The board lied because the rule had no owner

At 14:02 UTC on August 22nd a pull request merged into our public tooling repository carrying the deliverable for a brief called runtime credential contract. Three files changed. None of them was the stream board. Twenty minutes later the board still read 0/7 for that stream, and the job that regenerates the board had not run at all — it triggers on changes under docs/, and the merge touched nothing there.

$ gh pr view 67 -R medici-finance/assay --json mergedAt,files \
    --jq '.mergedAt, (.files|length), ([.files[].path|select(startswith("docs/"))]|length)'
2026-08-22T14:02:09Z
3
0
$ gh api 'repos/medici-finance/assay/contents/STATUS.md?ref=f78ea24' --jq .content | base64 -d \
    | grep desk-containers | head -1 | cut -d'|' -f3-
 P2 | active | 0/7 | 2026-08-22 |  |

The worker that opened that PR had followed its instructions. That is the part worth writing down. The lesson: a rule that lives only in prose is a description, not a control — if a claim has a witness, derive it in code; if it needs judgment, write it down and name the human; never leave an obligation in prose with no owner.

the incident

A stream board is one row per brief, one Status cell per row: the thing a human reads to know what is done. Our workers run from a skill file, the standing instructions an agent reads before it touches a brief. The public copy is 957 lines. It says "stop at implemented" four times.

$ git show f78ea24:plugins/assay/skills/worker-desk/SKILL.md | wc -l
     957
$ git show f78ea24:plugins/assay/skills/worker-desk/SKILL.md | grep -c 'stop at .implemented'
     4

Every one of those four is a ceiling — never set verified/done, never flip ready. Not one is an edit — change the Status cell before you open the PR. Search the file for an instruction to edit the README's status and you find one hit, about detecting a superseded PR, not about flipping your own row.

$ git show f78ea24:plugins/assay/skills/worker-desk/SKILL.md | grep -n -i -E 'README.*(implemented|flip)'
558:     brief's stream README for `status: implemented` pointing at another PR. A superseded PR gets

The worker read "stop at implemented" as a state you reach, not a line you write. It reached the state. The board did not. This was not the first time: the day before, the private toolkit's history shows two commits titled phantom sweep, hand-flipping merged-but-todo rows across streams, eight rows in those two commits alone.

$ git log --format='%ad' --date=short --grep='phantom sweep' | sort -u
2026-08-21
$ git show <sweep-1> <sweep-2> | grep -c -E '^\+.*\| implemented'
8

the root cause: an obligation in prose, with no owner

The proximate cause is one paragraph. A few lines above the four ceilings, the skill assigns the in-progress flip — the other half of the same row — to a different role: "the human-legible board claim (flipping each brief's row to in-progress in its stream README and pushing to main) is the coordinator's responsibility at delegation time." On August 14th that coordinator was moved to pull-requests-only; direct pushes to main were retired by ruleset. Nobody updated the paragraph. The in-progress flip now belonged to a role that could no longer perform it, and the implemented flip had never belonged to anyone.

The real cause is what kind of thing that paragraph is. It is prose, and prose is read by a model the way a human reads a policy manual: as a description of how things are. A description does not fail when it stops being true. It keeps being read, keeps sounding right, and a worker that follows it exactly is still following it when the role it names has been retired for a week. There is no step at which a sentence can refuse. Contrast the ruleset change that orphaned it: that was code, and the moment it landed, a push to main from the old role failed. The code half of the change enforced itself. The prose half drifted.

Two failures compound that. First, the phantom sweeps treated the symptom: a sweep compares the table to reality and fixes the table, which is the right move exactly once, to measure the drift, and the wrong move as a routine, because a scheduled reconciliation is a cron job whose job is to hide a missing owner. We filed the sweeps as a class of work without asking why the rows went stale. Second, our first fix was more prose: a new bullet saying the board row is part of the deliverable. It is correct, it shipped the same day, and it has the same shape as the sentence that failed — it asks a reader to remember, and it will drift the next time a role moves.

what we learned: claims belong in code, judgment belongs in prose

A board cell is a claim about the world: "this brief's deliverable is on main", "its Verify rows were re-run by someone else and passed". Almost every such claim already has a durable witness — a merged PR, a run log, an approval at head, a signed row. Where a witness exists, the cell should be derived from it by a tool, never typed by a person or a model. Where no witness can exist — "this is ready for customers", "this memo's rulings are the ones we meant" — the cell is a judgment, and it belongs in prose with a named human behind it.

The dividing rule is the lesson. Here is why it holds:

• A derived cell cannot be forgotten. The obligation moves from a reader's memory to a check that runs whether or not anyone remembers.
• A derived cell cannot drift. Code encodes the convention and fails loudly when the convention changes; prose encodes it and keeps sounding right.
• A derived cell makes the implementer cheaper to trust. When correctness lives in the gate rather than in the model's reading, a less capable model behind the same gate is no less safe — and the skill it reads gets shorter, not longer.
• A judgment cell cannot be faked by a tool that looks like it can. We once marked a decision memo implemented on the size of the memo when its definition of done was "rulings recorded"; a tool keyed on "a PR merged" would make the same mistake with more authority.

The corollary for reconciliation: run it once, to measure; never on a schedule, to cope. If the same sweep has a cron entry, the cron entry is the bug report.

how we are resolving it

Three changes, all of them moving a claim out of prose and into a check:

1. The link from PR to brief becomes one line of data, written where the worker is already typing — a Brief: trailer in the PR body, which the PR tool refuses to open without. Nothing parses titles or guesses from branch names; a merged PR without the trailer is a lint finding, never an inference.
2. Every lifecycle cell is derived from its witness: in-progress from an open PR with the trailer; implemented from that PR merged; verified from the re-run log; done from an approval at head or a human sign-off. A cell the tool could not check is unknown, with the reason printed in the cell — never a quiet todo. A board that cannot say "I did not look" will say "nothing happened" instead, and the two are indistinguishable to the reader.
3. The board table becomes a generated region with one writer. Hand-editing it is a lint failure, like hand-editing any other generated artifact. The skill text that told workers to flip cells gets deleted, not improved.

We specified the change as a set of briefs with executable verify rows, and the same machinery caught the author writing them. The first draft of seven briefs went through the standing lint before commit and failed:

$ statusgen --root . --lint
NOTICE: … brief-01 …: Verify row 2 uses `\|` inside a `grep -E` pattern — in an extended
  regex `\|` is a LITERAL pipe, not alternation, so the row matches almost nothing and
  passes whatever the file contains …
(10 NOTICEs of that class, 1 for an unsubstituted placeholder; 8 PROBLEMs for paths
named as if they already existed)
LINT: FAIL 8 problem(s)

Ten Verify rows that would have passed forever while checking nothing, written by the session that had just spent an afternoon arguing hand-asserted state is untrustworthy. The lint exists because that regex bit someone before. Coverage is the set of past incidents; the point of a gate is that it does not care who is on the other side of it.

what to do with this on your own board

• Grep your process docs for obligations with no named owner. Every "X must be updated" in a runbook, skill, or CONTRIBUTING file: who, at which step, enforced by what? If the answer is "whoever remembers", it is already drifting.
• For each cell on your board, write down its witness or mark it judgment. "Merged" has a witness (the merge commit). "Reviewed" has a witness (the approval). "Ready for customers" may be a judgment — then say whose, and stop pretending a tool can set it.
• When you fix a process, count the prose you deleted. A fix that only adds instructions has moved the failure.

the hedge

• The derivation described here is authored and under review, not running. The reconciling tool, the trailer check, and the generated table are specified in briefs with executable verify rows; today's boards are still hand-edited. The interim prose fix is what is in force as I write.
• Deriving state from the forge makes the forge the truth store. A force-push, a revert, or a renamed branch produces a confident wrong cell. unknown covers "could not look"; it does not cover "looked at the wrong thing".
• Code freezes a convention at write time. Changing it is now a schema version and a migration, where prose would have drifted with nobody noticing. That cost is real: the change ships as a major version.
• Fail-closed instruments fail whole. One malformed brief already freezes board regeneration for the entire tree; a per-node error model is designed, not built.
• Drawing the line between witness and judgment is itself judgment. That line lives in prose, with a named human behind it, and it will be drawn wrong sometimes.

The worker did what the file said. The file said the wrong thing because a rule had moved and its sentence had not. A board is a set of claims; a claim nobody is obliged to keep true is a claim you should expect to be false.