The lifecycle: merged is not verified

The moment an agent finishes a piece of work in our tree, it is the best-informed party in the fleet and the least-qualified witness. It has just run the checks and watched them pass; it also wrote the code the checks are about, and it has the most at stake in the answer. Every tracker gives work a status vocabulary. A fleet forces a sharper question: which identity is allowed to write which word?

The unit of work here is a brief — one markdown file that carries its own definition of done as a Verify table, literal commands with expected output, written to be runnable by a stranger. A brief's status is one of five words:

todo → in-progress → implemented → verified → done

Most of that machine is ordinary. The load-bearing part is a wall between the third word and the fourth, and the wall is this article's whole subject: the lifecycle is an identity partition wearing a progress vocabulary — no identity may write a state that grades its own work. The methodology's documentation gives the rule its handle: an implementer verifying their own work "is the narrator grading their own exam."

the implementer stops at implemented — after running every check

implemented is not a shortcut past the checks. To claim it, the implementer runs the full Verify table itself and logs its results in the brief's Evidence section. That run has real value — it catches honest failures while the context to fix them is still loaded — and it goes on the record as exactly what it is: the interested party's account of its own work.

What the implementer may not do is write the next word. Not because agents lie constantly — most self-runs are accurate — but because the conflict is structural, and a rule that only binds when the narrator happens to be honest is not a rule. The problem with a student grading their own paper isn't that every student cheats; it's that the grade stops meaning anything.

The diagram's point is what it refuses to draw: the merge — the moment most trackers treat as the finish line — is not an edge in this machine at all.

merging does not verify

After a brief's pull request merges, the brief does not move. It lands in a queue the status board renders under its own heading — awaiting verification — until someone independent runs the checks. On our board as of this writing that queue holds 39 merged briefs, 38 of them still at implemented.

Merging feels terminal: review happened, the checks were green, the code is on main. But everything green at merge was measured on the branch, about the diff, largely by the party that produced it. The lifecycle doc gives rule and reason in one breath: "an unwatched awaiting-queue is how briefs rot at implemented — verified is a distinct, owned step, not a side effect of merge." The queue makes merged-but-unverified work a visible liability with an owner, instead of a silent default.

verified is a re-derivation, not a stronger adjective

To move a brief to verified, a non-implementer re-runs the entire Verify table against merged main and appends a dated result under its own identity — in the doc's words, independent re-execution is the check that "works on my machine / green in isolation" claims survive contact with main. The verifier is not asked to believe the implementer's log or audit its prose; it is asked to re-derive the result — same commands, different hands, current tree.

Attribution is part of the state: Verified and Reviewed cells take dated, attributed entries, never a bare checkmark — an undated tick is unattributable and unauditable. done costs one thing more: the recorded review verdict, which for a risk-flagged brief must name a human; a model's sign-off does not close one.

the log appends; a green run never buries a red one

The Evidence section those runs land in is a log; each entry is an execution witness. The mechanized form runs each Verify row's command in a fresh subshell and writes one row per check:

Each column is chosen against a specific forgery. The command is recorded as authored in the Verify table, so a later run can prove the row hasn't been edited since. The output cell is a hash of everything the command printed — a fingerprint two people can compare. The runner cell pins an identity to the exact tree it ran against, with a +dirty suffix on the SHA when the working tree was modified — a witness from a touched tree says so on its face. And the runner is derived from the executing process, never supplied: there is deliberately no flag to set it, and asking for one is refused with its own message, because a witness you can caption is a witness you can forge. When no identity can be derived, the tool writes nothing rather than record an unattributed row.

Two rules follow from the section being a log. Runs append, never overwrite: an implementer's run, a verifier's re-run, and a re-verify at a later SHA are three separate facts, and rewriting the section in place would let a green re-run erase a red one — "editing the recorded basis of a past sign-off, which is the falsification the whole mechanism exists to catch." And results come in three states, not two — pass, fail, could-not-run — where could-not-run never renders green, so a row nobody could execute cannot be laundered into coverage by writing a witness for it.

one brief, two runs, three weeks apart

The brief that moved our board generator onto a pinned, hash-verified release binary shows the whole machine in motion. Its Verify table holds five rows: the committed pin's hash matches the released binary; the CI lint gate runs the downloaded-and-verified binary; a grep proving no workflow still builds the tool from source (expect 0); the post-merge board regeneration goes green via the pin; the pinned binary's lint exits zero.

On 2026-07-23, a verifier with no part in the implementation ran all five rows from an isolated worktree off merged main, against a fresh clone rather than the shared checkout. All five passed; the entry — dated, attributed, per-row exit codes — went onto the log, and the brief went to done, along with two non-blocking flags: a verifier's job is findings, not just green.

Three weeks later a re-verify was requested. On 2026-08-13 a different verifier identity ran the table again, against a main that had moved: the pinned release had drifted from v0.1.0 to v0.8.1, eleven releases later. It re-downloaded the released binary, re-hashed it against the committed pin — pin file, release checksums, and served binary agreed on all three platforms — and passed rows one, three, and five. Rows two and four it could not execute under isolation, because their live-CI legs belong to a consumer repo outside the verification boundary; it recorded them as corroborated from green run history, explicitly not as passed. Verdict: the done state still holds on current main.

Both entries stand on the log today; that is the point of appending. The second run is not a correction of the first but a new fact at a new SHA. A re-verify that found a regression would also have stood — above the old pass, not in place of it.

what the wall does not hold

The wall is made of process, and it is honest about its material. The runner cell is a derived string, not a signature: the lint that checks a verifier isn't the implementer compares authored names in self-written text, without corroborating them against commit authorship — the compliance mapping marks this control "enforced as a string check, advisory as a control," and a single participant willing to write both cells satisfies it. The witness has the same shape of limit, stated about itself: it is evidence, not an attestation, because whoever controls the process controls the environment it reads — the variables that name the runner, the git config, the subshell. Its real strength is where it lands: in a pull-request diff, next to the tree SHA it names, where a second identity can re-run the command and compare hashes.

Nor does verified mean correct. The Verify table proves function — "works?" — while the review proves quality — "well-built?" — and neither substitutes for the other. A table of weak rows verifies weakly: re-execution multiplies the table's rigor by a second identity, never adds rigor the rows lack. And briefs closed before the witness mechanism existed lack machine witnesses by construction, so the lint notices that gap rather than hard-failing it — back-writing witnesses to green the gate would manufacture precisely the evidence the witness replaces.

So the strong claim — verification here is impossible to forge, status "is measured, never self-reported" — is one the methodology's own docs deny. What the independent re-run actually buys is a second identity re-deriving the witness on the merged tree, on the record, in a form a third can re-derive again. Attribution, not enforcement — claim the weaker, true thing.

states in a file, a log that appends, an identity split

Nothing above requires our tooling; the wall is four decisions on a stock forge:

1. Give work a closed status vocabulary in the work item itself, and write the stop rule where implementers will read it: run your checks, log your results, stop at implemented.
2. Make the next state cost a second identity: verified is written only by a non-implementer who re-ran the checks on merged main. Enforce what your platform can, lint the rest, and say plainly the leftover is a string check.
3. Make evidence an append-only log of runs — per check: the command as authored, exit code, output hash, date, runner pinned to the tree SHA. Never rewrite an entry; a green run lands above a red one, not over it.
4. Put merged-but-unverified work in a queue someone owns and everyone can see.

Do that, and verified stops being a synonym for merged and starts costing what it should: a second identity, re-deriving the result. The narrator still writes the first draft of the record — nothing here prevents that. It just stops being the only handwriting on the exam.

The board that renders these states — compiled from the briefs by a single writer, linted on every branch — is its own mechanism, introduced in "Introduction to Assay: you don't need to trust the agents."