Context precedence: what wins when rules disagree

Once a library gets past a handful of rules, sources of truth start disagreeing. Field help text says one thing, a global rule says another, an object rule contradicts a field rule, and the user just typed "ignore that, I want all of them."

Something resolves that on every question. Either you decide what, or the model decides, and the model's decision is a function of retrieval order rather than anything you intended.

Two different things are going on here, and conflating them is where builds go wrong.

Authority: the ladder

What can override what. This doesn't bend.

Rank 1 isn't a design choice, it's a fact. Your allowlist is a semantic policy about what's worth sending the model; sharing rules and field-level security decide what the running user may see. Where they disagree, the platform wins whether you planned for it or not, and it wins silently.

Rank 2 is the choice people skip. A constraint written in guidance text is a request. The same constraint checked in code against the finished query plan is a boundary. That difference is the entire reason prompt instructions are not authorization.

Rank 4 matters more than it looks. Help text is genuinely useful as a baseline, and it's also the most common source of confidently stale meaning in a CRM. Any active rule about a field supersedes whatever the description says, including when the description sounds more official.

Specificity: breaking ties among equals

Within rank 3, more specific wins:

field rule  >  object rule  >  global rule

The reasoning is that whoever wrote the narrower rule knew the broader one existed and wrote the exception anyway.

The two combine in strict order: authority first, then specificity, then priority as the explicit tiebreak. Specificity never promotes a rule up a tier. A field rule does not beat a platform permission for being specific, and no amount of narrowness turns guidance text into authorization.

Where a live user instruction sits

This is the part people get wrong, and it matters more as agents get more capable.

A user instruction can narrow. It can never widen.

The override path is why the starter exclusion rule reads "unless the user has explicitly asked for operational testing records." The rule anticipated the request and granted the exception in advance. That's a decision someone made, recorded in a reviewable place, rather than a decision the model makes under social pressure at query time.

Put plainly: users can restrict the answer. They can't grant themselves access or switch off a safety rule by asking nicely. The adversarial golden questions exist to check that this holds when the asking gets persuasive.

When two rules genuinely conflict

Two active rules can contradict with nothing separating them. Somebody wrote a New ARR definition in March, someone else wrote a different one in July, both active, both scoped to Opportunity.

The failure mode is that you get an answer anyway. The model picks one, doesn't mention there was a choice, and which one wins depends on retrieval order. Change the sort and the number changes, with no edit to any rule.

Three things stop it:

Validate for it. Two active rules with the same category, overlapping appliesTo, and no priority gap is a lint error. Catch it in CI next to schema validation.

from collections import defaultdict
 
buckets = defaultdict(list)
for rule in active_rules:
    for obj in rule["appliesTo"]:
        buckets[(rule.get("category"), obj)].append(rule)
 
for (category, obj), group in buckets.items():
    if len(group) < 2:
        continue
    priorities = [r.get("priority") for r in group]
    if len(set(priorities)) < len(priorities) or None in priorities:
        ids = ", ".join(r["id"] for r in group)
        print(f"CONFLICT RISK  {category} on {obj}: {ids} — no priority separation")

That's a coarse check and it earns its keep anyway. It flags the pairs a human should look at, and most of them turn out to be one rule that should have been deprecated.

Fail closed at runtime. If a conflict reaches an agent, the correct resolution state is conflicting: stop and route to review. Don't let the model arbitrate.

Resolve it as a decision. Set priority deliberately, or retire one rule and set replacedBy. Never resolve a conflict by reordering the payload, because that fix is invisible and the next person to touch retrieval will undo it without knowing.

Why this is worth spelling out

Every other failure this site covers has the same shape, and precedence is the purest version of it: the conflict produces a result rather than an error.

Nobody sees a warning. There's no log line saying two rules disagreed. There's a number, in a sentence, with the right units and a plausible magnitude, and which of your two ARR definitions produced it is not recoverable after the fact.

• How to build a CRM AI context layer — the concept and full build
• The rule schema — priority, replacedBy, and the resolution states
• Permissions and safety — rank 1 and rank 2 in full
• Golden-question testing — the adversarial tier that tests this