LLM Output Verification Patterns - Grounding Checks, Self-Verification, Cross-Model Review, and Citation Enforcement

First Published: 2026-08-02
Last Updated: 2026-08-02

Every team that puts a language model in front of real users eventually arrives at the same question, and it is rarely the question they expected to be asking. It is not "which model is best" and it is not "how do we make the prompt better". It is narrower and much harder: for this specific output, on this specific request, can we say it is correct — and if we cannot, what do we do about it?

The reason this question is hard is that "wrong" is not one thing. An output can be malformed. It can be perfectly well formed and contradict the document it was supposed to summarize. It can be faithful to the document and still be false, because the document was wrong. It can be true, well formed, well grounded, and still ignore the instruction that said "answer in under fifty words and do not mention pricing". It can be true today and wrong next quarter. It can carry a citation that looks authoritative and points at a paper that does not exist.

These are six different failures, and they are not interchangeable. A JSON Schema validator catches the first one completely and the other five not at all. A grounding check catches the second one and can be actively misleading about the third. A second model reviewing the first one's work catches the fourth reasonably well and shares the first model's blind spots on the rest. There is no single verification technique that covers the space, which means the practical question is never "which verifier should I use" but "which combination, in what order, against which failure".

This article is a map of that space. It organizes verification into five machine layers plus a human layer, and for each layer it states two things with equal weight: what the layer catches, and what the layer is structurally incapable of catching. That second half is the part most treatments leave out, and it is the part that determines whether a verification stack actually reduces risk or merely produces reassuring green checkmarks.

1. Introduction

1.1 Who this is for

This article is written for engineers and architects who already run at least one generative AI feature in production and now need to justify its outputs to someone — a compliance reviewer, a customer, an incident postmortem, or their own on-call rotation. It assumes you have already shipped something and have started to notice that "it usually works" is not an answer anyone accepts twice.

It does not assume any particular model provider, framework, or cloud. Where a concrete implementation helps make a pattern legible, examples are drawn in parallel from several providers rather than from one, and provider-specific depth is delegated to dedicated articles rather than reproduced here.

1.2 What this article covers, and what it deliberately does not

In scope: a taxonomy of output errors; five layers of machine verification and one human layer; what each layer detects and what it cannot; how to select a combination given an error profile, a risk level, and a latency budget; how to evaluate the verification stack itself; and the failure modes that make verification stacks decorative rather than load-bearing.

Out of scope, deliberately:

Retrieval quality engineering. Chunking, hybrid search, reranking, and metadata filtering determine whether the right evidence is in context at all. That is upstream of verification and is covered in Amazon Bedrock Knowledge Bases Retrieval Quality Engineering.
Managed evaluation features. Running evaluation jobs, configuring built-in metrics, and wiring evaluation into a specific cloud's tooling is a distinct topic; see Amazon Bedrock Model Evaluation Practical Guide and Amazon Bedrock AgentCore Evaluations Practical Guide.
Safety and policy filtering. Blocking harmful content is a different objective from establishing correctness, and conflating the two produces a stack that does neither well. See Responsible AI Guardrails Architecture on AWS and Amazon Bedrock Guardrails Implementation Deep Dive.
Prompt engineering technique catalogs. The history and lineage of prompting methods is covered in RAG and Prompting Techniques History and Timeline.
Model comparison, leaderboard scores, and pricing. No benchmark numbers appear in this article. Where a paper's finding is referenced, it is attributed to that paper as a claim, and the numeric result is deliberately not transcribed — scores move with model versions and evaluation harnesses, and a number copied into a blog post outlives its validity almost immediately.

1.3 A note on sources and dates

Every research method referenced here is cited to its original arXiv preprint, using the v1 submission date rather than the latest revision date, so that the chronology of ideas is stable regardless of when a paper was last updated. Provider API behavior is cited to the vendor's own current documentation. Both categories were checked on 2026-07-31, which is the confirmation date for every specification detail in this article.

This matters more than usual for this topic. Structured output APIs, citation APIs, and constrained decoding support are all areas where the surface changed materially over the last two years and continues to change. Treat every API-level detail below as accurate as of the confirmation date and verify against current documentation before building on it.

2. What "Wrong Output" Actually Means

2.1 Six failure types

Verification design starts to make sense the moment you stop treating "hallucination" as a single phenomenon. The word is used, in practice, for at least six distinct failures that have different causes, different detection strategies, and different consequences.

The table below is the taxonomy the rest of this article uses. The identifiers (F1 through F6) are labels for this article's convenience, not established terminology.
* You can sort the table by clicking on the column name.

ID	Failure type	Definition	Concrete example
F1	Fabricated fact	A claim that is false about the world, and for which the supplied context offers no support either way	An invented product limit for a service the model was never given documentation for
F2	Ungrounded claim	A claim that contradicts the supplied sources, or is simply absent from them. The claim may happen to be true in the world; it is still unsupported by what was retrieved	A summary that states a contract's termination period as ninety days when the contract says sixty
F3	Format violation	Output that does not conform to the required schema, type, or enumeration	A missing required field, or a free-text status where an enum was required
F4	Instruction deviation	Output that satisfies the schema but ignores a stated constraint on length, tone, exclusions, or required sections	A response that is valid JSON, factually correct, and four times the requested length
F5	Stale information	A claim that was correct at training time or at retrieval time and is no longer correct	A quoted quota that was accurate when the document was indexed and has since been raised
F6	Bad citation	A reference that does not exist, or that exists but does not support the sentence attached to it	A plausible-looking paper title with real authors that was never written, or a real paper cited for a claim it does not make

The distinction between F1 and F2 is the one most worth internalizing, because it determines which verification layer can help you at all. F1 is a claim about the world with nothing in context to check it against. F2 is a claim that disagrees with something you supplied. Only F2 is checkable without reaching outside the request. This is why retrieval-augmented systems are easier to verify than open-ended ones: they convert a portion of F1 into F2, and F2 is tractable.

The distinction between F2 and F5 is the one that bites in production. A grounding check compares the output to the sources. If the sources are stale, a perfectly faithful output is confidently wrong, and the grounding check reports success. Grounding verifies faithfulness to the evidence, not truth. Systems that conflate the two develop a specific, dangerous failure mode: high measured groundedness alongside a steady trickle of user-visible errors that nobody's dashboard explains.

2.2 Why the model produces these at all

It is worth being precise about the underlying cause, because the framing affects what you expect verification to achieve.

The paper "Why Language Models Hallucinate" (Kalai et al., arXiv v1 2025-09-04) argues that hallucination is not primarily a mysterious defect but a predictable consequence of how models are trained and evaluated — the authors frame it in terms of training and evaluation procedures that reward confident guessing over acknowledged uncertainty. Separately, "Hallucination is Inevitable: An Innate Limitation of Large Language Models" (Xu et al., arXiv v1 2024-01-22) presents a formal argument that hallucination cannot be entirely eliminated.

Both framings point the same practical direction, and it is the premise of this entire article: the objective is not a model that never produces wrong output. The objective is a system that detects wrong output at a rate proportional to the cost of letting it through. That reframing is what makes verification an engineering problem with tractable trade-offs rather than a research problem waiting on a better model.

2.3 The layers, and the mapping

Verification techniques sort naturally into five machine layers plus a human layer, ordered roughly by cost and by how much of the world they need access to.

Verification Layers - Layer 1 Structural, Layer 2 Grounding, Layer 3 Self-Verification, Layer 4 External, and Layer 5 Cross-Model Review, each annotated with what it catches and what it is blind to, followed by Human Review.

The same content as a mapping between failure types and layers is below. This table is the working core of the article: sections 3 through 8 expand one row each, and section 9 turns it into a selection procedure.
* You can sort the table by clicking on the column name.

Layer	Catches	Structurally cannot catch	Why not
L1 Structural	F3	F1, F2, F4, F5, F6	Operates on shape, never on meaning. A schema-valid value is not a correct value
L2 Grounding	F2, F6, and F1 to the extent the sources speak to it	Errors carried by the sources themselves, F4, F1 where sources are silent	Measures agreement with supplied evidence, not truth
L3 Self-Verification	Claims that are unstable across samples, some F4	Confidently held systematic errors, F5	A consistent wrong belief is consistent; consistency cannot distinguish it from a consistent right one
L4 External	F1 and F5 for claims a tool can adjudicate	Claims no tool can settle; adds the tool's own error surface	Verification is delegated to the tool, and inherits its correctness and freshness
L5 Cross-Model	F4, holistic quality, partially F1	Blind spots shared with the generator	The reviewer is another generator, with correlated failure modes
Human	Anything, in principle	Whatever reviewer throughput and expertise do not allow	The binding constraint is capacity, not capability

Two properties of this table are worth stating explicitly before the detail sections.

First, the layers are not a pipeline where later stages subsume earlier ones. Layer 5 does not "include" Layer 1. A model reviewing another model's output is unreliable at spotting a subtly malformed enum value, which a schema validator catches with certainty and negligible cost. Cheap deterministic checks are not a lesser version of expensive probabilistic ones; they are strictly better at their own job.

Second, the "cannot catch" column is not a list of current limitations awaiting better tooling. These are consequences of what each layer has access to. A grounding checker that only sees the retrieved documents cannot know the documents are out of date, no matter how good it gets. Designing around that is the work.

3. Layer 1 — Structural Verification

3.1 What this layer is

Structural verification asks a single question with a definite answer: does this output conform to the declared shape? Shape means the JSON Schema, the type of each field, the permitted values of each enumeration, the presence of required properties, and any grammar the output must parse against.

This is the only layer in the article that is decidable. Every other layer produces a judgment that could be wrong. A schema validator produces a fact. That property is the reason this layer belongs first: it is the cheapest check, it never returns a false positive on a genuinely conformant output, and it removes an entire failure class from consideration so that later layers can spend their budget on meaning.

3.2 Three implementation strategies

There are three distinct ways to obtain structural conformance, and they differ in where enforcement happens.

Validate after generation. The model produces free text, your code parses and validates it against a schema, and invalid output triggers a retry. Universally available, requires no provider support, and costs a full regeneration on every failure.
Constrain during decoding. The sampler is restricted at each step so that only tokens keeping the output within the grammar can be selected. Malformed output becomes unrepresentable rather than merely detectable. "Efficient Guided Generation for Large Language Models" (Willard and Louf, arXiv v1 2023-07-19) frames guided generation as transitions over a finite-state machine built from the schema or regular expression, which is what makes per-token masking cheap enough to be practical. "Grammar-Constrained Decoding for Structured NLP Tasks without Finetuning" (Geng et al., arXiv v1 2023-05-23) applies the same idea to general formal grammars, and XGrammar (Dong et al., arXiv v1 2024-11-22) addresses the engine-level efficiency of structured generation.
Delegate to the provider. Several APIs now accept a schema and take responsibility for conformance server-side, which is constrained decoding operated by the provider.

On the provider-delegated route, the surface is broadly similar and the details differ in ways that matter. As of the confirmation date:

Anthropic exposes structured outputs through output_config.format with a json_schema, and separately supports strict: true on a tool definition to guarantee that tool inputs validate. Strict tool schemas require additionalProperties: false together with an explicit required list. The supported JSON Schema subset excludes recursive schemas, numeric constraints such as minimum and multipleOf, and string constraints such as minLength. New schemas incur a one-time compilation cost on first use, with subsequent requests served from a cache.
OpenAI requires strict: true alongside the schema, and its documentation lists allOf, not, dependentRequired, dependentSchemas, if, then, and else as unsupported, with anyOf additionally disallowed at the root.
Google documents a JSON Schema subset for structured output and notes that very large or deeply nested schemas may be rejected.

The practical consequence of all three lists is the same and is easy to miss during design: the constraints you can express in a schema are a subset of the constraints you care about. If your requirement is "an integer between 1 and 100", the schema layer on at least one major provider will give you "an integer" and leave the range to you. Range checks, cross-field consistency, and referential integrity belong in your own validation code regardless of what the provider enforces.

3.3 What this layer cannot catch

Everything that is not shape. This is worth spelling out because provider marketing language around structured outputs is easy to over-read.

OpenAI's own documentation states the boundary plainly: structured outputs ensure the model generates responses adhering to the supplied schema, and that adherence applies to format compliance only — the feature does not guarantee factual accuracy or the semantic validity of the values generated. That is an accurate description of every implementation of this layer, from every provider, and of hand-rolled post-validation too.

Concretely, a schema-valid output can still be entirely wrong:

{
  "contract_id": "C-2024-0417",
  "termination_notice_days": 90,
  "governing_law": "Delaware",
  "confidence": "high"
}

Every field conforms. termination_notice_days may still be 60 in the actual contract (F2). governing_law may be invented (F1). The confidence enum is especially treacherous: it is schema-valid by construction, carries no calibration guarantee whatsoever, and reliably gets consumed downstream as though it did.

There is also a subtler cost worth weighing. Constraining decoding modifies the distribution the model samples from. When a model would otherwise have declined, hedged, or produced a shape the schema does not permit, forcing conformance can convert an honest non-answer into a confident fabrication that validates cleanly. On some APIs a safety refusal is surfaced through a distinct field or stop reason precisely so that a refusal is not silently coerced into schema-shaped nonsense — check for it before parsing, rather than after.

A related and easily missed interaction: on Anthropic's API, enabling citations on a document block is incompatible with output_config.format and returns a 400. That is not an arbitrary restriction; it reflects a genuine tension between "the response must be exactly this JSON object" and "the response must be decomposed into spans that carry provenance". Section 4.4 returns to this, because it shapes how Layer 1 and Layer 2 can be combined in a single call.

4. Layer 2 — Grounding Verification

4.1 What this layer is

Grounding verification asks whether each claim in the output is supported by the evidence supplied to the model. It is the highest-value layer for any system that retrieves documents before answering, and it is the layer most often skipped in pattern-oriented treatments of this topic — which is unfortunate, because it is where most production error budget actually goes.

The formulation that made this measurable is "Measuring Attribution in Natural Language Generation Models" (Rashkin et al., arXiv v1 2021-12-23), which introduced Attributable to Identified Sources as a framework for asking whether a generated statement is supported by a designated source. The key move is to make attribution a property of a statement-source pair, judged by whether a reasonable reader would agree the source supports the statement. That turns a vague notion of "grounded" into something with an evaluation protocol.

Two early systems demonstrated that models could be built to produce attributable output rather than have it checked afterward: WebGPT (Nakano et al., arXiv v1 2021-12-17) had the model browse and collect references while answering, and "Teaching language models to support answers with verified quotes" (Menick et al., arXiv v1 2022-03-21) trained models to accompany claims with supporting quotes. The design lesson carried forward: it is far easier to verify attribution when the generation step was asked to produce it than when you try to reconstruct it afterward.

4.2 Entailment-based consistency checking

The workhorse technique is natural language inference. Treat the source passage as the premise, the generated sentence as the hypothesis, and ask whether the premise entails the hypothesis. Not entailed means unsupported, which is exactly F2.

The lineage here is worth knowing, because it explains why modern implementations look the way they do:

SummaC (Laban et al., arXiv v1 2021-11-18) revisited NLI models for inconsistency detection and showed that operating at sentence-level granularity rather than document-level was the change that made NLI models effective for this task. Document-level NLI had underperformed largely because of the granularity mismatch.
TRUE (Honovich et al., arXiv v1 2022-04-11) re-examined factual consistency evaluation across a range of tasks and standardized the comparison, making it possible to talk about consistency metrics without task-specific caveats swamping the discussion.
AlignScore (Zha et al., arXiv v1 2023-05-26) proposed a unified alignment function trained across multiple task formats, so that one function serves summarization, question answering, and fact verification rather than needing a per-task metric.
MiniCheck (Tang et al., arXiv v1 2024-04-16) addressed the operational problem directly: checking every sentence of every response against grounding documents with a large model is expensive, and the paper targets efficient fact-checking on grounding documents at smaller model sizes.

That last point is the one that governs architecture. Grounding checks run on every sentence of every response, which makes them the highest-volume verification you will operate. A checker that costs as much as the generator doubles your inference budget for the entire product. This is the principal reason grounding verification is usually implemented with a small dedicated model rather than by asking a frontier model "is this supported?".

4.3 Decomposition into atomic claims

A long response is not one claim; it is dozens, mixed together, of which perhaps two are wrong. Judging the response as a whole discards that structure and produces a verdict that is useless for repair.

FActScore (Min et al., arXiv v1 2023-05-23) formalized the alternative: break long-form generation into atomic facts, verify each independently against a knowledge source, and treat factual precision as a property of the set. The operational payoff is not the aggregate figure — it is that you now know which sentence failed, which is what makes automated repair possible instead of blanket regeneration.

For retrieval systems specifically, RAGAS (Es et al., arXiv v1 2023-09-26) proposed a reference-free evaluation framework for retrieval-augmented generation, decomposing quality into separately measurable dimensions rather than a single score. The separation that matters architecturally is between retrieval quality and generation faithfulness: if the right passage was never retrieved, no amount of grounding verification on the generation step will help, and the fix belongs entirely upstream. Diagnosing which of the two is failing is the first thing to do when groundedness drops, and it is covered in depth in Amazon Bedrock Knowledge Bases Retrieval Quality Engineering.

Verification can also be pulled into generation rather than bolted on after it. Self-RAG (Asai et al., arXiv v1 2023-10-17) trains a model to emit reflection tokens that decide when to retrieve and critique what was retrieved, making retrieval and self-assessment part of the generation loop. A decoding-time variant of the same instinct is context-aware decoding (Shi et al., arXiv v1 2023-05-24), which amplifies the difference between the model's output distribution with and without the supplied context, pushing generation toward the evidence rather than toward parametric priors.

4.4 Citation enforcement

Citations turn grounding from an internal metric into something the user can audit. They also introduce F6, a failure type that does not otherwise exist: a citation can be fabricated outright, or it can be real and attached to a claim it does not support. The second is more dangerous, because it survives any check that merely confirms the reference exists.

"Enabling Large Language Models to Generate Text with Citations" (Gao et al., arXiv v1 2023-05-24), which introduced the ALCE benchmark, established the evaluation shape that matters: citation quality has to be assessed on both recall (is every claim that needs support actually cited) and precision (does each cited passage actually support the claim it is attached to). Checking only that citations exist measures neither. "Automatic Evaluation of Attribution by Large Language Models" (Yue et al., arXiv v1 2023-05-10) examines using models to perform that attribution judgment automatically, which is what makes continuous checking feasible.

On the implementation side, the strongest available guarantee comes from APIs that emit citations as structured metadata rather than as text the model writes. Anthropic's citations feature is the clearest current example: enabling citations on document blocks causes the response to be split into multiple text blocks, where cited blocks carry a citations array. Each citation carries the cited_text, a document_index, a document_title, and a location whose type depends on the source — char_location with start and end character indices for plain text, page_location with one-indexed page numbers for PDFs, or content_block_location for custom content. Citations must be enabled on all document blocks in a request or none.

The architectural significance is that the span is emitted by the API rather than transcribed by the model, which eliminates fabricated citations by construction: there is no text-generation step in which a plausible-but-nonexistent reference could be produced. F6 does not disappear entirely — the model can still attach a genuine span to a claim the span does not actually support — but the fabrication half of F6 is closed off structurally rather than checked probabilistically.

This is also where the constraint flagged in section 3.3 becomes a design decision rather than a footnote. On that API, citations and output_config.format cannot be used in the same request. If your feature needs both machine-checkable structure and API-emitted provenance, you have three options, and it is worth choosing deliberately rather than discovering the constraint late:

Two calls. Generate the cited prose first, then extract structure from it in a second call. Costs an extra round trip; keeps both guarantees intact.
Citations plus your own parsing. Take the cited output and validate structure with your own code rather than the provider's schema enforcement. Keeps provenance; downgrades Layer 1 from guaranteed to checked.
Structure plus your own grounding check. Take the schema-enforced output and run an entailment check against the sources yourself. Keeps the schema guarantee; makes grounding probabilistic rather than span-exact.

There is no universally correct answer. For a regulated summarization workflow where a reviewer must trace every assertion, option 1 or 2 is usually right. For a structured extraction pipeline feeding a database, option 3 usually is.

4.5 What this layer cannot catch

Three blind spots, each of which has produced real production incidents.

Errors in the sources. Grounding measures agreement with supplied evidence. If the evidence is wrong, a faithful output is wrong and the check reports success. This is the F2-versus-F5 distinction from section 2.1, and it is the single most common way a grounding-verified system produces confident errors. Source freshness is a data pipeline concern, not a verification concern, and no amount of investment in the checker addresses it.

Instruction deviation. A response can be perfectly grounded in every sentence and still ignore every formatting, length, and scope instruction it was given. F4 is invisible to this layer.

Claims the sources are silent about. When the retrieved documents say nothing relevant, an entailment checker returns "not supported" for both a fabrication and a true statement the model happened to know. Treating "not supported" as "false" produces false positives on correct output; treating it as "unknown" leaves F1 unhandled. Which of those you prefer is a policy decision that belongs in your escalation design, not a detail you can leave to the checker's default.

One further caution: the checker is itself a model making a judgment. Entailment decisions on long or technical passages are not reliable in the way a schema validator is. A grounding score is evidence, not proof, and section 10 covers how to establish how much weight it deserves.

5. Layer 3 — Self-Verification

5.1 What this layer is

Self-verification uses the generating model, or another instance of it, to examine its own output without external evidence. It is the layer available when there is no source of truth in context and no tool that can adjudicate — which describes a great deal of real usage.

The techniques divide into two families that are frequently conflated and behave very differently: sampling-based consistency, which exploits variance across independent generations, and critique-based revision, which asks the model to review and improve a draft. The evidence for these two is not equally strong, and the distinction matters.

5.2 Sampling-based consistency

The premise is simple and, unusually for this field, robust: content the model is confident about tends to be stable across independent samples, while fabricated content tends to vary.

"Self-Consistency Improves Chain of Thought Reasoning in Language Models" (Wang et al., arXiv v1 2022-03-21) established the pattern for tasks with an extractable final answer: sample several reasoning paths rather than taking one greedily, then marginalize over the paths and select the most consistent answer. The constraint is that it requires an answer you can compare for equality, which limits it to tasks with a discrete result. Universal Self-Consistency (Chen et al., arXiv v1 2023-11-29) removes that constraint by having the model itself select the most consistent response among candidates, extending the idea to free-form generation.

SelfCheckGPT (Manakul et al., arXiv v1 2023-03-15) turns the same observation into a detector rather than a selector. It is zero-resource and black-box — requiring neither an external database nor access to model internals — and works by sampling multiple responses and measuring consistency among them, on the premise that hallucinated content diverges across samples while grounded content does not.

The operational property to plan around is cost. This family requires N independent generations where N is typically small but greater than one, and the latency floor is the slowest sample unless you parallelize. It is the most expensive family in this article per unit of output, which places it firmly in the "use where it is warranted" category rather than as a default.

5.3 Critique-based revision

The second family asks the model to review its own draft and improve it.

Self-Refine (Madaan et al., arXiv v1 2023-03-30) describes iterative refinement in which the same model generates, provides feedback on its own output, and revises, without supervised training data for the feedback step. Chain-of-Verification (Dhuliawala et al., arXiv v1 2023-09-20) is more structured and, for verification purposes, more interesting: the model drafts a response, plans verification questions, answers those questions independently, and then generates a final verified response. The independence of the verification step is the load-bearing design element — answering the verification questions without conditioning on the draft is what prevents the draft's errors from propagating into their own confirmation.

That design detail generalizes into the most useful rule in this section. A verification step that can see the draft tends to ratify it. Whenever you build self-verification, isolate the check from the artifact being checked as far as the task allows.

5.4 What this layer cannot catch, and the strongest caveat in this article

Sampling-based consistency detects instability, not falsehood. A model that confidently and consistently holds a wrong belief produces that belief in every sample, and consistency-based detection reports high confidence. This is not a tuning problem; the signal simply is not present. Systematic errors — a misremembered API name, an outdated default value, a widespread misconception in the training data — are exactly the errors this layer is worst at and exactly the errors that occur most often in technical domains.

For critique-based revision, the caveat is stronger and deserves to be stated without hedging. "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., arXiv v1 2023-10-03) examines intrinsic self-correction — self-correction without external feedback — and reports that models struggle to correct their own reasoning in that setting, with performance in some cases degrading after self-correction. The paper's framing is directly relevant to production design: results that look like successful self-correction often depend on external signals, such as oracle labels indicating when to stop, that are unavailable at inference time.

The practical reading is not that self-verification is useless. It is that self-correction driven by external feedback is a different mechanism from self-correction driven by introspection alone, and only the first has a solid basis. If a check has an external signal to work with — a compiler error, a failing test, a retrieved passage, a tool result — feed it in. If it does not, treat the outcome as weak evidence and do not build a gate on it.

There is one genuinely intrinsic signal worth knowing about. "Language Models (Mostly) Know What They Know" (Kadavath et al., arXiv v1 2022-07-11) studies whether models can evaluate the probability that their own answers are correct, and finds self-evaluation is meaningful under the right conditions. That is a real capability, but note the qualifier in the paper's own title, and note that a confidence field in a JSON schema is not this — a self-reported confidence string in structured output has no calibration guarantee unless you have measured it yourself on your own distribution.

6. Layer 4 — External Verification

6.1 What this layer is

External verification hands the question to something that is not a language model. A calculator settles arithmetic. An interpreter settles whether code runs. A database settles whether an order ID exists. A search settles whether a document says what was claimed.

This is the only layer that can establish that a claim is true rather than merely well-formed, well-supported, or stable. Layers 1 through 3 all operate within the boundary of the request; this one reaches outside it.

6.2 Computation and code as verification

PAL (Gao et al., arXiv v1 2022-11-18) established the pattern of having the model produce a program that expresses the reasoning and delegating execution to an interpreter, so the model supplies the formulation and the runtime supplies the answer. The verification consequence is that arithmetic and logical steps stop being generated text subject to F1 and become executed operations with a definite result.

For code generation specifically, this layer is unusually strong, because the verifier is the same artifact the user cares about. Compilation, type checking, linting, and a test suite together constitute an external verifier that is precise, fast, and already in your build system. Any code-producing feature that does not execute its own output is leaving the cheapest high-signal verification on the table.

Reasoning chains can be verified at the step level too. "Training Verifiers to Solve Math Word Problems" (Cobbe et al., arXiv v1 2021-10-27) introduced training a separate verifier to judge candidate solutions rather than trusting the generator, and "Let's Verify Step by Step" (Lightman et al., arXiv v1 2023-05-31) compares supervising each reasoning step against supervising only the final outcome. "A Chain-of-Thought Is as Strong as Its Weakest Link" (Jacovi et al., arXiv v1 2024-02-01) makes the operational point in its title: a chain whose conclusion is right by way of an invalid step is not a chain you should trust, and evaluating only the final answer cannot tell the difference.

6.3 Retrieval and tool use as verification

ReAct (Yao et al., arXiv v1 2022-10-06) established interleaving reasoning traces with task-specific actions, which is the structural basis for a model that checks as it goes rather than producing a complete answer and hoping. FacTool (Chern et al., arXiv v1 2023-07-25) applies tool augmentation specifically to factuality detection across several task types.

RARR (Gao et al., arXiv v1 2022-10-17) is worth separate attention because it targets a scenario the other patterns do not: output that already exists. It researches and revises generated text after the fact, attributing claims to retrieved evidence and editing to fix unsupported ones while preserving the original as much as possible. That last property is what makes it a repair strategy rather than a regeneration strategy, and repair is usually the better option — regeneration discards the parts that were correct and re-rolls the dice on all of them.

Tool interfaces are the practical mechanism. All major providers expose tool or function calling; a verification tool is an ordinary tool whose job is to return a fact rather than perform an action. Protocol-level history and the interoperability picture are covered in Tool Use and Agent Protocol History and Timeline.

6.4 What this layer cannot catch

Claims no tool can settle. "Is this summary appropriately balanced" has no oracle. Attempting to build one produces a Layer 5 judge wearing a Layer 4 costume, with Layer 5's reliability characteristics and Layer 4's misplaced air of authority.

The tool's own errors. Verification is delegated, and delegation transfers trust. A stale replica, a mis-scoped query, a subtly wrong unit conversion — each produces a confident verification verdict that is wrong. This layer does not eliminate the trust problem; it moves it somewhere you can apply conventional engineering to, which is a real gain but not the same as elimination.

Cost and latency. External calls are the slowest verification in the stack and the only one that can fail independently. A verification path that calls three services has three new availability dependencies, and a verifier that is down must have a defined behavior — fail open, fail closed, or escalate. Choosing that behavior per check is part of the design, not an operational afterthought.

7. Layer 5 — Cross-Model and Judge Patterns

7.1 Scope of this section

Using a model to evaluate another model's output is a large topic with a substantial literature and several thorough dedicated treatments. This section deliberately does not attempt to be one of them. What it covers is the part that belongs in a layered map: where this layer sits relative to the other four, what it is uniquely good at, and the failure modes that determine whether it earns its place in a given stack. Judge prompt design, rubric construction, and scoring methodology are out of scope here.

7.2 What it is uniquely good at

"Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" (Zheng et al., arXiv v1 2023-06-09) is the standard reference for the approach and, usefully, examines the method's limitations alongside its agreement with human preference. G-Eval (Liu et al., arXiv v1 2023-03-29) develops evaluation of generated text using chain-of-thought and a form-filling paradigm.

Positioned against the other layers, this one's distinctive contribution is narrow but real. It is the only layer that handles F4. No schema validator can tell you the response ignored "keep it under fifty words and do not mention pricing". No grounding checker cares. No tool adjudicates it. Asking a second model whether the output complied with a stated instruction is the practical option, and for that specific job it works well — instruction compliance is a comparison between two pieces of text, which is a task models are genuinely good at.

It is also the only layer that evaluates holistic properties — coherence, tone, appropriate structure, whether the response actually answered what was asked. These resist decomposition into checkable claims, which is precisely why the other four layers cannot touch them.

Two variants extend the basic pattern. "Improving Factuality and Reasoning in Language Models through Multiagent Debate" (Du et al., arXiv v1 2023-05-23) has multiple instances argue toward a converged answer rather than issuing independent verdicts. Constitutional AI (Bai et al., arXiv v1 2022-12-15) uses an explicit set of written principles for critique and revision, which has an underrated operational benefit: the principles are a text artifact you can version, review, and diff, rather than a judgment buried in a prompt.

7.3 What this layer cannot catch, and the biases that matter

The reviewer is another generator. Where the reviewer shares the generator's architecture, training data, or model family, it tends to share its blind spots. A confidently wrong claim produced by one model is disproportionately likely to be accepted by a sibling model, which means cross-model review is most valuable when the models are genuinely different and weakest in the configuration teams most often deploy, which is the same model reviewing itself.

Three documented biases determine whether a judge's verdict means anything:

Position bias. "Large Language Models are not Fair Evaluators" (Wang et al., arXiv v1 2023-05-29) reports that the order in which candidate responses are presented can change the verdict, and proposes calibration strategies to address it. If you run pairwise comparisons without swapping order and aggregating, some fraction of your verdicts are an artifact of presentation order.
Self-preference. "LLM Evaluators Recognize and Favor Their Own Generations" (Panickssery et al., arXiv v1 2024-04-15) examines evaluators favoring text they produced themselves. This has a direct architectural consequence: a model judging its own output is not an independent check, and reporting it as one overstates the assurance the stack provides.
Verbosity and presentation effects. Discussed in the MT-Bench work above — judges can be influenced by length and surface form in ways that do not track the quality being assessed.

Each of these has a mitigation, and none of the mitigations is free: swapping and aggregating order doubles the calls; using a different model family adds a provider dependency; controlling for verbosity requires a rubric that names it explicitly. The honest summary is that this layer is useful for what only it can do, and a poor substitute for layers 1 through 4 where those apply. A judge asked to assess factual accuracy against a document is doing Layer 2's job worse and more expensively than an entailment checker would.

8. Human-in-the-Loop Placement

8.1 The pipeline shape

Machine verification produces a verdict. What the system does with that verdict — deliver, repair, regenerate, or escalate — is where verification becomes an architecture rather than a metric.

A Verification Pipeline - generate a candidate output, run the verification stack, branch on whether all required checks pass, deliver on pass, and on failure classify the failure into recoverable repair or regeneration with a retry budget, or escalation to a human.

Three properties of this shape are load-bearing and are the ones most often missing from real implementations.

Failures are classified before they are handled. A schema violation and an ungrounded claim are both "fail", and they call for completely different responses. The first is often repairable by re-prompting with the validation error attached. The second may indicate the retrieval step failed, in which case regenerating with the same context will fail identically. Classification is what makes the branch meaningful.

The retry loop has a budget. Regeneration without a bounded retry count is how a verification stack turns a wrong answer into an outage. The budget should be small — and when it is exhausted, the path is escalation, not delivery.

Escalation is a real path with a real destination. If "escalate to a human" resolves to a queue nobody reads, the system's effective behavior on unverifiable output is to drop it silently. That is sometimes the correct product decision, but it should be a decision, made explicitly, rather than the emergent result of an unstaffed queue.

8.2 Deciding what reaches a person

Human review is the only layer that can catch anything, and the only one whose capacity is fixed in the short term. Everything about its placement follows from that asymmetry: the design problem is not "how do we get humans to check the output" but "given that humans can check a small fraction of it, which fraction".

Three placements, which compose:

Gate. Nothing is delivered without review. Appropriate where the action is irreversible or externally binding — a payment, a filing, a message sent under the organization's name. The throughput ceiling is the reviewer pool, and the design question is how far machine verification can shrink each review, not whether it can eliminate it.
Escalation. Only outputs that fail machine verification, or that verification flags as uncertain, reach a person. This is the default for most systems and the one the pipeline above describes. Its quality depends entirely on the false-negative rate of the machine layers, because anything they wrongly pass never reaches the human.
Sampling. A random fraction of passing output is reviewed regardless. This is the only mechanism that measures the false-negative rate, and it is the one most often omitted — which leaves teams with no way to know how much escaped. Section 10 develops this.

Risk tiering is the usual way to allocate the fixed capacity. Tie the tier to the consequence of a wrong output reaching a user, not to the model's reported confidence:
* You can sort the table by clicking on the column name.

Risk tier	Characteristic	Human placement	Machine layers
Irreversible	External commitment, regulated action, or a change that cannot be undone	Gate on every output	All applicable, to shorten review
High	User-visible and materially misleading if wrong; correction is costly	Escalation plus sampling	L1, L2, and L4 where a tool applies
Moderate	User-visible, correctable, bounded consequence	Escalation only	L1 and L2
Low	Internal, exploratory, or trivially correctable by the user	Sampling only	L1

Public risk management frameworks are a reasonable anchor for making these tiers defensible to people outside the engineering team. The NIST AI Risk Management Framework provides vocabulary for describing how risks are mapped, measured, and managed, which is useful when a tiering decision has to survive a conversation with compliance rather than only with engineers.

9. Choosing a Verification Stack

9.1 Start from the error profile, not the technique

The most common way to get this wrong is to start from a technique — someone read about LLM-as-a-judge, so a judge gets added — and then look for something for it to do. The result is a stack that is expensive, slow, and misaligned with the failures the system actually produces.

The order that works is:

Determine which failure types this feature can actually produce. An extraction pipeline over supplied documents produces F2, F3, and F6, and essentially cannot produce F1 because it is never asked to know anything. An open-ended assistant produces all six.
Establish the consequence of each type reaching a user. For the extraction pipeline, F3 breaks the downstream consumer loudly and F2 corrupts data silently — so F2 is the more dangerous failure despite being less visible.
Select the cheapest layer that covers each type you care about, using the mapping in section 2.3.
Check the latency budget, and cut from the most expensive layer down until it fits.

Step 4 is where the design becomes real, because verification is not free and the cost is structural rather than incidental.

9.2 The cost of each layer

Measured in additional inference passes and added dependencies rather than in currency, since the former is stable and the latter is not:
* You can sort the table by clicking on the column name.

Layer	Additional inference	Added latency	New failure dependencies
L1 Structural	None, or one retry on failure	Negligible	None
L2 Grounding	One check per claim, typically on a small model	Low to moderate; scales with response length	The checker model
L3 Self-Verification	N samples, or draft plus verification questions plus final	High; the floor is the slowest sample	None beyond the generator
L4 External	Varies; often none, but one call per tool	Bounded by the slowest external service	Every service called
L5 Cross-Model	One per judgment, doubled if debiasing order	Moderate to high	The judge model, and a second provider if cross-family
Human	None	Minutes to days	Reviewer availability

Two orderings follow directly and are worth treating as defaults.

Run cheap deterministic checks first. If Layer 1 rejects the output, no other layer needs to run. Putting a judge ahead of a schema validator means paying for a model call to evaluate output that was going to be discarded anyway.

Prefer a small specialized checker to a large general one. Grounding verification is per-claim and therefore the highest-volume check in most stacks. The efficiency motivation behind work like MiniCheck exists precisely because this is the check that scales with usage.

9.3 The selection table

Combining error profile, risk tier, and latency budget:
* You can sort the table by clicking on the column name.

If the dominant failure is	And risk is	Then the stack is	Because
F3 Format	Any	L1 alone, provider-enforced where available	Decidable, cheap, complete for this type
F2 Ungrounded	Moderate	L1 plus L2 entailment on a small model	Highest coverage per unit cost for retrieval systems
F2 Ungrounded	High or irreversible	L1 plus L2 with citation enforcement, plus human escalation	Provenance makes review fast enough to be affordable
F6 Bad citation	Any where citations are shown	API-emitted citation spans, not model-written references	Removes the fabrication half of F6 by construction
F1 Fabricated fact	Moderate, tool exists	L4 against the authoritative system	Only layer that establishes truth rather than support
F1 Fabricated fact	Moderate, no tool, latency available	L3 sampling consistency	Detects instability where no external check exists
F1 Fabricated fact	High, no tool	Human escalation; do not gate on L3 alone	Consistency cannot see confident systematic error
F4 Instruction deviation	Any	L5 with a rubric naming the constraints	The only layer that assesses compliance with instructions
F5 Stale information	Any	L4 live lookup, plus source freshness in the data pipeline	No verification layer can detect staleness in its own sources

The row that surprises people is the last one. Staleness is not a verification problem. If the answer depends on a value that changes, the fix is a live lookup at answer time or a freshness guarantee on the corpus. Adding verification layers on top of stale sources produces a system that is thoroughly verified and confidently out of date.

9.4 A worked example

Consider a support assistant that answers customer questions from a product documentation corpus and can look up the customer's own account state.

Error profile. F2 is the dominant risk, since answers are supposed to come from the documentation. F5 is significant because documentation lags releases. F1 is possible when documentation is silent and the model answers from parametric knowledge. F6 matters because the assistant shows source links. F3 is a non-issue for prose output. F4 matters mildly for tone and length.

Risk tier. Moderate for informational answers; high when the answer includes account-specific state, because a wrong account fact is both credible and consequential.

Resulting stack. Grounding verification on every generated sentence against the retrieved passages, using a small checker, with citation spans emitted by the API so the user can verify independently. Account state answered exclusively through a tool call to the authoritative system, never from retrieval or parametric memory — this is Layer 4 handling both F1 and F5 for the class of claims where they matter most. Sentences the grounding checker marks unsupported are not silently dropped; they trigger a regeneration constrained to the retrieved context, and a second failure escalates. No judge in the request path: F4 here is minor, and tone compliance is checked offline on sampled traffic rather than paid for on every request.

What is deliberately not covered. If documentation is wrong, the assistant will confidently repeat it. That risk is accepted and managed through documentation review rather than through the verification stack, because no layer available in the request path can detect it. Writing that down — in the design document, where the next engineer will find it — is more useful than adding a layer that appears to address it and does not.

10. Measuring Verification Itself

10.1 The verifier has its own error rates

Every layer except Layer 1 is a classifier, and every classifier has two error modes. It is worth being explicit about which one you are optimizing, because they trade against each other and their costs are wildly asymmetric in visibility.

False positive: verification rejects correct output. The cost is a wasted regeneration, added latency, or a reviewer's time spent on something that was fine. Highly visible — it shows up as retry rate, latency, and reviewer complaints.
False negative: verification passes incorrect output. The cost is a wrong answer reaching a user. Nearly invisible — by definition nothing in the system flagged it.

This asymmetry produces a predictable organizational failure. False positives generate pressure to loosen thresholds, because everyone can see them. False negatives generate no pressure at all, because nobody knows they happened. Left alone, thresholds drift toward permissiveness and the stack quietly becomes decorative — still running, still green, no longer catching anything.

The only remedy is to measure the invisible side deliberately. That requires the sampling path from section 8.2: review a random fraction of passing output. Without it, the false-negative rate is not merely unknown, it is unknowable, and any claim about the stack's effectiveness is unfounded.

10.2 What you need to measure it

A labeled set with known-bad outputs, which is harder to obtain than it sounds because organic bad outputs are rare enough that random sampling yields few. Three sources, in ascending order of usefulness:

Historical incidents. Every escaped error is a labeled example. The discipline is to capture the exact input and output at the moment it is reported rather than reconstructing it later.
Deliberate perturbation. Take verified-correct outputs and introduce specific defects — alter a number, swap an entity, add an unsupported sentence, attach a citation to the wrong claim. This gives per-failure-type coverage, which aggregate metrics cannot.
Human-labeled production samples. The most expensive and the most representative, because it reflects your real input distribution rather than your imagination of it.

Perturbation is underused and worth the effort. It is the only method that answers the question you actually need answered, which is not "how good is our verification" but "which failure type is our verification worst at". Aggregate accuracy hides exactly the information that would tell you what to fix.

10.3 Offline and online

Offline evaluation runs against a fixed dataset before deployment. It is reproducible, it gates changes, and its blind spot is that the dataset reflects the inputs you anticipated.

Online evaluation runs against production traffic. It catches distribution shift and the inputs nobody predicted, and it cannot use ground truth labels at request time, so it relies on proxy signals — verification pass rates by segment, escalation rates, user corrections, thumbs-down — plus the sampled human review that supplies real labels after the fact.

Both are necessary and they answer different questions. Offline answers "did this change make verification better on cases we know about". Online answers "is verification still working on the traffic we are getting now".

One trap specific to verification: a verifier calibrated against one generator can silently degrade when the generator changes. A model upgrade changes the distribution of errors the verifier sees, and thresholds tuned for the old distribution may be badly placed for the new one. Treat generator version changes as events that require re-validating the verification stack, in the same way a schema change requires re-validating a consumer. Managing model and prompt versions as first-class artifacts makes this tractable; see Prompt Lifecycle Management on AWS.

The instrumentation side of this — how to emit verification outcomes as spans and metrics, and which attribute conventions to use so the data is portable — is a topic of its own and is deliberately not covered here. See LLMOps Observability and Evaluation Architecture on AWS for an implementation-oriented treatment, and OpenTelemetry GenAI Semantic Conventions Implementation Guide for the vendor-neutral semantic conventions.

11. Failure Modes and Anti-Patterns

11.1 Verification theater

The most common failure is a stack that runs, reports, and changes nothing. Checks execute, scores are recorded, dashboards are green, and no output is ever blocked or escalated because the thresholds were set where nothing trips them.

The diagnostic question is direct: in the last month, what did verification actually prevent? If the answer is "nothing", either the generator is remarkable or the stack is decorative. The second is far more likely. A verification layer that has never rejected anything is not evidence of quality; it is an untested code path.

11.2 Trusting the judge

A judge's verdict is a model output, subject to the same failure types as any other model output. Treating a judge score as ground truth reintroduces at the verification layer exactly the problem verification was meant to solve.

This shows up concretely in two ways. Teams compute a judge score, observe it improve after a prompt change, and conclude quality improved — when the change may have shifted output toward what the judge favors. And teams gate on a judge score without ever measuring its agreement with human judgment on their own data, which means the gate's threshold is arbitrary.

The mitigation is unglamorous: periodically compare judge verdicts to human verdicts on the same samples, and treat the agreement rate as a property of your system that needs monitoring rather than a property of the technique that can be assumed.

11.3 Prompt injection into the verifier

This one is under-discussed and structurally serious. Verification layers read content, and in a retrieval system that content is frequently not fully trusted.

"Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection" (Greshake et al., arXiv v1 2023-02-23) describes how instructions embedded in retrieved content can influence a model that processes it. The observation that matters here is that this applies to the verifier just as it applies to the generator. A grounding checker reading a retrieved document, or a judge reading a generated response that itself incorporated untrusted content, is processing attacker-influenceable text with the authority to approve output.

A verifier that can be talked into approving is worse than no verifier, because it converts an unchecked path into a path that reports as checked. Practical mitigations are the ordinary ones — keep the verifier's instructions structurally separated from the content under review, constrain the verifier's output to a narrow decidable form so an injected instruction has no channel to express itself, and never let a verifier's output be interpreted as anything other than a verdict. Defense-in-depth for the surrounding system is covered in AI Agent Defense in Depth Model, and output-side detection for sensitive data in PII Detection and Redaction Patterns for Generative AI on AWS.

11.4 Evidence placement in long contexts

Grounding verification against a large evidence set runs into a positional effect. "Lost in the Middle: How Language Models Use Long Contexts" (Liu et al., arXiv v1 2023-07-06) reports that model performance depends on where relevant information sits within the input context, and degrades when it must be retrieved from the middle of long contexts.

The verification consequence: passing an entire retrieved corpus as the premise for an entailment check is less reliable than passing the specific passage relevant to the specific claim. Decomposition — the FActScore-style approach in section 4.3 — helps here for a reason beyond diagnostic granularity: it keeps each individual check short.

11.5 Double inference and the latency budget

Every verification layer that calls a model adds at least one inference pass. Self-consistency adds several. A stack with grounding checks, a judge, and retry-on-failure can multiply the latency of a request by a factor that makes an interactive feature unusable.

Three mitigations, in order of preference: run cheap deterministic checks first so expensive ones are skipped on already-failing output; run independent checks in parallel rather than in sequence, since most verification layers do not depend on each other's results; and move checks that do not need to gate the response out of the request path entirely, running them asynchronously on sampled traffic. The third is underused — a check that informs your understanding of quality does not need to block a user, and a check that must block a user should be one you are prepared to pay for on every request.

11.6 Regeneration without classification

Retrying a failed generation with the same prompt and the same context, hoping for a different result, wastes the information the verification step produced. If the schema validator says a field is missing, that error belongs in the retry prompt. If the grounding checker identified which sentence was unsupported, the repair can target that sentence rather than re-rolling the whole response — which is the design instinct behind the revision-rather-than-regeneration approach discussed in section 6.3.

And some failures are not retryable at all. If the retrieval step returned nothing relevant, regenerating produces the same ungrounded answer. Detecting that a failure is structural rather than stochastic, and routing it to escalation immediately, is what separates a retry budget from a retry loop.

11.7 Assuming later layers subsume earlier ones

Stated in section 2.3 and repeated here because it recurs in design reviews: a judge does not replace a schema validator, and a grounding check does not replace a tool call. The layers cover different failure types with different reliability characteristics. Replacing a decidable check with a probabilistic one because the probabilistic one is "more powerful" trades certainty for capability in a place where certainty was available for free.

12. Frequently Asked Questions

12.1 Can any combination of these layers eliminate hallucination?

No, and treating that as the goal produces bad architecture. As noted in section 2.2, there is published work arguing that hallucination cannot be entirely eliminated in language models. The achievable objective is different and more useful: detect wrong output at a rate proportional to the cost of letting it through, and have a defined path for what happens when detection fires. A system that catches most errors and escalates the rest is a working system. A system designed on the premise that errors will not occur has no path for the ones that do.

12.2 If I can only implement one layer, which one?

It depends on what your system produces, which is the whole point of section 9 — but the two most common answers are worth stating. If your output is structured, Layer 1, because it is decidable, nearly free, and removes an entire failure class. If your output is prose grounded in retrieved documents, Layer 2, because F2 is where a retrieval system's errors concentrate and it is the only layer that addresses them.

Layer 5 is a poor first choice despite being the easiest to implement, because it is expensive per request, its verdicts require calibration against human judgment before they mean anything, and it overlaps least with the failures that dominate most production systems.

12.3 Is it acceptable to use the same model as generator and verifier?

For Layer 3 that is inherent to the technique, and the caveats in section 5.4 apply in full. For Layer 5 it substantially weakens the check: work on self-preference in evaluation reports that evaluators favor their own generations, so a model reviewing its own output is not an independent check and should not be reported as one.

If a second model family is not available, you still get value from Layer 5 on instruction compliance, which is largely a mechanical comparison between the instruction text and the output. You get considerably less value on factual assessment, where shared blind spots dominate.

12.4 How do I verify output when there is no source of truth at all?

Accept that you cannot, in the strong sense, and design accordingly. With no evidence in context and no tool that can adjudicate, the available signals are consistency across samples (Layer 3, which cannot see confident systematic error) and cross-model review (Layer 5, which shares blind spots to the degree the models are similar). Neither establishes correctness.

The productive move is usually to change the problem rather than to strengthen the verifier: introduce a source of truth so that F1 becomes F2. Retrieval exists as much for verifiability as for coverage — giving the model documents to answer from converts an unfalsifiable claim into a checkable one. That reframing is the single highest-leverage change available for a system with no source of truth.

12.5 Where does structured output enforcement fit if the response also needs citations?

This is a concrete constraint rather than a theoretical one, at least on Anthropic's API as of the confirmation date, where citations and output_config.format are mutually exclusive and combining them returns a 400. Section 4.4 sets out the three options — two calls, citations with your own structural validation, or schema enforcement with your own grounding check — and the choice follows from which guarantee your reviewers actually rely on. If a human must trace each assertion to a span, keep the citations. If a downstream system must parse the result without breaking, keep the schema.

Check current documentation before designing around this, as it is exactly the kind of constraint that gets relaxed.

13. Summary

Verification is not one technique and "hallucination" is not one failure. The six failure types in section 2 have different causes and different detection strategies, and the mapping in section 2.3 between those types and the six layers is the whole of the design guidance in compressed form.

Four points are worth carrying away.

Every layer has a structural blind spot, and the blind spots are the design constraints. Structural verification cannot see meaning. Grounding verification cannot see errors in its own sources. Self-verification cannot see confident systematic error. External verification inherits the tool's correctness. Cross-model review shares the generator's blind spots. These are not gaps awaiting better tooling; they follow from what each layer has access to, and a stack is only as trustworthy as its awareness of what it does not cover.

Cheap deterministic checks are not a lesser version of expensive probabilistic ones. Run them first, and do not let a more sophisticated layer take over a job a simpler layer does with certainty.

The false-negative rate is invisible unless you deliberately measure it. Sampled human review of passing output is the only mechanism that reveals what escaped, and without it, thresholds drift toward permissiveness under the one-sided pressure of visible false positives.

Some failures are not verification problems. Stale sources, missing retrieval, and wrong documentation cannot be fixed by adding layers, and a stack that appears to address them is worse than an honest gap, because it converts a known risk into an unknown one. Writing down what the stack does not cover is part of building it.

14. References