Match structured interfaces to acceptance gates

Learning objective

Select or combine native JSON outputs and strict tool inputs at their respective interfaces, with semantic post-validation, calibrated review routing, and safe failure behavior.

Core idea

For an architect composing a production workflow, native JSON outputs and strict tool inputs protect different consumers. output_config.format constrains the final response; strict: true constrains emitted tool arguments. The Professional decision is how to combine those interfaces with acceptance rules so that a well-shaped but unsupported result cannot advance to a business action.

Assume the extraction and semantic-validation mechanisms. Here you assign contracts to stages, calibrate the route to review, and preserve a safe outcome when generation or validation cannot complete. An accepted tool call, an accepted final report, and an authorized external write remain three separate decisions; see 1.2.2 for the write boundary.

How it works

Allocate enforcement to the two consumers

Use output_config.format for the final JSON record and strict: true with input_schema for emitted tool arguments; combine them when the workflow has both consumers. Assign each consumer an owner and an acceptance artifact: the executor validates the proposed operation against trusted state, while the report consumer checks claims against the actual tool results and supplied evidence.

For a supplier assessment, the executor checks the proposed supplier identifier before the lookup, and the report consumer refuses to label the supplier verified unless the lookup produced the required authorized evidence. Record evidence, validation_failures, and review_status as application fields. A final report that passes its schema cannot retroactively validate an earlier operation.

Structured outputs are generally available on supported models through the Claude API, Claude Platform on AWS, Google Cloud, and Microsoft Foundry, while Amazon Bedrock support is limited to the legacy integration for Opus 4.6, Sonnet 4.6, Sonnet 4.5, Opus 4.5, and Haiku 4.5 and excludes Claude in Amazon Bedrock. Verify the exact deployment before designing a shared adapter around that guarantee.

Leave margin in combined schema complexity

The request permits twenty strict tools, twenty-four optional parameters, and sixteen union-typed parameters, counted across strict tool and JSON output schemas. Budget the composition: a report with eight optional fields and four tools with four optional fields each already reaches twenty-four. These are example schemas.

The explicit counts are not the entire boundary. Interacting nesting, optional fields, and union types can exceed internal compiled-grammar limits even when every listed count passes. The API returns HTTP 400 with “Schema is too complex for compilation.” It also enforces a 180-second compilation timeout for grammars that pass explicit checks but compile too slowly. Budget compilation against the caller’s deadline.

Reduce optional parameters and simplify nesting before dividing the workflow into requests or sub-agents. Make a field required only when its semantics justify an explicit supplied value. If the operation must retain strict enforcement, do not remove it to clear a compilation error; split the interfaces and evaluate the added calls against the end-to-end deadline. Test the combined schema as a deployment artifact, not each tool independently.

Retain the supported-subset and enum-casing rules: objects require additionalProperties: false, unsupported numerical wire constraints return 400, SDK-stripped constraints need client validation, and string enum/const comparisons must tolerate case differences. These rules locate checks; they do not establish that the report’s values follow from the evidence.

Calibrate acceptance and review together

Choose review thresholds from held-out, task-specific labeled cases, then compare accepted-case error and review volume by field and workload segment. Suppose the target is no more than one percent incorrect accepted supplier identifiers, with reviewers available for twenty percent of cases. These are business requirements in this example. A threshold is deployable only if both measurements meet their target; a good aggregate score that fails handwritten documents is insufficient for that segment.

Test the trade-off using the same workload distribution for candidate thresholds. If no threshold meets both constraints, reduce automated coverage, change the extraction or evidence path, or increase review capacity. Keep unresolved work queued; give procurement the coverage loss and staffing requirement.

Verified conflicts, unresolved ambiguity, failed business rules, and unvalidated segments override the score. Reviewers need the candidate, the competing evidence, and the failed rule, with permission to leave the case unresolved. Sample accepted cases independently for audit: low-score review outcomes alone cannot measure confident errors in the accepted population.

Recalibrate after a prompt, retrieval, model, or schema change before treating the earlier threshold as release evidence. Preserve denominators and case mix. The acceptance owner releases the threshold with the evaluated configuration; see 1.2.4 for the feedback and release loop.

Recover the workflow without weakening acceptance

Keep native citations separate from output_config.format, because that combination returns 400; when JSON carries source identifiers and quotes instead, verify those application fields against the actual sources. Anthropic’s grounding guidance recommends direct quotes and verification against supporting text. That check belongs before approval, including after recovery on another inference path.

A missing required operation or unresolved lookup leaves the assessment incomplete even if its final JSON parses; strict inputs do not force a call under tool_choice: {"type": "auto"}. Save accepted lookup evidence and retry only the unresolved stage, preserving the write identity described in 1.2.2. A stop_reason: "max_tokens" result needs a higher-max_tokens retry within the remaining deadline; exhausted recovery leaves dependent purchasing blocked.

For classifier refusals, the documented models are Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Sonnet 5.5, and Claude Haiku 5.5: branch on stop_reason: "refusal" and retain stop_details.category, which can be null. Do not assume this classifier-detail contract for every model. Anthropic says sending the same request to another Claude model can usually recover an answer.

One mechanism is fallbacks: "default" with anthropic-beta: server-side-fallback-2026-07-01, beta on the Claude API, excluding Message Batches, Amazon Bedrock, Google Cloud, and Microsoft Foundry. It retries on the recommended model for the refusal category; if no fallback is recommended, the refusal stands. Claude Haiku 5.5 has no server-side fallback; use client-side or manual retry instead. Choose an approved recovery path whose evidence, schema, and deployment requirements still satisfy the assessment, or keep refusal terminal. Never publish partial refusal output as the report.

Verification against the actual sources belongs before approval, including after recovery.

Key distinctions and trade-offs

Per-interface shape versus workflow completion: Two valid payloads do not establish that the lookup succeeded or that the final claims use its evidence.

Explicit limits versus compilation budget: Staying below the three counts avoids those specific violations, but does not guarantee compilation or acceptable response time.

Recovery versus acceptance: Another model or another attempt supplies another candidate. It does not remove evidence checks or authorize the downstream write.

Splitting requests reduces combined grammar complexity and exposes intermediate checks, but adds round trips and state to operate. More mandatory review lowers automatic coverage and adds latency. Evaluate both costs against the business deadline and accepted-case quality target.

Architecture / decision scenario

A healthcare procurement team assesses suppliers within four hours, with twenty percent reviewer capacity and a one-percent accepted-identifier error target. Its strict read-only supplier lookup feeds a native JSON assessment; a separate purchasing service handles approved orders.

The architect compares one combined request with separate lookup and assessment requests. Schema tests reveal a compilation-complexity 400 despite passing the explicit counts. The team reduces optional fields and nesting, then splits the interfaces when that remains insufficient. The four-hour target permits the extra call, and accepted lookup evidence remains available if assessment generation needs recovery.

Held-out evaluation selects the identifier threshold, and accepted-case audits test the error target. A confident identifier conflicting with the registry goes to review, as does an unvalidated handwritten segment. If review exceeds capacity, procurement defers cases rather than forwarding unchecked assessments.

The team keeps classifier refusal terminal: its approved deployment has no evaluated alternate model, so it does not enable server-side fallback merely to improve completion rate. A token-limited assessment receives the higher-max_tokens retry if time remains; a failed or refused assessment cannot permit purchasing. This preserves the approval gates and exposes the recovery cost.

Common exam traps

• Testing each schema separately and assuming their combination will compile.
• Budgeting to the explicit counts without internal grammar or compilation-time margin.
• Relying on a field description or SDK-stripped constraint to enforce a numeric business rule.
• Reusing an acceptance threshold after an unevaluated configuration change.
• Treating confident unresolved evidence or scarce reviewers as grounds for acceptance.
• Enabling fallback without an approved model and revalidation path.

What to remember

Allocate shape enforcement to each consumer, budget the combined grammar with margin, and calibrate review against quality and capacity together. Recover only through paths that preserve the original evidence and acceptance requirements. Unresolved assessment means no dependent business action.

Knowledge check

References

• Anthropic, Structured outputs
• Anthropic, Strict tool use
• Anthropic, Reduce hallucinations
• Anthropic, Define success criteria and build evaluations
• Anthropic, Refusals and fallback
• Anthropic, Define tools