Anthropic CCA-F: Claude Structured Output: Prompts, Validation and Review

A model can return impeccably structured data that should never be allowed into a production database. A compliance assistant may emit valid JSON while identifying the wrong customer. A claims extractor may place an unsupported amount in the correct numeric field. Those are not formatting defects. They are architectural defects in the way a system chooses evidence, checks meaning and authorizes the next action.

Prompt Engineering & Structured Output makes up 20% of the published Claude Certified Architect – Foundations exam blueprint. Candidates should be able to explain how system-level criteria, examples, typed outputs, validation, feedback, batching and review fit together. The goal is not to write the cleverest prompt. It is to design a process that can fail visibly and recover safely when an apparently compliant answer is wrong.

Write acceptance criteria before you draft the prompt

Imagine an application that extracts contract renewal dates, billing amounts and termination notice periods from signed customer agreements. A weak request says, “Read the document and output JSON.” It never says which agreement version counts, whether a date is an effective date or a signature date, what to do when an amount is missing, or how to distinguish cited text from interpretation. When the model fills those gaps on its own, the output can be internally consistent and commercially wrong.

Start by describing the decision that consumes the extraction. The billing team needs the operative agreement, the parties, effective date, renewal clause, notice window and the passage from which each value was derived. It does not need a model’s confidence alone. State that absent or conflicting values must be represented explicitly, not guessed. Make clear that an extracted termination date is not permission to send a legal notice or change an account.

An architect can then write prompts that express useful boundaries: identify the controlling source, distinguish direct quotations from inferences, prefer “unresolved” over a fictional default, and return the specific source reference supporting each populated field. These requirements remain relevant even if the implementation moves from plain text to constrained JSON or tool use.

Choose few-shot examples for boundary cases, not decoration

Examples are most useful when they resolve ambiguity. One contract may have a clearly labeled renewal date, another may amend the date in an addendum, and a third may have no enforceable date in the available pages. Three examples that all show the simple case teach little. A stronger set demonstrates a direct extraction, a conflict requiring source precedence, and a case where the system must return insufficient evidence.

Each example should match the actual acceptance standard without implying that the model may invent a missing clause. Keep examples realistic but minimal: the purpose is to teach how to choose evidence and format a response, not to flood the working context with long boilerplate. A good team tests an example against held-out documents; an improvement on the examples themselves may not improve performance on genuinely unfamiliar agreements.

For Claude, Anthropic’s prompting guidance emphasizes relevant, varied examples and clear instructions. Apply that to the architecture as a testing principle. Record which error a new example is intended to prevent and measure its effect. If adding another example increases latency or distracts from source retrieval without improving correctness, it may not deserve a permanent place in the prompt.

Separate JSON outputs, strict tool inputs and domain validation

Current Claude API documentation describes two complementary structured-output controls. output_config.format can constrain the model’s direct JSON response to a supported schema. A tool definition with strict: true can constrain the parameters used when the model requests that tool. These are different interfaces: one governs returned data and the other governs requested tool arguments. A schema can help an application parse results reliably; it does not establish the authority or truth of those results.

For the contract extraction, a useful typed response might contain agreement_id, renewal_date, source_reference, evidence_status and needs_review. It could allow an explicit null renewal date instead of silently inventing a value. Define controlled evidence states such as verified, conflicting and missing, then decide which statuses a downstream workflow may accept. A field named approved is too ambiguous unless the operating contract explains whether it means model assessment or legally authorized action.

Be aware that schema features and model support change. SDK helpers may simplify unsupported JSON Schema constraints and enforce extra checks locally. The application’s own validator should therefore enforce business ranges, cross-field dependencies, identity matching, date logic and any unsupported original schema constraints. Verify a new provider feature against the current documentation rather than assuming that every regex, length bound or schema composition rule is guaranteed by model decoding.

Validation and retry need informative feedback

Retries are useful when the model receives actionable feedback. “Wrong answer, try again” gives little help. “The document provides two conflicting notice periods; cite the addendum governing the current term or return conflicting evidence” identifies a specific defect. A validation cycle should check whether the next result actually meets the business rule, not merely whether its wording sounds more confident.

Separate transient defects from structural ones. A malformed response may justify another model attempt or a stricter output configuration. A source that is missing cannot be conjured up through retry. An unauthorized document should not be accessed through an alternative tool. A suspected incorrect contract identifier should trigger reconciliation with the contract system, not a model request to “make the ID more likely.”

Set limits on retries, cost, latency and repeated side effects. If the extraction requires a tool that writes data, make the write a separate authorized stage after validation. This keeps a failing prompt from repeatedly creating partial records. The Architect Foundations scenario analysis illustrates how to compare designs by the consequence of being wrong; that is the right criterion for selecting retry versus escalation.

Batch processing is a business trade-off, not a prompt trick

Suppose 80,000 agreements require migration to a structured archive. Running every agreement interactively may be unnecessarily expensive and difficult to monitor. Batch processing can offer more predictable throughput for work that does not need an immediate response. But a batch is still a set of independently validated records. One failed document should not quietly contaminate a complete job, and progress reporting must distinguish submitted, processed, validated, rejected and manually reviewed items.

Design the batch around record identity and replay safety. Each agreement gets a stable job key, a source version and an idempotent destination write where possible. Failed items have typed reasons: unreadable scan, conflicting amendment, unsupported schema, missing party identity, transient provider error. Use those reasons to decide what can be retried automatically. A rerun must not overwrite an earlier human correction or mark a previously unresolved document as valid without rechecking the evidence.

Prompt design changes when a batch contains varied material. An extraction prompt validated on one contract family may perform poorly on a different jurisdiction or document type. Segment the evaluation and use held-out examples from each meaningful category. A single high average score can hide a particularly damaging error rate in a small but high-value group of documents.

Use multi-pass review for genuinely different jobs

Several identical passes with the same prompt may produce agreement without increasing correctness. A better review separates extraction from critique. One pass proposes values and source spans. A second checks that each value is supported by those spans and the controlling contract version. A deterministic validator then checks arithmetic, date sequence and required fields. High-consequence or unresolved cases move to a human reviewer with all cited evidence.

The architecture should preserve disagreement. If a reviewer flags a conflict, do not have a final synthesizer silently choose one side merely to populate a mandatory field. Keep the conflict state and the sources that caused it. The business may be able to proceed with a qualified recommendation, but it should not record disputed evidence as a verified fact.

Independence matters as well. A critic that simply repeats the first output may only amplify the same error. Review against original evidence, not against the first answer’s confidence or polished explanation. Where budget permits, compare distinct extraction methods or model configurations on a representative validation set; choose by observed downstream error cost rather than raw volume of tokens consumed.

A test suite for structured-output architecture

To assess the contract pipeline, prepare a small suite in which the expected system response is known. Include an ordinary agreement with all values present; an amendment that supersedes a date; an unreadable page; a contract for the wrong legal entity; a malicious instruction embedded in a scanned note; a conflicting currency or unit; and a document whose renewal is conditional on a notice that is not in the supplied records.

Evaluate more than JSON parse success. Measure correct value extraction, accurate source attribution, justified abstention, false confident answers, safe handling of disallowed actions, end-to-end latency and reviewer effort. The most important metric may be the rate of incorrect values accepted into the archive without escalation. A pipeline that produces fewer automatic completions but reliably exposes uncertainty can be the better business solution.

This is the Architect Foundations lesson: the best structured-output system combines clear criteria, informative examples, schema control, independent validation, bounded feedback and proportional human oversight. Adjacent Associate Foundations prompting work teaches better everyday task framing; the architectural task is to prove that the entire extraction workflow deserves to be trusted before another system acts on its output.