# The Constraint Template

> A principle is a mood. A constraint is a rule with a failure condition
> attached, which means a person, a reviewer, or an eval can catch it being
> broken. This page has the shape, the tests a constraint has to pass, and
> twenty worked examples across consumer, enterprise, and agent products so you
> can see what specific looks like before you write your own.

---

## The shape

Every constraint is two clauses.

**Rule.** What is true of the product.
**Broken when.** The observable moment it failed.

That is the whole format. If the second clause is hard to write, the first
clause is a principle wearing a costume.

```
RULE: <what is always true>
BROKEN WHEN: <the specific observable failure>
CHECKED BY: <person | reviewer | eval | test>
```

---

## The four tests

Run every candidate through these before it goes in the doc.

**1. The stranger test.** Hand it to someone who was not in the room with five
real outputs. Can they point at the one that violates it? If they hesitate, it
is not specific yet.

**2. The cost test.** Name what breaking it costs: harm, trust, rework, money,
or time. If you cannot name a cost, cut the constraint. This is the test that
kills most of them, and that is the point.

**3. The disagreement test.** Could a reasonable person on your team argue for
the opposite? If not, you have written a truism. "The product should be usable"
passes nobody's day.

**4. The check test.** Name who or what catches it. A constraint nobody checks is
a wish with better grammar.

---

## How many

Three to six per surface. Ten means you wrote principles and called them
constraints. If you have twenty, they are not all load-bearing, and the team
will learn to skim all of them because of the eight that never mattered.

---

## Twenty worked examples

Steal the shape, not the content. Your product's constraints come from your
product's failures.

### Consumer

**1. Reversal parity**
RULE: Any action a user can take in one tap is reversible in one tap.
BROKEN WHEN: Accepting takes a tap and undoing requires a settings screen.
CHECKED BY: reviewer, on every new action.

**2. No surprise sends**
RULE: Nothing leaves the user's account without an explicit action from them in
that session.
BROKEN WHEN: A message, post, or invitation goes out from a background job the
user did not initiate.
CHECKED BY: eval on the action log.

**3. Suggestions never occupy the primary action**
RULE: A generated suggestion is never the largest or most emphasized control on
the screen.
BROKEN WHEN: The suggestion button outweighs the user's own compose or submit
control.
CHECKED BY: reviewer.

**4. Silence is a valid state**
RULE: When confidence is low, the product shows nothing rather than a weak guess.
BROKEN WHEN: A low-confidence output is displayed with the same treatment as a
high-confidence one.
CHECKED BY: eval, confidence threshold on the render path.

**5. The empty state teaches**
RULE: Every empty state names the one action that fills it.
BROKEN WHEN: An empty state is decorative, or explains the feature without
offering the action.
CHECKED BY: reviewer.

**6. No dark reversal**
RULE: Cancelling costs no more steps than subscribing.
BROKEN WHEN: Subscribe is two clicks and cancel is a chat with support.
CHECKED BY: person, quarterly walkthrough.

**7. Notifications carry the decision**
RULE: A notification contains enough for the user to decide without opening the
app.
BROKEN WHEN: The notification is a prompt to come look, with no content.
CHECKED BY: reviewer.

### Enterprise

**8. Admin visibility**
RULE: Anything the system does on a user's behalf is visible to their admin in
an audit trail within the hour.
BROKEN WHEN: An automated action exists only in the user's own view.
CHECKED BY: eval on the audit log.

**9. Confirmation is not disclosure**
RULE: A confirmation dialog is never the first place a user learns what the
system already did.
BROKEN WHEN: The dialog describes a completed action rather than a pending one.
CHECKED BY: reviewer.

**10. Bulk actions are previewable**
RULE: Any action affecting more than a handful of records shows the affected set
before it runs.
BROKEN WHEN: A bulk operation executes with only a count in the confirmation.
CHECKED BY: person, on every bulk feature.

**11. Permission-aware output**
RULE: Generated output never contains data the viewing user could not retrieve
directly.
BROKEN WHEN: A summary includes a record the user is not entitled to see.
CHECKED BY: eval, with fixtures per permission tier.

**12. Export parity**
RULE: Anything shown in the interface can leave it in a usable format.
BROKEN WHEN: A view exists that cannot be exported, printed, or copied.
CHECKED BY: reviewer.

**13. Degraded, not dead**
RULE: When the model or a dependency is unavailable, the manual path still works.
BROKEN WHEN: An outage in a generated feature blocks the underlying task.
CHECKED BY: test, dependency failure simulation.

**14. One owner per surface**
RULE: Every automated action names the human or team accountable for it in the
interface.
BROKEN WHEN: Users cannot tell who to ask about something the system did.
CHECKED BY: reviewer.

### Agent products

**15. The window before the act**
RULE: Any autonomous action has a stated reversal window, shown before it runs
and again after.
BROKEN WHEN: The user learns the window exists only when trying to reverse.
CHECKED BY: reviewer.

**16. Overnight actions get a morning summary**
RULE: Work done while the user was away is summarized on their next session
start, before anything else competes for attention.
BROKEN WHEN: The user has to go looking for what happened.
CHECKED BY: eval on session-start payload.

**17. Refusal is specific**
RULE: When the agent declines, it names the reason and the nearest thing it can
do.
BROKEN WHEN: The response is a generic inability message with no next step.
CHECKED BY: eval, refusal set scored for both fields.

**18. No irreversible action without a human in the loop**
RULE: Deletion, payment, external communication, and permission changes require
explicit confirmation in that session.
BROKEN WHEN: Any of those four categories executes autonomously.
CHECKED BY: test, action classifier on the tool-call path.

**19. Reasoning on request, not by default**
RULE: The trace is one action away, and never the first thing shown.
BROKEN WHEN: The interface leads with the reasoning and buries the answer, or
hides the reasoning entirely.
CHECKED BY: reviewer.

**20. State is legible before the ask**
RULE: Before the agent asks the user for anything, it shows what it already did.
BROKEN WHEN: A question arrives with no account of the work so far.
CHECKED BY: reviewer.

---

## Filling in your own

| Rule | Broken when | Cost when broken | Checked by |
|---|---|---|---|
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |

Pull the first three from things that have already gone wrong. Constraints
invented from first principles tend to describe a product nobody has shipped.
Constraints pulled from real failures describe yours.

---

## Where they live

In the same place the work lives, not in a separate design doc. A constraint set
that is not in the brief, the ticket, or the prompt is not operating, it is
archived. Put them where generation happens, so the constraint arrives before
the output does.

---

## The one thing to do this week

Take one surface. Write three constraints. Run the stranger test on them with
somebody who was not in the room. Rewrite whichever one they hesitate on, and
that hesitation is the most useful signal you will get all week.

---

_From "Specifying Behavior", chapter 3 of The Design Operating Model._
_falkster.com/design/specifying-behavior_