Form Field Dependency Graph Prompt

This prompt is designed for form automation engineers who need to extract and codify the conditional logic embedded in static form documents. The primary job-to-be-done is converting a human-readable form (PDF, paper scan, or static HTML) into a dynamic, interactive digital experience. The ideal user has already completed field-level extraction—identifying labels, types, bounding boxes, and positions for every field on the form—and has also isolated the form's instructional text. This prompt does not perform OCR, field detection, or label association; it assumes those upstream tasks are complete and focuses exclusively on the relationships between fields.

Use this prompt when you need to map three specific dependency types: show/hide (conditional visibility of fields or sections), enable/disable (conditional editability), and populate/validate (auto-fill rules and cross-field validation constraints). The prompt analyzes both explicit dependencies stated in form instructions (e.g., 'If yes to Question 4, complete Section B') and implicit dependencies inferred from layout proximity and grouping (e.g., a set of address fields that appear only when a 'mailing address differs' checkbox is selected). The output is a structured dependency graph where each node is a field and each edge defines a trigger condition, an action, and the affected target fields.

Do not use this prompt when the form logic is already expressed in a machine-readable format like JSON Schema conditionals, XFA, or a dynamic form builder's internal representation. It is also unsuitable for forms where conditional logic is purely sequential (every field depends only on the previous field) without branching, as simpler rule-based parsers will be more reliable. Avoid this prompt when the form instructions are contradictory, heavily redacted, or written in a language the model cannot reliably parse. For high-stakes workflows—such as legal filings, insurance claims, or healthcare intake—always route the generated dependency graph through a human review step before wiring it into a production form renderer, as a missed dependency can cause users to skip required fields or expose irrelevant sections.

This prompt template is designed to be copied directly into your prompt management system or codebase. It instructs the model to analyze a form's field inventory and associated instructions to produce a dependency graph in strict JSON. The graph captures relationships such as show/hide, enable/disable, populate, and validate, along with the trigger conditions and affected fields. The template uses square-bracket placeholders for all dynamic inputs, making it safe to embed in Python f-strings, Jinja2 templates, or any string-substitution system without conflicting with the model's own tokenization.

textCopy
You are an expert form automation engineer. Your task is to analyze the provided form field inventory and form instructions to produce a dependency graph. The graph must capture all conditional logic between fields, including show/hide, enable/disable, auto-populate, and cross-field validation rules.

## INPUT
- **Form Field Inventory:** [FIELD_INVENTORY]
- **Form Instructions:** [FORM_INSTRUCTIONS]
- **Document Layout Context (optional):** [LAYOUT_CONTEXT]

## OUTPUT SCHEMA
Return ONLY a valid JSON object with this structure:
{
  "dependencies": [
    {
      "rule_id": "string",
      "rule_type": "show" | "hide" | "enable" | "disable" | "populate" | "validate",
      "trigger": {
        "field_id": "string",
        "condition": "equals" | "not_equals" | "contains" | "greater_than" | "less_than" | "is_filled" | "is_empty",
        "value": "string | null"
      },
      "target_field_ids": ["string"],
      "action_description": "string",
      "source": "explicit_instruction" | "layout_proximity" | "inferred",
      "confidence": 0.0-1.0
    }
  ],
  "unresolved_ambiguities": [
    {
      "field_ids": ["string"],
      "description": "string",
      "possible_interpretations": ["string"]
    }
  ]
}

## CONSTRAINTS
- Do not invent dependencies that are not supported by the instructions or layout context.
- Distinguish between explicit dependencies (stated in instructions) and implicit dependencies (inferred from layout proximity). Set the `source` field accordingly.
- For implicit dependencies, set `confidence` below 0.8 and include an entry in `unresolved_ambiguities`.
- Handle cross-page references: if a field on page 2 depends on a field on page 1, include the dependency and note the page span in `action_description`.
- Ignore coincidental layout proximity that does not imply a logical dependency.
- If the instructions are ambiguous, do not guess. Document the ambiguity in `unresolved_ambiguities`.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template for your pipeline, replace each bracketed placeholder with data from your document processing system. [FIELD_INVENTORY] should be a structured list of fields extracted from the form, including field IDs, labels, types, and page locations. [FORM_INSTRUCTIONS] is the raw or preprocessed text of any instructions printed on the form itself. [LAYOUT_CONTEXT] is optional but recommended for complex multi-column forms; it should describe spatial relationships between fields. [FEW_SHOT_EXAMPLES] should contain 2-3 annotated examples of correct dependency graphs for forms similar to yours. [RISK_LEVEL] should be set to "high" if the form is used in a regulated domain (legal, healthcare, finance), which will cause the model to apply stricter confidence thresholds and flag more ambiguities for human review. After generating the graph, always validate the JSON structure against your schema before ingesting it into your form automation engine. For high-risk workflows, route any dependency with confidence below 0.9 or source equal to "inferred" to a human reviewer before activating the conditional logic in production.

The Form Field Dependency Graph Prompt is designed to be called after field extraction and label association are complete. The input should be a structured representation of all detected fields—including their labels, types, positions, and page numbers—along with any form instructions or instructional text extracted from the document. This prompt is not a standalone document reader; it requires pre-processed field data from upstream extraction steps. The output is a machine-readable dependency graph (JSON) that your application can consume to dynamically show, hide, enable, disable, populate, or validate fields in a form UI or processing workflow.

Wire this prompt into your pipeline as a post-extraction reasoning step. First, assemble the [FIELD_LIST] as a JSON array of objects, each containing field_id, label, type, page, bounding_box, and value_state (filled/empty). Include [FORM_INSTRUCTIONS] as raw text extracted from the document's instructional sections. Set [OUTPUT_SCHEMA] to require a JSON object with a dependencies array, where each dependency has trigger_field_id, condition (e.g., 'equals', 'is_filled', 'is_checked'), trigger_value, action (e.g., 'show', 'hide', 'enable', 'populate', 'validate'), affected_field_ids (array), and confidence (0-1). Implement a validation layer that checks: (1) all field_id references exist in the input field list, (2) no circular dependencies exist in the graph, (3) confidence values are present for every edge, and (4) cross-page references are explicitly flagged with a cross_page boolean. On validation failure, retry up to two times with the validation errors appended to [CONSTRAINTS]. If retries fail, route the document to a human review queue with the partial graph and error details attached.

For model selection, use a model with strong reasoning capabilities and long-context handling, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. The prompt benefits from models that can reason about spatial layout when bounding box coordinates are provided. Set temperature to 0.1–0.2 for deterministic outputs. Log every invocation with the input field count, output dependency count, validation pass/fail status, retry count, and any human review escalations. This telemetry is critical for detecting drift in extraction quality upstream—if dependency confidence scores trend downward, investigate whether your field label association or OCR steps are introducing noise. Avoid running this prompt on documents with fewer than five fields; trivial forms rarely have meaningful dependencies and waste inference cost. For high-throughput pipelines, consider caching dependency graphs for standard form templates and only invoking the prompt when the form layout or instruction text differs from known templates.