Identity Precedes Staging: one play, many stages
Description
A program's domain is usually written together with the code that deploys it, so a new place to run, or a new kind of client, means editing the domain. This paper reports one that was not. A game's rules — holding no input or output, naming no framework in its build graph — ran on five deployment configurations and were read by six clients, the last of them across three machines, at zero edits to the domain and zero test doubles in its own tests. A deployment is called a staging throughout, after theatre: one script, many productions.
The mechanisms that allow this are old and none is claimed. What is claimed is a property of the domain, measured against an orthodox ports-and-adapters version of the same game built for the comparison. That baseline matches the zero per staging. It decouples a domain where this arrangement closes one, on two independent measurements: the domain declares no obligation outward, where the baseline declares three driven ports — whence its stand-ins, its public surface, and the state it admits from outside — and its reconstitution needs no surface of its own, where the baseline grew one at 56 lines added and 5 removed. Calling those two closure, and reading the invariance as an identity prior to any staging, are readings and not further measurements. The paper is analytic in Gregor's (2006, Type I) sense, and offers a question to put to a system already built rather than a prescription. Two limits bound it: the domain is a pure computational core that causes no external effect, and its author commissioned the work.
Series information (English)
Paper 9 of the Puppeteer Papers, a series of self-deposited preprints on journaled, actor-native architecture. The series is cumulative: each paper relies on vocabulary and conditions established by its predecessors, and Paper 1 is the entry point.
This one rests on four of them. Paper 4 supplies the actor's speech and tell; Paper 3 supplies Reaction read as the recognition of a routine; Paper 7 read the server as an accidental category, ephemeral after bootstrap; and Paper 8 supplies testimony, whose observer receives an account it is told. Paper 8 noted, without pursuing it, that a narration received is not yet a narrative recognized — this paper takes up the recognition, and reaches it not as its subject but as a consequence of the identity it argues.
Where the earlier papers ask who may speak (Paper 4) and who may decide what an output is (Paper 8), this one asks a prior question: what is it that holds still while both change. Its answer is a property of the domain that can be measured on a built system, and the deployment is called a staging throughout, after theatre.
Technical info (English)
Reproducing the nine labs. The accompanying archive holds labs/paper09-* and data/paper09-*: the vendored example — a Tetris Well domain, its actor and twelve host projects — the nine labs, the ported hexagonal baseline of Lab F, and the captured output each lab's write-up cites. The archive is built from git's tracked file list rather than by compressing directories, so it carries no build output.
Requirements. .NET 9 SDK. One external dependency, and only one: the framework, cited against the public Puppeteer repository at commit 2673d57 (github.com/alvaroNCubo/puppeteer). Point $env:PuppeteerEngine at a checkout at or after that commit; if it is unset the build stops with that sentence rather than a path error. Lab B additionally needs a local container runtime. The labs' console commands assume PowerShell, with Git Bash for two shell scripts.
Two exceptions to self-containment. Lab A's claim is about a history and a copy has none: it reads the git chronology of github.com/alvaroNCubo/puppeteer-examples on main at ec9a2d4, and its output is captured under data/ for a reader who would rather not clone. Lab H reproduces one of its three stagings locally; the warm-server and in-container stagings are captured in data/paper09-labH-recognition/.
Verified at the pinned commit. Every lab was re-run there rather than carried forward from the draft: Lab A's chronology (domain last committed 2026-06-29, three stagings added 2026-07-23, empty domain diff across the fifteen commits between); Lab E's fence (no packages, the domain's 44 tests passing with the framework absent from its build graph); Lab F's ported baseline (64 tests); Lab G's equivalence (129 acts, 136 entries, 47,783 steps compared, 9,265 landings, 0 divergences); Lab H's recognizer (two placements, closing at entries 13 and 18); Lab B's three containers (converged at entry 20, three byte-identical journals and three byte-identical frames); and Lab I's growth (+98/−3 lines, the twelve hosts passing before and after at zero edits). All twenty-four source anchors the paper cites — nineteen in the artifact, five in the framework — were re-resolved at the deposited commit.
Files
09-identity-precedes-staging.md
Additional details
Software
- Repository URL
- https://github.com/alvaroNCubo/puppeteer
- Programming language
- C#
- Development Status
- Active