Constraint Design, Not Prompt Magic
Why this matters
The quality of output is mostly downstream of the constraints you set. A useful prompt is not clever language. It is a clear statement of: goal, context that matters, hard constraints (what must be true), what to do when uncertain, and what "good" looks like. Vague prompts produce fluent noise. Tight constraints produce something you can actually evaluate.
What you will be able to decide after this
- Whether an output meets the standard you set — because you wrote the standard down.
- What to change when the output misses: the constraints, not the luck.
- Which parts of a prompt were doing the work, and which were decoration.
Core lesson
The five elements of a constrained prompt:
- Goal: what the output is for, and who it is for.
- Context that matters: what the system needs to know to produce something real.
- Hard constraints: what must be true of the output — no invented numbers, no marketing language, exact length.
- What to do when uncertain: "if information is missing, say so" — instead of letting it guess.
- Success criteria: what "good" looks like, written so you can check it.
Vague prompts produce fluent noise. Tight constraints produce something you can actually evaluate.
Example prompts (use as patterns, not scripts)
Bad (vague)
"Write a project update for the website redesign."
Better (constrained)
Goal: Write a 150–200 word project update for stakeholders on the website redesign.
Context: We are in week 6 of 10. Design is approved. Development is 40% complete. Main risk is the payment integration taking longer than estimated.
Hard constraints:
- No marketing language
- State current status, what changed this week, and the single biggest risk
- Do not invent dates or percentages
- If information is missing, say "Not specified" instead of guessing
Success criteria: A reader should know exactly where we stand and what could still go wrong without needing to ask follow-up questions.
Another example — decision support
Goal: Help me decide whether to bring a contractor in for the remaining API work.
Context: Internal team has bandwidth for 3 more weeks. The remaining work is estimated at 5–6 weeks. Budget allows up to $18k. Quality bar is "production-ready, documented, and hand-offable."
Hard constraints:
- List only options that stay under budget
- For each option give: time-to-done, main risk, and what I would still own
- Do not recommend. Rank the trade-offs and stop.
If any key number is missing, tell me what you need instead of assuming.
Worked example
The same request, two ways. "Write a project update" produces a paragraph that could be about any project, anywhere. The constrained version produces something a stakeholder can act on — and, just as important, something the requester can check. The difference is not magic wording. The difference is that the constraints were written down before the output existed.
Practice
Take one weak prompt you have used recently. Rewrite it with the five elements. Notice which element changes the output the most — it is usually the hard constraints or the uncertainty handling.
Apply — produce the artifact
Take the task from Module 1. Write a constrained prompt that includes goal, relevant context, hard limits, uncertainty handling, and success criteria. Run it. Keep both the prompt and the raw output.
Verify
Compare the output against the success criteria you wrote. Mark every place it met or missed the constraints. If you did not define the criteria tightly enough to judge, rewrite the prompt and run it again.
Sources
This module is original practice guidance based on the authoring standard and does not depend on a specific external factual claim. Editorial review is still required.