Produce, validate, and consume Claude output using established patterns.

A claims service asks Claude to return a claim record through a tool whose input schema declares an amount as a number and a claim type as a string. Every returned object parses cleanly and matches the declared types, yet finance has recorded eleven payments last quarter whose amount exceeded the policy cap of 5,000 pounds for the stated claim type. The requirement is that no claim breaching the cap reaches the ledger. Which change to the integration layer meets it?

• ATighten the tool's input schema so that the amount field carries the policy cap for each claim type in its field description, and leave the parsing path unchanged.
• BWiden the exception handling around the parse call so that a record carrying an out-of-policy amount is caught there and re-requested from the model with reworded instructions.
• CConfigure the parser in strict mode so that it rejects any object whose fields do not match their declared types, which will also stop amounts that sit above the policy cap.
• DAdd a validation step after parsing that checks the parsed record against the policy rules for its claim type, and reject any claim above the cap before the ledger write happens.check_circle Correct

Why A is wrong: Tempting because the schema is where the field is defined, so it looks like the natural home for the rule. A description is guidance to the model rather than an enforced constraint, so an over-cap amount can still be produced and still parses cleanly.

Why B is wrong: Tempting because defensive parsing is a real step and does belong at this boundary. A parse succeeds on an over-cap amount, so no exception is raised and the handler never runs.

Why C is wrong: Tempting because strict parsing genuinely removes a class of defect. Type checking answers whether the amount is a number, not whether the number is allowed, so every over-cap payment still passes.

Why D is correct: Correct: schema conformance and business validity are separate questions, and only an explicit validation step run on the parsed object can decide whether a well-formed amount is permitted.