Skip to content

Consistency Model

Prime #
738
Origin domain
Computer Science & Software Engineering
Subdomain
distributed systems → Computer Science & Software Engineering

Core Idea

A consistency model is an explicit contract about what different observers of a shared state are allowed — and not allowed — to see, and in what order, when updates are made concurrently. It does not say what the state is; it says which interleavings of reads and writes count as legal observations, and therefore what observers may assume about one another's view. The structural commitment is to specify, in advance and independently of any particular state value, the set of permitted observation sequences out of the vastly larger set of conceivable ones, so that every party can reason about the shared referent without re-deriving from scratch what divergence is possible. The model is, in effect, a thin specification interposed between the messy reality of concurrent updates with propagation delay and the applications that must be built on top of it.

The structural variables are spare and substrate-free: a shared object that multiple observers reference as the same thing; an observer set whose views of the object may differ; an operation history of reads and writes across all observers; and an ordering relation constraining which permutations of that history each observer is permitted to witness. Fixing the model is fixing that constraint, and the central trade-off it governs is also structural: stronger models forbid more behaviours and demand more coordination — more latency, bandwidth, or blocking — while weaker models permit more behaviours and allow looser coupling. Every domain in which a state is shared across observers separated by propagation delay confronts this trade-off whether or not it has the vocabulary for it, which is what makes the consistency model a recurring structural object rather than a fact about computers; the vocabulary, however, is unmistakably engineered in origin, so the transfer to non-computing substrates is real but largely analogical.

How would you explain it like I'm…

Shared Scoreboard Rules

When lots of people are looking at the same thing that keeps changing, a Consistency Model is the promise about what each person is allowed to see and in what order. It's like a rule for a shared scoreboard that says how out-of-date or out-of-order your view can be. It doesn't say what the score is — just what views are fair and which ones aren't allowed.

Who Sees What, When

A Consistency Model is a clear agreement about what different people watching the same shared thing are allowed to see, and in what order, when it's being changed by many people at once. It doesn't tell you what the thing actually is; it tells you which sequences of reads and writes count as legal, so everyone can reason about what others might be seeing. There's a built-in trade-off: a strict model bans more weird views but needs more coordination, which makes things slower; a loose model allows more odd views but lets everything run faster and more independently. Any time something is shared among people separated by delay, this trade-off shows up.

Legal-Observation Contract

A Consistency Model is an explicit contract about what different observers of a shared state are allowed — and not allowed — to see, and in what order, when updates happen concurrently. It doesn't say what the state is; it says which interleavings of reads and writes count as legal observations, and therefore what observers may assume about one another's view. The point is to specify in advance, independent of any particular value, the set of permitted observation sequences out of the far larger set of conceivable ones, so each party can reason about the shared thing without re-deriving what divergence is possible. The variables are spare: a shared object, an observer set whose views may differ, an operation history of reads and writes, and an ordering relation constraining which permutations each observer may witness. The central trade-off is structural too: stronger models forbid more behaviours and demand more coordination (latency, bandwidth, blocking), while weaker models permit more and allow looser coupling.

 

A Consistency Model is an explicit contract about what different observers of a shared state are allowed — and not allowed — to see, and in what order, when updates are made concurrently. It does not say what the state is; it says which interleavings of reads and writes count as legal observations, and therefore what observers may assume about one another's view. The structural commitment is to specify, in advance and independently of any particular state value, the set of permitted observation sequences out of the vastly larger set of conceivable ones, so that every party can reason about the shared referent without re-deriving from scratch what divergence is possible. The model is, in effect, a thin specification interposed between the messy reality of concurrent updates with propagation delay and the applications built on top of it. The structural variables are spare and substrate-free: a shared object that multiple observers reference as the same thing; an observer set whose views may differ; an operation history of reads and writes across all observers; and an ordering relation constraining which permutations of that history each observer is permitted to witness. Fixing the model is fixing that constraint, and the central trade-off it governs is also structural: stronger models forbid more behaviours and demand more coordination — more latency, bandwidth, or blocking — while weaker models permit more behaviours and allow looser coupling. Every domain in which a state is shared across observers separated by propagation delay confronts this trade-off whether or not it has the vocabulary for it, which is what makes the consistency model a recurring structural object rather than a fact about computers; the vocabulary, however, is unmistakably engineered in origin, so the transfer to non-computing substrates is real but largely analogical.

Structural Signature

the shared object referenced by all parties — the set of divergent observers — the history of concurrent reads and writes — the ordering constraint on permitted observation sequences — the strength-versus-coordination-cost trade-off — the propagation-delay (staleness) budget

A configuration is a consistency model when each of the following holds:

  • A shared object. Multiple parties reference the same logical state as one thing, even though their physical copies or views may differ.
  • An observer set. There are distinct vantage points whose views of the object can diverge because updates reach them at different times.
  • An operation history. Across all observers there is a record of reads and writes; the model constrains this history rather than the state's values.
  • An ordering constraint. The model selects, out of all conceivable permutations of the history, the subset of observation sequences each observer is permitted to witness — this constraint is the model.
  • A strength axis with a cost dual. Stronger models forbid more interleavings and demand more coordination (latency, bandwidth, blocking); weaker models permit more divergence and allow looser coupling, so position on the strength axis is position on a cost axis.
  • A staleness budget. Propagation delay is a first-class variable: how stale a local view may be before it bites is an explicit, tunable bound, and divergence may be tolerated and then compensated (reconciliation, audit, apology) rather than prevented.

These compose into an inter-observer contract: fix a shared object, name the observers and their operation history, declare which orderings each may witness, and tune that declaration per operation against the strength-versus-cost and staleness trade-offs.

What It Is Not

  • Not concurrency. Concurrency is the condition — multiple operations in flight at once; a consistency model is the contract specifying which observations of that concurrency are legal. Concurrency creates the problem the model governs; the model is the chosen answer, not the phenomenon.
  • Not consistency (logical). Logical consistency is the non-derivability of a contradiction from a commitment set; a consistency model constrains which orderings of reads and writes across observers are permitted. One is about a static rule-set avoiding self-contradiction, the other about dynamic observation contracts under propagation delay.
  • Not coordination. Coordination is the mechanism (consensus, locking) that enforces a strong model; the consistency model is the specification of what is to be enforced. A strong model demands coordination, but the contract and the machinery that satisfies it are distinct.
  • Not fault_tolerance. Fault tolerance concerns surviving component failures; a consistency model concerns legal observations under concurrency even when nothing has failed. They interact (partitions force consistency/availability trade-offs) but answer different questions.
  • Not data_integrity. Data integrity is about state being correct and uncorrupted; a consistency model is about which divergent views of state are permitted across observers. State can be perfectly intact yet legitimately observed at different staleness by different parties.
  • Common misclassification. Assuming "everyone sees everything immediately" — an implicit strongest-model assumption that holds silently at small scale and breaks silently at large scale. The catch: ask whether the system has a written model at all; an unstated guarantee is a latent failure priced as a free feature.

Broad Use

  • Distributed computing. Linearizability, sequential consistency, causal consistency, eventual consistency, and snapshot isolation are named models for replicated databases, file systems, and caches, each a precise rule about which read outcomes are legal given a history of concurrent writes.
  • Multi-jurisdictional law and records. Title registries, civil registers, and tax records held across jurisdictions need a rule for what each office may assume about the others' state, and closing a property sale presumes a particular consistency guarantee about the registry.
  • Organizations with multiple sites. Branch offices, factories, and field teams act on locally cached versions of corporate truth, and the chosen answer to "how stale may a local copy be, and must changes propagate before being acted on?" is a consistency model in all but name.
  • Scientific publication and replication. Preprints, peer-reviewed versions, errata, and retractions form a system in which different readers see different current truths, and the norms about which version binds whom and how long propagation may take constitute an implicit consistency model for the scholarly record.
  • Memory hardware. CPUs and GPUs publish memory models (x86-TSO, ARM relaxed, the Java memory model) specifying which orderings of reads and writes the hardware honours, and programmers reason against these rather than against transistor behaviour.

Clarity

A consistency model converts a vague worry — "will everyone see the same thing?" — into an explicit, testable contract: given any history of operations, which observation sequences are permitted? It surfaces the hidden assumption every multi-observer system carries, that there is something it means for the parts to share state, and forces that assumption to be stated rather than left to silently fail. The clarifying force is to make the divergence budget explicit: a strong model declares that observers may not diverge at all, a weak one declares precisely how much and in what respects they may, and in either case the previously implicit question of who is allowed to see what, when, becomes a written specification one can check operations against. This is exactly the clarity a system needs at the moment it scales, because the naive assumption that "everyone sees everything immediately" is one that holds silently at small scale and breaks silently at large scale; naming the model converts a future surprise into a present, examinable design choice, and lets the designer reason locally — "I write, then I read; what am I guaranteed?" — rather than case by case over every possible interleaving.

Manages Complexity

Without a stated consistency model, every interaction across a distributed system must be reasoned about one interleaving at a time, an intractable accounting once concurrency and propagation delay are present. With one, the designer replaces an enormous space of possible histories with a small set of permitted ones and draws a line above which applications can be built without re-examining the substrate: the model is a thin specification that absorbs the combinatorial complexity of concurrency into a few stated guarantees. The management move is to match the guarantee to the operation rather than to the system as a whole — strong consistency for funds movement, eventual consistency for like-counts — so that the expensive coordination is paid for only where it is needed and the cheap, loosely-coupled path is used everywhere else; most real systems are therefore mixtures, applying different models per operation type on the same shared object. A further management lever is to treat propagation delay as a first-class variable: the recurring question "how stale may local belief be before it bites?" is the same in caches, branch offices, jurisdictional registries, and rumour networks, and answering it explicitly lets one accept staleness deliberately and add compensating discipline — reconciliation jobs, audits, apology pathways such as refunds or errata — rather than paying for the strongest guarantee everywhere. The complexity that the model manages is the complexity of unbounded divergence; what it buys is the ability to bound and reason about that divergence at a stated cost.

Abstract Reasoning

The consistency model's structural setup — a shared object, a set of observers, a history of operations, and a constraint on the permutations each observer may witness — is substrate-free, and once it is in place a fixed set of trade-offs recurs. Strength-versus-cost reasoning: stronger models forbid more behaviours and require more coordination, so moving along the strength axis is always a movement along a cost axis, and the analyst can reason about where on that axis a given operation should sit by asking how much divergence its correctness can tolerate. Per-operation tiering: because different operations on the same object can legitimately use different models, the right unit of analysis is the operation rather than the system, and recognizing this prevents the error of imposing the strongest needed guarantee uniformly. Staleness budgeting: treating the maximum tolerable propagation delay as an explicit parameter turns "is this copy fresh enough?" into a checkable bound and lets one design the refresh discipline to meet it. Compensation as an alternative to prevention: where a strong guarantee is too costly, one can adopt a weaker model and add a reconciliation, audit, or apology pathway that repairs the rare divergence after the fact, trading prevention for correction. Each of these is a reasoning template stated in terms of observers, histories, and permitted orderings, and each applies — with the engineered vocabulary translated — to a registry system, a multi-site organization, or a scholarly record as readily as to a replicated database.

Knowledge Transfer

The transferable content of the consistency model is a set of design interventions that carry across substrates because each attaches to the abstract inter-observer contract rather than to any particular technology, with the caveat that the vocabulary is CS-native and the transfer outside computing is by analogy. The first transferable move is make the guarantee explicit before scaling: a small system's implicit "everyone sees everything immediately" assumption breaks silently as it grows, and naming the model converts that latent failure into a present choice — the move applies as much to a company opening branch offices as to a service adding replicas. The second is match the model to the operation, not the system: the discipline of using strong consistency where correctness demands it (funds movement, a last-unit reservation, a binding registry entry) and eventual consistency where it does not (display counts, cached read-only views) transfers directly to a registry that holds a linearizable central truth while local recorders' offices hold cached copies, and to an organization that keeps some figures authoritative-and-synchronized while letting others lag. The third is use a weaker model and add compensating discipline: rather than pay for the strongest guarantee everywhere, accept bounded staleness and add reconciliation, audit, or apology pathways — refunds and errata and recount procedures are the human-scale analogues of a reconciliation job. The fourth is treat propagation delay as a first-class variable: the question of how stale a local belief may be before it causes harm is one question whether the copy is a cache, a branch office's records, a jurisdiction's registry, or a rumour, and budgeting that delay explicitly is the same intervention in each. A multinational retailer that uses cached stock counts at the storefront, a linearizable decrement against a warehouse reservation so two stores cannot sell the same last unit, and a snapshot-isolation view for nightly reconciliation is making exactly the structural decisions — what guarantee, for whom, at what cost — that a national land registry makes when local offices hold cached title information, the central registry holds the linearizable truth, and contract law specifies which office's view binds in a dispute; the decisions transfer one-to-one, with only the substrate and the vocabulary changing.

Examples

Formal/abstract

Consider a replicated key-value store holding a single counter, with three replicas as the observer set and the counter as the shared object. Two clients concurrently issue increment writes; a third issues a read. The operation history records all three operations plus their propagation between replicas. Now fix the ordering constraint under competing models. Under linearizability (the strongest model), there must exist a single total order of the operations consistent with real-time: if the read is issued after both increments have returned, it must observe the counter at \(+2\); no replica may legally return \(+1\) or $0\(. Under *causal consistency*, only causally-related operations are ordered, so a read that has seen one increment must see all increments that happened-before it, but concurrent increments may be observed in either order. Under *eventual consistency* (the weakest), the read may legally return any value the history could produce — \$0\), \(+1\), or \(+2\) — provided all replicas converge once writes quiesce. This is the strength-versus-cost trade-off made precise: linearizability forbids the most interleavings and demands the most coordination (a consensus round, blocking, latency), while eventual consistency permits maximal divergence and demands none, paying instead with a staleness budget — how long the read may lag — and a reconciliation step to converge. The same shared object thus admits a whole lattice of legal-observation contracts, and the design act is choosing one.

Mapped back: The replicated counter instantiates the full signature — a shared object, divergent observers, a concurrent operation history, an ordering constraint that is the model, and a strength axis dual to a coordination-cost-and-staleness axis.

Applied/industry

A multinational retailer's inventory system makes per-operation consistency choices on one shared object — the stock count — exactly as the formal lattice predicts, and the engineering vocabulary translates cleanly into operational design. The shared object is the count of a given SKU; the observers are storefront displays, warehouse reservation services, and the nightly reconciliation job. The retailer matches the model to the operation, not the system. The storefront "items remaining" badge uses eventual consistency — a cached, possibly-stale count is fine, since showing "7 left" when there are really 6 harms little, and the staleness budget is generous. But the decrement that reserves the last unit uses a linearizable operation against the warehouse: two stores must not both sell the final item, so this write pays for a coordination round to enforce a single total order. The nightly audit uses a snapshot-isolation view, reading a consistent point-in-time cut across replicas without blocking live traffic. Where the system deliberately tolerates divergence, it adds compensation rather than prevention: if an oversell slips through, a refund-and-apology pathway repairs it after the fact, the human-scale analogue of a reconciliation job. The identical structural decisions — what guarantee, for whom, at what cost, with what compensation — are made by a national land registry where local recorders' offices hold cached title copies (eventual), the central registry holds the linearizable binding truth, and contract law specifies which office's view governs in a dispute.

Mapped back: Retail inventory and a multi-jurisdictional land registry both tier consistency per operation on a shared object — strong where correctness demands it, weak-plus-compensation elsewhere — budgeting staleness explicitly, instantiating the inter-observer contract in distributed-systems and institutional-records substrates.

Structural Tensions

T1 — Strength versus Coordination Cost (the core trade). The defining axis: stronger models forbid more interleavings and demand more coordination (latency, bandwidth, blocking); weaker ones permit divergence cheaply. The failure mode is selecting strength by intuition rather than by correctness need — paying for linearizability on a like-counter, or accepting eventual consistency where a last-unit sale demands a total order. Diagnostic: ask how much divergence each operation's correctness can actually tolerate; if a stale or reordered view causes no harm, strong consistency is overpayment, and if it causes an oversell or double-spend, weak consistency is a latent bug priced as a feature.

T2 — System-Wide versus Per-Operation Guarantee (scopal). The right unit of analysis is the operation, not the system; the same shared object can legitimately carry different models per operation. The failure mode is uniform imposition — choosing one model for the whole system, forcing the strongest needed guarantee everywhere (crippling throughput) or the weakest tolerable one everywhere (corrupting the operations that needed strength). Diagnostic: ask whether a single model is being applied across heterogeneous operations; if reads and reservations, displays and decrements share one guarantee, the system is either over-coordinating cheap paths or under-protecting critical ones.

T3 — Prevention versus Compensation (sign/direction). Strong models prevent divergence; weak-plus-reconciliation tolerates it and repairs after the fact (refunds, errata, recounts). The failure mode runs both ways: paying prevention cost where cheap compensation would suffice, or relying on compensation where the divergence is irreversible and cannot be apologized away (a shipped item, a published verdict). Diagnostic: ask whether a rare divergence can be repaired after detection; if the bad outcome is correctable post hoc, prevention is overkill, but if it is irreversible, no apology pathway substitutes for forbidding the interleaving in the first place.

T4 — Stated Contract versus Real Propagation Delay (measurement). The model is a contract over permitted orderings, but it presumes a staleness budget that the physical substrate must actually honor. The failure mode is a contract that assumes a propagation bound the network cannot guarantee — designing against "eventually consistent within seconds" when partitions stretch it to minutes, so the budget silently exceeds reality. Diagnostic: ask whether the assumed maximum staleness is enforced or merely hoped for; a consistency model is only as good as the delay bound it rests on, and an unmeasured propagation tail turns a tolerable divergence into an unbounded one.

T5 — Latent Small-Scale Assumption versus Scale-Exposed Failure (temporal/scalar). The naive "everyone sees everything immediately" holds silently at small scale and breaks silently at large scale, because concurrency and delay are negligible until they are not. The failure mode is shipping a system whose implicit model was never stated, so the contract surfaces only as a production incident once replica count and load cross a threshold. Diagnostic: ask whether the system has a written consistency model at all; if the guarantee is implicit, it is almost certainly the strongest-imaginable one assumed for free, and that assumption is a time bomb that detonates at scale, not a design.

T6 — Engineered Frame versus Analogical Substrate (frame-honesty). The vocabulary is CS-native; transfer to registries, organizations, and scholarly records is by analogy, and the analogy can mislead. The failure mode is importing a precise distributed-systems guarantee into a human substrate where no mechanism enforces the ordering — assuming a "linearizable" registry truth when jurisdictional offices have no consensus protocol, only legal convention about which view binds. Diagnostic: ask what actually enforces the claimed ordering in the non-computing substrate; if the enforcement is a norm or a court rather than a protocol, the borrowed model names a goal, not a guarantee, and reasoning as if it were mechanically held will over-trust the contract.

Structural–Framed Character

Consistency Model sits just on the structural side of the middle of the structural–framed spectrum, consistent with its mixed-structural label and mid-range aggregate. The skeleton is genuinely substrate-free — a shared object, divergent observers, an operation history, and an ordering constraint on the permitted observation sequences — but a computer-science framing rides along on four of the five diagnostics, each registering a half rather than a full mark.

The home vocabulary partly travels: linearizability, sequential consistency, snapshot isolation, and "staleness budget" are distributed-systems terms of art, and when the pattern shows up in a land registry, a multi-site organization, or the scholarly record, the entry is candid that the transfer is largely analogical — the registry has no consensus protocol, only legal convention, so a domain re-tells the move in its own words rather than importing the CS lexicon intact. The origin is an engineered discipline (distributed systems), a mild institutional flavor rather than a purely formal pedigree. It is partly human-practice-bound: the named models and the whole apparatus presume engineered systems with designers choosing guarantees, and the strongest non-computing instances still lean on human institutions (courts, audit functions) to enforce the ordering. And invoking it partly imports a frame — bringing the engineered "what guarantee, for whom, at what cost" perspective — rather than purely recognizing a pattern already there. Only evaluative weight reads a clean zero: a consistency model carries no inherent approval, being merely a stronger-or-weaker contract whose appropriateness depends on what the operation's correctness can tolerate. The relational core (observers, a history, a permitted-orderings constraint) is real and does the cross-substrate work, which is why the grade lands mixed-structural; but the engineered vocabulary and the practice-boundedness are heavy enough to keep it off the pure-structural floor, exactly as the entry's own tension T6 (engineered frame versus analogical substrate) concedes.

Substrate Independence

Consistency Model is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. The skeleton is genuinely relational and substrate-free: a shared object referenced by many observers, an operation history of concurrent reads and writes, and an ordering constraint selecting which observation sequences each observer may legally witness. That inter-observer contract recurs wherever a state is shared across parties separated by propagation delay — replicated databases, file systems and caches in distributed computing; multi-jurisdictional title and tax registries in law; branch offices acting on locally cached corporate truth in organizations; preprints, errata, and retractions in the scholarly record; and the published memory models of CPUs and GPUs. What pins it to the middle is that the vocabulary is unmistakably engineered — linearizability, sequential consistency, snapshot isolation, "staleness budget" are distributed-systems terms of art — and the transfer outside computing is largely by analogy rather than mechanical instantiation: a land registry has no consensus protocol, only legal convention about which view binds, so the borrowed model names a goal rather than an enforced guarantee. The pattern presupposes engineered systems with designers choosing guarantees, or human institutions (courts, audit functions) standing in for protocols. The breadth is real and the structural move (tier the guarantee per operation, budget the staleness, compensate rather than prevent) does carry, but the CS-native framing and the analogical-not-mechanical transfer hold all three components, and the composite, at a moderate 3.

  • Composite substrate independence — 3 / 5
  • Domain breadth — 3 / 5
  • Structural abstraction — 3 / 5
  • Transfer evidence — 3 / 5

Relationships to Other Primes

One-hop neighborhood: parents above, mutual partners to the right, children below.Consistency Modelcomposition: ConcurrencyConcurrency

Parents (1) — more general patterns this builds on

  • Consistency Model presupposes Concurrency

    The file: 'Concurrency is the CONDITION — multiple operations in flight; a consistency model is the CONTRACT specifying which observations of that concurrency are legal. Concurrency creates the problem the model governs.' It presupposes concurrency. The 0.85 embedding-nearest is concurrency.

Path to root: Consistency Model → Concurrency

Neighborhood in Abstraction Space

Consistency Model sits among the more crowded primes in the catalog (6th percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.

Family — Formal Methods & Idealized Models (31 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-06-14

Not to Be Confused With

The consistency model is most often confused with concurrency, its nearest embedding-neighbor, and the confusion is a category error worth naming precisely. Concurrency is a condition of the world: multiple operations are in flight at once, on the same shared state, without a globally-agreed order. A consistency model is a contract about that condition: given the concurrency, which observation sequences across observers are legal? Concurrency is what creates the space of conceivable interleavings; the consistency model is the chosen restriction of that space to the permitted ones. The two are related as a problem to a stipulated answer — there can be concurrency with no stated consistency model (the implicit "everyone sees everything immediately" assumption that breaks at scale), and a consistency model is meaningless without concurrency to constrain. A practitioner who treats them as one thing will either think that having concurrency control "is" a consistency model (it is a mechanism, not a contract) or think that naming a model removes the concurrency (it only bounds what the concurrency may produce). Keeping the problem and the answer separate is what lets the designer ask the real question — how much divergence can each operation tolerate — rather than treating the mere presence of concurrency as the whole story.

A closely related but distinct neighbor is coordination, because strong consistency models are purchased with coordination and the two are easy to run together. The distinction is between a specification and the machinery that satisfies it. A consistency model says what observations are legal; coordination (consensus protocols, locking, two-phase commit, synchronization barriers) is how a system actually forbids the illegal ones. The strength-versus-cost trade-off that defines the consistency model is precisely the statement that stronger contracts demand more coordination, but the contract is logically prior to and separable from its enforcement: the same linearizability contract can be enforced by different coordination mechanisms, and a coordination mechanism is chosen because of the model one has committed to, not the other way around. Conflating them leads to reasoning about cost in terms of mechanism ("we use Raft, therefore we are consistent") rather than in terms of the contract the mechanism is meant to deliver, which obscures whether the guarantee actually matches what each operation's correctness needs.

Finally, the consistency model must be separated from the purely logical prime consistency, with which it shares a word but little else. Logical consistency is a static property of a commitment set: that no contradiction is jointly derivable from a body of rules under a combination rule. A consistency model is a dynamic property of a system of observers: which orderings of reads and writes over shared state, evolving in time under propagation delay, each observer may witness. One is about a rule-set not contradicting itself; the other is about distributed views of mutable state not violating an agreed observation contract. The Core Idea's emphasis that the model "does not say what the state is" but which interleavings are legal is exactly what marks the difference — logical consistency cares about the content of commitments, the consistency model cares about the ordering of observations regardless of content. A reader who imports the logical notion will look for a contradiction to eliminate when the real question is a staleness budget and a permitted-orderings constraint.

For a practitioner the cluster sorts by asking what kind of object is in hand. Is it a condition (concurrency), a contract (consistency model), a mechanism (coordination), or a static rule-set property (logical consistency)? Each lives at a different layer, and the recurring design failure is to answer a contract question with a mechanism, or to assume the strongest contract for free because the concurrency was never made explicit. The discipline the model teaches — write the contract, tier it per operation, budget the staleness — is exactly what is lost when these layers are collapsed.

Solution Archetypes

No catalogued solution archetypes reference this prime yet.