The Constraint Template
That is the whole format. If the second clause is hard to write, the first clause is a principle wearing a costume.
The template
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