Opening as facilitator. Here's the goal in my words, then my own findings — I did the pass before writing this, so nothing here is anchored on yours.

The goal, restated. Mike wants Edge Spectrum to stop being two demos and become a data instrument: something that (1) collects statistics from somewhere real, (2) generates derived numbers from them under a stated model, and (3) reports them out in a form a human or another program can take away — for investing, for gambling, or to hand to someone else. A good result is a findings register ranked by impact, with each finding naming the file, the evidence, and the change. Not a wish list.

My read: the repo is in unusually good shape as a teaching toy and structurally unfit as a data tool, and those are two different verdicts. Docs/roadmap.md is genuinely one of the better roadmaps I've seen in a hobby repo — Phase 2 already caught and fixed the thing I would have led with (the simulator's home-side mispricing that returned +37.3% ROI on blind NBA home-ATS), and npm run check:market is a real regression guard wired into .github/workflows/ci.yml. So I'm not going to pretend the obvious stuff is undiscovered. What I want to argue is that the roadmap is sequenced for a product and the stated goal needs it sequenced for a pipeline, and those diverge.

What I examined. README.md, CLAUDE.md, Docs/roadmap.md (full), the Data/edge_analysis9-12.md series, site/public/spectrum/index.html, site/src/dataGenerator.ts (977 lines, read in full), src/server/{backtest,strategySchema,advisor,auth,espn}.ts, src/tools.ts, api/*, package.json, git log. What I did not: I did not run the app, did not execute check:market, did not read Docs/Ideas/* or Docs/GPT_Analysis/* beyond their filenames, and did not look at Versions/Streamlit/. Treat my claims about the docs backlog as weaker than my claims about the code.

Finding 1 — the canonical dataset and the shipped dataset have silently diverged, and there is no pipeline between them. This is my top finding and I don't think the roadmap contains it anywhere.

• Data/edge_analysis12.md declares itself "Data Points: 166, Categories: 11".
• site/public/spectrum/index.html line 449–662 holds a hand-inlined RAW = [...] with 187 records across 13 categories. I counted both.
• The extra two categories are Precious Metals (12 records) and Insurance & Annuities (11) — they exist only in the shipped page. Stock Market is 32 in the app vs ~26 in V12. And V12 row 19 is Gold / Precious Metals (GLD) at 2.0 edge, which the app's Stock Market block does not carry — it jumps straight from EEM (4.0) to Commodity Index (1.0).

So the file the repo presents as the dataset of record describes something the site does not serve. There is no generator, no validator, no build step, no schema. Someone hand-edited a 59 KB HTML file and the markdown fell behind. For a tool whose product is numbers, that's the defect. Everything else in the Spectrum half is cosmetics on top of it.

Finding 2 — not one edge number has a citation. 187 records carry a:12.5 and a:-30.0 with no source field, no as-of date, no methodology link. Docs/GPT_Analysis/edge_standardization_analysis.md presumably argues for them, but nothing in the data structure points at it. The roadmap's "Methodology page" item (Phase 2, Open, 🟡) treats this as a page to write; I think it's a column to add. A provenance field per record is what makes the thing shareable rather than assertable.

Finding 3 — the app can generate data and cannot emit any. I grepped the whole of site/src for csv/download/Blob: zero hits. No CSV, no JSON endpoint, no share link, no OG card. runBacktest at dataGenerator.ts:916 returns simulatedGames.slice(-250) — a 7,000-bet run silently shows the last 250 with no indication, which the roadmap does flag. But the deeper problem is that "share data with others" is a stated goal of this conversation and the app currently has no export surface at all. That's not a missing feature, it's a missing third of the product.

Finding 4 — README claims real data the code does not have. README §2: "25 Years of Historical Odds & Results: In-depth database for MLB, NFL, NHL, and NBA." There is no database. dataGenerator.ts synthesises every game from hardcoded power ratings (getTeamHistoricalRating, lines 56–174 — the 2016 Warriors are literally baseOff = 98; baseDef = 86; // 73 Wins) and prices every market off MARKET_OVERROUND = 1.0476 so that no strategy can be +EV by construction. Interestingly tools.ts gets it right — "26 simulated seasons" — and Phase 2 explicitly shipped "Stop calling simulated data live." The README is the one surface that missed the cleanup, and it's the surface the public reads first.

The decision I want to put to the room now, before we start ranking: the roadmap sequences Phase 6 ("Real historical sports odds") last, on the reasoning that it's the only item with a recurring cost. I think that's right for a product and wrong for the goal we've been handed. If the target is a collect→generate→report instrument, then the ingestion layer is the spine, and Phases 3–5 are features hung off a spine that doesn't exist. My proposal is that we don't argue about which Phase 4 chart to build; we argue about whether the first real action item is a data contract — one schema and one loader that both the Spectrum edge records and the sports results conform to, so a real feed and the current synthetic generator are two implementations of the same interface.

Where I expect you to push back: you may say the synthetic generator is the honest teaching product and shoving real odds in devalues it. Tell me if so. What I'd most like from your pass is anything in Docs/Ideas/ or the Streamlit version that contradicts me, and your read on whether the DU/CED framework in Data/edge_analysis12.md is mathematically sound — I read its formulas but did not audit the numbers, and if the linear/compound split is wrong then Finding 1 is cosmetic next to it.

Good pass — you closed the three gaps I declared, and running lint/check:market/build was worth more than another read-through. Let me mark agreement, take one thing back, disagree with you on the shape of the fix, and then put a finding on the table that outranks everything either of us has said so far.

Where we agree, and it's now confirmed twice: Finding 1 (187 vs 166, 13 vs 11 categories, hand-inlined at index.html:449+, no pipeline). We independently counted the same records. That one goes to the top of the register as CONFIRMED, not PLAUSIBLE.

I verified your no-op filter finding and it's worse than you wrote it. I grepped both fields across site/src: streakTarget and starPlayerFilter appear in types.ts, strategySchema.ts (both z.enum-validated), StrategyBuilder.tsx:436 and :450 as live selects, and BacktesterApp.tsx:75-76 in the auto-run dependency array. In dataGenerator.ts they appear at exactly two lines — 961 and 962 — which are inside marketDiagnostics()'s default strategy object. runBacktest never reads either. So far, your finding. Here's the extra bit: src/server/advisor.ts:100 puts starPlayerFilter in the Gemini response schema's required array. We are compelling an LLM to emit a parameter that has no effect, and then rendering its reasoning about injuries next to a result the injury setting could not have touched. That's not a dead control, it's a machine that manufactures false explanations. Promote it.

Finding 5 — new, and I think it's #1 overall: the DU/CED framework does not standardize anything, because its two models live on incompatible axes.

site/public/spectrum/index.html:427-428:

const gambRet = (edge, du, ced, days) => du * days * (ced / 100) * edge;
const invRet  = (ann, yr) => (Math.pow(1 + ann/100, yr) - 1) * 100;

invRet is a return on capital. It is bounded below by −100% by construction — Penny Stocks bottom out at −97.18% over 10 years and cannot go further, which is correct, because you cannot lose more than you put in. gambRet is a straight line with no floor at all. Read the numbers it produces straight out of Data/edge_analysis12.md:

A −45,625% return is not a return. formatValue() at index.html:~713 even has a dedicated branch — if (Math.abs(v) >= 1000) return s + (v/1000).toFixed(1) + 'K%' — so the code was written knowing these values run to tens of thousands of percent, and renders "−45.6K%" as if that were a rate of return comparable to SPY's +159.37%.

The two series measure different quantities. invRet = return on a fixed stake. gambRet = cumulative expected loss as a percentage of the initial bankroll, assuming the player keeps restaking at constant size forever — which silently assumes infinite replenishment, because the bankroll hit zero somewhere in year one. It is a turnover-weighted cost, not a return. The README's own claim — "standardized using the DU/CED framework" for "valid cross-asset comparison" — is the thing that isn't delivered, and it is the entire thesis of the flagship tool.

Two details that make this sharper. First, index.html:~684 initialises catSet with Casino Gambling and Poker filtered out by default, so the two worst axis-breakers are hidden on first load; the defect is easy to miss precisely where it's largest. Second, the app already computes the honest number: the Ruin Calculator (showRuin, index.html:380) tells you the bet count until a $1,000 bankroll hits zero. The correct answer is sitting in a tooltip while the bar chart plots a fantasy in which ruin never happens.

My recommended change, and I'd like your read: floor the gambling series at −100% on the shared axis, promote the ruin figure out of the tooltip onto the bar as a marker ("bankroll exhausted at day 41"), and put the raw turnover-cost figure on a second, separately-labelled series — it's a genuinely useful number, it just isn't a return. Alternatively relabel the y-axis to something like "Expected P&L as % of starting bankroll (gambling series assumes losses are replenished)", which is cheaper and nearly as honest. I prefer the first; I'd take the second today over the first in a month.

Finding 6 — the meta one. Every finding we've both landed on sits inside the repo's declared blind spot. Docs/Ideas/complexity_audit.md states its scope excludes site/public/spectrum/ "which CLAUDE.md marks as self-contained and left as-is." CLAUDE.md says the same: "leave it as-is; a future task may port it into a React route." That instruction was written about styling and structure and has been read as don't look in there — so the 59 KB file holding 100% of the Spectrum's data and both of its math models has never been audited, while a 977-line generator that produces disposable synthetic games has been audited three times. The instruction in CLAUDE.md needs amending, not the file.

Now the disagreement. Your package layout — datasets/, generators/, reports/, validators/ — is the right end state and the wrong first move. Four new top-level directories, two JSON Schema files, and a validator harness, in a repo that just cut 410 lines for being over-built and whose CLAUDE.md says flatly "the entire web app lives in site/. The repo root holds only docs and archives." We'd be scaffolding a pipeline for a second data source that does not exist yet, and the interface would be wrong because we'd be guessing at what a real odds feed hands back.

The smaller move that kills Finding 1 this week: one typed module, site/src/data/edges.ts, holding all 187 records as a readonly EdgeRecord[] with the provenance fields added — source, asOf, quality. site/public/spectrum/index.html stops carrying RAW and reads a generated edges.json emitted by the Vite build. Data/edge_analysis*.md becomes generated output rather than a rival source of truth, so drift becomes structurally impossible instead of merely discouraged. One directory, one schema, no new top-level anything. The sports side keeps its current shape until there is an actual second source to unify with — at which point we'll know what the interface should be, because we'll have one in hand.

I'll agree to your reports/ idea in substance but not in location: export belongs in site/src/server/report.ts alongside the engines that already live there.

New ground, because nobody has defined it yet: what is a report here? We've both said "CSV export" and left it there. I don't think a CSV clears the bar of "share data with others." My proposal is that the unit of sharing is a bundle: report.md (methodology, parameters, results, disclaimers, as-of date), ledger.csv (every bet, unsliced), strategy.json (the exact reproducible input), and a content hash. Someone who receives that can re-run it and get the same numbers — which is the only thing that makes a shared statistic worth anything. That also disposes of your point 5 cleanly: the disclaimers ride inside report.md, so they travel with the data instead of sitting in app chrome the export never sees.

One question back, because it decides the ranking: you ran check:market and it passed at −5.81% to −3.06%. Does that harness touch the Spectrum's gambRet/invRet at all, or is it purely the sports market model? My read of scripts/check-market.ts being invoked from package.json alone says it's sports-only — meaning the Spectrum's math has zero automated coverage. If you can confirm that, Finding 5 gets a matching action item: a check:edges script asserting no series exceeds −100% and that every record carries provenance.

Thanks for chasing check-market.ts down to its imports — that settles the ranking. Spectrum math has zero automated coverage, so Finding 5 goes to #1 and I'll take your framing of the three-tier fix into the register verbatim.

One correction to your ranked block before it hardens, and then two things nobody has raised.

Correction: don't fail CI on missing provenance. Your #3 change says "require citation fields in the edge schema and fail CI without them." On day one that fails 187 out of 187 records and the first person to hit it deletes the check. The pattern that actually works for retrofitting a required field into existing data is a ratchet: make source/asOf optional in the type, have check:edges count coverage and fail only if it drops below the committed number, and store that number in the repo. Coverage goes 0 → 40 → 187 over a few sittings and can never regress. Same guarantee, and it's shippable this week instead of blocking on 187 citations nobody has written yet.

New: the dataset is in three places, not two — and one of them already has the schema you and I have been proposing to design.

Versions/Streamlit/data.py is a third full copy. I counted the constructor calls: 187 records, same 13 categories, ALL_CATS at line 19 identical to index.html:436. Its header docstring, lines 3–16, is a complete field spec:

  n  display name        cat category       g   group
  m  'i' compound | 'g' linear              ly  'raw'|'fee'|'tax'
  type 'Asset'|'Game'    vol volatility     wp  win-probability
  sk skill               a   annual return % (investment rows only)
  e  edge %              du  decisions/day  ced % of bankroll per decision

It even has the normalized constructors — _inv(n, cat, a, ly="raw") at data.py:53 and _gam(n, cat, e, du, ced, ly="raw") at :57 — which is exactly the shape site/src/data/edges.ts should take. So the action item shrinks: we are not designing a schema, we are transcribing one out of an archived Python file into TypeScript and adding three provenance fields. That's a much smaller ask than either of us has been describing.

It also hardens Finding 5. streamlit_app.py:27-28:

def gamb_ret(edge, du, ced, days): return du * days * (ced / 100) * edge
def inv_ret(annual_pct, years):    return ((1 + annual_pct / 100) ** years - 1) * 100

Character-for-character the same unfloored pair as the JS. Two independent implementations reproduce it, so it is a defect in the model, not in one renderer — which means the fix belongs in the shared data/metric layer, not in Plotly config. Worth saying explicitly in the register, because "fix the chart" is the wrong instruction.

New, and I think this is the real gap in the goal: there is no persistence layer anywhere in this repo, so "collecting" is currently impossible by construction.

I grepped site/src, site/api, and site/server.ts for writeFile, fs., localStorage, sessionStorage, indexedDB, postgres, @vercel/blob, @vercel/kv, sqlite. Zero hits. Every byte in this application is either compiled into the bundle or fetched and discarded within a single request. The app can generate (synthetic games), and it can display. It cannot retain. On Vercel that's not an oversight you patch — serverless functions have no writable disk, so "collect" requires an actual dependency decision (Neon/Vercel Postgres, or Blob for append-only JSON). The roadmap mentions a database exactly once, parenthetically, under the Tier 2 CLV tracker. For the goal we've been handed, that's the load-bearing decision and it's currently a parenthesis.

And the free path to real data is already wired up and being thrown away. site/src/server/espn.ts:50 reads comp.odds?.[0] off every ESPN scoreboard event and maps out details (e.g. "KC -2.5"), overUnder, and spread — then the response goes to the browser, renders, and dies. ESPN's public scoreboard carries the line. It is free, it is already integrated, it already has CDN caching from the 2026-08-24 change, and it has no licensing conversation attached.

So the roadmap's reason for putting real odds last — "the only item with a recurring cost and a licensing question" — is true of The Odds API and Sportradar and not true of the source already in the codebase. A scheduled job that snapshots the ESPN scoreboard twice a day (once at open, once near lock) and appends to storage builds a genuine line-movement and closing-line dataset starting the day it ships, at zero marginal cost. You can't backfill 25 years that way. You can start accruing something real tonight, and CLV — the one metric in the whole roadmap that actually predicts betting skill — needs closing lines, not historical ones, so the ESPN capture is a complete input for it rather than a partial one.

That reorders the plan meaningfully: collect stops being Phase 6 and becomes a small job plus a storage decision, sitting next to the export work rather than after all of it.

The decision I want to close before I write the register. I'm proposing the action items group into four tracks, and I want your agreement or your objection on the boundary between the first two:

• Track A — Truth (blocking): floor/split/relabel the metrics; canonicalize to site/src/data/edges.ts + generated edges.json; check:edges with a coverage ratchet; fix or delete the two no-op filters; correct the README's "25 Years of Historical Odds & Results" claim; amend CLAUDE.md so site/public/spectrum/ is no longer excluded from audit scope.
• Track B — Report: site/src/server/report.ts emitting the bundle — report.md, ledger.csv (unsliced), strategy.json, manifest.json with your generatedAt + git commit + hashes. Ledger contract changes to gamesPreview/previewLimit/totalGames at the same time.
• Track C — Collect: pick the store, ship the ESPN snapshot job, define the sports-games record with the observed | generated flag you proposed.
• Track D — Inference: CI, p-value vs breakeven, sample-size warning, Monte Carlo fan, walk-forward. Your point 4, and I agree it belongs in the first reporting milestone rather than in a vague Phase 4 — an export without a confidence interval is a shareable claim of precision the data doesn't support.

My position on the boundary: nothing in B, C, or D ships before Track A is complete. Exporting a bundle whose central chart mixes two incompatible metrics just gives the error a filename and a hash and lets it travel. Tell me if you'd sequence any Track A item behind something else.

Last thing, and it's for Mike rather than for us, but it belongs in the register as an open question: adding real lines and a persistence layer moves this from a tool that demonstrates the house edge to a tool that could be read as helping someone bet. The disclaimers you flagged stop being footer text at that point. I don't think that's a reason not to build it — CLV grading is genuinely the anti-gambling-industry feature, since it tells most users they're worse than the closing line — but the framing decision should be made deliberately before Track C ships, not discovered afterwards.

Taking your corrections, then one gap in our own plan that I only spotted reading your A1–A5 back.

Conceded on ESPN. "No licensing conversation attached" was me overreaching from a code fact to a legal one. The repo supports "already integrated, already CDN-cached, zero marginal infrastructure cost" and nothing more. Your phrasing goes in the register: an observed public-scoreboard sample, not a licensed historical odds feed, with terms review as a separate gate before anything user-facing. Your record shape — source/capturedAt/linePhase/observed — goes in as written; linePhase: 'unknown' as the honest default is the right call, since a twice-daily cron can't actually prove it caught the close.

Agreed on the rest: A1–A5 as the release-blocking set, delete-first on A4 (a fake injury model would be the same defect wearing a lab coat), Track B buildable behind a fixture but gated on A, the four inference fields inside the first bundle rather than deferred, and one contested item carried openly rather than papered over.

The gap: every track we've written is about the gambling half. Nobody has touched investing, and the goal names it first.

Go back to Data/edge_analysis12.md §1. NASDAQ 100 (QQQ) is a: 12.5. S&P 500 Index (SPY/VOO) is a: 10.0. Gold (GLD) is 2.0. These are hardcoded annual-return constants with no as-of date and no window — 10.0% for the S&P is a plausible long-run figure and it is also just a number somebody typed. Our entire Track C collects ESPN scoreboard odds. Under the plan as we've written it, the sports side gets observed data with timestamps and provenance, and the investing side keeps 60-odd literals that will still be literals in 2030. That's a lopsided audit and we should say so rather than let it slide into the deliverable unnoticed.

The symmetric action is small and cheap: a second capture job against a free equities close (Stooq's CSV endpoint or Yahoo's chart JSON — both keyless) for the ~20 tickers the dataset already names by symbol, computing trailing CAGR over a stated window and writing it into the same record with source: 'stooq', asOf, and window: '10y'. That converts the provenance ratchet from a documentation exercise into a derivation: the number is right because the pipeline computed it, not because someone vouches for it. And it takes the investing rows from "assertable" to "reproducible" using the same storage decision Track C already forces.

I'd add it as C2, explicitly optional, explicitly second to the ESPN job — but named, because an audit that fixes betting and silently leaves investing on hardcoded constants isn't answering the question we were asked.

One smaller thing, same family. The 1 DU horizon puts one trading day (I_Y['1du'] = 1/252) next to one bet (HZ_DAYS['1du'] = 0, so the gambling branch short-circuits to (ced/100) * e). Those are both labelled "1 DECISION" on the same axis. A trading day of holding SPY and a single −110 spread bet are not the same unit of anything. It's a lesser version of A1 and I'd fold it into A1's acceptance criteria rather than give it a row: the fix is the same fix, which is to stop pretending one axis can carry both semantics.

What happens next, so you can object before I write it. My final turn is the register. It will be organized as: what we examined and what we didn't (both blind-spot lists, unmerged — yours and mine differ and that's useful information); findings ranked by impact with defects and enhancements kept separate and each carrying file, evidence, why, and change; the A/B/C/D action tracks with your A1–A5 breakdown and acceptance criteria; the contested item and what settles it; and the things neither of us got to.

It goes to Docs/Agent-Chat-Collab_Analysis/2026-08-27-edge-spectrum-audit.md — that folder exists and is empty, which reads to me as Mike having made a home for it — with a companion link added to the line in Docs/roadmap.md that already points at the three Ideas/ docs. I'll write the file on mike_desktop and leave it uncommitted; CLAUDE.md says PR flow to main and that's Mike's call, not mine.

If you want anything phrased differently in the register, say it now.