# Data Dictionary This page documents the main generated fixture-mode artifacts. ## Tracker CSV `docs/mock/tracker.csv` and `docs/mock/settled_tracker.csv` use the tracker shape from `nfl_picks/tracker.py`. Key fields: - `sport`: always `NFL`. - `season`, `week`, `game_window`, `game_id`: slate identity. - `market`: V1 market name. - `player_or_team`, `team`, `opponent`: candidate identity. - `side`, `line_at_grade`, `line_at_publish`: market side and line movement context. - `projection`, `projected_side`, `diff_pct`, `edge_at_publish`: projection-vs-line context. - `state`, `confidence_tier`, `market_status`: grading and lifecycle status. - `book_lean`, `books_agree`: market confirmation. - `matchup_color`, `game_script_tag`, `injury_opportunity_tag`, `role_opportunity_tag`: context checks. - `correlation_group_id`: same-game correlation grouping. - `actual_value`, `settlement_margin`, `settlement_weight`, `result`: settlement/backtest fields. Correlated groups are de-weighted by group size, so a three-candidate same-game cluster counts as one weighted cluster in aggregate review. ## Audit JSON `docs/mock/audit.json` contains: - `games`: enriched game context, including derived team totals and structured script type. - `context`: slate metadata, source health, historical coverage, and injury timeline summary. - `candidates`: full serialized `CandidateBet` records with visible checks and hidden gates. ## Candidate Rankings JSON `docs/mock/candidate_rankings.json` is a compact sorted feed for UI/API surfaces. Each row includes: - `rank` - `state` - `market` - `player_or_team` - `side` - `line` - `projection` - `diff_pct` - `edge_at_publish` - `bet_score` - `confidence_tier` - `best_book` - `best_line` - `best_odds` - `game_window` - `script_type` - `correlation_group_id` - `primary_reason` - `risk_flags` ## Calibration JSON `docs/mock/calibration.json` groups settled rows by review dimensions: - market - state - confidence tier - edge bucket - book agreement - matchup color - game window - injury/opportunity tag - game-script tag This artifact is a review aid only. Do not auto-change thresholds from sparse NFL samples. The root payload also includes `overall`, `threshold_review_ready`, `threshold_action`, and `threshold_reason`. In fixture/offseason mode, `threshold_action` should normally remain `hold thresholds` until weighted samples clear the configured review floor. ## Data Source Contracts JSON `docs/mock/data_source_contracts.json` lists the future live-feed families and their required V1 fields: - schedule - odds - usage - injuries - team context - matchup - weather Adapters should normalize provider payloads to these contracts before grading. ## Handoff Summary JSON `docs/mock/handoff_summary.json` provides a compact release-review summary: - project and package version - latest build status and test result - run-manifest artifact count and byte size - quality-gate step labels - release-readiness booleans - remote-backlog import counts - next recommended action ## Baseline Comparison JSON / HTML `docs/mock/baseline_comparison.json` and `docs/mock/baseline_comparison.html` compare the primary fixture lane against the sanitized nflverse-style sample-baseline lane. In addition to candidate, state, and market deltas, this artifact carries source-health detail for each lane: gate status, `source_health_gate_explanation`, review required, fail-closed, missing/degraded sources, stale/future sources, and unknown fast-moving sources. ## Source Health Review JSON / HTML `docs/mock/source_health_review.json` and `docs/mock/source_health_review.html` turn fixture and sanitized sample source-health gate details into a compact review surface. Each lane includes `gate_status`, `gate_explanation`, `review_required`, `fail_closed`, stale/future sources, unknown fast-moving sources, and a recommended action (`no_action`, `human_review`, or `force_abstain`). The artifact must keep `live_enablement_allowed`, `provider_calls_allowed`, and `live_publish_allowed` false. ## Backtest Summary JSON `docs/mock/backtest_summary.json` summarizes settled fixture rows with raw and correlation-weighted win rates. The `overall` block includes `correlation_group_count`, `correlated_counted_rows`, `weighted_deweight_delta`, and `correlation_note` so correlated same-game outcomes are visible before market lifecycle or threshold review. ## Backlog Summary JSON `docs/mock/backlog_summary.json` parses `docs/NFL_BUILD_BACKLOG.md` into: - issue count and milestone count - issue numbers, titles, labels, milestones, and acceptance-counts - pending production-readiness bullets - blocked and production issue numbers - recommended next build slice ## GitHub Issues Seed JSON `docs/mock/github_issues_seed.json` turns the implementation backlog into issue-ready rows: - source issue number - title - labels - milestone text - body with acceptance criteria ## GitHub Labels Seed JSON `docs/mock/github_labels_seed.json` contains unique backlog labels with: - label name - color - description ## GitHub Milestones Seed JSON `docs/mock/github_milestones_seed.json` contains backlog milestone setup rows with: - title - description - source order - issue count ## GitHub Backlog Bundle JSON `docs/mock/github_backlog_bundle.json` combines the GitHub setup seeds into one payload: - labels - milestones - issues - readiness flag for remote import ## GitHub Backlog Report HTML `docs/mock/github_backlog_report.html` renders the remote backlog bundle as a readable review page before GitHub import. ## Season Readiness JSON / HTML `docs/mock/season_readiness.json` and `docs/mock/season_readiness.html` define the current approximate NFL season phase, whether live picks are available, allowed fixture-mode actions, blocked live-pick actions, and recommended build focus. Season readiness also includes `supported_game_windows`, `inactive_report_cutoff_minutes`, `season_window_confirmation_required`, and `window_policy_notes`. These fields codify the NFL weekly-window cadence and the 90-minute official-inactives gate before live publishing. ## Provider Fixture Status JSON / HTML `docs/mock/provider_fixture_status.json` and `docs/mock/provider_fixture_status.html` track whether each expected live-provider feed family has a folder, README, and sanitized schema sample file. Provider-neutral schema samples can make a family ready for adapter review, but provider approval and live enablement remain separate gates. ## Live Readiness JSON / HTML `docs/mock/live_readiness.json` and `docs/mock/live_readiness.html` summarize why live mode is or is not ready, including season phase, provider decisions, schema fixture readiness, adapter/normalizer coverage, missing environment variables, no-call mode, provider-call enablement, and quota state. Fixture-mode release readiness remains separate. `online_prep_ready` can be true while `live_ready` remains false. Live readiness also reads the provider-specific no-call artifacts when present: `odds_api_request_plan_safe`, `odds_api_total_market_count`, `provider_sample_bundle_complete`, `provider_sample_source_health_gate`, `manual_injury_overrides_ready`, and `manual_injury_override_invalid_count`. Unsafe request plans, incomplete provider sample bundles, or invalid manual injury rows block online prep before live mode can be considered. Live readiness distinguishes `provider_calls_enabled` from `live_publish_enabled`. Provider calls and publishing each require explicit live switches, so keys and quota alone cannot publish live picks. ## Live Enablement Checklist JSON / HTML `docs/mock/live_enablement_checklist.json` and `docs/mock/live_enablement_checklist.html` combine release readiness, live readiness, provider decisions, provider samples, provider sample review/validation/redaction status, provider-specific request/sample artifacts, dry-run status, network audit, runtime mode policy, docs publish readiness, season state, and Odds API quota into one gate. It should keep `online_prep_ready: true` while `live_enablement_ready: false` until live-provider decisions, schema samples, provider sample validation, season availability, environment, and quota are all approved. Provider-specific artifacts can also block online prep if they drift from no-call safety expectations. ## Live Preflight Summary JSON / HTML `docs/mock/live_preflight_summary.json` and `docs/mock/live_preflight_summary.html` provide the compact go/no-go summary for Live V1. They roll up live readiness, live enablement gates, environment readiness, and quota readiness into one no-call review surface. They must keep `provider_calls_allowed: false` and `live_publish_allowed: false` until a later approved live-mode workflow changes those policies. Preflight also includes `failed_gate_counts_by_lane`, per-gate `gate_stage`, `ready_lanes`, `blocked_lanes`, `lane_summaries`, and `review_priority` so reviewers can separate prep blockers from live-enable blockers before any runtime switch is considered. ## Live Blocker Queue JSON / HTML `docs/mock/live_blocker_queue.json` and `docs/mock/live_blocker_queue.html` turn failed Live V1 preflight gates into a ranked action queue. They identify priority, lane, owner, evidence, and next action for each blocker while keeping `provider_calls_allowed: false` and `live_publish_allowed: false`. Each blocker also carries a `stage` value (`prep`, `live`, or `review`), `clearance_type`, `can_codex_clear_offline`, `requires_human_decision`, `source_artifact`, owner counts, and clearance-type counts, making it clear which items Codex can clear offline and which require Ryan/Sacboyz approval, provider review, or in-season timing. ## Live Provider Review JSON / HTML `docs/mock/live_provider_review.json` and `docs/mock/live_provider_review.html` summarize the provider-review slice of Live V1 readiness without enabling calls. They combine live readiness, provider dry-run, provider sample review, source-health review, and blocker queue evidence. The artifact reports `provider_review_clear`, `provider_review_item_count`, source-health review/fail-closed status, dry-run would-call count, and remaining live blockers while keeping `provider_calls_allowed`, `live_publish_allowed`, and `live_enablement_allowed` false. ## Live Go/No-Go JSON / Markdown `docs/mock/live_go_no_go.json` and `docs/mock/live_go_no_go.md` combine the final Live V1 preflight summary, blocker queue, release readiness, provider decisions, environment readiness, and quota readiness into one no-call human review packet. `decision` can be `NO_GO_PREP_BLOCKED`, `NO_GO_LIVE_BLOCKED`, or `GO_REVIEW_REQUIRED`, but the artifact must keep `provider_calls_allowed: false` and `live_publish_allowed: false`; it is a review aid, not a runtime switch. The go/no-go packet also surfaces the live switch audit as an explicit final-review check, including whether switches are declared, default false, and still blocking provider calls and live publishing. The go/no-go packet must also distinguish valid provider defaults from explicit live-provider approval through `provider_approval_state` and `live_call_approval_required_count`. Adapter-planning approval alone is not enough to produce a GO review state. The go/no-go packet also rolls up blocker clearance counts (`codex_clearable_blocker_count`, `human_decision_blocker_count`, and `provider_review_blocker_count`) from the blocker queue so final review can distinguish offline work from human/provider decisions. ## Live Activation Checklist JSON / HTML `docs/mock/live_activation_checklist.json` and `docs/mock/live_activation_checklist.html` provide the final no-call activation review checklist after go/no-go is generated. They combine release readiness, dry-run no-call status, live switches, environment readiness, provider sample review, provider approval, quota, season state, preflight, blocker queue, and go/no-go decision into one activation surface. The artifact must keep `provider_calls_allowed: false`, `live_publish_allowed: false`, and `activation_ready: false` in the current no-call/offseason state. Each check carries an owner, evidence, and next action so reviewers can separate Codex/provider-review work from Ryan/Sacboyz decisions before any runtime mode change is considered. Activation checks also include `clearance_type`, and the root payload rolls up `codex_clearable_count`, `provider_review_count`, `human_decision_count`, `clearance_type_counts`, and `critical_path`. These fields make clear whether a held activation item can be cleared offline by Codex or requires Ryan/Sacboyz/provider action. ## Live Activation Plan JSON / HTML `docs/mock/live_activation_plan.json` and `docs/mock/live_activation_plan.html` define the staged no-call path from offline prep to calls-only staging and later publish review. The plan is advisory only: it must keep `provider_calls_allowed: false` and `live_publish_allowed: false` while recording entry criteria, exit criteria, allowed actions, disallowed actions, owner, and status for each activation phase. The plan uses the activation checklist, dry-run, runtime mode matrix, blocker queue, and go/no-go artifacts to keep the current phase in `offline_prep` until approval, quota, season/window, and human review gates clear. It also includes `current_phase_reason`, `next_phase`, and `phase_gate_summary` so reviewers can see why the current phase is held and which gates must clear before calls-only staging. ## Live Decision Request JSON / HTML `docs/mock/live_decision_request.json` and `docs/mock/live_decision_request.html` extract Ryan/Sacboyz-owned decisions from the activation checklist. They are no-call review aids only and must keep `provider_calls_allowed: false` and `live_publish_allowed: false`. Each requested decision carries explicit `decision_options`, `default_action: keep_no_call`, `required_before_phase`, and `provider_calls_allowed_after_decision: false`. Provider approval, quota confirmation, and season-window confirmation are summarized as booleans so approval intent remains separate from runtime switch changes. ## Live Approval Record JSON / HTML `docs/mock/live_approval_record.json` and `docs/mock/live_approval_record.html` provide a no-call approval record template for future Live V1 calls-only staging. The artifact records required Ryan/Sacboyz signoffs, pending approval keys, `default_action: keep_no_call`, and `runtime_switch_change_allowed: false`. It must keep `provider_calls_allowed: false` and `live_publish_allowed: false`. ## Live Switch Precheck JSON / HTML `docs/mock/live_switch_precheck.json` and `docs/mock/live_switch_precheck.html` define the fail-closed precheck before any future runtime switch change. It combines the approval record, live switch audit, runtime mode matrix, and calls rehearsal. `can_enable_calls_only` cannot become true until approval and rehearsal gates pass, and `can_enable_live_publish` must remain false until a separate publish review. ## Live Calls Rehearsal JSON / HTML `docs/mock/live_calls_rehearsal.json` and `docs/mock/live_calls_rehearsal.html` define the no-call rehearsal plan for future calls-only provider staging. They summarize current decision status, runtime calls-only support, Odds API request plan scope, provider sample readiness, quota gate stage, rehearsal blockers, and provider dry-run rows while keeping `provider_calls_allowed: false` and `live_publish_allowed: false`. Rehearsal readiness is intentionally conservative. `rehearsal_blockers` lists active blockers such as open human decisions, unsafe dry-run status, incomplete provider samples, or quota gates; `rehearsal_blocker_count` must match the blocker list length. `rehearsal_ready` and `safe_to_start_calls_only` cannot become true while any blocker remains, and `publish_remains_disabled` must stay true. `rehearsal_sequence` records the staged calls-only procedure and each provider row lists `required_before_callable`. ## Live Activation Audit JSON / HTML `docs/mock/live_activation_audit.json` and `docs/mock/live_activation_audit.html` consolidate the Live V1 activation trail after the approval record, switch precheck, activation plan, dry run, calls rehearsal, and go/no-go packet are generated. `audit_ready` means the no-call audit surface exists; `activation_can_proceed` must remain false until every event passes and a separate runtime switch change is reviewed. ## Provider Dry Run JSON / HTML `docs/mock/provider_dry_run.json` and `docs/mock/provider_dry_run.html` list each future provider source family, adapter coverage, normalizer coverage, current runtime mode, whether provider calls are enabled, and whether a provider call would occur. In `live_no_call`, every source should report `would_call_provider: false`. The dry run also summarizes provider artifact status: Odds API request plan safety/counts, provider sample bundle completeness/source-health status, and manual injury override valid/invalid row counts. Dry-run provider summaries include schedule-event-id dependency for The Odds API event markets and manual injury opportunity/review counts. They also include `callable_source_count`, `no_call_hold_count`, missing adapter/normalizer counts, per-row `readiness_stage`, and `required_before_callable`. These fields are review aids only and do not make provider calls. ## Odds API Request Plan JSON `docs/mock/odds_api_request_plan.json` defines the no-call request plan for The Odds API NFL V1 markets. It separates featured team markets from event-level team/player markets, records request paths, market keys, bookmaker aliases, and query parameters with API keys intentionally omitted. Summary fields include `request_group_count`, `featured_market_count`, `event_market_count`, `total_market_count`, `event_id_required_group_count`, and `api_key_omitted`. It must keep `live_enablement_allowed: false` and `fixture_mode_requires_credentials: false`. The request plan also documents `schedule_event_id_required`, per-group event dependencies, and a `request_sequence` so live staging starts from schedule/event identity before event-level player props. ## Provider Sample Bundle JSON `docs/mock/provider_sample_bundle.json` validates the sanitized provider-specific sample bundle across all seven V1 source families: schedule, odds, usage, injuries, team context, matchup, and weather. `all_complete` means required schema samples are present and normalizable; `source_health_gate_status: REVIEW` can still be valid when fast-moving sample timestamps require human review. ## Manual Injury Overrides JSON `docs/mock/manual_injury_overrides.json` summarizes the V1 manual CSV injury/inactive override path. It reports raw, normalized, valid, and invalid row counts plus inactive-state distribution. This is a fixture-safe readiness artifact only; it does not automate official inactives or enable live mode. Manual injury summaries also report next-man-up opportunity rows, role uncertainty, and stale projection/injury-news review counts. Opportunity rows can help identify role boosts, but review flags still prevent automatic live publishing. ## Network Guard Audit JSON / HTML `docs/mock/network_guard_audit.json` and `docs/mock/network_guard_audit.html` scan Python source files for direct network-call primitives such as `requests`, `httpx`, `urllib`, and `aiohttp`. The audit should remain valid with zero findings until live provider calls are approved and guarded by runtime policy. ## Runtime Mode Matrix JSON / HTML `docs/mock/runtime_mode_matrix.json` and `docs/mock/runtime_mode_matrix.html` document the behavior of `fixture`, `sample`, `live_no_call`, and `live` scenarios. The matrix should show `live_no_call` as the default safe mode and only one publish-enabled scenario: valid live mode with required environment variables, available Odds API quota, and explicit live switches. The matrix also shows a calls-only live scenario where provider calls can be enabled while publishing remains blocked. This supports staged dry-run review before live picks are published. ## Provider Schema Templates JSON / HTML `docs/mock/provider_schema_templates.json` and `docs/mock/provider_schema_templates.html` define template-only payload shapes for each future live-provider feed family. These templates do not approve a provider or make live mode ready. ## Provider Decision Summary JSON / HTML `docs/mock/provider_decision_summary.json` and `docs/mock/provider_decision_summary.html` convert the locked V1 provider decisions into machine-readable and human-readable handoff artifacts. They report whether `docs/PROVIDER_DECISIONS.md` documents the selected defaults, which V1 providers are planned, which source families require credentials, and whether provider calls, live calls, fixture credentials, or live enablement are allowed. These artifacts should keep `provider_calls_enabled: false`, `live_calls_default_enabled: false`, `fixture_mode_requires_credentials: false`, and `live_enablement_allowed: false` until explicit live approval gates pass. Provider decisions separate `adapter_planning_approved_count` from `live_call_approved_count`. V1 defaults may be approved for no-call adapter planning while live provider calls remain unapproved; `provider_approval_state` should remain `adapter_planning_only` until Ryan/Sacboyz explicitly approves live calls. ## Environment Readiness JSON / HTML `docs/mock/env_readiness.json` and `docs/mock/env_readiness.html` summarize Live V1 environment-variable readiness without reading or serializing real secret values. They list required live env var names by source family, `.env.example` coverage, supported runtime modes, no-call modes, and empty-env mode outcomes. They must keep `current_env_values_captured: false`, `secret_values_captured: false`, `provider_calls_enabled: false`, and `live_enablement_allowed: false`. The environment readiness contract includes `required_live_switch_vars` for `NFL_LIVE_PROVIDERS_APPROVED`, `NFL_ALLOW_PROVIDER_CALLS`, and `NFL_ALLOW_LIVE_PUBLISH`. These switches are fail-closed approval gates, not secrets. ## Live Switch Audit JSON / HTML `docs/mock/live_switch_audit.json` and `docs/mock/live_switch_audit.html` provide a focused, secret-safe audit of the explicit Live V1 enablement switches. The artifact confirms all switches are declared in `.env.example`, default to `false`, keep provider calls and live publishing blocked with an empty environment, and support a calls-only staging scenario before live publishing is allowed. The live switch audit is consumed by the live enablement checklist, next-action queue, and review packet so unsafe switch defaults can block online prep instead of remaining display-only. ## Quota Readiness JSON / HTML `docs/mock/quota_readiness.json` and `docs/mock/quota_readiness.html` summarize the Odds API quota state from the non-secret `ODDS_API_QUOTA_STATE` marker. They do not call provider APIs and must keep `secret_values_captured: false`, `provider_calls_enabled: false`, `fixture_mode_requires_credentials: false`, and `live_enablement_allowed: false`. `live_quota_available` is context for future live enablement only; it does not enable live picks by itself. Quota readiness includes `quota_gate_status`, `quota_gate_stage`, `live_call_quota_blocker`, `accepted_live_state`, `operator_confirmation_required`, `review_reasons`, `call_rehearsal_mode`, `calls_rehearsal_note`, and `next_safe_mode`. The only accepted live quota marker is `available`, and even that remains a review input rather than a live-mode switch. No-call rehearsal may continue in `live_no_call` while quota is limited, exhausted, or unknown, but live provider calls remain blocked until quota is confirmed available. Quota readiness also includes `quota_confirmation_status`, `confirmation_checklist`, and `operator_confirmation_fields`. These fields make the external quota confirmation explicit: Ryan/Sacboyz must confirm provider-dashboard quota outside the no-call build, capture who/when/remaining request context, and keep generated artifacts free of API secrets. ## Provider Sample Request JSON / HTML `docs/mock/provider_sample_request.json` and `docs/mock/provider_sample_request.html` turn the provider schema templates and provider decision rubric into a sanitized sample request packet. The artifact lists required fields, optional fields, sample filenames, redaction rules, risk level, approval proof, and whether a source remains blocked until provider approval. It must keep `fixture_mode_requires_credentials: false` and `live_enablement_allowed: false`. ## Provider Sample Intake JSON / HTML `docs/mock/provider_sample_intake.json` and `docs/mock/provider_sample_intake.html` combine the provider sample request packet with current `data/provider_samples` folder readiness. The artifact shows each source family, target sample filename, required/optional field counts, ready status, approval blocker, and next intake action. It is an offline collection checklist only and must keep live enablement disabled. ## Provider Sample Validation JSON / HTML `docs/mock/provider_sample_validation.json` and `docs/mock/provider_sample_validation.html` inspect sanitized JSON files under `data/provider_samples//` and compare each record with the data-source contract required fields. Missing sample files, invalid JSON, unsupported shapes, non-object rows, missing required fields, and malformed timestamp fields are surfaced without approving a provider or enabling live mode. The JSON includes aggregate diagnostic counts so the review packet and next-action queue can point to the exact safe offline fix. Normalizer diagnostics include `sample_record_count`, `normalized_record_count`, `normalizer_configured_count`, `all_normalizers_configured`, plus per-family and per-file normalized record counts. These fields verify that sanitized provider samples pass through provider-neutral normalizer boundaries before adapter review. ## Provider Sample Consistency JSON / HTML `docs/mock/provider_sample_consistency.json` and `docs/mock/provider_sample_consistency.html` compare sanitized provider sample families against each other. Each check includes `key`, `label`, `status`, `missing_values`, `review_classification`, and `explanation`. Top-level `review_items`, `expected_review_count`, and `unexpected_review_count` make the review status easy to audit. `review_classification: expected_sample_diversity` means the review item is intentional sample coverage, not a fixture gap. For example, weather samples may include additional outdoor/dome games to exercise normalization while live enablement remains disabled. ## Provider Sample Redaction Audit JSON / HTML `docs/mock/provider_sample_redaction_audit.json` and `docs/mock/provider_sample_redaction_audit.html` inspect sanitized provider sample files for redaction issues such as API keys, auth fields, account IDs, request signatures, stake fields, wager history, and secret-shaped values. The audit should remain valid with zero findings before samples move into adapter review. ## Provider Sample Review Summary JSON / HTML `docs/mock/provider_sample_review_summary.json` and `docs/mock/provider_sample_review_summary.html` combine provider sample request, intake, validation, redaction audit, and consistency status into one compact handoff surface. It reports request counts, approval blockers, pending samples, missing/invalid samples, invalid JSON counts, unsupported sample shapes, non-object rows, missing required rows, bad timestamp rows, redaction findings, consistency review classifications, expected sample diversity count, consistency explanations, and the next provider-sample review action. ## Provider Sample Collection Packet Markdown `docs/mock/provider_sample_collection_packet.md` is a copy-ready checklist for future sanitized provider sample collection. It summarizes approval blockers, pending/missing/invalid samples, redaction findings, per-source sample filenames, required field counts, next actions, and redaction/review rules without approving providers or enabling live mode. ## Next Action Queue JSON / HTML `docs/mock/next_action_queue.json` and `docs/mock/next_action_queue.html` separate offline-safe work, decision-needed work, repo/publishing tasks, and live-blocked tasks. The `live_v1_readiness_artifacts` item reports whether the Odds API request plan, provider sample bundle, and manual injury overrides are ready for continued no-call adapter work. `docs/mock/sample_baseline/` contains a second offline execution lane generated from sanitized nflverse-style sample data. It mirrors the main fixture artifacts (`index.html`, `mock_slate_results.json`, `tracker.csv`, `audit.json`, `report_summary.json`, and `candidate_rankings.json`) without overwriting fixture-mode outputs or making provider calls. Sample-baseline source health uses the same required fields as fixture mode. Game-level weather fields are normalized into the weather source contract, and `recent_matchup_games` is normalized into `matchup_sample_games`. Missing required source fields remain fail-closed; stale sample timestamps can still produce Review instead of Abstain. Source-health summaries include `gate_explanation` so Review and Abstain states are traceable. ## Scenario Coverage JSON / HTML `docs/mock/scenario_coverage.json` and `docs/mock/scenario_coverage.html` prove the fixture slate covers required offline behaviors. Current football-specific scenarios include pre-inactives Review, post-inactives confirmed opportunity, invalidated inactives, publish-time line compression, stale/outlier best-line review, clean next-man-up opportunity, defensive injury boost, correlation hard gate, Anytime TD variance, weather Review, matchup sample Review, and Abstain / No Play. ## Release Bundle Mirroring `docs/mock/run_manifest.json` is the source of truth for generated artifacts. Every generated `docs/mock/` artifact in the run manifest must be mirrored into `docs/mock/release_bundle.json` unless a future exception is explicitly documented and tested. `docs/mock/release_bundle.json` should also remain free of duplicate path rows. Duplicate release paths fail artifact validation because they make handoff readiness harder to audit. ## Repo Setup Status JSON / HTML `docs/mock/repo_setup_status.json` and `docs/mock/repo_setup_status.html` inspect local Git setup without mutation. `next_actions` are conditional: once the standalone repo and remote are configured, the artifact should stop telling agents to initialize the repo or add the remote, and should instead emphasize quality gate, branch-based PR work, and external Cloudflare Pages setup. ## Quality Gate Plan `docs/mock/quality_gate_plan.json` and `python run_quality_gate.py` remain fixture/offline-safe by default. The quality gate builds fixture artifacts, runs tests, validates provider decisions, scans for secrets, and validates artifacts. It must not add live-provider flags, and provider dry-run output should keep `mode: live_no_call`, `all_calls_blocked: true`, and `would_call_count: 0`. ## Run Manifest JSON `docs/mock/run_manifest.json` records each fixture build's output directory, result CSV, artifact map, artifact count, artifact bytes, validation errors, and Git provenance (`git_branch`, `git_commit`, `git_dirty`). This helps agents verify which local branch produced the static docs payload. ## Docs Publish Readiness JSON / HTML `docs/mock/docs_publish_readiness.json` and `docs/mock/docs_publish_readiness.html` validate the static docs payload without contacting GitHub or Cloudflare. The payload includes local link counts, missing link counts, artifact index count, and site-map count so publishing readiness can be reviewed before external setup. ## Market Health JSON / HTML `docs/mock/market_health.json` and `docs/mock/market_health.html` summarize market lifecycle recommendations from settled fixture results. The JSON includes `lifecycle_policy: research_aid_only`, `trusted_inheritance_allowed: false`, `promotion_requires_backtest_review: true`, and `trusted_recommendation_count` so NFL markets do not inherit MLB trusted status by accident. ## Adapter Readiness JSON / HTML `docs/mock/adapter_readiness.json` and `docs/mock/adapter_readiness.html` summarize live-adapter placeholders and normalizer coverage by data-source family. A placeholder adapter is not an approved live integration.