Explain when 'citations required' belongs in the output rail

**A citation-required output rail enforces that every factual claim in the model's response points to a retrieved document by id.** The rail does not check whether the claim is true; it checks whether the claim can be checked by someone else. The enforcement loop is mechanical. After the model generates its response, the output rail: 1. Parses the response into claims (sentences or claim-shaped fragments). 2. For each claim, checks that an inline citation marker is present and that the marker refers to a document id in the retrieval set the model was given. 3. Optionally checks that the cited document actually supports the claim, typically a smaller verifier model or string-matching heuristic. 4. If any claim lacks a citation, either re-prompts the model with 'add citations to the uncited claims' or blocks the response entirely depending on the deployment. The failure mode this prevents is **overreliance on hallucinated content** (OWASP LLM09). RAG models can produce confident, fluent text that sounds grounded but is fabricated. The retrieved documents may not have contained the claim; the model filled in plausible-sounding detail. Without citation enforcement, a downstream user has no way to verify the claim. With citation enforcement, every claim has a paper trail. The distinction worth holding: **attributability is not truth.** The rail catches 'this claim has no source' but cannot catch 'this claim has a source that does not actually support it.' Truth-checking requires a separate verifier; attributability is the necessary first step that makes verification possible.

**The citation-required rail enforces attributability, not truth, and that distinction is the whole point.** **The enforcement loop.** Output arrives from the model. The rail parses claims, looks for citation markers (a stable format like `[doc_id]` or `[case_2024_007]`), and verifies two things: each claim has a marker, and the marker refers to a document id that was actually in the retrieval set fed to the model. Two failure modes get caught: claims with no citation at all (the model fabricated), and claims with citations to documents that were never retrieved (the model hallucinated a plausible-looking source). **Optional second pass.** Beyond the structural check, a verifier can confirm that the cited document actually supports the claim. This is more expensive, often a smaller LLM acting as a judge, or sentence-level NLI matching, or simple string-overlap heuristics. The second pass catches the 'cited but unsupported' case, which is the next-stage failure when the structural check is the only rail. **What the rail prevents.** Overreliance (OWASP LLM09), the failure mode where the model produces fluent, confident text that sounds grounded in the retrieval set but is actually hallucinated. RAG does not eliminate hallucination; it reduces it. Models routinely fill in details that were not in the retrieved documents, especially when the retrieval was thin. The citation rail makes that failure visible: a claim without a citation is by definition unsupported by the retrieval. **Why attributability is the right property.** Truth-checking is hard and often impossible for the rail (legal claims depend on jurisdiction, medical claims depend on patient context, financial claims depend on date). Attributability is tractable: either there is a citation or there is not. And attributability is what downstream reviewers need.