An outside reviewer found five problems. They were all the same problem.

TL;DR: A claim that has to survive a chain of language-model reads loses its provenance when it travels as prose, and keeps it when it travels as typed state with one owner. Checks that compare text against text catch an invented claim. They can't catch a borrowed one, because a borrowed claim was there to be found.

StratOS is a chain. The first read of the company feeds the customer profile, which feeds positioning, which feeds pricing, which feeds the brief an agent builds from. Every read inherits what the reads before it committed.

For a month we fixed defect after defect inside single reads, and the single reads got good. Then an outside reviewer, given nothing but the rendered chain, found five problems in one pass.

Five findings, one cause

The five: a customer profile labeled "Known" that the system itself had marked as an assumption one read earlier; four numbers shown the same way when one was a market assumption, one a calibration threshold, one an operating rule; a recommendation section that said only "carried in the sections above"; a founder-facing line that read "committed with 10 open validation issues"; and two documents giving opposite guidance on one decision.

Traced back, each had a mechanical cause. The "Known" label passed because the check asks whether the claim appears in the text the model was given, and it did: an upstream read had served it, as an assumption. A text check has no grade. The numbers looked alike because the number check asks one question, is this value in the served text, and can't tell a filter from a fact. The empty recommendation existed because a required section the model failed to write was filled with a stock sentence so the document could be committed. The ten-issues line was machine state shown as prose. The contradiction came from one rule with two authors and no owner.

The shared cause: claims traveled between reads as prose, with their provenance attached to the document or the label, not to the claim. The note "Known is too loose" had appeared in every review for a month under a different example each time.

The blind review was worth having for a second reason. With no code and no documentation, the reviewer's proposed fixes mapped one to one onto mechanisms we had built and that had been defeated by a missing consumer. Convergence from the rendered output alone says the failure classes are real, not self-confirming.

Why checking the text could not catch it

Every check we had compared a string against a set of text. That closes fabrication and leaves laundering wide open. A competitor or a figure that was never served gets caught. A claim that was served as an assumption and arrives downstream as a fact does not. The claim is present; what's missing is its grade.

A rule written over model prose is always one phrasing behind. Each new run surfaced a new way for a true claim to be misread: a bold terminator defeating a sentence splitter, a list ordinal read as a figure, an uppercase status label parsed as a vendor name. A detector of that kind can only be tuned against live output, and its cost runs both ways. A missed invention reaches a founder. A false positive throws away a five-minute document.

The contrast settled it. Where the server renders the committed value itself, from the stored record, the whole class of defect stopped recurring the day it shipped. Where a check tried to recognize the model's restatement of that value, the fixes never ended.

What travels instead

The mechanism is a claim ledger. Every committed read emits a typed list of the claims its prose rests on, each with an identity, a class (fact, assumption, calibration threshold, operating rule), a grade (known, assumed, to verify) and an origin. The server owns it, serves it to the next read beside the prose, and every check reads it.

Four rules follow, each with a consumer.

• A grade never rises downstream. A "Known" label must bind to a ledger entry whose grade is known, and a label whose only ancestry is an assumption is rewritten as one.
• A number has a class, and the display says which.
• A section the model failed to write is marked as missing, never filled with a stock sentence.
• Machine state is typed and translated. The count goes to the evidence panel, and the founder reads one plain sentence.

A founder's correction is the same object read the other way. Change one claim, and every read whose ledger cites it is marked stale by identity, with the prior reasoning still visible.

There was one more finding, the uncomfortable one. The same chain showed the checks were too strict. They blocked two of five reads, and what they blocked were projections the reads had honestly labeled as assumptions: switching durations, a customer-size range. For a product whose job is strategy under uncertainty, refusing to project isn't safety. It's refusing to do the job. So the rule for uncertainty is now: never block, demote and label. Blocking is kept for damage only, meaning broken output, leaked machinery, or a citation to a source that was never served.

Status, plainly: the four rules are built. The ledger keyed by claim identity and the correction propagation are the open work, and the chain logs will be attached when the full write-up is published.

The next review will be run the same way, blind, on the rendered chain, by someone who hasn't seen the code.