AnthropicClaude Certified Architect – Foundations2026-104.3 Enforce structured output using tool use and JSON schemas
Validate meaning after checking record structure
Completed by the knowledge check
Learning objective
Distinguish syntactic schema compliance from semantic accuracy such as inconsistent totals or values placed in the wrong fields.
Core idea
A valid record can state the wrong facts. strict: true constrains a tool’s inputs to the supported schema; native JSON outputs use output_config.format for the response shape. Those mechanisms can enforce a numeric total and correctly typed dates. They do not establish that the total matches the source or that a date belongs in the field that received it.
For an architect reviewing an extraction pipeline, separate structural acceptance from semantic acceptance. The first asks whether the record conforms to its contract. The second asks whether the values mean what the fields claim and are supported by the source. The exam guide explicitly names inconsistent totals and values in the wrong fields as semantic errors that strict schemas do not prevent.
See 4.3.1 for reading an extracted tool record and 4.3.5 for normalization. This lesson concerns the decision after a complete record exists: whether its contents are trustworthy enough for the next operation.
How it works
Identify what the schema actually checks
An extraction tool’s input_schema can specify type, required, and enum. With strict: true, the API constrains tool inputs using grammar-constrained sampling. A number where the contract requires a number is structurally acceptable. A missing required field is a structural defect; a present but unsupported value is a different defect.
Native JSON outputs and strict tool inputs share Anthropic’s supported JSON Schema subset. Do not infer that every restriction expressible in a validation library is enforced during generation. For example, minimum, maximum, and multipleOf are unsupported API constraints. SDK transformation and local validation are separate mechanisms, covered in 4.3.7.
Keep three questions distinct: Is the serialization valid JSON? Does the object conform to the intended schema? Does the object accurately represent the document? A JSON parser answers the first. Structural validation answers the second and remains useful for the enum and const capitalization exceptions in 4.3.7. Source comparisons and business checks answer the third. Calling all three questions “JSON validation” hides the failure that needs repair.
Reconcile related values under a stated rule
Consider an illustrative invoice whose three net line amounts are 400.00, 590.00, and 250.00. Their sum is 1,240.00. If the extracted net subtotal is 1,420.00, all four values can still have type: "number". The inconsistency is arithmetic, not a malformed record.
An application check should recompute the net subtotal from the extracted net line amounts and compare it with the reported net subtotal under the invoice’s stated rounding policy. Compare like quantities: a net subtotal need not equal a gross total that includes tax. Shipping, discounts, and tax must participate in the relevant equation when the document includes them. A check against the wrong equation creates false findings.
If the extracted values reproduce an inconsistent source document exactly, extraction itself can be accurate while the invoice is unsuitable for automatic payment. Preserve that distinction in the application’s result: a source inconsistency and an extraction mistake require different explanations. Do not silently replace the source’s total with the computed value and label it “extracted.”
These calculations are application checks over the extracted fields. They are not a Claude API switch that certifies a record’s business meaning. The exam guide’s semantic-validation requirement is the reason to retain them after schema enforcement succeeds.
Check field meaning against source evidence
An invoice can contain an issue date and a payment deadline, both represented as valid date strings. If the extractor swaps them, a JSON parser cannot detect the problem. Describe invoice_date and due_date in input_schema.properties with their distinct meanings and source labels. Anthropic recommends detailed tool and parameter descriptions; they guide interpretation rather than prove the resulting value.
Inspect the source passage behind a suspicious assignment. A value next to “Pay by” supports a payment deadline; a value next to “Issued” supports an issue date. Where the layout makes the association uncertain, use the uncertainty representation from 4.3.4. A chronology check can flag a suspicious result when the business contract requires that ordering, but chronology alone does not prove which label a value came from.
Anthropic’s hallucination guidance recommends allowing uncertainty. Its “Verify with citations” technique makes claims auditable through supporting quotes and sources. For an extraction contract that needs audit evidence, you can apply that technique by defining supporting text fields in the same schema and instructing the model to copy the relevant source wording. Verify those excerpts against the source; an excerpt generated by the model is still a claim until checked.
Do not assume native JSON responses can be combined with the citations feature. Anthropic documents a 400 error when citations are enabled with output_config.format. Supporting text fields are an application schema design, not API citation blocks.
Key distinctions and trade-offs
Use the defect’s deciding property to choose the check:
| Defect | Why structure alone is insufficient | Check that addresses it |
|---|---|---|
| A string in a numeric field | It violates the declared type | Supported schema enforcement |
| A numeric subtotal that disagrees with its lines | Every value can have the correct type | Recompute the relevant equation |
The issue date placed in due_date | Both fields accept the same representation | Compare each value with its source label |
| A plausible purchase-order number absent from the document | A plausible string satisfies a string field | Verify source support and allow a missing value |
| A source invoice whose printed total is itself wrong | Faithful extraction can preserve the inconsistency | Separate source validity from extraction accuracy |
More detailed descriptions can reduce interpretation errors without establishing truth. More source evidence makes inspection easier but increases record size and requires its own verification. More business checks improve detection only when their assumptions match the document. A blanket “due date must follow issue date” rule cannot substitute for an explicitly defined policy.
Architecture / decision scenario
An invoice pipeline receives two complete extract_invoice records from strict tool calls. The first has the three net line amounts from the example and a net subtotal of 1,420.00. The second has consistent amounts, but its extracted due_date matches the source’s “Issued” label rather than “Pay by.” Both records satisfy the declared types and required fields.
The consumer reads each tool_use block’s input and then applies semantic checks. It recomputes the first invoice’s net subtotal as 1,240.00 and checks the source’s printed subtotal. If the source says 1,240.00, the extraction is wrong; if it says 1,420.00, the source is inconsistent. The service preserves the evidence and does not release either unexplained mismatch for automatic payment. The source’s printed subtotal decides whether the mismatch is an extraction mistake or a source inconsistency.
For the second invoice, the service compares the two extracted dates with their labels in the document. It rejects the swapped assignment even though both dates parse correctly. The team improves the fields’ description values and supplies a contrast example that distinguishes issue date from payment deadline. It still checks subsequent records: a prompt improvement is not evidence that this particular record is accurate.
The next validation-and-feedback loop belongs to subsection 4.4. Here the key decision is to classify both failures by meaning rather than spend effort tightening an already satisfied type constraint.
Common exam traps
- Treating schema-valid data as verified source facts.
- Expecting
strict: trueto reconcile invoice arithmetic. - Treating a swapped date as a JSON syntax error.
- Comparing net line items with a gross total without accounting for tax.
- Correcting an inconsistent source silently and presenting the result as extraction.
- Assuming a field description guarantees the right semantic assignment.
- Accepting a model-generated supporting excerpt without checking it against the document.
What to remember
A schema constrains form. Arithmetic checks reconcile related values, and source checks establish which field a value belongs to. Keep extraction accuracy separate from source consistency, and route a defect according to the check it actually fails.
Knowledge check
An extractor using strict tool use has produced no schema errors for a month. An audit then finds records whose extracted net line amounts sum to 1,240.00 while the extracted net subtotal is 1,420.00. What should the team add?
tool_choice that names extract_invoice on every requestrequired entry for every property in the extraction schemaA reconciliation check flags an invoice whose extracted net lines sum to 1,240.00 while its extracted net subtotal is 1,420.00. Inspection confirms that the extracted lines match the source and that the source itself prints 1,420.00 as its net subtotal. What should the pipeline do?
A strict record places a valid date in due_date, and a reviewer suspects it is the invoice’s issue date. The reviewer must establish which source label the extracted value came from. Which check does that?
format: "date" constraintdue_date falls before its invoice_dateA new check compares the sum of extracted net line amounts with the extracted total, which includes tax. It flags nearly every taxed invoice, although sampling shows the extractions are correct. What should the team change?
total without tax in the recordtotal changes the extraction to fit a broken check.References
- Anthropic, Strict tool use
- Anthropic, Structured outputs
- Anthropic, Define tools
- Anthropic, Reduce hallucinations
- Anthropic, Claude Certified Architect – Foundations Exam Guide