Claims in code, judgment in prose — the line is the product

A week ago a status board on our public site read 0/7 for a body of work that had already shipped. The worker that shipped it had followed its instructions exactly; the instruction that would have updated the board lived in a paragraph of prose that, after a role moved, no longer had anyone behind it. I've written that failure up on its own terms — the board lied because the rule had no owner — and this piece is not the incident. It is the rule I drew afterward, and the bill that rule sends every month.

The rule is one sentence. Every claim that has a machine-checkable witness — a merged commit, a run log, a signed row, an approval at a known head — gets derived by an instrument, never typed by a person or a model. Only judgment stays in prose, and the prose names the human who owns it. The interesting part is not the deriving. It is the line: deciding which claims have a witness and which are judgments. That decision is not a detail of the plumbing. It is the product.

a claim with a witness, typed twice, is a bug waiting

Take a claim like "this deliverable is on the main branch." It has a durable witness: the merge commit is either there or it isn't. Ask a person or an agent to also type that fact into a board and you have made a second copy of it, and a second copy is a thing that can disagree with the first. Worse, it disagrees quietly. A description does not fail the moment it stops being true — it keeps reading correctly while the world slides out from under it, and a reader who trusts it has no signal that it has gone stale. Derive the cell from the commit instead and there is no second copy to drift: the obligation moves out of a reader's memory and into a check that runs whether or not anyone remembers it. That is why the board lied — not because anyone was careless, but because the truth was being kept in two places at once.

a judgment has no witness — and faking one is the worse error

Some claims have no witness anywhere. "This is ready for a customer." "These are the rulings we actually meant." No commit settles them, no log, no signature; they are judgments, and a judgment is owned by a person, not computed by a tool. The trap — and it is the sharpest failure in the whole method — is a claim that looks derivable and is not. We once marked a decision memo done on the size of the memo, when its real definition of done was "the rulings are recorded," a thing no byte count can see. A derivation keyed on "a pull request merged" would have made the same mistake with more authority, because a number carries more conviction than a guess. Code cannot hold judgment. It is very good at looking as if it can, and that resemblance is exactly where the damage gets in.

the line is the product

So the method reduces to one decision, made again and again: does this claim have a witness, or is it a judgment wearing a witness's clothes? That decision is itself a judgment — the judgment about which things are judgments — and it does not automate. Draw it well and two things happen: the instrument is honest, and the prose gets shorter, because every sentence that told a reader to remember something is deleted in favor of a check. Draw it wrong in either direction and you get one of two failure shapes: a judgment computed with false authority, or a checkable fact left to a human's memory. The tooling that enforces it is ordinary; the line is where the work is. That is why I say the dividing rule is the product, not the plumbing under it.

the honest half: six ways the rule is brittle

I'd rather ship the honest half with the claim than after it, because the same property that makes a derived board trustworthy makes it brittle, and I've watched each of these cost real time.

1. Code freezes a convention the moment you write it. Change the convention later and you don't edit a sentence — you ship a schema version and a migration, a real cost, paid in hours. Prose has no migrations because it drifts silently instead. The cost didn't vanish when I moved the claim into code; it moved from a wrong reading I couldn't see to a version bump I can. That is a trade, not a free lunch.
2. An instrument that fails closed fails whole. One malformed input can freeze a board's regeneration for an entire tree — every row goes stale because a single row was unreadable. Per-row failure, so that one bad brief yields one unknown cell rather than a frozen table, is something you have to design in. It does not arrive for free, and if you forget it, honesty scales straight into an outage.
3. Enforcement taxes every honest session, not just the bad one. A guard that stops the wrong write stops the right write too, and the person it slows is almost always doing legitimate work. Friction breeds evasion, and a guard someone has quietly learned to route around is worse than no guard, because now you are trusting a control that is no longer there. The answer is fewer controls, enforced where they cannot be bypassed — not more advisory ones sprinkled across the path.
4. A tool that looks like it can hold judgment is the most authoritative way to be wrong. The moment you derive a cell that was really a judgment, you have dressed a guess in a fact's clothes, and the dressing travels. The only defense is the dividing line itself, and the line is easy to draw wrong under deadline.
5. Green is not good. A board that passes proves the checks you wrote ran and found nothing — and the checks you wrote are exactly the set of failures you have already met. This week a batch of verification rows passed while matching almost nothing, because a pattern meant to catch a case was malformed; green meant "the check executed," not "the world is fine." I concede this one without a hedge: a passing instrument is evidence of the absence of known failure, and nothing more.
6. The instrument is only as honest as the store it reads. Derive a cell from the forge and you inherit the forge's mutability — a force-push or a rename can hand you a cell that is confidently wrong, and the confidence is the dangerous part. The one defense I trust is a status that can say "I could not look" out loud: unknown must mean "I did not see," never "I saw the wrong thing." Telling those two apart is unfinished work.

None of these is answered by drawing the line more cleverly. They are the price of moving claims into code at all, and the honest version of my position includes them: the dividing rule does not abolish these costs, it relocates them somewhere you can see and someone can own. Silent drift becomes a loud migration. A wrong reading becomes a missing one. An unspoken assumption becomes a guard you pay for on every honest write. I will take the visible, owned cost over the invisible one nearly every time — and "nearly every time" is itself a judgment, which is the joke of it. The rule that sends claims into code was never code; it stayed in prose, with my name on it. This is the third claim the site makes for the method we run and publish, after the method and independent human verification, and it is the one I am least willing to state without its hedges attached.

what to move Monday

The thing to do differently is narrow. Take one status your team keeps by hand — a board cell, a "done" column, a dashboard number — and ask it the two-part question. Is there a witness for this: a commit, a log, a signature that already settles it? If yes, derive it, and delete the instruction that told a person to type it; a claim kept in two places will eventually keep two answers. If no, stop pretending a tool will settle it — write the judgment down and put a name beside it. Then watch what the derivation costs you: the migration when the convention changes, the blast radius when an input is malformed, the tax on every honest write. Decide, out loud, whether the visible cost is the one you want. If it isn't, the claim was judgment all along, and it belongs back in prose. The line is the product; drawing it, and re-drawing it when it moves, is the work.