Lesson 8 of 25

The Discipline of Precise Limitation

Constraints are the limits you set on the answer before you get it - how long, what format, what tone, and crucially what to leave out. They work because an unconstrained model fills space with the most average version of a thing, and every limit you add removes a swathe of that averageness. Negative constraints, saying what not to include, often sharpen an answer more than positive ones.

Reach for it whenWhen you keep getting answers that are technically correct but too long, too generic, or padded with the one section you did not want.

Lay the constraints out as a labelled list under its own heading - Length, Tone, Format, Banned - so each is a separate checkable item rather than a clause buried in a sentence. Then add a step asking it to audit its own output against the list and report the real word count, including when it overshot. Standing constraints that apply to everything you write belong in Custom Instructions, not in each prompt.

Worth knowingWord counts are approximate - the model is not counting reliably as it writes, so a stated 150 may land at 170. Asking for the count makes the miss visible, which is the most you can get without editing it yourself.
  • Give each constraint its own labelled line, not a sentence.
  • Name banned words explicitly; vague bans do nothing.
  • Ask it to audit itself and report the real count.
  • State which constraint to sacrifice when two conflict.
  • Move standing house style into Custom Instructions.
Example 1: Constraining Length and Format

Instead of

Explain what an API is.

Perplexity version

## TASK
Explain what an API is to a non-technical project manager.

## CONSTRAINTS
- **Length:** 150 words maximum. Count them and put the count at the end in brackets.
- **Analogy:** Use the waiter in a restaurant - the customer places an order (the request), the waiter carries it to the kitchen (the system), and brings back the food (the response). Do not switch to a different analogy halfway.
- **Structure:** Analogy first, then one sentence of plain technical definition. Nothing after that sentence.
- **Audience:** Assume zero programming knowledge. If a word would need its own explanation, it is the wrong word.
- **Banned:** endpoint, protocol, interface, integration, payload. No bullet lists - this must read as prose.

## CHECK
After the 150 words and the count, add a line headed "Constraint check" confirming each of the five constraints above was met, and naming any you had to bend.

If the word limit and the structure genuinely conflict, tell me which you sacrificed rather than quietly breaking one.
Open Perplexity 1,022 characters
Example 2: Constraining Tone and Style

Instead of

Write an email telling my team we hit our sales target.

Perplexity version

## TASK
Write an internal email to the sales team announcing we have exceeded our quarterly sales target by 15%.

## CONSTRAINTS
- **Tone:** Exuberant and celebratory. Exclamation marks are welcome; two or three, not ten.
- **Style:** Direct and personal - "we" and "our team" throughout. No corporate jargon: no "leverage", "synergy", "circle back", "going forward", "touch base".
- **Must contain:** explicit thanks for the team's hard work; the figure "15% over target"; the announcement of a team celebration dinner next Friday.
- **Must not contain:** individual names singled out, next quarter's targets, any mention of what comes next. This email does one job.
- **Length:** Under 200 words including the subject line.

## OUTPUT
Subject line, then body. Nothing else.

Then, separately below the email, list any constraint above that pulled against another - celebratory tone against a jargon ban tends to be the hard one - and say how you resolved it.

If I will be writing team announcements regularly, tell me which of these constraints belong in Custom Instructions as standing house style rather than being retyped each time.
Open Perplexity 1,138 characters
Example 3: Using Negative Constraints to Sharpen Focus

Instead of

Give me a workout plan.

Perplexity version

## TASK
Create a 3-day-per-week beginner workout plan for building strength.

## POSITIVE CONSTRAINTS
- **Goal:** Functional strength for daily life. Not bodybuilding, not weight loss.
- **Equipment:** Bodyweight and dumbbells only.
- **Format:** One table with columns Day, Exercise, Sets, Reps, Why this exercise.

## NEGATIVE CONSTRAINTS
- No barbell work and no gym machines.
- No high-impact movement - no jumping, no running, no plyometrics. The user has sensitive knees.
- No exercise requiring a bench, a pull-up bar or a rack.
- No supplements, no diet advice, no body-composition talk.

## HOW TO HANDLE THE EXCLUSIONS
For each negative constraint, name the exercise you would normally have included and the substitute you used instead. A reader learns more from the swap than from the final table.

## SAFETY
This is a general plan, not medical advice, and the knee constraint is a reason to say so plainly in one line. Flag any exercise in your final table that still loads the knees meaningfully, even within the constraints - a sensitive-knee plan that quietly includes deep lunges is worse than no plan.

Do not pad the table to look complete. Four well-chosen exercises per day beats eight.
Open Perplexity 1,206 characters