Structured Output via Tool Use and JSON Schemas

The Structured Output with Tool Use and JSON Schemas topic maps directly to task statement 4.3 of the Claude Certified Architect — Foundations (CCA-F) exam: Enforce structured output using tool use and JSON schemas. This task statement sits inside Domain 4 (Prompt Engineering & Structured Output, 20% weight) and anchors the entire Structured Data Extraction scenario cluster — one of the six scenarios from which the exam draws four per sitting. If your extraction pipeline returns malformed JSON, every downstream system breaks; if your schema is strict but semantically empty, the system silently produces wrong answers. Structured Output with Tool Use and JSON Schemas is the architectural pattern the exam expects you to reach for whenever the scenario demands machine-readable output.

This study note walks through the full surface area an architect must internalize: why tool_use with a JSON schema is the most reliable enforcement mechanism on Claude, how the three tool_choice modes ("auto", "any", forced tool selection) change model behavior, the schema-design patterns that prevent hallucination (nullable fields, enum + other, required vs optional), the critical distinction between syntax errors and semantic errors (strict schemas prevent the former, never the latter), and the prompt-alongside-schema pattern that normalizes formats before they hit your validator. Every section is tuned to the Structured Data Extraction scenario cluster, where the exam asks you to design an invoice parser, a medical-record extractor, or a contract-clause classifier under hard reliability constraints.

Why Structured Output Matters for the CCA-F Structured Data Extraction Scenario

Structured Data Extraction is one of the six CCA-F scenario clusters listed in the official exam guide, and every question inside this cluster silently assumes you will reach for Structured Output with Tool Use and JSON Schemas as the default pattern. The scenario describes a production system that ingests invoices, medical records, legal contracts, or research papers and must emit JSON that a downstream service can consume without a human-in-the-loop validator. Free-form text output is not acceptable; neither is JSON wrapped in markdown code fences, JSON with trailing commas, JSON with hallucinated fields, nor JSON whose field values appear in the wrong key.

The exam pressure-tests whether you understand that Structured Output with Tool Use and JSON Schemas is categorically more reliable than asking Claude "please respond in JSON" via system prompt. Prompt-based JSON enforcement leaves schema compliance to the model's best-effort generation. Tool-based enforcement hands Claude a contract: your only way out of this turn is to emit arguments that match this schema. The architectural difference is enormous: prompt-based enforcement is advisory, tool-based enforcement is programmatic.

Where Structured Output Sits in the CCA-F Blueprint

• Domain 4, Task 4.3 — Enforce structured output using tool use and JSON schemas (this topic).
• Domain 4, Task 4.4 — Implement validation, retry, and feedback loops for extraction quality (pairs with this topic).
• Domain 2, Task 2.1 — Design effective tool interfaces with clear descriptions and boundaries (the same tool-definition discipline powers extraction schemas).
• Domain 2, Task 2.3 — Distribute tools appropriately across agents and configure tool_choice (directly overlapping sub-skill).

Because tool-use concepts repeat across Domains 2 and 4, the exam frequently pairs a Structured Data Extraction question with a Tool Design question in the same cluster, and mis-learning one ruins the other.

Tool Use as the Most Reliable Structured Output Enforcement Mechanism

The foundational insight of Structured Output with Tool Use and JSON Schemas is that Anthropic treats tool definitions as first-class typed contracts. When you define a tool with an input_schema and force Claude to call that tool, the API guarantees that the input payload in the resulting tool_use block matches the schema at the syntax level — keys are present, value types are correct, and required fields are populated.

How the Extraction-Tool Pattern Works End-to-End

1. Define a tool whose name and description describe the extraction task (for example, record_invoice with description "Record the structured invoice fields extracted from the document").
2. Populate input_schema with the JSON schema your downstream service expects — required fields, types, enums, nullable markers, nested objects.
3. Send the document as a user message and include the tool in the tools array.
4. Set tool_choice to force the model to call this specific tool (see the next section).
5. Receive the response: Claude's output contains a tool_use content block whose input object is the extracted data. stop_reason will be tool_use.
6. Consume the input object directly — you never actually execute the tool. Skip the tool_result round-trip entirely if no downstream action is needed.

Why This Beats Prompt-Based JSON Requests

Prompt-based JSON enforcement ("Return a JSON object with fields invoice_number, total, line_items...") relies on the model's training to produce well-formed JSON. Observed failure modes include markdown code fences wrapping the JSON, trailing commas, mismatched quotes, explanatory prose before or after the JSON, and hallucinated keys. Tool-based enforcement eliminates all of these failure modes because the API surfaces a typed input object rather than a text blob the client must parse.

The tool_choice Parameter: auto vs any vs Forced Tool Selection

tool_choice is the single most tested parameter inside Structured Output with Tool Use and JSON Schemas. It controls whether the model may reply with free-form text, must call some tool, or must call one specific named tool. The three modes map to three very different extraction architectures, and confusing them is one of the most frequent exam traps.

Mode 1: "auto" — Model May Choose Text or Tool

With tool_choice: "auto" (the default), the model may inspect the user input, decide a tool call is not warranted, and reply with plain text. On the CCA-F exam, if the scenario requires a guaranteed structured output for every input, "auto" is the wrong choice — there is no guarantee the model will call the tool, and text responses break downstream JSON consumers. "auto" is appropriate only when text responses are a legitimate outcome (for example, a customer-support agent that might either execute an action or ask a clarifying question).

Mode 2: "any" — Model Must Call Some Tool

tool_choice: "any" guarantees a tool call but lets the model pick which tool. This is the correct choice when you have multiple extraction schemas — for example, one tool for record_invoice, one for record_receipt, and one for record_purchase_order — and you want Claude to route each document to the right schema. The response will always be a tool_use block; your application handles whichever tool was called. "any" is wrong when only one extraction schema exists, because the extra routing freedom adds no value and may introduce ambiguity.

Mode 3: Forced Tool Selection — Model Must Call One Specific Tool

tool_choice: {"type": "tool", "name": "record_invoice"} forces the model to call record_invoice and no other tool. This is the most deterministic mode and the default recommendation for single-schema extraction pipelines. Combined with a well-designed input_schema, forced tool selection is the tightest bind you can put on Claude's output.

A Fourth Mode Worth Knowing: "none"

tool_choice: "none" disables tool calling entirely, even when tools are provided. This is useful when you want to reuse the same message history across turns but temporarily force a text response. The exam rarely tests "none" directly, but recognizing it prevents confusion if it appears in a distractor.

Syntax Errors vs Semantic Errors: What Strict Schemas Do Not Fix

This is the most load-bearing distinction in the entire Structured Output with Tool Use and JSON Schemas topic, and the exam exploits it relentlessly. A strict JSON schema guarantees syntax conformance — the keys exist, the types match, the enum values are from the allowed list, required fields are present. It guarantees none of the following:

• The line_items array sums to the total field.
• The invoice_date is chronologically before the due_date.
• The customer_name extracted is the actual customer, not the billing contact.
• A currency symbol in the source document was correctly normalized to the currency enum.
• A value that belongs in shipping_address did not end up in billing_address.

Every one of these is a semantic error — the JSON is well-formed, passes schema validation, and is still wrong. No schema feature can prevent semantic errors because the schema has no view into the source document.

Why the Exam Loves This Distinction

The Structured Data Extraction scenario commonly presents a failure report: "the extraction pipeline produced JSON that validated against the schema, but the total field did not equal the sum of line_items[].amount. Which change to the pipeline should the architect make?" Candidates who believe strict schemas fix all errors will pick "add strict: true to the tool definition." That answer is wrong — the JSON was already schema-compliant. The correct fix lives in task 4.4: add a validation step that checks the semantic invariant, and feed violations back as a follow-up turn so Claude can correct itself.

Semantic Error Mitigation Strategies

• Validation + retry loops (task 4.4): compute the invariant in application code, return tool_result with is_error: true and a descriptive message, let Claude re-attempt.
• Format normalization rules in the prompt (covered below): tell Claude exactly how to compute derived fields, which reduces — but does not eliminate — semantic errors.
• Multi-pass review (task 4.6): a second Claude call verifies the first Claude call's output, independent of schema validation.
• Confidence calibration and human review (task 5.5): route low-confidence extractions to a human.

Required vs Optional Fields: Schema Design Choices That Prevent Hallucination

Inside the JSON schema, every field has a subtle impact on Claude's behavior. The required-vs-optional distinction is not just a downstream-consumer concern — it directly affects whether Claude hallucinates.

Required Fields

Fields listed in the schema's required array must be present in the output. When Claude cannot find the information in the source document, it will either hallucinate a value or fail the schema entirely. Making a field required is therefore a commitment: you are telling Claude "this information is always present in the source; extract it without fail."

Optional Fields

Fields not in the required array may be omitted. Claude will include them only when the source document provides the information. This is the safer default for fields that are genuinely optional in your domain — for example, discount_percentage on an invoice.

The Anti-Pattern: Required + No Nullable

Making a field required when it might not appear in the source is the single highest-frequency hallucination recipe in Structured Output with Tool Use and JSON Schemas. Claude, faced with a schema that demands a value it cannot find, will produce a plausible-looking but fabricated value. The fix is either to move the field to optional or — better — to make it required and nullable.

Nullable Fields: The Hallucination Prevention Pattern

The nullable-field pattern combines two schema features: the field is in required, and the field's type is a union that includes null (typically ["string", "null"] or ["number", "null"]).

Why Nullable Beats Optional for Known Schemas

Optional fields (not in required) leave your downstream consumer with two ambiguous cases: the field is absent because the source lacked the information, or the field is absent because Claude forgot to include it. Nullable-and-required fields collapse these two cases: null always means "source lacked it," and a missing key is a schema violation you can reject. This clarity is why mature extraction pipelines prefer nullable-required over optional for every known field.

When to Use Each Pattern

• Required, not nullable — the field is guaranteed to appear in every source document in your domain (for example, invoice_number on every invoice).
• Required, nullable — the field is in your schema's domain but may or may not be present in any given source (for example, discount_code or shipping_tracking_number).
• Optional — the field only makes sense for certain document subtypes and should be absent in others (for example, tax_exempt_certificate_id only on B2B invoices).

The Enum + Other Pattern: Extensible Controlled Vocabularies

Many extraction schemas include a classification field — document type, customer segment, incident category — where the set of allowed values is mostly known but occasionally encounters something new. A naive enum rejects unknown values; a free-form string loses the controlled-vocabulary benefit. The enum + other pattern solves both.

How the Pattern Works

Define an enum field that includes a literal value "other", and add a companion string field that is required only when "other" is selected. In JSON schema terms:

• category — enum with values ["refund", "shipping", "billing", "technical", "other"].
• category_other_detail — string, required when category == "other".

When Claude encounters an incident that clearly falls into refund, it selects refund and leaves category_other_detail null. When Claude encounters something genuinely outside the enum, it selects "other" and populates category_other_detail with a short description.

Why This Pattern Is Exam-Favored

A Structured Data Extraction scenario often includes a line like "the team reports that 3% of documents contain categories not on the original list, and the pipeline is rejecting them." The correct architectural fix is the enum + other pattern, not expanding the enum indefinitely (which silently grows unbounded) and not removing the enum entirely (which loses the controlled-vocabulary guarantee).

Format Normalization Rules: Prompting Alongside Strict Schemas

A strict schema guarantees types and structure, but it cannot tell Claude how to parse a raw date string, how to handle currency symbols, or how to convert a percentage. These format-normalization decisions live in the prompt, not the schema. The most reliable Structured Output with Tool Use and JSON Schemas pipelines combine a strict schema with a short list of explicit normalization rules in the system prompt.

Common Normalization Rules Worth Specifying

• Dates — specify ISO 8601 (YYYY-MM-DD); tell Claude how to handle ambiguous source formats (03/04/2026 might be March 4 or April 3).
• Currency — specify whether to include the symbol, the ISO 4217 code, or just the numeric value, and how to handle multi-currency sources.
• Numbers — specify decimal separator, thousands separator, and whether to strip percentage signs.
• Enums — if the source uses synonyms ("shipping" vs "delivery" vs "logistics"), tell Claude which canonical enum value each synonym maps to.
• Whitespace and casing — specify trimming and case normalization for string fields.

Where These Rules Live

Put them in the system prompt or in the tool description, not in the schema. The schema enforces types; the prompt enforces semantics. Combined with a few-shot examples block (task 4.2), normalization rules dramatically reduce semantic errors without changing the schema.

Plain-Language Explanation: Structured Output with Tool Use and JSON Schemas

Abstract schemas and mode parameters become intuitive when anchored to physical systems. Three analogies span the full surface of Structured Output with Tool Use and JSON Schemas.

Analogy 1: The Tax Form — Required Fields, Nullable Fields, and Strict Schemas

Imagine a government tax form. The form has a fixed set of numbered boxes — some mandatory (your name, your taxpayer ID, your total income) and some conditional (dependents, charitable donations, foreign-income reporting). A mandatory box that demands a value regardless of whether it applies is the schema anti-pattern: taxpayers faced with a mandatory "foreign income" box when they have no foreign income are forced to either leave it blank (schema violation) or invent a value (hallucination). The fix is the nullable-required pattern: the box must appear on the form, but the form explicitly allows writing "N/A" in it.

Tool use with a JSON schema is the same discipline: you hand Claude a structured form, you mark which boxes must be filled, and for boxes that might not apply you allow an explicit "null" rather than forcing a fabricated value. Forced tool selection is like handing Claude only this form and no blank paper — there is no way to submit free prose instead of the form.

Analogy 2: The Restaurant Order Pad — tool_choice Modes as Order-Taking Discipline

A waiter taking an order has three possible disciplines. In "auto" mode, the waiter may write on the order pad or may simply chat with the customer without writing anything — useful when the customer hasn't decided yet. In "any" mode, the waiter must write on some pad but can choose between the food pad and the drinks pad — useful when the customer might order either. In forced mode ({"type": "tool", "name": "food_order"}), the waiter must write on the food pad specifically — useful when the table has already ordered drinks and only food remains.

A kitchen that expects every table to hand in a complete food order cannot tolerate "auto" mode, because the waiter might come back empty-handed. Similarly, a Structured Data Extraction pipeline cannot tolerate tool_choice: "auto" when it needs guaranteed JSON from every document. Mode selection is about matching the discipline of the order pad to the reliability needs of the kitchen behind it.

Analogy 3: The Factory Quality Inspector — Syntax vs Semantic Errors

Imagine a factory that produces sealed boxes of cereal. A syntax inspector at the end of the line checks that every box has the right shape, the right weight range, the right barcode, the right expiration-date format. This inspector catches malformed boxes but cannot detect that the wheat flakes inside are actually corn flakes, or that the declared net weight is off by 10%. That deeper check requires a semantic inspector who opens the box, weighs the contents, and verifies the ingredients.

Strict JSON schemas are syntax inspectors: they guarantee the box looks right from the outside. Semantic correctness — totals matching line items, customer names attributed correctly, dates internally consistent — requires a separate validation pass in application code or a second-Claude review. The exam traps you if you think the syntax inspector's badge is enough to sign off on the shipment.

Which Analogy to Use on Exam Day

• Questions about required, optional, and nullable fields → tax form analogy.
• Questions about tool_choice modes → restaurant order pad analogy.
• Questions about strict schemas not fixing totals / cross-field invariants → factory inspector analogy.

End-to-End Structured Data Extraction Pipeline Architecture

Putting every piece of Structured Output with Tool Use and JSON Schemas together yields a reliable end-to-end pipeline. The CCA-F exam frequently asks you to identify which component is missing from a broken pipeline; knowing the reference architecture makes these questions pattern-matches.

Reference Architecture

1. Ingestion — source document arrives (PDF, image-via-OCR, HTML, email).
2. Pre-processing — normalize text, chunk long documents, attach document metadata.
3. Prompt construction — system prompt with format normalization rules, few-shot examples, user message containing the document.
4. Tool definition — record_<document_type> tool with strict input_schema; enum + other for classification fields; nullable-required for fields that may be absent from the source.
5. API call — Messages API with tools array and tool_choice: {"type": "tool", "name": "record_<document_type>"}.
6. Response handling — extract the tool_use.input object from Claude's response.
7. Semantic validation — application code verifies cross-field invariants (totals, date ordering, etc.).
8. Retry loop (task 4.4) — on semantic validation failure, construct a tool_result with is_error: true and an instructive message; let Claude re-attempt.
9. Confidence routing (task 5.5) — low-confidence or repeated-failure cases go to human review.
10. Downstream consumption — validated JSON is handed to the consumer system.

Where Each Exam Task Maps

• Task 4.3 — steps 4, 5, 6 (this topic).
• Task 4.4 — steps 7, 8.
• Task 4.2 — step 3 (few-shot examples).
• Task 4.1 — step 3 (explicit criteria, precision).
• Task 4.5 — entire pipeline batched via Message Batches API when latency is not critical.
• Task 4.6 — multi-pass review as an alternative to or enhancement of step 7.
• Task 5.5 — step 9.

Batch vs Synchronous Extraction Trade-offs

Structured Data Extraction often runs at volume — nightly invoice batches, weekly contract reviews, monthly compliance sweeps. The CCA-F exam pairs Structured Output with Tool Use and JSON Schemas questions with task 4.5 (batch processing) routinely.

Synchronous Extraction

Send one document per API call via the Messages API. Latency is low (seconds), but cost per request is standard and concurrency is subject to rate limits. Appropriate when extraction must happen inside a user-facing flow or when results feed an immediately consuming system.

Batch Extraction via Message Batches API

Submit up to 100,000 requests in a single batch. Results are available within 24 hours (often much faster), cost is reduced by 50%, and the batch endpoint has separate rate-limit headroom. Appropriate when extraction is offline, overnight, or otherwise latency-tolerant. The schema and tool definition are identical to synchronous — only the submission path changes.

Exam Trap: Always-Choose-Batch

The exam presents scenarios where batch is correct (high volume, overnight) and scenarios where batch is wrong (real-time user-facing extraction). Always-choose-batch to save cost is a known failure mode. Match the mode to the latency requirement in the scenario.

Common Exam Traps for Structured Output

CCA-F aggressively exploits a handful of trap patterns tied to Structured Output with Tool Use and JSON Schemas. Drill each one.

Trap 1: Strict Schema Fixes All Errors

The canonical trap: a scenario describes a semantic error (totals don't match, dates out of order), and an answer says "add strict: true to the tool definition." Wrong — strict schemas prevent syntax errors, never semantic errors. The correct answer lives in validation + retry loops.

Trap 2: tool_choice: "auto" Guarantees JSON

Scenarios say "the pipeline must always receive structured JSON" and an answer uses "auto". Wrong — "auto" allows text responses. Forced tool selection is the correct choice for single-schema pipelines.

Trap 3: "any" Instead of Forced Selection for a Single Schema

Scenarios have exactly one extraction schema, and an answer uses "any". Not strictly broken, but forced tool selection is tighter and the preferred CCA-F answer whenever the extraction target is a known, specific tool.

Trap 4: System Prompt Requests JSON Instead of Tool Use

An answer uses a system prompt that says "respond only in JSON matching this structure" with no tool defined. Wrong — prompt-based enforcement is advisory; tool-based enforcement is programmatic. The exam consistently prefers programmatic enforcement.

Trap 5: Required + No Nullable for Sometimes-Absent Fields

A field that might not appear in every source is marked required with no nullable type. This recipe induces hallucination. The fix is required + nullable, so Claude can explicitly emit null when the source lacks the information.

Trap 6: Expanding Enums Indefinitely Instead of Enum + Other

A classification field sees occasional new values, and an answer proposes expanding the enum every time a new value appears. Wrong — the enum + other pattern is the correct extensible design.

Practice Anchors: Structured Data Extraction Scenario Templates

CCA-F practice questions tied to Structured Output with Tool Use and JSON Schemas cluster into five shapes. Each template appears multiple times across the community pass-report corpus.

Template A: Schema Enforcement Mechanism

"A team is building an invoice-extraction pipeline that must always produce JSON matching a specific schema. Which approach is the most reliable?" Correct answer: define an extraction tool with the schema as input_schema and use forced tool_choice. Distractors: system prompt requesting JSON; regex post-processing of free-form output; fine-tuning (out of scope for CCA-F).

Template B: tool_choice Mode Selection

"An extraction pipeline has three tools — record_invoice, record_receipt, record_purchase_order — and must always call exactly one per document. Which tool_choice setting is correct?" Correct answer: "any" (the model must call some tool but chooses which). Distractors: "auto" (no guarantee), forced selection of one specific tool (loses the routing capability), "none" (disables tools entirely).

Template C: Semantic vs Syntax Error Diagnosis

"An extraction pipeline validates every output against a strict schema successfully, but 2% of invoices have line items whose sum does not match the total. What is the most effective fix?" Correct answer: add a validation step that computes the sum and feeds violations back via tool_result with is_error: true. Distractors: add strict: true (already strict); expand the schema with more constraints (semantic errors are not schema violations); switch to "auto" (unrelated and harmful).

Template D: Hallucination Prevention for Optional Fields

"Source invoices sometimes omit the shipping_tracking_number field, and Claude is fabricating values when this happens. How should the schema be updated?" Correct answer: make the field required and nullable. Distractors: make it optional (loses the "Claude must address it" behavior and introduces key-absent ambiguity); remove the field entirely (loses downstream information); add a system-prompt rule (prompt-based, weaker than schema-based enforcement).

Template E: Extensible Classification

"The support-ticket categorization schema has an enum of five categories, and new ticket types appear occasionally. The team doesn't want to keep expanding the enum. What pattern should be adopted?" Correct answer: enum + other with a companion free-form detail field. Distractors: remove the enum entirely (loses controlled vocabulary); expand the enum on every new type (unbounded growth); train a separate classifier (out of scope).

Structured Output with Tool Use and JSON Schemas Frequently Asked Questions (FAQ)

Why is tool use more reliable than prompt-based JSON enforcement?

Because the Messages API treats tool definitions as typed contracts. When Claude emits a tool_use content block, the input object is guaranteed by the API to conform to the tool's input_schema at the syntax level — keys present, types correct, required fields populated, enum values valid. Prompt-based JSON enforcement relies on the model's training to produce well-formed JSON and commonly fails with markdown fences, trailing commas, hallucinated keys, or prose before/after the JSON. The exam consistently prefers programmatic enforcement (tool use) over prompt-based enforcement (system prompt requesting JSON).

What is the difference between tool_choice: "auto", "any", and forced selection?

"auto" lets the model decide whether to call a tool or return text — the model may return text instead of calling any tool. "any" forces the model to call some tool but lets the model pick which one from the available tools. Forced selection ({"type": "tool", "name": "..."}) forces the model to call one specific named tool. For single-schema Structured Data Extraction, forced selection is the default recommendation. For multi-schema routing pipelines, "any" is correct. "auto" is appropriate only when text responses are a legitimate outcome, which is not the case in most Structured Data Extraction scenarios.

Do strict JSON schemas prevent Claude from hallucinating field values?

No. Strict schemas prevent syntax errors (missing required fields, wrong types, invalid enum values) but cannot detect semantic errors — values that conform to the schema but are wrong in the real world. Totals that don't match line items, dates in the wrong order, customer names attributed to the wrong field all pass strict schema validation. Preventing hallucination of field values requires separate mechanisms: nullable-required fields (so Claude can explicitly say "I don't know"), format normalization rules in the prompt, validation + retry loops, and multi-pass review.

When should I use a nullable-required field instead of an optional field?

Use nullable-required for fields that are in your schema's domain but may or may not appear in any given source document — for example, discount_code on an invoice. Nullable-required makes Claude always address the field and gives it a schema-legal way to emit null when the source lacks the information. This prevents hallucination and eliminates the key-absent-vs-forgot ambiguity that optional fields introduce. Use truly optional (not in required) only for fields that only make sense for certain document subtypes and should be absent on others.

What is the enum + other pattern and when should I use it?

The enum + other pattern adds a literal "other" value to an enum and pairs it with a companion free-form string field that is required only when "other" is selected. Use it whenever a classification field has a mostly-known set of values but occasionally encounters something new. The pattern preserves strict schema validation for the common cases, preserves downstream analytics on the known categories, and provides a clean escape hatch for new categories without unbounded enum growth. It is the CCA-F-preferred architecture for extensible controlled vocabularies.

What is the difference between a semantic error and a syntax error in structured extraction?

A syntax error is output that violates the JSON schema — missing required field, wrong type, invalid enum value, malformed JSON. Strict tool-use schemas with forced tool_choice eliminate syntax errors at the API level. A semantic error is output that matches the schema but whose values are wrong in the real world — line items that don't sum to the total, dates out of order, values in the wrong field. Semantic errors pass schema validation and are invisible to the schema mechanism. Fixing them requires application-code validation, retry loops with feedback, multi-pass review, or human review workflows. This distinction is the most heavily exploited trap in CCA-F Structured Data Extraction questions.

Should I put format normalization rules in the schema or in the prompt?

In the prompt, not the schema. JSON schemas enforce types and structure; they cannot tell Claude how to parse a raw date string, which currency symbol to strip, or how to map source synonyms to canonical enum values. Format normalization rules (ISO 8601 dates, ISO 4217 currency codes, decimal-separator handling, synonym-to-enum mappings) belong in the system prompt or tool description. Combined with few-shot examples (task 4.2), explicit normalization rules dramatically reduce semantic errors without changing the schema itself. The pattern is schema-for-structure + prompt-for-semantics.

Further Reading

• Claude Certified Architect — Foundations Exam Guide: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Increase output consistency — Anthropic Docs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Strict tool use — schema-guaranteed output: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/strict-tool-use
• Define tools — tool descriptions and tool_choice: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/implement-tool-use
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Handle tool calls — tool_result format and error responses: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Message Batches API — high-volume extraction: https://docs.anthropic.com/en/docs/build-with-claude/batch-processing

Related ExamHub topics: Few-Shot Prompting and Output Consistency, Validation and Retry Loops for Extraction Quality, Tool Definitions and Descriptions, Batch Processing for High-Volume Extraction, Explicit Criteria for Prompt Precision.