Imagine a distributed computer system (like a bank network, a social media feed, or a cloud database) not as a single machine, but as a galaxy of observers (computers, phones, or servers) exchanging messages.

This paper, "Light Cone Consistency," proposes a new way to understand how these systems stay in sync. It argues that every computer in the network only sees a tiny, growing slice of the universe—its own "light cone" of history. The rules for how that computer decides what is true depend entirely on what it has seen and how it orders those events.

Here is the breakdown of their ideas using everyday analogies.

1. The Two Main Rules: The Filter and The Sorter

The authors say every computer's consistency model is built from two simple tools:

The Filter (Causal Closure): Before a computer can act on a message, it must have seen certain "prerequisite" messages.
- Analogy: Imagine you are reading a book. The Filter decides if you are allowed to read Chapter 10.
  - Strict Filter: You must have read Chapters 1–9 first.
  - Loose Filter: You can read Chapter 10 even if you missed Chapter 5.
  - No Filter: You can read any chapter in any order.
The Sorter (Fork Resolution): Sometimes, two messages arrive at the same time (concurrently), and the computer doesn't know which happened first. The Sorter decides how to line them up.
- Analogy: Two people, Alice and Bob, send you letters at the exact same time. The Sorter decides: "I will read Alice's letter first, then Bob's," or "I will read them in the order they arrived," or "I will treat them as a jumbled pile."

The paper claims that most named consistency models (like "Causal Consistency" or "Sequential Consistency") are just different combinations of these two tools.

2. The Big Secret: The Sorter Needs the Filter

The most surprising finding is that these two tools are not independent. You cannot have a "fair" Sorter without a strong Filter.

The Rule: If your computer decides to put two messages in a specific order (e.g., "Alice's letter came before Bob's"), it must have seen the causal history that proves that order is true.
The Metaphor: Imagine a judge (the Sorter) declaring a verdict. The judge cannot declare "Alice is guilty before Bob" unless the judge has seen the evidence (the Filter) that links the two. If the judge throws away the evidence but still declares an order, they are creating a "scar" in the system—a lie that can never be fixed.
The "κ-Shortcut": Sometimes, a system uses a global clock to force an order. The paper says this is like the judge skipping the evidence and just guessing. It works until the clock is wrong, at which point the system breaks.

3. The "Consistency Ratchet" (You Can't Go Backwards)

The paper introduces a concept called the Consistency Ratchet.

The Analogy: Imagine you are translating a document.
- You start with a high-quality, detailed translation (Strong Consistency).
- You pass it to a friend who summarizes it into bullet points (Weaker Consistency).
- You then pass those bullet points to a machine that turns them back into a full document.
The Result: You cannot get the original detailed document back. The information lost in the summary is gone forever.
The Lesson: If you read data under a "loose" rule (where you didn't see all the history) and then write it back, you permanently lose the ability to claim the "strict" rules for that data. You can never "upgrade" a piece of data back to a stronger consistency level once it has been weakened.

4. The "Merge" Problem: When Two Views Clash

What happens when two computers have different views of the world and try to combine them?

The Analogy: Two historians are writing books about the same war.
- Historian A says: "Battle X happened, then Battle Y."
- Historian B says: "Battle Y happened, then Battle X."
The Rule: They can only merge their books if their timelines agree on the events they both know. If they disagree on the order of a shared event, they cannot merge into a single, true history without one of them admitting they were wrong.
The Trade-off: If a network splits (a "partition"), the system must choose:
- Availability: Let everyone keep writing, but accept that the two sides will have conflicting stories (they can't merge).
- Ordering: Stop writing until the sides can agree on a single story (lose availability).

5. The "Linearizability" Boundary: The Global Clock Myth

The paper makes a sharp distinction about Linearizability (the "gold standard" where everything looks like it happens in one perfect, real-time line).

The Claim: Linearizability is not something a single computer can figure out just by looking at its own history.
The Analogy: Imagine a race.
- Single Observer: A runner can only see who passed them and who they passed. They can't know who was faster in a different lane unless they talk to someone else.
- Linearizability: Requires a "God's eye view" or a "Global Referee" who stands outside the race and sees everyone at the exact same time.
The Conclusion: To get Linearizability, you need two systems working together:
1. The data store (the runners).
2. A global serializer (the Referee) that forces a single timeline on everyone.
- The paper argues that no single computer's "light cone" (its local view) can ever supply this global timeline on its own. It must be manufactured by an external authority.

Summary of Key Takeaways

Consistency is Local: Every computer only knows what it has seen.
Ordering Requires History: You can't decide an order unless you have the history to prove it.
Loss is Permanent: Once you weaken your rules to read data, you can never make that specific piece of data "strong" again.
Global Order is Expensive: Creating a single, perfect timeline for the whole world requires a separate, special system (a "Referee") that sits outside the normal flow of messages.

The paper doesn't tell us how to build a specific app, but it provides a map of the rules. It shows us exactly where the "walls" are in distributed systems: where we can cut corners, where we lose information forever, and why a perfect, real-time global view is impossible without a special, external mechanism.

Technical Summary: Light Cone Consistency (LCC)

Problem Statement

The paper addresses the fragmentation and lack of structural coherence in the landscape of distributed consistency models. While numerous named models exist (e.g., causal consistency, linearizability, eventual consistency), they are often treated as a "flat catalog" of independent parameters. This approach obscures the fundamental relationships between models, the precise conditions under which data is readable across configurations, and the inherent impossibility results that govern message-passing systems.

The authors posit that every distributed system is fundamentally a message-passing system, which can be modeled as a growing Causal Directed Acyclic Graph (DAG). The core problem is to formalize consistency not as a monolithic property, but as a set of operators acting on an observer's visible sub-DAG, thereby revealing the structural dependencies and boundaries that current taxonomies miss.

Methodology

The authors propose Light Cone Consistency (LCC), a framework that decomposes consistency into two primary operators acting on an observer's visible sub-DAG, plus a response function and a waiting policy:

Causal-Closure Filter ( $C$ ): A filter that determines which causal dependencies an observer must have seen before acting on a message.
- Examples: deps_none (no dependencies), deps_object (dependencies within an object), deps_session (dependencies within a session), deps_explicit (full causal closure).
Fork Resolution ( $O$ ): An operator that resolves concurrent messages (forks) within the sub-DAG admitted by $C$ $C$ into a total order.
- Examples: O_trivial (no ordering of forks), O_object (ordering within objects), O_all (global total order).
Response Function ( $F$ ): Composed of a waiting policy ( $R$ ) and a selection function ( $s$ ), determining when and what value an observer returns.

The framework relies on three axioms: Monotonic Visibility, Creator Visibility (read-your-writes is a tautology within an observer), and Observation-Induced Dependency (Lamport's happened-before encoded as DAG edges). The analysis assumes a crash/omission model without Byzantine faults or shared memory, focusing strictly on the causal structure and visibility predicates.

Key Contributions and Results

1. Asymmetric Coupling of Closure and Ordering

The paper establishes that $C$ and $O$ are not independent dials. A causally faithful ordering ( $O$ ) entails a specific causal closure ( $C$ ).

The $\kappa$ Map: If an ordering refines causality (is $\kappa$ -clean), it supplies the closure that the writer's filter ( $C$ ) may not have demanded. For instance, a global total order ( $O_{all}$ ) forces full causal closure ( $deps_{explicit}$ ) even if the writer only specified object-level closure.
Factoring Dichotomy: The readability order (which configuration can read data from another) factors into independent $C$ and $O$ components only when ordering does not refine causality. When ordering does refine causality, the axes couple: the order supplies the missing closure, creating "shortcuts" in the configuration space that a flat parameter space cannot isolate.

2. The Readability Order and Factoring Dichotomy

The authors define a decidable readability order ( $A \preceq B$ ), meaning data written under configuration $A$ can be honestly read under configuration $B$ .

The Result: Under causal arbitration, $A \preceq B$ if and only if $O_A \succeq O_B$ (stronger ordering) and the closure of $B$ is entailed by the effective closure of $A$ (which includes the closure supplied by $A$ 's ordering).
Implication: The 12 possible $(C, O)$ configurations collapse into 8 equivalence classes under this order. This reveals that certain named models are structurally identical in terms of what they can read, despite different naming conventions.

3. The Retention Bound (Impossibility Result)

The paper formalizes a "database folklore" result as an impossibility for all message-passing systems: Resolving a fork requires retaining the causal history that distinguishes its branches.

Theorem: If an observer discards the dependency metadata of a message that lies on the causal path between two concurrent messages, no algorithm can guarantee a resolution faithful to the causal order.
Significance: This is not a storage detail but a fundamental constraint on message-passing systems. To reunite divergent views, the system must have retained the distinguishing history; otherwise, the fork cannot be resolved without violating causality.

4. The Consistency Ratchet and $\kappa$ -Scars

Consistency Ratchet: A consistency level lost during a value migration (reading a value under a weaker configuration and re-writing it) is never regained. The provenance of the data is capped at the weakest hop in the pipeline.
Detection = Prevention: A system can only detect that its resolved order has inverted causality (a $\kappa$ -scar) if it retained the exact causal history that would have prevented the inversion. If a system relies on a shortcut (ordering without full causal retention), it cannot audit itself for causal violations later.

5. The Single-Observer Boundary and Linearizability

The paper's sharpest claim concerns Linearizability.

The Claim: Linearizability is not a single-observer consistency configuration. It is a composite of two systems: a data store and a global, real-time serializer.
Reasoning: A single observer's light cone cannot supply a global order for spacelike-separated (concurrent) operations. Establishing such an order requires a "preferred frame" (a global simultaneity) that must be manufactured at a distinguished point (e.g., via consensus or a sequencer).
Result: Linearizability steps outside the single-observer frame. It is the only standard model that requires an external, real-time synchronization mechanism not derivable from the observer's own sub-DAG.

6. Mergeability and the Partition Tradeoff

The paper defines when two divergent views (cuts) can be merged.

Result: Views merge if and only if their orders agree on all pairs they both order.
Partition Tradeoff: When views diverge (e.g., due to a network partition), a system cannot simultaneously maintain availability (answering queries) and a strong ordering ( $O_{all}$ ) if the orders disagree. The system must either decline to answer (lose availability) or weaken its ordering scope.

Significance and Claims

The authors position LCC not as a unification of all impossibility results, but as a formalization of the observer-relative consistency model (referencing Burgess and Gerlits) that places classical results into a single coordinate system.

Structural Insight: The paper claims to reveal the "structural slack" in consistency: ordering supplies closure. This coupling explains why certain models behave as they do and why "flat" parameter spaces fail to capture the dependencies between causality and ordering.
Predictive Power: The framework generates a configuration space (Table 1) that maps to named models but also predicts unnamed configurations (e.g., "per-object unread logs" or "bounded causal per-object order"), suggesting the design space is larger than currently explored.
Modest Scope: The authors explicitly state they do not claim to unify the classical impossibilities (like CAP or FLP) but rather to show that they share a presupposition: the existence of a preferred frame (global simultaneity) that no single observer's light cone can provide. LCC makes this assumption visible within the single-observer framework.

In summary, the paper argues that consistency is best understood as the interaction between what an observer must see (closure) and how it orders what it sees (fork resolution), with the critical insight that true global consistency (linearizability) requires stepping outside the observer's light cone entirely.

Light Cone Consistency: Closure, Ordering, and the Single-Observer Boundary