Skip to main content

Causal Propagation Network

Events need adjudication; facts need propagation.

The Causal Layer is a metaphor for time, and events are its smallest unit.

In this loop, events are input, facts are output, and propagation turns output into the next round of input. By running this cycle repeatedly, the Causal Layer turns the unordered changes of the outside world into a traceable and explainable history inside the system.

Events and Facts​

An event is a requested change that the world has not yet accepted. It may come from external input or from internal propagation within the Causal Layer.

A fact is a relational change that has been formally admitted into history after adjudication.

The difference between them is crucial:

  • Events may conflict, be invalid, or be discarded.
  • Once a fact is established, it is not rewritten in place; later changes enter history as new facts.

This means the Causal Layer does not maintain "current state"; it maintains a continuously growing historical chain. State is just the projection of that chain at the present moment.

State model:      Causal model:
hp = 100         damage_taken
hp = 80          hp_depleted
hp = 0           entity_dead

See also Causal Layer

Adjudication and Propagation​

The Causal Layer runs on two kinds of rules:

  • Adjudication rules: decide whether an event can become a fact. From the application-layer perspective, an adjudication rule is a computation rule:

    (event, history) => Fact | null

    It has two internal steps:

    • Qualification check: does the event satisfy the preconditions?
    • Fact generation: produce the factual content from the input.

  • Propagation rules: decide which new events a fact produces, advancing the next cycle.

Adjudication rules are essentially stateless pure functions. Given an event and the current fact history, they output a new fact or a rejection. When events arrive, whether they are concurrent, or whether they conflict is not their concern.

From the perspective of time, the Causal Layer does not recognize "simultaneity." Events that appear concurrent are arranged into a sequence by the ordering mechanism before adjudication; the rule sees one input after another, never concurrency. This resonates with the functional-programming worldview: no true simultaneity, only mappings from input to output.

Locks, CAS, and similar concurrency primitives were born from the von Neumann shared-memory model: multiple execution streams read and write the same memory concurrently, so mechanisms are needed to protect that memory from corruption. From the causal perspective, competition and ordering are handled by the system ordering mechanism. These concurrency primitives are unnecessary at the application layer and should not be exposed there.

Engineering detail

Levels at which the ordering mechanism can be implemented:

  • Von Neumann architecture level: redesign hardware to natively support event ordering; ideally lock-free.
  • Language / runtime level: single-threaded event loops are naturally lock-free; multi-threaded runtimes may still need locks internally.
  • Distributed level: global order is reached through message queues and consensus protocols.

The application layer is lock-free; whether the lower layer is lock-free depends on the implementation. This event-driven structure resembles the Actor model, but Actor rules are scattered across individual actors, whereas dual-world theory emphasizes a unified fact history and eventual causal consistency.

Take an attack in a game:

Player presses attack key
        ↓
attack_requested (event)
        ↓
Adjudication rule (computation rule):
  ├── Qualification check: target in range? skill off cooldown? enemy dodge check?
  └── Fact generation: attack × buff − defense = damage
        ↓
damage_applied (fact)
        ↓
Propagation: death_check_requested (event)
        ↓
Adjudication rule (computation rule):
  ├── Qualification check: hp < 0? immune to fatal damage? can resurrect?
  └── Fact generation: determine death fact and derived values
        ↓
entity_dead (fact)
        ↓
Propagation: deathrattle, QTE, loot drop, quest update, experience gain, level-up, plot trigger (new events)

Adjudication and propagation:

Adjudication collapses uncertainty into facts; propagation lets facts reopen uncertainty.

Engineering Contract​

LayerResponsibilityImplemented by
Business-rule layerComputation rules, propagation rules, perception layerBusiness developers
Causal runtime layerAtomic ordering mechanism, rule schedulingFramework / middleware

Causal Propagation Network​

Without time, the world is just a static graph of relations; with time, static structure becomes a causal propagation network.

The causal propagation network is the core data model of the Causal Layer. It can be seen as a causal graph that continuously generates change, handling six basic topologies:

note

The ordering mechanism guarantees the order in which events enter the network, but it is not itself a network topology. Competition and ordering are handled by the ordering mechanism and should not be treated as questions of how changes connect and flow.

Six Basic Topologies​

1. Branching

One fact affects multiple future events:

    Fact
   /  |  \
  v   v   v
 A     B     C

2. Merging

Multiple facts jointly produce a new change:

Fact A      Fact B
   \          /
    v        v
      Event C

3. Feedback Loop

Propagation influences itself:

A → B → C
↑       |
└───────┘

4. Preemption

A new event interrupts an ongoing chain:

A → B → C
    ↑
    X  (new event interrupts B→C)

5. Delay

The effect of a fact occurs in the future:

Order created
    |
30 minutes
    ↓
Order timeout

6. Computation

Multiple inputs jointly produce one fact through a deterministic rule. A computation rule itself is timeless, concurrent-free, and conflict-free; it only cares whether the result is correct:

Event A     Event B     Fact D
   \           /          /
    v         v          /
      [Computation rule] ←──────
         |
         v
       Fact C

Topology-to-Engineering Mapping​

Causal ComplexityEngineering ManifestationTypical Techniques
BranchingOne change affects many modulesEvent bus, pub-sub, Observer, message queues
MergingMultiple conditions jointly determine behaviorState machines, rule engines, CEP, workflow
Feedback loopChanges keep influencing each otherFeedback control, transaction boundaries, iteration limits, resource bounds
DelayA change takes effect laterTimer, scheduler, job queue, cron, timeout
PreemptionNew events interrupt old processesInterrupts, cancellation tokens, rollback, state-machine switching
ComputationMultiple inputs produce one fact through deterministic rulesPure functions, formula systems, type-safe rule engines, deterministic state machines

Objects, states, and modules are merely spatial containers of propagation paths. The seemingly unrelated fields of software engineering—concurrency, distributed systems, transactions, interrupts, timeouts, feedback control—are all manifestations of the same causal propagation network under different constraints.

Core Properties​

For the Causal Layer to operate reliably, it must have four properties:

Capacity for Adjudication: Conflicts cannot remain unresolved forever; the system must produce a clear factual version.

Determinism: The same historical facts, events, and rules must yield the same result.

Traceability: Every fact can be traced back through a complete causal chain, not isolated as Enemy.dead = true.

Convergence: Any causal propagation within a finite scope must end in finite time.

Convergence is the most important; the others exist mainly to guarantee it. It is the fundamental assurance that the world can run stably. See Eventual Causal Consistency.

Summary​

The Causal Layer is the only channel through which world facts are formed. Through the loop of Event → Adjudication → Fact → Propagation, it turns continuous change into stable, explainable, and traceable history.