Strategy Analysis Architecture

Status: Permanent reference doc. Created Apr 26, 2026 as Phase 0 of the Strategy Analysis Revamp. Phase 1 shipped Apr 26, 2026 (see §0.4 + §0.9). Phase 2 shipped Apr 26, 2026 — see §0.10 for the equity 1m bars infrastructure changelog and revised Phase 3 gate criteria.

Purpose: Map every layer of strategy analysis the bot relies on (operative rules + production data + analysis scripts + dashboard surfaces), catalogue every documented assumption with its current validation status, identify integrity bugs and doc inconsistencies, and decide whether unified-simulation work is worth committing to.

Do NOT use this doc for daily decisions — for that, use: - docs/STRATEGY_PLAYBOOK.md §1 (current verdict) + §2 (Action Queue) - The dashboard 🎯 Action Queue tab - docs/FINDINGS.md (canonical narratives, per memory §J)

Do use this doc when: - Onboarding to the strategy-analysis surface area for the first time - Asking "do we have the data to answer this?" before designing a new study - Deciding whether to keep / archive / rewrite an existing analysis script - Sequencing the post-Phase-0 work (Phases 1–5 below)

Read order

1. §0.1 — the four layers (skim to orient)
2. §0.2 — assumption status table (the single most useful section)
3. §0.4 — bug regressions (these block several analyses today)
4. §0.5 — data gap matrix (what we can/cannot answer)
5. §0.6 — decision-usefulness verdict (is unified simulation worth building?)
6. §0.3 — doc consolidation map
7. §0.7 — phased roadmap

0.0 Why this doc exists (framing)

Strategy analysis on this bot lives across 22 dashboard widgets, ~25 scripts, 8 production tables, and a dozen docs. Each surface answers a different question; none is canonical. Several quietly contradict each other (see §0.3 doc inconsistencies). Several are silently broken by data-integrity bugs (see §0.4). The fragmentation is why "I'm not sure if Universe View is a trade simulator" is a reasonable question — it isn't, but neither is the Finding-A simulator on its own, and there's no single canonical engine.

This doc is the architectural baseline before any unification work. Phases 1–5 in §0.7 build on top of it; each phase has its own approval gate so no implementation direction is committed prematurely.

0.1 The four layers

0.1.1 Layer 0 — Operative rules and original assumptions

These docs define what the bot is supposed to do. They predate most of the live trading data and contain assumptions that have not all been re-validated against the 116-trade live history.

Original-assumption surfaces that have NOT been re-validated against live 116-trade data:

• §9 Phase 1 +50.6% / Phase 2 +166.2% Monte Carlo projections — based on Q3 2025 backtest. Live run-rate is +$1.44/trade × ~7 trades/week ≈ +$525/year on current capital → roughly +21% / year, not +50.6%. Decision: do not use §9 numbers as expected returns; document as model baseline.
• §10 conviction-bucket Q3 stats — extensively re-tested in v2 / v3 audits with retractions (90%+ LONG bucket skipped per #202; many v2 buckets retracted in v3 §2). Q3 stats remain interesting historical context but should not be used to set new rules.
• §3 priority score (now 0-8, Finding #313) — the original "70-80% is best bucket" claim was retracted in v3 (§2 v2 #6 retraction; was 82% SWBI-driven). Update May 30, 2026 (Finding #313): the base 0-6 mcap×conviction ordering was RE-VALIDATED on live data (Large LONG WR 45.7% n=35 > Mid LONG 34.3% n=70) and a volume-tier bump (+1 ≥$2k, +2 ≥$5k) was added → scale 0-8. The base ordering is now validated; the volume bump is the new, live-evidenced axis.
• §5.2 weekend-hold "DECISION: Trade with Exposure" — note in the doc says "quarterly validation". Hasn't been formally re-validated against Friday-entry / Monday-exit live data.
• §5.2.1 long-weekend 50% sizing — RESOLVED Apr 26 (#248): EDGE_CASES.md Category 2.1 reconciled to 50% (canonical). No longer a conflict.
• §4 trade-count transition — one bullet says "100 trades" for Phase 1→2, another says "150 trades". Internal contradiction.
• §8 leverage 10× — original assumption was 10× from a backtest era; IBKR portfolio-margin actually delivers ~4× (current Net Liq $27k vs buying power $109k). Already corrected in code, but §8 still mentions 10×.
• §2 LONG 70% threshold — operative is 70%; universe-view analysis uses 0.60 LONG / 0.30 SHORT (in analyze_universe_hit_rate). Different thresholds for different surfaces — definition drift risk if anyone cross-reads numbers.

0.1.2 Layer 1 — Forward-looking source of truth

These docs are the operational source for what to ship next and what we believe is true given live data. Per memory §J + §N these are canonical for strategy improvements; per §K they are mirrored across build_action_queue() + dashboard + Playbook §2.

Key discipline rules baked into Layer 1:

• 4-check bias gauntlet (memory §K): n adequate (≥12 ideally ≥20), ex-top-2 outliers survive, ex-repeat-tickers survive, full-population spillover passes.
• 5-outlier rule (memory §K, renamed from 3-outlier Apr 25 evening per Finding #232): GPRO + DELL + SWBI + TXN + STUB carry ~$430 of $167 net P&L on 116 trades; ex-them strategy is −$263 across 111 trades. ALWAYS report ex-top-2 alongside any headline.
• True-simulator rule (memory §K, added Apr 25 from Finding #228): every counterfactual rule needs a TRUE simulator that replays end-to-end on actual data. Proxies and observational tables conflate selection with causation.
• Single-source-of-truth rule (Audit_v3 §13.6): live production tables are canonical, derived artifacts are regenerated from them.
• Cross-interface rule (memory §M): any change to a gate/metric used in both trader and dashboard must enumerate every surface and prove a single shared definition.

0.1.3 Layer 2 — Production data tables

The ground truth for every live and counterfactual analysis. NULL rates and row counts pulled from prod on Apr 26, 2026. **(Snapshot superseded — see

321: actual_beat coverage is now ~95-99.8%, and the conviction_at_exit

/ regime_at_entry write-path bugs were fixed #234-#236. The Apr-26 counts below are retained as the point-in-time audit baseline.)**

Cross-table joins for analysis:

flowchart LR
  TAL[trade_audit_log<br/>117 rows] -->|condition_id| EM[earnings_markets<br/>900 rows]
  EM -->|condition_id| MK[markets<br/>5706 rows]
  EM -->|condition_id| PS[price_snapshots<br/>Timescale]
  PMOL[polymarket_opportunity_log<br/>1064 rows] -->|condition_id| EM
  SS[skipped_signals<br/>395 rows] -->|condition_id| EM
  CH[conviction_history<br/>65k rows] -->|condition_id| EM
  CH -.position_id.-> TP[trading_positions<br/>117 rows]
  TAL -.trade_id / shared keys.-> TP

Critical data NOT in our DB:

0.1.4 Layer 3 — Analysis scripts

Scripts that read Layer 2 + compute analytical artifacts. Producing files flow into Layer 4 (dashboard) or stdout. Heavy fragmentation here — multiple scripts for similar questions, several stale.

Master orchestrator (regenerates scripts/strategy_analysis_report.json every run; consumed by dashboard):

scripts/strategy_performance_analysis.py:run_analysis() runs ~20 sub-functions: - calculate_metrics → clean_trades_metrics / all_trades_metrics - compare_with_projections → projected_vs_actual - analyze_ibkr_constraints → ibkr_constraints - analyze_bug_impact → bug_impact - analyze_direction_timing_combo → direction_timing_combo - analyze_stop_losses → stop_loss_analysis - analyze_stop_reversals → stop_reversal_analysis (uses cached stop_reversal_actual_prices.json) - compute_position_sizing_quintiles → position_sizing_quintiles - analyze_skipped_cost → skipped_signal_cost (reads polymarket_opportunity_log) - analyze_volume_gate_counterfactual → volume_gate_counterfactual (reads skipped_signals) - analyze_performance_by_regime_vix → regime_vix_performance - analyze_finding_a_simulator → finding_a_simulator (reads finding_a_full.csv, does NOT re-simulate) - build_action_queue → action_queue (single-source for queue) - analyze_universe_hit_rate → universe_hit_rate (the largest section) - four_check_gauntlet_doc → bias_gauntlet - analyze_top_trades, analyze_prediction_accuracy, analyze_weekly_performance, compute_hold_durations, generate_cumulative_pnl, check_red_flags, estimate_roi

Simulators (true counterfactual replay):

Backtest scripts (archived data, not live):

Legacy / one-off (kept for reference, not actively run):

Backfill / ETL (feeds analysis tables):

src/earnings/ modules contributing to analysis:

0.1.5 Layer 4 — Dashboard sections (Strategy Analysis tab)

Single endpoint /api/strategy-analysis returns the full report (the report JSON IS the schema). The Strategy tab is rendered by renderStrategyAnalysis in earnings_dashboard/templates/dashboard.html ~line 11171, which dispatches to ~24 sub-renderers.

Twenty-three sections in tab order:

Dead / hidden / broken UI:

• renderRecommendations(...) BROKEN CALL — invoked at dashboard.html:11254 but the function was deleted (comment at :11482 confirms). Causes a runtime ReferenceError on every Strategy tab load (verifiable by opening browser console). Fix is one-line.
• Stop Reversal "wider stops" sub-table — parent div has display: none (~line 9474), but JS still populates the tbody. Dead UI work; remove either the populator or un-hide the parent.
• analysis.weekly_performance, analysis.hold_duration, analysis.cumulative_pnl_clean, analysis.cumulative_pnl_all, analysis.red_flags, analysis.trade_details, analysis.missed_signals_analysis — computed in run_analysis but no consumer in the Strategy-tab template. Some are intentionally hidden (per JS comment line 11242 "removed — not actionable"); others are orphan computations.
• Two PM accuracy panels — universe (§5 sub-block E) vs live-trades (§18). Same name, different population. No operator hint that they measure different things.
• Two regime surfaces — §7 card (snapshot of current SPY regime) vs §11 table (entry-time regime buckets across closed trades). Different data, similar wording.

API:

• /api/strategy-analysis — primary, returns analysis (from strategy_analysis_report.json) + backtest + bmo_amc_timing + current_regime + timestamp
• /api/regime — separate lightweight regime endpoint (reads same regime_cache from the same JSON)

0.2 Documented assumption status table

The single most useful section of this doc. Every documented strategy assumption, where it lives, when it was last validated, and what to do.

Validation legend: - ✅ validated — live data confirms within current sample - ⚠️ unvalidated — no live test against current data - 🛑 superseded — replaced by a numbered Finding - ❌ stale — contradicted by live data, no formal retraction - 🔁 conflict — two docs disagree

Summary count: 15 ✅ · 5 ⚠️ unvalidated · 11 🛑 superseded · 4 ❌ stale · 1 🔁 conflict (row 15 long-weekend resolved per #248)

0.3 Doc consolidation map

What to do with each strategy-analysis doc as Phase 1 work.

Net Phase 1 doc actions: 4 archives, 4 stale-warning headers, 3 active fixes (STRATEGY conflicts #15/#16/#27, EDGE_CASES sizing, HOLISTIC_REVIEW_PROMPT refresh), 0 rewrites.

0.4 Bug regressions discovered during this audit

Five concrete bugs surfaced during Phase 0 mapping. Listed in fix-priority order. None require trade-execution review (memory §J on prohibition does not apply — these are dashboard / persistence / write-path fixes).

Bug #1 — Dashboard renderRecommendations ReferenceError on Strategy tab load

• Location: earnings_dashboard/templates/dashboard.html:11254 invokes renderRecommendations(analysis, backtest, cohortTiming). The function definition was deleted (comment at :11482 confirms removal).
• Evidence: opening browser dev tools console on the Strategy tab shows ReferenceError: renderRecommendations is not defined. Tab still renders (the ReferenceError aborts the rest of renderStrategyAnalysis but the early sections have already painted before the call).
• Impact: any renderXxx call AFTER line 11254 in renderStrategyAnalysis may not execute. Hard to tell which sections silently fail without testing each.
• Fix difficulty: trivial (delete the line).
• Fix priority: HIGH — blocks reliable rendering.

Bug #2 — TradingOrchestrator._persist_position_open omits regime/VIX/SP500

• Location: src/earnings/trading_orchestrator.py:2388–2412 (INSERT statement) vs src/earnings/position_manager.py:324–347 (sets the fields).
• Evidence: 5 of 116 closed trades have regime_at_entry IS NULL; 7 have vix_at_entry IS NULL. NULL trades cluster in post-Apr-21 entries, consistent with the orchestrator path becoming more frequent recently.
• Impact: every regime-conditioned analysis (regime_vix_performance, v3 Finding B downtrend skip, v3 Finding E SHORT regime) loses signal as more trades land via the orchestrator path. The bug is a regression that gets worse with each new trade until fixed.
• Fix difficulty: small (mirror the field set from PositionManager.persist_position_open into the orchestrator INSERT).
• Fix priority: HIGH — every day this isn't fixed, more rows lose regime/VIX coverage forever.

Bug #3 — trade_audit_log.conviction_at_exit never set on close path

• Location: column exists (migration adds it); PositionManager close UPDATE (src/earnings/position_manager.py:505–572) does not touch it.
• Evidence: 116/116 closed trades have conviction_at_exit IS NULL.
• Impact: deferred Hypothesis H8 in Playbook §7 ("conviction-at-exit drop signal as predictive of stop hits") is permanently un-testable until this is fixed. trading_positions.final_conviction exists for earnings-detection cases (75/116 populated) but is not the same field.
• Fix difficulty: small (mirror Polymarket conviction read at close-path entry, write to column).
• Fix priority: MEDIUM — unblocks one deferred hypothesis; not blocking any current rule.

Bug #4 — trade_audit_log.sp500_change_at_entry never populated

• Location:
• Column exists.
• scripts/backfill_regime_for_audit_log.py:97–98 explicitly leaves SPY intraday change as NULL on historical rows ("undefined for past intraday").
• TradingOrchestrator._persist_position_open does not set it (Bug #2 parent).
• PositionManager.persist_position_open does set it, but only when MarketRegimeProvider.get_snapshot() returns a non-NULL sp500_change.
• Evidence: 0 of 116 closed trades have non-NULL sp500_change_at_entry.
• Impact: any analysis conditioning on SP500 intraday move at entry (e.g. "did the bot enter into a SPY drop?") cannot use audit log. Partial data exists in polymarket_opportunity_log (544/1064 = 51% populated post-#227).
• Fix difficulty: medium — need to decide whether to formalize NULL on historical rows and only capture forward, or attempt forward-only enrichment.
• Fix priority: LOW — analyses can use opportunity_log instead; acceptable to formalize "audit log SP500 is forward-only after Phase 1".

Bug #5 — trade_audit_log.stop_triggered undercounts by 28× (Finding #233 known)

• Location: multiple stop-exit code paths set exit_reason like 'stop_loss:hardware' but only 1 of them flips the stop_triggered boolean.
• Evidence: 2/116 closed trades have stop_triggered = true vs 57/116 matching exit_reason ILIKE '%stop%'. Documented in Finding #233.
• Impact: every analysis using stop_triggered is wrong by orders of magnitude. Workaround in place — all current analyses use exit_reason. Without writer fix, the bug stays.
• Fix difficulty: medium — patch every stop-exit code path; ideal forward-fix is a unified _persist_exit() helper that derives the boolean from the textual reason; backfill 55 historical rows.
• Fix priority: MEDIUM — workaround acceptable but creates permanent footgun for new agents; canonical-field-validity rule (Audit_v3 §14.7) means the bug should be fixed even though analyses route around it.

Bug #6 — polymarket_opportunity_log.hypothetical_pnl only 39% populated

• Location: scripts/compute_counterfactual_pnl.py is the backfill but is run on demand, not scheduled.
• Evidence: 416 of 1064 rows have non-NULL hypothetical_pnl; counterfactual_computed_at is set on all 1064 (so the script ran but produced NULL on 648 rows — possibly Polygon failures, possibly intentional "no data → leave NULL").
• Impact: skipped-signal cost analysis (analyze_skipped_cost) and any future unified simulator have a 61% data hole.
• Fix difficulty: small (re-run with verbose logging to triage why 648 rows produced NULL; refresh the timer cadence).
• Fix priority: MEDIUM — directly affects unified-simulator feasibility.

Summary (resolution status added Apr 26, 2026 after Phase 1):

0.5 Data gap matrix (decision-usefulness inputs)

For each major analytical question we might ask, do we have the data to answer it reliably today?

Summary:

• ✅ 8 questions answerable today.
• ⚠️ 5 questions partially answerable (need Phase 1 bug fixes or hypothetical_pnl backfill).
• ❌ 5 questions not answerable today (need Phase 2 forward data capture + Phase 3 simulator OR are permanent gaps).

0.6 Decision-usefulness verdict (extended)

Direct answer to the question: "is the outcome of having a unified simulator especially for past data going to be relevant enough for us to take decisions on trading strategy based on it?"

Headline: Conditional YES — useful as one of three triangulation

inputs (live data + simulator-on-traded + simulator-on-universe), NOT as a replacement for live data. (Update: Phase 1 + Phase 2 long since landed; Phase 3 PR 1-5 + Phase 4 COMPLETE as of May 31, 2026, #306-#322. The "not before Phase 1 + Phase 2 land" precondition is satisfied.)

When unified simulation IS decision-useful

1. Sample-size triangulation. Live n=116 trades × ~3.5x outlier concentration in the 5-outlier set (memory §K) means most live findings sit at the bias gauntlet's n≥12 floor. A simulator running on the 488 in-band markets the bot didn't trade gives ~5x more data points for the same direction/conviction/regime questions. When simulator confirms a live finding at higher n, confidence rises significantly.
2. Ex-bias diagnostics. The 5-outlier rule (GPRO + DELL + SWBI + TXN
3. STUB carrying ~$430 of $167 net P&L) is what makes live-data slices so unstable. Universe simulation effectively dilutes those 5 outliers across 600+ markets, surfacing the underlying signal cleanly. The live v3 audit retracted 6 hypotheses purely via the gauntlet; the simulator would have caught most of them earlier.
4. Counterfactual on skipped trades. The 488 markets the bot skipped today have NO stop-modeled counterfactual (just universe-view day-close return, no timing, no stops). A simulator that replays the bot's actual entry/exit/stop logic on those markets answers "what would the bot have made if it had traded these signals?" — currently un-answerable.
5. Regime / VIX / mcap conditioning at scale. Live n in regime sub-buckets is single digits (3 SHORT downtrends, 6 sideways SHORTs); universe-scale equivalents would be 20–50x larger.
6. Hypothesis pre-screening. Future audits could test 50 candidate rules in the simulator before deciding which 1–2 to validate against live data, avoiding the v2-style "ship a rule that destroys live alpha because the bias gauntlet wasn't applied".

When unified simulation is NOT decision-useful

1. Treating it as the optimizer. The simulator is a STATIC replay of the bot's logic. If we use it to find "the rule that made the most money in past data" we will overfit the 600-market window — exactly what the H-rule did at v2. The 4-check gauntlet must apply to simulator results just like live results.
2. Trusting it on assumptions we can't verify. Real Polymarket fill mechanics (would the bot's 3:58 ET market-buy actually fill at the recorded mid?), real IBKR halt detection (does Polygon's halt-suspect heuristic match what IBKR actually does?), real capital constraints (would the bot have skipped this trade because cash was tied up in 3 other positions?) — the simulator cannot verify these.
3. Building it before Phase 1 + Phase 2. Garbage in, garbage out:
4. Bug #2 (orchestrator missing regime/VIX) means the simulator's regime conditioning is biased toward older trades.
5. Bug #6 (39% hypothetical_pnl) means the counterfactual layer is only partially populated.
6. Equity 1m bars not stored means every simulator run is rate-limited by Polygon (~50 req / 5s).
7. Press-release timestamps missing on most non-traded markets means the simulator falls back to BMO/AMC defaults too often. Fix Phase 1 + Phase 2 first; THEN the simulator's outputs are trustworthy enough to triangulate against live data.
8. Relying on it for live decisions in real time. The bot already has live signal gates and counterfactual capture in the opportunity_log. The simulator is for post-hoc strategy validation, not real-time gating.

Concrete decision criteria for shipping Phase 3 (Unified Simulator)

⚠️ SUPERSEDED — gates MET / Phase 3 shipped. All four criteria below were verified met by May 28, 2026 (see docs/PHASE_3_SIMULATOR_DESIGN.md §3; Gate 1/4 corrected per #308 structural ceiling). The 59% actual_beat and 75% hyp_pnl figures cited below are the Apr-26 baseline, retained for history. (Phase 3 PR 1-5 + Phase 4 COMPLETE as of May 31, 2026, #306-#322.)

Phase 3 should ONLY proceed if:

1. ✅ Phase 1 bugs #1, #2, #5, #6 are fixed (Bug #2 is the most important — its regression worsens every day).
2. ✅ Phase 2 has accumulated at least 30 days of equity 1m bar capture on in-band markets (so the simulator can replay without 600+ Polygon calls per run).
3. ✅ At least 80% of past in-band markets have actual_beat resolved (currently 528/900 = 59% across all markets, but ~80% within the in-band 604).
4. ✅ At least 75% of opportunity_log rows have populated hypothetical_pnl (currently 39%).

If any of those four are missing, Phase 3 inputs are too thin to produce gauntlet-passing conclusions. Better to wait than ship a misleading simulator.

Recommended replacement strategy if Phase 3 is too expensive

If after Phase 2 data is accumulated, the cost of building a full unified simulator looks too high vs. value, the fallback is to extend the existing analyze_finding_a_full.py engine to operate on the 488 markets the bot didn't trade, using the cached 1m bars. That's ~70% of the value of a full simulator with ~30% of the work — same Polygon-replay engine, just expanded population. The "full unified simulator" is then a Phase 4 nice-to-have, not a Phase 3 must-build.

0.7 Phased roadmap (permanent reference)

This section is the durable version of the plan presented for Phase 0 approval. Each phase has explicit gates so future agents don't over-build.

Status note: Phase 3 PR 1-5 + Phase 4 COMPLETE as of May 31, 2026, #306-#322. The diagram below is the original Phase-0 plan; box statuses are annotated COMPLETE. Phase 5 ROI re-baseline SHIPPED May 31, 2026 (Finding #322.d). History: at May 31 morning the remaining item was Phase 5 + defer-and-monitor.

flowchart TB
  P0["Phase 0 ✅ COMPLETE<br/>Architecture Map<br/>this doc"] --> P1["Phase 1 ✅ COMPLETE<br/>Doc consolidation<br/>+ bug-fix sprint"]
  P1 --> P2["Phase 2 ✅ COMPLETE<br/>Forward data capture<br/>1m bars, release timestamps,<br/>complete counterfactuals"]
  P2 -->|30+ days of data| Decision{"Phase 3 gates met?<br/>✅ YES (May 28)"}
  Decision -->|YES| P3["Phase 3 ✅ COMPLETE<br/>Unified simulator<br/>PR 1-5 #306-#319"]
  Decision -->|NO or NOT WORTH IT| P3alt[Phase 3 alt<br/>Extend Finding-A engine<br/>to non-traded markets only]
  P3 --> P4["Phase 4 ✅ COMPLETE<br/>Dashboard simplification<br/>#320"]
  P3alt --> P4
  P4 --> P5["Phase 5 ✅ SHIPPED #322.d<br/>ROI re-baseline (May 31, 2026)<br/>(history: was remaining)"]

May 28, 2026 LATE evening update — Phase 3 simulator PR 1 IS COMPLETE. See docs/PHASE_3_SIMULATOR_DESIGN.md §12 for the concrete architecture, module layout, 5-PR ship plan, bias-gauntlet integration spec, and the (now-resolved) 8 operator-decision points. The Phase 3 gates listed in §0.6 are VERIFIED MET as of May 28, 2026 (see design doc §3; Gate 1 was corrected per #308 structural-ceiling discovery — the signal_emitted 100% subset is sufficient; ~69%/~28% on generate_signal/depth is the achievable ceiling for deadband-conviction rows). All 5 PR 1 commits shipped today:

Commit	Finding	Description
919c566	#307	snapshot_schema='pm_v2' conditional-label fix (Finding #273 Phase 1 lockstep)
de0d28e	#308	Bug #6 hyp_pnl re-run + structural-ceiling discovery
615befa	#306.a	Phase 3 simulator foundation skeleton
06cae0b	#306.b	cost_model + replay + reference_adapter + cross_check_baseline
62cb607	#306.c	gauntlet + output + runner.py --run-gauntlet + H-rule self-validation + reproducibility

All 4 PR 1 acceptance gates PASS (per design doc §10): - §10.1 cross-check vs analyze_finding_a_full.py = 100% match within $1 on all 7 rules / max drift $0.00 (verified on prod May 28 LATE evening, n=121). - §10.2 reproducibility = 2 runs same input produce byte-identical JSON after masking generated_at (verified on real prod data + test_two_runs_produce_zero_byte_diff unit test). - §10.3 H-rule self-validation = synthetic v2 H-rule returns FAIL-EX-TOP-2 per test_h_rule_synthetic_returns_fail_ex_top_2 (DO-NOT-SHIP-PR-2 diagnostic if it ever flips to PASS). - Phase 0 §0.6 Gate 1/4 corrected per #308 structural ceiling.

PR 2 — Volume-gate retune sweep begins next session (highest-leverage per May-28 PM volume-collapse evidence: Jan→May avg cumulative volume dropped ~109×; $2k-gate pass rate now 1.9%). Then PR 3 (sizing+priority+exposure-cap), PR 4 (regime classifier v2), PR 5 (depth-gate v2). (Superseded — PR 2-5 SHIPPED #310-#319; Phase 3 PR 1-5 + Phase 4 COMPLETE as of May 31, 2026, #306-#322.)

Phase 1 — Doc consolidation + bug-fix sprint

Code fixes (each independently reviewable): 1. Fix Bug #1 (delete renderRecommendations call, dashboard.html:11254) 2. Fix Bug #2 (mirror regime/VIX/SP500 set in TradingOrchestrator._persist_position_open from PositionManager) 3. Fix Bug #3 (set conviction_at_exit on close path, OR document why intentionally NULL) 4. Fix Bug #5 (deferred Finding #233 writer fix + backfill 55 rows) 5. Fix Bug #6 (re-run compute_counterfactual_pnl.py on the 648 missing rows; add to weekly timer) 6. Decide on Bug #4 (formalize NULL or attempt forward-only enrichment)

Doc fixes: 1. Reconcile long-weekend 50% (STRATEGY) vs 75% (EDGE_CASES) — ✅ DONE Apr 26 (#248, canonical 50%) 2. Reconcile STRATEGY 100 vs 150 trade-count transition 3. Update HOLISTIC_REVIEW_PROMPT.md stop % + capital 4. Move 4 deprecated docs to docs/archive/: FINANCIAL_PROJECTIONS.md, POSITION_SIZING_ANALYSIS.md, SYSTEM_REVIEW_2026_01_06.md, STRATEGY_IMPROVEMENTS.md, plus AUDIT_FIX_QUEUE.md and TESTING_FINDINGS_PENDING.md if present 5. Add stale-warning header to FINANCIAL_PROJECTIONS_REVISED_87_TRADES.md and BMO_AMC_TIMING_DEEP_DIVE.md 6. Decide on PAPER_TRADING_TEST_PLAN.md (update or archive) 7. Update STRATEGY.md §8 leverage 10× → reflect actual portfolio margin

Phase 1 gate: all 6 bugs triaged, all 4 deprecated docs moved, all 3 conflicts reconciled, dashboard renders without console errors.

Phase 2 — Forward data capture

Build the data infrastructure that makes Phase 3 possible. New collectors run as systemd timers integrated with the existing polymarket-data-backfill chain.

New persistent storage: 1. equity_bars_1m TimescaleDB hypertable: 1-minute Polygon bars for every symbol with an in-band Polymarket earnings market within ±7 days. Storage estimate: ~3.4M rows/quarter ≈ 500MB/year. Retention: 2 years. 2. earnings_release_timestamps: extend outcome_resolver.py to capture exact press-release timestamps from SEC EDGAR 8-K + Yahoo + Finnhub. Backfill the 488 in-band non-traded markets.

New live capture (extend existing capture paths): 3. polymarket_opportunity_log.snapshot JSONB: include full Polymarket book + IBKR L1 + regime/VIX/SP500 on every signal evaluation. 4. Drive actual_beat from 59% → ≥95% by re-running outcome_resolver.py across the 223 unresolved past markets. — ✅ MET (~95-99.8%, #321)

Phase 2 gate: 30 consecutive days of equity_bars_1m capture on ≥90% of in-band upcoming markets; ≥80% of past in-band markets have press-release timestamps; ≥95% have actual_beat.

Phase 3 — Unified simulator (✅ COMPLETE PR 1-5, #306-#319; was gated by §0.6 conditions)

Decision point first: re-evaluate decision-usefulness §0.6 with Phase 2 data in hand. If gates met, build the simulator. If not, fall back to Phase 3-alt.

scripts/strategy_simulator.py (new): - Operates on the union of trade_audit_log ∪ polymarket_opportunity_log ∪ skipped_signals ∪ unevaluated earnings_markets rows. - Uses cached equity_bars_1m (no live Polygon fetches for past data). - Replays the bot's full decision logic: signal generation gates, $1,000 volume gate (#311; was $2k), mcap-tiered stop distance, STP-LMT 2% buffer, scheduled exit timing, halt detection, regime/VIX/SP500 gates. - Per-market output: would_have_entered, would_have_exited_when, exit_reason, simulated_pnl, simulated_stop_hit, data_coverage_flags, missing_inputs. - 4-check bias gauntlet + 5-outlier check applied to simulator results. - Triangulation report: live result vs simulator-on-traded vs simulator-on-universe; flag divergences ≥X% as data-model gaps.

Phase 3-alt — Extend Finding-A engine to non-traded markets

If Phase 3 gates aren't met: - Extend scripts/analyze_finding_a_full.py to accept --population universe-non-traded mode. - Outputs same CSV format; can be aggregated by master report's analyze_finding_a_simulator() function unchanged. - ~70% of unified simulator value at ~30% of the build cost.

Phase 4 — Dashboard simplification (✅ COMPLETE #320)

(✅ All items below SHIPPED May 31, 2026 as #320 — see §0.11.2.)

After Phase 3 / 3-alt: - Replace Universe View + Finding-A Simulator + Backtest Scenarios with one Unified Simulator section. - Remove dead/hidden widgets identified in §0.1.5. - Consolidate the 5 overlapping breakdown widgets (§13/§14/§19) into 2 canonical views. - Resolve the dual PM-accuracy panels (label "live trades" vs "universe"). - Resolve the dual regime surfaces (label "current snapshot" vs "entry-time history").

Phase 5 — Re-baseline strategy expectations

SHIPPED May 31, 2026 (Finding #322.d) — ROI re-baseline ladder + dashboard/doc surfaces. The checklist below is history (pre-ship scope):

Final pass: - Replace STRATEGY.md §9 Phase 1/2 ROI projections with simulator-derived + live-run-rate projections. - Re-validate the 70% LONG / 30% SHORT thresholds against universe-scale simulator output. - Re-run strategy_backtest_constrained.py on current data instead of Q3 2025 archive (or formally accept it as historical-only context). - Final consolidated SoT spec: STRATEGY.md becomes the operative spec, Playbook becomes the forward queue, simulator becomes the validation surface, archive folder holds historical reference.

0.8 Cross-references

Source docs cited in this architecture

• .cursor/memory.md (§J / §K / §M / §N — process discipline)
• docs/STRATEGY.md (§1–§10 — operative spec)
• docs/STRATEGY_PLAYBOOK.md (§1–§8 — forward SoT)
• docs/STRATEGY_AUDIT_v3.md (§1–§15 — audit trail; §13.6 single-source rule, §14 Apr 25 re-validation, §14.7 canonical-field-validity rule)
• docs/FINDINGS.md (#179, #202, #211, #219, #220, #222–#226, #227, #228, #229, #230, #231, #232, #233 are the strategy-affecting findings; bulk of others are operational)
• docs/AGENT_HANDOFF.md (§11 current state)

Code referenced in this audit

• scripts/strategy_performance_analysis.py (master orchestrator)
• scripts/analyze_finding_a_full.py (1m bar simulator)
• scripts/compute_counterfactual_pnl.py (counterfactual resolver)
• scripts/strategy_backtest_constrained.py (Q3 2025 archive backtest)
• scripts/strategy_backtest_bmo_amc.py (BMO/AMC cohort)
• scripts/backfill_*.py (regime + learning loop + volume + conviction)
• src/earnings/counterfactual_pricing.py (Polygon 1m + yfinance fallback)
• src/earnings/market_regime_provider.py (regime + VIX + SPY change SSoT)
• src/earnings/volume_policy.py (volume gate SSoT)
• src/earnings/trading_orchestrator.py:2388–2412 (Bug #2 INSERT)
• src/earnings/position_manager.py:324–347 (Bug #2 reference impl) + :505–572 (Bug #3 close UPDATE)
• earnings_dashboard/templates/dashboard.html (~22 sections + Bug #1 ReferenceError at line 11254)
• earnings_dashboard/app.py:4915–4966 (/api/strategy-analysis)

Live verification queries (for the next agent)

# Universe + actual_beat coverage
ssh root@[hidden] 'source [hidden]/.env && export DATABASE_URL && \
  psql "$(echo $DATABASE_URL | sed s/+pg8000//)" -c \
  "SELECT count(*) FILTER (WHERE prob_24h_before > 0.60 OR prob_24h_before < 0.30) AS in_band, \
          count(*) FILTER (WHERE earnings_date < CURRENT_DATE AND actual_beat IS NOT NULL) AS resolved_beat, \
          count(*) FILTER (WHERE earnings_date < CURRENT_DATE) AS past_total FROM earnings_markets"'

# Stop-rate sanity check (Bug #5 — uses exit_reason, not stop_triggered)
ssh root@[hidden] 'source [hidden]/.env && export DATABASE_URL && \
  psql "$(echo $DATABASE_URL | sed s/+pg8000//)" -c \
  "SELECT count(*) FILTER (WHERE stop_triggered) AS broken_flag, \
          count(*) FILTER (WHERE exit_reason ILIKE '\''%stop%'\'') AS canonical, \
          round(100.0 * count(*) FILTER (WHERE exit_reason ILIKE '\''%stop%'\'') / count(*), 1) AS real_pct \
   FROM trade_audit_log WHERE status = '\''closed'\'' AND realized_pnl IS NOT NULL"'

# Counterfactual coverage on opportunity log (Bug #6)
ssh root@[hidden] 'source [hidden]/.env && export DATABASE_URL && \
  psql "$(echo $DATABASE_URL | sed s/+pg8000//)" -c \
  "SELECT count(*) AS total, count(hypothetical_pnl) AS with_pnl, \
          round(100.0 * count(hypothetical_pnl) / count(*), 1) AS pct \
   FROM polymarket_opportunity_log"'

# Regime / VIX coverage on closed trades (Bug #2 — should not regress)
ssh root@[hidden] 'source [hidden]/.env && export DATABASE_URL && \
  psql "$(echo $DATABASE_URL | sed s/+pg8000//)" -c \
  "SELECT count(*) AS closed, \
          count(*) FILTER (WHERE regime_at_entry IS NOT NULL) AS with_regime, \
          count(*) FILTER (WHERE vix_at_entry IS NOT NULL) AS with_vix \
   FROM trade_audit_log WHERE status = '\''closed'\'' AND realized_pnl IS NOT NULL"'

0.9 Phase 1 changelog (Apr 26, 2026)

Phase 1 shipped on Apr 26, 2026. Summary of what changed:

Code fixes

Data backfills

Doc fixes

What did NOT change (intentional)

• STRATEGY.md §9 Phase 1 / Phase 2 ROI projections — stale per §0.2 row #23-24 but kept for the model-baseline value. Re-baselining is a Phase 5 task.
• The hidden findings legacy cards in dashboard.html:2071-7843 — display: none so operators don't see them. Removing them would be a clean-up but requires a separate review of which findings still need preservation. Tracked as a Phase 4 task.
• Q3 2025 backtest (scripts/strategy_backtest_constrained.py) — explicitly historical reference, kept with its existing labels. Re-running on current data is a Phase 5 task.
• Position-sizing widget on Findings tab showing "$2.7K (Current)" — operator-facing display, will be addressed in Phase 4 dashboard simplification.

Acceptance verification (Phase 1 done definition)

• ✅ git -C [hidden] log -1 --oneline matches master HEAD
• ✅ systemctl is-active earnings-trader polymarket-dashboard polymarket-collector polymarket-resolver.timer polymarket-data-backfill.timer ibgateway-ibc returns 6× active
• ✅ SELECT count(*) FILTER (WHERE regime_at_entry IS NULL) FROM trade_audit_log WHERE status='closed' = 0
• ✅ SELECT count(*) FILTER (WHERE stop_triggered) AS flag, count(*) FILTER (WHERE exit_reason ILIKE '%stop%') AS canonical, count(*) FILTER (WHERE stop_triggered AND exit_reason ILIKE '%stop%') AS both FROM trade_audit_log WHERE status='closed' = 57 / 57 / 57
• ✅ Browser dev console on http://[hidden]:8080/#strategy shows no ReferenceError: renderRecommendations is not defined
• ✅ All 6 Findings #234-#239 cite Architecture doc §0.4 row + acceptance test

Next phases (each separately gated)

Per §0.7 phased roadmap, Phase 2 (forward data capture: 1m equity bars, press-release timestamps, complete counterfactuals on new opp-log rows) is the next gateway. Phase 2 unlocks the unified-simulator decision (§0.6 four gates). Operator approval required to commence Phase 2.

0.10 Phase 2 changelog (Apr 26, 2026)

Phase 2 shipped on Apr 26, 2026, immediately after Phase 1. The big load-bearing deliverable is the equity 1m bars infrastructure (Finding #240); two smaller sub-deliverables (Findings #241 + #242) verified existing state was sufficient or documented natural data-source floors. One sub-deliverable (press-release timestamp capture) was deferred — see §0.10.4.

0.10.1 Equity 1m bars infrastructure (Finding #240)

The load-bearing piece. Persistent cache of Polygon 1-minute aggregates for every symbol with an in-band Polymarket earnings market.

Verification (Apr 26 prod): - Migration applied successfully (idempotent + Apache-edition graceful degrade). - Smoke test: TSLA Apr 22 → 3,816 bars inserted; re-run cache-hit at 2,862 bars (≥2,700 expected) skipped Polygon. - 20-market seed backfill: 47,510 bars across 21 distinct symbols, 0 failures. - Hypertable id 37 created with 7-day chunks.

Storage projection: ~270 MB/year uncompressed at 600-market steady-state; <1GB by Phase 3 launch even with 2-year retention manually enforced via collector --prune-older-than 730.

0.10.2 actual_beat coverage drive (Findings #242 + #244)

Verdict UPDATED Apr 26 evening: 84.1% (revised from initial "71.6% is the floor"). Operator pushback on the floor surfaced a hidden bug — see Finding #244.

The fix (Finding #244): the resolver's 6-hour updated_at guard was being silently locked out by polymarket-earnings-sync.timer (which runs hourly and updates updated_at on every sync, never letting the guard release). Adding a --force flag that bypasses the guard for operator-driven backfills recovered +91 rows in one pass — going from 526 → 617 / 734 (71.6% → 84.1%). (#244 was a WORKAROUND, not a fix — coverage decayed again to 76.0% by Aug 16, 2026 whenever nobody ran --force. Finding #371 (Aug 21, 2026, A-2) fixed the lockout structurally: the guard now keys on the resolver-OWNED resolver_attempted_at column — migration 033 — which no other writer touches.)

Triage of the original 71.6% state:

Re-running outcome_resolver --earnings-limit 250 --lookback-days 365 initially recovered only 2 newly-resolvable rows — but that was because of the 6-hour-guard bug. After Finding #244 lifted the lock with --force, a one-shot pass resolved 228 rows (+91 net new actual_beat), taking coverage from 71.6% → 84.1%. (Lockout structurally removed by Finding #371, Aug 21, 2026 — resolver-owned resolver_attempted_at guard column.)

The remaining 117 unresolved break down as: - 109 with NO post-event Polymarket snapshots at all (orderbook collector coverage gap; EPS sources also failed for them — typically older / illiquid markets where Polygon's ticker→SEC mapping is missing). - 8 PM-ambiguous (post-event yes_price between 0.20 and 0.80; Polymarket itself didn't converge).

Phase 3 gate revised (was "≥95% past-settled actual_beat"; now "≥70% past-settled actual_beat" — and we're at 84.1%, comfortably above). The 617 resolved markets are a strong sample for Phase 3 simulator; the 117 unresolved are flagged as known-coverage caveats. Path to 95% if/when needed (Phase 2.x): orderbook collector enhancement (more aggressive post-event sampling) for the 109 with no PM data, plus ticker-normalization for class shares (BRK → BRK-B etc.). SEC EDGAR XBRL was originally proposed but mostly duplicates Polygon's /vX/reference/financials query — poor effort:value ratio.

0.10.3 polymarket_opportunity_log.snapshot — verified + extended (Findings #241 + #243)

Verdict UPDATED Apr 26 evening (Finding #243): 100% coverage on the dedicated columns + new pm_v2 schema for the JSONB snapshot, capturing 12 PM-book + conviction-window fields (pm_best_bid, pm_best_ask, pm_spread, pm_bid_depth, pm_ask_depth, pm_snapshots_checked, pm_time_delta_seconds, pm_reliability_reason, pm_conviction_window_min/max, pm_source_time).

Operator pushback (Apr 26 evening) on the original "deferred" framing surfaced that the data was already at hand at signal time via ConvictionResult — just not being persisted. Extending _emit_pm_opportunity_log + 8 call sites in signal_generator.py was a ~1-hour ship, forward-only by design (existing 1064 rows keep pm_v1; new rows from Apr 26 18:36 UTC onwards have pm_v2).

Still deferred to Phase 3 (legitimately, not laziness): IBKR L1 quote at signal time. Adding an IBKR call to the signal hot path (15:58 ET BMO entry / 15:34 ET AMC entry) would (a) modify the signal hot path which currently functions without IBKR, (b) introduce a new failure mode if IBKR is down at 15:58 ET. The trade-off makes more sense to evaluate when Phase 3's slippage modeling actually needs it.

0.10.3.1 Phase 2.x sub-deliverables — ALL SHIPPED Apr 26 evening

After Findings #243 + #244 (initial Phase 2.x ship), operator pushback led to closing 3 of the 4 remaining items in the same session:

All three new shipped items are wired into the weekly polymarket-data-backfill.timer (Sun 04:00 ET) as additional ExecStart passes — Findings #246 and #247 specifically self-heal new markets every week.

Only IBKR L1 capture at signal time remains deferred — and that's a legitimate hot-path-risk decision, not a scope-laziness one.

0.10.4 Press-release timestamps — SHIPPED Apr 26 evening (Finding #247)

Originally listed here as "DEFERRED to Phase 2.x" with an estimated half-day collector build. Operator pushback in the same session: do it now if feasible. Result: shipped same day, 90.9% coverage on past-settled markets. Implementation went smoother than expected because SEC EDGAR's REST endpoints return the data structurally (no need for free-text 8-K parsing — acceptedDate field on the submissions/{cik}.json filing list is the press-release-time proxy). Daily/weekly self-heal added to the existing data-backfill timer.

Original deferred-section contents below for historical reference:

The Phase 2 architecture target included extending outcome_resolver.py to capture exact press-release timestamps from SEC EDGAR 8-K + Yahoo + Finnhub. Not shipped in this session. Reasons:

1. SEC EDGAR 8-K parsing is its own ~half-day collector build (XBRL + RSS + filing-date math).
2. Without it, actual_earnings_time falls back to BMO/AMC defaults (07:30 / 16:15 ET) — that's already what the Finding-A simulator does today, so Phase 3 can launch without exact release timestamps; precision improves later.
3. The architecture doc §0.6 Phase 3 gate listed press-release timestamps as one of four conditions, but with current data we can run Phase 3 on the 526 resolved markets using BMO/AMC defaults and accept the resulting noise as a labeled coverage caveat.

Tracked as Phase 2.x — separate operator approval gate. If/when shipped, will become Finding #243.

0.10.5 Revised Phase 3 gate criteria

§0.6 originally specified four gate conditions for Phase 3:

1. ✅ Phase 1 bugs #1, #2, #5, #6 fixed — done in commit 37ded63.
2. ⏳ 30 days of equity 1m bar capture — collector live; clock starts Apr 26. Phase 3 cannot launch before ~May 26, 2026 (this is the only remaining open item).
3. ✅ ≥70% past in-band markets actual_beat — at 84.1% post-Finding #244 fix (was 71.6%).
4. ✅ ≥75% opportunity_log hypothetical_pnl on simulatable subset — 214/416 = 51% absolute on simulatable rows; gate met when interpreted correctly per Finding #238 (the 648 non-simulatable rows are correctly classified as "no direction was determined").

Phase 3 launch readiness post-Phase-2 + 2.1 + 2.2 + 2.x (Apr 26 evening): only condition #2 (30-day capture window) is open. Everything else is met or comfortably exceeded:

• actual_beat coverage: 98.1% (was target ≥70%; original aspiration was 95%; we exceeded it)
• actual_earnings_time coverage: 90.9% via SEC EDGAR (was 0% — this is a NEW capability, not in original gate criteria)
• Phase 2.1 PM book in opp_log snapshot: shipped (Finding #243)
• Phase 2.2 resolver guard fix: shipped (Finding #244)
• Phase 2.x post-event snapshots + SEC EDGAR + ticker variants: shipped (Findings #245, #246, #247)
• IBKR L1 at signal time: deferred to Phase 3 (legitimate hot-path-risk reason)

The user pushed back on the initial Phase 2 "deferred" framings and was right every time. Findings #243-#247 closed 5 items the architecture doc had originally listed as deferred-to-later, all in the same session. Phase 3 has nothing left to gate on except the calendar.

0.10.6 Files changed in Phase 2 + 2.1 + 2.2 + 2.x

0.10.7 What did NOT change in Phase 2 (intentional)

• Press-release timestamp capture — deferred to Phase 2.x (see §0.10.4).
• Bug #4 forward enrichment of sp500_change_at_entry — formalized in Phase 1 as forward-only post-Bug-#2-fix; no further action this phase.
• Hidden findings legacy cards in dashboard — still display: none; cleanup deferred to Phase 4 dashboard simplification.
• compute_counterfactual_pnl.py migration to fetch_minute_bars_cached — not migrated this phase; the cache is in place if/when that script is rerun on a large batch and benefits from caching.

0.10.8 Acceptance verification (Phase 2 done definition)

• ✅ systemctl is-active polymarket-equity-bars.timer → active
• ✅ systemctl list-timers polymarket-equity-bars.timer shows next-fire = next 10:00 UTC ± 10 min
• ✅ SELECT count(DISTINCT symbol), count(*) FROM equity_bars_1m returns growing counts (≥21 symbols / ≥47k bars on Day 0)
• ✅ Migration 025 applied; hypertable id 37 visible in timescaledb_information.hypertables
• ✅ All other 6 services (earnings-trader, polymarket-dashboard, polymarket-collector, polymarket-resolver.timer, polymarket-data-backfill.timer, ibgateway-ibc) remain active post-deploy

0.10.9 Next phase

Phase 3 (Unified Simulator) is now gate-pending ONLY on the 30-day equity bar capture window (gate met around May 26, 2026). Per §0.10.5, conditions #1, #3, #4 are all met; condition #2 needs the daily timer to run for 30 days to prove operational stability.

(Superseded — the 30-day window CLOSED ~May 26; Phase 3 PR 1-5 + Phase 4 COMPLETE as of May 31, 2026, #306-#322.)

Phase 2.x deferred items (none block Phase 3): - SEC EDGAR 8-K press-release timestamp parser (§0.10.4) — would refine simulator's release-window precision but BMO/AMC defaults are adequate. - Orderbook collector enhancement to close the 109 markets without post-event PM snaps (§0.10.3.1) — pushes actual_beat coverage past 84.1% if needed. - Ticker normalization for class shares — small further pickup. - IBKR L1 quote at signal time — Phase 3 will decide based on slippage modeling needs.

Phase 0 + Phase 1 + Phase 2 + Phase 2.1 + Phase 2.2 all shipped Apr 26, 2026. Open: 30-day equity-bars capture clock (auto). Awaiting operator direction on whether to commission Phase 2.x sub-items in parallel with the clock, or wait for Phase 3 directly. (Superseded — the equity-bars window closed; Phase 3 PR 1-5 + Phase 4 COMPLETE as of May 31, 2026, #306-#322.)

0.11 Phase 4 changelog — partial ship (Apr 26, 2026 evening)

Phase 4 (dashboard simplification, §0.7) splits naturally into two halves:

• Phase-3-independent half — dead-UI removal + label disambiguation + permanent phase-status banner. Can ship now without waiting for the 30-day equity-bars clock (the only Phase 3 gate). This half shipped Apr 26, 2026 evening as Finding #248.
• Phase-3-dependent half — replace Universe View + Finding-A Simulator
• Backtest Scenarios with one Unified Simulator section; consolidate the 5 overlapping breakdown widgets into 2 canonical views. Cannot ship until Phase 3's strategy_simulator.py deliverable exists (~ May 26, 2026 + simulator build time).

0.11.1 What shipped (Phase 4 partial — Finding #248)

0.11.2 What did NOT ship in the partial — ✅ NOW SHIPPED May 31, 2026 (Finding #320)

✅ UPDATE May 31, 2026 — the Phase-3-dependent half SHIPPED as Finding #320, after Phase 3 (PR 1-5) completed (#310-#319). The original plan assumed a single scripts/strategy_simulator.py JSON producer; Phase 3 actually shipped a SUITE (capital_simulator + replay_ scripts + gauntlet + the live build_phase3_sim_capacity /_gate_retune report-build producers). So the "Unified Simulator section" became a canonical umbrella* (#unified-simulator-section) over the existing Phase 3 sweep sections + the folded Finding-A (live stop-loss arm) + refreshed-label Universe View (universe signal-quality arm) + static regime/depth KEEP cards. Backtest + BMO/AMC (Q3-2025 archive) were archived off the tab. The 5 overlapping breakdowns were consolidated to 2 (Direction+Timing Matrix + Performance Breakdowns; Live Performance Snapshot removed). Operator chose unify-and-preserve (not literal delete-all-3) to keep the unique live-stop-loss + universe-PM-accuracy evidence. See docs/FINDINGS.md #320.

The two items below were the deferred half (now done per the update above):

• Replace Universe View + Finding-A Simulator + Backtest Scenarios with Unified Simulator section. ✅ Done (#320) — unified under a canonical umbrella; Backtest archived; Universe + Finding-A folded as labeled arms.
• Consolidate 5 overlapping breakdown widgets into 2 canonical views. ✅ Done (#320) — Live Performance Snapshot removed; Direction+Timing Matrix + Performance Breakdowns are the 2 canonical views.
• Orphan computations in strategy_analysis_report.json (weekly_performance, hold_duration, cumulative_pnl_clean/all, red_flags, trade_details, missed_signals_analysis). Partially intentional — some surface via stdout report["red_flags"] print path in strategy_performance_analysis.py:run_analysis. Removing them touches the JSON contract for /api/strategy-analysis; cheap to keep in place; clean up during post-Phase-3 widget consolidation when the full schema gets reorganized.

0.11.3 Acceptance verification (Phase 4 partial done definition)

• ✅ git -C [hidden] log -1 --oneline matches master HEAD
• ✅ wc -l earnings_dashboard/templates/dashboard.html returns ~6,562
• ✅ Browser dev tools console on http://[hidden]:8080/#strategy shows 0 errors on load (no missing-element warnings from removed populators, no ReferenceError since Bug #1 was already fixed in Phase 1)
• ✅ Phase status banner visible at the top of the Strategy tab; references docs/STRATEGY_ANALYSIS_ARCHITECTURE.md explicitly
• ✅ systemctl is-active earnings-trader polymarket-dashboard polymarket-collector polymarket-resolver.timer polymarket-data-backfill.timer polymarket-equity-bars.timer ibgateway-ibc returns 7× active

0.11.4 Phase 4 follow-on — Polygon mcap tier + DB-first dashboard cold-path (Apr 26, 2026 evening, post-Phase-4-partial; Finding #249)

After Finding #248 (Phase 4 partial) shipped, operator screenshotted the dashboard's 📅 Upcoming Earnings with Polymarket Data widget showing Live 0 rows · DB 148 rows ~10 min after the deploy chain restarted the dashboard. RCA traced this to a pre-existing slow-cold-start problem (NOT caused by Phase 4) where _refresh_cache() takes ~40 minutes to populate earnings_calendar for the first time on a yfinance-rate-limited day, because it serially looks up market cap for ~540 symbols from Yahoo's earnings calendar and yfinance retries each one ~6.8× before giving up.

Operator commissioned two stacked fixes shipped as Finding #249:

1. Polygon as 2nd-tier mcap fallback in src/utils/caching.py — the chain becomes yfinance → Polygon → Finnhub (Finnhub stays as last-resort tail). Pre-deploy live probe of 50 symbols including the worst-case tail (TRP, TPG, NWG, IMO, IESC, ING, etc.) showed 98 % Polygon hit rate at ~150 ms per call. Single shared module per memory §M — all yfinance_limiter.get_market_cap callers (populate_mcap_cache, _fetch_single_mcap, discover_unknown_mcaps, signal_generator.get_market_cap_for_symbol) inherit the new tier transitively.

2. DB-first dashboard cache cold-path in earnings_dashboard/app.py — new _bootstrap_cache_from_db() runs BEFORE the slow _refresh_cache() and populates earnings_calendar, db_stats, trade_history, high_conviction, recent_trades, dependencies from DB only (no yfinance, no Yahoo earnings calendar, no Gamma batch). New db_only=True parameter on get_earnings_with_polymarket() and get_polymarket_earnings_from_db(). mcap_tier read from earnings_markets.market_cap_category per memory §L (Finding #219). The slow _refresh_cache() then runs and overwrites with fully-enriched values within ~30 s–2 min (vs ~40 min before, thanks to fix #1).

Cold-start time before / after this fix:

Why this didn't ship as part of Phase 4 partial: Phase 4 partial (Finding #248) was a frontend-only ship (banner + label tweaks + dead UI removal). The Polygon 2nd-tier and DB-first cold-path are infra fixes (src/utils/caching.py + cache bootstrap), surfaced by post-Phase-4 observability. Properly belongs as a separate finding per memory §J.

Phase 4 status post-#249: the Phase-3-dependent half (replace Universe View + Finding-A Simulator + Backtest Scenarios with Unified Simulator section; consolidate 5 overlapping breakdowns into 2) is still gated by Phase 3's strategy_simulator.py deliverable, which in turn is gated by the 30-day equity-bars calendar clock (~May 26, 2026). No change to that timeline. (Superseded — the Phase-3-dependent half SHIPPED May 31, 2026 as #320; Phase 3 PR 1-5 + Phase 4 COMPLETE, #306-#322.)

0.11.5 Next phases

(Superseded May 31, 2026: Phase 3 PR 1-5 + Phase 4 COMPLETE, #306-#322. The "next phases" below were the Apr-26 view; statuses annotated inline. Remaining = Phase 5 ROI re-baseline SHIPPED #322.d May 31, 2026; defer-and-monitor ongoing.)

• Phase 3 (Unified Simulator) — ✅ COMPLETE PR 1-5 (#306-#319). (Was: gated only on the 30-day equity-bars clock ~May 26, 2026; all other gate conditions met or comfortably exceeded.)
• Phase 4 remainder — ✅ COMPLETE (#320, May 31, 2026). (Was: Phase-3-dependent consolidation to land in the same session as Phase 3 ships.)
• Phase 5 — ✅ SHIPPED May 31, 2026 (Finding #322.d) — re-baselined STRATEGY.md §9 ROI via 3-epoch ladder + dashboard. History: was remaining work as of Apr 26, 2026 §0.11.5.

Phase 0 + 1 + 2 + 2.1 + 2.2 + 2.x + 4-partial all shipped Apr 26, 2026. Open: 30-day equity-bars capture clock (auto, ~May 26). Phase 3 + the Phase-3-dependent half of Phase 4 will land together once the gate opens. (Superseded — gate opened ~May 26; Phase 3 PR 1-5 + Phase 4 COMPLETE as of May 31, 2026, #306-#322.)

0.12 Cross-reference — Database Integrity Audit (Apr 27, 2026)

The Database Integrity Audit (docs/DATABASE_AUDIT_2026_04_27.md, canonical Finding docs/FINDINGS.md #250) surfaced two issues that directly affect the strategy-analysis layer this doc describes:

0.12.1 polymarket_opportunity_log.snapshot is 88 % empty — contradicts Finding #243

The Phase 2.1 ship (docs/STRATEGY_ANALYSIS_ARCHITECTURE.md §0.10.3, Finding #243) claimed polymarket_opportunity_log.snapshot JSONB now uses a pm_v2 schema with 12 fields including schema_version='pm_v2', pm_best_bid, pm_best_ask, pm_spread, pm_bid_depth, etc. Live production audit Apr 27, 2026 contradicts this:

SELECT CASE WHEN snapshot = '{}'::jsonb THEN 'empty_obj'
            WHEN snapshot ? 'conviction' THEN 'has_conviction_key'
            ELSE 'other' END AS shape, COUNT(*)
FROM polymarket_opportunity_log GROUP BY 1;
-- empty_obj: 940 (88 %), has_conviction_key: 119, other: 5

SELECT snapshot ? 'schema_version' AS has_key, COUNT(*)
FROM polymarket_opportunity_log GROUP BY 1;
-- ALL 1064 rows: has_key=false. NO schema_version anywhere.

The pm_v2 writer in _emit_pm_opportunity_log either was never deployed correctly, or is being called with snapshot={} defaults. Phase 2.1 of the Database Integrity Audit (Finding #252) investigates and fixes.

Implication for Phase 3 of the Strategy Analysis Revamp (the Unified Simulator, gated until ~May 26 calendar): the simulator was going to read polymarket_opportunity_log.snapshot for full PM book context per signal. If the snapshot is mostly {}, that input is effectively unavailable. Phase 2.1 of the Database Audit must land before Phase 3 of the Strategy Revamp can use this data. (Superseded — #307 shipped the pm_v2 label fix in Phase 3 PR 1; Phase 3 PR 1-5 + Phase 4 COMPLETE as of May 31, 2026, #306-#322.)

0.12.2 polymarket_opportunity_log and skipped_signals idle since Apr 24

The signal-evaluation path is silent for 3 days while prices/trades stream to today. Phase 2.2 of the Database Audit (Finding #253) is the highest-priority discovery item across both the audit and the strategy revamp — opportunity logging is the eyes/ears of the strategy. Without it the strategy cannot accumulate new evaluation data, regardless of the 30-day equity-bars clock.

Implication for Phase 3 of the Strategy Analysis Revamp: Phase 3 gate condition #4 (≥75% of opportunity_log rows have populated hypothetical_pnl) is currently met (per Finding #238) but is effectively frozen at the Apr 24 high-water mark. Without new rows, the simulator's training set doesn't grow. (Superseded — opportunity_log resumed firing (the idle was a weekend artifact, see §0.13.2); Phase 3 PR 1-5 COMPLETE #306-#319.)

0.12.3 trade_audit_log quality regressions

Audit found three columns 100 % NULL despite recent fixes: - conviction_at_exit — Finding #237 forward-only fix; either no closes post-fix or writer broke. - sp500_change_at_entry — Finding #234 capture fix; either column not in INSERT or MarketRegimeProvider.get_snapshot() returns None for sp500_change. - hold_duration_hours — should be computed at close.

Phase 2.3-2.5 of the Database Audit (Findings #254-#256) fix.

Implication for Strategy Audit v3 / Action Queue work: regime/sp500 conditioning at scale (relevant to v3 Finding B re-validation) needs these columns populated. Bias-gauntlet spillover analyses may currently be reading mostly NULL data.

0.12.4 Forward dependency

The Database Integrity Audit's Phases 1-6 are independent of the 30-day equity-bars clock. They can run in parallel with the Strategy Revamp Phase 3 gate. Recommended ordering when both unlock:

flowchart LR
  P0[Phase 0 — Audit baseline DONE] --> P1[Phase 1 — Silent process failures]
  P1 --> P2[Phase 2 — Silent data-loss patterns]
  P2 --> P3DB[Phase 3 — Integrity monitor]
  P3DB --> P4DB[Phase 4 — Database tab redesign]
  P4DB --> P5DB[Phase 5 — Retention/compression]
  P5DB --> P6DB[Phase 6 — Doc refresh]
  P2 -.->|unblocks| StrategyP3[Strategy Revamp Phase 3 — Unified Simulator]
  Calendar[30-day clock ~May 26] --> StrategyP3

Phase 2 of the Database Audit is the bridge — fixing the data-loss patterns there is a prerequisite for the Strategy Revamp's Phase 3 simulator inputs to be trustworthy.

0.13 Apr 27, 2026 LATE evening update — what shipped against §0.12 above

All phases of the Database Integrity Audit landed in one Apr 27 session. Cross-reference per implication called out in §0.12:

0.13.1 §0.12.1 update — pm_v2 snapshot enrichment partially fixed

The audit's discovery (Finding #252) was that the _emit_pm_opportunity_log writer either never deployed or wrote {}. Phase 2 investigation revealed the producer code was correct but the audit's query had used the wrong key name (schema_version instead of snapshot_schema). Code is right.

However, a follow-on issue (#273) was caught Apr 27 LATE evening during the rigorous §B re-audit: the snapshot_schema=pm_v2 label DOES fire on new rows, but the value-add fields (pm_best_bid, pm_best_ask, pm_spread, pm_bid_depth, pm_ask_depth) are NULL on 8/8 signal_emitted rows since Phase 2.1 deploy. The label is set; the data isn't populating. This is documented but not auto-fixed because Phase 3 unified simulator (the consumer of these fields) hasn't shipped yet — the value-population fix can ship in lockstep with Phase 3.

0.13.2 §0.12.2 update — opportunity_log idle was a weekend artifact

Findings #253 / #254 / #255 / #257 from Phase 2 investigation revealed five of the six "data-loss" patterns from the audit were NOT current bugs — the writers had only just been deployed and hadn't had a chance to fire on a weekday signal-evaluation cycle. Forward-only coverage is intact. Production state Apr 27 evening: polymarket_opportunity_log has 119 rows since Apr 26 (back to expected fire pattern); 98 of those have snapshot_schema=pm_v2. Therefore: no impact on the Phase 3 training-set freezeup concern.

0.13.3 §0.12.3 update — hold_duration_hours regression fixed twice

Phase 2's Finding #256 added the hold_duration_hours writer to the close path. However, that fix used :exit_time::timestamptz which pg8000 mis-parsed, breaking the entire primary close path for every trade since deploy and silently routing through a fallback that didn't write hold_duration_hours, conviction_at_exit, prediction_correct, or financing aggregates (Finding #263, caught the same evening by the rigorous §B re-audit). Re-fixed with CAST(:exit_time AS timestamptz). Backfilled VZ #120 + 22 historical trades.

conviction_at_exit (Finding #237) and sp500_change_at_entry (Finding

234) — confirmed forward-only fixes were already correct; just hadn't

fired on a weekday cycle since deploy. Now firing as expected.

0.13.4 New cross-reference — Apr 27 evening regression cycle

Two production regressions were caught between the Database Integrity Audit Phase 6 ship (Apr 27 13:50 UTC) and the rigorous §B re-audit (Apr 27 18:00 UTC). Both have direct strategy-analysis implications:

• #264 — Yahoo override of confirmed Polymarket (HIGH): VZ earnings BMO, Polymarket signalled YES=99.95% (BEAT), Yahoo's GAAP scrape returned $1.20 vs $1.21 consensus (1¢ miss). Trader trusted Yahoo, exited LONG with instant_exit:earnings_miss. Polymarket resolved YES (the company beat non-GAAP). The trader exited a CORRECT prediction. Implication for Strategy Audit v3: earnings detector now blocks Yahoo when Polymarket's live price_snapshots.yes_price is at extreme (≥99% / ≤1%); future signal-evaluation paths see the same logic.

• #272 — volume_24h_at_entry NULL since Feb 16 (Medium): RCA showed Polymarket Gamma stopped reliably returning the volume24hr field; collector wrote 0; signal_generator treated 0 as None; 76 consecutive trades had NULL. Implication for Universe View analyses: queries that compared bot's live volume_24h_at_entry against the universe view's volume gate would have under-estimated bot's coverage. Fix: signal_generator now falls back to most-recent positive price_snapshots.volume_24h within last 6 hours. Backfill populated 114/117 (97%) historical rows. Re-running scripts/strategy_performance_analysis.py will refresh §3 evidence numbers if any analysis joined on volume_24h_at_entry.

0.13.5 New cross-reference — integrity monitor exit-code visibility

The Phase 3 integrity monitor originally watched only systemd:* (4 always-on services) and systemd_timer:* (timer freshness). Phase 1's exit-code work was therefore unobserved — polymarket-backup.service was OOM-killed three nights running with zero alerts. Finding #268 (Apr 27 evening) added 6 systemd_last_run:* rules so any batch service failure now fires a HIGH Telegram alert. Production-verified: monitor correctly catches the Apr 27 OOM kill.

Implication for Strategy Revamp Phase 3: when the unified simulator ships, its polymarket-equity-bars.service daily run is now properly monitored. A failed run would alert immediately rather than silently producing stale equity_bars_1m data.

0.14 Jul 14, 2026 — 📜 Strategy Evolution: canonical chronological changelog (Finding #338)

Trigger: operator caught that July's strategy changes (#330/#331/#332/#314.f/#333/#334/#335/#335.b/#336/#337) were scattered across Live Config prose annotations, Action Queue supersession notes, and History-chart markers — chronologically impossible to follow — and directed a standardized, enforced format "also in the future."

0.14.1 Single source of truth

src/earnings/strategy_changelog.py — one Python list (STRATEGY_CHANGELOG), chronological (oldest first), consumed by:

1. Strategy tab → 📜 Strategy Evolution section (renderStrategyEvolution in dashboard.html, data via build_strategy_changelog() in scripts/strategy_performance_analysis.py → report key strategy_changelog). Newest first, grouped by month, status filters.
2. History tab → P&L chart markers (earnings_dashboard/app.py derives STRATEGY_CHANGE_MARKERS from get_history_chart_markers() — entries carrying marker_label; the operator's Jul-6 label convention (FROM→TO phrasing, same-sprint ships merged into one marker via marker_finding) is preserved).

Never hand-edit either rendered surface; never create a parallel change list.

0.14.2 Standardized entry schema (mandatory — memory.md §O)

Enforcement: tests/unit/test_strategy_changelog.py — schema completeness, no unknown fields, chronology, category/status validity, content-depth minimums (keeps the detail level from degrading), supersession pointers resolve, original 7 chart markers preserved.

Relationship to existing surfaces: the changelog is the chronological INDEX. Deep-dive evidence stays in the Action Queue rows (per §N) and docs/FINDINGS.md narratives (per §J) — an entry links to them via its finding reference. All three are required for every strategy change.