Conserved-State Authority, Built

R-12, Conserved-State Constraints, named a gap and converged on a direction for closing it without naming that direction settled. It also named, precisely, what a vertical slice would have to prove before anyone should trust the direction rather than merely find it plausible. This entry is that vertical slice, reported the same way R-12 reasoned about it: what was actually verified, not what was intended.

1. What was built

A real database, real concurrent transactions — not simulated, not mocked. defineLedger, reserve, settle and release against a ledger and a reservations table; a real HTTP surface (GET the ledger state, POST reserve, settle, release); and an SDK composing those calls with the existing, unmodified, free can().

can() itself was never touched. That is the property R-12 insisted on throughout — the state layer sits beside the evaluator, not inside it — and it held under implementation, not just under design: consumed_before reaches can() as an ordinary caller-supplied fact, and reserve() is where the actual arithmetic and the actual authorization check happen.

2. R-12's own checklist, checked

Section 8 of R-12 named exactly what a vertical slice would have to prove. Taken item by item, against what was actually verified:

• Concurrent reservations cannot overspend — verified directly: 20 genuinely concurrent reserve() calls racing a ledger with room for exactly 10 settle at exactly the limit, never over, never short.
• Repeated can() calls consume nothing — true structurally, not just by test: can() itself was never touched by this work. State changes only inside reserve()/settle()/release(), never at evaluation time.
• Reservations expire, and failed execution releases capacity — verified, including the case where a hold has expired but nothing has swept it yet; the next operation to touch that ledger reclaims it before deciding anything else, rather than assuming a background job already ran.
• Successful execution settles — verified over both an internal call and a real HTTP round trip through the deployed API and SDK, not only at the module boundary.
• A reservation is bound to the exact decision that created it — verified: reserve() loads the real authorization decision itself and derives its cryptographic binding from that record, rather than trusting a value the caller supplies. A decision for the wrong artifact, one that was not actually authorized, or one already spent against a different reservation are all rejected.
• The transcript reproduces the original can() decision — including the honest, harder case: a caller can misstate the running total when calling can() and still receive a real, permanently-recorded authorized answer, because can() cannot verify that number without losing its statelessness. But settling that decision cannot: it checks the figure the decision actually recorded against the ledger's real number and refuses a mismatch, whichever side caused it.
• Offline verification correctly reports that it cannot establish current conserved state — not yet built. The rail-3 problem R-12 §4 named stands exactly as described there.

Six of seven, verified against real concurrent load rather than assumed from the design. The seventh isn't a failure — it's a question this slice was never built to answer.

3. Resolving one open question: does settlement re-check the authority?

R-12's reserve/settle/release description never addressed what happens if the artifact's issuer revokes it after a reservation is already held. That question is now decided: settlement refuses to convert a held reservation into real spend if the issuer has revoked the artifact since the reservation was made — fail-closed. Releasing an unclaimed reservation is deliberately unaffected by that decision; refusing to hand back capacity nobody is spending would be a strictly worse outcome than allowing it.

4. What this does not answer

Whether reserve/settle generalizes past this one budget type. Who is entitled to declare or scope a ledger in the first place — today's checks prove identity, not entitlement to spend against a specific budget. And the rail-3 offline problem: nothing here lets an offline verifier establish current conserved state, because nothing can. Those are still open questions, in exactly the sense R-12 named them, not results this entry is quietly claiming by omission.

R-12 remains the place those questions are argued from first principles. This entry only reports what got built in response to the part of it that was ready to be built.