Required Field Presence Check Prompt

This prompt is for integration engineers and agent harness developers who need a deterministic, auditable gate before an agent step executes. Its job is to validate that every mandatory input field is present, non-null, and well-formed according to a provided schema. Use it when the cost of a downstream failure—such as a corrupted database write, a malformed API call, or a silent null propagation—is higher than the latency cost of an upfront check. The primary reader is a developer wiring this prompt into a pre-execution hook within an agent loop, a data pipeline validator, or a form submission handler.

Do not use this prompt when the input schema is ambiguous, when field optionality depends on complex business logic better handled in application code, or when the model's probabilistic nature introduces unacceptable risk for strict boolean pass/fail decisions. This prompt is not a substitute for JSON Schema validation in your application layer; it is a semantic complement that can reason about placeholder values like 'TBD' or 'N/A' that a structural validator might miss. For high-risk domains such as finance or healthcare, always pair the model's completeness checklist with a deterministic schema validator and log any disagreement for human review.

The prompt expects a structured [INPUT_PAYLOAD] and a [FIELD_DEFINITIONS] schema that declares each field's name, type, required status, and any format constraints. It produces a completeness checklist with explicit pass/fail per field and remediation suggestions for missing data. Before integrating, define your bail-out behavior: the harness should parse the model's output, check for any status: "fail" entries, and either block execution with a structured error response or route to a human for manual completion. The next section provides the copy-ready template.

This template is designed to be dropped into a pre-execution validation harness. It forces the model to act as a strict schema validator, not a conversational assistant. The prompt accepts a list of required fields and the actual input payload, then produces a deterministic pass/fail report per field. Use this when the cost of executing a step with missing data is higher than the cost of an upfront check—common in database writes, API calls with side effects, and regulated workflows where partial execution creates audit complexity.

textCopy
You are a strict input validation engine. Your only job is to check whether all required fields are present in the provided input payload. Do not infer, guess, or fill in missing values. Do not execute any downstream task. Do not produce conversational text outside the output schema.

[CONTEXT]

REQUIRED FIELDS:
[REQUIRED_FIELDS]

INPUT PAYLOAD:
[INPUT_PAYLOAD]

[OUTPUT_SCHEMA]

[CONSTRAINTS]

[EXAMPLES]

[RISK_LEVEL]

How to adapt this template: Replace [REQUIRED_FIELDS] with a structured list of field names, their expected types, and whether null values are acceptable. [INPUT_PAYLOAD] should be the raw JSON or structured data your agent step is about to consume. The [OUTPUT_SCHEMA] placeholder should contain a strict JSON schema for the validation report—typically an array of objects with field, status (PASS/FAIL), received_value, and remediation keys. [CONSTRAINTS] is where you add domain-specific rules: date ranges, enum values, regex patterns, cross-field dependencies, or conditional requirements. [EXAMPLES] should include at least one passing and one failing payload to anchor the model's behavior. [RISK_LEVEL] controls the strictness: at HIGH, treat any ambiguity as FAIL; at LOW, flag but don't block. After copying, test the prompt against edge cases including empty payloads, extra fields, type mismatches, and deeply nested missing keys before wiring it into your agent harness.

The Required Field Presence Check prompt is designed to sit at the boundary of an agent step, acting as a precondition gate before any downstream logic, tool calls, or model reasoning consumes the input payload. In a production harness, this prompt should be invoked immediately after the input payload is assembled and before it is passed to the main task prompt. The harness is responsible for constructing the prompt with the expected field schema and the actual input payload, then parsing the structured pass/fail output to decide whether to proceed, bail out, or request remediation. This is not a prompt that runs in isolation; it is a control point in a larger workflow.

To wire this into an application, define a FieldSchema object that lists each required field name, its expected type, and an optional description. Serialize this schema into the [REQUIRED_FIELDS] placeholder as a structured list. The [INPUT_PAYLOAD] placeholder receives the actual data the agent intends to process. After invoking the model, parse the output against a strict JSON schema that expects a fields array, each with field_name, present (boolean), value_type (string or null), and remediation (string or null). A top-level all_present boolean provides the quick bail-out signal. If all_present is false, the harness should return a structured error response to the caller or trigger a remediation workflow, never proceeding to the main agent step with missing required fields. Log the full check result for observability, including which fields failed and the model's suggested remediation.

For high-reliability systems, add a validation layer after the model response. Confirm that every field in [REQUIRED_FIELDS] appears in the output fields array. If the model omits a field, treat it as a failure and re-prompt or escalate. Set a low temperature (0.0–0.2) to maximize deterministic pass/fail judgments. For latency-sensitive paths, consider caching the schema-to-prompt template so only the input payload changes per invocation. If the input payload contains sensitive data, apply redaction before passing it to the model, or use a local model deployment to keep data in-boundary. The harness should also enforce a timeout and a retry budget: if the model fails to return valid JSON after two retries, bail out with a PRECONDITION_CHECK_FAILED error rather than silently proceeding.

When integrating this into an agent framework, place the check inside a pre_execute hook or middleware that wraps every tool call or step. The harness should distinguish between 'field missing' (bail out) and 'check failed' (retry or escalate). Do not use this prompt for semantic validation such as email format correctness or business rule conformance; that belongs to a separate Input Data Schema Validation Prompt downstream. The sole responsibility here is presence detection. Avoid the temptation to combine presence checking with type validation in one prompt, as that increases output complexity and makes failure attribution harder during debugging. Keep the contract narrow and the harness behavior predictable.