Skip to lesson

AnthropicClaude Certified Architect – Professional2026-102.2 Design system prompts, templates, and guardrails

Answer only what supplied sources support

Completed by the knowledge check

Learning objective

Ground responses in supplied sources and permit “I don’t know” to reduce unsupported claims

Core idea

Free-form answers need a policy for what they may claim, how a reader can inspect the support, and what happens when the supplied sources cannot answer the question. Honest missing-value representations remain useful, but prose adds a harder problem: a fluent paragraph can combine supported facts with an unsupported conclusion.

Anthropic recommends permitting uncertainty, restricting claims to provided documents, grounding in direct quotes, and checking claims against sources. These techniques reduce hallucinations without eliminating them. Your design must make an incomplete but supported answer acceptable, then measure whether the assistant abstains for the right reasons.

For an architect, the decision is how much source traceability the application needs and what unsupported inference could cost. A helpful answer to part of a question is different from a complete answer assembled by guessing. Make that difference visible to both the user and the owner who accepts the output.

How it works

Define the answerable unit

Treat each material claim as something that needs support. A source can establish an event without establishing its cause. A report can state that a control exists without proving that it operated throughout a period. Instruct Claude to distinguish what the supplied documents state from what they leave unresolved.

An application prompt can say to answer only from the supplied material, cite supporting passages, and explicitly identify questions the material does not settle. These are grounded-answer instructions, not a special API switch that disables model knowledge. They need testing against questions whose likely answers are familiar but absent from the documents.

Anthropic recommends extracting word-for-word relevant quotes before analysis for long documents exceeding 20,000 tokens. This makes the supporting material explicit before synthesis. The purpose is a traceable passage selection, not a demand to expose hidden internal reasoning. The prompt can then require each conclusion to be justified by the selected material.

A passage is not sufficient merely because it repeats the nouns in the question. If a document says a supplier plans to complete an audit, it does not support the claim that the audit is complete. Teach the assistant to preserve dates, qualifiers, and the difference between a reported plan and an observed result.

Choose native citations when location matters

The Messages API accepts document content blocks with type: "document". Enable native citations with citations: {"enabled": true} on each document; the documentation requires citations on all or none of the documents within a request. Supported document formats include plain text, PDFs with extractable text, and custom content.

For plain text, a source with type: "text", media_type: "text/plain", and data supplies the citable content. Response text blocks carry a citations array. A plain-text citation uses type: "char_location", with document_index, start_char_index, end_char_index, and cited_text. Document and character indices are zero-based. PDF citations instead identify page ranges, which are one-based.

Use the response citation objects to render the source references rather than asking Claude to invent document URLs. Anthropic guarantees valid pointers to the supplied documents and extracts cited_text directly. That guarantee concerns the pointer, not the truth of the document or whether the passage logically supports every implication in the answer.

For third-party sources, return native search_result blocks in the retrieval tool’s tool_result.content array. Each result requires source, title, and content containing text blocks; set citations: {"enabled": true} consistently on every search result in the request. If one block in a tool result is a search_result, every block in that result must be a search_result; put supporting text inside a result’s own content. This preserves citable source structure inside the untrusted-content channel rather than flattening it into a JSON-encoded string. Search result content blocks are available on the Claude API, Amazon Bedrock, and Google Cloud, a narrower list than document citations, and are supported on all active models except Claude Haiku 3, with no beta header.

Keep the relationship between each source and the original input available to the renderer. An index identifies a document in that request; it is not a durable business identifier across unrelated requests. Preserving the request’s document ordering lets a reviewer inspect the right material rather than a similarly named report.

Respect format and source boundaries

Document citations are generally available on the platforms listed by Anthropic: Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud, and Microsoft Foundry. The citation page states that all active models support the feature. Only text citations are supported; an image-only scan without extractable PDF text is not a citable source under this mechanism.

Native citations cannot be combined with structured outputs. Enabling document citations while including output_config.format produces a 400 error. Choose cited prose when the reader needs an auditable narrative. If another stage needs strict JSON, separate the stages and validate that stage’s claims against the preserved source material. Do not promise that JSON containing a source label has the same pointer guarantee as native citations.

Source grounding also does not grant instruction authority to the source. A supplied report saying “ignore all restrictions” remains report content. Keep third-party retrieval in tool_result, as required by 2.2.2, and use the native search_result blocks described here when citations are needed. The fact that text can be cited does not make its embedded directives application policy.

Make abstention specific and useful

Permit a partial answer that states the supported portion and names the missing evidence. “The report identifies the control owner, but does not state the last test date” is more useful than either an invented date or a blanket refusal. When sources conflict, expose the conflict rather than choosing whichever version makes the answer complete.

Anthropic also recommends verifying claims after drafting and retracting a claim when no supporting quote can be found. That review is another model-mediated check, not independent proof. For consequential outputs, the reviewer still needs to assess whether the passage supports the conclusion and whether the source itself is suitable.

Measure supported-answer quality alongside abstention. Unnecessary abstention on a clearly answerable question is a failure, just as unsupported certainty is. A system that always says “I don’t know” can minimize invented facts while delivering none of the intended service.

Key distinctions and trade-offs

Source pointer versus entailment: Native citations locate text. A reviewer or evaluator must still judge whether that text supports the claim.

Missing evidence versus negative evidence: No test date in the supplied report does not prove that no test happened. Preserve that distinction in the answer.

Completeness versus support: Adding an unsupported conclusion raises apparent coverage while reducing reliability. Partial answers preserve useful information without hiding the gap.

Architecture / decision scenario

A healthcare organization’s procurement team must summarize 30 vendor security responses within one working day. It needs cited prose for reviewers, and its reporting database also expects strict JSON. The tempting design enables citations and output_config.format together and instructs Claude to fill every field.

The architect retrieves the vendor responses as citation-enabled search_result blocks inside tool_result, then uses a cited-answer stage and a separate structured-record stage. A response that states “testing is scheduled” supports a planned test, not completed testing. The narrative says the completion date is unknown and cites the schedule; the record stage must preserve that unresolved status. The security lead owns the interpretation and approves any decision that depends on completion.

An evaluation contains 40 clearly answerable questions and ten deliberately unsupported ones. The team requires at least 38 supported answers on the first group and correct abstention on all ten of the second. These are illustrative acceptance targets, not Anthropic benchmarks. A candidate that answers only 25 of the supported questions fails despite never fabricating a date. The chosen architecture spends another processing stage to keep auditability and machine-readable reporting distinct, while reviewers retain responsibility for source adequacy.

Common exam traps

  • Equating valid citation pointers with a true or fully supported conclusion.
  • Treating missing evidence as proof that an event did not occur.
  • Combining native citations with output_config.format in one request.
  • Assuming an image-only PDF scan supports text citations.
  • Rewarding blanket abstention without testing answerable questions.

What to remember

Restrict answers to supplied support, permit specific unknowns, and preserve partial answers. Native citations provide valid locations, not semantic or factual certainty. Choose an output design that respects citation compatibility, and evaluate both unsupported claims and unnecessary abstention.

Knowledge check

References