Expected Output Contract Definition Prompt

Use the Expected Output Contract Definition Prompt when you are building a prompt that will feed into a production system, a regression test suite, or any workflow where downstream code, users, or automated gates depend on the shape and content of the model's response. This prompt is not for casual chat or one-off brainstorming. It is for the moment before prompt authoring begins—when you need to lock down the exact schema, field-level constraints, acceptable variance, refusal conditions, and validation rules that will determine whether an output passes or fails. The primary user is a prompt engineer, AI platform engineer, or QA lead who needs to turn an ambiguous product requirement ('the model should return a summary') into a machine-readable contract that can be enforced in CI/CD.

This prompt is most valuable when multiple people—or multiple systems—will consume the output. If a frontend expects a specific JSON shape, if a logging pipeline needs certain metadata fields, or if a regression test suite must compare outputs across prompt versions, you need a contract first. The prompt forces you to answer hard questions before you write a single instruction: What fields are required? What happens when the model is uncertain? Should it refuse, return a null, or guess with a confidence score? What constitutes a breaking change to the output schema? By defining these answers upfront, you prevent the most common production failure mode: a prompt that 'works' in manual testing but produces unparseable, incomplete, or silently incorrect outputs under real traffic.

Do not use this prompt when the output format is genuinely freeform, when you are in early exploration mode and don't yet know what good looks like, or when the consumer is a human who can tolerate unstructured text. Do not use it as a substitute for writing the actual generation prompt—this prompt defines the contract, not the instructions that fulfill it. If you skip this step and go straight to writing instructions, you will inevitably discover schema mismatches, missing fields, and ambiguity during integration, when they are most expensive to fix. The output of this prompt should be treated as a living artifact: version it alongside your prompt, check it into your repository, and use it to gate every prompt change with automated validation.

The following prompt template is designed to produce a machine-readable output contract for a given AI task. It forces the model to define not just the desired JSON schema, but also field-level constraints, acceptable variance ranges, and explicit conditions under which the output should be refused or left empty. This contract becomes the single source of truth for downstream validation, testing, and evaluation harnesses.

textCopy
You are a precise output contract designer. Given a description of an AI task, produce a strict output contract. The contract must define the expected structure, field-level rules, and failure boundaries.

TASK DESCRIPTION:
[INPUT]

ADDITIONAL CONTEXT (optional):
[CONTEXT]

OUTPUT CONTRACT REQUIREMENTS:
1.  **Output Schema**: Define the exact JSON schema for a successful response. Use standard JSON Schema syntax.
2.  **Field Constraints**: For every field, specify:
    - Data type and format (e.g., 'string (ISO 8601 date)', 'integer (0-100)')
    - Nullability and optionality rules.
    - A plain-English description of valid content.
    - An explicit list of invalid or edge-case values that should be rejected.
3.  **Acceptable Variance**: For fields requiring semantic judgment (e.g., summaries, sentiment), define the acceptable range of semantic equivalence. Use a scale of 1-5 where 1 is 'exact string match' and 5 is 'topic is mentioned'.
4.  **Refusal Conditions**: List specific input conditions or content types where the AI should refuse the task entirely and return a structured error object instead of a best-effort output.
5.  **Validator Generation Hook**: Provide a Python function signature and pseudocode for a validation function that could check a real output against this contract.

OUTPUT FORMAT:
Return your response as a single JSON object with the following top-level keys: 'schema', 'field_constraints', 'variance_definitions', 'refusal_conditions', and 'validator_hook'.

To adapt this template, replace the [INPUT] placeholder with a clear, concise description of the AI's job-to-be-done, such as 'Extract key financial figures from an earnings call transcript' or 'Classify the sentiment of a customer support ticket.' The optional [CONTEXT] placeholder can be used to inject relevant business rules, a glossary of terms, or examples of tricky edge cases. The output of this prompt is not the final answer to the task, but the contract that any answer must satisfy. This contract should be versioned and stored alongside your prompt code. For high-risk domains like healthcare or finance, the generated contract must be reviewed by a domain expert before it is used to gate a production system.

The Expected Output Contract Definition Prompt is not a one-off brainstorming tool—it is a schema generation engine that should be integrated into your prompt development lifecycle. When you invoke this prompt, you are asking the model to produce a machine-readable output contract (typically JSON Schema, TypeScript interfaces, or Pydantic model definitions) that downstream validators, test harnesses, and CI/CD gates will enforce. The prompt expects structured inputs: a description of the task the target prompt performs, example inputs and desired outputs, known edge cases, and any domain-specific constraints. The output is a formal contract that includes field-level types, required vs. optional fields, enum constraints, acceptable variance ranges, refusal conditions, and validator generation hooks.

Integration pattern: Call this prompt as a pre-commit or design-time step before writing the actual system prompt. Store the generated contract in version control alongside the prompt template. Wire the contract into your evaluation harness by converting the schema into executable validators (e.g., jsonschema.validate() in Python, Zod schemas in TypeScript, or Pydantic models). For each regression test run, validate every model output against the contract. Failures should be logged with the specific field, expected type, and actual value. Retry logic: if a model output fails schema validation, use a separate Output Repair Prompt to fix malformed outputs before retrying. Do not silently coerce invalid outputs—log the failure, attempt repair, and escalate to human review if repair fails twice. Model choice: use a model with strong structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) for contract generation. For validation at runtime, a lighter model or deterministic parser is sufficient.

Tool use and RAG considerations: If your target prompt uses function calling or tool selection, the output contract must include tool-call schemas, argument constraints, and expected tool response shapes. Feed the contract into your tool registry so that argument validation happens before tool execution. For RAG workflows, the contract should specify citation format requirements, source grounding fields, and abstention conditions. Human review gate: for high-risk domains (healthcare, finance, legal), require a human reviewer to sign off on the generated contract before it gates production outputs. Store the approval timestamp and reviewer identity in the contract metadata. Avoid: generating contracts without concrete examples of expected outputs—the model needs exemplars to infer field constraints. Also avoid treating the contract as static; re-run this prompt when the target prompt's behavior changes, and version the contract alongside the prompt.