# 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`