Cross-Field Dependency Resolution Prompt

Use this prompt when assembling a single coherent record from multiple extracted fields where the value of one field constrains or determines the valid values of another. The primary job-to-be-done is resolving these cross-field dependencies—such as a state field restricting valid zip_code formats, or a product_type field dictating which specifications sub-schema to apply—before the record is inserted into a downstream system. The ideal user is an integration engineer or data pipeline builder who already has raw field extractions and needs a dependency-aware assembly step that catches impossible combinations, computes derived fields, and flags conflicts rather than silently producing a structurally valid but logically broken record.

This prompt is not a replacement for initial field extraction. It assumes you already have a set of candidate fields with their raw values and optional confidence scores. Do not use this prompt when you need to extract fields from unstructured text for the first time; start with a strict schema extraction prompt instead. It is also not a general-purpose record normalization tool—use a dedicated normalization prompt if your primary need is date formatting, unit conversion, or identifier canonicalization without dependency logic. Avoid this prompt when your dependency rules are simple enough to encode in application-level JSON Schema validation or a few if statements; the prompt adds latency and cost that is only justified when the dependency graph is complex, conditional, or requires reasoning across multiple fields simultaneously.

Before using this prompt, you must define your dependency rules explicitly. Provide a [DEPENDENCY_RULES] block that specifies which fields constrain others, what the valid combinations are, and what should happen when a constraint is violated (flag, repair, or escalate). Include a [TARGET_SCHEMA] so the model knows the final record shape. Wire the prompt into a harness that validates the output against both structural schema compliance and dependency rule satisfaction. For high-stakes pipelines—financial reporting, clinical data, legal records—always route records with unresolved conflicts or low-confidence resolutions to a human review queue. Start with a small set of known dependency rules and expand as you observe failure modes in production traces.

This template is designed to be dropped into an extraction or assembly pipeline where one field's value constrains another. It expects a set of partially assembled fields, a dependency map, and a set of validation rules. The model resolves dependencies, computes derived fields where possible, and flags conflicts or missing prerequisites. Use this when you have already extracted raw fields and need to enforce business logic before ingestion.

textCopy
You are a record assembly validator. Your job is to resolve cross-field dependencies, compute derived fields, and flag constraint violations in a partially assembled record.

## INPUT
- Partial record: [PARTIAL_RECORD]
- Dependency map: [DEPENDENCY_MAP]
- Validation rules: [VALIDATION_RULES]
- Target schema: [OUTPUT_SCHEMA]

## INSTRUCTIONS
1. For each field in the target schema, determine its value using the following priority:
   a. Use the value from the partial record if present and valid.
   b. If the field is derivable from other fields using the dependency map, compute it.
   c. If the field is required but missing and cannot be derived, mark it as null with a reason code.
2. For each dependency rule in the dependency map, verify that the prerequisite fields are present and valid before computing the dependent field.
3. For each validation rule, check whether the resolved record satisfies the constraint. If not, add a violation entry with severity, field path, and description.
4. Detect circular dependencies. If found, break the cycle by marking all fields in the cycle as unresolved and add a circular_dependency flag.
5. If a field's value changes because of dependency resolution, record the original value, the resolved value, and the rule that triggered the change.

## OUTPUT FORMAT
Return a JSON object with this structure:
{
  "resolved_record": { ... },
  "derived_fields": [
    {
      "field_path": "string",
      "derived_value": "any",
      "rule_applied": "string",
      "prerequisite_fields_used": ["string"]
    }
  ],
  "violations": [
    {
      "severity": "error | warning",
      "field_path": "string",
      "rule": "string",
      "description": "string"
    }
  ],
  "unresolved_fields": [
    {
      "field_path": "string",
      "reason": "missing_prerequisite | circular_dependency | invalid_input | computation_error",
      "detail": "string"
    }
  ],
  "circular_dependencies_detected": [
    {
      "cycle": ["field_path"],
      "description": "string"
    }
  ],
  "resolution_metadata": {
    "total_fields_resolved": 0,
    "total_violations": 0,
    "total_unresolved": 0,
    "resolution_complete": true
  }
}

## CONSTRAINTS
- Do not hallucinate values for fields not present in the partial record or derivable from the dependency map.
- If a prerequisite field is missing or invalid, do not attempt to compute the dependent field.
- Preserve all original values in the resolved record unless a dependency rule explicitly overrides them.
- For date fields, normalize to ISO 8601 format.
- For currency fields, preserve the original currency code; do not convert unless a rule specifies it.

To adapt this template, replace the square-bracket placeholders with your actual data and rules. The [PARTIAL_RECORD] should be a JSON object containing the fields extracted so far. The [DEPENDENCY_MAP] should define which fields depend on which others and how to compute them—for example, "total_price": "[quantity] * [unit_price]". The [VALIDATION_RULES] should specify constraints like "end_date must be after start_date" or "discount cannot exceed total_price". The [OUTPUT_SCHEMA] defines the final shape of the resolved record. If your dependency rules involve complex logic, consider expressing them as a structured array of rule objects with field, depends_on, and compute properties rather than free-text descriptions. This makes the model's job more predictable and reduces ambiguity in rule interpretation.

Before deploying this prompt into a production pipeline, build a test harness with at least these cases: a record with all fields present and no dependencies triggered, a record with a missing prerequisite that blocks derivation, a record with a circular dependency, a record where a validation rule is violated, and a record where a derived field overwrites an existing value. For each test case, assert that the resolved record matches expectations, violations are correctly flagged, and unresolved fields carry the right reason codes. In high-stakes ingestion pipelines where incorrect dependency resolution could corrupt downstream data, route records with severity: error violations or unresolved required fields to a human review queue before insertion.

The Cross-Field Dependency Resolution Prompt is not a standalone utility—it is a processing stage that sits between raw field extraction and downstream record ingestion. In a typical pipeline, you first extract individual fields from unstructured text using extraction prompts, then pass those extracted fields into this dependency resolution stage. The prompt expects a structured input containing the extracted fields, a dependency map that defines how fields constrain each other, and a target output schema. The output is a resolved record where dependent fields are validated, derived fields are computed, and any conflicts or missing prerequisites are flagged with explicit markers.

To wire this into an application, build a harness that constructs the prompt payload from three sources: the extracted fields from the previous pipeline stage, a dependency configuration stored as code or configuration (not inline in every prompt), and the target record schema. The dependency configuration should define constraint rules such as if field_a == X then field_b must be in [Y, Z], derivation rules like field_c = field_a + field_b, and prerequisite rules such as field_d requires field_e to be present. Before sending the prompt, validate that all required inputs are present—if prerequisite fields are missing, the harness should either abort with a clear error or route to a partial-record completion stage instead. After receiving the model response, validate the output against the target schema, check that all dependency flags are properly structured, and verify that no hallucinated fields appear that were not in the input or derivation rules.

For production reliability, implement a retry layer with a maximum of two retry attempts. On the first failure—whether from schema validation errors, malformed JSON, or missing required fields—construct a repair prompt that includes the original input, the failed output, and the specific validation error messages. If the second attempt also fails, log the full input-output-error trace and escalate to a human review queue rather than silently ingesting broken records. Model choice matters here: use a model with strong structured output capabilities and low hallucination rates for schema-constrained generation. For high-throughput pipelines, consider batching multiple records into a single prompt call with clear delimiters, but keep batch sizes small (3-5 records) to avoid cross-record contamination. Always log the dependency configuration version, model version, and prompt template version alongside each resolved record for auditability.

The most common production failure mode is circular dependencies in the configuration. Before any prompt call, run a static analysis pass on the dependency map to detect cycles—if field A depends on B and B depends on A, the prompt cannot resolve this and will produce inconsistent results. Build this check into your CI/CD pipeline for dependency configuration changes. Another failure mode is ambiguous constraint resolution where multiple valid interpretations exist; the prompt is instructed to flag these rather than guess, so your harness must handle ambiguity flags by routing to a review queue or applying a deterministic tie-breaking rule from your business logic layer. Finally, never use the resolved output as ground truth without human review when the conflict flags are non-empty or when derived fields involve financial, legal, or clinical calculations—these should always pass through a human approval step before ingestion.