Cross-Field Consistency Validation Prompt for Tool Arguments

This prompt acts as a pre-execution guardrail for integration developers and platform engineers. Its job is to catch logical contradictions in tool call arguments before they reach a downstream API. Use it when a tool schema contains mutual exclusion rules, conditional dependencies (if X is set, Y is required), or conflicting argument pairs that would cause undefined behavior, silent data corruption, or confusing error messages from the target system. This is not a type checker or a required-field validator; it assumes arguments are already well-typed and present. It focuses exclusively on cross-field logical consistency.

Wire this prompt into your tool-call pipeline after schema conformance checks and before dispatch. For example, if your tool accepts start_date and end_date, a type checker confirms both are ISO 8601 strings, but only this prompt catches that start_date is after end_date. Similarly, if a search tool has mutually exclusive query and filter_id parameters, this prompt detects when both are provided and flags the conflict. The prompt outputs a structured consistency report—not a corrected payload—so your application can decide whether to reject, repair, or escalate. Common failure modes include the model missing subtle conditional dependencies (e.g., if payment_method is 'wire', then routing_number is required) or over-flagging valid combinations when rules are ambiguous. Always pair this prompt with a rule-definition schema that explicitly lists each cross-field constraint.

Do not use this prompt for type validation, enum enforcement, or required-field checks—those belong to separate, specialized validators earlier in the pipeline. Do not rely on it for business-rule validation that requires external data (e.g., 'transfer amount must not exceed account balance'), as that demands a stateful check against a live system. For high-risk domains such as finance or healthcare, always route violations to human review rather than automated repair. After reading this section, proceed to the prompt template to copy the exact instructions, then review the implementation harness for wiring it into your application with retries, logging, and eval criteria.

This prompt template is designed to sit between your tool-calling model and the execution layer. Its job is to catch logical contradictions that would pass individual field validation but produce undefined or dangerous behavior when the arguments are combined. Use it when your tool schema includes mutually exclusive options, conditional dependencies ("if X is set, Y is required"), or argument pairs that conflict under specific business rules. The template expects a structured input containing the tool's schema, the generated arguments, and your consistency rules, and it returns a structured report you can use to block, repair, or escalate the call.

textCopy
You are a tool call argument validator. Your task is to check a generated set of tool arguments for cross-field consistency violations before execution.

You will receive:
- A tool schema describing the expected arguments, their types, and any documented constraints.
- A set of generated arguments produced by a model for a specific tool call.
- A list of consistency rules that define logical relationships between arguments.

Consistency rules can include:
- **Mutual exclusion**: Two or more arguments must not be present together (e.g., [MUTUALLY_EXCLUSIVE_ARGS]).
- **Conditional requirement**: If argument [CONDITION_ARG] is present and has value [CONDITION_VALUE], then argument [REQUIRED_ARG] must also be present and non-null.
- **Conditional prohibition**: If argument [CONDITION_ARG] is present, then argument [PROHIBITED_ARG] must not be present.
- **Value dependency**: If argument [ARG_A] has value [VALUE_X], then argument [ARG_B] must have a value from the set [ALLOWED_VALUES_FOR_B].
- **Range consistency**: If both [ARG_A] and [ARG_B] are present, [ARG_A] must be [COMPARISON_OPERATOR] [ARG_B] (e.g., start_date must be before end_date).

For each consistency rule provided, evaluate the generated arguments and determine whether the rule is satisfied or violated.

Output a JSON object with the following structure:
{
  "overall_consistent": boolean,
  "violations": [
    {
      "rule_id": "string identifier for the violated rule",
      "rule_type": "mutual_exclusion | conditional_requirement | conditional_prohibition | value_dependency | range_consistency",
      "description": "human-readable explanation of the violation",
      "conflicting_arguments": ["list", "of", "argument", "names"],
      "conflicting_values": {"arg_name": "value", "arg_name2": "value"},
      "suggested_fix": "actionable suggestion for resolving the conflict, or null if no clear fix"
    }
  ],
  "warnings": [
    {
      "rule_id": "string identifier for a rule that is technically satisfied but suspicious",
      "description": "explanation of why this combination is flagged as a warning"
    }
  ]
}

If no violations are found, return an empty violations array and set overall_consistent to true.

Do not modify the arguments. Only report violations.
Do not execute the tool call.
If the arguments are missing required context to evaluate a rule, note it as a warning rather than a violation.

---

TOOL SCHEMA:
[TOOL_SCHEMA]

GENERATED ARGUMENTS:
[GENERATED_ARGUMENTS]

CONSISTENCY RULES:
[CONSISTENCY_RULES]

To adapt this template, replace the three square-bracket placeholders with your actual data. [TOOL_SCHEMA] should contain the full JSON Schema or OpenAPI parameter definition for the tool, including field descriptions and any inline constraints. [GENERATED_ARGUMENTS] is the raw JSON object your model produced for the tool call. [CONSISTENCY_RULES] is where you encode your business logic as a structured list of rule objects, each with a unique rule_id, a rule_type from the enumerated set, and the specific argument names and values that define the constraint. For high-risk operations such as financial transfers, user deletion, or permission changes, route any output where overall_consistent is false to a human review queue rather than attempting automated repair. For lower-risk operations, you can feed the suggested_fix field into a repair prompt to attempt automatic correction before retrying the call.

This prompt is designed to sit as a pre-execution gate in your tool-calling pipeline, after argument construction but before the tool is dispatched. The typical integration point is a middleware function that receives the proposed tool name and arguments, calls the LLM with this prompt, parses the structured consistency report, and decides whether to proceed, repair, clarify, or escalate. Because cross-field contradictions often indicate upstream errors in intent understanding or argument filling, this validator should run after individual field-level checks (required fields, enum enforcement, type conformance) but before business-rule validation that assumes consistent input.

The implementation should follow a validate-decide-act loop. First, call the model with the prompt template, passing the tool schema, argument payload, and any known dependency rules as [CONSTRAINTS]. Parse the output into a structured report containing a top-level consistent boolean and an array of violations, each with a rule_id, description, and severity. If consistent is true, proceed to execution. If false and all violations are severity: warning, log and proceed with caution. If any violation is severity: error, route to a repair or clarification path. For high-risk write operations, require human review for any error-level violation. Use a strict JSON Schema to validate the model's output before acting on it; if the output fails schema validation, retry once with a stronger format instruction before escalating to a human operator.

For production reliability, instrument every validation call with structured logging that captures the input arguments, the raw model output, the parsed consistency report, and the final dispatch decision. This audit trail is essential for debugging false positives (the validator flags a legitimate combination) and false negatives (a contradiction slips through). Store these logs alongside your tool-call traces. When you observe repeated false positives for a specific rule, add it to the [EXAMPLES] section of the prompt with a correct classification. When you discover a new class of contradiction that the prompt misses, add it to the [CONSTRAINTS] block as an explicit rule. Treat this prompt as living configuration that tightens over time, not a static artifact.