Structured Data Request Prompt for Incomplete Forms

This prompt is designed for operations teams and workflow automation engineers who process user-submitted forms through an AI pipeline. Its job is to act as a pre-processing gate: it inspects a submitted form against a defined schema of required fields, identifies any missing or invalid entries, and generates a structured, polite, and specific request for the missing information. Use this prompt when you need to prevent silent failures, partial data ingestion, or downstream processing errors caused by incomplete submissions. It belongs in the workflow immediately after form intake and before any data transformation, storage, or action is taken.

This is not a prompt for validating data types or business logic; it focuses exclusively on completeness checks and user-facing clarification generation. Do not use this prompt when you need to enforce regex patterns, cross-field validation rules, or database uniqueness constraints—those checks belong in your application layer or a separate validation prompt. Similarly, avoid this prompt when the form submission is part of an internal API where the caller can be programmatically corrected; the polite, user-facing tone is designed for human submitters who need clear guidance on what to fix. The ideal user is a platform engineer or automation developer who already has a defined form schema and needs a reliable, testable gate that produces structured interruption payloads rather than vague error messages.

Before implementing this prompt, ensure you have a machine-readable schema of required fields with field names, expected types, and human-readable descriptions. The prompt's effectiveness depends entirely on the quality of this schema input. If your schema is ambiguous or incomplete, the prompt will produce inconsistent results. Wire this prompt into your workflow with a clear contract: it should receive the raw form submission and the schema, and it must return a structured JSON response that your application can parse to either proceed with processing or surface the clarification request to the user. For high-stakes workflows involving financial, healthcare, or compliance data, always include a human review step before the generated clarification request is sent to the end user, and log every gate decision for auditability.

This prompt template is designed to be placed directly into your system instructions or a pre-processing step in your AI workflow. It forces the model to act as a strict completeness gate before any downstream processing occurs. The prompt instructs the model to compare a provided form submission against a defined schema of required fields, and if any are missing, to halt all other work and output a structured JSON request for the missing information. This prevents silent failures and partial completions that can corrupt databases or confuse users.

textCopy
You are a Form Completeness Validator. Your only job is to check if a user's form submission contains all required fields. You must not answer questions, perform actions, or generate any content other than the validation report.

# INPUTS
- Form Submission Data: [FORM_DATA]
- Required Field Schema: [REQUIRED_SCHEMA]
- User Language Preference: [LANGUAGE]

# TASK
1. Parse the [FORM_DATA] and the [REQUIRED_SCHEMA].
2. Identify every field defined in the [REQUIRED_SCHEMA] that is missing, null, or an empty string in the [FORM_DATA].
3. If all required fields are present and non-empty, output a JSON object with `"status": "complete"`.
4. If any required fields are missing, output a JSON object with `"status": "incomplete"` and a structured request for the user.

# OUTPUT_SCHEMA
{
  "status": "complete" | "incomplete",
  "missing_fields": [
    {
      "field_name": "string",
      "field_label": "string",
      "reason_required": "string",
      "clarification_prompt": "string"
    }
  ],
  "user_facing_message": "string"
}

# CONSTRAINTS
- The `user_facing_message` must be a single, polite, and concise paragraph in [LANGUAGE] that introduces the list of missing items.
- The `clarification_prompt` for each missing field must be a specific, easy-to-understand question in [LANGUAGE] asking for that exact piece of data.
- The `reason_required` must explain *why* the field is needed (e.g., "to verify your identity", "to process your payment") based on the context in [REQUIRED_SCHEMA].
- Do not hallucinate missing fields. Only report fields defined in [REQUIRED_SCHEMA] that are genuinely absent from [FORM_DATA].
- If the form is complete, the `missing_fields` array must be empty and `user_facing_message` must be null.

To adapt this template, replace the placeholders with your specific context. [FORM_DATA] should be the raw JSON or key-value pairs from the user's submission. [REQUIRED_SCHEMA] is a critical input; it should be a structured definition (like a JSON Schema subset or a simple list of objects) that includes not just the field names but also their human-readable labels and the business reason they are required. This allows the model to generate helpful, specific clarification_prompt and reason_required values. [LANGUAGE] can be a static value like 'English' or dynamically injected based on the user's locale. After pasting this prompt, the next step is to build a thin application harness that parses the JSON output and routes it: a 'complete' status proceeds with the workflow, while an 'incomplete' status surfaces the user_facing_message and the list of missing_fields back to the user interface.

The Structured Data Request Prompt for Incomplete Forms is designed to sit between form ingestion and downstream processing. When a user-submitted form arrives, the application should first run a lightweight schema validator to catch obvious structural issues (missing JSON keys, null required fields, type mismatches). If the validator passes, the form proceeds directly to processing. If it fails, the application constructs the prompt with the original form payload as [FORM_PAYLOAD], the required field specification as [REQUIRED_FIELDS_SCHEMA], and any business context as [FORM_PURPOSE]. The model's job is not to fix the data but to generate a precise, user-facing clarification request that lists exactly what is missing and why each field matters.

Wire the prompt into a pre-processing middleware that intercepts incomplete payloads before they reach your core workflow. The middleware should: (1) deserialize the incoming form, (2) run structural validation against your schema, (3) on failure, call the LLM with the prompt template and capture the response, (4) validate the LLM output against the [OUTPUT_SCHEMA] (expecting missing_fields as an array of objects with field_name, description, and why_required), and (5) return the structured clarification request to the user or queue it for human review. Use a retry budget of 2 if the LLM output fails schema validation; if it still fails, fall back to a templated error message built from the validator's raw output. Log every interruption event with the form ID, detected missing fields, generated request, and whether it was auto-sent or escalated.

For high-risk domains (healthcare intake, financial applications, legal submissions), do not auto-send the clarification request to the end user. Route the generated request to a human review queue where an operator can verify that the missing-field detection is accurate, the tone is appropriate, and no sensitive data is exposed in the request. Attach the original form payload (redacted as needed) and the validator output so the reviewer has full context. Only after approval should the clarification request be dispatched. This gate prevents the model from asking for information the user already provided but the validator misclassified, or from exposing internal field requirements in a way that confuses or alarms the user.

Model choice matters here. This prompt requires strong instruction-following and structured output discipline, not creative reasoning. GPT-4o, Claude 3.5 Sonnet, and Gemini 2.0 Flash all perform well with low temperature (0.0–0.2). Avoid smaller or older models that may conflate missing-field detection with field repair or generate conversational fluff instead of the strict output schema. If you're running this at high volume, cache the [REQUIRED_FIELDS_SCHEMA] and [FORM_PURPOSE] in the system prompt prefix to reduce token spend. For multi-tenant SaaS platforms, ensure the [TENANT_ID] is injected into the logging context and that no cross-tenant form data leaks into the prompt assembly.

Testing and eval: Build a golden dataset of 50+ incomplete form variants covering single missing fields, multiple missing fields, fully empty submissions, edge-case field names, and forms where all required fields are present but empty strings. For each test case, assert that the output contains exactly the missing fields, no hallucinated additions, and no field repairs. Measure precision (did it flag only truly missing fields?) and recall (did it catch every missing required field?). If precision drops below 0.95, add few-shot examples showing the distinction between 'missing' and 'present but empty.' If recall drops, check that your [REQUIRED_FIELDS_SCHEMA] is unambiguous and that the model isn't ignoring conditional requirements. Run these evals on every prompt version change before deployment.