A water-billing adjustment tool accepts an adjustment_amount number with no schema constraint, and a malformed agent call once sent a negative meter reading that silently created an absurd billing credit. Where should this be caught?
Select an answer to reveal the explanation.
Short Explanation
You do not let a teller process a negative deposit and hope the branch manager notices next quarter. A min and max in the schema is the window that stops the bad number at the counter.
Full Explanation
Validation belongs at the boundary where a value first becomes trusted. Once an adjustment_amount crosses into billing logic, every downstream component treats it as a legitimate figure, so a negative meter reading becomes a real credit on a real resident's account. The cheapest place to reject it is before it is ever accepted.
A minimum and maximum constraint declared in the tool's input schema rejects an out-of-range adjustment at the tool boundary, before billing sees it. Because the constraint is part of the contract rather than a downstream check, it applies to every caller uniformly and the rejection carries a reason the agent can act on.
Deferring to a quarterly audit leaves an absurd credit live in the billing system for months, turning a preventable input error into a financial and customer-service incident; trusting the model never to send an out-of-range value assumes the correctness a boundary exists precisely so you need not assume; silently clamping to zero hides the failure, so the call appears to succeed, the adjustment is still wrong, and neither the agent nor a human learns anything went astray.
Exam caveat: rejection has to be legible—a validation failure should return a structured error naming the offending field and the allowed range, not merely refuse. Operational check: send a call with a negative adjustment_amount in a test environment and confirm it is rejected at the schema layer with an actionable error and no write to the billing ledger.