Generation is a proposal
A drafted block is not accepted because a model produced it. It arrives as a proposal, naming the material it says supports it.
That list is an allow-list. The draft must stay inside it. If the block has no citations, cites an unknown evidence item, or contains a detail that its cited evidence does not state, the block is rejected by validation.
This is a useful place for a system to disagree with its own generator. The generator can write a plausible sentence. The guard can still refuse to commit it.
The rule is about particulars
The guard looks for details that can make a sentence materially different from its evidence. This includes numbers, years, spelled-out quantities, amounts, dates, and durations. It also checks proper nouns.
Each detail must appear in at least one single cited evidence item. The guard does not combine every allowed evidence item into one large pool and then license the draft from that union.
That restriction matters. If a block cites five items, a number from the fifth item should not automatically become available for a claim based on the first. Evidence is attached to a claim through the block’s selected citations. The guard checks that relationship rather than treating citation as a general licence to say anything found nearby.
Proper nouns follow the same principle. An employer, product, person, or organisation named in the draft must appear in a cited evidence item. The check is intentionally conservative. A legitimate capitalised word can be rejected if it is not recognised by the heuristic.
The consequence is deliberate. The system keeps the unsupported text out of the committed document instead of guessing whether the name was harmless.
What rejection looks like
Validation records which passage failed and why. A sentence can fail because it cites nothing, because it cites material that is not available to it, because it strays outside what the material can be used to claim, or because it introduces a figure or a name the cited passage never mentions.
The rejected text is not silently folded into the accepted result. The caller receives accepted blocks and rejected blocks as separate collections.
That gives the rejection a place in the workflow. A downstream service can fall back to deterministic text, ask for clarification, or report that the proposed wording needs review. The exact response belongs to the workflow. The guard’s job is to make the failure explicit.
The same pattern appears when answering over reference material. A proposed finding must have a citation. Its quote must be a substring of a cited passage. If the quote is absent, or if a number or proper noun is not licensed, the finding is recorded as rejected with a reason.
Why verbatim matters
“The contract says thirty days” and “the contract says thirty-five days” are close strings. They are not close facts.
Requiring a number or date to appear verbatim in the cited material creates a narrow check for a high-impact class of changes. It does not prove that the whole sentence is correct. It does stop the guard from accepting a new particular that the passage never states.
The check also avoids a subtle laundering path. A question may contain an assumption such as “is 90 days correct?” That assumption must not license “90 days” in the answer merely because it appeared in the question. Numbers are checked against the cited passage or the defined case facts.
The guard is therefore not trying to turn generated prose into a quotation. Connectives and conditional reasoning remain prose. The specific details that anchor the sentence must have a traceable home.
The honest limits
This is not a complete truth detector. A passage can contain a number that is misunderstood. A citation can be technically present but poorly chosen. A sentence can connect supported particulars in a way that needs human review.
The proper-noun check is a heuristic too. It can reject valid text. That is a known trade-off in the implementation. The fallback is a less ambitious document, not an unlicensed employer, product, or person.
The guard also does not decide whether a reference document is evidence about the user. That boundary is settled earlier, when the document is taken in. Validation works with the evidence set it receives. The set must already represent the right source class.
These limits are part of the design. A guard should report what it checked and what it could not establish. It should not turn a rejected block into an invisible edit.
The guard earns its place by refusing
The important event is not that a model drafted a sentence. It is that the sentence had to pass an evidence check before it could replace deterministic output or reach a committed document.
That check is narrow by design. It licenses details from cited material, records rejection when the licence is missing, and leaves the unresolved case visible. The system can generate a proposal. The evidence decides whether the proposal is admissible.