CB-WP-0019-T05: what the meta budget is for, at 80/20

InnerLoop v1.7. The purpose is written first and the number follows from
it: most spend on the task at hand, some on control, review and
improving the process. make status prints it above the figure, because a
threshold with no stated purpose is what let this number be argued three
times.

Soft 20% over a trailing 5, and the self-test enforces that the ratio and
the window are a PAIR: META_SOFT_PCT == 100 / TRAILING_PASSES. One meta
pass among n at parity cost reads 1/n, so 80/20 is one pass in five at
normal cost -- a five-pass window. The same 20% over three would have
silently also demanded the meta pass be half-price, which makes meta work
rushed rather than rare. Moving the ratio without the window goes red.

The phase setting is declared, argued and expiring in gates.toml, and
reverts on review_by unless re-argued. Verified live at 35%. One with no
reason or no expiry is refused rather than honoured, because a threshold
anyone may move is not a threshold.

Measured: the last five passes read 7% against the new line.

InnerLoop.md crossed the 400-line limit three times while this was
written and was fixed structurally each time -- the arithmetic, the
cost-per-response basis and the two review case studies moved to
InnerLoopReference.md. The limit was not raised.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-03 18:35:05 +02:00
parent 07261b4444
commit cc8917a6fb
5 changed files with 235 additions and 37 deletions

View file

@ -227,3 +227,73 @@ So window 2 carries a falsifier: **if it produces no override at all, that
is evidence the rate went too far**, not evidence the mechanism is
healthy. A window that cannot fire cannot be evaluated, which is the exact
failure d10 had.
## Meta budget — why 20% goes with a five-pass window
*(CB-WP-0019 T05, 2026-08-03, at the maintainer's instruction: "the main
budget should be spent on the task at hand while some of the budget should
be spent on control, review and improvement… 80/20 to start with".)*
The ratio and the window are a pair. With one meta pass among `n` at the
same cost `P` as each product pass, the measured share is `P / (n·P)`, so:
| window | one meta pass at parity reads | what a 20% line then demands |
|---:|---:|---|
| 3 | 33% | the meta pass must cost **half** a product pass |
| 4 | 25% | ~80% of one |
| **5** | **20%** | **parity — one pass in five, normal cost** |
| 6 | 17% | 20% is slack |
So 80/20 over a **trailing 5** is the literal reading of the instruction:
one pass in five is meta, and it may cost what a pass costs. The same 20%
over a trailing 3 would silently also require it to be half-price, which
does not make meta work rarer — it makes it rushed, and this project's
meta passes are where its instruments get repaired.
**Why not simply keep 25% over three?** Because 25% over three is *"one in
four at three-quarters cost"*, which is a ratio nobody chose; it was
inherited from ADR-0006 without the window being considered alongside it.
Stating the pair is the correction.
**The phase setting.** `meta_phase` in `gates.toml` carries `pct`,
`reason`, and `review_by`. It exists because stage 0 and a stabilisation
phase do not deserve the same ratio — but it expires, because a threshold
anyone may move is not a threshold. The failure it guards against is the
one this project has refused four times: raising a limit to pass a breach
rather than fixing the breach.
## Loop work cashes out — the measured basis
*(ADR-0006 D4, moved out of `InnerLoop.md` by CB-WP-0019 T05 when that file
crossed the loadability limit. Limits get fixed structurally here.)*
Cost per response across five passes ran **0.123, 0.228, 0.362, 0.298,
0.123** dollars. The reading that survived the data is that **cost tracks
distance from a runnable check**: the passes that shipped a command were
cheap; the passes that argued about what a number means were not
(CB-EV-0007 §5).
**Refuted if** a prose-only meta pass lowers cost per response, or catches
a class no command could.
## Why review is adversarial execution, not re-derivation
*(Moved out of `InnerLoop.md` by CB-WP-0019 T05 at the loadability limit.
Two cases, three passes apart, with the same shape.)*
**v1.1, from CB-WP-0002 — the same-sample blind spot (SSB).** The dedup
invariant was verified on the main transcript by the survey (206/206
groups) and independently re-verified by the reviewer, who used the same
transcript. It is **false** in the 8-response `subagents/` tree neither
examined. Two independent checks, one blind spot, because both sampled the
same way. Only an assertion running over all the data at execution time
caught it.
**v1.4, from CB-WP-0005 — re-derivation is not enough.**
`evidence/CB-EV-0001` reported `AM-7 replay | met, 2,290×` for a clause
that asserts nothing: the hash reaches only a `println!`. The reviewer
found it by opening a test out of curiosity and said so; **no systematic
step pointed there.** Mutating it settled it in one command.
Both are verification steps that inherited the author's blindness, and
both fixes replace re-derivation with **adversarial execution**.