Document checks that bind claims to a source

AI writing tools state facts nobody checked.

The failure is not that these tools are usually wrong. It is that a confident sentence and a checked sentence look exactly alike on the page, so the reader has no way to tell which is which, and the writer has no cheap way to prove the difference. Documents that go outside a business, to a customer, a lender or a regulator, are where that matters, because the cost of one unchecked number is not the embarrassment but the loss of standing for everything else in the document.

Reviewing every sentence by hand does not scale, and it also does not work: attention degrades exactly where the text reads most fluently. What is needed is a mechanical step that refuses to let an unsupported claim reach a finished document.

I defined the problem, specified the gate and what it refuses, reviewed each release and ratified it; AI agents wrote most of the code under my gates.

A document pipeline checks selected claims against a confirmed fact base and checks rewritten wording against approved sources. It also checks rendered documents against their selected text and records export receipts. A failed check stops the affected export.

These are explicit checks with a defined scope. They do not establish that every possible sentence is true, and confirmed source facts still need human review.

Facts and prose are kept apart. A confirmed fact base holds statements that have been checked, with what confirmed them. The document then selects from that base rather than asserting on its own authority, so a claim in the finished text can be traced to the record that supports it.

Three checks run at different points. Selected claims are checked against the fact base. Rewritten wording is checked against the approved source, which is the check that catches a rephrasing that drifted away from what the source actually said. And the rendered document is checked against the text it was supposed to contain, because a document can be correct right up until the point where the export mangles or drops something.

The consequential design decision is what happens on failure. The export stops. It does not warn, annotate or downgrade to a draft, because a warning attached to a document that still exists is a warning somebody will route around under time pressure. Export receipts are recorded.

This site is subject to the same discipline. The public resume was rendered from a separately approved projection and checked against its source text, and every figure on these pages traces to a released claim.

The current source includes deterministic checks for selected claims, approved wording and rendered output. The September 8 release record documents cases where stricter checks changed which exports were valid and records remaining gaps. The public resume on this site was rendered from a separate approved projection and checked against its source text.

The record shows that tightening the checks changed which exports were allowed, which is evidence the gate does something rather than evidence that the documents became more useful. No improvement in decision quality has been measured and none is claimed.

The honest test of a gate like this is whether unsupported claims reach a finished document after it is in place. That requires counting refusals, and counting what got through, over a real period of use. This entry does not report either.

If a business needs its written material tied to something checkable, the knowledge and reference engagement starts by testing which claims the existing sources can support. The retrieval half of the same problem is in connected records and search, and the applied research case is in filings research.