Cross-Field Consistency and Dependency Validation Prompt

Use this prompt when your application generates structured outputs—such as order records, user profiles, configuration objects, or event payloads—where the validity of one field depends on the value of another. The job-to-be-done is automated business logic validation: catching contradictions like a status of 'shipped' with a null tracking_number, a start_date after an end_date, or a payment_method of 'credit_card' with an empty billing_address. The ideal user is a platform engineer, data pipeline owner, or backend developer who needs to validate LLM outputs before they hit a database, API response, or downstream workflow. You need a defined set of dependency rules and a structured output to act on.

This prompt is not a replacement for a deterministic rule engine when your dependency rules are simple, static, and easily expressed in code. If you have five boolean checks, write them in your application layer. Use this prompt when the rules are numerous, expressed in natural language, subject to change, or require nuanced interpretation—for example, a policy document that says 'international orders must include a customs declaration unless the item is a digital good.' The prompt shines when the consistency logic lives in documentation, not just in a schema. It is also not a substitute for JSON Schema validation; run structural checks first, then use this prompt for semantic consistency.

Before wiring this into production, define your dependency rules as a clear, enumerated list in [CONSTRAINTS]. Each rule should specify the fields involved, the condition that triggers a violation, and the severity (error vs. warning). Pair this prompt with a structured output schema so the consistency report is machine-readable. For high-stakes workflows—financial transactions, healthcare records, legal filings—always route violations to a human review queue rather than auto-correcting. The next section provides the copy-ready prompt template you can adapt with your own rule set.

This prompt template is designed to be dropped into an evaluation harness that checks structured AI outputs for internal logical consistency. It goes beyond simple schema validation to verify that field values agree with each other according to business rules—for example, ensuring a status of 'shipped' requires a non-null tracking_number, or that start_date precedes end_date. The template uses square-bracket placeholders so you can adapt it to your specific data model, dependency rules, and risk tolerance without rewriting the core logic.

textCopy
You are a data quality validator specializing in cross-field consistency checks.

Your task is to examine the provided [INPUT_DATA] against a set of dependency rules and produce a structured consistency report.

## INPUT DATA
[INPUT_DATA]

## DEPENDENCY RULES
Evaluate the input against each of the following rules. A rule is violated only when the condition is definitively met.

[DEPENDENCY_RULES]

Example rules format:
- RULE_ID: IF [FIELD_A] equals '[VALUE]' THEN [FIELD_B] MUST NOT be null
- RULE_ID: IF [FIELD_A] is populated THEN [FIELD_B] MUST be greater than [FIELD_C]
- RULE_ID: [FIELD_A] MUST be before [FIELD_B] when both are present

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "consistency_score": <number 0.0 to 1.0, where 1.0 means all rules pass>,
  "total_rules": <number>,
  "rules_passed": <number>,
  "rules_failed": <number>,
  "rules_skipped": <number>,
  "violations": [
    {
      "rule_id": "<string>",
      "rule_description": "<human-readable description of the rule>",
      "status": "FAILED",
      "field_paths_involved": ["<dot-notation path to field>", ...],
      "actual_values": {"<field_path>": "<value or null>"},
      "expected_behavior": "<what should have happened>",
      "severity": "ERROR|WARNING"
    }
  ],
  "skipped_rules": [
    {
      "rule_id": "<string>",
      "reason": "<why the rule was skipped, e.g., required field was null so condition could not be evaluated>"
    }
  ]
}

## CONSTRAINTS
- Only report violations where the rule condition is definitively met and the expected behavior is not satisfied.
- If a rule's condition depends on a field that is null or missing, mark the rule as SKIPPED, not FAILED.
- Use dot-notation for nested field paths (e.g., `order.items[0].price`).
- Assign ERROR severity to violations that would break downstream processing. Assign WARNING severity to suspicious but non-breaking inconsistencies.
- If no rules are provided, return a consistency_score of 1.0 with zero rules evaluated.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is HIGH, you MUST flag any ambiguity as a potential violation and recommend human review.

To adapt this template, replace [DEPENDENCY_RULES] with your actual business rules expressed as conditional statements. Each rule should have a unique ID for traceability in logs and dashboards. The [EXAMPLES] placeholder should contain at least two few-shot examples: one showing a clean record with no violations, and one showing multiple violation types with correct severity assignments. For high-stakes domains like finance or healthcare, set [RISK_LEVEL] to HIGH and ensure the output is routed to a human review queue before any automated action is taken. Wire this prompt into a post-generation validation step where the model's structured output is passed as [INPUT_DATA] immediately after parsing, before it reaches any downstream system.

This prompt is designed to sit inside a post-generation validation pipeline, not as a standalone chat interaction. After your primary LLM generates a structured output (e.g., a JSON order, a patient record, or a CRM update), you route that output to this consistency validator. The validator receives the full payload and a set of dependency rules, then returns a structured report. The application layer should parse this report and decide whether to accept the output, trigger a repair loop, or escalate for human review. The prompt works best with models that have strong reasoning capabilities and support structured output modes, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro, because the task requires multi-field comparison and logical inference rather than simple pattern matching.

Integration pattern: Wrap the prompt in a function that accepts [INPUT_PAYLOAD] (the generated JSON object) and [DEPENDENCY_RULES] (an array of rule objects, each with rule_id, description, condition, and severity fields). The function should call the LLM with response_format set to a JSON schema matching the expected output: { "violations": [{ "rule_id": "string", "field_paths": ["string"], "description": "string", "severity": "critical"|"warning", "evidence": "string" }], "is_consistent": boolean }. Implement a retry strategy with at most 2 retries if the validator itself returns malformed JSON. Log every validation result—including the input payload hash, rule set version, model used, and violation count—to your observability platform for drift detection and audit trails. For high-risk domains like healthcare or finance, always route critical severity violations to a human review queue and never auto-repair without approval.

Failure modes to instrument: The most common production failure is the validator missing a dependency because the rule description is ambiguous. Mitigate this by versioning your rule sets and running regression tests with known-bad payloads before deploying rule changes. A second failure mode is the validator hallucinating violations on large payloads with many fields; if your payloads exceed ~50 fields, consider splitting validation into smaller, domain-specific rule groups and running them in parallel. A third risk is the validator accepting a payload that downstream systems reject due to implicit dependencies not captured in your rules. To catch this, pair the consistency validator with a schema validator from the Format Compliance pillar and run both before ingestion. Start with a rule set of 5-10 high-impact dependencies, measure false-positive and false-negative rates against a golden dataset of 50+ payloads, and expand coverage incrementally.