A design principle is a mood. A design constraint is a rule with a failure condition attached, which is what makes it checkable by a person, a reviewer, or an eval.
Shape is three lines.
Rule: what is always true of the product. Broken when: the specific observable failure. Checked by: person, reviewer, eval, or test.
Three real ones, so the difference is visible.
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 an eval on the action log.
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 a reviewer.
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 an eval that scores the refusal set for both fields.
Hand any of those to somebody with five real outputs and you get a straight answer about which one violates it.
You cannot do that with "trustworthy."
Four tests decide whether a candidate survives. Most do not, which is the point.
The stranger test. Hand it to someone who was not in the room, with five real outputs, and ask them to point at the violation. Hesitation means it is not specific yet, and the hesitation is information about your writing rather than their judgment.
Cost test. Name what breaking it costs: harm, trust, rework, money, or time. No nameable cost, no constraint. This one eliminates the most candidates.
Disagreement test. Could a reasonable colleague argue for the opposite? If not, you wrote a truism. "The product should be usable" passes nobody's day.
And the check test. Name who or what catches it. If what you actually mean is that somebody would notice eventually, that is a hope wearing a checker's badge.
Three to six per surface. Ten means principles with a new label. Twenty means the team will skim all of them because of the eight that never mattered.
Pull the first three from failures that already happened in your product. Constraints invented from first principles describe a product nobody has shipped. Constraints pulled from real incidents describe yours, and they carry the political weight of a thing that already went wrong, which makes them much harder to argue away in planning.
Three categories produce the most useful constraints in AI products: reversal, disclosure, and refusal. Reversal parity: any action a user can take in one tap is reversible in one tap, broken when undoing requires a settings screen. Disclosure: anything the system does on a user's behalf appears in the admin audit trail within the hour, broken when an automated action exists only in the user's own view. None of those three were design surfaces three years ago.
Then put them where generation happens. The brief, the ticket, and the prompt. A constraint set living in a separate design document is archived, and archived rules do not change what ships. Putting constraints into system instructions means design is writing something that runs, which is the job now, and the alternative is that the behavior gets specified anyway by whoever was closest to the code at eleven at night.
Constraints that a machine can check should be checked by one, using the same mechanics as The Eval Is The Spec. The ones that need a human get a named reviewer and a moment in the process. Keep both kinds in the same document, because splitting them into a design list and an engineering list is how half of them stop being enforced.
One thing to do this week: take one surface, write three constraints with all three lines, then run the stranger test with somebody who was not in the room. Rewrite whichever one they hesitate on.
The template, the four tests, and twenty worked examples across consumer, enterprise, and agent products are in The Constraint Template. The full argument is Specifying Behavior.