Checklists and best-practice lists are useful, but they can feel like a pile of disconnected rules. A framework does something different: it gives you a single mental model you can carry into any new structured-output problem and use to derive the right design from first principles. This piece introduces one, organized so the stages spell a word you can remember.
We call it the CONTRACT model, because the central idea of structured output is exactly that—a contract between an unpredictable text generator and the deterministic code that consumes it. The seven stages are Contract, Optionality, Narration, Type-enforce, Receive, Audit, and Correct-and-Track. Each maps to a decision you must make, and the order reflects when you make it.
The framework is not a replacement for the step-by-step approach; it is the conceptual layer above it. The steps tell you what to do; the framework tells you why each exists and how to reason when a new situation does not match the template.
C: Contract
Everything begins with the contract—the schema. Before any model call, you define the shape of the data: which fields, what types. This is the agreement both sides honor.
The key insight at this stage is that the contract must be a single artifact that drives both what you ask the model for and what your code accepts. When the contract is one typed object, the two sides cannot disagree. Two hand-written copies inevitably do.
O: Optionality
The second decision is which parts of the contract are guaranteed and which are conditional. For each field, ask: can the model always determine this from the input?
The Optionality Rule
If yes, the field is required. If there exist legitimate inputs where the value genuinely does not exist, the field must be optional, and your code must handle its absence. Getting this wrong in the required direction produces the most insidious failure—fabricated values that fill required slots, which look real and pass structural checks. The examples piece shows this exact failure in resume parsing.
N: Narration
The third stage is narrating the contract to the model through field descriptions. A type tells the model the shape; a description tells it the meaning and the edge cases.
Narration is where most accuracy is won or lost. An enum with bare values scatters; the same enum with a sentence per option explaining when to choose it becomes consistent. Treat each description as a small, anchored prompt that travels with exactly the field it governs.
T: Type-enforce
Now you constrain the model call itself. Use the strongest enforcement available—strict schema enforcement if your provider has it, JSON mode if not, a constrained-decoding library for open models.
The framework's stance here is to maximize enforcement but never to mistake it for completeness. Enforcement covers structure. It does not cover meaning, and the later stages exist precisely because of that gap. The tooling survey maps which level each provider supports.
R: Receive
The fourth stage is receiving the response defensively. Parse inside error handling, treating a malformed response as a recoverable event rather than an assumption that will always hold.
This stage is short but non-negotiable. Over enough volume, even strong enforcement occasionally produces something your parser chokes on, and a single unhandled instance becomes an outage. Receiving defensively is what makes the difference between a recoverable blip and a 2 a.m. incident.
A: Audit
Now you audit the received data in two passes. Structural audit confirms the data matches the contract's shape. Semantic audit confirms the values satisfy your business rules—ranges, allowed sets, plausibility.
Why Audit Is Two Passes
These are genuinely different jobs. Structural audit is generic and cheap; semantic audit encodes domain knowledge no schema can express. A discount can pass structural audit as a valid number and fail semantic audit because it exceeds your company's maximum. Skipping the semantic pass is the most common source of clean-looking bad data, as the common mistakes article details.
C: Correct-and-Track
The final stage closes the loop. When an audit fails, correct: re-call the model with the specific error fed back, within a bounded number of attempts, falling back to a stronger model or a human queue when retries are exhausted. And track: log every failure and retry with the failing field.
Correction keeps the pipeline running through the model's bad days. Tracking turns those bad days into a tuning signal, revealing which fields are weak and which descriptions need rewriting. Together they make the system not just reliable but improvable over time.
A Worked Pass Through the Stages
To see the framework in motion, take a concrete task: classifying inbound emails into one of four departments and extracting the sender's stated deadline if they gave one.
At Contract, you define a schema with two fields: department, an enum of the four options, and deadline, a date. At Optionality, you recognize that not every email states a deadline, so deadline becomes optional with a "null if none stated" instruction, while department stays required because every email can be routed somewhere. At Narration, you write a sentence per department explaining what belongs in it, and a note on deadline clarifying that vague phrases like "soon" do not count as a date.
At Type-enforce, you switch on your provider's strict schema mode so the enum and types are guaranteed. At Receive, you parse inside error handling. At Audit, the structural pass confirms the two fields are present and typed, and the semantic pass checks that any deadline is in the future and that the department is one your routing system actually serves. At Correct-and-Track, a failed audit re-prompts with the specific error, and every failure is logged with its field.
Notice that nowhere did you invent a step. Each stage asked a question, the task answered it, and a complete design fell out. That is the framework working as intended—not prescribing answers, but guaranteeing you ask the right questions in the right order.
Applying the Framework to a New Problem
The value of CONTRACT is that it is a sequence of questions you can ask about any structured-output task. Faced with a new problem, walk the seven stages: What is the contract? Which fields are conditional? How do I narrate each? What enforcement is available? Am I receiving defensively? What does each audit pass check? How do I correct and track failures?
Answer those seven and you have a complete design. The framework does not give you the answers—those depend on your domain—but it guarantees you ask every question that matters and ask them in the right order. That is what separates a designed pipeline from a hopeful one.
Frequently Asked Questions
How is this framework different from a checklist?
A checklist is a list of things to verify; a framework is a mental model that generates those things from a smaller set of principles. The CONTRACT stages are questions you ask about any task, so you can design for situations the checklist never anticipated. Use the framework to reason and the checklist to verify you executed the reasoning.
Why are structural and semantic audits separate stages within one letter?
Because they are different jobs that share a moment in the pipeline. Structural audit is generic shape-checking; semantic audit encodes domain rules no schema can express. Grouping them under Audit reflects that they run together after receiving, while keeping them conceptually distinct reminds you that passing one does not mean passing the other.
Does every task need all seven stages?
Conceptually yes, though some stages are trivial for simple tasks. A tiny classification might have an obvious contract, no optional fields, and minimal narration—but you still reason through each stage, even if the answer is quick. Skipping a stage by forgetting it is the danger; skipping it deliberately after consideration is fine.
Where does the framework put prompt engineering?
Primarily in the Narration stage, through field descriptions, and partly in the Contract itself. The framework's view is that for structured output, most prompt engineering should live inside the schema as descriptions anchored to specific fields, rather than as free-floating instructions, because anchored guidance is more reliable.
Can I use this framework with any provider or model?
Yes. The framework is provider-agnostic because it describes decisions, not implementations. The Type-enforce stage adapts to whatever enforcement your provider or library offers, and every other stage is the same regardless of model. That portability is the point of having a mental model rather than a provider-specific recipe.
Key Takeaways
- CONTRACT is a seven-stage mental model: Contract, Optionality, Narration, Type-enforce, Receive, Audit, Correct-and-Track.
- The contract is a single typed schema that drives both the model instruction and your validation.
- Optionality decisions prevent fabricated values; narration through field descriptions wins most of your accuracy.
- Audit is two passes—structural and semantic—because enforcement covers shape but never meaning.
- The framework generates a complete design by making you ask every question that matters, in order, for any task.