Start a Conversation
Puppeteer Architecture

An architecture organized around causality, not only state.

Puppeteer is a distributed-systems substrate built around software subjects with identity, authority and durable histories of their own. It preserves a domain as a continuous program of actions, consequences and manifestations.

State still exists. Infrastructure still exists. The difference is where continuity is defined.

In continuous production since 2018 · an ongoing research series.

State-centered
Action→Resulting state→Read state→Continue
Causality-centered
Action→Meaning→Consequence→Manifestation→Preserved history→Continue the domain
The Causal Program

State tells you what is true.
The journal tells you how it became true.

The causal program preserves what happened, why it mattered, and what may still need to happen.

  1. ActSomething is done in the domain.
  2. JournalWhat happened, and what it meant.
  3. ConsequenceWhat has to follow from it.
  • NowWhat the participant sees immediately.
  • DeferredWhat stays open without losing its cause.
  • Replay · ContinueThe same history, enacted again or carried forward.

An entry is not a record of a change. It is the reason for one.

  2. Currently viewingEntry 01 · Participant joined
    Cause
    A participant entered the shared domain.
    Now
    Presence acknowledged; the roster updates.
    Deferred
    Eligibility for the next distribution.
    May follow
    Open a boundary · assign a role.
  6. →Current domain condition
Step through it — The clerk

The journal keeps the narrative where the domain happened, instead of reconstructing it later from unrelated traces.

Paper 0A, §3.2The assembled verb
The Puppet

From actor to subject.

A Puppet is a software subject with identity, authority and a durable history of its own.

Identity persistsHistory accumulatesPuppet

Where it runs

  • process
  • host
  • node
  • cluster
  • network
  • runtime

What it is

  • identity
  • authority
  • voice
  • verbs
  • roles
  • durable history
  1. ActorAn independent unit of execution.
  2. EnactAn admitted exercise becomes an act in the Puppet's own history.
  3. Durable historyActs are persisted so the subject can be reconstructed.
  4. SubjectThe Puppet to which this history belongs.

Infrastructure determines where it runs. Its history determines who it is.

Not every request becomes history.

A Puppet records an exercise as one of its acts only after it crosses its admission frontier. Refused exercises leave no act; once admitted, the act remains in history whether execution succeeds or fails.

Before the frontier

After the frontier

  • Refused 0 acts
  • Admitted → execution fails 1 act
  • Admitted → execution achieves 1 act
request exercise frontier act history
Attention

Attention is not memory.

A journal cannot, by itself, remember to act because something did not happen — that is what attention adds. remember is how a subject arranges its own return to a concern still open.

Memory preserves what happened. Attention preserves what still matters.

STILL OPEN. LOOKED AT AGAIN.
Distributed systems

Built to exist in distributed systems.

Puppeteer is built so populations of independent subjects can execute concurrently, persist their acts and be reconstructed across changes in process, host and topology.

  • Actor Modelhelps to read independent, concurrent execution.
  • CQRShelps to read the separation of intent from reads.
  • Event Sourcinghelps to read history as a source of reconstruction.
  • Puppeteeruses enacted acts to constitute a subject's durable history.

History is not only how state is rebuilt. It is part of who the Puppet is.

Actors give us concurrency. Puppeteer gives them subjecthood.

How nCubo engineers across topologies
Identity precedes staging

One play. Many stages.

The production can change. The domain should not have to.

A screen is one staging of the domain, not the domain itself.
Acting and observing are architectural roles, not properties of a particular screen.

One domain, labelled ONE PLAY, connected downward to four stages — console, browser, network and three-peer — each serving a different client in a different role: human actor, human audience, observer audience, AI actor. The staging changes while the domain remains the same: different stages, different clients, different roles, same domain.
This visual shows four representative stage families; the two web transports measured separately in the paper are grouped into the Browser Stage. Open full size
Published evidence · Paper 09
1
domain
5
measured stagings
6
clients
0
domain edits
Read Paper 09Step through it — Topology is a drawing
Authority

Authority has a location.

Puppeteer keeps cause, meaning, observability and destination under explicit authority.

  1. DOMAINWhat may exist
  2. ACTORWhat becomes observable
  3. ASSEMBLERWhere observation occurs
Paper 08, §4, Table 1Inference without authority
Two identical machines side by side. Each contains a cashier and a bookkeeper, and in each machine it is the bookkeeper — not the cashier standing beside it — who is labelled the only one who writes. The same component in the same place does not carry the same authority.
Layers divide code. Authorities divide decisions.Location does not grant authority. Architecture does.Open full size

Observation is governed too: producing a consequence and deciding where it appears are different responsibilities.

Assembler can stage it toDatabase · Topic · Screen · File · Console · None

Step through it — The bookkeeper
Continuity

Meaning must survive replay, delay and changing environments.

Not uptime, and not failover. Continuity here is architectural.

Continuity preservescausalityidentityauthoritypending consequence

Organized as two integrity families.

Causal integrity requires authority integrity.

The Continuity Contract

Causal Integrity

Causality · Identity
  • Interpretable actions
  • Preserved history
  • Attributable consequences

Authority Integrity

Authority · Pending consequence
  • Legitimate observables
  • Explicit bindings
  • Authorized destinations
Familiar primitives

Familiar primitives. A different architectural center.

  • Actor ModelIsolate concurrent executionDoes the process that runs it decide who it is?
  • Event SourcingPreserves what happenedWho authors the observable account?
  • Ports & adaptersInvert dependenciesDoes the domain still ask the outside world to complete it?

The primitives are familiar. The authority contract is different.

The question is who is actually in a position to make the decision.

Research

The architecture was isolated, tested and extended through research.

Not only proposed. Each paper examines one architectural property on its own.

Selected papers from an ongoing series
  1. 02ProgramIdentityWhat makes a running unit remain itself?
  2. 04ParticipantsContinuityWhat must hold when one cause reaches many actors?
  3. 05JournalCausalityWhat must be preserved for behavior to continue?
  4. 08AuthorityAuthorityWho is entitled to decide what becomes observable?
  5. 09StagingIdentityWhat remains itself when stage, client and deployment change?
Explore the full research series

Research isolated the architectural properties. Engineering turned them into an executable asset.

The Asset

From architectural proposition to executable asset.

  1. Research
  2. Specification
  3. Compilation
  4. Manifestation
  5. Validation

No step replaces the one before it. The result is not only an implementation — it is a reusable architectural asset.

Open questions

The architecture is still unfolding.

The research documents not only its propositions, but the conditions under which they must still be tested.

  • 01External side effects
  • 02Authority across trust boundaries
  • 03Long-running deferred consequences
  • 04Scale and partition boundaries

The experience is simple. The architecture is not.

Inspect the ResearchInspect the CodeStart a Technical Conversation
Ask it of your own stack: Why It Is There