Rules Ranked by Binding Force

When every rule carries the same weight, an important constraint gets buried under a minor preference. What a tier gives you is a declaration of what yields first in a conflict, not a guarantee of compliance — MUST isn't a promise, it's a priority.

Problem

Instruction files are flat. "Indent with tabs" and "never touch the production database" sit side by side, in the same typeface, as bullet points of the same size. A human knows the latter matters more, but not because the instruction file says so — it's because the reader already knows. The model has no cue pointing to that weight.

And instructions aren't enforcement — they're text to read. So how well they're followed depends on how they're written, and full compliance is never promised (Official, see in Practice; what each source actually names is scoped there). Which means "something will get dropped" is the premise, not the exception, and staying flat means saying nothing about what drops. What drops is whatever happens to drop.

Context

Applies when:

• Rules are mixed together — non-negotiables, recommendations, and mere preferences coexist in one file
• The cost of violation varies widely — one side means a rewrite, the other means something irreversible
• Only the author knows the weights — the implicit weighting lives outside the instruction file

Does not apply when:

• A constraint can be stopped mechanically. A gate is more reliable than piling binding-force language onto words. The official docs themselves say to "skip conventions that standard linters or formatters already enforce" (see in Practice)
• There are only a handful of rules, all of equal weight. Only the cost of building tiers remains. A tier means something only in contrast with other tiers — no contrast, no tier

Boundary with neighboring patterns:

• Instruction Layering and Scoping — where it applies (scope) is that pattern; how strongly it applies (binding force) is this pattern. Different axes, used together
• Failure as Institutional Memory — what to write is that pattern; what binding force to give it is this pattern. Anything that doesn't pass that pattern's test never makes it onto a tier at all
• Separating Mechanical Gates from Semantic Gates — this pattern's limit lives here. Binding force is words, and words work only non-deterministically. If a failure must be stopped deterministically, make it a gate, not words
• Resident Context Inventory — a ranked rule is still resident content, paying rent every turn. A tier doesn't exempt it from rent

Solution

Why this works. The starting point is a single fact: instructions are context, not enforced configuration (Official, see in Practice). Were it enforcement, a conflict would be rejected before execution — if two settings contradicted each other, one would be bounced as invalid.

Text to read is different. Contradictions load side by side, and the conflict gets resolved inside the model, on the spot.

This is where this pattern plays. A conflict always gets resolved. The question is whose criteria it gets resolved by.

A flat set of rules hands that resolution entirely to the model. When it hits a situation where "indent with tabs" and "never touch the production database" can't both hold, nowhere in the instruction file does it say which one to yield. It's in the author's head. What isn't written was never handed over.

Writing binding force means handing over the conflict-resolution rule before the conflict happens. A tier doesn't add a new rule. What it adds is an ordering between rules.

Here's where a mix-up happens. Adding a tier doesn't guarantee compliance. The tier declaration is itself an instruction, and instructions aren't enforcement — meaning a tier, too, is material that works only non-deterministically. Following this through, what this pattern can promise gets narrow:

What a tier is trying to change isn't "whether it's followed" — it's "what yields first when there's a conflict." And a tier only declares that order; it does not guarantee it.

So "I wrote MUST and it still wasn't followed" isn't this pattern failing. MUST was never a guarantee to begin with. It's a declaration of priority.

Miss this and run with it anyway, and eager to make things stick, tiers get piled with rules until everything is MUST. At that point the tier has already vanished — if everything is MUST, MUST says nothing more than "this is a rule," and you're back to a flat list.

A tier's meaning is made of its difference from other tiers. So the more tiers you add, the thinner each one gets.

One more thing: binding-force vocabulary conveys strength, not why it's strong. "MUST" says nothing more than "don't break this." When the model hits a situation no one anticipated, the vocabulary gives it no material for judging whether this rule reaches that far.

The reason lives where the vocabulary doesn't reach — the official docs state plainly that including the reasoning behind a rule improves the model's judgment in edge cases (see in Practice). A tier gives order; a reason gives reach. Both are needed.

Trade-offs

Advantages

• Conflict resolution becomes a declaration on our side. In a flat list, the judgment of which to yield falls to the model every time, with no grounds on our side to even examine the outcome. With a tier, at least what was handed over stays on our side.
• Heavy rules stop getting buried under light preferences. It resolves the very state of "never touch the production database" sitting in the same typeface as an indentation preference. Weight isn't always something the reader already knows.

Costs

• Adding a tier is not a guarantee. The official docs state plainly that not every instruction is followed perfectly every time (see in Practice; the scope of what the original text names is limited there). A tier only declares order — and there's no guarantee that declaration gets read either. A failure that must be stopped deterministically belongs in a mechanical gate, not words ("Separating Mechanical Gates from Semantic Gates").

• Tiers invite filling. A hierarchy of binding force tends to push toward adding more rules — build a tier, and something wants to go in it. But writing MUST over something the model already does just adds noise. The official docs name this exact kind of writing as "adding noise without improving effectiveness." The reason given is already optimized — the model already does it (see in Practice). One individual repository's audit independently flags the same model-babysitting tendency in rules (a judgment, not a measurement; see in Practice).

  The structure of binding force doesn't exempt content from needing justification. This pattern only decides which tier something sits in; whether it should be written at all is tested by Failure as Institutional Memory.

  The two are on different axes — this pattern handles the structure of binding force; that pattern handles the content of a rule. Having built a tier is not a reason the content passed that test.

GitHub Copilot in Practice

This pattern is a tool-independent practice; binding force is realized as a way of writing inside the container of an instruction file. So this section shows not a feature name but how to practice this on Copilot, and the granularity the official docs support versus the kind of writing they don't.

github.com — custom instructions for code review

What this section's Official quotes actually cover

Every quote below describes custom instructions for Copilot code review specifically. Do not cite it as a benchmark for instruction files in general. Neither the numbers nor the advice should be extended beyond what the source text names.

Source: Using custom instructions to unlock the power of Copilot code review (retrieved 2026-07-16).

The official docs list three limits on whether an instruction actually applies Official:

• Non-deterministic behavior: Copilot may not follow every instruction perfectly every time.
• Context limits: Very long instruction files may result in some instructions being overlooked.
• Specificity matters: Clear, specific instructions work better than vague directives.

The first — not every instruction is followed perfectly every time — is the basis for this pattern's cost. But what the original text speaks to is Copilot code review custom instructions, not instructions in general. The basis for the general premise placed in Solution (instructions aren't enforcement) is in the Claude Code text below.

Granularity is given too Official:

Begin with 10–20 specific instructions that address your most common review needs, then test whether these are influencing Copilot code review in the way you intended.

Start with 10–20 specific instructions, and test whether they're influencing things as intended. Before building a tier, start at this scale. A tier is about order, and order is easier to assign the fewer things there are to count.

And the official docs give a section its own name — instructions not to write Official:

Vague quality improvements:

• Be more accurate
• Don't miss any issues
• Be consistent in your feedback

These types of instructions add noise without improving Copilot's effectiveness, as it's already optimized to provide accurate, consistent reviews.

This is the basis for the trade-off "tiers invite filling." Slapping a MUST on "be accurate" doesn't change the fact that it adds noise without improving effectiveness. The reason is given too — already optimized, meaning it's what the model already does. A tier of binding force doesn't exempt content from this test.

VS Code — how to write custom instructions

Source: VS Code — Custom instructions (retrieved 2026-07-16). The official docs list writing advice, three of which apply directly to this pattern Official:

• Keep your instructions short and self-contained. Each instruction should be a single, simple statement.

One rule, one sentence. This is a condition that comes before applying a tier. If one bullet carries multiple claims, no single tier can be assigned to it — which tier does "never touch the production database, and also indent with tabs" get? Being in a shape that can carry a tier is the precondition for applying one.

• Include the reasoning behind rules. When instructions explain why a convention exists, the AI makes better decisions in edge cases.

State why a convention exists, and the AI's judgment in edge cases improves. This is the official docs' own answer to what Solution described as "vocabulary conveys strength, but not why it's strong." Note the qualifier edge cases — reasoning does its work exactly where binding-force vocabulary doesn't reach. A tier and a reason don't compete. A tier gives order; a reason gives reach.

• Focus on non-obvious rules. Skip conventions that standard linters or formatters already enforce.

Skip conventions that a linter or formatter already enforces. This is the basis for "does not apply" in Context — "constraints stoppable mechanically." What the official docs are saying is that writing something a machine can already enforce into an instruction is putting it in the wrong place. Rewriting something enforceable as something unenforced just makes it weaker.

Equivalents in other tools — Claude Code's instruction file

The general premise placed at the start of Solution is in Anthropic's original text (source: code.claude.com/docs/en/memory, retrieved 2026-07-16) Official:

CLAUDE.md files are loaded into the context window at the start of every session, consuming tokens alongside your conversation. ... Because they're context rather than enforced configuration, how you write instructions affects how reliably Claude follows them. Specific, concise, well-structured instructions work best.

Context rather than enforced configuration — instructions are context, not enforced configuration. That's exactly why how you write them affects how reliably Claude follows them. This pattern counts binding force as one part of that "how you write it."

But the original text doesn't say "write binding force." It says only as far as specific, concise, well-structured. This text isn't used as the basis for "adding a tier improves compliance" — what it supports is only "instructions aren't enforcement / how you write it affects compliance," and this pattern's core (a binding-force tier becomes material for conflicts) is placed in Solution as a tool-independent argument built on top of that.

Two vendors, in separate resources, writing the same shape

GitHub writes, about Copilot code review custom instructions, that "not every instruction is followed perfectly every time." Anthropic writes, about CLAUDE.md, that "instructions are context rather than enforced configuration, and how you write them affects how reliably they're followed." What each original text names is different, and neither can be extended to the other's scope. Yet the two agree on one single point — instruction compliance is not guaranteed. This pattern's cost (a tier isn't a guarantee) stands on that agreement.

Observed in real-world use

One individual repository's audit (as of 2026-07-07, Claude Code environment, n=1) flags a model-babysitting tendency in its rules. Things like "don't claim done until tests pass" are current models' default behavior, so writing them down has little marginal value — that's the judgment.

This is the auditor's judgment, not a measurement. No counterfactual was run — no one ran without such rules and counted whether behavior changed. Measured can only cover what's visible without running a counterfactual, and this judgment doesn't qualify. Still, it's worth recording. The official docs' "add noise ... already optimized," and an independent individual-environment audit, reach the same conclusion — building a binding-force tier is no reason to put something the model already does into that tier. The weight of the evidence comes from the agreement itself.

Also Known As

Name	Source
Constitutional pattern	Folklore — circulates in the community, but its primary source can't be traced (below)
MUST / SHOULD / WON'T	Folklore — same as above. Circulates as binding-force vocabulary, but no established source could be confirmed
Rules Ranked by Binding Force	Descriptive — this catalogue's descriptive name; no primary source uses it

Both "constitutional pattern" and "MUST / SHOULD / WON'T" are current in the community. But this catalogue could not trace a primary source for either. Untraceable doesn't mean "wrong" — it means "provenance can't be shown." A name whose provenance can't be shown isn't written as if it could.

This distinction matters in practice. The name "constitutional pattern" sounds as if the norm carries authority — a constitution is a norm that becomes void when broken. But as Solution showed, breaking a tier in an instruction file voids nothing. The strength the name promises and the strength the mechanism actually has don't match. The vocabulary carries the same risk. Capitalized MUST looks like a term of art defined somewhere, but this catalogue could not confirm that source. So this catalogue gave a descriptive name matched to the mechanism's actual strength. Ranking by binding force means declaring a hierarchy, not enforcing one.

Related

• Instruction Layering and Scoping — where it applies (scope) is that pattern; how strongly it applies (binding force) is this pattern. Different axes, used together. The same single rule can declare both scope and binding force. Binding force alone can't narrow where a rule applies, so read that pattern too when you also want to narrow the scope
• Failure as Institutional Memory — what to write is that pattern; what binding force to give it is this pattern. The order is "should it be written" first, "which tier" second. Having built a tier isn't a reason it should be written
• Separating Mechanical Gates from Semantic Gates — this pattern's limit lives here. Binding force is words, and words work only non-deterministically. A failure that must be stopped deterministically belongs in a gate, not a tier. The official docs also say "don't write conventions a linter already enforces" (see in Practice)
• Resident Context Inventory — a ranked rule is still resident content, paying rent every turn. A tier doesn't exempt it from rent. Placing something in a heavy tier is no reason that rule gets to keep its seat
• If reading just one more next: One Authoritative Source for Instructions — having built a tier, it's next to consolidate the authoritative source into one