Three systems.
Three decisions, costed.

01 / problem

ABACUS makes live decisions under noisy feedback: it reads signals, commits an allocation, and attaches a protective exit to each one. What makes the system hard is not the arithmetic. It is silence.

A staleness watchdog inspected the handle a consumer held open — and a handle's identity never changes, so the check could not fire. Ever. Two processes stayed alive, stayed polling, and did nothing for hours while the layer above re-read the same frozen stream and logged thousands of unchanged rows. The supervisor's view said healthy throughout, because health had been defined as the process existing.

The archive accepted a successful, well-formed, completely empty reply from its upstream service and wrote it down as a day on which nothing had happened. And a live path produced nothing for hours because its admission gate demanded the decision arrive inside a window, while the underlying data arrived with a lag — the window was not tight, it was unreachable, and had been from the start.

02 / decision

Every guard is built to refuse, and each is exercised in the failing direction: the pin tests re-pointed at a deliberately wrong fingerprint, the deployment attempted outside its window and watched decline, a manual start made impossible at the platform level and the impossibility verified by attempting one.

The most consequential gate is enforced by absence. Until a per-account setting carries an explicitly signed value, every pass skips its actions and writes a hold record; missing configuration yields the held behaviour, so the guarantee does not depend on code being reached in the right order. Weeks later a person signed, and the loop released with no code change — the difference between armed and acting is a decision with a name attached.

New live gates ship behind a flag, off by default, fail closed, and every refusal is written to the ledger with its own reason code, so a quiet afternoon cannot be confused with a silent filter. The safety arithmetic is encoded as acceptance tests — the amount at risk at a protective exit must equal the allocation, two simultaneous exits must stay under the daily limit — and a standing rule forbids optimising a guard into its negation, because the negation admits exactly the cases the guard existed to exclude.

03 / cost

Every guard carries two tests rather than one, and the failing-direction test is the more awkward to write. Lateness became a first-class input: an incremental engine so the decision exists before the window opens rather than after it closes.

A gate was built, tested, proven correct — and then not enabled, with the commit saying so. Being built is a separate decision from being switched on, and the second belongs to a person looking at the running system.

01 / problem

UMBRA is a peer fabric with no window in which the whole network is quiet. The moment a message's shape changes, two populations disagree about what a message means, and the obvious answer — optional fields, negotiated capabilities — was rejected because every optional branch is a place where two implementations can quietly disagree. The failure surfaces in the field, months later, without a stack trace.

Meanwhile the one upgrade that actually matters — new key material, a new handshake — invalidates every existing message shape at once. Landing it early would have shipped a break with nothing underneath it: no stores to hold the new material, no replay defence, nothing to retry against.

The team's own evidence needed the same scrutiny. A traversal test passed repeatedly on both address families — and was meaningless, because the testbed's pre-configured forwarding rules, not the pathfinding code, were what made the packets arrive. The evidence was about the harness.

02 / decision

Each protocol version gets its own complete copy of the tree: framing, coordinator, client, directory, deployment module, test topology. A version can be kept alive or abandoned without untangling flags, and the difference between two versions is legible as a whole rather than as a scatter of conditionals.

The release plan is split at an explicit boundary. An additive phase — more than a dozen steps — in which every step only adds variants, stores and configuration, every step must leave the old flows working unchanged, and every step sits behind its own test gate. Then one deliberate breaking fork, where the break is the point.

When the harness turned out to be the thing under test, the result was invalidated rather than reinterpreted, and the change record was rewritten to say what had and had not been shown.

03 / cost

Duplication, and a merge burden carried by hand. The security property arrives last, and the schedule looks padded until you read what the padding is for. A milestone already recorded as passed was withdrawn in public inside the team's own records.

A tested, documented, convenient library function was deleted rather than wrapped, because the real protocol has two sides and the function could never operate on work someone else had issued. A rejected optimisation sits behind a compile-time flag with its measurements and the condition that would reverse it — kept, because deleting it would mean paying for the same knowledge twice.

01 / problem

KEEL is a small estate, few hands, real services. A rebuild you have never performed is a hypothesis, and the first deliberate reset cycle exposed how much of each machine lived only in someone's memory: firewall rules, service definitions, the order in which things had to start.

The declarative record lagged the imperative one in the ordinary way — a change typed by hand at the moment of need, the repository updated later or not at all — and the running artifact was the source of truth until proven otherwise. Per-port rules looked like security and behaved like a promise to remember every port, so the estate accumulated silent holes nobody wrote down.

Then a proposal arrived to make the datastore highly available: two copies, automatic failover, the standard shape from every design document.

02 / decision

The review asked a narrower question: what failure does this remove? The datastore dying on its own was already the cheap case — the scheduler restarts it in seconds and the application reconnects. The failure that actually happens takes the whole machine with it, and redundancy inside one machine survives neither. The decision was copies instead of replicas: backup generations held by different companies, in different buildings, plus a restore drill that proves they can be read. The record states the reasoning, including that the cheaper answer was the better one.

Exposure became a decision with an owner: default-deny on the ingress path with a short allowlist, an access list flipped from allow to deny in a rolling pass with credentials minted before the flip so the change could not lock itself out, and the anonymous dashboard path closed. Credentials are scoped per machine, and the denials are proven by making the request and watching it be refused.

Renewal became a delivery problem. The running service keeps the old credential in memory, so the procedure is: signal a reload, then connect and compare the fingerprint of what is actually served against the file just written, and restart only if the old credential is still served. Having written a file is not evidence that anything changed.

03 / cost

Writing is not small. A repository that can rebuild a machine has to be maintained as if it were the machine, and the temptation to make one quick change by hand never goes away. The estate's documentation is split into what should be true and what is true, and the gap between them is the real work queue — in one review the document said the secret store reopened itself after a restart, and the check said it did not.

A force-run of automation was halted by the operator, because the script would have restarted a cluster member on machines where the reload path had not been proven. And the failures this estate has chosen to live with are written down, out loud.