Skip to content

Inconsistent Shared Model

Prime #
914
Origin domain
Systems Thinking
Subdomain
distributed state and coordination → Systems Thinking

Core Idea

An inconsistent shared model is the pattern in which two or more subsystems persist with mutually incompatible models of a shared external state. Each subsystem's model is internally consistent and was derived from a defensible inference process over the data that subsystem had access to. The inconsistency is detected only when a downstream consumer tries to act on both models at once, at which point one or both models must be revised under time pressure, or the action proceeds in a fragmented way that exposes the inconsistency to the world. It is structurally distinct from information asymmetry (one party simply knows more), from disagreement (parties hold different evaluative opinions), and from belief revision (a single agent updating): it is the specific case where two or more subsystems represent the same external state differently, each believes its representation is ground truth, neither has the information that would force a reconciliation, and a downstream layer relies on their joint output.

Three commitments fix the shape. First, a shared referent: there must be a single external state both subsystems model, not two related-but-distinct states. Second, persistent inconsistent representations: each subsystem's model survives unchallenged because the subsystems do not directly compare notes — their channels of inference do not cross. Third, a forcing event: a downstream consumer (a coordinated action, a joint output, a customer touch-point, a regulator request) requires both models to ground its decision, and the inconsistency becomes load-bearing at that moment. Without the forcing event the inconsistency would remain invisible; with it, the cost lands all at once and under time pressure. The decisive feature is structural invisibility before the forcing event: the inconsistency exists but cannot be observed without explicit reconciliation machinery, so a system can be exposed even when every subsystem is working correctly.

How would you explain it like I'm…

Two Different Maps

Two friends are each drawing a map of the same playground, but in separate rooms, and they never compare. Each map looks perfect to the friend who drew it. The trouble only shows up when someone tries to use *both* maps at once to find the swings — and the maps say different things! Until that moment, nobody even knew there was a problem.

Both Sure, Both Different

An inconsistent shared model is when two parts of a system each hold a different picture of the SAME thing in the world, and each part is sure its picture is the true one. Each picture was built sensibly from the information that part had, so neither is being silly. The problem stays hidden because the two parts never directly compare notes. It only blows up when something downstream tries to use BOTH pictures at once — like sending one bill and one shipment that don't match — and suddenly the disagreement matters, all at once, under pressure. The scary part is that every single part can be working correctly and the system still gets exposed.

Hidden Until It Collides

An inconsistent shared model is the pattern where two or more subsystems persist with mutually incompatible models of the SAME external state, each internally consistent and each derived from a defensible inference over the data that subsystem could see. It is not information asymmetry (one side simply knowing more), not disagreement (different opinions), and not belief revision (one agent updating) — it is specifically two subsystems representing the same referent differently, each believing its own version is ground truth, with neither holding the information that would force reconciliation. Three things fix its shape: a shared referent (one external state both model), persistent inconsistent representations (the models survive because the subsystems never directly compare notes), and a forcing event (a downstream consumer that needs BOTH models to ground a decision). Before the forcing event the inconsistency is structurally invisible — it exists but can't be seen without explicit reconciliation machinery. So the cost lands all at once and under time pressure, and a system can be exposed even when every subsystem is working correctly.

 

An inconsistent shared model is the pattern in which two or more subsystems persist with mutually incompatible models of a shared external state. Each subsystem's model is internally consistent and was derived from a defensible inference process over the data that subsystem had access to. The inconsistency is detected only when a downstream consumer tries to act on both models at once, at which point one or both must be revised under time pressure, or the action proceeds in a fragmented way that exposes the inconsistency to the world. It is structurally distinct from information asymmetry (one party simply knows more), from disagreement (parties hold different evaluative opinions), and from belief revision (a single agent updating): it is the specific case where two or more subsystems represent the SAME external state differently, each believes its representation is ground truth, neither has the information that would force a reconciliation, and a downstream layer relies on their joint output. Three commitments fix the shape. First, a shared referent: there must be a single external state both subsystems model, not two related-but-distinct states. Second, persistent inconsistent representations: each model survives unchallenged because the subsystems do not directly compare notes — their channels of inference do not cross. Third, a forcing event: a downstream consumer (a coordinated action, a joint output, a customer touch-point, a regulator request) requires both models to ground its decision, and the inconsistency becomes load-bearing at that moment. Without the forcing event the inconsistency would remain invisible; with it, the cost lands all at once and under time pressure. The decisive feature is structural invisibility before the forcing event: the inconsistency exists but cannot be observed without explicit reconciliation machinery, so a system can be exposed even when every subsystem is working correctly.

Structural Signature

the single shared referentthe two-or-more internally-consistent subsystem modelsthe uncoupled inference channelsthe structural invisibility before comparisonthe forcing event requiring joint actionthe symmetry invariant (neither subsystem more informed overall)

A configuration is an inconsistent shared model when each of the following holds:

  • A single shared referent. There is one external state that two or more subsystems each model — not two related-but-distinct states. The referent's singularity is what makes the divergence a genuine inconsistency rather than mere difference.
  • Multiple internally-consistent subsystem models. Each subsystem holds a model that is internally coherent and was produced by a defensible inference over the data that subsystem had. No subsystem is malfunctioning.
  • Uncoupled inference channels. The subsystems do not directly compare notes; their channels of inference do not cross, so each model survives unchallenged.
  • Structural invisibility before comparison. The inconsistency exists but cannot be observed without explicit reconciliation machinery. A system can be exposed even when every subsystem inspected individually is working correctly.
  • A forcing event. A downstream consumer requires both models to ground a single joint action, output, or decision, at which point the inconsistency becomes load-bearing — typically all at once and under time pressure.
  • A symmetry invariant. Neither subsystem is more informed overall; both have defensible models from their own data. This distinguishes the pattern from information asymmetry and rules out "give one party the missing data" as the fix.

These components reduce to three system-level rates — each model's update frequency, the coupling rate between models, and the forcing-event distribution — so inconsistency exposure can be reasoned about and intervened on without enumerating individual disagreements.

What It Is Not

  • Not information_asymmetry. Asymmetry is the case where one party knows more; this prime is the symmetric case where neither subsystem is more informed overall, each holds a defensible model from its own data, and "give one party the missing data" is not the fix.
  • Not coordination. Coordination is the achievement of aligned joint action; this prime is the pre-design or design-failure state in which the subsystems cannot align because no channel surfaces the inconsistency before the forcing event. Consistency protocols and consensus are the engineered responses, not this.
  • Not a consensus_problem. A consensus problem assumes the parties are actively trying to agree on a value; here the subsystems are not even comparing notes — the inconsistency is structurally invisible until joint action forces it.
  • Not confounding. Confounding is a spurious association from an unmeasured common cause in a single inference. This is multiple subsystems each running a defensible inference over different data, with no shared inference at all.
  • Not value disagreement or conflict. The subsystems are not pursuing different objectives (a value clash); they model the same external state differently, each believing its representation is ground truth. Reconciling values will not fix a model inconsistency.
  • Common misclassification. Diagnosing the pathology as a knowledge gap and pouring data into one side. The remedy is a comparison channel between symmetric models, not a data transfer; "just inform them" is aimed at the wrong structure.

Broad Use

The same shared-referent, uncoupled-channels, forcing-event skeleton recurs across substrates that share no mechanism. In distributed computing, split-brain failures (two leaders each authoritative after a partition) and eventual-consistency anomalies (two replicas reading and writing divergent values until reconciliation) are exactly this pattern, and the CAP-theorem trade-off characterises how a system handles it when a partition heals. In sensor fusion, a vehicle's lidar and camera disagree about an object's presence, position, or class, and the planner must act under the disagreement; aviation experiences the same on disagreeing airspeed or attitude sensors, with several catastrophic accidents traced to an inconsistent shared model plus a crew unable to resolve it under time pressure. In multi-database systems, a data warehouse and an operational store report different numbers for the same business question until a regulator or board forces reconciliation. In organisations, sales-and-operations disconnect (incompatible demand forecasts discovered only at a quarterly shortfall) and pre-crisis intelligence-sharing failures (each agency holding a defensible threat model from its own collection, the joint model never existing until the forcing event) instantiate it. The pattern extends to cognitive science (bilateral hemispheric disconnect, each hemisphere internally consistent until a motor command needs both), public health (epidemiology and clinical-care models with measurably different transmission parameters, surfacing only at policy formulation), multi-team software engineering (backend and frontend holding divergent models of a shared API contract until deployment forces joint execution, a Conway's-law inevitability), diplomacy (two allied nations modelling a third country's intentions), and regulation (two regulators with differing models of the same activity until a cross-agency action forces both to ground the same case). In every case the vocabulary travels unchanged.

Clarity

The prime clarifies by separating three failure modes that collapse together when one has only the language of "they disagreed." One subsystem is wrong is an epistemic failure that the right data would fix. The subsystems have different objectives is a value conflict that data will not fix. The subsystems hold inconsistent models of the same state under no pressure to compare is a structural pathology that only forced comparison reveals — and it is its own thing, distinct from the other two. Naming it makes the upstream condition inspectable: do the subsystems share a channel that would surface inconsistency before the forcing event? If not, the system is structurally exposed even when every subsystem is working correctly, and that exposure is invisible to any inspection that examines the subsystems one at a time.

The clarifying force is sharpest at the boundaries with neighbouring patterns, which the prime distinguishes precisely. It is not information asymmetry, where one party knows more; it is the symmetric case, in which both parties have defensible models from their own data and neither is more informed overall. It is not the underdetermination-from-below of multiple equally good models of the same data; it is persistent inconsistency from above — different subsystems with different data, each producing a defensible model, with no channel to compare. It is not paradigm incommensurability, where vocabularies cannot align; the prime presupposes the subsystems share enough vocabulary to be comparable in principle, and lack only the channel to perform the comparison. And it is the pathology that consistency models, eventual consistency, and consensus protocols are the engineered responses to — the pre-design or design-failure state, not the contract or protocol that prevents or resolves it. Holding these apart keeps the prime from being mistaken for a knowledge gap, a value clash, or a solved coordination problem.

Manages Complexity

In a system with \(N\) subsystems each modelling a shared state, the combinatorial space of possible inconsistencies is the \(N(N-1)/2\) pairwise disagreements. The prime collapses this to three operational quantities: the update frequency of each subsystem's model, the coupling rate between subsystems (how often their models touch), and the forcing-event distribution (how often joint action is required). Inconsistency risk is a function of update frequency divided by coupling rate, evaluated at the forcing-event scale, and a designer can intervene on any of the three — slow updates, increase coupling, batch forcing events — without enumerating individual inconsistencies. The intractable inspection of every pairwise model comparison becomes a tractable reasoning over a handful of system-level rates.

The compression is operational because it lets the analyst reason about the structural exposure of a system independent of the content of any particular disagreement. Two systems can be compared by their inconsistency-exposure profile — how many subsystems hold models of how many shared referents with what coupling — without examining the contents of any model, and a proposed architecture can be evaluated by predicting its exposure before it is built. The same exposure calculation applies to a distributed database, an aviation cockpit, a multinational coalition, and a multi-team software organisation, because the variables are substrate-neutral. The prime thereby converts a problem that appears to require modelling every subsystem's beliefs into one that requires only counting subsystems, referents, and coupling, and reasoning about three rates — a decisive reduction in what the designer must hold in mind.

Abstract Reasoning

The prime supports reasoning about a system's structural exposure independent of the content of any disagreement. The reasoner asks: how many subsystems model how many shared referents? How often does each subsystem's model update, and how often do the models touch? How often does a forcing event require joint action grounded in multiple models? Because these questions reference only the abstract roles — shared referent, internally consistent subsystem models, uncoupled inference channels, forcing event — they apply to a distributed database, a cockpit, a coalition, or a software organisation without translation, and a proposed architecture can be evaluated by predicting its inconsistency-exposure before it is built.

Several reusable moves follow. The exposure-profile move treats inconsistency risk as a function of update frequency over coupling rate at the forcing-event scale, so the reasoner can rank architectures by exposure without inspecting any model's content. The forcing-event move recognises that the danger is not the inconsistency itself but the moment joint action requires reconciliation under time pressure, which directs design attention to making comparison happen before that moment rather than at it. The symmetry move distinguishes this pattern from information asymmetry by noting that neither subsystem is more informed overall, which rules out "give one party the missing data" as a fix and points instead to building a comparison channel. And the fail-safe move recognises that some forcing events will arrive before reconciliation, so the system needs a pre-declared behaviour for that case — defer, escalate, pick the conservative model, or refuse and log — rather than an improvised one. The same reasoning that tells a distributed-systems engineer to add anti-entropy between replicas tells an intelligence officer to schedule deconfliction calls between agencies, because both are reasoning about coupling rate against forcing-event scale.

Knowledge Transfer

The transferable content is a family of constant-shape interventions that practitioners in unrelated domains recognise as instances of one another. Establishing a single source of truth for the shared referent — master-data management, primary-source designation, leader election, authoritative-system designation — removes the symmetric ambiguity by fiat. Scheduling explicit reconciliation cadences ensures the forcing event is not the first comparison: sales-and-operations meetings, per-frame sensor-fusion checks, daily standups, and anti-entropy in distributed databases are the same move. Introducing a reconciliation protocol the subsystems run voluntarily and recurrently — two-phase commit, vector clocks, consensus protocols, fact-check meetings, sensor-fusion arbiters with explicit uncertainty, CRDTs — is the same move again. Making inconsistency observable before the forcing event — dashboards showing model divergence, alarms on cross-system metric drift, cross-team review of shared assumptions, intelligence-community deconfliction — converts a hidden exposure into a watched signal. And designing fail-safe behaviour for the forcing event itself gives the system a pre-declared response rather than an improvisation.

The transfer is deep because these interventions are not analogies but instances of one structural toolkit applied to one structural problem: a vector-clock reconciliation and a quarterly sales-and-operations meeting are doing the same work. A regional hospital network running three coexisting electronic-health-record systems makes the mapping concrete. Each system maintains its own model of every patient's allergy list, populated by the clinicians who use it; a patient has an allergy recorded at one hospital, presents at another whose record shows none, and is prescribed the contraindicated drug. The three models were each internally consistent, each derived from a defensible inference (the clinician recorded what they were told), none was challenged because the systems did not exchange notes, and the inconsistency was structurally invisible until the forcing event — a prescription requiring the joint allergy model — made it load-bearing. The matched interventions are the substrate-independent toolkit: designate a master allergy list (single source of truth), reconcile at each admission (cadence), run a bridge service that pushes updates across systems (protocol), show a divergence warning when the local list differs from the network reference (observability), and require explicit override when the systems disagree on prescription (fail-safe). Because the toolkit is substrate-neutral, a clinician designing this safeguard and a distributed-systems engineer designing anti-entropy are applying the same five moves to the same structural pathology, and a practitioner who has internalised it in one domain can specify the safeguard for another on first contact.

Examples

Formal/abstract

A distributed key-value store under network partition is the pattern in its cleanest engineered form. The single shared referent is the current value of one key — say an account balance. Two replicas, A and B, each hold a model of that value. Before the partition both agree; then the network splits them into two sides that can still each take client writes. The uncoupled inference channel is now literal: the replication link between A and B is severed, so each continues to apply writes and update its own internally consistent model with no way to compare against the other. A accepts a deposit and reads balance 150; B accepts a withdrawal and reads balance 70; neither is malfunctioning, and the symmetry invariant holds exactly — neither replica is more informed, each has a defensible model from the writes it saw. The inconsistency is structurally invisible during the partition: any inspection of A alone, or B alone, shows a coherent system. The forcing event is the partition healing, at which point a client read or a reconciliation pass requires a single authoritative value and the two models must be merged under time pressure. The CAP-theorem trade-off is precisely the menu of pre-declared responses: refuse writes during partition to preserve consistency (CP), or accept divergence and reconcile afterward via vector clocks or a CRDT merge function (AP). The engineered toolkit maps one-to-one onto the prime's interventions — leader election (single source of truth), anti-entropy gossip (reconciliation cadence), vector clocks (reconciliation protocol), divergence metrics (observability), and a declared conflict-resolution rule (fail-safe).

Mapped back: The key's value is the shared referent, the two replicas are the internally-consistent subsystem models, the severed link is the uncoupled channel, partition-heal is the forcing event, and the CAP choice plus vector-clock merge are the reconciliation protocol and fail-safe — inconsistent shared model with the machinery made explicit.

Applied/industry

A regional hospital network running three coexisting electronic-health-record systems instantiates the identical structure in a substrate with no replication link at all. The shared referent is a single patient's allergy list. Each EHR maintains its own internally consistent model of it, populated by the clinicians who use that system; the uncoupled channels are the three vendors' databases that do not exchange notes. A patient has a penicillin allergy recorded at Hospital 1, presents at Hospital 2 whose record shows none, and is prescribed the contraindicated drug. Each model was defensibly derived — the clinician recorded what they were told — and the symmetry invariant holds: no system is "more right," each simply saw different encounters. The inconsistency is structurally invisible until the forcing event, a prescription decision that requires the joint allergy model and makes the divergence load-bearing all at once, under time pressure, with a patient in front of the prescriber. A second instance is intelligence-sharing before a coordinated threat: two agencies each hold a defensible threat model from their own collection, the channels never cross, and the joint model does not exist until an operational decision forces it. In both the matched five-move toolkit applies identically: designate a master list (single source of truth), reconcile at each admission or via scheduled deconfliction (cadence), run a bridge service or liaison that pushes updates across systems (protocol), surface a divergence warning when the local record differs from the network reference (observability), and require explicit override when systems disagree (fail-safe). A clinician designing the allergy safeguard and an intelligence officer designing deconfliction are running one playbook.

Mapped back: The allergy list and the threat picture are shared referents; the three EHRs and the two agencies are internally-consistent subsystems on uncoupled channels; the prescription and the operation are forcing events that make the hidden inconsistency load-bearing — the same prime in clinical informatics and intelligence coordination.

Structural Tensions

T1 — Invisible Latency versus Forcing-Event Onset (temporal). The inconsistency accrues silently while channels stay uncoupled, then becomes load-bearing all at once when a forcing event demands joint action — the cost is deferred and then concentrated under time pressure. The characteristic failure is reasoning from quiet operation to safety: every subsystem inspected alone looks correct, so the system is judged healthy right up to the moment reconciliation is forced and there is no slack to perform it. The diagnostic is to ask when the next forcing event will require both models, and whether comparison has happened since the last update — not whether anything is currently visibly wrong.

T2 — Symmetric Divergence versus Information Asymmetry (sign/direction). The pattern is symmetric — neither subsystem is more informed overall, each holds a defensible model from its own data — which is exactly what rules out the asymmetry fix of giving one party the missing data. The failure is misdiagnosing the pathology as a knowledge gap and pouring data into one side, leaving the other side's equally-defensible model untouched and the inconsistency intact. The diagnostic is to ask whether either subsystem is actually better-informed overall; if neither is, the remedy is a comparison channel, not a data transfer, and any "just inform them" fix is aimed at the wrong structure.

T3 — Update Frequency versus Coupling Rate (coupling). Exposure scales with how fast each model updates relative to how often the models touch; fast updates over slow coupling guarantee drift between comparisons. The failure is improving one subsystem's update cadence — making its model fresher and more authoritative-seeming — without raising the coupling rate, which widens divergence rather than narrowing it. The diagnostic is to measure update frequency against coupling rate at the forcing-event scale: a subsystem that updates daily but reconciles quarterly is structurally exposed, and speeding its updates alone makes the exposure worse, not better.

T4 — Reconcile-Before versus Fail-Safe-At the Event (boundary). Two distinct design regimes meet at the forcing event: prevent inconsistency by reconciling beforehand, or accept that some events arrive before reconciliation and pre-declare a safe behaviour for that case. The failure is investing entirely in prevention and leaving the boundary case improvised, so the first un-reconciled forcing event is handled ad hoc under pressure. The diagnostic is to ask what the system does when a forcing event precedes reconciliation: if the answer is "improvise," the fail-safe (defer, escalate, pick the conservative model, refuse-and-log) is missing, and prevention alone cannot cover the case it failed to catch.

T5 — Single Source of Truth versus Local Authority (scalar / local-global). Designating one authoritative model for the shared referent removes the symmetric ambiguity by fiat — but it overrides locally-derived models that each subsystem trusts and that may capture data the master lacks. The failure runs both ways: no master leaves the symmetric inconsistency unresolved, while an over-trusted master discards a local model that was right about its own encounters. The diagnostic is to check whether the master genuinely subsumes the local data or merely outranks it; a single source of truth that is missing what a local model saw converts an open inconsistency into a confidently-wrong consensus.

T6 — Shared Referent versus Distinct States (scopal). The pattern requires one external state that both subsystems model; if they are actually modelling two related-but-distinct states, the apparent inconsistency is mere difference and the reconciliation machinery is misapplied. The failure is forcing agreement between models of genuinely different referents — collapsing a legitimate distinction into a spurious conflict — or, conversely, treating one referent as two and tolerating a real inconsistency as benign difference. The diagnostic is to verify referent singularity first: do the subsystems point at the same external state? Only then is divergence an inconsistency to reconcile rather than a distinction to preserve.

Structural–Framed Character

Inconsistent shared model sits at the structural end of the structural–framed spectrum, consistent with its structural label and aggregate of 0.0. It is a bare multi-subsystem state-representation pattern — a single shared referent, two or more internally-consistent but mutually incompatible models held over uncoupled inference channels, structural invisibility until a forcing event requires joint action — and every diagnostic reads structural.

No home vocabulary travels with it: the same shape is recognised as split-brain state in distributed computing, disagreeing sensors in sensor fusion, divergent replicas in multi-database systems, departments with conflicting pictures in organizations, hemispheric dissociation in split-brain cognition, and clashing case counts in public health, each told in its own field's words with no imported lexicon (vocab_travels 0). It carries no inherent approval or disapproval — divergent models are neither good nor bad until a forcing event makes the inconsistency load-bearing; the prime is explicit that every subsystem can be working correctly (evaluative_weight 0). Its origin is formal, statable purely in terms of shared referents, representations, and uncoupled channels, with no appeal to human norms or institutions (institutional_origin 0). It runs indifferently across computational, biological, and organizational substrates — two databases or two brain hemispheres instantiate it identically, requiring no human practice to obtain (human_practice_bound 0). And invoking it merely recognises a divergence already latent in the subsystems rather than importing an interpretive frame; the forcing event reveals a structure that was already there (import_vs_recognize 0). On every criterion it reads structural, with no inherited frame beneath the multi-agent skeleton.

Substrate Independence

Inconsistent shared model is a highly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. Its domain breadth is broad and genuinely cross-kind: the shared-referent, uncoupled-channels, forcing-event skeleton recurs across distributed computing (split-brain failures, eventual-consistency anomalies, the CAP trade-off), sensor fusion (disagreeing lidar/camera or airspeed/attitude sensors), multi-database systems, organisations (sales-and-operations disconnect, pre-crisis intelligence-sharing failures), cognitive science (bilateral hemispheric disconnect), public health, multi-team software engineering (divergent API-contract models, a Conway's-law inevitability), diplomacy, and regulation — reaching into computational, biological, and organisational substrates alike. Its structural abstraction is high because the signature is stated purely in terms of a shared referent, multiple representations of it, and channels that stay uncoupled until a forcing event makes the divergence load-bearing — with no domain commitment, so two databases and two brain hemispheres instantiate it identically and every subsystem can be working correctly. Its transfer evidence is strong: the vocabulary travels essentially unchanged, and the same forcing-event diagnosis (the joint model never existed until the partition healed, the sensors disagreed, or the policy meeting forced reconciliation) carries cleanly across the substrates, several traced to documented catastrophic failures. What holds the composite at 4 rather than 5 is that the pattern's biological reach is a single analogue (the split-brain case) and the bulk of its weight sits in engineered and organisational substrates rather than spanning physics and pure formalism — broad and well-evidenced, but not quite the universal recognition of a top-band structural prime.

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

Neighborhood in Abstraction Space

Inconsistent Shared Model sits among the more crowded primes in the catalog (12th 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 most consequential confusion is with information_asymmetry, because both describe two parties whose views of the world differ. Information asymmetry is the case where one party simply knows more than the other — the seller knows the car's defects, the insured knows their own risk — and the entire structure of the pathology and its remedies turns on that imbalance: screening, signalling, and disclosure all work by transferring the missing information to the less-informed side. Inconsistent shared model is the symmetric case, and the symmetry is load-bearing. Neither subsystem is more informed overall; each holds an internally coherent model produced by a defensible inference over the data it had, and there is no "less-informed party" to top up. This is exactly what rules out the asymmetry fix. Pouring data into one side leaves the other side's equally-defensible model untouched and the inconsistency intact; the remedy is a comparison channel that lets the two models surface their divergence before the forcing event, not a data transfer. The discriminating question is whether either subsystem is actually better-informed overall: if yes, it is asymmetry (transfer the information); if neither is, it is this prime (build the channel), and a "just inform them" intervention is aimed at the wrong structure.

A second genuine confusion is with coordination and its engineered cousins (consensus protocols, consistency models). Coordination names the achievement of aligned joint action, and consistency models, two-phase commit, vector clocks, and consensus protocols are the machinery that produces or restores alignment when models touch. Inconsistent shared model is the prior, structural state these mechanisms exist to address — the pre-design or design-failure condition in which subsystems hold divergent models of one referent on uncoupled channels, with no comparison happening at all. The relationship is that this prime is the problem and coordination protocols are the solution; conflating them obscures that a system can be fully exposed to inconsistency precisely because it has not yet adopted any coordination mechanism, and that the exposure is invisible to inspection of the subsystems one at a time. Reading the situation as "a coordination problem" risks treating it as already-instrumented when the diagnostic finding is that the comparison channel does not yet exist.

A third confusion, in modelling and inference settings, is with confounding. Confounding is a property of a single inference: a spurious association arises because an unmeasured common cause influences both the variables under study, so one analyst's estimate is biased. Inconsistent shared model involves multiple subsystems, each of whose inferences is defensible and unbiased given its own data — there is no single flawed inference but two coherent ones over different data that happen to disagree about a shared referent. The structural objects differ entirely: confounding lives inside one causal model and is fixed by measuring or adjusting for the confounder, while inconsistent shared model lives across models and is fixed by coupling them. Treating a cross-model inconsistency as confounding sends the analyst hunting for a hidden common cause inside one model when the actual issue is the absence of a channel between two.

These distinctions matter because each points to a different lever: asymmetry calls for information transfer, coordination is the solution rather than the diagnosis, and confounding calls for adjustment within one model — whereas inconsistent shared model calls for a comparison channel and a pre-declared fail-safe for the forcing event, the moves that no single-model or one-sided framing makes visible.

Solution Archetypes

No catalogued solution archetypes reference this prime yet.