Pre-Execution Field Audit Prompt Template

This prompt is designed for operations engineers and platform teams who need to enforce a data quality gate before an automated workflow proceeds. The core job-to-be-done is auditing a single record or payload against a configurable completeness specification and generating a structured, machine-readable pass/fail report with per-field status. It is ideal for preventing silent failures, partial completions, or downstream corruption caused by missing required fields in agent pipelines, ETL jobs, or API-driven automation. The user is typically an engineer who understands the data contract and needs a reliable, context-aware gate that can be wired into a pre-execution hook.

Use this prompt when you need a semantic completeness check that goes beyond simple schema validation. Unlike an API contract validator that checks for type correctness, this prompt understands context-dependent requirements and severity thresholds. For example, a customer_email field might be optional for a lead record but critical for a contract_signing event. The prompt evaluates each field against a specification that defines whether it is required, optional, or conditionally_required based on other field values, and assigns a severity (BLOCKER, WARNING, INFO) to each violation. This allows the calling application to decide whether to halt execution, log a warning, or proceed with caution.

Do not use this prompt as a replacement for static schema validation at the API boundary. It is not designed to validate JSON Schema, XML Schema, or Protobuf contracts; those checks should happen in the application layer before the payload reaches this audit. Also avoid using this prompt for real-time, latency-sensitive transactions where a 500ms-2s LLM call is unacceptable. For high-throughput streaming data, pre-filter with deterministic rules and reserve this prompt for edge cases or records that fail initial validation. In regulated domains such as finance or healthcare, always route BLOCKER-level audit failures to a human review queue and log the full audit report for compliance evidence.

Before implementing, define your completeness specification as a structured object that the prompt can consume. Each field rule should include the field name, its requirement level, any conditional dependencies, and the severity of a violation. The output is a JSON report with an overall audit_result (PASS, FAIL, WARNING) and a field_results array containing each field's status, missing value indicator, and a human-readable reason. Wire this prompt into your workflow's pre-execution hook, parse the JSON response, and use the audit_result to gate the next step. Start with a small set of critical fields and expand the specification as you observe false-positive and false-negative patterns in production.

The following prompt template is designed to be pasted directly into your prompt layer. It accepts a target record, a completeness specification, and optional severity thresholds. Every variable is enclosed in square brackets. Replace each placeholder with the actual data, schema, or configuration value before sending the prompt to the model. The prompt instructs the model to perform a strict field-by-field audit and return a structured report—never a conversational summary.

textCopy
You are a pre-execution field audit system. Your only job is to compare a target record against a completeness specification and produce a structured pass/fail report.

## INPUT
Target Record:
[RECORD]

Completeness Specification:
[SPECIFICATION]

Severity Thresholds:
[SEVERITY_THRESHOLDS]

## TASK
1. Parse the completeness specification. It defines required fields, optional fields, data-type constraints, format patterns, and cross-field dependency rules.
2. For every field listed in the specification, determine whether the target record satisfies the requirement.
3. Assign each field a status: PASS, FAIL, or NOT_APPLICABLE.
4. For every FAIL status, include:
   - The field name.
   - The specific requirement that was violated.
   - The actual value found (or indicate that the field is absent).
   - A severity level: BLOCKER, WARNING, or INFO, based on the severity thresholds provided.
5. If any field has a BLOCKER severity, set the overall audit result to FAIL. Otherwise, set it to PASS_WITH_WARNINGS if any WARNING exists, or PASS if all fields pass.
6. Do not invent fields. Do not guess missing data. If the specification references a field that is absent from the record, report it as FAIL with severity BLOCKER unless the specification marks it optional.

## OUTPUT_SCHEMA
Return a single JSON object with this exact structure:
{
  "audit_result": "PASS" | "PASS_WITH_WARNINGS" | "FAIL",
  "audit_timestamp": "ISO-8601 timestamp of audit completion",
  "fields": [
    {
      "field_name": "string",
      "status": "PASS" | "FAIL" | "NOT_APPLICABLE",
      "requirement": "string describing the rule that was checked",
      "actual_value": "string or null",
      "severity": "BLOCKER" | "WARNING" | "INFO"
    }
  ],
  "blocker_count": 0,
  "warning_count": 0,
  "info_count": 0
}

## CONSTRAINTS
- Do not add commentary outside the JSON object.
- Do not omit fields that are present in the specification.
- If the target record is empty or missing, report every required field as FAIL with severity BLOCKER.
- Respect the severity thresholds. A field that violates a BLOCKER rule must never be downgraded.

To adapt this template, replace [RECORD] with the actual payload, database row, form submission, or API request body under audit. Replace [SPECIFICATION] with a structured description of required fields, types, formats, and dependency rules—this can be a JSON schema fragment, a YAML policy block, or a plain-text field list. Replace [SEVERITY_THRESHOLDS] with rules that map violation types to severity levels, such as 'missing required field → BLOCKER' or 'format mismatch → WARNING'. After substitution, validate that the output schema is still reachable by running the prompt against a known-good and known-bad record before deploying it into a production gate. If the workflow involves regulated data or irreversible actions, always route BLOCKER results to a human review queue before proceeding.

The Pre-Execution Field Audit prompt is designed to act as a synchronous gate before any downstream action. Wire it into your application as a blocking step: the system sends the payload and the completeness specification to the model, receives the pass/fail report, and only proceeds if audit_result is pass. If the result is fail, the application must halt execution and route the structured failure report to the appropriate handler—typically a human review queue, a notification system, or a retry loop that requests missing data from the user. This prompt is not a background check; it is a hard gate. The application layer must enforce the pass/fail decision; never rely on the model's output alone to block execution without a code-level guard that checks the audit_result field before calling the next step.

Validation and retry logic: Parse the model's JSON output immediately. Validate that audit_result is exactly pass or fail. If the field is missing or malformed, retry the prompt once with an explicit error message appended to the context: The previous output was missing the required 'audit_result' field. Return a valid JSON object with 'audit_result' set to 'pass' or 'fail'. If the second attempt also fails, escalate to a human operator with the raw payload and specification attached. For high-stakes workflows (financial transactions, configuration changes, data deletion), add a secondary validation step: if audit_result is pass, randomly sample 5-10% of passed audits for human spot-checking to detect false positives where the model incorrectly approved an incomplete payload. Log every audit result—pass or fail—with the full payload, specification, model version, and timestamp for audit trail purposes.

Model choice and tool use: This prompt works best with models that have strong JSON output capabilities and low latency, since it sits on the critical path of a workflow. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable defaults. Avoid using smaller or faster models without testing them against your specific field rules and severity thresholds; false negatives (incorrectly passing incomplete payloads) are the primary risk. Do not give this prompt access to tools or function calling—it should produce a self-contained JSON report without side effects. If your completeness specification is large or dynamic, store it as a configuration object in your application and inject it into the [COMPLETENESS_SPEC] placeholder at runtime rather than hardcoding it in the system prompt. For RAG-augmented audits where field rules depend on external policy documents, retrieve the relevant policy sections first, inject them into the specification, and then run the audit prompt.

Human review integration: When the audit fails, the field_status array in the output is your primary handoff artifact. Route it to a review queue with the original payload, the failing fields highlighted, and the severity levels preserved. The reviewer should be able to override the failure (with a required justification logged for audit), request missing data from the submitter, or reject the payload permanently. Never allow the system to automatically retry the action after a human override without re-running the audit prompt against the corrected payload. For compliance-heavy environments, store the full audit report alongside the action record so that downstream reviewers can see exactly which fields were checked and what the model found.