← Back to Dashboard
1. Prompt Contracts and Output Schemas2. Template Variables and Reuse

Prompt Contracts and Output Schemas

📚 Prompt Engineering on Bedrock⏱ 10 min⭐ 70 XP

Production Prompt Contracts

Treat prompts as versioned contracts. Define task, boundaries, allowed tools, output format, and refusal behavior. A prompt without an explicit output contract produces output you cannot parse, validate, or regression-test.

The Anatomy of a Contract

Role: Incident Analyst
Task: Classify ticket priority
Output: JSON {"priority":"P1|P2|P3","reason":"..."}
Constraints:
 - reason must cite evidence from the ticket text
 - never invent services that are not mentioned
Safety: If unsure, return {"priority":"P3","reason":"insufficient evidence"}

Every element is testable: you can assert the JSON parses, the priority is one of three values, and the fallback fires on ambiguous input.

Enforcing Structure on Bedrock

TechniqueHowReliability
Prompt-level schemaDescribe the JSON shape + give 1-2 examplesGood with strong models, still validate
Tool-based extractionDefine a tool whose input schema IS your output schema; force the model to "call" itHigh - the model must emit valid JSON matching the schema
Post-validation + retryParse → validate → on failure, re-prompt with the validation errorHighest - catches residual drift, bound retries at 2-3

Why Contracts Beat Vibes

  • Parseability - downstream code consumes a schema, not prose.
  • Testability - golden datasets can score adherence automatically.
  • Auditability - refusal behavior is defined, not improvised.
  • Portability - a contract survives a model swap; loose prose often does not.
Rule of thumb: if you cannot write an automated test for your prompt's output, the prompt is not production-ready. Contracts reduce ambiguity and make regression testing possible.
🧪 Knowledge Check
Press 1-4 to select1 of 2
Why use explicit output schemas in prompts?
To increase hallucinations
To simplify downstream parsing and validation
To avoid retries forever
To replace IAM