An architecture organized around causality, not only state.
Puppeteer 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 production since 2018 · an ongoing research series.
Behavior and value do not have to be the same thing.
A value describes a condition. An operation describes how that condition came to exist and what it means within the domain. Puppeteer explores what becomes possible when the operational program stays durable and replayable, independent from any one manifestation of its values.
- Value set A→Manifestation A
- Value set B→Manifestation B
- Replayed later→Manifestation C
One program. Multiple valid manifestations.
One domain. Many stagings.
A deployment is one staging of a domain — not the domain itself. Puppeteer keeps the dependency one-directional: every staging is built against the domain, while the domain references none of them.
The staging changes. The domain does not.
The journal preserves what happened — and why it still matters.
A Puppeteer journal is not only a historical log. It is an ordered causal program: a sequence of domain operations whose meaning can be interpreted, replayed and continued. Select an entry to inspect it.
- →Current domain condition
- Cause
- A participant entered the shared domain.
- Affected members
- The participant and the shared roster.
- Immediate consequences
- Presence acknowledged; the roster updates.
- Deferred consequences
- Eligibility for the next distribution.
- Permitted next operations
- Open a boundary · assign a role.
- Resulting manifestations
- Mobile welcome · shared roster display.
The architectural question is not whether an event can be saved. It is whether its domain meaning remains executable and continuous.
Replay is not only recovery. It is a way to continue meaning.
The same causal program can be replayed to produce more than one valid view — without losing its identity.
- replay at t1→Mobile manifestation
- replay at t2→Shared display
- replay at t3→Audit view
- replay at t4→Reconstructed world
Reconstruction
Rebuild a current manifestation from the causal program.
Observation
Inspect how one condition emerged from earlier operations.
Alternative manifestation
Use the same causal history to produce a different valid representation.
An audience can only see a play already performed.
A command response belongs to the actor performing the action. An audience — spectators, remote participants and passive observers — must read what has already been recorded. The journal is therefore not only a recovery mechanism: it is the performed account through which an audience observes the domain.
- Audience
- Observer
- Remote client
Keep the identity together, and the narrative stays together.
When one domain keeps its identity in one place, its account can be read where it happened. When that identity is scattered across independent services and stores, the narrative must be reconstructed from traces, correlation identifiers and external observations.
Not that distributed tracing is unnecessary — it changes where the narrative lives, not whether it is needed.
Not every consequence belongs to now.
Some effects must be visible immediately. Others must remain unresolved without becoming lost, detached from their cause, or mistaken for failure.
- Immediate response
- Visible local consequence
- Shared condition update
- Preserved causal obligation
- Resolution condition
- Future manifestation
Offline is not a sync feature. It is evidence that a consequence keeps its identity across time — replay, after a delay.
One cause can belong to more than one participant.
A participant may initiate an action locally while its consequences alter another participant, a shared environment or a future condition. Puppeteer preserves the relationship between those experiences without requiring every client to receive the same manifestation.
- Participant A receives an acknowledgement
- Participant B receives a new available action
- Participant C sees an environmental change
- The shared display advances the collective condition
Shared continuity does not require identical screens.
The domain is not the screen — and no screen is the privileged view.
And the projection is not its destination.
The domain emits facts. A terminal grid, a browser canvas and an automated player's numerical model are different adapters over the same material. The human-facing rendering may feel primary, but the architecture grants it no special status.
- Terminal renderer→Human grid
- Browser adapter→Canvas
- AI adapter→Column-height vector
- Observer adapter→Passive view
One fact. Multiple legitimate readings.
Familiar primitives. A different architectural center.
Puppeteer may use familiar architectural patterns. Its distinction is not the primitive itself, but where causality, continuity and decision authority are defined.
Dependency inversion relocates the dependency. Puppeteer asks whether the domain needs that dependency at all.
The primitives are familiar. The contract between them is not.
Puppeteer keeps cause, meaning, observability and destination under explicit authority.
Causal integrity requires authority integrity.
Causal Integrity
The system preserves why each condition exists.
- Interpretable actions
- Preserved history
- Attributable consequences
Authority Integrity
Each decision is made by the part that can actually know it.
- Valid manifestations
- Legitimate observables
- External bindings
Identity Integrity
The domain references no staging.
- A new staging requires no domain edit
- A new client adds an adapter, not a behavior
- Every staging descends from one identity
From proposition to executable system.
Research defines the proposition. Specifications make it explicit. Compilation makes it executable. Manifestation makes it perceptible. Validation tests whether the meaning survived.
Each layer creates a different kind of reusable asset.
A cumulative architectural argument, still unfolding.
Each paper advances the argument — from how behavior is defined toward where system complexity moves. The series is a work in progress, and continues to grow.
- 01OperationsHow behavior is defined
- 02Program–value separabilityHow behavior stays independent from one value set
- 03Now & deferred consequencesHow consequences resolve across time
- 04Cross-participant consequenceHow one cause reaches many actors
- 05The journal as substrateHow history becomes executable and replayable
- 06Infrastructure implicationsWhere system complexity moves
- 07After the substrateWhat the datacenter stops being required for
- 08Inference without authorityNEW · PAPER 08Who defines what exists, what becomes observable and where it appears
- 09Identity precedes stagingDRAFT · PAPER 09What remains the same when an output is staged for another place or audience
- ··The argument continuesFurther papers are in progress
- Central question
- Who has the standing to decide each part of an output?
- Contribution
- Separates the domain, the actor and the assembler as three authorities.
- Architectural implication
- The producer of an observable should not also be required to know its destination.
- Evidence
- Running laboratories demonstrate the separation is buildable — existence proofs, not cost or performance evaluations.
- Related
- Actor speech & tell · The journal as substrate · Infrastructural symptom
What remains unresolved matters too.
Puppeteer is a developing architectural program. The research documents not only its propositions, but the conditions under which they must be tested.
- 01Semantic versioning of historical programs
- 02Determinism across manifestations
- 03External side effects
- 04Authorization of causal operations
- 05Observation and journal governance
- 06Scale and partition boundaries
- 07Long-running deferred consequences
- 08Compatibility across domain evolution
- 09Authority across trust boundaries
- 10Governance of destination bindings
- 11Whether complexity is removed or relocated
The experience is simple. The architecture is not.
If you are evaluating architectures for continuous, shared or multi-participant systems, inspect how Puppeteer preserves causality, separates authority and keeps meaning continuous across time and manifestations.
Review the open questions