§1 — Why this exists

An orchestrator running unattended waves against metered backends will eventually launch into an exhausted quota. That failure is expensive in a specific way: the wave's worktrees are already created, its nodes already fenced, and the work partially done — so the loss is not one call but a whole wave's setup plus whatever half-finished commits have to be judged. Holding before a wave costs nothing by comparison.

The mechanism is asymmetric across backends and the design must be honest about that rather than paper over it, because pretending to know headroom you cannot observe is worse than admitting ignorance.

So the contract is fail-safe in one direction only: unknown headroom never blocks a dispatch, and recorded exhaustion always does. Guessing exhaustion from silence would make the whole system refuse to work for the wrong reason.

Promotion now writes the backend as a first-class ledger field, and the reader walks record → agent → budget → member, recovering a legacy record from the normalised evidence its stream interpreter produced. Both previously-lost readings resolve to their producing backend (utilisation 1.02%, attribution: budget-evidence) with no committed record hand-edited; a delivery path naming a different harness does not change the answer; ambiguity stays unattributed and reports unattributed-ledger, distinct from nothing-recorded. The first attempt matched the manifest path and was right only by coincidence — it tracked the host's own runtime directory — which is why the fourth gate exists. 7 new tests, suite green at 1,698. Full record: §6 landed (commits 7c5f54d, 4593f96).

The reader matches a recorded budget block to a backend through the run record's agent block. A record promoted without one carries its headroom into durable storage and loses the only thing that makes it readable. Measured on this repository's own ledger: of seventeen records, six have no agent.backend, and both records carrying a genuinely known reading — utilisation 1.02%, resetting 2026-09-01 — are among them. Every real headroom signal the project has ever recorded is currently invisible to the mechanism built to read it.

The loss is provably caused by promotion rather than by absence. The same reading was attributed while its run was in flight, reported from the live pointer with a source and an observation time; a recovery pass then promoted those pointers, and the identical read now returns nothing for that backend. Durability cost the number its meaning.

This sits under the locked read-source decision, not beside it. That decision chose the ledger over a probe precisely because the ledger already holds what each backend emitted. If promotion can strip the attribution, the foundation of the free pre-flight is unsound, and no amount of correct threshold logic above it matters.

The failure mode is the one the fail-safe posture was built to prevent, arriving by another route. unknown must keep meaning "nothing was recorded". Here it means "something was recorded and could not be matched" — indistinguishable to every caller, and silently wrong in the direction that opens waves it should hold. A backend that publishes nothing and a backend whose signal was mislaid must not read the same.

§4 — Constraints

No provider name, concrete model identifier or account-specific figure enters reckon source, the schema or this plan's prose. Observed utilisation is user data recorded in a ledger, never a constant.

A hold is never silent and never destructive. It creates no worktree, cancels no ready node, and always reports. An orchestrator that cannot schedule its own resumption reports the reset time for a human instead — degraded, not broken.

Holds now live in crew.json beside the runs: one record per continuous window, opened by the command that decides to open a wave and closed with the measured wall-clock. A test hold closed at 137 s measured against a 600 s predicted reset — the gap is the point, since it is what shows whether a resumption fired late. Seven gates passed, including the one added mid-flight after the audit found a read-only tool writing history (ledger v1→v2 on a read; now v1→v1). Two runs, 783 s and 498 s of worker-time, 8 new tests, suite green at 1,668. Full record: §5 landed (commits 9bc21da, 49bc41c).

A hold leaves no trace. It creates no run, so nothing in the committed ledger records that a wave was held, on which backend, for how long, or whether the scheduled resumption fired — which loses the one measurement the mechanism generates: what holding actually costs in wall-clock, against what a burned wave would have cost. That figure cannot be reconstructed afterwards, so it has to be captured at the moment it is knowable.

A hold record, beside the run records rather than among them. A hold has no worktree, no commit, no gate and no worker-time, so writing it into the run list would feed empty measurements to the effort report that averages over it. A hold opens when a wave is held and closes when a later pre-flight finds that backend clear, carrying the measured wait.

Repeated pre-flights inside one window are one hold, not many. An orchestrator that checks every few minutes must not multiply records for the same window, or the count stops meaning "how often were we held" and starts meaning "how often did we look".

Closing is what makes it a measurement. An open hold records a decision; a closed one records a duration. The wait is measured against the wall clock rather than assumed from the reported reset, because the two differ whenever a resumption fires late — and the difference is exactly what tells a reader whether self-scheduled resumption is working.

/reckon-ship budget-aware-dispatch

/reckon-ship budget-aware-dispatch

/reckon-ship budget-aware-dispatch