A platform brief lists eleven non-functional requirements and marks every one of them "must" - 99.99% availability, p99 under 150 ms, zero data loss, seven-year audit retention, and seven more. What does that document actually constrain, and what is the single edit that makes it constrain anything?

The mechanism

A requirement constrains a design only if it is allowed to lose. Eleven musts means nothing can lose, which means the document cannot settle a single argument. It still has an effect, but not the one the author intended: because every line is a must, anyone can cite any line to block anything, and the document becomes a weapon in the review rather than an input to the design.

The conflict is usually arithmetic and arrives early. Zero data loss across regions means a commit is not acknowledged until a second region has it, and a US coast-to-coast round trip is roughly 60–80 ms. Put that on the write path and a 150 ms p99 budget is mostly gone before the application does anything. Nobody noticed at writing time because each requirement was checked against the system and none was checked against the others.

So the first time two musts collide, in week three, the collision is resolved by whoever is in the room that day, on the basis of who argues better. The brief provides no basis for appeal, and six months later nobody can reconstruct why availability beat retention.

The one edit

Write the order in which they give, and the name of the person who owns that order. Three lines is enough: "When these conflict, the order in which we sacrifice is retention window, then p99, then availability target; data loss is not on this list. Owner: the VP of Engineering, reviewed each quarter."

That edit does three things. It makes the brief usable in week three without a meeting. It separates the requirements that are genuinely non-negotiable — a statutory retention period, a contractual RPO — from the nine that are preferences with numbers on them, which is a different list and should be a different heading. And it turns the brief into something falsifiable: if in practice the team sacrifices availability first, the order was wrong and someone has to say so.

The practical rule: a brief with more than about three top-priority requirements has no priority. Ask for the order. If nobody will give it, write the order you are designing to, circulate it, and let silence be assent — the record then exists either way.

Common weak answers

• "Quantify them." They are already quantified. Numbers without a rank order do not resolve a conflict between two numbers.
• "Push back on all of them." This reads as the architect refusing the requirements, and the sponsor correctly hears it as "no". Asking for the order asks for one small thing and gets the whole benefit.
• "Design for the strictest interpretation of each." The strictest set is often jointly impossible, and building toward it means discovering that in month six instead of week one, with a design already committed.

When this is the wrong answer

Where the requirement set is genuinely small and non-conflicting — one availability target, one latency target, one retention rule — asking for a sacrifice order is bureaucracy. And do not rank a legal obligation against a performance preference in one list. Statutory retention, a regulator's reporting deadline and a signed contractual RPO are constraints: they belong above the line, unranked, with their source and the clause cited. The sacrifice order applies to everything below it.