Constraints bound the shape of the answer.
Typical ones are length, format, tone, audience and what to exclude.
Answer in under 100 words is a constraint that is easy to check.
Constraints turn an open-ended task into a verifiable one.
State them positively, since negative constraints are followed less reliably.
Constraints bound the shape of the answer rather than its content.
Length, format, tone, audience, reading level and exclusions are the usual ones.
They convert an open-ended request into something you can check.
Answer in under 100 words is verifiable, and be concise is not.
That checkability is the point, since an unverifiable constraint cannot be tested or enforced.
State them positively where you can, because negative rules are followed less reliably.
Write in plain English works better than do not use technical terms.
A negative constraint also plants the very thing you are excluding.
Keep the set small, since a dozen constraints guarantees a few are quietly dropped.
Order them so the ones that matter most are not buried at the end of a long list.
Numeric limits are approximate, and a request for exactly 50 words lands near 50.
For a hard limit, enforce it in your own code after the model has replied.
Format constraints are better solved by a schema than by asking politely.
Constraints that conflict with the instruction produce unpredictable compromises.
The best ones come from a real requirement downstream, not from a wish for tidiness.
One question on this card. Every option explains itself once you pick, right or wrong.
17 concepts in this module, then a graded test with every answer explained.