Skip to content

Inconsistent Shared Model

Version
v3 · 2026-08-30 · History
Prime #
914
Origin domain
Systems Thinking & Cybernetics
Subdomain
distributed state and coordination → Systems Thinking & Cybernetics

Core Idea

An inconsistent shared model is the pattern in which two or more subsystems hold mutually incompatible models of the same external state. Each model is internally consistent and defensibly derived; the inference channels never cross, so the inconsistency is structurally invisible until a forcing event requires both models to ground one joint action — at which point the cost lands all at once.

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.

Broad Use

  • Distributed computing: split-brain failures (two leaders after a partition) and divergent replicas under eventual consistency.
  • Sensor fusion: a vehicle's lidar and camera disagree about an object; aviation's disagreeing airspeed or attitude sensors.
  • Multi-database systems: a warehouse and an operational store report different numbers until a regulator forces reconciliation.
  • Organizations: sales-and-operations disconnect discovered only at a quarterly shortfall; pre-crisis intelligence-sharing failures.
  • Cognitive science: bilateral hemispheric disconnect, each hemisphere internally consistent until a motor command needs both.
  • Public health: epidemiology and clinical-care models with different transmission parameters, surfacing at policy formulation.

Clarity

Separates one subsystem is wrong (an epistemic gap) and different objectives (a value clash) from the symmetric case where both hold defensible models and only forced comparison reveals the divergence.

Manages Complexity

Collapses the \(N(N-1)/2\) pairwise disagreements into three system-level rates — each model's update frequency, the coupling rate, and the forcing-event distribution — so exposure can be reasoned about without inspecting any model's contents.

Abstract Reasoning

Lets a proposed architecture be ranked by inconsistency exposure before it is built, and recognizes that the danger is not the inconsistency itself but the forcing event that requires reconciliation under time pressure.

Knowledge Transfer

  • Distributed databases: anti-entropy between replicas is the same move as scheduled deconfliction calls between intelligence agencies.
  • Clinical informatics: a master allergy list plus admission reconciliation plus a divergence warning mirrors single-source-of-truth and observability moves from distributed systems.
  • Reconciliation protocols: vector clocks, two-phase commit, and CRDTs map onto quarterly sales-and-operations meetings.

Example

A hospital network running three EHR systems holds three internally-consistent allergy lists on uncoupled channels; the inconsistency is invisible until a prescription — the forcing event — requires the joint model, and the contraindicated drug is ordered.

Relationships to Other Abstractions

Local relationship map for Inconsistent Shared ModelParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.InconsistentShared ModelPRIMEPrime abstraction: Representation — is part ofRepresentationPRIMEDomain-specific abstraction: S&OP Disconnect — is a kind ofS&OP DisconnectDOMAIN

Current abstraction Inconsistent Shared Model Prime

Parents (1) — more general patterns this builds on

  • Inconsistent Shared Model is part of Representation Prime

    Inconsistent Shared Model contains two or more representations of one referent whose individually coherent contents cannot jointly be true.

Children (1) — more specific cases that build on this

  • S&OP Disconnect Domain-specific is a kind of Inconsistent Shared Model

    S&OP Disconnect is the multi-function operations-planning instance of subsystems persisting with incompatible models of one shared external state.

Hierarchy path (1) — routes to 1 parentless root

Not to Be Confused With

  • Inconsistent Shared Model is not Information Asymmetry because asymmetry is the case where one party simply knows more (fixed by transferring information), whereas this is the symmetric case where neither subsystem is more informed and the remedy is a comparison channel.
  • Inconsistent Shared Model is not Coordination because coordination is the achievement of aligned joint action (and consensus protocols are its machinery), whereas this is the prior pathology those mechanisms exist to address — the state where no comparison is happening at all.
  • Inconsistent Shared Model is not Confounding because confounding is a spurious association from an unmeasured common cause inside a single inference, whereas this involves multiple defensible inferences over different data that disagree about a shared referent.