Token-Aware Prompt Assembly Validation Prompt

This prompt acts as a programmatic gate that inspects a fully assembled prompt before it is sent to a model. Its job is to catch assembly errors—token limit violations, unresolved template variables, schema mismatches in structured output instructions, and conflicting directives between system, user, and tool messages—that would otherwise cause wasted inference costs, malformed outputs, or silent failures. The ideal user is a production engineer or AI platform developer whose application dynamically composes prompts from multiple sources: retrieval results, user input, tool schemas, few-shot examples, and behavioral policies. In that environment, assembly bugs are inevitable, and this prompt provides a structured validation report that can trigger a retry, a fallback, or a halt before the request leaves your application.

Use this prompt when your prompt assembly pipeline has multiple contributors and you need a deterministic, auditable checkpoint. It is appropriate when the cost of a bad inference is high—either because the model call is expensive, the output feeds a downstream system that expects a strict schema, or the user experience degrades sharply on malformed responses. The prompt expects a complete, rendered prompt as input, including all messages, tool definitions, and format constraints. It returns a validation report with specific failure flags, token counts, and conflict descriptions that your application can parse and act on. This is not a prompt for generating content; it is a meta-prompt for validating other prompts.

Do not use this prompt for simple, hand-written prompts that never change at runtime. If your prompt is a static string with no variable substitution, no retrieval, and no tool schemas, the validation overhead is unnecessary. Do not use it as a substitute for proper template rendering tests in your CI/CD pipeline—this prompt validates a single assembled instance, not the template logic that produced it. Do not use it to judge prompt quality, tone, or task effectiveness; it checks structural integrity, not semantic fitness. If your application already enforces token limits and schema validation in code, this prompt adds a second layer of defense for cases where code-level checks miss cross-message conflicts or subtle placeholder leaks. For high-risk domains, always pair the validation report with a human review step before blocking or modifying production traffic.

This template acts as a preflight guardrail for production prompt assembly pipelines. Before sending a fully assembled prompt to the model, you run it through this validation prompt to catch assembly errors that would otherwise produce silent failures, malformed outputs, or wasted inference costs. The validator checks token budget compliance, unresolved placeholder variables, structural integrity of the output schema, and contradictory instructions that could confuse the model at runtime.

textCopy
You are a prompt assembly validator. Your job is to inspect an assembled prompt before it is sent to a model for inference. You must produce a structured validation report. Do not execute the prompt. Do not simulate a response. Only validate the prompt structure and content.

## INPUTS

[ASSEMBLED_PROMPT]
(The complete, fully assembled prompt text that will be sent to the model. This includes system instructions, user input, retrieved context, tool schemas, examples, and output format constraints.)

[TOKEN_LIMIT]
(The maximum allowed token count for this model and deployment tier. Example: 8192, 32768, 128000.)

[REQUIRED_VARIABLES]
(A list of square-bracket placeholder names that must be resolved in the assembled prompt. Example: ["USER_NAME", "ACCOUNT_ID", "DATE_RANGE"])

[EXPECTED_OUTPUT_SCHEMA]
(The expected output format, such as a JSON schema, field list, or type description. Example: {"type": "object", "required": ["summary", "action_items"], "properties": {"summary": {"type": "string"}, "action_items": {"type": "array", "items": {"type": "string"}}}})

[INSTRUCTION_PRIORITY_RULES]
(A list of rules describing which instructions take precedence when conflicts are detected. Example: "System-level safety policies override user-requested tone adjustments. Tool output constraints override conversational formatting instructions.")

[RISK_LEVEL]
(The risk classification for this workflow: "low", "medium", "high", or "critical". Critical and high-risk workflows require stricter validation and must flag any unresolved issues as blocking.)

## VALIDATION STEPS

1. **Token Count Check**: Estimate the token count of [ASSEMBLED_PROMPT]. Compare it to [TOKEN_LIMIT]. If the estimated count exceeds 95% of the limit, flag as a warning. If it exceeds 100%, flag as a blocking error.

2. **Unresolved Variable Check**: Scan [ASSEMBLED_PROMPT] for any square-bracket placeholders matching the names in [REQUIRED_VARIABLES]. If any required variable remains as a literal placeholder (e.g., "[USER_NAME]"), flag as a blocking error. Also scan for any unexpected square-bracket tokens that look like unresolved placeholders and flag them as warnings.

3. **Output Schema Alignment Check**: Examine any output format instructions in [ASSEMBLED_PROMPT]. Compare them to [EXPECTED_OUTPUT_SCHEMA]. Flag mismatches in required fields, type conflicts, or missing schema constraints. If the prompt instructs the model to produce a different shape than expected, flag as a blocking error.

4. **Instruction Conflict Check**: Identify any pairs of instructions in [ASSEMBLED_PROMPT] that contradict each other. Use [INSTRUCTION_PRIORITY_RULES] to determine which instruction should win. Flag unresolved conflicts where priority rules do not provide a clear resolution. For high or critical [RISK_LEVEL], all unresolved conflicts are blocking errors.

5. **Structural Integrity Check**: Verify that the prompt has a coherent structure: system instructions are clearly delineated, user input is separated from instructions, tool schemas are well-formed, and examples are properly formatted. Flag structural issues that could cause the model to misinterpret sections.

## OUTPUT FORMAT

Return a JSON object with this exact schema:

{
  "validation_passed": boolean,
  "blocking_errors": [
    {
      "check": string,
      "severity": "blocking",
      "message": string,
      "location": string
    }
  ],
  "warnings": [
    {
      "check": string,
      "severity": "warning",
      "message": string,
      "location": string
    }
  ],
  "token_estimate": {
    "estimated_count": number,
    "limit": number,
    "utilization_percent": number,
    "status": "ok" | "warning" | "exceeded"
  },
  "unresolved_variables_found": [string],
  "schema_conflicts": [string],
  "instruction_conflicts": [
    {
      "instruction_a": string,
      "instruction_b": string,
      "resolution": string,
      "resolved": boolean
    }
  ],
  "recommendation": string
}

## CONSTRAINTS

- Do not hallucinate token counts. If you cannot estimate, state your uncertainty in the recommendation field.
- If [RISK_LEVEL] is "high" or "critical", any blocking error must set validation_passed to false.
- If [RISK_LEVEL] is "low", unresolved instruction conflicts may be treated as warnings rather than blocking errors.
- The recommendation field must contain a single actionable sentence telling the operator what to fix first, or "Ready for inference" if no issues are found.

To adapt this template, replace each square-bracket placeholder with runtime data from your prompt assembly pipeline. The [ASSEMBLED_PROMPT] should be the exact string that will be sent to the model, not a template reference. Wire the validator into your pre-inference hook so that prompts failing validation are blocked before they consume inference tokens. For high-risk workflows, log every validation report alongside the assembled prompt and model response for auditability. If your pipeline assembles prompts dynamically, run this validator on every assembled instance, not just on the template.

This prompt is designed to operate as a preflight guardrail—a synchronous check that runs after prompt assembly but before the final inference request is dispatched. The validation report it produces should be treated as a gate, not a suggestion. The harness must parse the structured output, check the valid boolean, and either release the prompt for inference or route it to a repair/alerting path. Do not send the assembled prompt to the primary model if the validator returns valid: false or flags critical errors such as token overflow, missing required variables, or instruction conflicts that violate your behavioral contract.

The implementation should follow a validate-then-dispatch pattern. First, assemble the final prompt string using your template engine, substituting all variables and injecting retrieved context, tool schemas, and conversation history. Second, send the assembled prompt to the validation model (a fast, cheap model like GPT-4o-mini or Claude Haiku works well here) with this playbook's template. Third, parse the JSON output and evaluate the checks array. Critical failures (severity: critical) should abort the request and return a controlled error to the user or trigger an alert. Warnings (severity: warning) can be logged and optionally allowed through depending on your risk tolerance. Log the full validation report alongside the prompt version, trace ID, and assembly parameters for debugging. For high-stakes domains (healthcare, legal, finance), require human review when the validator flags instruction_conflict or schema_mismatch errors.

Retry logic should be applied carefully. If the validator itself fails to return valid JSON, retry up to two times with a stricter output format instruction. If the validator flags a token_overflow, do not retry the same prompt—instead, route to a context compression or truncation module before re-validation. Integrate this check into your CI/CD pipeline as well: run the validator against a golden set of assembled prompts on every prompt template change to catch regressions before deployment. Avoid the temptation to skip validation for latency-sensitive paths; the cost of a bad inference is almost always higher than the 200-500ms overhead of a preflight check on a small model.