BFM-decomp/docs/calibration.md

# Endgame calibration — measured rates for P28/P29 sizing (Phase-27 T9)

> The roadmap (§6 risk register) makes the **member-adapt close-rate** THE swing number and holds
> P28/P29 yield projections until it's measured. This records what Phase-27 could measure directly and
> names honestly the one number that needs P28's `member_adapt` tool to pin down. All rates are
> byte-gate-grounded (G3/P9) — a "match" here means the whole-binary gate accepted it.

## Velocity (the flip-timing checkpoint input)

| | value | note |
|---|---|---|
| instr-weighted, Phase-26 close | 68.9% | committed baseline |
| instr-weighted, Phase-27 close | **67.0%** | a re-baselining DOWN, not a regression |
| game-code matches banked this phase | **~0** | Phase 27 was an INFRASTRUCTURE + FINDINGS phase |

The headline **dropped** because T7's disc-completeness audit added 4 SC07 overlays (~2.45 MB of mostly-
unmatched code) to the denominator — the prior 68.9% was measured over an incomplete disc. Raw match
velocity this phase was ~0 (no harvest ran), but the phase's product is leverage on FUTURE velocity: the
tool fixes (T2/T4/T6) and the pin-crash-wall dissolution (T5) unblock work the prior tooling hid. **For
the flip decision: do not read Phase-27 as ~0 progress/session — it is a denominator correction plus a
set of unblocking findings; the next harvest phase (P29) is where velocity resumes and should be
re-measured there.**

## The templatability swing (the number that decides P28/P29 yield)

> ### ⚠️ CORRECTED 2026-07-15 (Phase-28 T1) — the ≈0% row below was measuring a MISSING BUILD STEP.
>
> The Phase-27 row said `h_seq family ≈ 0%`, on the strength of `0x8017BEBC` banking **0 of 8**, and that
> number rewrote the endgame ("P29's arithmetic is (cores cracked) × (reach), NOT (families) × 120",
> `PhaseEnd_Phase27` Roadmap delta). **It is refuted.** The same family, same era, through the carve path
> its own exemplar required: **8 of 8 BANKED** (4 same-address + 4 cross-address; `make clean` +
> extract-all + `check-all` → **140/140 byte-identical**).
>
> **Root cause — the probe used a tool with no carve step.** `0x8017BEBC` is a **jr/switch** core. §47
> banked its exemplar as *"lazy isolation → carve (9-piece interleave) → splice → BYTE-IDENTICAL"* and
> stated the fix is *"×N template-safe"*. `family_sweep.hseq_sweep` stages C and gates — it has **no
> carve step**, so gcc's generated jump table is never placed at the sibling's address. The entire
> residual I byte-verified is **two words**: `lui $at,%hi(jtbl_801EC44C)` / `lw $v0,%lo(jtbl_801EC44C)($at)`
> (`classify_member` → **PURE, ndiff=2**, positions 343/345). `config/overlays.mk:112` carves
> `ov_SC01_000_jr_8017BEBC.o` for the exemplar; `:134` has no such entry for the member. The 0/8 measured
> the omitted carve, not the family. **`tools/jtbl_family_bank.py` exists to do exactly this per sibling
> and had never been run on this family.**
>
> **Compounding:** the family is one of only **3 of 163** with `has_mid_jr` — i.e. the roadmap generalized
> from n=1, on the least representative family in the population, using the wrong tool for its class. And
> the three Phase-26 exhaustion probes it corroborated (tiny-IMM 0/241, PURE 0/134, pinned 0/133) all
> **predate** `_carry_macros` (Phase-27 T5, `commit:0637`) — Phase 27's decision-log itself calls its re-probe
> "a **fourth** phantom exhaustion proof" while never re-running the first three. **R35: a 0% from a broken
> tool and a 0% from a working one are the same number and opposite facts.**

Propagation regimes, byte-measured (the whole-binary gate is the only entry here — G3/P9):

| regime | rate | evidence |
|---|---|---|
| **h_exact reach-N core** (byte-identical across N overlays) | **≈ ×N, near-100%** | §52 (Phase 26): 5 cracked cores → **670 banked instances** = ×134 each, mechanical |
| **h_seq family, jr/switch core, WITH the per-sibling carve** | **8/8 on a bounded probe** (n=1 family) | `0x8017BEBC` via `jtbl_family_bank.py --raw` (P28 T1): 4 same-addr + 4 cross-addr (`to_addr`), 140/140 clean-fleet |
| **h_seq family, jr/switch core, WITHOUT the carve** | 0/8 — **an artifact, not a rate** | the P27 T5 probe (`family_sweep`, no carve step). Do not cite this as templatability evidence. |
| **h_seq family, non-jr (PURE / IMM / MIXED)** | **UNMEASURED** | the three Phase-26 probes are pre-`_carry_macros` and were never re-run → P28 T3 |

**The honest state of the swing number.** The ≈0% doctrine has **no surviving post-fix evidence**. What
T1 establishes is narrow and real: a jr/switch family templates at 8/8 *when the carve its exemplar
required is actually performed*. What it does **not** establish is a general rate — n=1, and jr is by
construction the rarest class (3/163 families). **The general rate is exactly what P28 T3 measures**, over
the population that actually exists (from the T0-fixed map): **1,418 matched-exemplar families / 21,889
unmatched members** — PURE 17,024 (78%) · IMM 4,473 (20%) · **STRUCT 392 (1.8%)**.

**Note the roadmap's swing number is aimed at the wrong class.** It sizes P28/P29 on the *register-drift*
(STRUCT) close-rate — **1.8%** of the input. The mass is PURE+IMM (98%).

**The addressable pool (T0, from the fixed map).** 937,248 ins = **21.7% of all remaining weight** =
**7.16pp of fleet instr if it all banked**, all behind an already-matched exemplar:

| stratum | families | members | ins |
|---|---:|---:|---:|
| **SC07-only** (unmatched ONLY in the 4 P27 overlays; exemplar already byte-proven) | 1,255 | 6,268 | 230,612 |
| legacy PURE non-jr | 95 | 7,993 | 478,379 |
| legacy IMM (incl. `0x8017BEBC`: 115 members × 952 ins ≈ 109,480) | 36 | 6,644 | 212,707 |
| legacy MIXED | 30 | 968 | 10,462 |
| legacy PURE w/ jr | 2 | 16 | 5,088 |

This is a **prediction** (h_seq predicts; the gate decides). T3 gates it before P29 scales.

## The LEGACY h_seq rate — measured, CLASSIFIED (Phase-28 T3b, 2026-07-16)

The roadmap's actual swing number is the *legacy* h_seq rate (the SC07 pool T3-A measured turned out to
be h_exact + unwired, a different question). A bounded `family_sweep --hseq --chunk 1` over **6 legacy
PURE non-jr families** (smallest-nins first; `has_mid_jr` excluded per §53) gated:

| | count |
|---|---|
| **BANKED** (whole-binary) | **9** |
| **PLUMBING** (recoverable class) | 37 |
| **DIFF** (genuine gate byte-mismatch) | **274** |
| skipped (not-stub / pinned-exemplar) | 173 |

**~3% as-tooled (9 of 320 attempted).** *Unlike Phase 26, the failures are CLASSIFIED* — 274 genuine
gate-DIFF, not an unclassified 0%.

**But the DIFF is NOT structural variance, and this is the load-bearing nuance (R14/R35 on my own probe):**
the members are byte-level **PURE** (`classify_member` = PURE, reloc-only, 20/20 sampled), **genuine
h_seq** (all DIFF_BYTES vs the exemplar → `family_sweep` is the correct tool, not `dedup_extend`), and at
the **same vram**. A PURE family should template once its relocs are remapped. That 274 members do NOT
reproduce means the remapped exemplar body **fails to reproduce the member's bytes when recompiled** — i.e.
the residual is **recompilation divergence**, one of:
- **(a) an incomplete remap** — `symbol_map` not covering a symbol class these families use (the recurring
  jtbl/prefix bug: B2's 0/8, T4's 12 DIFFs — *both* turned out to be tooling this phase); or
- **(b) genuine TU-context regalloc divergence** — the same C compiling to different bytes in different
  overlay TUs (a real wall).

**These are the SAME two hypotheses B2 and the SC07 pool presented, and BOTH resolved to (a) tooling this
phase.** So the honest swing number is: **~3% as-tooled, ceiling UNKNOWN** — provisionally consistent with
"legacy h_seq largely doesn't mechanically template", but on a probe whose dominant failure mode is the
exact tooling-vs-wall ambiguity that keeps resolving to tooling. **P29 must run the disambiguating probe
before trusting 3%:** take one PURE DIFF member, diff its `family_sweep`-staged compiled bytes against the
target region-by-region — if the mismatch is at a reloc position, it's (a) incomplete remap (fixable); if
it's regalloc/schedule away from relocs, it's (b) a TU-context wall. Do NOT scale P29's "(cores)×(reach)"
arithmetic on 3% until that probe runs.

## The swing number RESOLVED — (a) TOOLING, an -O0 compile-flag artifact (Phase-29 Task 1, 2026-07-16)

The disambiguating probe RAN. **Verdict: the legacy-PURE-non-jr "~3%" is (a) TOOLING — dominated by an
`-O0` COMPILE-FLAG artifact — NOT a TU-context regalloc wall.** Built `tools/diff_regions.py` (the
deferred roadmap tool): remap the exemplar EXACTLY as `family_sweep --hseq` stages it, compile at the
EXEMPLAR's real optimization level (auto-detected from the Makefile -O0 rules), masked-diff vs the target,
classify each member (`O0-FLAG` / `TEMPLATES` / `PLUMBING-ISO` / `REGALLOC` / `NO-TARGET`).

**Root cause (byte-proven).** The two families supplying **~272 of the 274 DIFF** (`0x8013c964`,
`0x8013c938`) are **-O0 functions** — their exemplar lives in `ov_SC01_077_o0.c` (the Phase-19 -O0 cluster,
vram 0x8013B568..0x8013C98C, `21F0A003` frame-pointer prologue). `family_sweep --hseq` stages the remapped
draft into the member's CURRENT stub file, which compiles **-O2** (the Makefile -O0 rule covers ONLY
`ov_SC01_077_o0.o` / `boot.o` / the whale `_o0b` wildcard). An -O2 compile of an -O0 target can NEVER match
(a frameless ~4-ins leaf vs the 10-ins -O0 frame — `match_one`'s own `--o0` flag exists for exactly this).
Compiled at **-O0** the remapped C masked-MATCHes: `func_8013C964`@ov_SC01_000 → MATCH(10),
`func_8013C938` → MATCH(11); the -O2 compile the sweep used DIFFs(10/11).

**Distribution (106-member sample, 11 matched PURE-non-jr families, nins 2..133):**
`O0-FLAG 45 · NO-TARGET(already-banked) 29 · TEMPLATES(at exemplar opt) 17 · PLUMBING-ISO(type-lift) 15 ·
REGALLOC 0`. **ZERO genuine codegen walls.** Every failure mode is recoverable tooling: the -O0
compile-flag, already-banked, template-clean, or the §40a/§8d type-lift plumbing (a `match_one`-isolation
blind spot the real TU carries via `engine_types.h`; `family_sweep --no-preclassify` resolves it).

**Honest scope (§52b, R14/R35).** These are masked-MATCHes — a CANDIDATE, not a whole-binary bank. But the
fix is an INDEPENDENTLY byte-proven mechanism: the -O0 split (the whale banks ×134 via exactly this;
`ov_SC01_077_o0.c` banks byte-identical for THIS cluster in ov_SC01_077) + the §8d/§40a recovery (~20k
members banked so in Phase 25/26). **Whole-binary banking + the TRUE ceiling (larger families) are P29
Task 2a's gate — a prediction, gate-validated there.** Caveat carried: one cluster fn (`func_8013B7AC`,
%lo-fold) was called "overlay-local" in Phase 20 — Task 2a byte-gates EACH cluster member, never assumes
all 16 template.

**Consequence.** The "~3% as-tooled ceiling" is RETIRED (a tooling artifact — the THIRD "structural wall"
this endgame resolved to tooling, after B2 and SC07). P29's member track is NOT a low-ceiling per-member
grind; it is a **mechanical -O0 split rollout** (the deferred "-O0 ×134") + the type-lift sweep. The
~478k-ins legacy-PURE pool is back on the table. `member_adapt.py` (the (b)-wall delta engine) is NOT
needed for this pool. (Full run: `.run/probe29/`; tool: `tools/diff_regions.py`.)

## Cost / yield per tier (this session)

| tier | cost/fn | direct banks | durable yield |
|---|---|---|---|
| **Fable5** (discovery) | **~230k tok/fn** (238k/257k/270k/199k measured) | **0 / 5** | 3 oracle reclassifications + 2 cracked roots + **the pin-crash wall dissolved** + 4 new pin-free levers (cookbook §H) |
| cheap-Opus (apply idioms) | ~40–140k tok/fn (Phase-23/26 data) | the §52 wave: 5 cores | applies Fable5's idioms; the productive banking tier |
| permuter | CPU-only ($0) | regalloc/schedule drift | 7 all-time (all Phase-21); tail exhausted |
| local v3 | $0 | the ≤15-ins band | ~1,300 (Phase-23); off the hard tail |

**Fable5's ROI is NOT banks — it is idioms + wall-dissolutions** (the doctrine held perfectly this phase:
0 banks, but a propagation wall down and the codegen map extended). Budget Fable5 for *discovery*, then
harvest cheap-Opus against the distilled idioms. The perishable Fable5 window (~7/19) is spent on the
hard un-drafted cores + wall characterization, never on functions cheap-Opus can apply a known idiom to.

## The one number that needs P28 (honest gap)

**Member-adapt close-rate on REGISTER-DRIFT members** — the roadmap's headline swing — was NOT directly
measurable this phase: it needs P28's `member_adapt` tool (the exemplar→member delta engine) to try each
drift member and gate it. The bounding data: the refusal taxonomy's register-drift class is the *only*
adaptable one (§52 levers, ~⅓ pin-free crack rate per walled cluster), collision members filter out, and
pin-crash members are now UNBLOCKED (T5) rather than ×1-capped. **P28 opens by measuring this on a
byte-gated sample before P29 scales — exactly as the roadmap's risk register prescribes.**

## New lever this phase (not in the roadmap's projections)

The **pin-crash wall is dissolved** (T5 + `.run/giants/pin_crash_sigabrt.md`): the ~20 PINS-class stubs
in the manifest (and the 4 characterized pin families) were routed to the ×1 backlog as "cc1-crash /
intrinsic"; they now stage clean and are mechanically harvestable (byte-identity per sibling is the
gate's question, but the crash barrier is gone). This is un-projected P29 fuel — a whole reach-N class
the roadmap wrote off, back on the table.

---

## Stranded-draft integration recovery — measured 2026-07-24 (Phase 29 SESSION-16)

Population: the 36 stranded drafts of waves s14+s15 (`ov_SC07_006`, all reach-138), i.e. the drafts a
wave produced and the whole-binary gate rejected.

| question | measured |
|---|---|
| of the STRANDED residue, how many are byte-correct? | **24/36 MATCH, 11 near, 1 ERR (67%)** — the "~92%" is a whole-wave figure |
| blockers (they stack; cc1 shows only the first) | `self_decl_hdr` 21 · `callee_decl` 19 · `data_decl` 16 · `self_decl_tu` 5 · `local_type` 5 |
| per function, by MAX tier | T0 = 6 · T1 = 26 · not-an-integration-problem = 4 |
| yield of the EXISTING draft-side ladder | clears its own classes (callee 19→3, data 16→0) but converts **1/36** to compiling, which then DIFFs |
| yield of the per-overlay de-macroize (§65b) | 13/14 clean candidates rtu-MATCH; **14/14 attempted banks succeeded** |
| **total recovered** | **14 of 36 = 39%** (vs a pre-session projection of "all 22") |
| implied wave multiple | ~6/24 → ~20/24 = **~2.3×**, NOT the projected 3.7× |
| metric shape | distinct-code **+14 unique fns**; instr-weighted / fn-count ~flat (de-macroized banks are ×1) |
| R22 after each batch | **140/140**, three times — the T1 blast-radius claim holds |

Remaining, named (not silently dropped): 10 `match_one`-MATCH drafts still blocked by stacked classes
(3 `self_decl_tu` → `normalize_self_decls`; 3 `local_type`+`self_decl_hdr` → draft type uniquify then
de-macroize; 1 struct-tag redefinition; 1 callee-decl that rtu over-claimed; 2 with no static blocker
whose real cc1 error needs reading). 11 `near` drafts are NOT recovery fuel — they are unfinished
drafts and belong to the permuter/redraft track.

---

## Re-gating STORED drafts after a tool repair (P30 S39, measured)

**Question:** decision-log **A10** byte-proved the stored-draft backlog non-bankable by plain re-gate
(**0/958**, measured in T1). S38 then repaired several tools (the `jr_isolate_all`/`overlay_src_split`
alias-DEFINITION-deletion blindness, `harvest_verify._reload_corpus`). Does A10 still hold?

**Measured, three populations, all plain re-gate (`gate_stage --no-propagate`), no draft edits:**

| population | rate | note |
|---|---|---|
| **fresh wave-6 drafts** (S38-era, diagnosed "blocked on a class") | **4/6** | banked UNCHANGED — the class had already been freed by S38's own tool repairs |
| **stored pool, unbiased sample** (every 96th of 1,155 still-open) | **1/12** | the single hit was in `ov_SC06_030` — a REVERTED overlay |
| **the two REVERTED overlays' stored drafts** (targeted) | **3/17** | `ov_SC06_030` ×1, `ov_SC07_010` ×2 |

**Reading (P9, and the samples are small — treat as an order of magnitude, not a rate to plan on):**
A10 **broadly stands** for the general stored backlog: ~8% is not a harvest, and a 1,155-wide sweep
(1,155 whole-binary builds) is not justified by it. What IS real is that **a stored FAIL verdict is only
as current as the instrument that produced it** — drafts blocked by a defect that was later fixed bank
unchanged, and they concentrate where work was reverted or where a repair specifically applied.

**The rule (R35 applied to the backlog, not just to metrics):** after any tool repair, **re-gate the
drafts that defect plausibly touched** — targeted by the repair's blast radius, not the whole ledger.
Cheap, ~0 agent tokens, and it recovers work already paid for. Do NOT generalise a fresh-draft rate
(4/6) onto the stored pool (1/12); they are different populations.

**Ledger mechanics, for the record:** `.run/backlog.jsonl` is append-only; open-ness is re-derived from
`corpus.stubs` at every read (`load_best` drops now-banked rows per-binary, P9) and `make report` runs
`backlog.py prune`. So MEMBERSHIP is self-maintaining and currently clean (863 rows, 0 already-banked,
14 duplicate-addr; was 6,867 rows / 98% banked before Phase-29 compaction). What pruning does NOT
re-validate is the **verdict** on the rows it keeps — the `closeness` and residual class are as old as
the tooling that wrote them (Phase 28 found an outright corrupt one: `func_80178004` close=0 → 91).