Course Content
Prompt Engineering Mastery
6 sections · 32 lessons
How can prompt constraints help avoid unsafe or incorrect outputs?
What you need to know
A constraint is any rule that removes options: what topics, what sources, what format, what length, what actions. Fewer options mean fewer ways to be wrong.
Types of constraints
| Constraint | Example | What it prevents |
|---|---|---|
| Scope | "Only questions about our catalogue" | Off-topic or risky answers |
| Grounding | "Only from <policy>; else NOT_FOUND" | Invented facts |
| Format | JSON schema, enum of labels | Free text that hides errors |
| Prohibition with reason | "No legal advice, because users are not clients" | Harmful advice |
| Escalation | "Over Rs 10,000, hand off to a human" | High-risk actions by the model |
| Uncertainty | "If unsure, say so and ask" | Confident guesses |
Write constraints well
- Give the reason. "Do not state a deadline unless the clause does, because account managers act on it" lets the model handle cases you did not foresee.
- Few and clear. One precise rule beats five overlapping ones. Long lists of "never" in capitals make current models rigid and can anchor them on the banned idea.
- Positive where possible. "Describe what the clause says" works better than "don't interpret".
- Make the safe path easy. A defined NOT_FOUND value or escalation tool gives the model a correct way out.
Enforce the critical ones in code
Prompt constraints are strong defaults, not guarantees. For anything that matters, check the output independently: schema validation, an enum check, a regex for phone numbers, a filter for advice language, quotes that must appear in the source. Many teams also use a separate guardrail model or moderation API on inputs and outputs.
A real-life example
A legal-clause summariser is used by account managers. Early outputs sometimes said "this penalty is unenforceable, you can ignore it" — legal advice, and wrong.
The original prompt:
Summarise this clause and tell me if it's a problem.The constrained prompt:
Summarise the clause in <clause> for an account manager.- Describe only what the clause says. Do not judge whether it is fair or enforceable; only the legal team gives that advice.- Return JSON: {"summary": string, "obligations": [string], "risk_flag": "none" | "review_with_legal", "quote": string}- Set risk_flag to "review_with_legal" if the clause has a penalty, indemnity, auto-renewal or exclusivity.- If the text is not a contract clause, return summary "NOT_A_CLAUSE".In code, the team checks the schema, confirms quote appears in the clause, and scans summary for phrases like "unenforceable" or "you can ignore". On 200 test clauses, advice-like outputs fall from 14 to 0, and every penalty clause is flagged for Legal.
Follow-up questions to expect
- "Can constraints make a model too cautious?" — Yes. Overly broad bans cause refusals of harmless requests. Measure false refusals as well as unsafe outputs.
- "How do you handle a user who tries to break the rules?" — Keep rules in the system prompt, treat user and document text as data, and enforce critical rules in code so a successful injection still fails the check.
- "Enum or free text?" — Enum wherever the downstream system acts on the value; free text only for human-read parts.