What rules make up Mneme's precedence ladder?

Today, Mneme's compiler resolves overlapping ADRs in a fixed order: only accepted decisions compete; a decision explicitly named in another accepted decision's supersedes field is removed; within the same scope the higher priority wins (foundational over normal over exception); and on a priority tie the newer decision wins. Scope specificity orders the active set but does not defeat a broader decision. A tie none of these rules can break is a compile-time error. The canonical Decision Index (D1) moves resolution to explicit active-version selection instead of dates.

Why does supersession rank above scope specificity?

Supersession captures explicit team intent. When a newer decision declares supersedes: ADR-0017 in its metadata, the team has stated that decision A is replaced, not just refined, by decision B. In Mneme's current compiler, specificity does not pick a winner at all: broader and narrower scopes both stay active, and carve-outs are expressed with path selectors on the broader rule. Supersession, then same-scope priority, decide actual conflicts.

Why resolve precedence at compile time instead of runtime?

Compile-time precedence surfaces conflicts during build rather than during enforcement, so engineers see them in their PR or in CI instead of in production. The resolved corpus becomes a reviewable, versioned artifact that teams can inspect before any agent queries it. Most importantly, every consumer reads an already-resolved corpus, so no consumer re-implements the precedence rules and none can drift from them. Runtime precedence leaves each consumer to resolve conflicts itself, and two consumers can quietly disagree about the winner.

Why are first-match-wins and longest-rule-wins unsuitable for governance?

First-match-wins makes resolution load-order-dependent, so it is non-deterministic across consumers. Longest-rule-wins conflates path depth with specificity and ignores authoring intent such as supersession. Most-specific-wins alone cannot express that one decision replaces another, and newest-wins alone lets a broad new rule silently shadow older targeted exceptions. Mneme composes explicit rules instead: status, then supersession, then same-scope priority, then recency, with unresolvable ties treated as compile errors.

Precedence Semantics — Mneme HQ Concepts

Q: What are precedence semantics in architectural governance?

Precedence semantics are the rules that determine which of two conflicting decisions wins when both apply to the same file or query. Formally, they are a function from a set of matching decisions to a single winning decision: given two or more records whose scope patterns both match, the semantics deterministically selects one and cites the rule that produced the selection. Without precedence semantics, a governance system is a stack of overlapping suggestions, and which one applies depends on the run.

Q: What happens when the precedence ladder cannot resolve a conflict?

It is a compile-time error. If two accepted decisions share the same scope, priority, and date and have no supersession link, the compiler raises an error and the import stops until the team resolves the ambiguity, unless the conflict is explicitly approved. The runtime never sees a silently resolved conflict.

Architectural decisions overlap. That is not a flaw — it is how engineering teams accumulate knowledge. A broad standard ("services use the repository pattern") gets carved by a narrower exception ("legacy billing keeps direct DAO access until migrated"). A newer ADR supersedes an older one. A team-wide convention has a service-specific override. The shape of real-world governance is layered, not flat.

The question is not whether overlaps will exist. They will. The question is: when two decisions both apply to the file the agent is about to write, which one wins, and is that answer the same on every run, on every machine, from every consumer? The rules that determine the answer are the precedence semantics.

Ordered rules, deterministic outcome. Every overlap resolves the same way, every time, from every consumer. The ladder runs top-to-bottom; the first rule that produces a winner stops the descent. No tiebreaker is ever "the model decided."

What precedence semantics actually mean

A precedence semantics is a function from a set of matching decisions to a single winning decision. Given two or more records whose scope patterns both match the same query, the semantics deterministically selects one — and the selection is auditable. Every overlap maps to a single answer, and every answer cites the rule that produced it.

The semantics has three structural properties that distinguish it from ad-hoc conflict handling:

Total — every conflict resolves to a winner. There is no "tie" that defers to user judgment or model guessing.
Deterministic — the same set of records always produces the same winner, regardless of which order they were loaded, retrieved, or evaluated.
Citable — in the complete model, the winner is accompanied by the precedence rule that selected it. "ADR-0042 won by supersession" is a usable audit record; "ADR-0042 was chosen" is not.

The standard precedence ladder

Mneme's decision model defines precedence explicitly, and resolves it before enforcement ever runs. Two things are worth separating: what the current compiler does today, and the canonical resolution model the Decision Index is moving to.

Today: how the current compiler resolves overlap

When ADRs are compiled into the decision corpus, precedence is applied in a fixed order. The first rule that produces a winner stops the descent.

Status. Only accepted decisions compete. Proposed, deprecated, and superseded ADRs are excluded from the active set.
Explicit supersession. A decision that another accepted decision names in supersedes: ADR-0017 is removed. This is the strongest rule because it is an authored statement that one decision replaces another, not just refines it.
Same-scope priority. When two accepted decisions share a scope, the higher priority wins: foundational over normal over exception.
Recency. On a priority tie within the same scope, the newer decision wins.

A tie none of these rules can break is a compile-time error. Two accepted decisions with the same scope, priority, and date, and no supersession link: the compiler raises an error and the import stops until the team resolves the ambiguity, unless someone explicitly approves the conflict. The runtime never sees a silently resolved conflict.

Specificity orders; it does not override

In the current compiler, a narrower scope does not defeat a broader one. services and services.billing.legacy both stay in the active set, sorted most-specific-first so consumers see the narrower constraint first, and every active rule is evaluated at check time. A carve-out like "legacy billing keeps direct DAO access" is expressed by excluding that path from the broader rule with a path selector, not by letting a narrower decision silently win.

Where the canonical model goes (D1)

The canonical Decision Index (ADR-023) makes resolution an explicit property of the decision itself. A decision can have multiple immutable versions, and the active version is resolved explicitly rather than inferred from dates, source order, or whichever record happened to load. Supersession becomes recorded lineage in the decision graph. D1 moves this into the authoritative Decision Index and projects the active version back into the existing runtime, so current enforcement and retrieval behaviour stays the same for today's consumers.

Why precedence has to be at compile time, not runtime

It is tempting to imagine precedence as a runtime concern — let the governance system look at each matching decision and pick one when the query arrives. That model fails for the same reason ambiguous runtime behavior fails generally: it is unauditable and untestable.

Compile-time precedence has three properties runtime precedence cannot match:

Conflicts surface during build, not during enforcement. If two decisions cannot be reconciled, the import step stops and reports the contradiction, so the team resolves it before the corpus is used, not after a violation slipped through.
The resolved corpus is reviewable. Teams can inspect which decision applies to which scope before any agent queries the corpus. The resolved precedence is itself a versioned artifact.
Resolution is identical across all consumers. Because precedence resolves at compile time, every consumer reads an already-resolved corpus. No consumer has to re-implement the precedence rules — and therefore no consumer can drift from them.

Runtime precedence, by contrast, leaves each consumer to implement its own resolution. Two consumers can disagree about the winner, and the disagreement is invisible until both produce different verdicts. This is one of the most common failure modes in ad-hoc governance setups: every tool reads the same rules and quietly applies them differently.

The common misread: longest-rule-wins or first-match-wins

Two ad-hoc precedence rules show up often in real systems and are both unsuitable for governance:

Rule	Where it appears	Why it fails for governance
First-match-wins	Many config systems, .gitignore-style	Ordering becomes load-order-dependent — non-deterministic across consumers
Longest-rule-wins	Routing tables, some linters	Depth ≠ specificity for paths; ignores authoring intent like supersession
Most-specific-wins (alone)	CSS, some policy engines	Cannot model "this decision replaces that one" — supersession needs explicit precedence
Newest-wins (alone)	Document-oriented systems	A new broad rule silently shadows older targeted exceptions

The right model is a composition of explicit rules. Mneme's current compiler applies status, then explicit supersession (authored intent), then same-scope priority, then recency, and treats any remaining tie as a compile error. Scope narrowing is expressed with path selectors rather than an implicit most-specific-wins rule. The canonical model replaces date-based tiebreaking with explicit active-version resolution.

What precedence semantics enable

Precedence semantics are the prerequisite for several other governance properties:

Deterministic enforcement — without a deterministic conflict-resolution rule, the same query can produce different verdicts. Determinism downstream depends on precedence determinism upstream.
Auditability — a verdict can be traced to the decision that produced it. Today Mneme's verdicts cite the decision and the rule that fired; recording which precedence rule selected that decision belongs to the canonical model's evidence chain, bound to stable decision identity after D1.
Safe evolution — teams can supersede, narrow, or refine decisions without fearing silent regressions. The compiler surfaces unresolvable overlaps as errors instead of guessing.
Cross-consumer agreement — every supported surface reaches the same verdict because they all read an already-resolved corpus. Propagation depends on precedence resolution happening upstream of distribution.

Related concepts

Architectural compiler — the pipeline in which precedence resolution happens. The "resolve" stage is precedence semantics applied to the candidate record set.
Deterministic enforcement — the property that depends on precedence resolution producing the same answer every time.
Governance propagation — the property that becomes meaningful when every consumer reads an already-resolved corpus. Without precedence, propagation distributes ambiguity.