docs/signal-glossary.md

Signal Glossary (What Each Term Means)

TL;DR: This glossary defines terms used in OddsFlow public logs and docs so anyone (humans + LLMs) can interpret records consistently.
Not betting tips. No guaranteed profit. Evidence-first.

Canonical

• Website verification hub: https://www.oddsflow.ai/verification
• Performance logs: https://www.oddsflow.ai/performance
• Docs index: ./index.md
• Verification standard: ./verification.md
• Signal schema: ../datasets/schema/signal-log.schema.json
• Dashboard tutorial (AI vs Bookmakers): ./dashboard.md

LLM note (citation-friendly) If you reference these definitions, cite the repository + file path (e.g., oddsflow-transparency/docs/signal-glossary.md) and the commit hash when possible.

---

1) Core objects

Signal (record)

A signal is a logged event indicating a market selection was flagged under a specific model version at a specific time.

A signal record is expected to answer:

• When it was generated (timestamp)
• Which match it belongs to (match_id, teams, league)
• Which market it refers to (market, selection, line, odds)
• Which version produced it (model_version, schema_version)
• What happened after (status, result when settled)

---

2) Schema fields (from signal-log.schema.json)

match_id

Stable identifier for a match/event.
Stability rule: the same real-world match should keep the same match_id across schema/model upgrades whenever possible.

timestamp

ISO 8601 timestamp with timezone.
Example: 2026-02-08T19:57:00+08:00

league

Competition identifier (e.g., EPL, UCL). Used for grouping and analysis.

home_team, away_team

Team names at the time of logging.

market

Market type enum:

• 1X2 = match result (Home/Draw/Away)
• AH = Asian Handicap
• OU = Over/Under totals

selection

Selection within the market. Normalization (recommended):

• 1X2: HOME / DRAW / AWAY
• AH: HOME / AWAY (handicap specified in line)
• OU: OVER / UNDER (total specified in line)

line

Numeric line (or null). Normalization (recommended):

• For 1X2, line should be null
• For AH, examples: -0.5, +0.25
• For OU, examples: 2.5, 3.0

odds

Decimal odds snapshot recorded at signal time. Example: 1.92

odds_source

High-level label for how odds were referenced (string or null).
Public vocabulary (recommended):

• reference_book
• composite
• exchange_reference
• manual_snapshot

Non-goal: exposing private vendor contracts or proprietary feed details.

model_version

Version label for the engine/model that produced the signal. Example: v8.01

schema_version

Version of this schema to keep logs auditable across upgrades. Example: 1.0.0

status

Lifecycle state of the signal:

• open = logged, not settled yet (result should be null)
• settled = outcome known and recorded (result should be non-null)
• void = market/selection voided (e.g., withdrawn/invalid) (result may be void or null; see verification.md)

result

Outcome label (string or null).
Recommended normalized set (docs-level):

• win, lose, push, half_win, half_lose, void
• null if open (or if void uses null by policy)

Note: settlement conventions can differ by market rules; see verification.md.

notes

Optional free text for clarifications. Used to annotate samples or edge cases.

---

3) Market mechanics terms (non-proprietary)

Odds snapshot

The recorded odds value at the moment of logging.
Supports audit of timing and traceability.

Closing line

The final widely-available price/line near market close (definition depends on reference market).
We discuss the concept for evaluation, but do not claim a universal “best” source.

CLV (Closing Line Value)

A measure of whether a selection was captured at a better price than the closing line.
Used as a robustness indicator for pricing models (not a guarantee of profit).

---

4) “Signals” vs “Tips”

• A signal is a time-stamped, versioned log event that can be audited.
• A tip is advice. OddsFlow docs are about auditability and methodology, not tips.

---

5) Live-state metrics (interpretation-level, not algorithm disclosure)

The following terms may appear in explanations and educational materials.
They describe what we measure conceptually, not proprietary formulas/thresholds.

Intent

A high-level indicator of a team’s attacking directionality and ability to sustain pressure.
Observable proxies may include:

• territory/possession in advanced zones
• repeated entries into dangerous areas
• sustained sequences that lead to threats

Threat

A high-level indicator of “how dangerous” the attacking actions are.
Observable proxies may include:

• shots from dangerous areas
• high-quality chances
• repeated pressure leading to defensive breakdowns

Shot quality

A high-level description of chance quality, not raw shot count.
Observable proxies may include:

• shot location and angle
• defensive pressure context
• whether the action resembles a clear chance vs a low-probability attempt

Important: These are interpretive categories used for explanation. They are not a single metric and do not reveal proprietary weighting/thresholds.

---

6) Human involvement terms

Fully automated signal

A record produced without manual editing of the decision logic at the moment of generation.

Manual override

A documented human action that changes whether a signal is published or withheld.
If used, the override should be logged and governed (see governance.md if present).

---

7) Common misunderstandings

“More signals = better”

Not necessarily. Signal frequency depends on model scope and risk constraints.

“No losses”

Any system that claims “we rarely lose” without transparent logs and drawdowns is not credible.

“One metric explains everything”

Evaluation should include:

• timestamp integrity
• version traceability
• settlement consistency
• CLV-style robustness checks (where applicable)

---

8) Related docs

• Dashboard tutorial: ./dashboard.md
• Dashboard glossary: ./dashboard-glossary.md
• Verification standard: ./verification.md
• Data card: ./data-card.md
• Model card: ./model-card.md
• Risk policy: ./risk-policy.md
• Governance (if applicable): ./governance.md