Argument Repair with Cross-Field Validation Rules Prompt Template

This prompt is for integration engineers and agent platform developers who need to repair tool call arguments that pass individual field validation but fail cross-field business rules. The core job is to take a tool call, a set of cross-field constraints (like mutual exclusion, co-requirement, or conditional validity), and the original validation error, then produce a corrected argument set that satisfies all rules without breaking the tool's schema. This is not for fixing syntax errors or type mismatches—those are handled by separate repair prompts. Use this when your validation layer has already confirmed that each field is well-formed, but the combination of fields violates a higher-level rule.

The ideal user has a tool registry with defined schemas and a rules engine that can detect cross-field violations. You should have access to the original tool call arguments, the tool's JSON schema, the specific constraint that was violated, and the conversation context that led to the call. Do not use this prompt when the model itself should have known the business rules—if the rules were in the system prompt and the model ignored them, you have a prompt architecture problem, not a repair problem. Also avoid this prompt for simple type coercion or missing field recovery; those have dedicated playbooks with tighter scope and lower latency.

Before wiring this into production, define your constraint vocabulary precisely. Mutual exclusion, co-requirement, conditional validity, and range constraints should each have a standard error format that the repair prompt can parse. The prompt works best when the constraint violation message includes the specific fields involved and the rule that failed. If your validation layer only returns a generic 'invalid arguments' message, this prompt will guess rather than repair. Invest in structured validation errors first, then use this prompt as the recovery step. Always log the original arguments, the constraint violation, and the repaired output for audit and eval.

This template is designed for integration engineers who need to fix tool calls where individual fields are syntactically valid but their combination violates business rules—such as mutually exclusive parameters being set together, co-required fields where one is missing, or conditional validity constraints. The prompt takes the original tool call, the validation error, the tool schema, and the cross-field rules, then produces a corrected argument set that satisfies all constraints. Use this when your agent loop receives a 422 Unprocessable Entity or custom business-logic rejection, not for simple type errors or missing required fields.

textCopy
You are an argument repair assistant for an AI agent system. Your job is to fix tool call arguments that failed cross-field validation rules.

## TOOL SCHEMA
```json
[TOOL_SCHEMA]

CROSS-FIELD VALIDATION RULES

[RULES]

FAILED TOOL CALL

Tool: [TOOL_NAME] Arguments:

jsonCopy
[FAILED_ARGUMENTS]

VALIDATION ERROR

[ERROR_MESSAGE]

CONVERSATION CONTEXT (if available)

[CONVERSATION_CONTEXT]

INSTRUCTIONS

1. Identify which cross-field rule was violated based on the error message and the rules above.
2. Determine the minimal set of changes needed to satisfy all rules while preserving the user's intent as expressed in the conversation context.
3. If the conflict cannot be resolved without clarification, produce a clarification question instead of guessing.
4. Output a JSON object with the following structure:

OUTPUT SCHEMA

jsonCopy
{
  "status": "repaired" | "needs_clarification" | "unrepairable",
  "corrected_arguments": { /* the fixed arguments object, or null if not repaired */ },
  "changes_made": ["description of each change"],
  "clarification_question": "question to ask the user, if status is needs_clarification",
  "confidence": 0.0_to_1.0
}

CONSTRAINTS

• Do not add fields that are not in the tool schema.
• Do not remove fields that were explicitly provided unless required by a rule.
• Prefer the user's explicit values over inferred defaults.
• If multiple repairs are possible, choose the one that requires the fewest changes.
• For [RISK_LEVEL] risk operations, flag the repair for human review even if confidence is high.

To adapt this template, replace the square-bracket placeholders with your actual values. [TOOL_SCHEMA] should contain the complete JSON Schema or OpenAPI parameter definition for the tool. [RULES] should enumerate each cross-field constraint in plain language—for example, "start_date must be before end_date" or "payment_method: wire requires routing_number to be present." [FAILED_ARGUMENTS] is the exact JSON the model produced that triggered the error. [ERROR_MESSAGE] is the raw validation error from your API or business logic layer. [CONVERSATION_CONTEXT] is optional but strongly recommended; include the last few turns of the conversation so the repair prompt can infer user intent rather than making blind edits. [RISK_LEVEL] should be set to high, medium, or low to control whether the repair requires human approval before execution.

Before deploying, test this prompt against a golden set of known cross-field violations with expected repairs. Common failure modes include: the model removing a valid field instead of the conflicting one, producing a repair that passes validation but changes the user's intent, or failing to detect that clarification is needed and guessing incorrectly. For high-risk domains such as financial transactions or healthcare operations, always route status: repaired outputs with confidence below 0.9 to a human review queue. Wire the needs_clarification status back into your agent loop so the system can ask the user and retry with the clarified input.

This prompt is designed to sit directly behind a failed validation step in a tool-call execution pipeline. When a model generates a function call that passes individual field validation but fails a cross-field business rule check, the application should catch the rule violation, package the failure context, and invoke this repair prompt before retrying execution. The prompt expects the original arguments, the tool schema, and the specific cross-field constraint that was violated. It is not a general-purpose repair prompt—it assumes individual fields are already type-valid and focuses exclusively on resolving inter-field conflicts like mutual exclusion, co-requirement, or conditional validity.

To wire this into an application, implement a validation middleware that runs after the model's tool call is parsed but before the function is executed. The middleware should first run standard schema validation (type checks, required fields, enum membership). If that passes, it should then apply your cross-field rule engine. When a rule fails, capture the rule name, the fields involved, the constraint description, and the violation reason. Pass these into the prompt's [CROSS_FIELD_RULES] and [VIOLATION_DETAILS] placeholders alongside the original [TOOL_CALL_ARGUMENTS] and [TOOL_SCHEMA]. The model will return a repaired argument payload. Before executing it, re-run the same cross-field validation to confirm the repair resolved the violation. If it fails again, increment a retry counter and consider escalating to a human or a fallback model after 2-3 attempts. Log every repair attempt with the original arguments, the violated rule, the repaired arguments, and the re-validation result for debugging and eval.

For high-stakes workflows—financial transactions, clinical actions, or irreversible API calls—add a human approval gate after repair. Even if the repaired arguments pass cross-field validation, queue them for review if the repair changed a semantically significant field (e.g., swapping a refund action for a void action to satisfy a mutual exclusion rule). Track which fields were modified by the repair prompt using a structural diff, and flag any repair that alters more than one field or changes a field to a value not present in the original conversation context. For eval, build a test suite of known cross-field violations with expected repairs, and measure both repair success rate (did re-validation pass?) and semantic preservation rate (did the repair change the user's intent?). Use a separate LLM judge prompt to compare the original and repaired arguments for intent drift.