It is easy to nod along to advice about constraining model output and still have no idea what a good constraint looks like in your own work. Principles are portable; the judgment to apply them is not. The fastest way to build that judgment is to study specific cases where a constraint was the difference between a prompt that shipped and one that did not.
Constraint-based output prompting means defining the exact shape and boundaries of what the model returns rather than hoping the content arrives in a usable form. The examples below are deliberately concrete: a real task, the constraint that mattered, and what happened when it was present or absent.
Read them less as recipes and more as a way to train your eye for where a constraint belongs. The same constraint that is essential in one scenario is wasteful in another, and the only way to develop the judgment to tell which is which is to see enough cases that the pattern becomes obvious. Each example below pairs a task with the specific decision that determined whether it shipped, so the reasoning is visible rather than buried.
Extracting Fields From Unstructured Email
The scenario
A team needed to pull sender intent, requested action, and deadline from inbound support emails into a database. The first prompt asked for "the key details as JSON."
What made it work
It did not work at first. Outputs varied in field names and occasionally wrapped the JSON in explanation. The fix was a literal example object with fixed keys plus "Output only this object, no other text." Parse failures dropped to near zero. The same failure mode appears in Seven Ways Output Constraints Quietly Break Your Prompts.
Generating SQL Within Safe Boundaries
The scenario
An internal tool let analysts ask questions in English and have the model produce SQL. The risk was destructive or unbounded queries.
What made it work
The constraint set forbade any statement other than SELECT, required a LIMIT clause, and demanded the query reference only an allowlisted set of tables provided in the prompt. The boundary was structural, not stylistic, and it turned a risky feature into a safe one.
Producing On-Brand Marketing Copy
The scenario
A content team wanted variants that stayed within brand voice and never exceeded a character limit for a specific ad slot.
What made it work
Rather than "keep it short," the prompt specified "two variants, each a single sentence under 90 characters, no exclamation marks, no questions." Structural and exclusion constraints together produced reliably usable copy where a vague length request had produced overflow.
Summarizing With a Fixed Shape
The scenario
A research workflow needed every document summarized into the same three-part shape so downstream readers could scan consistently.
What made it work
The prompt named the three sections and their order, then showed a one-line example of each. The model produced the identical skeleton across hundreds of documents, which is exactly what made the summaries usable at scale. The structural discipline here mirrors the model in A Decision System for Shaping Model Output.
Classifying Into a Closed Set
The scenario
A routing system needed each ticket labeled as exactly one of five categories, never a sixth invented label and never a hedge.
What made it work
The constraint listed the five allowed values verbatim and added "Respond with exactly one of these values and nothing else. If none fit, respond with 'other'." Closing the output set eliminated the creative-but-wrong labels that broke routing. Measuring that this held is covered in Reading the Signal: What to Track When Outputs Must Conform.
Generating a Structured Changelog Entry
The scenario
An engineering team wanted the model to turn a merged pull request description into a changelog entry with a type (added, fixed, changed), a one-line summary, and an optional breaking-change flag.
What made it work
The first attempt produced lovely prose paragraphs that no script could file under the right heading. The fix enumerated the three types as a closed set, demanded the summary fit one line with no trailing period, and required the breaking-change flag to be a literal boolean. Once the output was a contract rather than a paragraph, the entries filed themselves. The principle is the same container-versus-content split that runs through A Decision System for Shaping Model Output.
Drafting Replies Within a Tone Boundary
The scenario
A team wanted customer replies that stayed professional and never made commitments the company could not honor, like specific refund amounts or delivery dates.
What made it work
The constraint was as much exclusion as inclusion: forbid any specific dollar figure, date, or guarantee, and route to a human when the situation required one. This is a case where the load-bearing constraint protects the business, not the parser, and where over-tightening the tone would have made replies feel robotic. The balance is exactly the trade explored in Choosing How Tight to Make Your Output Rules.
What the Examples Have in Common
Constraints were structural first
In every successful case, the load-bearing constraint shaped the structure of the output, not its prose. Structure is cheap to specify and easy to verify.
Exclusions did real work
"Nothing else," "only these values," "no other text" appear repeatedly. The exclusions prevented the model's default helpfulness from corrupting machine-readable output.
Examples beat descriptions
Where exactness mattered, a shown instance outperformed any description. This pattern is consistent enough to treat as a default.
Reading the Scenarios for Your Own Work
Find the analog, not the recipe
None of these scenarios will match your task exactly, and copying them verbatim is the wrong use. The right use is to find the structural analog: is your task an extraction, a classification, a bounded generation, or a fixed-shape transformation? Once you place your task in one of those families, the relevant constraints fall out, because each family fails in characteristic ways and each has a characteristic fix.
Notice which constraint was load-bearing
In every example, one constraint did most of the work while the others were supporting detail. For extraction it was the exclusion rule; for SQL it was the structural boundary; for classification it was closing the set. Identifying the single load-bearing constraint for your task is more valuable than enumerating ten minor ones, and it keeps you from the over-constraint trap discussed in Seven Ways Output Constraints Quietly Break Your Prompts.
Let the consumer define the constraint
Across all the cases, the constraint that mattered was dictated by what consumed the output: a parser, a router, an ad slot, a human reader. When you are unsure which constraint to write, look at the consumer and ask what would break it. That question answers most constraint decisions on its own.
Frequently Asked Questions
Why does the JSON extraction example need an exclusion rule?
Because models default to wrapping structured output in conversational text. Without "output only this object," you intermittently get preambles that break the parser, even when the JSON itself is correct.
Can I constrain SQL generation safely with prompting alone?
Prompting reduces risk substantially but should not be your only defense. Pair the prompt constraints with a query validator that enforces the same rules in code, since prompts can be circumvented.
How is a closed-set classification constraint different from a normal one?
It explicitly enumerates every allowed output and forbids anything else, including a fallback for the no-match case. This prevents the model from inventing plausible-sounding categories that break downstream routing.
Do structural constraints work for creative tasks too?
Yes. The marketing example shows structure (count, length, punctuation rules) coexisting with creative content. Structure constrains the container; creativity fills it.
Why show an example instead of describing the summary shape?
Description leaves section boundaries, ordering, and formatting ambiguous. A shown instance fixes all of them at once, which is why the summaries stayed identical across hundreds of documents.
Which of these patterns generalizes best?
Closing the output set and stating exclusions generalize almost everywhere output feeds another system. They are the cheapest constraints to add and prevent the most expensive failures.
Key Takeaways
- Field extraction needs a literal example plus an explicit "output only this" rule.
- Safe SQL generation comes from structural boundaries, not stylistic requests.
- Marketing copy stays usable when length and punctuation are specified, not implied.
- Fixed-shape summaries require named sections and shown examples to stay consistent.
- Closed-set classification must enumerate allowed values and forbid everything else.
- Across all cases, structural constraints, exclusions, and shown examples did the work.