Hypothesis Accounting Reconciliation — 2026-07-25

Why this exists

The experiment ledger (bot/runs/experiments.db, scans table) has counted scan hypotheses only since it was created on 2026-07-23. Several preregistrations (execution-level tests, not Edge Lab scans) also declared and spent hypotheses against the Research Program §3 budget ("2,000 hypotheses, project lifetime, tracked cumulatively in the experiment ledger") — but those counts lived only in prereg prose and CLAUDE.md status entries, never as ledger rows. The two bookkeeping systems drifted apart. The drift was first visible on 2026-07-25: streak_follow_btc_v1 (registered 2026-07-24) declared "cumulative 133 → 137 of 2,000," but the very next scan (universality-solusdt) continued the ledger's running total from 133, not 137 — a 4-count gap. This document traces the full drift from the beginning, not just that one gap, and fixes it.

Rule going forward (adopted here, see bottom): every future prereg's registered hypotheses get a ledger row at registration time, kind-equivalent tag split = 'research (execution prereg)', so the ledger is the single source of truth. No more parallel prose counts.

Method

1. Read every file in bot/preregistrations/*.md, grepped for "hypothes", and read the surrounding sections in full to extract each file's declared hypothesis count (if any) and any claimed cumulative.
2. Read every row of bot/runs/experiments.db → scans table in id order.
3. Established that zero existing ledger rows correspond to a prereg execution test — every existing row (ids 2–17) is an Edge Lab layer-3 scan config (displacement-event-scan, b4-fit, level-reaction, h4-ignition, rhythm, session-structure, upstreak-eth, three universality-*, two streak-regime-*). This confirms the task's premise directly: the ledger is scan-only.
4. Rebuilt the true chronological sequence of all hypothesis-spending events (scans and prereg-registered execution hypothesis sets) using each prereg's own "Date registered" line and each ledger row's date column, using internal cross-references between documents to order same-day events (e.g. expansion-v2-costfix explicitly cites the Donchian run's H1 result as already-measured, so Donchian precedes it same day; disp_follow_btc_v1 cites 2026-07-23-displacement-event-scan.md as its evidence basis, so the scan precedes it same day).

Per-document findings (every hypothesis-declaring prereg)

Total prereg-execution hypotheses that never reached the ledger: 1 + 3 + 3 + 6 + 4 + 4 + 4 = 25.

The true chronological sequence (scans + prereg executions, merged)

This table is the authoritative cumulative count. Ledger id is shown for scan rows (unchanged, pre-existing); backfilled prereg rows are new ledger ids 18–24 (added below) shown as such.

(disp-follow-btc-v1-validation.md and streak-follow-eth-REFUSED.md are omitted from this table — the first spends a Validation look, not a research hypothesis; the second spends nothing, by design.)

Where ledger and prose diverged, and why

• The ledger's own internal "base of 10" before its first row (id 2, dated 2026-07-23) is itself wrong, and reveals how the drift started. The five prereg executions before the ledger was born sum to 1 + 3 + 3 + 6 + 4 = 17 (Donchian → expansion-v2-costfix → fable-mentor-internal-xauusd → mentor-btc-v1 → fable-mentor-internal-btc), but the ledger's first row implies a starting base of only 10 (16 − 6). That 10 matches exactly mentor-btc-v1 (6) + fable-mentor-internal-btc (4) — i.e. whoever seeded the ledger on 2026-07-23 carried forward only the two most recent prereg executions and dropped the three from 2026-07-21 (Donchian, expansion-v2-costfix, fable-mentor-internal-xauusd = 7 hypotheses) entirely.
• From then on, every subsequent prereg execution repeated the same failure mode: each one (disp-follow-btc-v1, streak-follow-btc-v1) computed its own "cumulative" by reading the ledger's current (already-wrong, scan-only) total and adding its own count in prose — but never wrote that sum back as a ledger row. The next scan run then read the ledger's stored total directly (correctly, for scans) and continued from there, silently dropping the prereg's hypotheses a second time.
• mentor-btc-v1.md flagged its own gap explicitly at registration: "Experiment-ledger row to be written with the result (ledger table pending — recorded here and in Helm #33 until it lands)." It never landed — this reconciliation is that backfill, 17 days late in ledger time (same-day in project time).
• The 4-count discrepancy noticed during the universality sweep (declaration assumed 137, ledger said 133) is streak-follow-btc-v1's 4 hypotheses, which the ledger dropped in exactly the pattern above. It is real, it was one instance of a five-instance pattern, and it is now fixed for all five.

The correct current total

• Ledger's stored max(cumulative_hypotheses) before this reconciliation: 223 (scan-only running total, id 17).
• Ledger's raw sum(hypotheses) before this reconciliation: 213 (five fewer scan rows' worth of double-counting is not present — 213 vs 223 differ because the stored cumulative column started from the wrong base of 10, not because of duplicate rows; 213 + 10 = 223 confirms internal consistency of the scan-only chain).
• Missing prereg-execution hypotheses: 25 (1+3+3+6+4+4+4, enumerated above).
• CORRECT TRUE TOTAL: 213 + 25 = 238 hypotheses spent, of the 2,000-hypothesis project-lifetime budget, as of 2026-07-25.
• Confirmed post-backfill: select sum(hypotheses) from scans on the ledger now returns 238 directly (see Backfill section below) — no external arithmetic is needed to get the right number from the database from this point forward.

Budget remaining: 2,000 − 238 = 1,762.

Backfill performed

Seven new rows were added to bot/runs/experiments.db → scans, one per prereg whose hypotheses were registered but never logged, using split = 'research (execution prereg)', conditions = 0, and a short verdict quoted/summarized from each prereg's own Result section. No existing row (ids 2–17) was modified, deleted, or renumbered.

Post-backfill verification:

sqlite> select sum(hypotheses) from scans;
238
sqlite> select count(*) from scans;
23   -- 16 original + 7 backfilled

Important caveat on the cumulative_hypotheses column: existing rows (ids 2–17) keep their original stored values (16, 22, 28, …, 223) unchanged, and those are scan-only running totals — not the true budget total, and not comparable across the backfill boundary. The 7 new rows (ids 18, 19, 20, 21, 22, 23, 24) store the true reconstructed cumulative at their point in the chronological sequence (1, 4, 7, 13, 17, 51, 148 respectively — see the chronological table above for the full merged sequence with every scan interleaved). The table in this document, not any single SQL query against the raw cumulative_hypotheses column, is the authoritative record of the running total. A future reader who wants "the total spent as of date X" should either consult this document's chronological table or run sum(hypotheses) where date <= X, never max(cumulative_hypotheses).

Going-forward rule (adopted, effective immediately)

Every future prereg's registered hypotheses get a ledger row at registration time:

• date = the prereg's "Date registered."
• config = the prereg's filename (e.g. 2026-07-26-some-new-test.md).
• split = 'research (execution prereg)' (or 'validation (execution prereg)' if it's a Validation-split look — though Validation looks are governed by the separate 10-look budget, not the 2,000-hypothesis budget, and should still get a row for full traceability, with hypotheses = 0 against this budget if the file declares none against it).
• conditions = 0 (no parameter grid dimension applies to an execution prereg the way it does to a scan).
• hypotheses = N, taken from the prereg's own "Registered hypotheses" count at registration time — before the result is known.
• cumulative_hypotheses = the true running total (sum(hypotheses) over all rows with date <= this row's date, in true chronological order — i.e. just query the ledger, it is now self-consistent going forward from this reconciliation).
• verdict = filled in once the result lands (short summary), same as scan rows.

This makes the ledger the single source of truth — no prereg needs to (or should) compute and quote its own "cumulative N of 2,000" in prose ever again; it should read that number from the ledger after its row is inserted, and the row should be inserted at registration, before the run executes, exactly like a scan row is inserted at declaration time.

Scope notes / things intentionally NOT touched

• registry.db was not read or modified — out of scope per task instruction.
• No existing scans row (ids 2–17) was modified or deleted.
• No git commit was made.
• disp-follow-btc-v1-validation.md and streak-follow-eth-REFUSED.md were deliberately excluded from the hypothesis backfill (0 hypotheses against the 2,000 budget each, for the reasons given above) — this is a substantive finding of the reconciliation, not an omission.