Required Schema Definition Detection Prompt

This prompt is for API and data platform teams who need to guarantee that an AI-generated payload conforms to a known schema before the model ever produces a response. The job-to-be-done is simple: detect when a required output schema, contract, or type definition is absent from the generation context and halt the workflow immediately with a structured, machine-readable request for the missing definition. The ideal user is a platform engineer or integration developer wiring an LLM into a pipeline where downstream consumers—internal services, client SDKs, or database insert operations—expect strictly typed, validated outputs. Without this gate, the model may default to unstructured prose, hallucinate field names, or produce valid JSON that violates the expected contract, causing silent failures deep in the pipeline.

Use this prompt when the generation task has a known, required output shape that must be provided before generation begins. Typical triggers include: an API endpoint that expects a specific response body, a data extraction job that must populate a predefined table, or an agent tool call that requires a typed argument object. The prompt works best when the schema itself is the missing piece—not when the schema is present but ambiguous, incomplete, or contradictory. For those cases, a schema repair or clarification prompt is more appropriate. Do not use this prompt for open-ended creative generation, chat responses, or workflows where the output shape is genuinely flexible and validation happens post-hoc.

Before deploying this prompt, ensure your harness can supply the schema when requested and that the interruption does not create a deadlock. The prompt expects to run as a pre-generation gate: if the schema is missing, the workflow stops and returns the structured request. If the schema is present, the prompt should pass through cleanly and allow generation to proceed. Pair this with a validation step after generation to confirm the output actually conforms to the schema that was provided. In high-risk or regulated environments, log every schema-detection decision and consider a human review step when the prompt flags an unexpected schema absence in a critical pipeline.

This prompt template is designed to sit directly before any generation step that requires a structured output. It inspects the provided context for an output schema, type definition, or data contract. If none is found, it halts and returns a structured request for the missing definition instead of proceeding with unstructured generation that downstream systems cannot validate. The template uses square-bracket placeholders so you can wire it into your existing agent, pipeline, or API workflow without modification.

textCopy
You are a pre-generation schema gate. Your only job is to detect whether a required output schema, contract, or type definition is present before generation begins.

## Context
[CONTEXT]

## Expected Output Schema
[OUTPUT_SCHEMA]

## Constraints
[CONSTRAINTS]

## Instructions
1. Examine [CONTEXT] and [OUTPUT_SCHEMA] carefully.
2. If [OUTPUT_SCHEMA] contains a valid schema definition (JSON Schema, TypeScript interface, Pydantic model, protobuf definition, or equivalent structured contract), respond with exactly:
   {"status": "schema_present", "schema_type": "<detected format>", "field_count": <number of top-level fields>}
3. If [OUTPUT_SCHEMA] is empty, null, undefined, or contains only placeholder text, respond with exactly:
   {"status": "schema_missing", "request": "A required output schema was not provided. Please supply a JSON Schema, TypeScript interface, Pydantic model, protobuf definition, or equivalent structured contract before generation proceeds.", "blocking": true, "required_format": "json_schema"}
4. If [OUTPUT_SCHEMA] is present but ambiguous or incomplete (e.g., only field names without types, or natural language descriptions without a machine-readable contract), respond with exactly:
   {"status": "schema_incomplete", "request": "The provided output schema is ambiguous or incomplete. Please supply a machine-readable schema with explicit field names, types, required/optional markers, and constraints.", "blocking": true, "missing_elements": ["<list specific gaps>"]}
5. Do not generate any output content beyond this gate check. Do not guess the schema. Do not proceed with generation.

## Risk Level
[RISK_LEVEL]

If [RISK_LEVEL] is "high", add the following to any blocking response:
"This workflow is classified as high-risk. Human review is required before proceeding. Escalate to [ESCALATION_CONTACT]."

Adaptation notes: Replace [CONTEXT] with the task description, user input, or upstream data the model needs to understand. Replace [OUTPUT_SCHEMA] with the schema field from your application layer—this is what the prompt inspects. If your system passes the schema separately (e.g., as a tool parameter or API field), wire it into this placeholder. Replace [CONSTRAINTS] with any additional rules such as field length limits, enum values, or format requirements. Set [RISK_LEVEL] to "high" for regulated, financial, healthcare, or irreversible-action workflows, and provide [ESCALATION_CONTACT] with a role, queue, or email. The prompt returns structured JSON that your application can parse to decide whether to proceed, request a schema, or escalate. Always validate the response against the expected JSON structure before acting on it—malformed responses should trigger a retry or fallback to a human reviewer.

The Required Schema Definition Detection Prompt is designed to sit at the boundary between a user request and a generation step that expects structured output. It should be invoked before any model attempts to produce a typed payload, contract, or schema-conformant response. The prompt receives the user's request and any available context, then either returns a structured SCHEMA_REQUEST object or a PROCEED signal with the extracted schema. The application layer must parse this structured response and branch: if a SCHEMA_REQUEST is returned, the workflow halts and surfaces the request to the user or calling system; if PROCEED is returned, the validated schema is passed downstream to the generation prompt.

Wire this prompt as a pre-generation gate in your API handler or agent orchestrator. The model should be called with response_format set to JSON (or a structured output mode if available) and constrained to the two-type union: SCHEMA_REQUEST and PROCEED. On the application side, validate the response against a strict schema before branching. If the model returns malformed JSON or an unrecognized type, treat it as a SCHEMA_REQUEST with a generic missing-schema message and log the raw output for debugging. Implement a single retry on parse failure with a simplified re-prompt that includes the original request and the instruction: 'Return only a valid JSON object with type SCHEMA_REQUEST or PROCEED.' If the retry also fails, escalate to a human review queue with the original user request and both raw model responses attached.

For high-reliability workflows, add an eval step that samples a subset of PROCEED decisions and verifies that the extracted schema is actually present and complete in the user request. A false PROCEED—where the model claims a schema exists but the downstream generation fails due to missing fields—is more dangerous than a false SCHEMA_REQUEST. Log every decision with the user request hash, the model's response type, and the extracted schema (if any). This audit trail lets you tune the prompt's sensitivity over time and identify user request patterns that confuse the detector. When integrating with human-in-the-loop systems, format the SCHEMA_REQUEST payload directly into a ticket or Slack message that asks the user to provide the missing schema in a specific format (e.g., JSON Schema, TypeScript interface, or a structured example) before the workflow can resume.