How to Write a Precedence Order an Agent Can Explain

A clause is the unit of precedence. Give every rule a unique, stable ID (never renumber it when rules move; append instead), one priority signal, and a scope.

Pick one priority signal type per clause and be honest about which it is:

• A number (explicit weight). Easy to sort, easy to tie. Two clauses at the same weight are an unhandled conflict unless you add a tiebreaker.
• A specificity tag (general, condition-specific, exception). This encodes the common legal habit that a named exception beats the general rule, without arguing about numbers.
• A named exception (a clause that explicitly says "notwithstanding POL-REFUND-004"). The most readable signal for reviewers because the overrule is written down.

The mistake to avoid is mixing all three without a declared order of types. Decide once, up front, which signal type outranks which. A simple workable order: named exception beats specificity tag beats numeric weight, and within a type the more specific scope wins. Write that order as a clause itself, so it can be cited.

Scopes are where most wrong calls are born. Scope should always include a stop condition, for example applies only when transaction_amount_under_100 or applies only to customers onboarded before the policy date. A clause whose scope has no boundary is a clause that will overreach, and the trace will faithfully report the overreach as if it were correct.

You do not have to invent the need for IDs from scratch. Regulated environments already build identity into records: audit retention setup expects record types, per-user or per-service criteria, and an explicit priority level that says which policy wins when several exist (Microsoft Purview audit retention). That is the same shape as a precedence clause. Borrow the pattern rather than reinventing it.

The trace is a contract. Define it as a schema first, then instruct the model to fill it. Keep it small enough that a refusal is unambiguous.

{
  "decision": "hold_for_review",
  "winner_clause_id": "POL-REFUND-004",
  "overruled_clause_id": "POL-REFUND-001",
  "deciding_signal": "named_exception",
  "scope_checked": true,
  "confidence": 0.0
}

The instruction that goes with it:

Apply all clauses whose scope matches. If two or more clauses match with different outcomes, output winner_clause_id, overruled_clause_id and deciding_signal. deciding_signal must be one of: numeric_weight, specificity_tag, named_exception, tiebreaker. If you cannot identify both a winner and an overruled clause, or you cannot name the deciding signal, set decision to "escalate" and leave the other fields null. Never guess a signal.

Two things make this enforceable rather than aspirational. First, an explicit thinking section separated from the response section keeps the model from blending reasoning into the answer, a pattern popularized in hallucination-resistant prompt design where the model is asked whether it has enough facts before answering. Second, a structured output schema with required fields means the trace either validates or it does not. Evaluation frameworks let you assert on exact fields, on JSON structure, and on custom functions with thresholds, which is how you turn "the trace usually names the right winner" into a pass or fail rate (promptfoo expected outputs).

The refusal path deserves equal weight. If the trace is incomplete, escalate rather than default. A wrong automatic decision in a money movement or access-control flow costs more than a queued review. The legal AI literature makes the same point from the other direction: when contradictory retrieved evidence goes unresolved, generation models tend to merge it, producing outputs that are legally unsound (LegalWiz contradiction detection). Merging is exactly what an incomplete trace looks like from outside.

Explainability systems that record a full reasoning chain and keep it queryable show what this buys you operationally. When the trace links answer to source and stays persistent, you get audit logs and retrospective analysis instead of a one-time explanation (TrustGraph explainable AI). A precedence trace should be stored the same way, tied to the clause versions that were live when the decision was made.

Suppose a payments platform has four clauses governing whether a disputed charge is refunded, held, or denied.

Declared signal order: named exception, then specificity tag, then numeric weight. Declared tiebreaker within numeric weight: higher number wins, and equal numbers escalate.

Case 1. A standard card dispute with a missing delivery scan. POL-REFUND-001 wants a refund. POL-REFUND-004 names itself as an exception and wants a hold. The trace reads winner POL-REFUND-004, overruled POL-REFUND-001, deciding signal named_exception. Note what the numeric weight of 10 did: nothing. This is the decision rule most teams get wrong, assuming the bigger number wins. Under a declared order of types, the type outranks the number, and the trace makes that visible.

Case 2. An enterprise account with a fraud flag and a missing delivery scan. POL-VIP-010 (weight 50) says refund. POL-FRAUD-002 is a specificity tag and says deny. POL-REFUND-004 is a named exception and says hold. Winner: POL-REFUND-004, overruled POL-FRAUD-002, signal named_exception. The VIP weight never enters the final answer, which a human reviewer will want explained. The trace does that in one line.

Case 3. Two clauses with numeric weight 50 and no exception. The trace must come back escalate with null winner and null overruled. That is a designed outcome, and it should route to a queue rather than a coin flip.

The delivery evidence in case 1 is a good illustration of why the deciding signal needs to be checkable. Delivery confirmation is not a single thing: a basic delivered scan may not establish where a package was left or who received it, while photos, address data and signatures are stronger (chargeback evidence). "Delivery confirmation is missing" therefore depends on which evidence type the clause means. If the clause does not say, the trace will name a winner with a scope that is quietly too broad. Writing scope stop conditions is the fix.

Evidence discipline also matters for the reviewer's faith in the system. Merchants contesting chargebacks win roughly 30% to 45% of cases they fight, and those numbers drop fast when evidence is incomplete, mismatched or late (Chargeblast evidence packet). A trace is the agent's evidence packet. Incomplete, mismatched, late, and the review fails.

When a wrong call comes in, do not start by rewriting the prompt. Read the trace and work through these three checks in order. They are ordered by how often they are the culprit.

Move 1: Missing or untyped signal. The trace names a winner and an overruled clause but the deciding signal is numeric_weight when the correct answer depended on an exception. Cause: the exception clause has no explicit "notwithstanding" language, or its signal type was left unset. Fix: type every clause and rerun the failing case only. If the signal is null but a decision was still returned, your schema is not enforcing the refusal path; tighten validation first, before touching logic.

Move 2: Over-broad scope. The winner is right in principle but should not have applied here. Cause: the scope has no stop condition, so a regional or product-specific clause fired on a case outside its intended range. Fix: add the boundary to the scope, then rerun the full case set, not just the one that failed. Scope changes tend to fix one case and break three.

Move 3: Tie or undeclared type order. The trace shows two clauses at equal priority, or the agent ranked a specificity tag below a number because the type order was never stated. Fix: declare the tiebreaker and the type order as citable clauses, and add a regression test asserting escalate on every known tie.

A worked sequence. A refund was issued on a case that should have been held. The trace says winner POL-REFUND-001, overruled POL-REFUND-004, signal numeric_weight. That tells you immediately the agent compared numbers and ignored the exception type. You check POL-REFUND-004 and find its signal field is empty in the source config. That is move 1. You set named_exception, add a test that asserts the deciding signal equals named_exception for missing-delivery cases, and rerun. If it still fails, you check scope (move 2). If it passes but a neighboring case flips, you check ties (move 3).

Keep the trace, the clause version, and the test that covers the case. A trace without the clause version is not auditable, because the rule may have changed since.

This is where model routing becomes a practical question rather than an architectural one. You often want a cheap model for the bulk of routine cases and a stronger one for escalation review, without maintaining separate integrations. Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API with prepaid pricing in US dollars, which keeps the trace schema and prompt identical across models (https://quantaintelligence.ai/inference). Switching the model should never change the trace contract.

A reviewer defending a decision in a meeting or to a regulator needs a short, repeatable sequence. The checklist should mirror the trace field by field.

Two of these deserve elaboration because they are the ones reviewers actually catch.

Check 3 is about the rule for ranking, not the ranking itself. A reviewer does not need to know which number is bigger. They need to see that the signal used matches the declared order of signal types. If the declared order says named exception beats specificity tag, and the trace says a specificity tag beat a named exception, that is a defect even if the outcome happens to be right.

Check 5 connects the trace to evidence discipline. A clause that requires proof of delivery is not satisfied by a tracking scan whose location is unknown. Reviewers in payment disputes work this way already: the evidence must address the specific reason the dispute was raised, and mismatched evidence loses cases (evidence checklist). A good cover letter summarizes the situation and lists what is attached; a good trace does the same for a decision (dispute package checklist).

Check 7 requires persistence. The trace should be stored with the clause versions and be queryable later. That is the same principle as retention policies that keep audit records for a defined period and let you retrieve them after the fact (Microsoft Purview). If you cannot pull the trace for a case from six months ago alongside the rules that were live then, you cannot defend the decision.

For teams building agent-based review workflows, the larger lesson from dispute resolution research is that specialized agents doing triage, evidence retrieval and reasoning outperform a single generalist, but explainability and escalation calibration are among the four challenges that decide whether such a build reaches production (multi-agent dispute resolution). Precedence trace design is a cheap way to get ahead of the explainability challenge before you add more agents.

When the ruleset spans several business lines and you want the precedence order reviewed against your actual policies, a short working session with someone who has built these systems will surface scope gaps faster than another round of prompt edits. A free 30-minute AI discovery call is one way to get that review (https://quantaintelligence.ai/calendar).