Agent-Written Prose Has No Failing Test

This is the last part of the series, and the research desk is still illustrative. Before any of the controls in the earlier parts, memo M-104 reached clients through a one-click endpoint that skipped the publishing policy. Every URL that was present resolved. Some claims, c3 and c4, had no note reference at all. Another, c5, went beyond its cited note.

The controls from the first part fix the first problem. The publishing service refuses a memo with untraced claims and refuses one without a researcher's sign-off on that exact snapshot. Run the corrected memo through it, and it goes out. c3 now points at n3. c4 was dropped. And c5 still says "Lead times fell in every region", citing n4, a logistics survey whose data shows lead times fell in two of three regions and rose in the third.

c5 was fluent, it was confident, and it sat in exactly the right place in the moderator's argument. It passed the traceability check, because it pointed at a real note with a real source. The moderator agent's own review pass came back clean.

The wrong sentence is not the interesting part. Agents write wrong sentences, and they always will. The review that existed to catch it ran, produced a report, found nothing, and was right to find nothing given what it actually was: the same context that had written the sentence, asked a moment later whether the sentence was true. Nothing else in the pipeline objected either. A memo does not fail to render because a claim overstates its note. The build stayed green from the first draft to the client's inbox.

Two different checks are hiding under one word. Structural traceability asks whether each claim points at a note that has a source. A function can answer that, and the publishing service does. Claim-to-source fidelity asks whether the note actually supports the claim, at the strength the claim states it. Plenty of things check the memo: the schema validates, links resolve, every claim has a note id. None of those has an opinion about whether "every region" is true.

I should be careful here, because "nothing can check it" is too strong. c5 is testable. n4 carries its data, and "fell in every region" is a statement about that data. A three-line check would have failed on the sentence. Some claims have a reproducer like that, and when they do, I attach it. Most claims do not: whether a source supports a sentence in words, whether an example happened, whether a figure may be reused. For those, review is the only check there is.

That changes what the review step is for. In code, review is one assurance mechanism among several, and the others keep working even when review is weak. That is the general shape of agents acting at a gate they do not own. For prose, whether it is a client memo or an article like this one, the mechanical checks stay mechanical, and for most claims review is the only thing standing between a false claim and a reader. A gate carrying that alone has to be built like it.

Why a Second Pass Cannot Close the Gate

The obvious fix is to add a review step. When that does not work, the next guess is a stricter prompt for it.

Start with the case in favour, because it is real. Having a model critique and revise its own draft does improve it, on many kinds of task, by a margin large enough that it is tempting to stop there.

It stops working in the places you would least like it to. The gains shrink, sometimes to nothing, on tasks where the model cannot tell whether there is an error at all. A model that cannot detect the mistake is not made more likely to detect it by being asked a second time, and asked to self-correct without outside feedback, models sometimes make the answer worse. On the judging side the bias is measurable: judges tend to rate their own output, and output from similar models, more favourably, even against criteria that are meant to be objective. Using several judges reduces that. It does not remove it. And at least one line of work finds that more capable models make more similar mistakes on the tasks it measured, which, if it holds more widely, is bad news for any plan where one model checks another.

Be careful how much weight that carries. The research behind those statements measures model evaluation and reasoning benchmarks. None of it measures a researcher reading a two-page memo for a claim that is stronger than its note. It tells you the mechanism is plausible and which direction the bias points. It does not tell you how big it is here.

So the honest claim is narrower than "self-review does not work." Self-review probably does improve the draft. What it cannot do is satisfy an independent-review gate, because the artifact it produces is a clean report written by the party whose work is in question. That is a statement about what the check is evidence of, not about whether the check helps.

Independence is not a switch either. It is easier to reason about by asking what each kind of check shares with the writer, because a pipeline can describe itself as independent while sharing almost everything. A second pass in the same session shares the draft, the reasoning that produced it, and whatever the model was already wrong about. A fresh context running the same model family loses the drafting memory but keeps the priors. A different model or a different tool with no drafting history shares less, which is where correlated failure can start to loosen. Deterministic external checks do not share the model's reasoning, though they can still inherit the writer's assumptions through what they check and what they expect. They are also narrow: a link either resolves or it does not, and that says nothing about whether the source supports the sentence. A human reader shares none of the model's history, but brings their own assumptions, and two human readers can share the same wrong one just as easily as two models can. None of these is a superset of the others. Each catches a different kind of mistake.

The Checks That Have No Runner

Code review has help. A passing test tells you the code does what someone encoded, which is already less than most teams assume, but it is not nothing and it arrives without anyone being asked to be careful. Prose gets no equivalent for the things that matter most, and the list review has to carry alone is longer than it looks.

The first and dullest is claim-to-source fidelity. Not whether a citation is present, which is easy and which agents are good at. Whether the sentence says what the source says. A paper reporting improvement on seven benchmark tasks becomes "research shows this works." A framework describing practices becomes a framework requiring them. The citation is real, the link resolves, the claim has drifted, and no formatting or link check will notice.

Citation freshness is the second, and it decays quietly. A source that supported the sentence when it was written may not support it now. Preprints get revised, and a version three that agreed with you can become a version five that does not. This is the one place a mechanism helps: record the retrieval date next to the claim, then re-fetch before the piece goes out, and treat a changed source as a finding rather than a formality.

Anecdote provenance is where agent-written content fails in the way that costs the most. Ask an agent for a first-person example without giving it one to work from, and you will still get one. It will be specific, it will be well-shaped, and nothing about it tells you whether it happened. Composite stories are fine, as long as the piece is honest that they are composites. A merged narrative with a precise quarter attached to it is not a composite. It is a fabricated incident with good sourcing hygiene.

The rights and privacy check has the sharpest downside, and it is easy to skimp on. Reuse terms for a quoted passage or a redrawn figure are not established by deciding to use them, and a model asked for an illustration will produce one without ever having had access to the terms. Anonymization fails from the other direction: a story with the identifying details removed can still be undone by the one distinctive detail that felt too good to cut. Neither of these produces an error at build time. Neither produces an error at all, in fact, until somebody who recognizes the material reads it, and by then the remedy is not a fix but an apology.

And then the small half that is genuinely deterministic. Metadata that has to be present and well-formed. Links that have to resolve. Assets that have to exist at the path the document names. Rendering that has to not break. Build every one of those, because they are cheap and they never get tired. Just be clear about the ratio. That is the part with a runner, and it is the smallest part. Everything above it is a reader deciding whether sentences are true.

There is one more structural thing about content, and it catches people who have built the rest correctly. There are two artifacts, not one. The source is what the author edits. The rendered page is what the reader gets. A claim can be right in the source and wrong on the page, because a caption contradicts the figure above it, or a link that resolved at draft time now redirects somewhere else, or the layout puts a qualifier three screens away from the sentence it qualifies. The failure mode can belong to the second artifact alone: nothing in the source is wrong, but the page is misleading anyway, and a reviewer reading only the source can miss it. Reviewing the source is not reviewing the article. They are separate reads of separate things, and a pipeline that only does the first one will publish a piece nobody has actually looked at.

What Makes a Gate Load-Bearing

A gate needs four properties, and one missing any of them looks identical to a real one in a diff.

The reviewer has no drafting memory of the material. This is the property everything else rests on, and it is expensive to keep. In teams where an author cannot approve their own pull request, that is a policy line rather than a judgment call. A separate context is the minimum. A different tool is better. If the same session that wrote the piece is checking the piece, the independent assurance gate is still unsatisfied. That pass can still improve the draft; it just cannot supply the independent evidence the gate requires.

Findings get dispositioned one at a time. Accepted, modified, rejected, or deferred, each with a reason. Accepting a report in bulk records that you agreed with it. It does not record that you verified anything, and the difference shows up later, when you cannot remember whether finding four was wrong or merely inconvenient. Rejections matter as much as acceptances here. A review nobody ever pushes back on is a review nobody is reading.

The approval is bound to what it approved. A material change inside the approved content and asset scope invalidates the approval, and the system should notice without being asked. What a hash gives you is a mismatch when the content and assets it covers stop matching what was reviewed. That is freshness evidence, and it is the whole of what the mechanism offers: a person still decides whether the change mattered. It does not identify the artifact, establish who approved it, establish that they were entitled to, or say the approval was any good. Those are the receipt's job, and the receipt is only as good as whoever wrote it.

And a waiver stays visibly a waiver. Skipping a review is a legitimate decision that people will make on real days for real reasons. Recording it as a pass is not. The record has to say, permanently, that this gate was satisfied by someone deciding to skip it rather than by anyone checking, because six weeks later nobody remembers and the record is all there is.

Then the part that governed-looking pipelines get wrong, and the reason they end up with no human in them: satisfying the review gate is not permission to publish.

The diagram is conceptual, and its only job is to keep the two diamonds apart. Review authorization asks whether this has been checked by something that counts, and a recorded waiver answers it as legitimately as a pass does. Publication authority asks something else: does a person want this in front of readers, now, as it stands? A green review does not imply it, the last publication of the same article does not carry it forward, and no default fires it when the checks come back clean. The release-side version of this argument is the same shape applied to shipping code.

Which leaves one operation an agent structurally cannot perform, and it is neither writing nor reviewing. It is approving its own exception. An agent can draft, review material it did not write, apply findings, and assemble everything a waiver needs down to the reason. The moment it can grant itself the waiver, every gate above it is decorative, because the pipeline now runs unbroken from "I would like to skip this" to "this was skipped" with nobody in it.

The rubric I actually review against

Principles are easy to agree with and hard to apply on a Tuesday. So this is the rubric, with what "passes" means for each line. Every line blocks publication when it fails.

The claim ledger is the piece most people skip, and it is the one that makes the first line checkable. It lives next to the draft, outside the published content, one entry per claim:

# claims.yaml for memo M-104 (private, never rendered)
- id: c5
  sentence: "Lead times fell in two of three regions."
  first_written_as: "Lead times fell in every region."
  kind: numeric            # factual | numeric | opinion | hypothetical | experience
  note: n4
  source: s4
  retrieved: "2026-10-01"
  scope: "the three regions in the survey; not a statement about the supplier overall"
  reproducer: tests/claims/test_claims_m104.py
  reviewed_by: "<researcher>"   # fidelity is a human finding, recorded here

The ledger uses the same ids as the desk: claim c5, note n4, source s4. And the reproducer, for the claims that can have one. It is pseudocode like the rest of the series, and it reads the same fixtures/memo_m104.json that the publishing tests and the evals use:

# pseudocode: tests/claims/test_claims_m104.py, a reproducer for claim c5
n4 = fixture("memo_m104").notes["n4"].data    # {"north": -3, "central": -2, "south": 1}, illustrative
 
def test_c5_as_first_written_is_not_supported_by_n4():
    assert claim("c5").text == "Lead times fell in every region."
    assert not all(change < 0 for change in n4.values())          # south rose by a day
 
def test_c5_as_corrected_matches_n4():
    assert sorted(r for r, change in n4.items() if change < 0) == ["central", "north"]

A check that asserted the sentence as first written, every region below zero, would fail, because the south region rose by a day. The test file records both halves: the original wording is not supported, and the corrected wording, "fell in two of three regions", matches the data. The data itself is illustrative. That is the closest prose gets to a failing test, and it only covers a small part of what a memo says. c1 to c4 have no data to compute; their fidelity is a researcher's finding in the ledger.

When a document needs this gate

The rubric is too much for most writing. I apply it when a document goes outside the team, when readers will treat it as the answer without checking (runbooks, onboarding guides, anything customer-facing), or when it states numbers or describes controls. Everything else gets a normal read by someone who was not the writer.

What This Costs

I run a version of this on a personal project I build and maintain, and it is slower than not running it. The cost is real and it does not go away with practice.

More turns per piece, obviously. More scaffolding to maintain, and the scaffolding is itself content that can go stale. Plans go through several rounds of independent review before a word of the actual article gets written, which feels absurd right until a reviewer points at the thing the plan was quietly wrong about, and then it feels cheap. There are also days when the second tool is slow, or unavailable, or I simply do not want to spend the turn. On those days the piece waits. Writing down a skip and then approving it myself would be the self-granted exception this article argues against.

What it bought was not what I expected. The findings I needed most were not typos or awkward sentences. They were structural. A claim stated more strongly than the evidence underneath it supported. An argument that had quietly merged separate questions and answered none of them cleanly. An approval described as verified when the only thing verifying it was me. Whether a same-context read would have caught any of them is not something I can tell you, because that is not the comparison I ran. What I can say is that a clean report from the context that produced them would not have shown that anyone had tested them, and being tested was the entire value.

Whether any of that adds up to better delivery is a separate question with its own measurement problem, and I am not going to pretend I have solved it by describing a workflow.

Most Writing Does Not Need This

Almost none of it, in fact.

The axis is not how much you care about the writing. It is whether a wrong claim will sit in front of someone who cannot check it. A draft nobody but you will read needs no gate at all, because you are the reader and you will find out. A note to two colleagues who know the system better than you do needs no gate either, since the review is going to happen regardless, in the reply.

It starts to matter when the reader cannot verify and would not think to try. A memo read by a client who will repeat its claims in their own work. A technical article read by somebody about to configure their system that way. Documentation a new engineer will treat as the answer because it is written down. Anything where being wrong is invisible to the person being misled, which is the only case where the cost lands on someone who did not choose it.

Rollback does not save you here. Taking a published article down is mechanically easy and close to useless, because the page comes down and the reader who already acted on it is not covered by the deletion. The desk learned this in the release part: once clients are notified, what is left is a correction notice. On the code side, reversibility, data access, impact and blast radius decide who may sign: the harder something is to undo, the higher the authority needed to do it. Prose inverts that. The artifact is trivially retractable and the reading is not, so the cost of being wrong is set at publication and never comes back down.

Most of this assumes a public article, because that is where the boundary is unambiguous. Publication is an event. It has a moment, and a person can be asked to authorize that moment. Other content has a fuzzier equivalent and you have to go find it. For repository documentation it is usually the merge. For a wiki it is the approval, or the visibility change that moves a page from somebody's draft to something the team will quote back at each other. Look for the point where the material stops being yours and becomes everyone's, and put the gate there. If you cannot find that point, that is worth knowing on its own, and it is probably the more urgent problem.

What Procedure Cannot Manufacture

The uncomfortable part is that all of this is scaffolding around a judgment that none of it makes.

A separated review still ends with a person deciding which findings were real and whether they were addressed, and that decision is not gated by anything. The reviewer's independence protects the draft. Nothing protects the moment where a human reads four findings and rules on them. If that person does not understand what independence was supposed to catch, the apparatus becomes a form to fill in, and a well-run form is indistinguishable from a well-run review right up until the day it matters.

I also do not have a clean answer for where the line sits. I said the axis is whether the reader can check the claim, which is directionally right and operationally useless, because you do not know your readers, and the piece you assumed three people would see is the one that gets linked. Gate everything and you stop writing. Gate by feel and you will gate the pieces you were already nervous about, and those are not the pieces most likely to be wrong.

If you are running agents over content that matters, the cheapest change that actually does something is not a better review prompt. It is making the reviewer something other than the writer, and then writing down what it found, one finding at a time, before you decide anything. What I still cannot tell in advance is which pieces deserve the rest of it.