When a Repair Changes the Meaning: Validating Corrected Arguments

Structured outputs and JSON Schema enforcement solve the format problem. A schema can require that amount is a number, that currency matches a three-letter pattern, that due_date follows a date format, and that certain fields are present. Native structured output modes and libraries that wrap them exist precisely because free-form parsing is fragile and models change behavior between versions (Agenta).

Schema enforcement is also cheaper than it looks. A validator that sits between the model and the tool turns malformed arguments into a rejected call with a clear error, instead of a crash or a silent misuse downstream (Micheal Lanham on schema gating). If you do nothing else, do this.

But the same sources are explicit about the limit. Valid JSON is not a contract with meaning, and strict schema output narrows the interface only within its supported keywords; a schema-valid customer ID, amount, date or resource can still violate domain rules (TrueFoundry). Concretely:

• {"currency": "USD"} passes a pattern check. It does not prove the user meant US dollars rather than Canadian.
• {"due_date": "2026-03-04"} passes a date format. It does not prove the original 04/03 meant March 4 rather than April 3.
• {"amount": 1500} passes a type check. It does not prove 1500 is dollars rather than cents.

Each of those is a repair that a schema accepts and a semantic check should reject.

These are the drift cases worth building tests around. They are chosen because each passes at least one common schema check.

Take the currency case with numbers. Suppose the caller meant 100 US dollars. A repair that appends CAD produces a valid request whose settlement value is about 70 to 75 US dollars at typical exchange rates, which you should read from your own treasury feed rather than from memory. The tool call succeeds. The invoice is short by roughly a quarter. No error is logged, because nothing went wrong at the schema level.

The unit case is worse in multiplier terms. One and a half hours becomes thirty six hours. Any downstream capacity check that compares hours to a threshold will approve or reject on a number a factor of twenty four away from the intent.

The recipient case is the one that most resembles identity mistakes in agent systems. Agent frameworks retry calls by regenerating them from model reasoning, and a regenerated request is rarely byte-identical to the original, so text comparison is insufficient for spotting a duplicate or a substitution; you need an explicit key or fingerprint (Trussed). The same holds for a repaired recipient: you need to compare resolved identifiers, not strings.

The pipeline below runs after repair and before execution. It is deliberately boring: five gates, each of which can reject or escalate.

1. Preserve the original. Store the raw argument, the repaired argument and the error that triggered the repair. Without the raw value you cannot run any semantic comparison later, and cannot audit what happened.
2. Schema gate. Types, formats, required fields, enum membership. Reject on failure and return a structured error to the model rather than a stack trace, so the next attempt has something to reason about (n8n blog).
3. Canonicalization gate. Convert both the original and the repaired value into one canonical form: minor currency units with an explicit currency code, ISO 8601 dates with a time zone, base units for quantities, resolved entity IDs for people and accounts.
4. Equivalence gate. Compare canonical forms, not strings, with tolerances per field type. Currency must match exactly after conversion at a pinned rate. Dates must match to the day unless a time was specified. Quantities must match exactly. Entity IDs must be identical.
5. Consequence gate. Ask what the action does if it executes. If the action is read-only and the repair is equivalent, proceed. If it moves money, sends a notification, deletes or creates records, require confirmation on any mismatch.

A compact implementation of steps 3 and 4:

def canonical_repair(original, repaired):
    return {
        "amount_minor": to_minor_units(repaired["amount"]),
        "currency": repaired["currency"].upper(),
        "due_date": to_iso_date(repaired["due_date"]),
        "duration_hours": to_hours(repaired["duration"], repaired["unit"]),
        "recipient_id": resolve_entity(repaired["recipient"]),
    }

def equivalent(a, b, tolerances):
    for field, tol in tolerances.items():
        if field.endswith("_id"):
            if a[field] != b[field]:
                return False, field
        elif abs(a[field] - b[field]) > tol:
            return False, field
    return True, None

Run this against the original arguments canonicalized the same way. Any field failing equivalence is a candidate for escalation, and the failing field name should be logged, because the distribution of failures tells you which repairs to stop attempting.

The framing matters: a tool call with a typed name and argument object describes an intended action, and runtime authorization decides whether that action may happen (TrueFoundry). Repair validation is the layer between "the arguments parse" and "this action is authorized", and it is where the meaning gets checked.

If you are running this across several model providers, note that structured output support and schema keyword coverage differ by provider, so the same repair code can behave differently behind each one. An OpenAI-compatible gateway such as Quanta Inference lets you keep one validation pipeline while switching the model underneath.

Not every repair deserves the same scrutiny. Sort actions by reversibility and by whether an external party sees the effect.

This mirrors the least-privilege principle for agents: give each agent the minimum set of tools and actions its task requires, and insert human checkpoints for higher-risk or irreversible actions rather than allowing unattended execution (Okta, Trussed on semantic drift detection). Repair policy is part of that scoping. A tool that can only read should be repaired freely; a tool that can pay should not be repaired silently at all.

There is a cost angle too. Retries replay conversation history rather than a single failed step, so a modest per-step failure rate compounds into roughly two times the token spend on longer agent runs, and the bill is invisible on latency and error dashboards (Tianpan). Repairs that thrash, failing semantic equivalence and regenerating repeatedly, are a retry pattern by another name. Cap them per session.

Build a repair test set from your own logs. For each historical repair, record the original argument, the repaired argument, the expected canonical equivalence verdict, and the action class. Then assert on the verdict, not on the strings. Two additional practices pay for themselves:

• Golden pairs per field type. At minimum one pair for currency, date, unit, enum alias and recipient. Keep them in the repository and run them whenever the repair prompt, model or schema changes.
• Post-update revalidation. After any model, prompt or tool change, re-test agent behavior before it reaches production traffic, since decision boundaries shift in ways that are not visible in normal monitoring (Trussed).

Keep a term owner for each argument type, the way organizations assign ownership of metric definitions when the same word means different things across systems (AtScale). A repair that resolves active customer one way in one tool and another way in the next is the same failure at a different layer, and it is fixed the same way: one canonical definition, checked at execution time.

If the affected data sits behind a database, push enforcement down to the data layer where it can be governed deterministically, which is the core argument for row-level access control in front of LLM-driven queries (Tinybird, Snowflake). Restricting which rows query users can see at the engine level means a mis-repaired filter argument cannot exfiltrate more than the caller is already entitled to.