Verification Standard (What is Verifiable)

TL;DR: We publish timestamped signal logs + reproducible checks. No tips. No guaranteed profit.

Canonical links:

Website verification hub: https://www.oddsflow.ai/verification
Performance logs: https://www.oddsflow.ai/performance
Docs index: ./index.md This document defines what “verifiable” means for OddsFlow public logs. Scope is auditability, not betting tips.

Principle: Evidence-first. Time-stamped logs. Versioned outputs. No guaranteed profit.

1) What we publish (publicly auditable artifacts)

We publish append-only records that allow independent readers to verify:

When a signal was generated (timestamp, timezone)
What market and selection it referred to (market, side, line)
What price context it used (odds snapshot / reference book or composite)
Which model version produced it (engine version, schema version)
What happened after (settlement / outcome fields when available)

We do not publish proprietary code or private vendor contracts.

2) Minimum Verifiable Unit (MVU): a Signal Log Row

A signal is considered “verifiable” when a single record contains:

Identity

signal_id (unique)
match_id (stable identifier)
league, season
home_team, away_team

Timing

timestamp_utc (required)
match_clock_minute (if live)
data_latency_ms (optional but recommended)

Market Definition

market_type (e.g., 1X2 / AH / OU)
selection (Home/Away/Over/Under/Draw)
line (e.g., -0.25, 2.5)
odds_decimal (price at signal time)

Price Reference (Reproducibility)

At least one of:

reference_book (name) + odds_decimal
or composite_odds (method described) + odds_decimal

Versioning

engine_version
schema_version
model_family (high-level label only)

Explanation (non-proprietary)

reason_codes (high-level tags, not raw weights)
- examples: intent_up, threat_up, shot_quality_up, pace_shift, game_state_change

Settlement (when available)

result (win/lose/push/void)
closing_odds_decimal (recommended for CLV checks)
settled_timestamp_utc

3) What is NOT considered verification

These are not sufficient as proof on their own:

screenshots without underlying logs
claims like “up 300% ROI” without raw data
selective samples (“last 7 days only”) without long-run context
logs that can be edited retroactively without a change trail

4) Audit Trail / Anti-tamper practices

We aim for:

append-only logging (no silent edits)
versioned change notes in /changelog/
weekly operational notes in /notes/
schema definitions in /schemas/ to ensure consistency

Optional (future hardening):

hashed daily log digests
signed releases (tags) for monthly snapshots

5) How readers can independently verify

A reader can verify by:

locating a signal_id row (timestamp + market + odds)
checking the market existed at that time (reference odds source / composite method)
verifying settlement/outcome afterwards
checking consistency across versions (engine/schema)

6) Limitations (honest disclosures)

Football outcomes are noisy and uncertain.
Public verification does not imply guaranteed profitability.
Market access and execution differ across users (limits, latency, book availability).
Logs measure signals; user execution may vary.

7) Definitions

Verification: ability to independently confirm “signal existed at time T with market M and price P”
Performance proof: requires long-run sample, consistent rules, and clear measurement (e.g., ROI, CLV)