AI models default to hedging, over-explaining, and drifting off-topic — not because they're broken, but because those patterns dominate their training data. This lesson teaches you a systematic framework for specifying what AI should *not* do, so you can eliminate unwanted outputs before they happen.
You've written what feels like a perfectly clear prompt, submitted it, and watched the AI confidently return something completely unusable. Maybe it added three paragraphs of caveats you never asked for. Maybe it wrote your executive summary like a blog post. Maybe it answered a question about customer churn with a philosophical detour about the nature of loyalty. You didn't ask for any of that — but you also never told it not to do it.
This is the core tension in working with large language models: they are generative by nature, optimizing for plausible continuation of your input rather than strict adherence to your intent. Without explicit constraints, an LLM will fill every ambiguous inch of your prompt with its best guess about what you probably wanted — which often isn't what you actually wanted. The solution isn't to write longer prompts that describe everything you do want in exhaustive detail. The solution is to deliberately specify what you don't want, just as precisely as you specify what you do.
By the end of this lesson, you'll have a complete toolkit for constraint specification — the practice of defining explicit boundaries, exclusions, and prohibitions that steer AI output away from failure modes before they happen. You'll know not just which constraints to add, but why certain types of constraints work and others backfire.
What you'll learn:
You should be comfortable writing basic prompts and understand that LLMs are probabilistic text generators, not rule-following programs. If you want a refresher on how these models work under the hood, see Understanding Large Language Models: How ChatGPT and Claude Actually Work. You should also have read Prompt Engineering Fundamentals for Data Professionals or have equivalent hands-on experience.
Before we get into techniques, it's worth understanding the mechanism behind the problem. When you send a prompt to an LLM, the model doesn't "read" your instructions the way a human would and then make decisions. It generates the most statistically likely continuation given the full context — your prompt, its training data, and any system-level instructions already in place.
This means the model is doing something closer to pattern completion than instruction following. And patterns in training data have strong defaults:
None of these defaults are bugs in the traditional sense. They reflect what "good writing" looks like in the aggregate of the internet. But they create systematic drift away from your specific needs unless you explicitly counteract them.
Key insight
Negative constraints work because they shift the probability distribution of the model's output. When you say "do not include caveats," you're not issuing a command to a rule-following system — you're narrowing the space of likely continuations. The more specific your constraint, the more targeted the narrowing.
This is also why vague constraints fail. Telling an AI "be concise" is weak guidance because "concise" is ambiguous and the model's sense of appropriate length is calibrated to training data, not your use case. Telling it "do not exceed 200 words" is a hard constraint that actually narrows the output space.
Not all constraints are the same. To use them effectively, you need to know which category of problem you're solving.
These control the structure, length, and visual organization of the output. They're the most commonly needed and often the most straightforward.
Common format problems:
Example without format constraints:
Prompt: Summarize the key risks from this quarterly report for our CFO.
Output:
## Key Risk Summary
Sure! Here's a breakdown of the main risks from the quarterly report:
**1. Market Risk**
- Exposure to interest rate fluctuation...
- Currency volatility in APAC markets...
**2. Operational Risk**
- Supply chain dependencies...
This might look fine at first glance. But if your CFO is reading this in an email or a Slack message, the markdown won't render and you get ## symbols and **asterisks** littering the text.
The same prompt with format constraints:
Prompt: Summarize the key risks from this quarterly report for our CFO.
Constraints:
- Do not use markdown formatting, headers, or bullet points
- Do not open with pleasantries or acknowledgment of the task
- Do not exceed 150 words
- Write in plain prose paragraphs
Output:
The report identifies three primary risk categories requiring CFO attention.
Market exposure is elevated due to interest rate sensitivity on the variable-rate
debt portfolio and currency volatility in APAC, which together account for
approximately $4.2M in potential exposure. Operational risk centers on the
single-vendor dependency for logistics processing, where a contract renewal
is pending through Q3. Compliance risk is moderate, with two open audit
findings related to data residency requirements in the EU...
Tip
Format constraints are the lowest-hanging fruit. If your AI output is structurally wrong — too long, wrong format, cluttered with unwanted elements — add explicit format constraints before you try anything else.
These prevent the model from defaulting to its baseline register, which tends toward formal-but-casual, slightly enthusiastic, and universally hedged. Real business writing has specific voice requirements.
Common tone problems:
Example prompt with tone constraints:
Write a rejection notice for a vendor proposal that didn't meet our security
requirements.
Constraints:
- Do not apologize or use apologetic phrasing ("unfortunately," "regrettably")
- Do not include vague encouragement ("we encourage you to apply again")
- Do not use passive constructions to soften the message
- Maintain a professional, direct tone — neither cold nor warm
The constraint "do not apologize" might seem harsh, but it produces vendor communication that is actually clearer and more respectful of the recipient's time than a paragraph of softening language that buries the message.
These constrain what the AI talks about — preventing it from including information outside the scope you've defined, making up details you didn't provide, or drifting into adjacent topics.
This is one of the most critical constraint categories for data professionals, because AI models will hallucinate plausible-sounding specifics if you leave gaps in your context. If you ask for analysis of a dataset and don't constrain the model's scope, it may speculate about causes, industries, or trends that aren't in your data at all.
Warning
Content scope constraints are essential whenever you're working with actual business data. An AI analyzing your sales figures without scope constraints may confidently attribute trends to macroeconomic factors it has no evidence for, or compare your numbers to "industry averages" that it's fabricating. For more on this failure mode, see Evaluating AI Output: Accuracy, Hallucinations, and Validation.
Example prompt with content scope constraints:
Analyze the following customer churn data and identify patterns.
[DATA]
Constraints:
- Do not speculate about causes that are not supported by the data provided
- Do not reference external benchmarks, industry averages, or competitor data
- Do not suggest solutions or recommendations — only describe patterns in the data
- If a pattern is ambiguous, say so explicitly rather than choosing an interpretation
Notice that last constraint — "if a pattern is ambiguous, say so." This is an underused technique. You're not just stopping the AI from doing something wrong; you're instructing it on how to handle the edge case responsibly.
These constrain how the AI approaches the problem, not just what it produces. They're especially important when you're using AI to generate code, SQL, analytical frameworks, or structured data.
Common reasoning problems:
Example prompt with methodology constraints:
Write a Python function to identify duplicate customer records in this DataFrame.
Constraints:
- Do not use fuzzy matching libraries — exact string matching only
- Do not assume the email field is always populated; treat it as optional
- Do not use loops where vectorized pandas operations would work
- Do not create new columns in the original DataFrame; return a separate result
Without these constraints, a model might write a perfectly functional but inappropriate solution — maybe pulling in the fuzzywuzzy library for name matching when your compliance team requires deterministic matching, or building a complex scoring system when you just need exact duplicates.
Note
Methodology constraints are particularly valuable in automated workflows where you're using AI to generate code or queries. In those contexts, you're not reviewing every output line by line, so guardrails at the prompt level are your first line of defense.
These are the most interesting category, and the one most practitioners overlook. They constrain the AI's behavior during the task — things like asking clarifying questions, making assumptions, or explaining its reasoning.
Common behavioral problems:
Example prompt with behavioral constraints:
Given the data schema below, write a SQL query to calculate 30-day rolling
average revenue by customer segment.
[SCHEMA]
Constraints:
- Do not ask clarifying questions — if something is ambiguous, state your
assumption and proceed
- Do not explain the query after writing it unless the logic is non-obvious
- Do not offer alternative approaches
- Do not add comments inside the SQL unless they clarify non-obvious logic
The "state your assumption and proceed" instruction is one of the most valuable behavioral constraints you can use. It produces output you can actually evaluate, rather than a back-and-forth that delays your work.
Knowing the five categories is half the battle. The other half is writing constraints that the model actually respects. Constraints can fail in two ways: they can be too vague to matter, or they can conflict with each other (or with your positive instructions) in ways that produce bizarre outputs.
Be specific about what "not doing" looks like:
Weak: Don't be verbose.
Strong: Do not include background context, definitions, or explanations of concepts the reader already knows. Jump directly to the analytical finding.
The weak version gives the model almost nothing to work with. What's "verbose"? The strong version gives a specific definition of what you're trying to prevent.
Name the specific behavior, not the quality:
Weak: Don't sound robotic.
Strong: Do not use phrases like "It is important to note," "It is worth mentioning," or "As we can see." Avoid passive constructions.
You're identifying exact surface patterns to avoid, not asking the model to evaluate some abstract quality.
Use "avoid" and "do not" rather than "try not to":
Try not to use jargon is weak because it allows for interpretation. Do not use jargon is a harder boundary.
Specify what to do when the constraint creates a gap:
Constraints sometimes create situations the model doesn't know how to handle. Anticipate them.
Do not speculate about causes not in the data. If asked to explain a trend
and the data doesn't contain causal information, explicitly state:
"The data does not contain sufficient information to identify a cause."
This is far more useful than just prohibiting speculation — you're giving the model an approved fallback behavior.
Tip
Think of each constraint as answering the question: "What would the model do wrong here, and what should it do instead?" If you can answer the "what instead" part, build it into your constraint.
The most common failure mode when adding multiple constraints is creating contradictions that the model resolves arbitrarily. Here are the most common conflict patterns:
Length vs. completeness conflicts:
If you ask for "complete coverage of all risk factors" and also say "do not exceed 100 words," you've created an impossible constraint. The model will either violate one of them or produce something that technically satisfies both while being useless.
Resolve this by making your constraints compatible:
Cover only the top 3 risks by severity. Do not exceed 100 words.
Tone vs. content conflicts:
If you ask for "warm and empathetic" tone and also say "do not use emotional language," you have a conflict. Define what "warm" means in concrete terms instead.
Prohibition vs. instruction conflicts:
If you say "do not use bullet points" and your positive instruction says "list the steps," you have a conflict. Either permit lists or change the positive instruction to "describe the steps as a process."
A useful technique before you finalize a constraint set: read your positive instructions and your negative constraints together and ask yourself, "Is there any way to follow all of these simultaneously that produces bad output?" If yes, revise.
Individual constraints are useful. A well-organized constraint set is what enables reliable, repeatable output — especially in business workflows where you're running the same type of prompt repeatedly with different inputs.
Here's a template structure that works well for complex tasks:
[ROLE/CONTEXT]
You are a financial analyst summarizing earnings call transcripts for
portfolio managers at a mid-size asset management firm.
[TASK]
Summarize the key signals from the following Q3 earnings call transcript.
[INPUT]
{transcript}
[OUTPUT CONSTRAINTS]
Format:
- Plain prose, no markdown or headers
- Maximum 300 words
- One paragraph per topic area (guidance, margins, management tone)
Content:
- Include only information stated in the transcript
- Do not compare to analyst consensus or external benchmarks
- Do not include verbatim quotes longer than one sentence
Tone:
- Neutral analytical register — no editorial adjectives ("disappointing,"
"impressive")
- Do not use hedging phrases ("it seems," "appears to suggest")
Behavior:
- If the transcript lacks information on a standard topic (e.g., guidance),
note its absence rather than omitting the section
- Do not ask clarifying questions
Notice how the constraints are organized by category. This isn't just tidiness — it makes the prompt easier to maintain, easier to share with colleagues, and easier to debug when something goes wrong. If the output has a tone problem, you know exactly where to look.
For prompts you'll use repeatedly, this kind of structured template is the foundation of a reusable prompt library.
Key insight
The goal of a well-specified constraint set isn't to enumerate every possible thing that could go wrong. That's impossible and counterproductive. The goal is to anticipate the model's most likely failure modes for this specific task and close those doors before they open.
If you're building AI-powered tools, workflows, or applications rather than doing one-off prompting, you have access to a powerful constraint mechanism: the system prompt. Rather than repeating constraints in every user-turn prompt, you can establish them once at the system level.
This is the right place for constraints that should apply to all interactions with a given AI tool:
SYSTEM PROMPT — Internal Data Analysis Assistant
You are a data analysis assistant for [Company] internal use only.
Permanent constraints:
- Never reference, speculate about, or compare to competitor companies by name
- Never produce output that includes personally identifiable information,
even if present in input data
- Always respond in English regardless of the language used in input
- Do not provide legal, compliance, or regulatory interpretations —
redirect those questions to the Legal team
- When data is ambiguous, ask one clarifying question before proceeding,
not multiple questions simultaneously
The architecture here matters: permanent behavioral constraints live in the system prompt, while task-specific constraints live in the user prompt. This prevents your prompts from becoming bloated repetitions of the same boilerplate.
For a deeper treatment of how to design and structure system prompts for business applications, see Building Effective System Prompts for Business Applications.
There's a temptation to handle everything through positive instruction — just describe the perfect output in enough detail and the AI will produce it. This works, but it has limits.
Positive instructions are best for:
Negative constraints are best for:
The most reliable prompts use both. Think of positive instructions as drawing the target and negative constraints as removing the obstacles between the model and the bullseye.
A practical heuristic: if a positive instruction isn't working — if you've described what you want and the model keeps drifting — that's a signal to add a negative constraint that specifically prohibits the drift you're seeing. This iterative approach is foundational to diagnosing and fixing prompts that return unhelpful responses.
Let's put this together with a realistic scenario.
Scenario: You're building a weekly reporting assistant for a retail operations team. The assistant takes structured sales data as input and generates a brief performance commentary for the operations manager. You've been running a version of this for two weeks and have noticed the following problems:
Your task: Write a complete prompt template that addresses all four problems.
Here's a starter structure — try writing it yourself before reading the solution:
[SYSTEM/CONTEXT]
???
[TASK]
???
[INPUT]
{weekly_sales_data}
[CONSTRAINTS — Format]
???
[CONSTRAINTS — Content]
???
[CONSTRAINTS — Behavior]
???
Solution:
[CONTEXT]
You are a retail operations reporting assistant. Your role is to generate
factual weekly performance commentary from structured sales data.
[TASK]
Write a weekly performance commentary based on the sales data below.
The audience is a single operations manager reviewing performance
against plan.
[INPUT]
{weekly_sales_data}
[CONSTRAINTS — Format]
- Plain prose only. No bullet points, headers, or markdown.
- Length: 120–180 words. Not shorter, not longer.
- Do not open with pleasantries, acknowledgments, or phrases like
"Certainly!" or "Here's the..."
[CONSTRAINTS — Content]
- Report only what is present in the provided data.
- Do not reference industry trends, benchmarks, or external comparisons.
- Do not include recommendations, suggestions, or language that implies
action ("should consider," "may want to," "it would be advisable").
- If a metric is missing from the data, omit it rather than estimating.
[CONSTRAINTS — Behavior]
- Do not ask clarifying questions.
- If the data contains anomalies (e.g., zero values, missing dates),
describe them factually rather than interpreting their cause.
Notice that four distinct problems were addressed with four distinct types of constraints — content scope, behavioral, format, and tone/phrasing. This is the diagnostic value of the five-category framework.
More constraints isn't always better. Past a certain point, a dense constraint list causes incoherence — the model spends so much "attention" navigating prohibitions that the quality of the actual content degrades.
A practical limit: aim for no more than 8–10 total constraints per prompt. If you need more than that, consider whether you're trying to do too much in a single prompt. Breaking the task into steps often produces better results than adding more constraints to an overloaded single prompt.
"Write a detailed analysis. Do not exceed 50 words." You've created an impossible prompt and the model will resolve it in whatever way its probability distribution prefers — which may not be what you wanted.
If you catch yourself writing a constraint that seems to conflict with your task description, stop and clarify the task first.
If your output is factually wrong, adding more format constraints won't help. If the model is using the wrong methodology, adding tone constraints won't help. Diagnose which category of problem you have before reaching for constraints.
A quick diagnostic:
A constraint like "do not speculate" is incomplete if the model might encounter situations where some response is required but speculation would be needed. Always pair a prohibition with an approved alternative behavior. This connects to the broader principle of building AI guardrails in production workflows.
In most consumer AI tools, constraints in one conversation do not carry over to the next. If you've built a working constraint set, save it as a prompt template. Don't rely on the model "remembering" what you told it last time.
Warning
Even within a single long conversation, constraint adherence can degrade as the context window fills up. In long sessions, earlier instructions lose relative weight compared to recent messages. Periodically re-stating your critical constraints — or using a system prompt that anchors them — prevents this drift. For more on how context windows affect instruction following, see Tokens, Context Windows, and Input Limits: What Data Professionals Need to Know Before Building AI Workflows.
You can't know if your constraints are working unless you test them. After adding a new constraint, deliberately probe for the behavior you were trying to prevent. If you said "do not include recommendations," then send an input that would naturally prompt recommendations and see if the constraint holds.
This is especially important before deploying constrained prompts in automated pipelines. Build a simple test set of edge-case inputs and verify your constraints hold across all of them.
The core skill this lesson developed is treating constraints as first-class prompt components — not afterthoughts you add when something goes wrong, but deliberate design decisions you make upfront based on knowledge of model defaults and task-specific failure modes.
To recap the framework:
Where to go next:
The underlying principle is this: AI models are powerful but not obedient. They follow the path of highest probability through your prompt, not the path of your intent. Constraints are the mechanism by which you align those two things — and mastering them is what separates practitioners who get reliable output from practitioners who get lucky.
Intro to AI & Prompt Engineering