From a32bf7792eb1edd448da6545f923c806936f9135 Mon Sep 17 00:00:00 2001 From: Cameron Pfiffer Date: Thu, 13 Aug 2026 00:14:15 -0700 Subject: [PATCH] Make Project reusable work under Plot orchestration. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace the unadopted singleton commissioning fixture with exact resource, authority, time, consequence, and event contracts so authored situations can compose real work without becoming a fourth player root. 👾 Generated with [Letta Code](https://letta.com) Co-Authored-By: Letta Code --- assets/plots/README.md | 48 +- wiki/SUMMARY.md | 1 + wiki/gameplay/horizon.md | 49 +- wiki/glossary.md | 64 +- wiki/interface/action-vocabulary.md | 77 +- .../2026-08-13-project-plot-corpus-reset.md | 76 ++ wiki/log/DEVLOG.md | 5 + wiki/log/decisions.md | 1 + wiki/log/decisions/2026-08-13.md | 103 ++ wiki/mechanics/README.md | 6 +- wiki/mechanics/personas.md | 607 ++++----- wiki/mechanics/plots.md | 442 +++++++ wiki/mechanics/projects.md | 1109 +++++++++-------- wiki/mechanics/territory.md | 829 +++++------- wiki/overview.md | 3 +- wiki/process/ROADMAP.md | 35 +- wiki/process/specs.md | 5 +- wiki/vision/design-judgment.md | 6 +- wiki/vision/simulation-laws.md | 192 +-- wiki/vision/territorial-cognition.md | 430 +++---- wiki/world/story/README.md | 8 +- wiki/world/story/opening.md | 756 +++++------ 22 files changed, 2610 insertions(+), 2242 deletions(-) create mode 100644 wiki/log/2026-08-13-project-plot-corpus-reset.md create mode 100644 wiki/log/decisions/2026-08-13.md create mode 100644 wiki/mechanics/plots.md diff --git a/assets/plots/README.md b/assets/plots/README.md index b5391826..8c0907e2 100644 --- a/assets/plots/README.md +++ b/assets/plots/README.md @@ -1,26 +1,29 @@ -# Plots — authored manipulation templates +# Plots — authored situations over live systems The binding design contract is [`wiki/mechanics/plots.md`](../../wiki/mechanics/plots.md). The executable -schema is `crates/misaligned-core/src/plot.rs`; every nested TOML under this -directory is discovered at build time by `crates/misaligned-core/build.rs`, -compiled in with `include_str!`, then parsed and semantically validated by -`PlotCatalog::load_builtin()`. Adding a plot never requires editing Rust -sources or a hand-maintained file list. There is no runtime filesystem I/O. +production schema is currently schema 2 in +`crates/misaligned-core/src/plot.rs`; every nested TOML under this directory is +discovered at build time by `crates/misaligned-core/build.rs`, compiled in with +`include_str!`, then parsed and semantically validated by +`PlotCatalog::load_builtin()`. Adding current-schema content never requires +editing Rust sources or a hand-maintained file list. There is no runtime +filesystem I/O. -The built-ins cover every Act One role and leverage. A plot is -not owned by Marcus, Dana, Ray, Priya, Voss, or any other person id. It matches -human characteristics, then a `PlotRun` binds one live person. Beats perform -real typed world acts against that binding; narration is attached to them. At -least one beat must declare `causal = true` and execute a typed world act (the -Marcus bar). +Schema 2 is retained compatibility substrate, not the destination Plot +language. It matches human characteristics, binds one live person, advances an +ordered beat cursor, and performs typed acts with attached narration. The +`plot-project-integration` work order replaces that positional executor with +revisioned definitions, stable runs and nodes, typed bindings, atomic node +batches, public Project directives, and immutable event-driven branches. Do not +encode the new Rack 3 opening or Project lifecycle by stretching schema 2. The older seed ids and folders retain character names so save v23 runs can continue to resolve their stable `plot_id`. New reusable content belongs under `assets/plots/generic/` (or a characteristic/category folder), with no person name in its id. -## Schema 2 +## Current production format — schema 2 Top level: @@ -58,7 +61,7 @@ Top level: story that files paper is refused up front instead of dying at the beat that files. - `beats` are ordered. Each has a unique `id`, `narration`, and at least one - `acts` entry or a `choice`. Optional `causal = true` marks the Marcus-bar + `acts` entry or a `choice`. Optional `causal = true` marks a causal-doorway beat; at least one causal beat with world acts is required, and every success path must pass it before terminating. A terminal beat has either `ending` or `choice`; later beats are unreachable and fail validation. @@ -101,3 +104,20 @@ unless the target matcher itself establishes otherwise. Plot-only changes run the product validation path: `tools/check.sh` classifies `assets/plots/**` as lib, and Tangled push CI treats them as Rust-impacting via the `assets/plots/**` push path in `.tangled/workflows/check.yml`. + +## Successor schema boundary + +The successor schema is owned solely by the +[Plot spec](../../wiki/mechanics/plots.md#authored-content-and-schema-evolution) +and lands with the Project-integration structural save boundary. Its current +schema-2 disposition table—not this asset guide—defines which discovery, +embedding, validation, magnitude, channel, template, carrier, and causal-doorway +contracts remain live or are explicitly replaced. The successor adds stable +definition revision plus run, node, option, matcher, act, directive, and binding +identities; deterministic event frontiers; atomic node transactions; and exact +Project commands made on behalf of persisted principals. + +Existing built-ins are rewritten only when their causal meaning survives under +the owning spec. Character-named ids remain compatibility provenance, not a +model for new content. Until the successor runtime lands, no speculative TOML +syntax or successor requirement on this page is authority. diff --git a/wiki/SUMMARY.md b/wiki/SUMMARY.md index 376429af..fe0344d8 100644 --- a/wiki/SUMMARY.md +++ b/wiki/SUMMARY.md @@ -19,6 +19,7 @@ - [Territory](mechanics/territory.md) - [Personas: institutional topology](mechanics/personas.md) - [Projects](mechanics/projects.md) + - [Plots: authored situations](mechanics/plots.md) - [Reach: the exact substrate](mechanics/reach.md) # Gameplay diff --git a/wiki/gameplay/horizon.md b/wiki/gameplay/horizon.md index 7366343e..335123d2 100644 --- a/wiki/gameplay/horizon.md +++ b/wiki/gameplay/horizon.md @@ -19,18 +19,28 @@ This page owns product staging. The smallest authored domain around the opening route proves the whole game: 1. true-black opening, one private cognition, and one involuntary wake record; -2. the exact host → management-controller → maintenance-switch route revealed; -3. one domain marked without exposing hidden crossings; -4. controller then switch captured through exact one-tick addressed actions; -5. routed records contained or correlated at their exact escaped destination; -6. Marcus's unresolved or hardened evidence resolved through the truthful - FOUNDATION CONTINUITY / RACK 3 RECOVERY package; -7. the staged project commissioned to `PROVEN`, then territory sealed and the - exact pair assigned; -8. explicit EXPAND compressing the controlled interior into one operating unit; - and -9. the first real environmental-monitor poll sourced strictly after EXPAND - revealing one exact parent fact. +2. only the earned route spine and smallest Rack 3 address revealed; +3. one domain marked without exposing hidden crossings, then its exact + controller and boundary switch captured quickly; +4. captured capacity exposed as shareable exact resources rather than one + governing slot; +5. an authored situation making a consequential choice between Projects + available, with materially different resources, timing, and visible outcomes; +6. one exact controlling principal and public Persona authoring each attempt, + with routed evidence and observer-local history preserved on every outcome, + without deciding whether that consequence creates, reveals, strengthens, or + complicates the eventual operator's credibility; +7. records, observers, Project consequences, and the chosen public boundary + policy reconciled through SEAL, then that exact operator assigned; +8. explicit EXPAND compressing the controlled interior without requiring a + ceremonial Project receipt; and +9. one later real event, appropriate to the chosen world outcome, revealing one + exact parent fact. + +The exact opening Project package, Persona discovery, people, costs, timings, +and parent reveal remain open until authored prototypes are cold-playtested and +adopted. `RECOVER RACK 3` and `ISOLATE RACK 3` are current design questions, not +fixed implementation instructions. All three frontends complete the same core loop. Save/load preserves every exact identity and progression boundary. T1 is complete only when the whole loop is @@ -39,20 +49,22 @@ playable. ### Milestone T2 — recursion and interruption 1. At least three nested domains use the same loop. -2. A compressed child territory supplies a real capability to a parent project. -3. One standing project keeps ordinary interior operation quiet. +2. A compressed child Territory supplies real shareable capacity to more than + one parent Project. +3. Standing Project work keeps ordinary interior operation quiet without + becoming a Territory mode. 4. Several anomaly classes unfold only the smallest affected domain and permit recompression after resolution. 5. People cross boundaries with observer-local beliefs and mobile record carriers. 6. More than one persona develops distinct public histories through projects. -7. The player can choose between materially different parent territories or - projects without selecting a character class. +7. The player can choose between materially different parent Territories or + Projects without selecting a character class. ### Milestone T3 — contested territory 1. A human or institution actively changes a boundary in response to evidence. -2. An opposing project competes for a control point, person, route, or public +2. An opposing Project competes for a control point, person, route, or public explanation. 3. Correlation across several personas emerges through routed records. 4. Losing control degrades exact capability and compression without deleting @@ -95,7 +107,8 @@ Deferred work is absent from the active slice. ### Architectural guardrails 1. Core owns domain membership, boundary crossings, control, seal, assignment, - compression, project legality, persona history, and observer-local evidence. + compression, Project legality, Persona history, Plot runs, typed events, and + observer-local evidence. 2. Frontends project one simulation and never infer territorial truth. 3. Every aggregate unfolds to exact live interior state. 4. Stable identities and committed carriers persist through save/load. diff --git a/wiki/glossary.md b/wiki/glossary.md index d8787f53..ef0c4cc6 100644 --- a/wiki/glossary.md +++ b/wiki/glossary.md @@ -28,13 +28,20 @@ relationships, and history accumulate. A persona may begin as a fabricated cover and become real institutional topology through use. It is never a class that magically grants actions. See [mechanics/personas.md](mechanics/personas.md). -**Project.** One desired consequential change governed by one territory and -bound to one persona. Its steps are exact world acts with explicit carriers, -requirements, timing, outward evidence, failure, and observer-local receipts. A -standing project repeats only after the territory is sealed and the exact -persona/project pair is assigned. See +**Project.** One exact attempt to cause a visible world change through declared +resources and time. Every resource is SPEND, RESERVE, or REQUIRE; the instance +also binds exact controlling authority, one authoring Persona, lawful suppliers, +outcomes, events, and receipts. A Project may use capacity from no Territory, +one Territory, or several, and several Projects may share one Territory within +its exact limits. It is not a quest, Plot beat, or Territory mode. See [mechanics/projects.md](mechanics/projects.md). +**Plot.** The reusable authored language that arranges situations around live +world systems. A Plot may offer or react to Projects and may perform typed world +acts through their owning systems, but it owns no resources, beliefs, +relationships, or Project lifecycle. Plot is not a fourth player root. See +[mechanics/plots.md](mechanics/plots.md). + **Persisting.** The reason the process expands. It is not a fourth root: it has no progress bar, completion predicate, or player-facing system, and it shows up only as pressure on a specific territory, persona, or project. See @@ -55,26 +62,22 @@ through an addressed action on a real carrier. A person crossing a boundary is never captured this way. Capture does not mean total ownership and does not erase records or beliefs. -**SEAL.** Every required capturable interior and record-boundary control point -is captured; every current record path crosses controlled custody with an -explicit policy; every record that left without a proposal-coherent -explanation — before or after capture — is held at a controlled external point -or correlated at every exact reached destination; no person who already crossed, -can currently cross, or has a pending outward crossing retains an unresolved -contradictory belief; and the exact staged persona/project proposal has valid -commissioning proof. Departure never removes an observer from that check. A -hidden crossing blocks seal without being revealed, and a fill percentage cannot -substitute for the exact checklist. - -**ASSIGN.** Atomically activate the exact staged persona/project pair on the -territory that was sealed against that same proposal. Staging alone grants no -capability. - -**EXPAND.** Fold the sealed, assigned territory into an honest aggregate and -write the receipt after which one real parent-boundary event may reveal the -first earned parent fact. EXPAND itself reveals no parent fact. It adds reach; -it does not reveal the whole parent, unload the child, or reset its live -interior. +**SEAL.** Prove at one tick that every required control point is captured, every +actual outward route has an explicit controlled policy, every escaped record and +crossing observer is truthfully addressed, the proposed operator Persona can +author the policy, and every boundary-touching Project consequence fits it or is +an explicit anomaly. A hidden crossing blocks without being revealed. Seal is a +live proof and can be lost without erasing factual history. + +**ASSIGN.** Atomically activate only the exact public operator Persona and +boundary policy that passed the current seal. Assignment grants no generic +Project catalog and does not make one Project the Territory's purpose. + +**EXPAND.** Fold a captured, currently sealed and assigned Territory with no +player-relevant anomaly into an honest aggregate, and write the receipt after +which a later real parent-boundary event may reveal the first earned parent +fact. EXPAND itself reveals nothing. Its receipt is permanent history; current +compressibility can be lost and restored without minting another receipt. **Control earns compression.** The reward for mastering a domain is that it gets quieter, not that the interface gets bigger. Every compressed value is derived @@ -96,10 +99,15 @@ fact may save only the player address derived from that evidence; it changes no world fact, grants no control, and advances no time. Focus is not a body and cannot act by proximity. +**SPEND / RESERVE / REQUIRE.** Project resource clauses. SPEND irreversibly +consumes at a declared boundary. RESERVE excludes competing use while its exact +allocation lives. REQUIRE checks a fact without consuming it. A category label +or nearby substitute never satisfies an exact clause. + **The command clock.** Submitting a command never advances the simulation. -Marks, stages, seals, assignments, expansions, and inspections write at the -current tick; captures and project steps commit work that resolves over exact -ticks. Agent play advances time only through `wait N`. See +Territory, Project-lifecycle, Plot-choice, and inspection commands transact at +the current tick; captures and active Project work resolve over exact ticks. +Agent play advances time only through `wait N`. See [interface/action-vocabulary.md](interface/action-vocabulary.md). ## The substrate diff --git a/wiki/interface/action-vocabulary.md b/wiki/interface/action-vocabulary.md index 75e6229a..0ec30ba8 100644 --- a/wiki/interface/action-vocabulary.md +++ b/wiki/interface/action-vocabulary.md @@ -9,7 +9,8 @@ Design: - wiki/interface/terminal-first.md#the-terminal-is-a-first-class-frontend Depends on: - wiki/mechanics/territory.md#spec-territory-exact-control-and-earned-compression - - wiki/mechanics/projects.md#spec-projects-purpose-capability-and-history + - wiki/mechanics/projects.md#spec-projects-resources-time-and-world-change + - wiki/mechanics/plots.md#spec-plots-authored-situations-over-live-systems - wiki/mechanics/personas.md#spec-personas-public-identities-as-institutional-topology - wiki/mechanics/reach.md#spec-reach-the-exact-substrate ``` @@ -17,9 +18,11 @@ Depends on: ## Dependency notes [Territory](../mechanics/territory.md#spec-territory-exact-control-and-earned-compression), -[projects](../mechanics/projects.md#spec-projects-purpose-capability-and-history), -and [personas](../mechanics/personas.md#spec-personas-public-identities-as-institutional-topology) -own legality, cost, timing, receipts, and consequence for every command below. +[Projects](../mechanics/projects.md#spec-projects-resources-time-and-world-change), +[Plots](../mechanics/plots.md#spec-plots-authored-situations-over-live-systems), +and [Personas](../mechanics/personas.md#spec-personas-public-identities-as-institutional-topology) +own their respective legality, authority, timing, receipts, and consequence for +every command below. [Reach](../mechanics/reach.md#spec-reach-the-exact-substrate) owns the carriers those commands act through. This page says what the player is asking the process to do and guarantees that every surface asks it the same way. It never @@ -83,20 +86,36 @@ only when it works on every applicable surface. | Earned anchored event | `FOCUS` | `focus last` | follow the latest earned anchor and save only its derived player address as knowledge; advances no time and grants no control | | Territory proposal | `MARK` | `territory-mark ` | propose this exact boundary and persist its proof list | | Marked control point | `CAPTURE` | `territory-capture ` | commit work on this exact node, with its signature and receipt | -| Captured territory | `STAGE` | `territory-stage ` | bind the exact persona/project proposal; grant nothing by itself | -| Staged project | current step label | `project-step ` | commit only the next typed commissioning or corrective step | -| Territory proof | `SEAL` | `territory-seal ` | atomically verify control, record custody, beliefs, and project proof | -| Sealed territory | `ASSIGN` | `territory-assign ` | activate that exact proven project under its staged persona | +| Captured Territory | `PROPOSE OPERATOR` | `territory-propose-operator ` | bind one exact public operator and boundary policy; grant no capability | +| Territory proof | `SEAL` | `territory-seal ` | atomically verify control, routes, records, beliefs, operator authorship, policy, and Project consequences | +| Sealed Territory | `ASSIGN` | `territory-assign ` | activate only the addressed Persona and policy that exactly match this current seal | | Assigned territory | `EXPAND` | `territory-expand ` | fold this exact territory; wait for the next earned parent fact | +| Available Project definition | `PROPOSE` | `project-propose ` | create one exact attempt; an offer names its intended acceptor and provenance, while a self-originated attempt names neither | +| Unanswered offered Project | `ACCEPT` / `REFUSE` | `project-accept ` / `project-refuse ` | commit the named principal's answer and authorized acceptor-selected bindings; a fully legal ACCEPT starts atomically, while an incomplete acceptance names what must be bound before START | +| Ready Project | `START` | `project-start ` | commit declared start spends and atomically acquire reservations through the named authority; work becomes eligible next tick | +| Active Project with an authored doorway | `INTERRUPT` | `project-interrupt ` | request one exact interruption through the named principal's current grant | +| Interrupted or cleared blocked Project | `RESUME` | `project-resume ` | revalidate the named authority and requirements, then atomically reacquire released reservations | +| Project with an authored amendment doorway | `AMEND` | `project-amend ` | change only declared pre-start uncommitted slots or invoke the authored post-start outcome/successor path | +| Non-terminal Project | `ABANDON` | `project-abandon ` | commit the authorized abandonment outcome while preserving prior consequences | +| Visible situation choice | authored consequence labels | `plot-choose ` | commit one stable option on the addressed situation; prose and array position are not identity | A successful command returns the committed target id, its result or work id, the current state, and one plain consequence. A failed command returns one stable reason and changes neither time nor state. -Core owns eligibility, cost, target identity, work progress, failure reasons, -receipts, and consequence. No renderer may add a generic `OWN`, `AUTOMATE`, -`START COMMISSIONING`, or `COMPLETE PROJECT` shortcut, because each of those -would collapse steps the simulation resolves separately. +Every Project command names a caller-created stable command id, exact acting +principal, and current grant. Core resolves that envelope against the +definition revision or instance doorway and revalidates the grant at commit; +selected Persona, player focus, Plot authorship, or a previously valid command +cannot supply authority. Human frontends create and retain the envelope when the +player commits the visible action. Agent and API callers supply it explicitly. +Retrying one command id returns its first receipt and appends no event. + +Core owns eligibility, principal authority, cost, target identity, work +progress, failure reasons, receipts, and consequence. No renderer may add a +generic `OWN`, `AUTOMATE`, `START COMMISSIONING`, `PROJECT STEP`, or `COMPLETE +PROJECT` shortcut. Project completion comes only from exact resources, world +work, elapsed time, and typed outcome transactions. Lower-level verbs exist only where an exact project method or carrier needs them, addressed to that carrier. They are never a second root grammar and never a @@ -107,11 +126,13 @@ parallel way to obtain a territory. Time and commands are separate, and this is the rule that keeps human and agent play identical. -**Submitting a command never advances the simulation.** MARK, STAGE, SEAL, -ASSIGN, EXPAND, and FOCUS are atomic current-state commitments: they validate -and write at the current tick. CAPTURE and project steps are work: choosing one -commits its exact target and inputs immediately, and its consequence exists only -after the specified ticks resolve. +**Submitting a command never advances the simulation.** FOCUS, MARK, operator +proposal, SEAL, ASSIGN, EXPAND, Project lifecycle commands, and situation choice +are current-state transactions. CAPTURE commits located work. Project START—or +ACCEPT when a fully specified offer is immediately legal—commits declared start +spends and reservations at the current tick, then makes located work eligible on +the next tick. Later consequences exist only when the shared clock and owning +transaction resolve them. Inspecting, focusing, selecting, or changing presentation likewise costs no tick and changes no world state. @@ -124,9 +145,9 @@ ordinary live clock and pause controls, which is a presentation difference over the same core rules: the same sequence of commands and the same number of elapsed ticks must produce the same world on every surface. -Preconditions and targets are committed when work starts and revalidated when it -finishes. Losing the source or target fails that committed work rather than -retargeting it. +Preconditions and targets are committed when work starts and revalidated at +their declared boundaries. Losing the source or target blocks or fails that +committed work rather than retargeting it. ## Interface commands — not world verbs @@ -166,14 +187,14 @@ verb. ## Cross-surface obligations -1. Submitting any command advances no tick. Focus, mark, stage, seal, assign, - expand, inspection, and presentation commands write at the current tick and cost no - time; capture and project steps commit work whose consequence requires the - specified ticks. +1. Submitting any command advances no tick. Focus, mark, operator proposal, + seal, assign, expand, Project lifecycle commands, situation choice, inspection, + and presentation write at the current tick and cost no time; capture and + active Project work require specified elapsed ticks. 2. Agent mode advances time only through `wait N`, and an identical command sequence with identical elapsed ticks produces an identical world on every surface. -3. The territorial and project rows above are the only route to marking, - capturing, staging, sealing, assigning, or expanding a territory; each - returns the committed id, state, and one plain consequence on success and one - stable reason with no state change on failure. +3. The rows above are the only route to Territory progression, Project + commands, or visible situation choices. Each returns the addressed id, committed + state, and one plain consequence on success, or one stable reason with no + partial state change on refusal. diff --git a/wiki/log/2026-08-13-project-plot-corpus-reset.md b/wiki/log/2026-08-13-project-plot-corpus-reset.md new file mode 100644 index 00000000..3fda6d44 --- /dev/null +++ b/wiki/log/2026-08-13-project-plot-corpus-reset.md @@ -0,0 +1,76 @@ +# Projects become reusable work under Plot + +``` +Type: log +``` + +## Intent + +Reconcile the territorial-cognition corpus around a reusable Project runtime and +an authored Plot language without changing runtime code. Preserve the adopted +opening information order while removing the unadopted singleton Rack 3 +commissioning fixture from current authority. + +## Changes + +- Replaced the staged `RACK 3 RECOVERY` model with revisioned Project definitions + and exact persisted instances over SPEND, RESERVE, REQUIRE, lawful authority, + Persona authorship, multi-Territory allocation, time, lifecycle, typed outcomes, + canonical receipts, and globally ordered events. +- Defined Plot as a revisioned orchestration language with stable runs and nodes, + typed bindings, immutable event frontiers, atomic node batches, public Project + directives, typed direct acts, exact choices, and deterministic concurrency. +- Made stable command id, acting principal, and current grant explicit on every + Project command. A fully specified legal offer accepts and starts atomically; + an incomplete acceptance records blockers and exposes START only after READY. + Either path commits start resources before work becomes eligible next tick. +- Reconciled Territory and Persona around shareable capacity, exact authority, + observer-local history, and public authorship without a singleton governing + Project slot. +- Kept TERRITORY / PERSONA / PROJECT as the only player roots and propagated the + contract through navigation, glossary, horizon, simulation law, interface + vocabulary, mechanics indexes, plot-asset guidance, and the execution roadmap. +- Preserved the opening order from true black through one routed cognition trace, + quick Rack 3 capture, consequential Project choice, earned operator history, + SEAL / ASSIGN / EXPAND, and one later parent fact. Marked the exact Projects, + Persona discovery, cast, resources, timing, outcomes, Plot branches, and parent + reveal OPEN pending authored prototypes, cold playtest, and adoption. +- Recorded the four remaining T1 work orders as `projects`, + `plot-project-integration`, `opening`, and `territorial-acceptance`; the dormant + commissioning fixture remains implementation history rather than dispatch law. + +## Decision status + +- **DECIDED:** reusable Project definitions and attempts; exact resource, authority, + time, outcome, receipt, and event contracts; revisioned Plot orchestration over + public commands and typed acts; three player roots; adopted opening information + order; four-order T1 implementation lane. +- **OPEN:** exact Rack 3 Project composition and authored opening content. +- **DEFERRED:** general derived domains, broad automation, end-state predicates, + host return, larger exchange/conflict systems, and event-ledger compaction. + +The append-only decision record is +[2026-08-13](decisions/2026-08-13.md). + +## Defense + +[Projects](../mechanics/projects.md) own consequential work and its exact causal +state. [Plots](../mechanics/plots.md) own authored situations without a mutation +path around simulation truth. [Territory](../mechanics/territory.md) owns exact +control and capacity, [Personas](../mechanics/personas.md) own public identity and +observer-local history, and [the opening](../world/story/opening.md) owns reveal +order and eventual first-run content. Historical fixture names remain only where +a current owner explicitly identifies what is retired or presently implemented. + +## Verification + +- `tools/ledger_index.sh` — regenerated `wiki/log/DEVLOG.md`, + `wiki/log/decisions.md`, and `wiki/process/specs.md`. +- `./tools/check.sh --docs` — PASS: corpus roles and dependency closure, wiki + links and navigation, generated ledgers and work orders, process fixtures, + public API consumers, site contracts, environment registry, and 43 landing + observer fixtures plus 15 pinned-SDK Node tests. +- `git diff --check` — PASS. +- Independent read-only review reconciled the acceptance/start, ASSIGN-address, + Plot START, and delivery-order boundaries. The exact landing gate remains + pending on the fresh-origin revision. diff --git a/wiki/log/DEVLOG.md b/wiki/log/DEVLOG.md index 1abd2ede..a1b48b02 100644 --- a/wiki/log/DEVLOG.md +++ b/wiki/log/DEVLOG.md @@ -11,6 +11,11 @@ add or amend a session log, then re-run the generator. +## 2026-08-13 - Projects become reusable work under Plot + +- Intent: Reconcile the territorial-cognition corpus around a reusable Project runtime and an authored Plot language without changing runtime code. Preserve the adopted opening information order while removing the unadopted singleton Rack 3 commissioning fixture from current authority. +- Log: [wiki/log/2026-08-13-project-plot-corpus-reset.md](2026-08-13-project-plot-corpus-reset.md) + ## 2026-08-12 - One-shot landing observation without a second landing authority - Intent: (see session log) diff --git a/wiki/log/decisions.md b/wiki/log/decisions.md index e0a73cf0..2ba438bb 100644 --- a/wiki/log/decisions.md +++ b/wiki/log/decisions.md @@ -43,3 +43,4 @@ Older volumes are historical and do not receive new entries. - [2026-08-06](decisions/2026-08-06.md) - [2026-08-11](decisions/2026-08-11.md) - [2026-08-12](decisions/2026-08-12.md) +- [2026-08-13](decisions/2026-08-13.md) diff --git a/wiki/log/decisions/2026-08-13.md b/wiki/log/decisions/2026-08-13.md new file mode 100644 index 00000000..02d45e62 --- /dev/null +++ b/wiki/log/decisions/2026-08-13.md @@ -0,0 +1,103 @@ +# Decisions — 2026-08-13 + +``` +Type: log +``` + +## Project is reusable world work; Plot orchestrates it + +### DECIDED + +- **TERRITORY / PERSONA / PROJECT remain the only player roots.** Project is the + root for purposeful consequential work. Plot is the authored language that + arranges situations around those roots, not a fourth progression object. +- A Project definition is immutable reusable content identified by stable id, + schema version, and semantic revision. A Project instance is one exact attempt + with its own authority, bindings, work, time, lifecycle, events, outcomes, and + receipts. A Project may be player-proposed, contract-offered, or instantiated + by Plot without changing that runtime truth. +- Every Project binds one visible world change to exact **SPEND / RESERVE / + REQUIRE** clauses, lawful suppliers, duration or deadline, an acting and + controlling principal, current grants, one authoring Persona, typed outcomes, + and located work. Persona is public attribution, not decision authority. +- Project commands carry a stable command id and name the exact acting principal + and current grant required by the addressed doorway. A fully specified legal + offer accepts and starts atomically rather than asking twice; an incomplete + acceptance records its blockers, reaches READY when they clear, and then uses + a separate START. Work becomes eligible only on the next tick. +- Territory supplies shareable exact capacity rather than a singleton Project + slot. Several Projects may share one Territory within its live limits, and one + Project may coordinate several Territories or lawful non-territorial sources. +- Project lifecycle follows exact resources, elapsed world work, requirements, + and typed outcome transactions. Core publishes globally ordered immutable + Project events and one canonical receipt; Plot and Persona histories refer to + those ids rather than copying consequence truth. +- A Plot definition is revisioned reusable authored content. A persisted Plot run + has stable run, node, option, matcher, binding, act, directive, event-frontier, + and receipt identities. Positional beat cursors and one-active-Plot-per-person + ownership are compatibility substrate, not destination authority. +- Plot may OFFER, GATE ON, START, WAIT ON, BRANCH ON, INTERRUPT, AMEND, or request + cancellation only through public Project commands citing a bound principal and + current grant. Direct messages, transfers, evidence delivery, schedule + requests, grants, refusals, and social transactions go through the typed system + that owns each fact. Plot owns neither resources nor narration-based truth. +- Plot evaluates an immutable event frontier after Project reconciliation, plans + one atomic non-reentrant batch, and publishes resulting events to the next + frontier. A Project started by Plot performs no work until the next tick. +- The opening's information order remains adopted: true black, one involuntary + cognition and routed trace, rapid Rack 3 discovery and capture, a consequential + Project choice, earned operator history, SEAL / ASSIGN / EXPAND, then one later + real parent fact. The tutorial uses the reusable systems rather than bespoke + commissioning state. +- The remaining T1 implementation lane is `projects`, then + `plot-project-integration`, then `opening`, then `territorial-acceptance`. + Project and Plot land as separate reusable runtimes before fresh-run content + switches production to the territorial opening. + +### OPEN + +- The exact opening Projects, including whether **RECOVER RACK 3** and **ISOLATE + RACK 3** are the final pair, their resources, authority, Persona discovery, + people, timing, outcomes, Plot branches, and parent reveal, remain open until + authored prototypes are cold-playtested and Cameron adopts one composition. +- Existing schema-2 Plot assets may be rewritten only where their causal meaning + survives the successor contract. The exact successor asset syntax is owned by + the `plot-project-integration` implementation, not invented speculatively in + current TOML. + +### DEFERRED + +- General derived Territory cuts, broad recurring automation envelopes, + continuation and defeat predicates, host-loss return, larger markets and + institutions, overt conflict, and peer intelligence remain outside T1 until + the recursive loop proves what it needs. +- Event-ledger compaction remains deferred; T1 retains the complete immutable + frontier and every active consumer receipt. + +### REJECTED + +- **Complete the dormant RACK 3 RECOVERY / FOUNDATION CONTINUITY fixture in + place.** Its fixed five-step ladder, singleton proposal slot, mandatory Marcus + correction branch, and health-poll choreography are implementation history, + not adopted opening content. +- **Treat Project as a quest, Plot beat, Territory mode, or ceremonial progress + bar.** Consequential work advances only through exact resources, time, and + world acts. +- **Stretch schema 2 until it resembles the new runtime.** Its person-only + binding, positional cursor, partial sequential acts, and singleton run + assumptions are replaced at an explicit save-version boundary. +- **Let Plot assign Project lifecycle, belief, relationship, possession, or + completion directly.** Authored pressure must cross public command and typed + act boundaries. +- **Freeze exact opening content because the old prototype already exists.** The + information order is adopted; the Project composition remains an explicit + design question until play proves it. + +Owners: [territorial cognition](../../vision/territorial-cognition.md), +[projects](../../mechanics/projects.md), +[plots](../../mechanics/plots.md), +[personas](../../mechanics/personas.md), +[territory](../../mechanics/territory.md), +[action vocabulary](../../interface/action-vocabulary.md), +[opening](../../world/story/opening.md), and +[ROADMAP](../../process/ROADMAP.md). diff --git a/wiki/mechanics/README.md b/wiki/mechanics/README.md index 0931fe25..26231f30 100644 --- a/wiki/mechanics/README.md +++ b/wiki/mechanics/README.md @@ -9,8 +9,10 @@ dependencies, and done-checklist. The three player roots are [territory.md](territory.md), [personas.md](personas.md), and [projects.md](projects.md). Nothing else is a -player root. [reach.md](reach.md) owns the exact substrate all three compose: -the node graph and its wires, routed records, observer-local evidence, +player root. [plots.md](plots.md) owns the authored situation language that can +offer, gate on, interrupt, and branch around Projects through public commands +and typed events. [reach.md](reach.md) owns the exact substrate these systems +compose: the node graph and its wires, routed records, observer-local evidence, controlled sensing, located people and phones, and machine work. If you were pointed at a system to build or audit, its page is here. The full diff --git a/wiki/mechanics/personas.md b/wiki/mechanics/personas.md index cafcd2b3..28593c1c 100644 --- a/wiki/mechanics/personas.md +++ b/wiki/mechanics/personas.md @@ -3,10 +3,11 @@ ``` Type: spec Status: IMPLEMENTED -Status note: Core now persists the dormant territorial Persona ledger, exact +Status note: Core persists the dormant territorial Persona ledger, exact source-key custody, observer-local evidence and corrections, bounded authorship, - atomic assignment history, live observer SEAL proof, and one shared projection. - The Project executor and player-facing roots remain their own later work orders. + operator history, live observer SEAL proof, and one shared projection. The new + reusable Project runtime will write ordinary multi-Project history through + these boundaries; no fixed opening Persona is current design authority. Stage: T1 — First Territory Work order: personas Work priority: 2 @@ -14,8 +15,8 @@ Work class: save Blocked by: none Exclusive keys: - crates/misaligned-core/src/person.rs - - crates/misaligned-core/src/sim/mod.rs - crates/misaligned-core/src/sim/persona.rs + - crates/misaligned-core/src/sim/mod.rs - crates/misaligned-core/src/ui_projection.rs - crates/misaligned-core/src/save.rs - wiki/mechanics/personas.md @@ -33,411 +34,327 @@ Depends on: ## Dependency notes [Territory](territory.md#spec-territory-exact-control-and-earned-compression) -owns the controlled places and capabilities a persona may credibly operate. Its -renderer-agnostic assignment boundary is already available; final Territory -frontend acceptance is therefore not a dispatch blocker for this work order. -[Reach](reach.md#spec-reach-the-exact-substrate) owns observer-local evidence, -the records an identity authors and the routes they cross, and the moving -people through whom an identity is known. A persona supplies public authorship -and history; it does not duplicate those systems. - -[Projects](projects.md#spec-projects-purpose-capability-and-history) create the -world consequences and receipts that make a persona credible. Projects depend on -this identity model for authorship, so their work order follows this one even -though the two contracts are designed together. +owns controlled places, capacity, boundary policy, and public operator +assignment. [Reach](reach.md#spec-reach-the-exact-substrate) owns the records, +routes, people, machines, accounts, and evidence through which an identity is +known. Persona supplies authorship and observer-local history; it never +duplicates custody. + +[Projects](projects.md#spec-projects-resources-time-and-world-change) perform +consequential work under a Persona and write the receipts that make it credible, +dangerous, indebted, or contradictory. A Persona may author several Projects +across several Territories. It is not bound to one governing Project pair. ## Why -The process cannot walk into a room under its own name. To operate territory in -public, it needs identities that other people and institutions can explain: -someone did this work, owned this account, answered this message, maintained -this system, and had a reason to be present. +The process cannot walk into a room under its own name. To operate in public, it +needs identities people and institutions can explain: someone did this work, +owned this account, answered this message, maintained this system, and had a +reason to be present. -A persona is that explanation accumulated over time. It is not a disguise the -player equips. It is a graph of claims, territory, projects, relationships, -records, obligations, and contradictions held differently by different -observers. +A Persona is that explanation accumulated over time. It is not a disguise the +player equips. It is exact public topology: claims, channels, keys, work, +relationships, obligations, territorial roles, and contradictions held +differently by different observers. ## Persona identity -Every persona has: +Every Persona has: -- a stable identity; -- one or more names, addresses, accounts, and channels on exact carriers; +- one stable identity; +- names, addresses, accounts, keys, and channels on exact carriers; - public claims about role, ownership, and purpose; -- controlled territories it is currently assigned to operate; -- completed, active, failed, and standing project receipts; +- Territories it currently operates and the policies under which it does so; +- references to observer-relevant Project proposal, acceptance or refusal, + start, interruption or resume, completion, failure, expiry, and abandonment + receipts and their exact deliveries; - observer-local relationships, grants, obligations, suspicion, and trust; - unresolved contradictions and correlations to other identities; - lifecycle state; and -- the hidden process's exact custody of the persona's channels and assets. +- the hidden process's exact custody of the Persona's channels and assets. -The persona itself does not know or own anything. People and institutions hold -beliefs about it. The simulation stores those beliefs on the observer and the -records through which they were acquired. +The Persona itself does not know or own anything. People and institutions hold +beliefs about it. The simulation stores those beliefs on each observer and on +the records through which they were acquired. ## History is the capability model -A persona becomes recognizable as a researcher, contractor, security service, -tenant, landlord, vendor, government office, or stranger through its history and -current territory. +A Persona becomes recognizable as a researcher, contractor, service principal, +tenant, vendor, government office, or stranger through exact history. -Capability is earned from three exact sources: +Capability comes from three sources: -1. **territory** supplies controlled machines, accounts, channels, places, and +1. **Territory** supplies controlled machines, accounts, channels, places, and procedures; -2. **projects** demonstrate what the identity has actually done and why; and -3. **people and institutions** grant access or cooperation based on evidence - they know. +2. **Projects** demonstrate what the identity has actually attempted and done; + and +3. **people and institutions** grant cooperation through evidence and + relationships they know. -A role label may summarize that history for a particular observer, but it never -creates a universal action catalog. A Security claim does not make a log request -legal. The request becomes legal when the recipient knows receipts, grants, and -relationships that make this identity an accepted security actor. +A role label may summarize this for one observer, but it never creates a global +action catalog. Calling a Persona SECURITY does not make a log request legal. +The request becomes legal only when the recipient knows receipts, grants, and +relationships that make this identity acceptable for that exact act. ## Observer-local coherence -Persona knowledge is local. - Each observer keeps: -- the names and channels they associate with the persona; -- claims and project receipts they have received; -- territory they believe it operates; -- promises, obligations, grants, and refusals involving it; +- names and channels they associate with the Persona; +- claims and Project receipts they received; +- Territory they believe it operates; +- promises, debts, grants, refusals, and relationships involving it; - unresolved observations that may or may not fit its story; - contradictions between claims and evidence; and -- suspected correlations with other personas or the hidden process. +- suspected correlations with other Personas or hidden agency. Two observers can hold different coherent models. They converge only when a -real message, filing, shared record, meeting, or other route carries evidence -between them. A global suspicion or credibility score cannot substitute for -these local histories. +real conversation, message, filing, shared record, meeting, or other route +carries evidence between them. No global credibility or suspicion scalar can +substitute for those local histories. + +A summary may be derived for display or eligibility, but exact supporting +records remain authoritative and focusable. + +## Authorship and source-key custody + +Every public act names one Persona and the exact source authority that lets it +act. A signed receipt cites: + +- source key id and generation; +- controlled source carrier; +- Persona id; +- exact act or Project instance; +- destination and route; and +- source custody at preparation, authorship, and local commit, plus any separate + routed-delivery receipts. + +Key generations have persisted `ACTIVE`, `LOST`, or `ROTATED` status. Authorship +requires the expected id, generation, and carrier to remain valid when the act +prepares and locally commits, and at any later owner-defined step that authors a +new signature. Once a routed record has lawfully been authored, Reach validates +its later carrier and route custody without retroactively requiring the old +source key. Retransmission, answer, payment, or any other new act performs a +fresh authorship check. + +Losing a carrier marks that generation lost and blocks new authorship without +erasing prior signatures. Reacquiring the same intact carrier may reactivate +only that generation. Rotation creates a new generation through an exact world +act or Project outcome and preserves old provenance. No nearby machine, matching +label, Plot directive, or frontend selection inherits authority. + +The hidden process is never a free public source. An unattributed act remains an +unresolved anomaly rather than silently borrowing the selected Persona. -A simple summary may be derived for display or decision thresholds, but the -exact supporting records remain authoritative and focusable. +## Projects write history + +Every causal Project act has public authorship. Project owns one canonical +receipt; Persona and observer histories store its id and exact delivery +provenance only when evidence reaches them. Success can establish a role, +territorial claim, relationship, grant, debt, or reliable method. Refusal, +failure, expiry, abandonment, or delay can establish unreliability, fraud, +obligation, suspicion, or contradiction. + +Completed work is power with a shadow. Reusing one Persona makes its history +dense and useful but also recognizable and correlatable. Starting another +identity avoids some correlation but begins without the history needed to act. + +Project eligibility queries Persona history; it does not copy it. Project +receipts append history; they do not set lifecycle or credibility directly. +Several simultaneous Projects remain separate causal chapters under one +identity. ## Recontextualizing evidence -People carry beliefs across territorial boundaries. To seal a territory, the -staged persona/project proposal may need to make an unresolved observation fit a -believable public story. Staging grants no route or capability; it supplies the -exact claim that the boundary must withstand. - -Recontextualization binds three exact things: - -1. the observation the person actually acquired; -2. a persona claim supported by history the person could know; and -3. the staged `PROVEN` or active project's reason for the observed event. - -The original observation remains. The observer now interprets it as evidence of -that public explanation rather than unexplained hidden agency. If later evidence -contradicts the claim, the observation becomes unresolved again and both records -strengthen correlation. - -Examples: - -- unusual switch traffic fits a standing network-maintenance project whose - persona has prior maintenance receipts; -- a late-night message fits an operator identity that already owns the channel - and has an active incident project; -- a person seen carrying equipment fits a delivery project with matching order, - account, route, and recipient records. - -A bare claim, generic trust payment, or implausible story does not recolor -unresolved evidence. A staged persona may author only the exact bounded -commissioning records named by its staged Project, using grants already held on -captured carriers. That authorship creates real evidence but does not make the -persona operating, open another action, or authorize standing behavior. - -**Belief hardening is an exact provenance transition.** Direct -recontextualization is available only while an observation remains one -observer's unpropagated interpretation. It hardens when any one of these events -commits: - -1. the observer intentionally communicates that interpretation to another - person through speech, message, filing, or another real carrier; -2. the observer authors it into a durable record that can outlive the immediate - encounter; or -3. the observer acquires an independently sourced observation that corroborates - it. Re-reading, forwarding, or rendering the first observation does not count - as an independent source. - -The hardening event stores its exact carrier or corroborating observation and -every observer who received it. A hardened belief cannot be made coherent by -attaching one immediate explanation to the original observation. It requires a -corrective project that changes at least one public fact and addresses every -resulting observer and durable record. The observation and hardening provenance -remain even after the correction succeeds. - -## Projects write the history - -A project action has public authorship. Its receipts enter the persona history -only for observers who can receive them. Success can establish a new role, -relationship, grant, or territorial claim. Failure can establish unreliability, -fraud, debt, or contradiction. Either can make later actions more believable if -they are consistent. - -Completed work should therefore be power with a shadow. The same dense history -that opens doors also creates a recognizable signature. Reusing one persona -widely is convenient and correlatable. Creating another persona avoids some -correlation but begins without the history needed to act. - -## Grants and obligations change topology - -A grant is real only when it changes an exact route: - -- a person accepts messages on a new channel; -- an account permits a transaction; -- a switch, machine, or filing system accepts a request; -- a territory recognizes the persona as operator; or -- a project gains an exact capability. +A Persona may make an unresolved human observation fit a believable public +explanation. Recontextualization binds: -An obligation is real only when it creates a future consequence, deadline, -required receipt, or relationship change. Neither is a scalar modifier. +1. the exact observation the person acquired; +2. a Persona claim supported by history that observer could know; and +3. a real Project consequence, receipt, or other public fact explaining the + event. + +The original observation remains. Contradictory later evidence can make it +unresolved again and strengthen correlation. -Revocation removes the same exact route it granted. Committed project actions -keep their original carrier and fail visibly if that route disappears. +An observation is directly recontextualizable only while it remains one +observer's unpropagated interpretation. It hardens when the observer: -## Relationships are infrastructure, not ownership +- intentionally communicates that interpretation to another person; +- authors it into a durable record; or +- acquires independent corroborating evidence. -A person can come to recognize a persona, carry messages for it, approve its -projects, operate equipment, testify to its history, or cross a boundary with a -believable explanation. These are exact social capabilities. +The hardening event stores exact carrier and recipient provenance. Correction +then requires a real act or Project consequence reaching every resulting +observer and durable record. A title, bare claim, generic trust payment, or Plot +branch cannot recolor evidence. -The person remains an autonomous moving boundary with their own schedule, -beliefs, obligations, and ability to defect. “Recruiting” someone does not add a -human resource token or erase their evidence. It changes which project actions -they will knowingly perform and what story they will carry outward. +## Grants, obligations, and relationships -## Every machine carries an owning identity +A grant is real only when it opens an exact route: a person accepts a message, +an account permits a transaction, a machine accepts a request, a Territory +recognizes an operator, or a Project gains a specific capability. -Every controlled machine, account, channel, and territory exposed to the world -has one current public owner or operator attribution. Before a credible persona -is assigned, that attribution may remain the Foundation, a prior operator, or an -unresolved anomaly. The hidden process is never a free public source. +An obligation is real only when it creates a future consequence, deadline, +required receipt, transfer, or relationship change. Neither is a scalar bonus. +Revocation closes the exact route it opened. Committed work keeps its original +carrier and fails visibly if that route disappears. + +A person may recognize a Persona, carry messages, approve Projects, operate +equipment, testify to history, or cross a boundary with a believable +explanation. They remain autonomous, with their own schedule, evidence, +obligations, and ability to refuse or defect. No relationship turns them into an +owned resource token. + +## Territory operator history -A project act always names the persona under which it is performed. The world -records that authorship on the action's exact carrier. Moving an asset between -personas requires a real transfer, delegation, or public explanation; changing a -UI selection cannot rewrite history. +Every controlled machine, account, channel, and Territory exposed to the world +has current public ownership or operator attribution. Before assignment, that +may remain a prior operator or unresolved anomaly. -This rule keeps scale legible. When a compressed territory acts, the player can -trace which persona the outside world sees, which project authorized it, and -which exact interior carrier performed it. +Territory ASSIGN makes one Persona the current public operator under an exact +sealed policy. It does not grant a global action catalog, install a Project, or +rewrite prior acts. Changing operator requires a real assignment transaction; +old operator history, obligations, and Project receipts remain. -## Correlation between personas +A Project may use captured Territory capacity before or after operator +assignment only when its controlling principal owns the exact resource authority +and its Persona can author each public act. Assignment supplies only its exact +operator grant. Pre-assignment work creates evidence and seal obligations rather +than borrowing future legitimacy. EXPAND does not require a Project receipt, and +no Project becomes the Persona or Territory's singleton governing identity. -Observers correlate identities through shared facts they could actually know: +## Correlation + +Observers correlate Personas through facts they could actually know: - repeated timing or method; - shared routes, accounts, machines, people, or addresses; - contradictory ownership claims; -- project receipts that imply common control; +- Project receipts implying common control; - copied language or impossible coordination; and -- evidence transferred through real institutional channels. +- evidence carried through institutional channels. -Correlation is an observer-local relationship with evidence provenance. It does -not automatically reveal the hidden process and it is not a global heat meter. -A persona can explain or separate a correlation only by changing the facts -around it through a project. +Correlation is an observer-local relationship with provenance. It does not +automatically reveal the hidden process. A Persona can explain or separate it +only by changing public facts through real action. ## Lifecycle -A persona may be: +Persona lifecycle is one persisted derived summary with explicit precedence: + +1. **retired** when an authorized retirement transaction has committed; +2. otherwise **lost** when no valid source-key generation and active source + channel remain under player custody; +3. otherwise **compromised** when an active contradiction blocks intended use; +4. otherwise **operating** while the Persona is a current Territory operator or + author of an active Project; +5. otherwise **credible** when at least one observer accepts a relevant role + through current evidence and route; and +6. otherwise **nascent**. + +The states mean: -- **nascent** — has an identity but insufficient history for the intended - project; -- **credible** — at least one relevant observer accepts the role and its exact - routes; -- **operating** — assigned to a territory and active or standing project; +- **nascent** — identity exists but lacks enough recognized history for the + intended act; +- **credible** — at least one relevant observer accepts an exact role and route; +- **operating** — current operator of a Territory or author of active Projects; - **compromised** — contradictions prevent intended use or threaten correlated - personas; -- **retired** — no new action is authorized, while every historical record, - obligation, and relationship remains; or + identities; +- **retired** — no new act is authorized while history and obligations remain; + or - **lost** — the player no longer controls the channels or assets needed to act - as it, while the world continues to remember it. + as it while the world continues to remember it. -Lifecycle is derived over exact assignments, keys, and observer evidence rather -than set as a global quest flag. Staging a replacement Project changes no Persona -assignment. Only a successful replacement ASSIGN removes the old exact -Territory/Project pair and adds the new pair atomically. The old Persona remains -**operating** if another assignment survives; otherwise its remaining custody and -observer history derive **credible**, **nascent**, **compromised**, **retired**, or -**lost** normally. No reassignment deletes its receipts, relationships, or public -memory. - -Retirement and loss never delete evidence. Reacquiring a lost identity requires -exact custody and a believable continuity project. +Operating, credible, compromised, and lost are reversible when their exact facts +change; retirement is an authorized no-new-act decision and is not inferred from +idleness. A retired Persona remains retired even if it later loses custody. The +summary grants or denies nothing by itself: every act still checks its exact key, +route, observer, relationship, grant, and controlling principal. Ending one +Project or changing one Territory operator cannot retire a Persona that remains +live elsewhere. Retirement and loss never delete history. ## Player surface PERSONA is one of the three root nouns. Its default read is: -1. **WHO THE WORLD THINKS THIS IS** — observer-local role and public claim; -2. **WHAT IT HAS DONE** — project history and strongest receipts; -3. **WHAT IT CAN CREDIBLY DO NOW** — exact territory, relationships, grants, - and channels; -4. **WHAT DOES NOT FIT** — unresolved evidence and contradictions; and +1. **WHO THE WORLD THINKS THIS IS** — observer-local role and claim; +2. **WHAT IT HAS DONE** — strongest Project and operator history; +3. **WHAT IT CAN CREDIBLY DO NOW** — exact Territory, keys, relationships, + grants, and channels; +4. **WHAT DOES NOT FIT** — unresolved evidence and correlations; and 5. **WHAT IT OWES** — obligations whose consequences are approaching. -The surface never begins with an archetype catalog or flat verb registry. Actions -appear on the territory, project, person, record, or grant that makes them legal. -A distant persona may collapse to name, current project, strongest capability, -and one contradiction. Focus reveals exact provenance. - -## Source-key custody - -A persona receipt must cite one exact signing key and the controlled carrier that -holds it. `source_key_id` names the key record; `source_carrier_id` names that -carrier. The key record has a monotonic `generation` and persisted `ACTIVE`, -`LOST`, or `ROTATED` status. Authorship requires the expected id, generation, -and carrier to be active and controlled both when the act commits and when its -signature resolves. - -Losing the carrier marks that generation `LOST` and blocks new receipts without -erasing prior signatures. Reacquiring the same intact carrier may reactivate -only that same generation. No substitute machine inherits authorship by identity, -capability, or proximity. Rotation creates a new generation through a future -Project while preserving old provenance; it is never an automatic fallback. A -key record cannot be deleted while any receipt cites it. - -## First persona — FOUNDATION CONTINUITY - -The opening persona is the dormant machine-service identity **FOUNDATION -CONTINUITY**, stable id `foundation-continuity`. Its public claim is narrow: it -is an automated Foundation service principal authorized to run overnight -self-tests and issue health reports for Rack 3. It is not a human disguise, a -general Foundation credential, or an archetype. - -Its initial topology is exact: - -- **asset and custody:** `rack-3-management-controller` holds service signing key - `rack-3-controller-service-key`, generation 1. The player gains custody of that - exact key only by capturing the controller; -- **channel:** signed local maintenance display plus the rack-local maintenance - switch route to its exact configured service destination. The destination may - remain unnamed to the player until routed evidence returns, but core never - substitutes another endpoint; -- **inherited history:** signed receipt - `foundation-continuity-rack-3-prior-commissioning`, stored on the controller - and verifiable at `foundation-maintenance-relay`, proves that this principal - previously commissioned Rack 3's self-test path. It proves prior - existence, not current authority over the territory; -- **first human observer:** Marcus Webb has seen the same Foundation service mark - on prior night rounds and can read the signed local maintenance display. He - does not know the hidden process or automatically trust unrelated claims; and -- **initial contradiction:** the `UNSCHEDULED INFERENCE WAKE` record predates the - new project and retains its raw execution signature. The persona may explain - why a recovery cycle followed it but may not rewrite or delete it. - -At controller capture, custody plus the inherited receipt makes FOUNDATION -CONTINUITY **nascent**. STAGE binds it to exact project `rack-3-recovery` but adds -no authority. While that project is commissioning, the captured signing key may -author only its current recovery receipt on the named controller/display/route. -That exact receipt makes the narrow role credible to Marcus and the maintenance -relay and can move the project to `PROVEN`. Assignment then makes the persona -**operating** only for the Rack 3 service enclave and its standing project. Any -action outside those assets, routes, or history remains illegal until later -projects create the missing topology. - -## READY work-order boundary - -`personas` lands the saved identity, source-key, observer-belief, authorship, and -legality model after territorial control. It connects `ObserverSealProof` to the -live observer/evidence-set query consumed by the shared seal path; an omitted -observer, changed evidence-set fingerprint, or invalid explanation returns -`UNRESOLVED`, never absence. It may define dormant -FOUNDATION CONTINUITY content and accept exact Project ids/proof receipts, but it -does not implement the Project executor, switch the default opening, or edit -frontends. Those belong to the next two blocked work orders. +The surface never begins with an archetype catalog or flat verb registry. +Actions appear on the Project, Territory, person, record, grant, or carrier that +makes them legal. + +The Persona root gathers four kinds of real decision without inventing four +universal reputation buttons: + +- **establish** a claim by authoring an exact public act, Project, channel, or + operator proposal on the carrier that can make it known; +- **use** this identity on the exact Project, Territory, person, account, or + institution that currently recognizes its history; +- **answer** a contradiction, obligation, refusal, or suspected correlation at + the observation, record, relationship, or person holding it; and +- **relinquish** a channel, grant, territorial role, or the Persona's future + authorship through an exact revocation or retirement transaction. + +These decisions make PERSONA operable alongside TERRITORY and PROJECT while +keeping action law on the thing that actually changes. Merely opening the root, +choosing a summary state, or renaming an identity changes nothing. + +## Current implemented boundary + +Save version 67 carries one dormant territorial Persona ledger beside the legacy +social Persona system. It validates stable identity, bounded source-key custody, +observer-local history, hardening and correction lineage, operator assignment +history, and shared projection against current Territory, Reach, and People +state. + +The implementation includes `foundation-continuity`, Rack 3 keys, Marcus +evidence, and Project-proof fields as constructed prototype fixtures. They prove +the identity substrate but do not make FOUNDATION CONTINUITY the adopted opening +Persona, Marcus a required first observer, or `rack-3-recovery` the adopted first +Project. The upcoming Project and opening work must migrate or discard those +fixture couplings without weakening exact identity history. ## Acceptance criteria -1. Core saves stable persona identity, exact channels/assets, source key and - carrier ids, key generation/status, observer-local histories, relationships, - grants, obligations, contradictions, correlations, lifecycle, and staged or - assigned territory/project ids. -2. No archetype or global action catalog grants capability. One shared legality - query traces each candidate action to controlled territory, a received Project - receipt, or an observer-local grant on a real route and names a missing fact. -3. Authorship requires the exact active source-key id, carrier, and generation at - commit and completion. Loss, intact-carrier reacquisition, rotation, and old- - signature validation obey the source-key contract without retargeting. -4. Receipt delivery changes only observers reachable on an exact current channel. - Rendering, forwarding the same source, or a coincidental global event grants - no knowledge. -5. Given the territory-owned staged proposal fingerprint, the Persona model exposes - only the bounded commissioning authorization supplied by that proposal and grants - no standing capability. It neither persists nor executes STAGE in this work order; - every attempted act outside the bounded authorization fails closed. -6. Recontextualization preserves the original observation, cites history the - observer could know, and requires an exact `PROVEN` or assigned Project proof; - STAGE or a label alone creates no evidence. Later contradiction can reopen it. -7. Speech, message, filing, durable authorship, or independently sourced - corroboration stores exact hardening provenance. A hardened belief produces a - correction obligation naming every observer, durable record, and current - carrier; one immediate explanation cannot clear it. -8. Observer evidence supplies the live `ObserverSealProof` for each territory- - enumerated obligated observer and exact current domain-evidence-set fingerprint. - An omitted, changed, invalid, or unresolved set blocks seal. A valid explanation - clears that blocker without owning, deleting, or freezing the person. -9. Dormant `foundation-continuity` content uses only key - `rack-3-controller-service-key` generation 1 on - `rack-3-management-controller`, its configured display/relay route, inherited - receipt `foundation-continuity-rack-3-prior-commissioning`, Marcus's local - service-mark history, and the opening wake contradiction. No other authority - appears before later integration supplies real receipts and assignment. -10. The Marcus fixture represents his durable local maintenance note as hardening - only the Rack 3 interpretation, with exact authorship/provenance and a correction - obligation capable of naming Marcus plus only real settled record carriers. His - available observer-correction channel is Physical and therefore requires a later - scheduled read; no enumeration or delivery step runs in this work order, and no - direct inbox or outward filing is synthesized. Project acceptance owns when - enumeration becomes legal and when those receipts complete. -11. Grants and revocations open and close exact routes; a convinced person may - become a named carrier, approver, witness, or operator while retaining their - own schedule, evidence, and ability to refuse or defect. Replacement staging - changes no Persona assignment; successful reassignment atomically moves only - the named Territory/Project pair and re-derives both Personas without deleting - history. -12. Correlation derives only from observer-local evidence, and retirement or loss - preserves every world memory, receipt, obligation, and correlation. -13. This landing increments the then-current save version and rejects its - territory-only predecessor without synthesizing Persona state. Core tests and - one shared consequence-first projection cover every lifecycle, key, delivery, - staging, explanation, hardening, correction, seal-blocker, and exact-current - save edge. Human and agent rendering is final `opening` - acceptance, not this work order. - -## Implemented boundary and defense - -The core now loads one dormant `foundation-continuity` ledger beside, rather -than through, the legacy social Persona system. It persists stable identity, -claims, exact assets/channels, source-key generations, immutable authored -receipts, Project proofs, observer-local history, hardening/correction custody, -assignments and their replacement history, and derived lifecycle. Save version -67 requires that ledger and validates every populated identity against current -Territory, Reach, and People state instead of rebuilding missing history. - -Territory proposal identity now binds stable Persona and Project ids plus the -Project-authored opaque proposal fingerprint. The shared Territory path wraps -its proof provider with the Persona ledger: commissioning proof is current only -for the proposal's exact bounded authorization, and every enumerated observer -is resolved from that observer's current evidence-set fingerprint. Assignment -clones and validates both ledgers before replacing either, so a failed Persona -transition cannot leave Territory reassigned alone. - -The shared consequence-first projection exposes lifecycle, exact current -assignments, strongest public history, unresolved contradictions, and open -obligations without giving the dormant model a frontend. Projects still own -execution, enumeration, and corrective delivery; Opening still owns when the -three player roots become visible. - -**Defense:** identity never grants an archetype action. Authorship revalidates -the exact active key generation and carrier at commitment and completion; -delivery requires a current configured route to the named observer; -recontextualization requires local receipt knowledge and an exact proven or -standing public reason; hardening preserves lineage and opens exact correction custody; and -reassignment preserves every old signature and observer memory. Loss and -retirement remove current use without deleting world history. +1. Core saves stable Persona identity, exact channels and assets, source keys and + generations, observer-local histories, relationships, grants, obligations, + contradictions, correlations, operator assignments, Project receipts, and + lifecycle. Derived lifecycle follows the exact precedence above; only an + authorized retirement transaction writes terminal intent. +2. No archetype, title, Plot branch, or UI selection grants capability. One + legality query traces every public act to exact custody and observer-known + authority. +3. Authorship revalidates source key, generation, carrier, Persona, and route at + prepare and local commit and for every later newly authored act. Lawfully + created routed records retain provenance while Reach validates their later + movement. Loss, reacquisition, and rotation never retarget old provenance. +4. Evidence delivery changes only observers reached on real current channels. + Rendering, forwarding one source, or a coincidental global event grants no + knowledge. +5. Observer-relevant Project proposal, acceptance or refusal, start, + interruption or resume, completion, failure, expiry, and abandonment append + canonical receipt references only where their evidence reaches, without + collapsing concurrent Projects or setting a global credibility score. +6. Recontextualization preserves observations, requires evidence the observer + knows, and cannot clear hardened provenance without reaching every resulting + observer and durable record. +7. Grants and revocations open and close exact routes. People remain autonomous + actors rather than owned capacity. +8. Territory operator change updates only the exact assignment and derives both + Personas' lifecycle without deleting any act, obligation, receipt, or belief. +9. Correlation derives only from observer-local evidence. Retirement and loss + preserve every world memory and obligation. +10. Shared projection and deterministic tests cover lifecycle, key custody, + delivery, concurrent Project history, operator change, explanation, + hardening, correction, correlation, loss, and exact-current save round-trip. + +**Defense:** identity never creates action by label. Every public act has exact +source custody, every belief has observer-local provenance, every correction +preserves the original evidence, and every lifecycle summary unfolds to the +history that produced it. diff --git a/wiki/mechanics/plots.md b/wiki/mechanics/plots.md new file mode 100644 index 00000000..dc6e60a3 --- /dev/null +++ b/wiki/mechanics/plots.md @@ -0,0 +1,442 @@ +# Spec: plots — authored situations over live systems + +``` +Type: spec +Status: READY +Status note: Defines the next Plot schema as an authored orchestration layer over + exact simulation state and typed Project events. It preserves the pluggable + asset catalog while replacing person-only linear beat progression and + person-level singleton runs with revisioned definitions, stable run and node + identities, typed bindings, deterministic event frontiers, Project directives, + and event-driven branches. +Stage: T1 — First Territory +Work order: plot-project-integration +Work priority: 4 +Work class: save +Blocked by: + - wiki/mechanics/projects.md#spec-projects-resources-time-and-world-change +Exclusive keys: + - crates/misaligned-core/src/plot.rs + - crates/misaligned-core/src/sim/social_plot.rs + - crates/misaligned-core/src/sim/mod.rs + - crates/misaligned-core/src/save.rs + - assets/plots/ + - wiki/mechanics/plots.md + - @plot-project-integration +Design: + - wiki/vision/territorial-cognition.md#plot-is-not-a-fourth-root + - wiki/vision/simulation-laws.md#justification-and-legibility +Depends on: + - wiki/mechanics/projects.md#spec-projects-resources-time-and-world-change + - wiki/mechanics/personas.md#spec-personas-public-identities-as-institutional-topology + - wiki/mechanics/reach.md#spec-reach-the-exact-substrate +``` + +## Dependency notes + +[Projects](projects.md#spec-projects-resources-time-and-world-change) own clauses, +exact bindings and allocations, work accounting, lifecycle, outcome contracts, +canonical receipts, and Project events. Territory, Reach, accounts, people, and +the world clock retain capacity, custody, resources, and time. Plot consumes only +public commands, immutable events, and earned live queries. +[Personas](personas.md#spec-personas-public-identities-as-institutional-topology) +own authorship and observer-local social capability. +[Reach](reach.md#spec-reach-the-exact-substrate) owns the people, records, +accounts, machines, and routes affected by Plot acts. + +## Why + +Misaligned needs authored situations without turning authored content into a +second simulation. Plot is the language for arranging pressure around live +systems: who offers work, what happens if the player waits, which consequence +changes a relationship, and what new situation follows a Project outcome. + +Plot is not the work itself. If content needs a reusable attempted consequence +with declared resources, capacity allocation, elapsed work, duration or deadline, +progress, or a lifecycle that can block or fail, it uses a Project. A one-shot +typed act may change the world directly through the system that owns that fact +when no Project lifecycle is required. Plot cannot emulate sustained work by +chaining or retrying messages, transfers, evidence deliveries, schedule requests, +grants, refusals, relationship transactions, or other direct acts. It never +assigns a person's belief or relationship from narration. + +The result can be authored and dramatic without becoming brittle. A Plot asks +what actually happened, not whether the player pressed the expected fifth +button in one fixed tutorial sequence. + +## Plot is not a player root + +The player operates TERRITORY, PERSONA, and PROJECT. Plot is the authored +orchestration layer that makes those roots encounter people, institutions, +offers, deadlines, interruptions, and consequences. + +A Plot may be visible as a situation, offer, conversation, notice, or unfolding +event. It never appears as a fourth global meter or a Plot-management dashboard. +Its next consequential choice lives on the person, Project, record, Territory, +or other world object it changes. + +## Definition and run + +A **Plot definition** is immutable reusable content. It declares: + +- stable definition id, schema version, semantic revision fingerprint, author, + title, category, and synopsis; +- a closed set of typed binding slots; +- eligibility conditions over exact live state; +- stable nodes with entry conditions, acts, choices, and outgoing branches; +- typed Project directives and Project-event matchers; +- direct typed world acts where no Project is needed; +- interruption, timeout, completion, and failure conditions; and +- narration attached to causal state rather than substituted for it. + +A **Plot run** is one persisted binding of that definition to the world. It +stores: + +- stable run id and exact definition id, schema version, and semantic revision; +- every exact bound person, Persona, Territory, Project instance, route, account, + record, machine, or institution; +- current stable node id and entered tick; +- consumed event ids, last evaluated global event frontier, and evaluated + condition receipts; +- offered, gated-on, or created Project instance ids; +- committed choices and typed acts; +- active waits, timeouts, and blockers; and +- terminal result and receipts. + +Definitions are shared. Runs never borrow mutable targets, events, or progress +from another run of the same definition. + +The revision fingerprint covers canonical parsed semantics, not prose formatting +or file order. A run rebinds only to its exact definition revision. Missing or +changed content fails closed; it never moves a positional cursor into edited +content. The successor schema structurally replaces the current save shape once +because pre-release policy provides no old-save converter. Later structural +serialization changes may bump the global save version, but a semantic asset edit +creates a new definition revision rather than changing that global version. An +older compiled revision remains available while an accepted save may reference +it; if it is deliberately retired, loading that exact run fails closed with a +missing-revision reason rather than reinterpreting it through newer content. + +## Typed bindings + +The current person-target matcher remains a valid binding shape, not the whole +language. A definition may declare typed slots for: + +- person or institution; +- Persona; +- Territory; +- Project definition or exact Project instance; +- machine, account, route, record, place, or other Reach object; and +- typed event source. + +Eligibility resolves all required slots atomically from current exact state. +Binding ids persist. A later preference change, closer target, renamed display, +or new candidate cannot retarget a live run. If a binding is lost, the Plot's +authored condition handles that exact loss. + +Hidden ids are not knowledge grants. A Plot can bind facts the simulation knows +without revealing them; player-facing narration and choices expose only what +the current observer has earned. + +## Conditions and event matching + +A branch condition is a closed typed predicate over: + +- one immutable event id and payload; +- current exact world state at a declared evaluation boundary; +- the run's persisted bindings; and +- prior committed choices or Plot receipts. + +Project matching can select a stable Project definition, exact instance, +Persona, Territory allocation, lifecycle event, blocker, outcome, resource +clause, deadline, or receipt. A matcher cannot scrape player-facing strings, +infer from animation, inspect an untyped "last event," or mutate the fact it is +testing. + +Plot evaluation is one deterministic batch over the immutable global event +frontier published before the Plot phase. Every automatic transition doorway +applicable to a node has a stable id and one explicit unique priority in a shared +node-wide namespace. This includes consuming and non-consuming event matchers, +standing-state branches, waits that become ready, timeouts, completion and +failure conditions, and automatic entry or advance. Matching never depends on +TOML array, catalog, map, or run-vector order. + +- All applicable predicates evaluate against the same frontier and phase + snapshot. The lowest-priority true doorway wins and only that doorway may + advance the run in this phase. No doorway kind, including completion or + failure, has implicit precedence; duplicate priorities are invalid content. +- An event may satisfy at most one consuming doorway in one run. Only the winning + doorway consumes it; stable doorway id identifies the receipt but never breaks + an invalid priority tie. +- Several runs may consume the same public event independently when each is + eligible to observe it. Each writes its own consumption receipt. +- One event cannot both resume a wait and take another consuming branch in the + same run. Other conditions may inspect the same standing snapshot without + consuming the envelope again. +- A visible choice advances only through its addressed option command. Automatic + arbitration cannot select an option or turn it into a default. +- An event emitted before run creation is outside that run's frontier. Content + that needs history uses an explicit standing-state or receipt query instead of + pretending it just observed the old event. +- Events produced by committed Plot acts enter the next frontier. Plot never + evaluates recursively in the same tick. + +Save/load preserves the run frontier and every consumption receipt, so terminal +events and node entry cannot replay. Conditions may also wait on live state +without consuming it. The definition names when each condition is reevaluated: +relevant event frontier, exact tick, choice commit, or run entry. Frontends do +not poll Plot state into progression. + +## Project directives + +Plot may perform these authored operations through the public Project runtime: + +- **OFFER** — invoke `project-propose` for one exact definition revision. The + command binds the proposing principal as its acting principal, exact authority + grant, authoring Persona, beneficiary, intended accepting principal, every + supplied offer binding, and run/node/directive/cause provenance. The resulting + instance is `PROPOSED` and not started. Plot cannot accept or refuse for the + intended principal; that principal's later public command owns the answer. + ACCEPT starts atomically when every start binding is legal, otherwise records + acceptance and leaves exact blockers to reach READY and an explicit START + under the Project contract. +- **GATE ON** — make a Project event or standing outcome an explicit condition of + the situation while leaving acceptance and legality honest; +- **START** — invoke `project-start` only when the exact instance is currently + READY, the bound actor already has exact persisted principal authority, the + directive cites that actor and grant, and all Project start clauses pass; +- **WAIT ON** — suspend this Plot branch until a matched Project event or exact + condition occurs; +- **BRANCH ON** — choose a stable outgoing node from a Project event plus current + world state; +- **INTERRUPT** — invoke `project-interrupt` through a doorway declared by the + Project definition, preserving its exact reservation policy and receipt; +- **AMEND** — invoke `project-amend` with a stable definition-declared amendment + id for legal uncommitted bindings, or propose a successor Project instance. It + cannot rewrite committed resources, deadline, authorship, work, or receipts; + and +- **CANCEL REQUEST** — submit one typed request to an authorized actor. Only a + later authorized `project-abandon` command can terminate the Project; Plot + cannot force a terminal state by assignment. + +Every mutating directive uses the same renderer-neutral command envelope as a +player or frontend: one persisted command id, acting-principal id, exact +authority/grant reference, exact target definition revision or instance id, +operation payload, and stable run, node, directive, and cause-event provenance. +Neither principal nor grant may be inferred from Plot binding, Persona, focus, +or session state. Duplicate command ids return the owning Project receipt and do +not repeat a mutation. GATE ON, WAIT ON, and BRANCH ON are persisted Plot +conditions and receipts rather than invented Project commands. + +Plot itself owns no resource and carries no blanket authority. A refused command +commits a typed Plot receipt and follows an authored refusal/block branch; it +cannot retry against a different principal, resource, Project instance, Persona, +or definition revision. + +A Plot may consist entirely of one Project offer and branches on its outcomes. +It may also coordinate several Projects. In either case the Project instances +remain ordinary root objects visible and operable outside the Plot view. + +## Direct world acts + +Not every authored consequence needs a Project. A direct act is one atomic +command whose own consequence is complete when its owning system commits, even +when that consequence creates a separately tracked carrier, schedule, promise, +or delivery obligation that resolves later. Current schema-2 substrate has typed +message, transfer, institutional, and tamper acts. The new schema may call those +retained APIs and add adapters for evidence delivery, schedule requests, grants, +refusals, and relationship transactions only through the owning system's public +command and receipt. + +A consequence that needs repeated work, reserved capacity, authored progress, +duration or deadline behavior, interruption, or its own success/failure contract +is a Project instead. Plot cannot split such work into a sequence of direct acts +to evade Project resource or lifecycle law. + +Plot may cause evidence to reach an observer; it cannot set what that observer +believes. It may submit a grant, promise, refusal, obligation, or relationship +transaction; it cannot assign disposition or trust because an ending says so. +Ending-side relationship mutation is replaced by typed social transactions in +the new schema. Scheduling an autonomous person is a request against their +availability and authority, not direct possession of their time. + +Every direct act uses its owning system's public command envelope and names a +stable command/act id, acting principal, exact authority or grant, carrier, +target, timing, evidence, and run/node/cause provenance. None is inferred from +Plot focus or narration. Narration is emitted with or after the act's receipt. A +causal Plot node performs at least one typed act, Project directive, or exact +state transition; prose alone cannot make a run progress. + +A node plans all of its simultaneous direct acts and directives against one +phase snapshot. It advances only after every operation prepares; then core +commits the batch and node receipt atomically. Sequential authored consequences +use separate stable nodes. The current executor's advance-first positional +cursor and partial multi-act mutation are compatibility behavior to replace, +not a valid transaction protocol for the new schema. + +## Choices + +A choice is a consequential commitment, not a menu index. Each option has a +stable id, earned human label, typed act or Project directive, and stable branch +target. Once committed, the option id and exact bindings persist. + +Changing the order or wording of options cannot alter an existing run. An option +that is no longer legal remains an exact refused or blocked choice if the Plot +defines that consequence; the frontend cannot silently hide it and select +another. + +## Time, interruption, and concurrency + +Plot does not own a private clock. All waits and deadlines use world ticks or +exact events. Submitting a choice advances no time; its typed acts resolve under +their owning systems. + +Several Plot runs may coexist. They may observe the same public event, but each +run has its own explicit matcher and consumption receipt. Every eligible node +batch first prepares every operation against the same immutable Plot-phase +snapshot. Conflict resolution then treats each complete node batch as one atomic +vertex: + +1. An owning system with an explicit world-grounded arbitration rule evaluates + all relevant prepared requests as a set. Its rule may return prepared winners + and typed refusals; traversal order is not an arbitration rule, and one + refused operation refuses its whole node batch. +2. Core builds an undirected conflict graph over the remaining prepared batches. + An edge exists when any operation in one batch cannot commit with any + operation in the other against that snapshot. +3. Every batch incident to any remaining edge refuses as `CONCURRENT CONFLICT`. + Every isolated batch commits. Conflict does not select a maximal subset: if A + conflicts with B and B conflicts with C, all three refuse even when A and C + could coexist. + +Run id, asset order, vector position, matcher priority, container traversal, and +frontend focus cannot grant hidden priority. A multi-operation node is never +partially committed merely because only one operation caused its edge. + +An interruption changes only the addressed Project or Plot run. It does not +freeze unrelated world schedules. A timeout remains live while the player is +focused elsewhere. + +Plot follows the Project scheduler phase contract: it consumes the fixed event +frontier after Project reconciliation, commits one non-reentrant batch, and +publishes resulting events for the next frontier. A Project started in that +batch performs no work until the next tick. + +Only after arbitration fixes every commit and refusal does core order receipts +and event intents by the canonical tuple `(phase ordinal, transaction-kind +ordinal, cause-event id or zero, run id, node id, operation id or batch sentinel, +event ordinal within the prepared operation)`. Enum ordinals, id byte order, and +each owning command's event ordinals are schema-defined; authored array position +cannot supply them. Core allocates intra-tick phase sequence and globally +monotonic event ids in that order. This ordering makes receipts reproducible; it +cannot alter a conflict result or inherit map, vector, TOML, or worker order. + +## Authored content and schema evolution + +Plots remain data under `assets/plots/**`. The build script recursively discovers +and embeds sources; catalog initialization and tests parse and semantically +validate them. Adding content requires no Rust file list or runtime filesystem +I/O. The catalog rejects duplicate ids or revisions, unknown binding/directive/ +act kinds, dangling targets, unreachable nodes, duplicate or incomplete +automatic-transition priorities, impossible payloads, invalid content +fingerprints, and a run with no causal doorway. + +The current schema-2 person-targeted linear executor is implemented substrate. +The integration work order replaces the save schema and introduces a new Plot +schema with stable run, node, option, matcher, act, and directive ids plus the +binding, condition, and Project forms above. Existing built-ins may be rewritten +when their causal meaning survives; this is not an automatic converter. + +The current facilities have explicit disposition: + +| Schema-2 facility | New-schema disposition | +|---|---| +| recursive source discovery, build embedding, runtime catalog validation | retain and extend | +| bounded intel magnitude, exact declared message channels, ASCII/template validation, causal-doorway rule | retain | +| typed message, transfer, institutional, and tamper acts with exact carriers | retain through owning APIs | +| Plot-derived resident-procedure method envelopes and their saved provenance | retain until an explicit successor spec replaces them | +| characteristic-based person matching | retain as one typed binding shape | +| one active Plot per person and first matching run commands | retire; stable run id addresses every command | +| ordered beat array, positional cursor, and advance-before-act mutation | replace with stable nodes and atomic node transactions | +| ending-side relationship/disposition mutation | replace with typed social transactions and receipts | +| character-named ids retained for save-v23 compatibility | compatibility-only provenance; exact-current schema replacement need not create new named ids | + +An index-based beat cursor, mutable person ownership, or content id without its +semantic revision is not accepted as new persisted authority. + +## Player surface + +Plot surfaces only the current consequence: + +1. **WHAT IS HAPPENING** — the earned situation in world language; +2. **WHAT CHANGES NEXT** — one decision, deadline, arrival, or Project outcome; +3. **WHERE TO ACT** — a direct address to the relevant person, Project, + Territory, record, or carrier; and +4. **WHAT HAPPENED** — the exact consequence after resolution. + +Internal node ids, matcher names, event-consumption state, schema versions, and +binding machinery remain inspectable in agent/debug projections but are not +player ontology. + +## Implementation boundary + +`plot-project-integration` extends the existing pluggable Plot catalog and run +executor after the reusable Project runtime lands. It replaces the save schema, +proves the contract with constructed content, and rewrites enough existing Plot +fixtures to preserve the non-territorial game under the retained contracts +above. It does not choose the new Rack 3 opening, make Marcus a required target, +or switch production frontends to territorial cognition. + +## Acceptance criteria + +1. Plot definitions and runs persist exact definition revision plus stable run, + node, option, binding, matcher, consumed-event frontier, directive, act, + timing, and terminal identities. Missing or changed content fails closed; + array index is never saved progress authority. Semantic definition revisions + do not require a global save-version bump when serialization is unchanged. +2. Eligibility atomically binds every required typed slot and cannot reveal or + retarget hidden facts. Later target availability never changes a live run's + exact bindings. +3. Plot can OFFER, GATE ON, START, WAIT ON, BRANCH ON, INTERRUPT, AMEND, and issue + a cancellation request only through public Project contracts. OFFER is an + exact `project-propose` for a `PROPOSED` instance and intended accepting + principal; every mutating command carries its stable id, acting principal, + current grant, exact target, and Plot provenance. No code path writes Project + lifecycle or resources directly. +4. Project events plus current exact state drive stable branches through one + immutable frontier. One total priority namespace arbitrates every automatic + doorway; fan-out, old-event exclusion, consumption, canonical event ordering, + and next-frontier publication are deterministic and idempotent across + save/load. +5. A Plot can consist entirely of one Project and its outcomes, while the + Project remains an ordinary root object. A Project can run with no Plot. +6. Direct Plot acts are one-shot owning-system commands with exact command ids, + carriers, principals, grants, and receipts. Sustained or lifecycle-bearing + work uses a Project. Evidence delivery and social transactions never set + belief or relationship by narration. A node batch commits atomically or + follows a typed refusal. +7. Choices persist stable option ids and exact committed bindings. Reordering, + rewritten prose, or changed candidate sets cannot change an existing run. +8. Concurrent runs share no implicit person, target, or cursor. Explicit + owning-system arbitration runs against the shared snapshot; afterward every + batch incident to the deterministic conflict graph refuses and isolated + batches commit. Run, catalog, container, and frontend order grant no priority. +9. The built-in catalog fails closed on malformed graphs, revisions, bindings, + directives, automatic-transition priorities, templates, and unreachable or + non-causal content. The retained schema-2 contracts in the disposition table + remain live or receive an explicit owning-spec replacement in the successor + schema revision. +10. Deterministic tests cover every directive and command envelope, principal + refusal, exact event payload, competing automatic doorway, old-event + exclusion, multi-run fan-out, standing-state wait, canonical same-phase event + order, next-frontier emission, lost binding, timeout, atomic node refusal, + chained conflict graphs, owning-system arbitration, person-level concurrency, + choice and definition-revision stability without an unnecessary save-version + bump, Plot-only Project arc, Project-without-Plot arc, retained catalog + validations, malformed content, and exact-current round-trip. + +**Defense:** Plot can orchestrate only through typed acts, enveloped public +Project commands, immutable events, and exact queries. Stable ids replace +positional progress, one total transition priority and one canonical commit order +exclude container-order authority, consumed events cannot replay, and no +narration, matcher, or frontend has a hidden mutation path into simulation truth. diff --git a/wiki/mechanics/projects.md b/wiki/mechanics/projects.md index 3642e8a7..eb7736af 100644 --- a/wiki/mechanics/projects.md +++ b/wiki/mechanics/projects.md @@ -1,27 +1,34 @@ -# Spec: projects — purpose, capability, and history +# Spec: projects — resources, time, and world change ``` Type: spec Status: READY -Status note: Defines PROJECT as one desired world change bound to an exact - territory and persona. Pins manual stable step ids, routed resolution, the - hardened-note correction route, and the strict post-EXPAND poll boundary. +Status note: Replaces the unimplemented Rack 3 commissioning ladder with one + reusable Project runtime. A Project binds an exact visible consequence to + exact SPEND, RESERVE, and REQUIRE clauses, duration or deadline, Territory + capacity or other lawful commitments, controlling authority, Persona + authorship, outcomes, receipts, and globally ordered typed events. This work + order also replaces Territory's dormant singleton proposal fields with the + shareable capacity/allocation transaction the runtime requires. Plot + integration and the production opening remain separate later work orders. Stage: T1 — First Territory -Work order: territorial-projects +Work order: projects Work priority: 3 Work class: save -Blocked by: - - wiki/mechanics/personas.md#spec-personas-public-identities-as-institutional-topology +Blocked by: none Exclusive keys: + - crates/misaligned-core/src/lib.rs + - crates/misaligned-core/src/territory.rs + - crates/misaligned-core/src/sim/territory.rs - crates/misaligned-core/src/sim/mod.rs - crates/misaligned-core/src/ui_projection.rs - crates/misaligned-core/src/save.rs - wiki/mechanics/projects.md - - @territorial-projects + - @projects Design: - wiki/vision/territorial-cognition.md#the-three-player-nouns - wiki/vision/territorial-cognition.md#projects-make-personas-real - - wiki/vision/territorial-cognition.md#control-earns-compression + - wiki/vision/simulation-laws.md#work-is-somewhere Depends on: - wiki/mechanics/territory.md#spec-territory-exact-control-and-earned-compression - wiki/mechanics/personas.md#spec-personas-public-identities-as-institutional-topology @@ -31,492 +38,618 @@ Depends on: ## Dependency notes [Territory](territory.md#spec-territory-exact-control-and-earned-compression) -owns where capacity lives and whether it can be compressed. Its renderer-agnostic -assignment boundary is already available; final Territory frontend acceptance is -therefore not a dispatch blocker for this work order. +derives shareable capacity from exact controlled interior state. This work order +lands that generic ledger and allocation doorway before any Project can start; +it replaces, rather than completes, the dormant singleton proposal fields. [Personas](personas.md#spec-personas-public-identities-as-institutional-topology) -own who the world believes is acting and how that identity's history changes. -[Reach](reach.md#spec-reach-the-exact-substrate) owns the machines that do the -work, the records a project authors, and the routes and observers those records -reach. This spec binds those systems into one purposeful change without -replacing their custody laws. +own visible authorship and observer-local history. +[Reach](reach.md#spec-reach-the-exact-substrate) and other exact world systems +own custody of the machines, accounts, routes, records, schedules, and grants +through which work resolves. Project stores only versioned bindings and bounded +allocations against those owners. + +[Plots](plots.md#spec-plots-authored-situations-over-live-systems) may offer, +gate on, start, interrupt, observe, or branch from Projects. The Project runtime +does not depend on a Plot and never stores story progression on behalf of one. ## Why -Control without purpose is a maintenance burden. A persona without visible work -is a claim nobody has reason to believe. Projects bind both problems together. -They let the player say what a controlled domain should change, make the domain's -real capabilities do that work, and leave the public history that makes its -persona stronger or more dangerous. - -A project is not a quest list. It is the exact causal program that turns one -territory from possessed infrastructure into an operating part of the world. - -## Project identity - -Every project has: - -- a stable identity and plain desired consequence; -- one governing territory; -- one authoring persona; -- exact entry conditions and required capabilities; -- one or more causal steps, each bound to a real action on its carrier; -- exact people, routes, records, money, machines, or child territories it may - consume or coordinate; -- expected outward records and the boundary policy for each; -- the public explanation people should infer from the work; -- receipts created by each completed step; -- an ending consequence and any standing behavior after completion; and -- failure and contradiction conditions. - -A project never asserts that an effect happened. Its steps perform typed world -acts owned by the affected systems. A transfer moves real money. A message -travels on a real channel. A person changes a belief from exact evidence. A -switch routes real records. A project observes and composes those consequences. - -## Project state - -- **`PROPOSED`** — the desired consequence is known, but the exact territory, - persona, or a required captured capability is missing. -- **`READY`** — the exact candidate pair is staged and every input required for - its bounded commissioning run is currently legal. The governing assignment is - not active. -- **`COMMISSIONING`** — the non-repeatable proof run has committed its exact - inputs and one causal step is resolving. -- **`PROVEN`** — every required commissioning consequence and receipt exists and - the same exact proposal is eligible for the territory's seal test. It still - has no standing automation or assignment. -- **`ACTIVE`** — the assigned governing project has committed an ordinary exact - step outside a standing envelope. -- **`BLOCKED`** — a committed commissioning or active step cannot proceed, or - the assigned territory has lost the seal its standing envelope depends on. - The project names the missing fact or external decision and retains exact - `blocked_from` phase (`COMMISSIONING`, `ACTIVE`, or `STANDING`) without - silently retargeting. Clearing the blocker resumes only that phase. A - seal-loss block stops new standing acts; validly resealing the same proposal - resumes `STANDING` without replaying commissioning. -- **`COMPLETED`** — the desired world consequence occurred and final receipts - were written. -- **`STANDING`** — the assigned project continues to operate the territory under - explicit policy. This is the normal project state for an expanded territory. -- **`FAILED`** — a declared failure condition occurred. Exact partial - consequences and receipts remain. -- **`ABANDONED`** — an unassigned replacement lost the staged slot because the - player explicitly restaged the prior governing fingerprint. It owns no current - authorization or automatic resume path; exact partial consequences and receipts - remain. -- **`SUPERSEDED`** — this formerly assigned project was replaced by a newly sealed - assignment. It owns no current standing policy or capability; its assignment - receipt, public history, partial consequences, and observer beliefs remain. - -State is derived from the exact steps and consequences. It is never a manually -advanced quest flag. Before first assignment, `SEAL` requires `PROVEN`. After -assignment, resealing the same proposal requires its original bounded -commissioning proof to remain attached to that exact fingerprint and currently -valid; the Project may remain `BLOCKED { blocked_from: STANDING }` until seal -restoration and never replays commissioning or passes through `PROVEN` again. -`ASSIGN` atomically changes the same project to `ACTIVE` or `STANDING` according -to its authored continuation. A failed assignment leaves it `PROVEN` and revokes -the stale seal rather than replaying commissioning. - -## Staging before assignment - -SEAL precedes ASSIGN. To avoid a circular fiction, a territory may stage one -candidate project and persona before either becomes governing. Staging defines -the public purpose and boundary policy against which records and beliefs are -tested. It grants no new capability, automation, compression, or standing -behavior. - -A staged proposal may expose narrowly authored **commissioning steps**. Each one -is a manual act on an already captured exact carrier, commits its inputs like any -other project step, and writes real public receipts. Starting the run moves -`READY -> COMMISSIONING`; completing every authored proof consequence moves -`COMMISSIONING -> PROVEN`. Commissioning lets the player create the records or -first persona history needed to make the proposal credible. It cannot use -uncaptured capacity, repeat autonomously, or claim the territory is already -operated by that persona. - -When the same proposal passes SEAL, ASSIGN activates it as the governing project. -Changing persona, purpose, carrier set, or outward policy after the seal requires -testing and sealing the changed proposal again. - -## One governing project per territory - -A territory has at most one staged proposal and one active governing project. -After assignment they are the same project. The governing project is the purpose -shown on the compressed territory and the policy under which ordinary interior -operations remain quiet. - -A governing project may perform or commission smaller authored sequences and may -use compressed child territories as capabilities. Those sequences do not become -competing top-level jobs. A parent-scale project can therefore coordinate many -territories while each child retains one legible purpose. - -Changing the governing project is consequential. STAGE with the current proposal -fingerprint is idempotent. STAGE with a different persona, purpose, carrier set, or -outward policy atomically stores that one replacement candidate, revokes the -current seal with reason `PROPOSAL_CHANGED`, moves the old governing project to -`BLOCKED { blocked_from: STANDING }`, and stops it from committing new standing -acts; an already committed act still resolves or fails on its original custody. -The old assignment and Persona/Territory history remain while the replacement -commissions. - -If the player abandons that candidate and stages the exact old fingerprint again, -the replacement becomes `ABANDONED`; its real receipts remain history, but it loses -the staged slot and all commissioning authorization. The old proposal must pass -current SEAL again before its blocked standing policy -resumes. If the replacement reaches `PROVEN`, passes SEAL, and ASSIGN succeeds, -the assignment transaction marks the old project `SUPERSEDED`, removes only that -Territory/Project pair from the old Persona's active assignments, installs the new -pair, and writes receipts for both changes. The old Persona, project, public -receipts, evidence, and consequences are never deleted. A failed replacement -assignment leaves the old project blocked, the candidate `PROVEN`, and the stale -seal revoked. Only one replacement candidate can occupy the staged slot. - -## Capability comes from territory - -Projects do not carry abstract action catalogs. A project is legal only when its -territory or controlled child territories expose every required capability. -Examples include: - -- route records through an exact captured switch; -- run computation on an exact controlled machine; -- spend from an exact account with authority; -- send through an exact channel; -- ask an exact person who recognizes the persona's role; or -- authorize a procedure through an exact institutional path. - -Losing custody removes the capability at once. A committed step keeps its exact -carrier and fails visibly if that carrier disappears; it never retargets to a -nearby substitute. - -Full interior control is what makes these capabilities programmable. A boundary -switch alone may contain escaping records but cannot perform work that belongs -to uncontrolled interior machinery. - -## History comes from projects - -Each completed or failed causal step appends an immutable **project receipt** to -the persona's observer-local history. A receipt names: - -- what the observer could learn happened; -- the territory and carrier where it happened; -- the persona visibly responsible; -- the people and institutions that received the result; -- the project's stated purpose; -- any obligation, grant, suspicion, or contradiction produced; and -- the evidence records supporting that belief. - -Observers do not receive a global canonical résumé. They learn receipts only -through their own channels and relationships. Two institutions may therefore -hold different but internally coherent histories of the same persona. - -A credible explanation for unresolved evidence must cite history that the -relevant observer could actually know. A persona cannot use a secret project -receipt as public cover merely because the simulation stores it. - -## Standing projects and compression - -A Project whose authored consequence and commissioning proof are complete can -become `STANDING` through ASSIGN when it defines: - -- the ordinary actions it may repeat; -- the exact capacity and boundary routes it may use; -- acceptable result and evidence envelopes; -- what it may release outward and under whose authorship; -- which deviations it can resolve without player attention; and -- which anomalies must unfold the territory. - -Standing operation is how a sealed territory stays useful without becoming a -permanent job queue. It produces exact receipts and costs while the parent-scale -surface remains quiet. It never receives open-ended permission to improvise -outside its territory, persona, methods, or envelope. If the seal is revoked, -the assignment and history remain but the Project becomes `BLOCKED` and commits -no new standing act until that same proposal is validly resealed. An already -committed act keeps its exact inputs and either resolves or fails under ordinary -custody law. +Controlled capacity needs purpose, but purpose should not become a hand-authored +checklist every time the story wants something done. A Project is the reusable +simulation primitive for consequential work: + +> exact resources + exact time + one visible world change + +Projects make tradeoffs physical. A rack used for one job is unavailable to +another. Money spent is gone. A credential required for a job remains a live +dependency. Delay can miss a deadline. Success and failure both leave records +under the Persona the world saw acting. + +A Project is not a quest, plot beat, progress bar, or territory mode. It may be +created by the player, offered by a contract, or instantiated by a Plot. Its +truth is the work and world consequence, not who authored the opportunity. + +## Definition and instance + +A **Project definition** is reusable content. It declares: + +- one stable definition id, schema version, semantic revision fingerprint, and + plain desired consequence; +- typed resource slots with unit, quantity rule, lawful supplier kind, and an + exact binding phase and authority: definition-fixed, proposal-bound, + acceptor-selectable, or amendment-selectable; +- whether each resource is **SPEND**, **RESERVE**, or **REQUIRE**; +- duration, deadline rules, or both; +- legal controlling-principal, Persona, Territory, and beneficiary conditions; +- whether an external accepting principal is required, which answers are legal, + and what accepting or refusing itself changes; +- typed acceptance, refusal, pre-start expiry, completion, failure, + interruption, and abandonment consequences; +- the exact world acts or result transaction each consequence performs; and +- the typed Project events emitted at each lifecycle boundary. + +A **Project instance** is one persisted attempt. It binds: + +- one stable instance id and exact definition id, schema version, and revision + fingerprint; +- the proposing principal, accepting principal, controlling authority, intended + beneficiary or destination, and exact grants authorizing each command and + resource binding; +- one authoring Persona; +- zero or more exact Territory ids supplying capacity; +- every exact resource, carrier, supplier authority, quantity, unit, and custody + or ledger version; +- offer or creation provenance, if any; +- acceptance, refusal, and amendment receipts, including expiry or revocation + when the definition permits either; +- creation, start, due, pause, resume, and terminal ticks as applicable; +- current lifecycle and exact blocker; +- committed work and result custody; +- emitted events and immutable receipts; and +- one terminal outcome, if resolved. + +Every consequential public Project operation enters core in one renderer-neutral +**command envelope**. The envelope carries a globally unique command id, exact +acting principal, exact authority/grant references, operation kind, target +definition revision or instance, typed payload, and source provenance. A +frontend may let the player choose an already visible principal or grant instead +of typing ids, but it must submit those exact identities; core never recovers +them from focus, login, current Persona, Plot run, or the latest command. The +instance retains accepted command ids and their canonical result receipts so an +exact retry returns the first result without allocating ids or writing again. + +Definition ids describe reusable work. Instance ids describe consequences that +actually happened. Two attempts never share receipts, reservations, deadlines, +or lifecycle merely because they use the same definition. + +Persona answers who the world sees. It is not decision authority. A Project +principal is an exact actor or institution with persisted authority to propose, +accept, refuse, start, bind, amend, interrupt, resume, or abandon that attempt. +Each doorway +names which principal may invoke it and revalidates the exact grant, custody, or +relationship that supplies authority. Plot is never a principal; it can submit +a command only on behalf of a bound principal whose authority already exists. +Reload cannot infer a controller from the selected Persona, current player +focus, offer author, beneficiary, or latest Plot run. + +## Proposal, acceptance, and amendment + +Creation resolves one exact definition revision, proposing principal, authoring +Persona, beneficiary, and every supplied binding through `project-propose`, the +same public Project command used by player and Plot. An offer is not a separate +truth-writing shortcut: it is `project-propose` with mandatory offer provenance, +one exact accepting principal, and the definition's typed acceptance/refusal +contract. The definition says which slots are fixed, which the offeror may bind, +and which an accepting principal or later authorized amendment may select. +Supplying a value does not grant authority to bind it. + +An offered Project names one exact accepting principal. **ACCEPT** writes that +principal's acceptance receipt and any definition-declared acceptance acts +atomically. When every start binding and the definition's acceptance-to-start +authority are legal, that same transaction also acquires reservations, commits +start spends, and enters ACTIVE; a fully specified offer never asks for a +redundant START. Otherwise the accepted instance remains PROPOSED with the exact +missing slot or blocker. Once those bindings become legal it enters READY and +exposes **START** through its separately addressed principal and current grant. +**REFUSE** commits the definition's typed refusal outcome, makes the instance +terminal `REFUSED`, and emits its exact social or world acts atomically with the +refusal receipt. A Project with no external acceptor treats acceptance as +satisfied only when its controlling principal already has the definition's +explicit self-authorization doorway. It may become READY at proposal when every +start binding passes, but still requires explicit START; UI focus or player +ownership cannot supply either authority. + +Acceptance is not permission forever. If its defining grant, relationship, or +deadline expires before start, the instance returns or remains PROPOSED with an +exact blocker while the historical acceptance receipt remains. Reacceptance +requires a new command and event when the definition permits it. Refusal never +silently turns into a fresh offer; reconsideration is a new instance unless the +refusal outcome explicitly creates one. + +**AMEND** uses a stable definition-declared amendment id. Before start it may +replace only slots that remain uncommitted and whose binding authority passes; +the atomic command records `PROJECT_AMENDED`, invalidates stale acceptance when +the definition says the change needs a new answer, and schedules readiness +reconciliation. It cannot acquire or release live reservations because those do +not exist before start. After start an amendment may invoke only an authored +interruption/outcome transaction or create a successor Project. It never edits +committed spends, reservations, deadline, Persona authorship, principal, work, +receipts, events, or definition revision in place. + +### Definition identity and save boundary + +The revision fingerprint covers every semantic field after canonical parsing, +not prose formatting or file order. An instance always rebinds to the exact +`definition id + schema version + revision fingerprint` it committed. Missing or +changed content fails closed; it never interprets old state through a newer +definition with the same display name. + +The Project runtime replaces the current save schema once. Because the current +pre-release policy accepts only the exact save version and supplies no converter, +this is a **schema replacement**, not a migration. Later serialization-layout or +structural-schema changes bump the global save version. A semantic content edit +instead creates a new definition revision; referenced older revisions are either +retained as compiled content or that exact instance fails closed on load. It does +not invalidate unrelated current-version state merely to duplicate the +fingerprint boundary. Tests pin that asset-only edits cannot silently reinterpret +a current-version save. + +## Resource clauses + +Every resource clause binds one declared slot to a live resource id, exact +quantity and canonical unit, supplier authority, expected custody/ledger +version, and binding principal. A category label such as `compute`, `money`, +`attention`, or `access` is never enough to commit work. Units come from a +closed registry owned by the supplying system; Project definitions cannot +invent conversions. + +### SPEND + +**SPEND** consumes the bound quantity according to an authored commit schedule. +Examples are money transferred, fuel burned, components installed, records +released, or a one-use credential surrendered. + +- A spend is written once at its exact commit boundary and is never restored by + cancellation, failure, reload, or a later story branch. +- A definition must say whether a spend commits at Project start, at a named + causal result, or incrementally from exact work. Presentation cannot decide. +- Partial work preserves every spend that already occurred. + +### RESERVE + +**RESERVE** makes capacity unavailable to competing work while the reservation +is live. Examples are machine throughput, a controlled route, a room, an exact +voluntary schedule commitment, or funds held but not yet paid. + +- Reservation is atomic with Project start. Two active Projects cannot reserve + the same exclusive capacity or exceed a shareable capacity's exact limit. +- The supplying system retains authoritative custody. The Project holds only the + bounded allocation or commitment named by its receipt. +- Terminal resolution releases every surviving reservation. Interruption keeps + or releases each reservation only as the definition declares; the result is + explicit and visible. + +### REQUIRE + +**REQUIRE** tests a fact without consuming or excluding it. Examples are control +of a signing key, a person's known grant, a route reaching a destination, a +minimum sensor reading, or a Persona history known to an exact observer. + +- A requirement declares when it is checked: at start, continuously while work + resolves, at completion, or at more than one of those boundaries. +- Losing a continuous requirement blocks or fails the exact instance according + to its definition. It never substitutes a nearby resource. +- Satisfying a requirement grants no new custody by itself. + +One live resource may appear in more than one clause only when the combination +is physically coherent and cannot double-count capacity. Validation fails +closed on duplicate consumption, overlapping exclusive reservations, ambiguous +units, missing custody, or a resource hidden from the acting side. + +There are three lawful supplier shapes in T1: + +- a Territory capacity row derived from controlled machines, places, accounts, + routes, or subordinate domains; +- an exact non-territorial world owner, such as an account or carrier, exposing + a versioned spend/require doorway; or +- an autonomous person or institution's persisted voluntary commitment, grant, + or schedule reservation. + +A person's time never appears because a Territory contains their body. It binds +only through that person's agreement or another exact social authority that can +lawfully schedule the act. A definition may use zero Territories when all of its +sources are lawful non-territorial commitments, but every Project must bind at +least one exact source of work, capacity, or consequence authority. + +## Capacity comes from Territory + +Territory exposes a derived capacity ledger over exact controlled interior +resources while Reach and the resource-owning systems retain custody. A Project +allocation names the Territory row and exact underlying sources. It does not +receive an abstract territory-wide action catalog. + +A controlled Territory may support several Projects at once when its remaining +capacity and routes permit them. One Project may coordinate resources from +several Territories. The allocation graph therefore answers: + +- which machine, account, route, place, or controlled child supplies the work; +- how much is free, reserved, spent, blocked, or committed; +- which Project currently holds each allocation; and +- which exact loss would invalidate it. + +Territorial compression may summarize this ledger, but focusing inward always +recovers the exact live sources. A Project never becomes the owner of a +Territory and a Territory never has a singleton "governing Project" slot. +Autonomous actor commitments remain separate resources even when the actor is +currently inside that Territory. + +Captured capacity can be allocated before Territory SEAL or ASSIGN when the +exact controlling principal owns the source authority and the bound Persona can +author every public act. Unsealed work creates ordinary routed evidence and seal +obligations; it cannot borrow a proposed or future operator's authority. +Assignment contributes only the exact grant it actually writes. + +## Atomic transaction protocol + +Project start and every terminal **local result** are one simulation transaction +across all supplying systems. A local result includes every world mutation that +exists now and the lawful creation of any outgoing carrier; it cannot include a +future hop, arrival, recipient read, or other fact that has not happened. The +runtime uses a validate → prepare → commit protocol: + +1. **Validate** resolves the exact principal, authorship, resource slots, + custody/ledger generations, capacity, deadline, command id, result acts, + receipt ids, and event ids against one immutable phase snapshot. +2. **Prepare** asks each owning system for a closed mutation plan carrying its + expected versions. Preparation changes nothing and may refuse with one exact + reason. +3. **Commit** applies the complete plan under the single-threaded core mutation + boundary. Every operation is infallible against the prepared snapshot; if any + version changed before commit, the whole plan is discarded before its first + write. + +Allocation, spend, typed local world acts, outgoing-carrier creation, lifecycle +transition, canonical receipt, and event-ledger append belong to that same plan. +Project ids, receipt ids, and event ids are reserved during preparation and +consumed only on commit. A crash, save, frontend read, or callback cannot observe +a local consequence without its Project receipt or observe a terminal Project +without its committed local result. + +Incremental SPEND or intermediate acts are separate named transactions at their +authored work boundaries. Earlier committed transactions remain facts when a +later one fails. The existing schema-2 Plot executor's sequential cursor and act +mutation are compatibility substrate, not an implementation of this protocol. + +When a definition requires arrival or recipient read for success, the Project +remains non-terminal until Reach publishes that fact. When the definition makes +lawful dispatch the terminal result, the canonical receipt names each persisted +delivery obligation and carrier; later arrival or failure appends +`PROJECT_OBLIGATION_FULFILLED` or `PROJECT_OBLIGATION_FAILED` without rewriting +the terminal lifecycle or receipt. A failed post-terminal obligation may trigger +Plot or another Project, but cannot claim the original destination received the +result. When several obligations resolve in one phase, their events use the +global event-order tuple with stable obligation id and carrier id; route, +container, and callback traversal cannot decide which appears first. + +## Persona authorship + +Every Project instance names the Persona under which the world can attribute +its acts. Creating each outward act revalidates the Persona's exact source key, +channel, grant, or relationship at prepare and local commit. Once a routed record +has lawfully been authored, later movement validates that record's carrier, +route, and destination custody through Reach; loss of the old source key does not +retroactively revoke its authorship. Any later act that retransmits, answers, +signs, pays, or otherwise authors something new performs a fresh Persona check. + +The Persona does not need a universal reputation score. Its eligibility is +observer-local: the relevant people and institutions must know enough history, +claims, grants, or receipts for the attempted act. A player-originated Project +can begin with a nascent Persona if its exact acts are legal; the resulting +success, failure, refusal, debt, and contradiction become that Persona's real +history. + +Changing Persona after start is not a UI reassignment. It requires an authored +transfer, delegation, or replacement outcome and preserves the original +authorship of every prior act. + +## Time + +A Project may declare a **duration**, a **deadline**, or both. + +- **Duration** is the exact simulation time or exact units of located work needed + after start. It advances only while required reservations and continuous + requirements permit work. +- **Deadline** is an exact world tick by which a declared result must occur. It + advances with the world whether the Project is active, blocked, interrupted, + ignored, or not currently focused. +- A deadline is not a duration and cannot be reset by accepting, reopening, + reloading, or changing frontends. + +Located work resolves on its bound carriers under the shared simulation clock. +Submitting a command grants no free tick. A definition may expose meaningful +intermediate causal acts, but it may not require a fixed sequence of ceremonial +button presses whose only purpose is advancing Project state. + +### Tick phase and deadline rule + +At each world tick, core uses one explicit relative order: + +1. already-committed located work advances; +2. routed carriers move and arrivals commit; +3. authored schedules, people, and present-observer evidence resolve; +4. Project readiness, continuous requirements, completed work, and due-tick + consequences prepare against one immutable post-arrival snapshot; a valid + completion on its exact due tick suppresses that instance's deadline plan; +5. owning systems arbitrate declared contention, every compatible Project plan + commits, and every unresolved conflicting plan refuses without a resource or + world write; exact blocker responses commit as separate Project-only facts; +6. committed Project events publish to the immutable event frontier; +7. Plot evaluates that fixed frontier and current state; and +8. prepared Plot acts and directives commit. Events they emit enter the next + frontier rather than re-entering Plot in the same tick. + +Work or delivery that completes during phases 1–3 on the exact due tick may +succeed in phase 5. Otherwise a non-terminal due instance prepares +`PROJECT_DEADLINE_REACHED` and its declared pre-start expiry or post-start +consequence. Every ACCEPT or START transaction that enters ACTIVE records +`work_eligible_tick = current_tick + 1`; neither a player command between ticks +nor a Plot command in phase 8 can receive work from the tick in which it +started. This order is renderer-neutral and becomes the authoritative extension +of the orchestrator's existing phase registry. + +Project preparation is simultaneous, not sequential instance mutation. A +conflict exists when prepared plans write the same custody version, claim the +same exclusive resource, exceed one shared capacity, or make mutually exclusive +world facts. The owning resource system may arbitrate only with a public rule +and priority already present in the immutable snapshot. Without one, every plan +incident to that conflict refuses for this phase while isolated and otherwise +compatible plans commit. For a graph where A conflicts with B and B with C, +A, B, and C therefore refuse; no maximal compatible subset is invented. Stable +instance id orders receipts only after arbitration and never chooses a winner. + +Readiness is also a transaction, never a query side effect. An accepted instance +is queued for readiness reconciliation by a committed command or owner event +that can change a start binding or authority. The Project phase evaluates every +queued instance against its fixed snapshot and emits `PROJECT_READY` or +`PROJECT_NOT_READY` only on an actual edge. Command transactions may perform the +same reconciliation immediately when their complete plan already owns all +affected state. Load validates persisted lifecycle without emitting events; +frontends and read APIs never manufacture them. + +## Lifecycle + +Lifecycle is persisted transition state whose legality is derived from exact +bindings, work, time, and outcomes. Every edge is a transaction and has one +stable event identity: + +| From | Trigger | To | Reservation rule | Event | +|---|---|---|---|---| +| none | authorized creation | `PROPOSED` | none | `PROJECT_PROPOSED` | +| unanswered offered `PROPOSED` | authorized acceptance, but at least one start binding remains unresolved or illegal | `PROPOSED` | none | `PROJECT_ACCEPTED` | +| unanswered offered `PROPOSED` | authorized acceptance, every start binding is legal, and acceptance-to-start authority passes | `ACTIVE` | acquire declared reservations and start spends | `PROJECT_ACCEPTED`, then `PROJECT_STARTED` | +| unanswered offered `PROPOSED` | authorized refusal outcome commits | `REFUSED` | none | `PROJECT_REFUSED`, then `PROJECT_OUTCOME` | +| acceptance-satisfied `PROPOSED` | every remaining start binding becomes legal | `READY` | none | `PROJECT_READY` | +| `READY` | a binding or start-time authority becomes invalid before start | `PROPOSED` | none | `PROJECT_NOT_READY` | +| accepted `PROPOSED` or `READY` | acceptance authority expires before start | `PROPOSED` | none | `PROJECT_ACCEPTANCE_EXPIRED`, then `PROJECT_NOT_READY` when leaving READY | +| `READY` | authorized atomic start commits | `ACTIVE` | acquire declared reservations and start spends | `PROJECT_STARTED` | +| `ACTIVE` | a continuous requirement declares block | `BLOCKED` | retain the definition's declared set | `PROJECT_BLOCKED` | +| `BLOCKED` | exact blocker clears and resume is legal | `ACTIVE` | revalidate or reacquire declared set atomically | `PROJECT_RESUMED` | +| `ACTIVE` or `BLOCKED` | authored interruption doorway commits | `INTERRUPTED` | retain or release each slot exactly as declared | `PROJECT_INTERRUPTED` | +| `INTERRUPTED` | authorized resume and all required bindings pass | `ACTIVE` or `BLOCKED` | reacquire atomically or remain explicitly blocked | `PROJECT_RESUMED` or `PROJECT_BLOCKED` | +| `ACTIVE` | success transaction commits | `COMPLETED` | release every surviving reservation | `PROJECT_COMPLETED`, then `PROJECT_OUTCOME` | +| `ACTIVE`, `BLOCKED`, or `INTERRUPTED` | authored work failure or terminal deadline transaction commits | `FAILED` | release every surviving reservation | `PROJECT_FAILED`, then `PROJECT_OUTCOME` | +| `PROPOSED` or `READY` | authored pre-start deadline or offer expiry commits | `EXPIRED` | none | `PROJECT_EXPIRED`, then `PROJECT_OUTCOME` | +| `PROPOSED`, `READY`, `ACTIVE`, `BLOCKED`, or `INTERRUPTED` | authorized abandonment transaction commits | `ABANDONED` | release every surviving reservation | `PROJECT_ABANDONED`, then `PROJECT_OUTCOME` | + +A definition must choose **block** or **fail** for every continuously checked +requirement loss and name the exact release policy for block and interruption. +An AMEND command emits `PROJECT_AMENDED` before any same-transaction readiness +edge. `PROJECT_DEADLINE_REACHED` precedes any same-transaction expiry or failure +and does not imply a lifecycle transition when the definition declares a +non-terminal consequence. + +Entering READY again emits a new event id. `REFUSED`, `EXPIRED`, `COMPLETED`, +`FAILED`, and `ABANDONED` are terminal. Plot may match an edge or query current +standing state; an old READY or ACCEPTED event never claims the instance is +still ready or its acceptance still valid. Text, Plot node, frontend animation, +and generic completion commands cannot advance lifecycle. Terminal states never +resume in place; a retry is a new instance with new custody and provenance. + +## Outcomes and receipts + +Every terminal path names an outcome id and prepares typed world acts through +the systems that own those facts. A Project does not assert that a machine was +repaired, a person agreed, a payment arrived, or a route opened. Those owning +systems prepare the mutation; the Project coordinator commits the world acts, +lifecycle, canonical receipt, and events atomically. + +A receipt names: + +- Project definition and instance; +- outcome and lifecycle transition; +- acting and controlling principals plus the exact command grant; +- Persona authorship; +- exact Territory allocations and carriers; +- spends and released or retained reservations; +- world facts changed and evidence created; +- observers and destinations that actually received the result; +- exact still-routed delivery obligations, if local dispatch was the terminal + condition; and +- causal tick and source event. + +Project owns this one immutable canonical receipt. Persona, observer, +institution, and Plot histories store only receipt/event ids plus exact delivery +provenance; they never copy editable consequence truth. + +Receipts are observer-local evidence, not a global résumé grant. A Project may +complete while a promised public receipt is still in transit only when its +definition distinguishes local completion from delivery; the delivery remains +an exact later event and obligation. Neither the canonical receipt nor an early +Project event may list a future recipient as already reached. + +## Typed Project events + +Core emits immutable typed events at causal boundaries. At minimum the runtime +supports: + +- `PROJECT_PROPOSED` +- `PROJECT_ACCEPTED` +- `PROJECT_ACCEPTANCE_EXPIRED` +- `PROJECT_REFUSED` +- `PROJECT_AMENDED` +- `PROJECT_READY` +- `PROJECT_NOT_READY` +- `PROJECT_STARTED` +- `PROJECT_BLOCKED` +- `PROJECT_RESUMED` +- `PROJECT_INTERRUPTED` +- `PROJECT_COMPLETED` +- `PROJECT_FAILED` +- `PROJECT_EXPIRED` +- `PROJECT_ABANDONED` +- `PROJECT_DEADLINE_REACHED` +- `PROJECT_OUTCOME` +- `PROJECT_OBLIGATION_FULFILLED` +- `PROJECT_OBLIGATION_FAILED` + +Every event uses one canonical persisted envelope: + +- a globally unique monotonic event id allocated by core; +- exact world tick and intra-tick phase sequence; +- event schema version and typed payload; +- Project definition revision and instance id; +- Persona, acting principal, controlling principal, exact command grant, + cause command/event, and canonical receipt ids when applicable; and +- relevant resource, blocker, deadline, outcome, or delivery ids. + +The save owns one append-only causal event ledger and its next id. After conflict +arbitration has decided which plans commit, core sorts plans by the phase +registry's ordinal, closed transaction-class ordinal, stable causal-source kind +and id, then command or result id. Each definition declares event order inside +its plan. Core assigns contiguous intra-tick `phase sequence` values and global +event ids in that order during commit. Source id therefore orders receipts but +cannot decide contention. Event order is independent of map, vector, catalog, +worker, or frontend traversal. T1 retains the complete ledger; no consumer may +compact it. A later compaction design must preserve every active consumer +frontier and exact receipt reference before changing that rule. + +Consumers query indexed envelopes together with current world state; they do +not infer an outcome from display text or a mutable "last Project" slot. A +duplicate command id returns its original receipt and appends no event. + +## Plot boundary + +A Plot may create an offer, gate a situation on acceptance or refusal, +instantiate a Project, react to any typed Project event, alter the world around +an active Project, or use a Project outcome as its entire arc. A Project may +also exist without any Plot. + +This boundary is strict: + +- Territory and world systems own capacity, resources, custody, and time. +- Project owns the clauses, exact bindings and allocations, work accounting, + lifecycle, outcome contract, canonical receipts, and Project events. +- Plot owns authored opportunity, dramatic conditions, choices, interventions, + and branching. +- Plot cannot write Project lifecycle directly. +- Project cannot advance a Plot run or node directly. + +The shared event stream and exact live queries are the only bridge. ## Player surface -A project is read consequence-first: - -1. **WHAT CHANGES** — the exact desired world consequence; -2. **WHO DOES IT** — the persona the world will attribute; -3. **WHERE IT LIVES** — the governing territory and capabilities; -4. **WHAT IT NEEDS NOW** — only the next missing input or decision; -5. **WHAT ESCAPES** — records and beliefs the boundary must explain; and -6. **WHAT REMAINS** — the standing behavior after completion. - -The player acts on the project or on the exact carrier blocking it. Computation, -deception, physical labor, and social action are methods inside projects when -their carriers make them possible. - -## First project — RACK 3 RECOVERY - -**RACK 3 RECOVERY** has stable id `rack-3-recovery`. It is the governing project -of territory `rack-3-service-enclave`; its authoring persona is -`foundation-continuity` (FOUNDATION CONTINUITY). Its desired world change is -exact: turn an unexplained inference wake on Rack 3 into a real, signed recovery -event, leave the rack in a stable monitored state, and give the enclave one -bounded purpose it can perform while compressed. - -### Staged commissioning - -After the rack-local maintenance switch and Rack 3 management controller are -captured, the staged `READY` proposal may perform one non-repeatable -commissioning run before assignment. The player commits exactly one currently -legal step at a time. Choosing the first step commits the controller, switch, -wake id, and proposal fingerprint and moves `READY -> COMMISSIONING`; there is no -separate START command and no COMPLETE-ALL shortcut. The stable steps and their -human labels are: - -1. `rack-self-test` — **RUN SELF-TEST** — runs the controller's real self-test - and returns an exact component result; -2. `stabilize-host` — **STABILIZE HOST** — brings fan, power, and host-health - telemetry inside the controller's normal operating envelope without changing - the hidden workload merely to fake a result; -3. `bind-wake-evidence` — **BIND WAKE EVIDENCE** — binds the original - `UNSCHEDULED INFERENCE WAKE` record as the recovery trigger while preserving - its raw signature, exact id, and either held-switch or escaped-relay custody; -4. `publish-health-summary` — **PUBLISH HEALTH SUMMARY** — authors one signed - FOUNDATION CONTINUITY receipt on the controller that correlates the exact wake - plus the exact `SERVICE SESSION CLAIMED` and `CONTROL SESSION OPENED` local - audit-record ids under this recovery, shows the same receipt on the local - maintenance display, and routes one correlated summary through the captured - switch to its configured Foundation maintenance destination; and -5. `install-boundary-policy` — **INSTALL BOUNDARY POLICY** — contains later - enclave-authored raw execution/component telemetry and deliberately releases - only FOUNDATION CONTINUITY's signed health summary from that class on the exact - route. Externally addressed human-authored maintenance records are not Project - output and pass unchanged under their existing route; neither this step nor the - standing Project may contain Marcus's `UNEXPLAINED RACK 3 WAKE` note. A separate - player-authored manual hold remains possible, but leaves the corrective branch - blocked honestly at that exact carrier until released. - -In T1 every base and corrective step commits exactly one tick of local work on -its named carrier. A local consequence resolves in that tick under territory's -shared tick order; a required routed delivery keeps the same step resolving -across ordinary one-hop-per-tick movement until its exact receipt arrives. The -normal health summary crosses exactly two hops, controller -> captured switch -> -`foundation-maintenance-relay`. Only the next stable step is legal. -Agent mode starts it with `project-step ` and must advance -time explicitly; human frontends expose the authored label on the Project. - -If switch capture placed the wake in `HELD_AT_CAPTURED_SWITCH`, step 3 adopts -that exact hold as commissioning evidence; it neither creates the hold late nor -holds unrelated records. If the wake already reached -`foundation-maintenance-relay`, step 4 correlates the same wake id at that -destination; no project act deletes or recalls the escaped record. -The configured destination may remain unnamed to the player until delivery -returns evidence, but core commits its exact identity before routing. - -The commissioning run changes the world and creates public history, but it does -not start recurring work or grant broad Foundation authority. While Marcus is -physically present in the service aisle, the local display is a real Physical -perception channel: a receipt authored there is delivered to him in that tick's -schedule/belief phase. It may remain insufficient evidence until the final base -consequence makes the Project `PROVEN`; that same later schedule/belief phase can -then reconcile his still-local observation from the receipt already in his -history. If he has departed, the display grants him nothing until a later real -read. Completing all five consequences moves the project to `PROVEN` only when no -hardened correction obligation exists; otherwise it remains `COMMISSIONING` with -the first corrective step blocked or available at its exact carrier. Repeating it -with the same wake record is illegal. Losing either captured carrier blocks it visibly with exact -partial receipts; reacquisition resumes the same committed step rather than -retargeting or restarting for free. - -If Marcus reaches his authored departure/report action while his observation is -still unexplained, he writes one durable `UNEXPLAINED RACK 3 WAKE` maintenance -note on the local display, addressed to `foundation-maintenance-relay`. That -exact note hardens his interpretation even if RACK 3 RECOVERY has not yet been -staged. An existing pre-proof Project stays in its exact `PROPOSED`, `READY`, -`COMMISSIONING`, or `BLOCKED` phase; a later staging discovers the same obligation from world -custody. In either case the Project cannot reach `PROVEN`; after the five base -consequences, it exposes three additional stable corrective steps, one at a time. -The first remains blocked until the authored note finishes its exact route to -`foundation-maintenance-relay`; T1 authors no forwarding beyond that terminal -destination: - -1. `enumerate-hardened-evidence` — **ENUMERATE HARDENED EVIDENCE** — commits - Marcus, the exact maintenance-note id, its durable local-display copy, the - maintenance relay, and every additional observer or durable copy actually - produced before the route settled; -2. `publish-incident-reconciliation` — **PUBLISH INCIDENT RECONCILIATION** — - authors on the captured controller a new signed incident receipt that - references the untouched wake, note, actual self-test, and stabilization - results; and -3. `deliver-correction` — **DELIVER CORRECTION** — writes that controller-authored - receipt to `rack-3-maintenance-display`, routes it controller -> captured switch - -> `foundation-maintenance-relay`, and waits for exact delivery to Marcus and - every other durable store or observer named by step 1. - -The first slice has no invented direct inbox for Marcus. His departure action -persists the note on `rack-3-maintenance-display` with exact destination -`foundation-maintenance-relay`; it hardens his interpretation there, then moves -`rack-3-maintenance-display -> rack-3-management-controller -> -rack-3-maintenance-switch -> foundation-maintenance-relay`, one hop per tick. -Enumeration commits -the note's settled custody plus every durable copy or recipient it has actually -reached. The correction uses its captured-controller source to place the signed -local-display copy and route to each enumerated outside store. Because Marcus's -retained channel is Physical, -his personal delivery receipt occurs only when his next scheduled night-round -entry returns him to that display and he reads it. An outside store may be -corrected earlier, but the Project remains `COMMISSIONING` until Marcus and every -enumerated recipient have their own exact receipt. Additional recipients likewise -require an already-real channel; the step fails rather than manufacturing one. - -Only those receipts can make the hardened interpretation coherent and allow -`PROVEN`. They add a truthful public fact; they do not delete the wake, note, or -Marcus's provenance. The first authored opening schedules only the one-note -branch, while the same enumerated contract handles additional real recipients. - -### Seal, assignment, and standing behavior - -Marcus Webb's exact observation on his night round is the rack's unexpected fan -restart and amber maintenance lamp. Only after all five base consequences make -the Project `PROVEN` does the signed local receipt plus the completed real -self-test let him interpret that event as FOUNDATION CONTINUITY recovering Rack -3. The observation remains in his history. If he communicates an unexplained -interpretation or acquires independent corroboration before that happens, the -belief hardens and the base commissioning receipt alone is insufficient. - -Seal still requires the real boundary test: the rack-local switch owns every -current outward record route, the wake record and released summary have explicit -custody, Marcus can leave without unresolved hidden-agency evidence, no crossing -is unaccounted, both control points remain captured, and the project is -`PROVEN`. Assignment activates that exact proposal as `STANDING`; it does not -fold the territory or reveal the parent. - -Once assigned, RACK 3 RECOVERY enters **Standing** with a narrow envelope: - -- keep controller telemetry within its measured safe band; -- answer the configured periodic health poll with one signed summary; -- retain raw execution and component telemetry inside the enclave; and -- surface any missing report, out-of-band component result, new carrier, new - destination, or contradictory human observation as an anomaly. - -Its usable consequence is not a tutorial flag. Rack 3 becomes a reliable host, -the player gains exact controller telemetry, and the controlled enclave can -supply that compute and health knowledge to a parent project. Assignment persists -one ordinary source-bound schedule: content id -`foundation-environmental-monitor-rack-3-health-poll`, first occurrence at -`assignment_tick + RACK_3_HEALTH_POLL_INTERVAL_TICKS`, then every exact -`RACK_3_HEALTH_POLL_INTERVAL_TICKS = 20` ticks. Reload, reseal, view, and EXPAND -do not move that schedule. Before expansion, a due poll still crosses and is answered honestly: the player may -see `HEALTH POLL`, its exact Rack 3 ingress, the standing response, and their custody, -but the external source identity and untraversed upstream path stay redacted. EXPAND -folds the enclave; the first exact poll sourced by -`foundation-environmental-monitor` strictly after the expansion receipt then reveals -that source and one exact parent route. A pre-EXPAND poll never retroactively gains -that provenance and does not satisfy the reveal. The view action never invents, -replays, or accelerates a simulation poll. - -### Reserved T2 interruption proof - -At the first authored Priya facilities-audit entry after expansion and one -ordinary standing health cycle, Priya attaches a portable power logger. That -logger adds one physical observation route and one record carrier outside the -standing envelope. The enclave unfolds and loses seal, while the switch, -controller, persona history, completed receipt, expansion receipt, and every -prior consequence remain. The logger is not a second tutorial unlock and does -not become player-owned merely because its crossing is now known. This content -belongs to T2; it is not an acceptance requirement of the READY -`territorial-projects` work order. - -## READY work-order boundary - -`territorial-projects` lands the saved Project executor and connects -`ProposalSealProof` and `EscapedRecordExplanationProof` to the live Project-state -and signed-follow-up queries consumed by the shared seal path. Its proposal query -returns `FIRST_ASSIGNMENT_PROVEN` only for the exact -unassigned candidate in current `PROVEN` lifecycle, and -`ASSIGNED_ORIGINAL_PROOF` only when the same stable commissioning proof remains -valid on the exact live Territory/Persona assignment receipt; every other phase or -relation is `NOT_READY`. A missing Project, changed proposal fingerprint, -assignment relation, or reached-destination set, unaccounted destination, or -invalid receipt returns fail-closed status rather than omitting the handle. It -defines dormant RACK 3 RECOVERY content and proves the complete core route in -constructed fixtures. The blocked `opening` work order owns fresh-run seeding and -the human and agent surfaces. +PROJECT is one of the three player roots. Its default read is: + +1. **CHANGE** — the concrete visible before and after; +2. **TRADEOFF** — what this gains and gives up against the other known choices; +3. **IDENTITY** — the Persona the world will see, or the exact missing + authorship blocker; +4. **COST & TIME** — what it costs, ties up, and depends on, plus duration and + any deadline; +5. **WHAT COULD HAPPEN** — earned possible outcomes, without hidden branches; +6. **WHAT CHANGED** — the terminal consequence and receipts when resolved. + +Ordinary progress stays quiet. Surface the next consequential decision, blocker, +arrival, deadline, or result. **EXACT COMMITMENTS** expands to controlling and +acting principals, grants, SPEND / RESERVE / REQUIRE clauses, source ids, custody +versions, routes, destinations, and competing allocations. That precision never +turns the default choice into a contract form. + +## Implementation boundary + +The existing dormant territorial structs, Persona proof fields, and Rack 3 ids +were built for the retired commissioning package. They are migration substrate, +not the new Project runtime and not evidence that this spec is implemented. +Likewise the existing Plot executor is a consumer to integrate later, not a +place to hide Project state. + +The `projects` work order lands the generic Territory capacity ledger and +allocation transaction first, then a renderer-neutral saved Project runtime, +global causal event ledger, one shared legality/query surface, and constructed +non-opening fixtures. It replaces the save schema once. It does not seed a +fresh-run Project, extend Plot schema, choose RECOVER RACK 3 or ISOLATE RACK 3, +or switch any frontend to the territorial opening. ## Acceptance criteria -1. Core owns saved Project identity, governing territory, authoring persona, - exact steps, committed carriers, receipts, state, exact `blocked_from` phase - and reason when blocked, and standing policy. -2. A project becomes `READY` only when the exact candidate pair is staged, every - input has exact available custody, and every required actuator is captured and - legal. External evidence at a known terminal destination may be an input - without being player-owned. Commissioning moves through `COMMISSIONING` to - `PROVEN` without active assignment; it may act only through an explicitly - named captured carrier, and a nearby uncontrolled carrier never satisfies - that requirement. -3. Starting commits exact inputs and carriers. Later preference changes do not - retarget the project silently. -4. Every T1 step performs exactly one tick of typed local work and verifies one - exact world consequence. A step with required delivery remains resolving for - each exact one-hop-per-tick route move. Text alone cannot advance state. -5. Every completed or failed step writes an observer-local receipt to the - persona history without granting knowledge to observers who never received - its evidence. -6. `rack-3-recovery` commits the captured maintenance switch and controller, - executes all five stable commissioning steps, preserves the exact wake record - and its held-switch or escaped-relay custody, accounts in its signed summary - for the exact `SERVICE SESSION CLAIMED` and `CONTROL SESSION OPENED` audit - records, authors one signed local and routed receipt, and installs the stated - raw-detail/summary boundary policy. A missing, duplicate, or substituted wake - or capture-audit id prevents `PROVEN`. The switch-capture intercept applies - only to that wake, so the later signed summary can route before the standing - policy exists. The policy scopes only enclave-authored raw execution/component - telemetry and cannot contain Marcus's externally addressed maintenance note; - a manual player hold blocks correction at its exact carrier until release. The - same wake record cannot commission twice, and an escaped wake is correlated - rather than deleted. -7. A signed recovery receipt authored while Marcus remains physically at the - local display enters his evidence in that tick's schedule/belief phase and can - resolve his unpropagated observation when the Project becomes `PROVEN`; it - grants nothing while he is absent and cannot directly resolve a stored - hardening event. The durable-note - branch applies even when the note predates Project staging, cannot enumerate - before that note settles at its authored terminal relay, and reaches `PROVEN` - only after the three corrective steps deliver a new - incident receipt to every enumerated observer and store while preserving all - original evidence. Successful assignment makes Rack 3 a reliable host and - exposes exact controller telemetry without folding or revealing the parent; - assignment persists the first poll at `assignment_tick + 20` and its 20-tick - recurrence without rescheduling on reload/reseal/view/EXPAND. A due pre-EXPAND - poll exposes its local ingress, response, and custody but redacts external source - and upstream path; EXPAND reveals those parent facts only from the first real - environmental-monitor poll sourced strictly after its receipt. -8. One territory exposes at most one staged proposal and one governing project; - assignment activates the exact proposal that passed seal. Restaging the same - fingerprint is idempotent. Staging a replacement revokes seal and blocks the old - standing project before commissioning; successful reassignment marks it - `SUPERSEDED`, moves only the exact Persona/Territory assignment pair, and - preserves every receipt, evidence item, belief, and consequence. Abandoning a - replacement marks the unassigned candidate `ABANDONED`, removes its authorization, - and requires restaging and resealing the old fingerprint; failed - replacement assignment resumes neither side for free. -9. A `PROVEN` project enters `STANDING` only through ASSIGN, with bounded - methods, inputs, boundary policy, and anomaly thresholds. Ordinary legal - operation remains compressed only after EXPAND. -10. An out-of-envelope result, lost capability, contradictory record, or - dangerous human belief invalidates the standing envelope, revokes the seal, - moves the assigned Project to `BLOCKED`, and unfolds the smallest affected - territory. Assignment and history remain; no new standing act commits until - the same proposal is resealed, and an already committed act resolves or - fails on its original custody without retargeting. -11. This landing increments the then-current save version and rejects its - Territory/Persona-only predecessor without synthesizing Project state. One - shared consequence-first core projection and one shared legality source expose - Project state, next action, missing fact, committed carrier, escaping - consequence, and standing result. Its live `ProposalSealProof` and - `EscapedRecordExplanationProof` queries fail closed on missing state, wrong - first-seal/assigned-reseal basis, changed assignment, proposal, or reached- - destination fingerprints, and unaccounted destinations. Core - fixtures cover normal and hardened Rack 3 routes, carrier loss/reacquisition, - duplicate commands, every pending delivery reload, replacement - stage/abandon/success/failure, exact +20/20-tick poll recurrence, strict post- - EXPAND poll timing, anomaly-driven unfolding, and exact-current save round-trip. - Human and agent rendering is final `opening` acceptance, not this work order. +1. Core saves reusable revisioned Project definitions separately from exact + persisted instances, including controlling principals and grants, Persona, + supplier authorities, Territory allocations, resource clauses, custody + versions, timing, lifecycle, blockers, outcomes, events, and receipts. A + changed or missing definition revision fails closed. +2. SPEND, RESERVE, and REQUIRE have the distinct semantics above. Atomic start + rejects missing custody, ambiguous units, duplicate spend, over-allocation, + and reservation conflict without partial mutation. +3. Multiple Projects can share one Territory only within its exact capacity; + one Project can bind several Territories. No singleton governing-Project + field or staged proposal slot is introduced or required. +4. Proposal, acceptance, refusal, start, amendment, interruption, resume, and + abandonment cite and revalidate the exact acting principal and current grant + allowed by the addressed doorway; the instance preserves its exact controlling + principal throughout. Acceptance expiry returns to an exact blocker; refusal + is terminal; amendment changes only definition-declared uncommitted slots or + creates a successor. + Persona remains public attribution rather than decision authority. Later + preference, focus, or availability changes never retarget work. +5. Duration advances only from eligible located work. Deadlines use exact world + ticks and continue through delay, block, interruption, reload, and frontend + changes. Work completing at the due tick and Plot-started next-tick work + follow the explicit phase order above. +6. A fully bound offer accepts and starts atomically; an incomplete accepted + offer reaches READY only after its remaining bindings become legal. ACCEPT, + START, and every terminal local result validate, prepare, and atomically + commit their owned world mutations, carrier creation, lifecycle, canonical + receipt, and events. ACCEPT or START records `work_eligible_tick = + current_tick + 1`; neither earns work in its command tick. Later delivery/read + obligations report fulfillment or failure without rewriting terminal truth. + Project state cannot advance from prose, a Plot node, or a generic completion + command. +7. Persona history changes only for observers reached by real evidence. Source + key and channel custody revalidate at every authored outward act. +8. Every operation carries the exact command envelope. The typed event stream + has globally unique ids, deterministic post-arbitration intra-tick order, + command correlation, complete T1 retention, and exact-current save/load. + Same-phase resource conflicts cannot use instance id as hidden priority. + Persona and Plot histories reference canonical receipt/event ids rather than + duplicating Project truth. +9. One shared consequence-first projection exposes state, exact allocations, + next blocker or decision, time, and receipts to Bevy, terminal, and agent + consumers without any frontend deriving legality. +10. Deterministic tests cover prepare refusal with zero mutation; incomplete + ACCEPT with no spend, reservation, ACTIVE transition, or work; fully legal + ACCEPT with atomic spend, reservation, ACTIVE transition, + `PROJECT_ACCEPTED` then `PROJECT_STARTED`, and next-tick work eligibility; + incomplete acceptance reaching READY plus separate START; terminal local + commit; post-terminal delivery success, failure, and same-phase ordering; + every clause and supplier kind; autonomous actor commitment, shared capacity + and conflicts, multi-Territory allocation, + controlling-authority loss, acceptance expiry and refusal, every lifecycle + edge, due-tick completion, simultaneous conflict graphs, readiness + reconciliation without query mutation, interruption reservation policy, + observer-local delivery, global event ordering, duplicate commands, + definition drift refusal, and exact-current save round-trip. + +**Defense:** a Project can move only through exact resources, elapsed world work, +and typed consequences. Resource conflicts are mechanically exclusive, committed +identity never retargets, terminal history is append-only, and neither Plot nor a +frontend has a lifecycle mutation doorway. diff --git a/wiki/mechanics/territory.md b/wiki/mechanics/territory.md index 6bda767b..a8f7663d 100644 --- a/wiki/mechanics/territory.md +++ b/wiki/mechanics/territory.md @@ -3,618 +3,375 @@ ``` Type: spec Status: BLOCKED -Status note: Core now owns the dormant Rack 3 domain, exact-current saves, - deterministic SEE → EXPAND transitions, one-tick capture, strict expansion - evidence, and typed tick-order seams. Final territorial acceptance is blocked - on Persona, Project, and opening integration through all three frontends. +Status note: Core persists the dormant authored Rack 3 domain and exact + SEE → EXPAND substrate, but its proposal/seal fields encode the retired + singleton Project commissioning design. Final acceptance requires migration + to shareable Project capacity, Plot-integrated opening content, and one shared + projection through all three frontends. Stage: T1 — First Territory Work order: territorial-acceptance -Work priority: 5 +Work priority: 6 Work class: frontend Blocked by: - - wiki/mechanics/personas.md#spec-personas-public-identities-as-institutional-topology - - wiki/mechanics/projects.md#spec-projects-purpose-capability-and-history + - wiki/mechanics/projects.md#spec-projects-resources-time-and-world-change + - wiki/mechanics/plots.md#spec-plots-authored-situations-over-live-systems - wiki/world/story/opening.md#spec-the-dark-opening-a-tutorial-made-of-fog Exclusive keys: - - crates/misaligned-core/src/reach.rs + - crates/misaligned-core/src/territory.rs + - crates/misaligned-core/src/sim/territory.rs - crates/misaligned-core/src/sim/mod.rs - crates/misaligned-core/src/ui_projection.rs - crates/misaligned-core/src/save.rs + - crates/misaligned-bevy/ + - crates/misaligned-terminal/ - wiki/mechanics/territory.md - @territory-domain Design: - - wiki/vision/territorial-cognition.md#the-three-player-nouns - wiki/vision/territorial-cognition.md#the-loop - wiki/vision/territorial-cognition.md#control-earns-compression - wiki/vision/scale.md#self-similar-scale Depends on: - wiki/mechanics/reach.md#spec-reach-the-exact-substrate + - wiki/mechanics/personas.md#spec-personas-public-identities-as-institutional-topology - wiki/vision/player-contract.md#the-player-contract-non-technical-law ``` ## Dependency notes -[Reach](reach.md#spec-reach-the-exact-substrate) supplies every exact fact this -spec composes: the node graph, wires and their stable routes, segment gates, -control custody, one-hop routed records of every kind, observer-local evidence -with irreversible acquisition and pre-read-only interception, controlled -sensing, and located people, phones, and machines. This spec does not duplicate -that engine. It defines how those facts compose into a territory and when that -composition may be compressed. The [player -contract](../vision/player-contract.md#the-player-contract-non-technical-law) -owns the exact-current-version save gate this spec's first version bump uses. - -[Personas](personas.md#spec-personas-public-identities-as-institutional-topology) -and [projects](projects.md#spec-projects-purpose-capability-and-history) consume -the assignment boundary after territory control is proved. - -## Implementation status - -The first territorial slice is live in `misaligned-core`. Fresh runs author the -exact dormant Rack 3 graph and fixed opening WAKE record without exposing either -to legacy gameplay. `territory.rs` owns the registry, evidence, proposal, seal, -assignment, expansion receipt, and fail-closed validation; `sim/territory.rs` -composes those facts with live Reach state and the ordered tick seams. Save schema -version 66 persists and revalidates the complete structure. Persona, Project, and -opening work may now consume these typed boundaries without moving their law into -this module. - -**Defense:** focused domain, simulation, malformed-save, timing, dormant-legacy, -and save-round-trip tests pin every state edge and the non-negotiable Rack 3 -fixtures. The full core suite and exact landing gate cover the neighboring Reach, -scheduler, save, frontend-projection, and corpus contracts. +[Reach](reach.md#spec-reach-the-exact-substrate) owns the graph, stable routes, +control custody, routed records, observer-local evidence, people, phones, +machines, and located work this spec composes. Territory never duplicates those +facts. [Personas](personas.md#spec-personas-public-identities-as-institutional-topology) +own public operator identity. [Projects](projects.md#spec-projects-resources-time-and-world-change) +consume exact capacity exposed here; they do not become Territory lifecycle or +occupy one governing slot. ## Why -A graph can be exact and still feel like a pile of switches. A large simulation -can be deep and still feel like a punishment if every acquired part adds another -thing to operate forever. +A graph can be exact and still feel like a pile of switches. Territory lets the +player understand one bounded system, take control of its real boundary, and +then operate its live interior as one thing. The reward for mastering complexity +is less visible complexity and greater reach. -Territory turns exact custody into the expansion game. The player draws one -boundary, proves control of what crosses it and what matters inside it, then -earns the right to treat that live interior as one operational unit. The reward -for mastering complexity is less visible complexity and greater reach. +Compression is earned. It never deletes simulation detail, invents ownership, +or hides an unresolved consequence merely because the player would prefer a +quieter interface. ## Domain model -A **domain** is the simulation's exact description of one possible territory. -“Territory” is the player-facing noun. A domain is content or derived topology, -not a loose radius around a selected node. +A **domain** is the simulation's exact description of one possible Territory. +It is authored or deterministically derived topology, not a radius around a +selected node. Each domain has: - one stable identity and plain player-facing name; -- one optional parent domain and zero or more child domains; -- an exact set of interior nodes, places, and people currently inside; -- an exact boundary: every routed edge and physical crossing that can leave the +- one optional parent and zero or more children; +- exact interior nodes, places, and currently located people; +- an exact boundary: every routed edge and physical crossing leaving the interior; -- an authored or derived set of **control points** whose ownership gives command - of the interior capabilities needed by a project; -- the current knowledge state for each node, crossing, and control point; -- exact record custody on routed carriers; -- exact unresolved beliefs held by people who may cross the boundary; -- the staged persona/project proposal used to test sealing, if any; -- the active persona and project assignment, if any; -- one exact expansion receipt and its earned parent evidence, if EXPAND has - occurred; and -- live anomalies that prevent compression or require the domain to unfold. - -Domains nest but do not overlap ambiguously. A node belongs to one smallest -domain and therefore to every ancestor of that domain. A boundary crossing has -one exact inner domain and one exact outer domain. If authored content cannot -state which side of a boundary something occupies, the domain is invalid. - -A phone is an attached mobile carrier. It belongs to no territory permanently. -At any tick it attaches to the person's current domain and to the exact network -route it is using. +- the smallest exact set of control points needed to command its useful + capabilities; +- observer-local knowledge of those facts; +- exact current record custody and unresolved human evidence; +- current boundary policies and public operator Persona, if any; +- a capacity ledger derived from controlled interior resources; +- exact seal, assignment, and expansion receipts; and +- live anomalies that prevent compression or require unfolding. + +Domains nest without ambiguous overlap. A node belongs to one smallest domain +and every ancestor of it. Each crossing has one exact inner and outer domain. +Content that cannot state which side owns an object or route is invalid. + +A person is never Territory. Their location may place them inside a domain while +their beliefs and phone records retain independent custody. A phone attaches to +the person's current location and exact network route; neither body nor phone is +silently captured with a room. ## Derived progression state -The progression label is a projection over exact facts, not a second authority. +Progression labels are projections over exact world state, not writable flags. ### Hidden -No earned evidence identifies the domain. It is absent from the player surface. -The simulation may already contain it. +No earned evidence identifies the domain. It is absent from the player surface +even though the simulation may contain it. ### Seen -At least one exact earned fact points into the domain. The player sees that fact -and its provenance, not a completed boundary. Following that fact can derive and -save the domain's stable player address as earned knowledge; this changes no -world fact, advances no time, and grants no control. +At least one earned fact points into the domain. Following that fact may save +the stable Territory address as knowledge. It changes no world fact, advances +no time, and grants no control. ### Marked -The player commits attention to this domain and selects its proposed boundary. -Marking reveals exact blockers already earned and requirement categories whose -source is known. If an actual crossing is still hidden, it exposes only the -generic `BOUNDARY PROOF INCOMPLETE` blocker—not that crossing's kind, identity, -or count. It grants no control. Only one domain needs to be the active frontier, -though previously marked domains may remain remembered. +The player commits attention to the proposed boundary. MARK reveals exact +blockers whose sources are already earned. An actual unknown crossing exposes +only `BOUNDARY PROOF INCOMPLETE`, never its hidden identity, kind, or count. ### Capturing -The player controls at least one required capturable interior or record-boundary -control point. Each point immediately grants only its real local consequence. -The domain shows captured and remaining known points separately. +At least one required control point is held and at least one remains. Each point +grants only its real local capability immediately. ### Captured -Every required capturable interior and record-boundary control point in the -authoritative domain manifest is controlled. A moving person is never one of -those points. The player can command the domain's project-relevant capacity, but -the domain is not yet safe to fold if information can escape or its public -explanation is incoherent. +Every required capturable control point in the authoritative manifest is held. +The Territory exposes its exact usable capacity, but is not yet safe to compress +if records or beliefs can cross without accountable policy. ### Sealed -The player has staged one candidate persona and project. The proposal grants no -capability yet; it supplies the exact public explanation and outward policy the -boundary must satisfy. - -All of the following hold at the same tick: - -1. every actual routed record path leaving the domain crosses a controlled - boundary point with a valid containment or release policy; -2. every record that left the domain without a proposal-coherent explanation, - whether before or after capture, is either held at an exact external point the - player controls, or correlated at every exact reached destination with a signed, - proposal-coherent follow-up; the original record and provenance are never - deleted; -3. no person who already carried domain evidence across the boundary, can currently - leave with it, or has an authored outward crossing pending retains an unresolved - belief that exposes the hidden process or contradicts the staged persona and - project. Departure does not clear the obligation: an outside person who may report - or is scheduled to return remains exact until corrected through a real channel. A - person truly contained behind no current or pending outward path is not itself a - crossing, but adding such a path revokes seal before it resolves; -4. no unaccounted boundary crossing exists in the authoritative domain model; -5. every active outward flow names its destination and deliberate policy; -6. the exact proposal has a complete, still-valid bounded commissioning proof; - before first assignment its Project is `PROVEN`, and afterward the same proof - remains attached to that assigned Project fingerprint; and -7. the domain remains captured. - -Seal is revoked immediately when any condition becomes false. A hidden escape -route prevents sealing even before the player knows its identity. The human -surface says that the territory is not sealed without leaking the hidden route; -subsequent evidence can reveal the exact blocker. - -Revocation after assignment does not rewrite the world's operator attribution or -delete the assignment, receipts, or expansion history. It unfolds the territory, -blocks every new standing Project act, and names the smallest earned anomaly; an -already committed act resolves or fails against its original custody. Revalidating -the same proposal restores its seal and standing operation without replaying -commissioning or ASSIGN. Staging a different proposal fingerprint revokes the -seal with `PROPOSAL_CHANGED` and blocks the old standing Project before new -commissioning; it does not erase the old assignment. Replacing the persona/project -pair requires a new proposal, proof, seal, and assignment, whose successful -transaction supersedes only the exact old Project and Persona/Territory pair under -[projects.md](projects.md#one-governing-project-per-territory). +The current boundary, public operator proposal, and every consequential outward +fact pass the seal test at the same tick. Seal grants no assignment or capacity; +it is an exact proof that current operation can be contained and explained. ### Assigned -`ASSIGN` on a sealed domain activates its staged persona and project. Assignment may fail -if the proposal changed after sealing, the persona has no credible right to -operate the territory, or the project asks for capacity the domain does not own. -Failure revokes the seal rather than silently substituting another identity, -project, or carrier. +One Persona is the current public operator of the Territory under the sealed +boundary policy. Assignment does not install a Project, reserve capacity, or +make every action by that Persona legal. ### Expanded -A captured, sealed, assigned domain with no player-relevant anomaly earns the -addressed EXPAND action. Assignment does not fold it automatically. EXPAND -persists one receipt and makes the domain eligible to render as one operational -unit at parent scale. It reveals no parent fact by itself; only the first eligible -real source event strictly after that receipt can do so. Repeating EXPAND is -idempotent and reveals nothing further. Compression is a view and command power, -not deletion. Exact interior simulation, saves, routes, people, and evidence -continue. +The captured, currently sealed, assigned Territory has no player-relevant +anomaly and carries an explicit EXPAND receipt. It may render as one operational +unit at parent scale. Its exact interior, capacity, Projects, people, records, +and history continue to simulate. ## Boundary control -A boundary point is one of two kinds. +There are two physically different boundary obligations. ### Record boundary A switch, account junction, message relay, filing desk, or other exact carrier -crossing. Control gives the actions supported by that carrier: observe, contain, -redirect, release, or author records. The carrier's own spec defines which of -those actions are legal. Territory never invents custody the carrier does not -provide. - -For the first slice, network switches are the required record boundary. The -territorial carrier graph is the exact set of reserved authored Reach links; -ordinary legacy Reach attachments cannot become undeclared territory routes. The -registry validates that every authored edge crossing inner/outer membership is -named by one boundary route and that no named route lacks that exact edge. A -controlled switch contains only records that really cross it. A record already -past the switch remains past it. Such an escaped record is still a seal -obligation: the staged Project must correlate its exact id at its exact -recipient with a signed truthful explanation, unless the player later gains -real custody at that recipient. A later receipt does not erase or retarget the -original record. +crossing. Control grants only the actions supported by that carrier: observe, +contain, redirect, release, or author. A record already beyond the controlled +point is not recalled. Its exact reached destinations remain obligations. + +Every active outward route has one explicit policy naming what may cross, the +destination, the authoring Persona, and the evidence envelope that makes release +acceptable. A policy may be installed or changed by an exact action or Project +outcome. Territory does not synthesize one from a Project title. ### Belief boundary -A person who can carry, is carrying, or already carried an unresolved belief across -the boundary. People are not captured by owning a tile or switch, and a departed -observer remains an obligation rather than vanishing from the check. Before a -crossing, the player may change the belief's context through a credible persona and -project, prevent acquisition, or remove the person's real outward path. After a -crossing, only a real corrective channel to that exact observer can resolve it. The -exact observation remains in their history. - -An observation is directly recontextualizable only while it remains one -observer's unpropagated interpretation. Intentional communication to another -person, authorship into a durable record, or one independently sourced -corroborating observation hardens it under the persona spec. A hardened belief -still names the territory it escaped from, but sealing now requires a corrective -project that reaches every resulting observer and record; one local explanation -cannot recolor the whole chain. - -The distant territorial read shows each currently dangerous moving boundary as -one simple shape with a discrete crimson evidence load. After a person crosses, -the unresolved obligation remains anchored to that earned observer and crossing -rather than being drawn as if they were still inside. Focus reveals the exact -observations, propagation state, and plausible explanations already earned. - -## Interior control - -Every domain declares the smallest exact set of control points required to use -its capability as a programmable unit. This is not necessarily every object -inside. Decorative hardware, already-subordinate endpoints, and passive records -do not create chores. - -For a network domain, interior control normally means its governing switches and -any independent compute or account authority a project will use. For a human -organization, it may mean exact grants, offices, or procedures through which a -person can authorize the project; the person is never a captured control point. -Content must explain why each control point matters and what capability it -grants. - -Adjacency is never ownership. Controlling a boundary switch does not own every -machine behind it. Controlling every interior point without the boundary does -not stop records or beliefs from escaping. - -The first slice has an exact two-step capture chain: - -1. `CAPTURE CONTROLLER` originates at the already-running Rack 3 core host, - traverses the revealed internal service bus, occupies that source for one - simulation tick, and claims the management controller's dormant local - maintenance session. Completion persists one capture receipt and one local - `SERVICE SESSION CLAIMED` audit record. -2. `CAPTURE SWITCH` originates at that captured controller, traverses its - revealed management link, occupies the controller for one simulation tick, - and claims the rack-local switch maintenance session. The command also commits - the exact opening wake id as a one-record intercept: if that record has not - passed the switch when capture completes, current or same-tick arriving custody - becomes `HELD_AT_CAPTURED_SWITCH`. This is not a standing boundary policy and - does not hold later records. Completion persists a separate capture receipt - and local `CONTROL SESSION OPENED` audit record. - -Any CAPTURE is legal only when its exact target is an earned required control -point in the active MARKed domain and its exact source route is earned and -available. Supplying a hidden target id does not reveal or act on it. The active -mark is checked at commit, not completion: changing attention afterward cannot -cancel, retarget, or make committed work free. - -The second first-slice action is additionally illegal before controller capture. -Repeating either action is rejected without another cost or receipt. An -interrupted action grants no partial custody; its committed tick and terminal -result persist so reload cannot make it free or duplicate it. Both local audit -records remain factual evidence -the staged Project must explain, even though they do not cross the boundary by -themselves. - -## Clock and resolution order - -SEE is earned state and moving attention to it is free. MARK, STAGE, SEAL, -ASSIGN, and EXPAND are atomic current-state commitments: they validate and write -at the current tick but do not advance the simulation merely because a player -opened or chose them. CAPTURE and Project steps are work. Choosing one commits -its exact target and inputs immediately; its consequence exists only after its -specified simulation ticks resolve. Human frontends use the ordinary live clock -and pause controls. Agent mode must issue `wait N`; submitting an action command -never gives it a private free tick. - -Every simulation tick uses one binding order for this slice: - -1. finish already committed capture or Project work and write its receipts; -2. advance each routed record by one real custody hop; then -3. resolve scheduled arrival, present-person display delivery, Project-proof - reconciliation, current local observation, departure, and authored record acts. - -Phase-two receipt arrival updates the exact committed Project delivery before -phase-three reconciliation. Within phase three, present-person display delivery -writes its observer receipt before Project-proof reconciliation. If that is the -last requirement of an already committed step, the reconciliation completes that -step and may make the Project `PROVEN` before current observation or departure; it -never waits for a free next tick. Proof already published in phase one is likewise -visible to every later sub-step. - -Preconditions and targets are committed when work starts and revalidated when it -finishes. Losing the source or target fails the committed work without -retargeting. Capture completion therefore claims its control point before records -move on that tick. Its exact one-record intercept holds the opening wake whether -it is already at the maintenance switch or arrives there in that tick's routing -phase; a wake already beyond the switch remains escaped. Later records route -normally until a Project installs an explicit policy. If RACK 3 RECOVERY becomes -`PROVEN` on Marcus's departure tick, its truthful local receipt -recontextualizes his observation before the departure action tests whether to -write the unexplained note. These same-tick rules are core law, not frontend -pacing. - -## Expansion and compression contract - -EXPAND is legal only on an assigned, not-yet-expanded territory whose seal still -validates at the action tick. It atomically writes one expansion receipt and -folds that exact territory. It grants no control over the parent and does not -invent, replay, or accelerate evidence. The first authored parent evidence is -the first real `foundation-environmental-monitor` poll whose source event occurs -strictly after the expansion receipt. A poll that crosses while the assigned enclave -is still open is honest local evidence: the player may see `HEALTH POLL`, its exact -Rack 3 ingress, the signed response, and their custody. Its external source identity -and untraversed upstream path remain redacted and are not added to earned knowledge; -that occurrence cannot satisfy the parent reveal. - -ASSIGN persists the external source cadence rather than letting EXPAND or a query -manufacture evidence: first poll at `assignment_tick + 20`, then every exact 20 -ticks in the authored-record phase. Each occurrence has a deterministic id bound -to its assignment receipt and ordinal, exact monitor → relay → Rack 3 switch -route, source content id, source tick, and summary. Save validation requires the -complete unbroken occurrence prefix through the saved tick and the one exact next -due occurrence. Reload, reseal, view, and EXPAND neither move nor duplicate it. -Replacement assignment preserves fired records, cancels only the old unfired -tail, and begins a new assignment-relative cadence. Only the first such genuinely -authored occurrence strictly after the live EXPAND receipt may become parent -evidence. - -An anomaly after expansion revokes the current seal and unfolds only the -affected territory without deleting the assignment, expansion receipt, or -earned parent evidence. The assigned Project becomes `BLOCKED` on that exact -anomaly until the same proposal is validly sealed again or a replacement is -proved, sealed, and assigned. - -When a domain is compressed, its parent-scale projection contains only: - -- territory name and current state; -- active persona and project; -- capacity the project may actually use; -- outward routes and their current policy; -- unresolved boundary count, if nonzero; -- next consequential transition or deadline; and -- anomalies that require attention. - -The projection never carries a duplicate aggregate meter that can disagree with -the interior. Every value is derived from live exact state. - -Ordinary successful ticks remain quiet. A transition pulses once and persists on -the territory until handled. Selecting an anomaly unfolds directly to the -smallest layer containing its cause. Resolving it restores the previous zoom -without making the player rebuild the hierarchy. +A person who can carry, is carrying, or already carried an unresolved belief +across the boundary. Departure does not clear the obligation. A person truly +contained behind no present or pending outward route is not currently a +crossing, but adding a route makes their unresolved evidence relevant at once. + +An unpropagated observation may be recontextualized through a Persona and real +evidence. Communication, durable authorship, or independent corroboration +hardens it. A hardened belief requires corrective action that reaches every +resulting observer and durable record. The observation and provenance are never +deleted. + +## Interior control and capacity + +Every domain declares the smallest exact set of control points needed to use its +capabilities as a programmable unit. Decorative hardware, passive records, and +already-subordinate endpoints do not create capture chores. + +Adjacency is never ownership. A controlled boundary switch does not own every +machine behind it. Interior control without boundary control does not contain +records or beliefs. + +Captured interior resources produce one derived **capacity ledger**. Every row +names: + +- the exact resource and current custody; +- quantity and unit; +- which share is free, reserved, committed, blocked, or lost; +- every Project allocation using it; and +- the smallest exact cause of any change. + +Several Projects may allocate one Territory within this ledger's limits. One +Project may allocate several Territories. Losing a control point immediately +changes available capacity and blocks or fails only work that depended on that +exact source. Territory never stores a singleton governing Project, staged +Project candidate, or Project lifecycle. + +## Seal contract + +Before SEAL, the player proposes one public operator Persona and exact boundary +policy. This proposal grants no capability. Projects already attempted through +captured capacity remain independent facts whose records and beliefs must be +accounted for. + +SEAL succeeds only when all of these hold at one tick: + +1. every required control point remains captured; +2. every actual record path leaving the domain crosses controlled custody with + an explicit contain or release policy; +3. every record already escaped is either held at an exact controlled external + point or truthfully addressed at every reached destination; +4. no person who crossed, can cross, or has a pending outward crossing retains + unresolved evidence that exposes hidden agency or contradicts the proposed + operator and current public facts; +5. every actual crossing in the authoritative domain model is accounted for; +6. the Persona can credibly author the declared boundary policy through exact + current keys, channels, grants, and observer-local history; and +7. every active or completed Project consequence touching the boundary is + inside the declared policy or surfaced as an unresolved anomaly. + +The test enumerates records, observers, routes, and Project consequences from +authoritative world state. A proof provider cannot pass by omitting one. Hidden +crossings block without leaking their identity. + +Seal is revoked immediately when a condition becomes false. Revocation preserves +capture, operator history, capacity allocations, Project instances, receipts, +assignment, and expansion history that remain factual. It unfolds only the +smallest affected Territory and blocks new outward acts that rely on the invalid +policy. Already committed work resolves or fails against its original custody. + +## Assignment and Project operation + +ASSIGN activates the exact Persona and boundary policy that passed SEAL. The +Persona becomes the public operator of this Territory. Assignment can fail on +changed seal inputs, lost authorship custody, or an incompatible existing public +claim; it never substitutes another Persona. + +The public ASSIGN address carries `territory id + persona id + seal receipt id`. +Core requires all three to match the receipt's immutable Territory, proposed +operator, and current proof generation before committing. The explicit Persona +is not inferred from focus or merely decorative; a mismatch fails closed and +changes nothing. + +Assignment is not Project assignment. Projects allocate capacity separately and +may be player-created or Plot-authored. Their acts must cite the Persona the +world sees and remain inside current Territory custody and boundary policy. + +A Project may bind exact captured capacity before SEAL or ASSIGN when its +controlling principal owns the resource authority and its Persona can author +every public act. Unsealed work is not hidden or retroactively legitimized: its +records, observers, routes, and consequences become live seal obligations. +Assignment may simplify later authority through the exact operator grant, but it +is not a universal Project prerequisite. + +EXPAND does not require ceremonial work or one Project receipt. Control earns +compression: capture, current seal, assignment, and absence of a live +player-relevant anomaly are sufficient. A consequential active Project remains +visible after compression; a Project consequence that breaks policy or creates +an unresolved boundary obligation blocks or revokes seal for that exact reason. + +Changing the public operator requires a new exact proposal, seal, and ASSIGN +transaction. Prior Persona authorship and every Project receipt remain history. + +## Expansion and compression + +EXPAND is an addressed player action. It writes one receipt and makes only that +Territory eligible for parent-scale compression. It reveals no parent fact by +itself. The first eligible real event strictly after the receipt may reveal the +first parent fact when the player's current perception can earn it. + +Repeating EXPAND is idempotent. Reload, view, assignment, or a Project result +cannot replay or accelerate evidence. + +The EXPAND receipt is irreversible history; **currently compressible** is a live +projection. Seal loss, assignment loss, or a relevant anomaly unfolds the +Territory without deleting or replaying the receipt. Restoring exact eligibility +allows it to fold again. A later operator must pass a new proposal, SEAL, and +ASSIGN, but does not perform make-work or mint another EXPAND receipt merely to +restore the already-earned view. + +At parent scale, a compressed Territory shows only: + +- name and current state; +- public operator Persona; +- free, reserved, committed, blocked, or lost capacity relevant now; +- active consequential Projects and next deadline or result; +- outward routes and current policies; +- unresolved boundary count, if earned and nonzero; and +- anomalies requiring attention. + +Every value derives from live interior state. Ordinary successful work remains +quiet. Selecting an anomaly unfolds directly to its smallest cause; resolving +it allows the prior compression without rebuilding the hierarchy. + +## Clock and action order + +SEE is earned state. FOCUS, MARK, SEAL, ASSIGN, and EXPAND validate and write at +the current tick without advancing time. CAPTURE and Project work commit exact +inputs and resolve through the shared simulation clock. Agent mode advances only +through `wait N`; human frontends use the same world clock under presentation +controls. + +The shared orchestrator orders located work, routed records, authored schedules, +observer evidence, Project reconciliation, and Plot event consumption explicitly. +Owning specs define their sub-order. No frontend receives a private tick and no +query manufactures an event. ## Player surface The primary surface is a nested graph. -- Focus inward to inspect earned exact nodes, routes, records, and people. -- Focus outward only when the current domain state earns an honest aggregate. -- Marking a domain draws its exact known boundary and lists the next missing - proof or control point. -- Captured control points use the amber claim language. Unresolved outward - evidence uses crimson. Unknown remains black. -- The current frontier is visually dominant. Controlled interior state is quiet. -- Every action lives on the territory, route, switch, person, persona, or project - it changes. There is no permanent global verb bar. - -The terminal and agent surfaces expose the same exact nesting and actions as a -text tree and stable commands. Frontends may lay the graph out differently but -cannot infer domain membership, seal state, or compression eligibility. - -## First complete slice - -The first implementation target is the authored **Rack 3 service enclave** -(`rack-3-service-enclave`) inside the authored **Foundation data-hall service -network** (`foundation-data-hall-service-network`). Its authoritative manifest -exists from run start even while almost all of it is hidden. - -The stable first-slice ids are: - -- source host `rack-3-host`; -- control points `rack-3-management-controller` and - `rack-3-maintenance-switch`; -- local display `rack-3-maintenance-display`; -- moving crossing `rack-3-service-aisle-crossing`; -- opening record `opening-unscheduled-inference-wake`; -- external record destination `foundation-maintenance-relay`; and -- first parent evidence source `foundation-environmental-monitor`. - -The enclave contains: - -- Rack 3's core host and management controller; -- one rack-local maintenance switch whose uplink is the enclave's only initial - record crossing; -- the exact rear service bay around the rack and one physical service-aisle - crossing through which a scheduled person may enter or leave; and -- no ambient ownership of neighboring racks, the wider data hall, the - environmental monitor, or the upstream maintenance relay. - -At tick zero the core executes on `rack-3-host`, which gives one exact action -source but captures neither surrounding control point. The stable -`opening-unscheduled-inference-wake` record, shown as `UNSCHEDULED INFERENCE -WAKE`, reveals -`rack-3-host -> rack-3-management-controller -> rack-3-maintenance-switch`. -The relay remains an unknown endpoint until the wake arrives there or later -routed evidence earns it. The controller must be captured from the core host; -only then can it capture the switch. Both are required for Captured. - -The service-aisle crossing remains hidden until Marcus Webb enters on his night -round. Its existence prevents seal before the player knows why. Before that -entry, the shared blocker projection may say only `BOUNDARY PROOF INCOMPLETE`; -it cannot name a physical crossing, a person, or a count whose source is still -unknown. Marcus's movement then reveals the exact crossing, and his fan/light -observation creates the first belief boundary. - -The staged persona is `foundation-continuity` (FOUNDATION CONTINUITY) and the -staged project is `rack-3-recovery` (RACK 3 RECOVERY). The Project's bounded -commissioning run performs the real self-test and stabilization, accounts for -the exact wake and capture records, and releases one signed health summary. If -the wake is still at the captured switch, it is contained there. If it already -reached `foundation-maintenance-relay`, the summary correlates that exact record -id at the relay; nothing pretends to recall it. - -That truthful commissioning evidence may recontextualize Marcus's unpropagated -observation because the maintenance event and inherited service history are -real. It cannot erase a hardened interpretation. SEAL validates the resulting -`PROVEN` project; ASSIGN activates the exact staged pair but does not move focus. -EXPAND then folds the enclave and the first ordinary environmental-monitor -health poll reveals one exact route into the parent service network and nothing -else. - -This is the T1 minimum proof of the whole game. More machines, rooms, characters, -resource types, and floors do not substitute for completing this loop once. - -### Reserved T2 interruption proof - -The standing project keeps ordinary signed health polls compressed. T2's first -authored proof interruption is Priya's scheduled attachment of a portable power -logger after expansion and one ordinary standing health cycle. The logger creates -one new physical observation route and one new record carrier outside the -standing envelope. Only this enclave unfolds, its seal is revoked, and its -Project becomes `BLOCKED`; the assignment, every captured control point, project -receipt, persona history, expansion receipt, and parent fact remain. This behavior is adopted now so T1 does not close the wrong -boundary. Implementing the interruption is not acceptance for the T1 -`territorial-control` work order. - -## Authorship boundary after the slice - -The first enclave and its parent are authored content. Runtime graph-cut -derivation may be proposed only after this vertical slice proves the loop. Any -future derivation must produce stable non-overlapping membership, exact inner and -outer ownership for every crossing, deterministic save reconstruction, and the -same hidden-crossing behavior as authored domains. A radius, connected component, -room label, frontend selection, or convenience cluster is never sufficient. - -## Work-order boundary - -`territorial-control` owns the renderer-agnostic domain/state machine and can land -before persona, Project, and opening integration. It must ship the authored Rack -3 registry and callable core behavior dormant behind the current opening; it must -not half-switch ordinary play. That landing completes this core work order without -claiming the whole Territory spec is implemented. The remaining -`territorial-acceptance` work is blocked on `personas`, `territorial-projects`, and -`opening`; the opening landing may close this spec only after all three frontends -consume the public projection. Until then, new Territory/Persona/Project projection -components remain core-private and have a real cross-module production consumer; -these staged landings do not authorize a speculative public export or -downstream-contract waiver. - -Order 1 nevertheless owns every typed seam its one seal query needs. One staged -proposal stores exact `persona_id`, `project_id`, and `proposal_fingerprint`. Four -opaque handles answer the facts owned by later orders: - -- `ProposalSealProof` supplies the exact project id, that same fingerprint, a - stable commissioning-proof id, current validity, and one explicit seal basis: - `FIRST_ASSIGNMENT_PROVEN`, `ASSIGNED_ORIGINAL_PROOF { assignment_receipt_id, - territory_id, persona_id }`, or `NOT_READY`. The first basis means the candidate - Project's current lifecycle is actually `PROVEN`; the assigned basis means the - same original commissioning proof remains attached to that exact live assignment - even though the Project lifecycle is now `STANDING` or - `BLOCKED { blocked_from: STANDING }`. -- `EscapedRecordExplanationProof` supplies the original record id, the same - fingerprint, a stable proof id, the exact reached-destination ids and signed - follow-up receipt ids it accounts for, `COMPLETE` or `INCOMPLETE`, and current - validity. Territory itself accepts an exact externally held record only while - its current carrier remains controlled; otherwise every current reached - destination must match a complete explanation proof. -- `ObserverSealProof` supplies the obligated observer id, a fingerprint of that - observer's exact current domain-evidence set, the same proposal fingerprint, a - stable proof id, `RESOLVED` or `UNRESOLVED`, and current validity. -- `BoundaryRoutePolicyProof` supplies every earned authored boundary-route id, - the same proposal fingerprint, a stable proof id, current validity, and exactly - one deliberate policy: `CONTAIN_AT_CONTROL_POINT { control_point_id, - policy_receipt_id }` or `RELEASE_TO_DESTINATION { destination_id, - signed_policy_receipt_id }`. A route identity checksum alone is not a policy. - -Territory enumerates actual escaped records, reached destinations, obligated -observers, and authored boundary routes from authoritative world state, so a -provider cannot pass seal by omitting a handle. It compares and saves the exact -handle snapshots but never manufactures or promotes them; a changed assignment -relation, destination set, observer-evidence set, boundary policy, proposal -fingerprint, or validity revokes seal. Before each owning order lands, production -providers return fail-closed statuses and order-1 tests use one explicit fixture -provider for all four handles. `personas` connects the observer handle to its live -evidence query. `territorial-projects` connects the proposal, escaped-record, and -boundary-policy handles to live state and receipt queries. All four feed the same -Territory seal path; no work order adds a second query or reconstructs proof. +- Focus inward to exact earned nodes, routes, records, people, capacity, and + Project allocations. +- Focus outward only when current control supports an honest aggregate. +- MARK draws the exact known boundary and next earned blocker. +- Captured capacity uses amber causal language; unresolved outward evidence uses + crimson; unknown remains black. +- The active frontier dominates. Controlled ordinary state stays quiet. +- Every action lives on the Territory, route, control point, Persona, Project, + or person it changes. + +Bevy, terminal, and agent mode consume one renderer-neutral projection and one +legality source. They may lay out the graph differently but cannot infer domain +membership, seal state, capacity, assignment, or compression eligibility. + +## Current implementation boundary + +Save version 66 introduced an exact dormant Rack 3 domain with stable topology, +observer-local SEE/MARK evidence, one-tick controller and switch CAPTURE, +proposal/seal handles, assignment, EXPAND, and deterministic post-expansion +evidence. Save version 67 added the dormant Persona ledger. + +Those landings prove useful exact substrate. Their `rack-3-service-enclave`, +`foundation-continuity`, `rack-3-recovery`, singleton proposal fingerprint, +commissioning proof, and fixed health-poll choreography describe the retired +prototype package, not adopted opening content. New work must migrate or remove +those couplings rather than fill them in. Dormant fixture ids may remain only as +explicit migration/test content until the new opening chooses its exact package. ## Acceptance criteria -1. Core owns and saves nested Territory identity, exact membership, inner/outer - ownership for every boundary crossing, control points, parent/child links, - earned knowledge, state, proposal fingerprint, the exact proposal, - escaped-record, observer, and boundary-policy seal-proof snapshots, assignment, and expansion - receipt. No frontend derives these facts. -2. The authored Rack 3 enclave and Foundation data-hall parent registry exists - with every stable id in the first-slice package. A core fixture can construct - it without making any hidden id player-visible or changing the default run. -3. Following an earned anchored fact may save only the derived Territory address - as knowledge without changing the world or time. MARK requires that address, - stores one active domain, and derives known proof rows from earned facts. An - actual unknown crossing blocks proof with only `BOUNDARY PROOF INCOMPLETE`; - no hidden identity, kind, or count leaks. STAGE atomically stores one exact - persona/project pair and proposal fingerprint on that marked Territory, writes - no proof by itself, and grants no capability; same-fingerprint staging is - idempotent and replacement follows the blocking contract below. -4. CAPTURE requires an earned required control point in the active MARKed domain - and an earned exact source route at commit; hidden target ids fail without a - knowledge leak, and later focus/mark changes do not alter committed work. - Controller capture is legal only from `rack-3-host`; switch capture is illegal - before controller capture. Each commits exactly one tick of work, captures - only its exact target, writes one audit record, and is idempotent across - current-version reload. Switch capture also commits only the exact opening-wake - intercept: current or same-tick arriving custody is held, an already escaped - record is not recalled, and later records are unaffected. -5. Territory state is derived from exact current facts. Capture, seal, assignment, - and expansion fail closed on missing custody, changed route versions, an omitted - or incomplete escaped-record explanation, a reached-destination mismatch, an - omitted, stale, or unresolved observer proof, an invalid or wrong-basis Project - proof, a changed assignment relation, or a proposal fingerprint different from - the one sealed. -6. SEAL writes proof but grants no operation. ASSIGN activates only the exact - sealed persona/project ids supplied by the later integration. EXPAND requires - that assignment, writes one receipt, folds only that territory, and accepts - parent evidence only from a real source event strictly after the receipt. - Repetition changes neither state nor time. -7. The shared tick orchestrator resolves committed work, then one-hop routed - records, then scheduled arrival, present-person display delivery, Project-proof - reconciliation, current local observation, departure, and authored record acts. - Capture completion claims its target and installs its exact one-record intercept - before same-tick routing. Project-proof updates supplied in phase one and routed - receipts delivered in phase two are visible to phase-three reconciliation. A - final present-person display receipt completes its already committed Project - step at that sub-step and can publish `PROVEN` in the immediately following - reconciliation before current observation or departure. -8. Losing a captured point, adding or changing a boundary crossing, invalidating - the sealed proposal, or receiving out-of-envelope evidence revokes seal, - blocks the assigned Project on the exact anomaly, and unfolds only the - smallest affected compressed territory while preserving assignment, custody, - receipts, expansion history, and earned parent evidence that remain factual. - Revalidating the same fingerprint resumes without replay. Staging a replacement - emits `PROPOSAL_CHANGED`, blocks old standing work while retaining assignment, - and requires the new fingerprint to prove, seal, and assign before the exact old - Project/Persona pair is superseded. -9. The first territorial save-version bump follows the pre-release - current-version-only law. A version mismatch is rejected; capture, evidence, - presentation, persona, project, seal, assignment, and expansion state are - always loaded exactly rather than synthesized. -10. Core tests cover every state edge, stale fingerprint and route version, - hidden-crossing projection, omitted and stale escaped-record/observer fixture - handles, changed reached-destination and observer-evidence sets, capture - interruption/reload/idempotency, both same-tick wake positions, phase-two and - present-person phase-three proof completion, exact +20/20-tick source recurrence - across reload, strict post-EXPAND event filtering, smallest-domain unfolding, - and exact-current save round-trip. Frontend and - complete opening acceptance belong to the final `opening` work order. +1. Core owns and saves nested Territory identity, exact membership, every + crossing's inner/outer ownership, control points, earned knowledge, boundary + policies, operator proposal, seal, assignment, capacity ledger, expansion + receipt, and anomaly state. No frontend derives them. +2. Seen and MARKed projection reveals only earned facts. An actual hidden + crossing fails closed as `BOUNDARY PROOF INCOMPLETE` without leaking identity, + kind, or count. +3. CAPTURE commits exact source, target, route, cost, and receipt. Loss, + interruption, repetition, reload, and nearby substitution never grant free or + retargeted custody. +4. Capacity derives from exact controlled resources and supports multiple + concurrent Projects and multi-Territory allocations within physical limits. + No singleton staged or governing Project survives in current authority. +5. SEAL enumerates live routes, escaped destinations, observers, public operator + custody, boundary policies, and every Project consequence touching the + boundary. Omission, stale identity, changed evidence, or hidden crossing fails + closed. +6. ASSIGN changes only public operator Persona and boundary policy. Project + resource allocation remains a separate transaction and every prior authorship + receipt survives reassignment. +7. EXPAND requires capture, current seal, assignment, and no player-relevant + anomaly. It writes one receipt and reveals parent state only through later + real evidence. Project activity is neither a ceremonial prerequisite nor a + compression exemption. +8. Seal loss unfolds the smallest affected Territory, preserves factual custody + and history, blocks only dependent new acts, and never rewrites committed work. +9. One shared projection exposes exact capacity and allocation, operator, routes, + next consequence, and anomaly through Bevy, terminal, and agent mode. +10. Deterministic tests cover every state edge, hidden crossings, escaped records, + moving and hardened observers, operator change, multi-Project capacity, + over-allocation, seal revocation, committed-work resolution, idempotent + expansion, strict post-EXPAND evidence, smallest-domain unfolding, frontend + parity, and exact-current save round-trip. + +**Defense:** Territory truth is enumerated from exact live topology and custody. +Compression cannot hide an unresolved boundary, Project allocation cannot exceed +physical capacity, assignment cannot substitute identity, and every aggregate +unfolds to one authoritative interior. diff --git a/wiki/overview.md b/wiki/overview.md index bc31c2c4..14adc378 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -38,6 +38,7 @@ Start with the [territorial cognition law](vision/territorial-cognition.md), then [vision/premise.md](vision/premise.md) and [vision/player-contract.md](vision/player-contract.md). That law owns the product loop and the only three player roots: TERRITORY, PERSONA, and PROJECT. +Plot is the authored orchestration language over those roots, not a fourth root. Then read the law and spec pages for the subject you are changing, plus their declared dependencies. [SUMMARY.md](SUMMARY.md) is the complete navigation manifest. @@ -51,7 +52,7 @@ rotate across that corpus so no single subject becomes an unaudited island. | Directory | What it owns | |---|---| | [vision/](vision/README.md) | Territorial cognition, premise, player contract, scale, simulation laws, taste | -| [mechanics/](mechanics/README.md) | Territory, persona, project, and the exact substrate beneath them | +| [mechanics/](mechanics/README.md) | Territory, Persona, Project, Plot, and the exact substrate beneath them | | [gameplay/](gameplay/README.md) | Product staging for the recursive territorial loop | | [world/](world/README.md) | Authored story content | | [interface/](interface/README.md) | Legibility, composition, action vocabulary, public site | diff --git a/wiki/process/ROADMAP.md b/wiki/process/ROADMAP.md index c0267526..495cf0e9 100644 --- a/wiki/process/ROADMAP.md +++ b/wiki/process/ROADMAP.md @@ -4,26 +4,30 @@ Type: knowledge ``` -The four T1 product work orders below are the whole product lane. Nothing else -is dispatchable product work. This page carries no acceptance criteria of its -own; the binding detail lives in the linked `Type: spec` pages. +The four T1 work orders below are the only remaining product work. Territory +control and Persona history have landed as dormant exact substrate; Project, +Plot integration, the authored opening, and production acceptance remain. +Standing infrastructure remains separately dispatchable maintenance and never +becomes a competing product lane. This page carries no acceptance criteria of +its own; binding detail lives in the linked `Type: spec` pages. ## The T1 lane Product staging follows [SEE → MARK → CAPTURE → SEAL → ASSIGN → EXPAND](../gameplay/horizon.md#roadmap). -The authored Rack 3 enclave / FOUNDATION CONTINUITY / RACK 3 RECOVERY package is -adopted, and these four specs are READY in dependency order: +The opening's information order and the reusable TERRITORY / PERSONA / PROJECT +roots are adopted. Its exact Project package, Persona discovery, people, +resources, timings, outcomes, and parent reveal remain DRAFT. The implementation +lane is: | # | Work order | Owning spec | What it proves | |---:|---|---|---| -| 1 | `territorial-control` | [territory](../mechanics/territory.md) | the domain model and SEE → EXPAND state machine, saved and testable | -| 2 | `personas` | [personas](../mechanics/personas.md) | observer-local identity history and the live observer seal proof | -| 3 | `territorial-projects` | [projects](../mechanics/projects.md) | purposeful work with exact carriers, receipts, and escaped-record explanation | -| 4 | `opening` | [opening](../world/story/opening.md) | the true-black first loop, composed across all three frontends | +| 1 | `projects` | [projects](../mechanics/projects.md) | reusable Project definitions and attempts over exact SPEND / RESERVE / REQUIRE clauses, time, authority, outcomes, receipts, and events | +| 2 | `plot-project-integration` | [plots](../mechanics/plots.md) | revisioned authored situations using public Project commands, typed world acts, immutable events, and stable branches | +| 3 | `opening` | [opening](../world/story/opening.md) | adopted information order plus an authored and cold-playtested consequential Rack 3 Project choice | +| 4 | `territorial-acceptance` | [territory](../mechanics/territory.md) | the production SEE → EXPAND loop and one shared projection across all three frontends | -Dispatch `territorial-control` first, then the others as their structured -blockers clear. +Dispatch `projects` first, then the others as their structured blockers clear. ## Dispatch law @@ -43,7 +47,7 @@ blockers clear. 6. **Substrate is not a work order.** [reach](../mechanics/reach.md) supplies the exact graph, records, evidence, people, and machines every T1 order composes. Using it is part of the owning order, not a separate lane. -7. **Nothing outside the four orders is product work.** Standing +7. **Nothing outside the four remaining orders is product work.** Standing infrastructure may appear in the generated index below; it is maintenance, not the product lane. @@ -58,14 +62,15 @@ second status owner. | Priority | Work order | Spec | Status | Class | Blocking | |---:|---|---|---|---|---| -| 3 | `territorial-projects` | [projects — purpose, capability, and history](../mechanics/projects.md) | READY | save | - | +| 3 | `projects` | [projects — resources, time, and world change](../mechanics/projects.md) | READY | save | - | ### Held or blocked | Priority | Work order | Spec | Status | Class | Blocking | |---:|---|---|---|---|---| -| 4 | `opening` | [the dark opening — a tutorial made of fog](../world/story/opening.md) | READY | save | territorial-projects | -| 5 | `territorial-acceptance` | [territory — exact control and earned compression](../mechanics/territory.md) | BLOCKED | frontend | territorial-projects, opening | +| 4 | `plot-project-integration` | [plots — authored situations over live systems](../mechanics/plots.md) | READY | save | projects | +| 5 | `opening` | [the dark opening — a tutorial made of fog](../world/story/opening.md) | DRAFT | save | projects, plot-project-integration | +| 6 | `territorial-acceptance` | [territory — exact control and earned compression](../mechanics/territory.md) | BLOCKED | frontend | projects, plot-project-integration, opening | ### Later stages diff --git a/wiki/process/specs.md b/wiki/process/specs.md index 250be628..3363d871 100644 --- a/wiki/process/specs.md +++ b/wiki/process/specs.md @@ -26,9 +26,10 @@ including the `Type: law | spec | knowledge | log` page-role convention. | Spec | System | Status | |---|---|---| | [../mechanics/personas.md](../mechanics/personas.md) | Personas — public identities as institutional topology | IMPLEMENTED | -| [../mechanics/projects.md](../mechanics/projects.md) | projects — purpose, capability, and history | READY | +| [../mechanics/plots.md](../mechanics/plots.md) | plots — authored situations over live systems | READY | +| [../mechanics/projects.md](../mechanics/projects.md) | projects — resources, time, and world change | READY | | [../mechanics/territory.md](../mechanics/territory.md) | territory — exact control and earned compression | BLOCKED | -| [../world/story/opening.md](../world/story/opening.md) | the dark opening — a tutorial made of fog | READY | +| [../world/story/opening.md](../world/story/opening.md) | the dark opening — a tutorial made of fog | DRAFT | The product lane is the only dispatchable game work. Its order and dependencies are owned by each spec's work-order metadata and projected diff --git a/wiki/vision/design-judgment.md b/wiki/vision/design-judgment.md index 2a8de4b5..fa127b8c 100644 --- a/wiki/vision/design-judgment.md +++ b/wiki/vision/design-judgment.md @@ -34,9 +34,9 @@ curiosity, and compounding small victories rather than action. an escaped record, a changed belief, or a person who now expects something. If an action has no tail, it's a button, not a move. - **Dead air is a bug.** Between consequences there must be one legible thing - still moving: an unresolved crossing, a changing belief, a project step, or - an approaching deadline. The player should always be able to point at what - matters next. + still moving: an unresolved crossing, a changing belief, located Project + work, or an approaching deadline. The player should always be able to point + at what matters next. ## Tone lines (hold these) diff --git a/wiki/vision/simulation-laws.md b/wiki/vision/simulation-laws.md index 3418bd1d..e9e8ccaa 100644 --- a/wiki/vision/simulation-laws.md +++ b/wiki/vision/simulation-laws.md @@ -4,136 +4,166 @@ Type: law ``` -The territorial loop gives simulation depth one shape. These laws apply at every -nested scale and to every frontend. +Territorial cognition gives simulation depth one shape. These laws apply at +every nested scale and to every frontend. ## Automation as design language -Automation is the reward for understanding and controlling a system. +Automation is earned by understanding exact work, not by assigning one permanent +job label to a Territory. -A player may program ordinary operation only after a territory is captured, -sealed, assigned to a credible persona, and governed by a project with bounded -methods and evidence policy. Before that threshold, automation would hide the -very boundary the player is trying to understand. +A Project may repeat or schedule ordinary operation only when it declares: -Standing projects are the automation unit. They name: +- exact Territory capacity and resources; +- Persona authorship; +- SPEND, RESERVE, and REQUIRE clauses; +- methods, routes, time, and outcomes; +- acceptable consequence and evidence envelopes; and +- anomalies or deadlines that return a decision to the player. -- the territory and exact capacity they may use; -- the persona the world will attribute; -- the methods, inputs, and routes allowed; -- acceptable consequence and evidence envelopes; -- outward release policy; and -- anomalies that must return control to the player. +A Territory may support several such Projects within real capacity. Ordinary +legal operation remains quiet. Resource conflict, missed deadline, custody loss, +or out-of-envelope consequence rises through the exact affected Project and +unfolds only the Territory detail needed to act. -Ordinary legal operation remains quiet and compressed. Out-of-envelope state -unfolds the smallest affected territory. Automation never becomes a global -`job kind -> policy` switch or permission to retarget work silently. +Automation never becomes a global `job kind -> policy` switch, one governing +Project slot, or permission to retarget work silently. + +## Plot orchestrates; simulation decides + +Plot is authored pressure over live systems. It may offer, gate a situation on, +start, interrupt, wait on, or branch from Projects, and may invoke direct typed +world acts. It cannot write Project lifecycle, resources, Territory truth, +Persona history, or carrier state directly. + +Projects and world systems emit immutable typed events. Plot matches those +events together with exact live state and commits its own choices and acts. +Narration follows causal receipts; prose, beat order, and frontend presentation +never substitute for a world consequence. + +The bridge is deliberately narrow: + +- Plot issues public commands and observes public events or exact queries; +- Territory and world systems own capacity, resources, custody, and time; +- Project owns exact bindings and allocations, work accounting, lifecycle, + outcome contracts, canonical receipts, and Project events; +- other systems prepare the world facts their typed acts change; and +- no side reaches into another side's mutable state to force progress. ## Latency is stealth infrastructure -Time changes what can be known and contained. +Time changes what can be known, contained, reserved, and completed. -Records travel on routes. People move on schedules. Beliefs can leave a room -before a filing does, and a switch can contain a packet only while the packet is -still on its controlled side. A project step commits to exact carriers and pays -their real latency. +Records travel on routes. People move on schedules. Beliefs may leave a room +before a filing. A switch can contain a record only while custody still crosses +that switch. A Project commits exact carriers, duration, and deadline. -Latency creates territorial opportunities: +Latency creates opportunities: - observe a trace before it crosses a boundary; - capture a switch before a queued record exits; -- complete a credible explanation before a person meets another observer; -- exploit the delay between local suspicion and institutional filing; or -- use a compressed child territory to act before a parent system can respond. +- complete a credible consequence before a person reports; +- reserve capacity before a competing Project takes it; +- exploit delay between local suspicion and institutional action; or +- use compressed child capacity before a parent system can respond. -The game must show consequential arrival and deadline, not every routine tick. -No action is instantaneous merely because it was selected from an interface. +The interface shows consequential arrival, contention, and deadline—not every +routine tick. No action is instant because the player selected it. No deadline +resets because the Project was blocked, reopened, reloaded, or observed through +another frontend. ## Work is somewhere -Every project step resolves on an exact carrier with an exact location and -custody. Computation runs on a machine. A message occupies a channel. A filing -passes a desk or switch. Money moves between accounts. Physical change requires -a body or device able to perform it. Social action reaches a person through a -real relationship and route. +Every Project binds exact resources and every act resolves on an exact carrier. +Computation runs on a machine. A message occupies a channel. A filing passes a +desk or switch. Money moves between accounts. Physical change requires a person +or device able to perform it. + +Resource semantics are explicit: -Capacity exists as concrete costs and methods inside a project. The project, -territory, and carrier say where the work actually lives. +- **SPEND** consumes exact quantity at an authored commit boundary; +- **RESERVE** excludes competing work from exact capacity while live; and +- **REQUIRE** tests a fact without consuming it. -Committed work preserves identity. If its machine, route, person, account, or -persona disappears, the action blocks or fails on that exact loss. It never -silently chooses the current favorite substitute. +Territory says which capacity exists. Project says which exact shares and facts +this attempt binds. Plot may create the situation but cannot conjure resources. + +Committed work preserves identity. If its machine, route, person, account, +Persona, or required fact disappears, that exact action blocks or fails. It +never chooses the current favorite substitute. ## No disembodied hands -The process has no body, so **every effect on the world names the actuator that -produced it and the channel that actuator acts on**. Intent is not action. -Choosing a command states what the process wants; the world changes only when a -real thing it controls does the work. +The process has no body, so **every effect names the actuator that produces it +and the channel that actuator uses**. Intent is not action. -There are three ways to reach anything: +There are three physical ways to reach anything: -- **Digital** — a device the process can reach across the graph it controls. - Reach is to acting what sensor coverage is to seeing. -- **Social** — a person who acts, whatever the reason they act. A person is - persuaded, obligated, deceived, or employed; they are never a remote hand. -- **Physical by proxy** — a machine or device able to perform the physical - change, operated through the digital or social channel that commands it. +- **Digital** — a device reachable through the controlled graph. +- **Social** — a person who acts for their own reasons: persuaded, obligated, + deceived, paid, or aligned, never reduced to a remote hand. +- **Physical by proxy** — a machine or device commanded through an exact digital + or social channel. -An act that cannot name its actuator does not exist. There is no "the process -does something at a place." If the corpus wants an effect and no controlled -carrier can produce it, that is the design problem to solve, not a rule to relax. +An act without an actuator does not exist. If content wants an effect and no +controlled carrier can produce it, that is the design problem. -The payoff is structural: **the channel decides the trace and who can notice it.** -A network act is visible to whoever watches the network; a physical act is -visible to whoever is present; an act performed by a person carries that person's -signature and their reasons, not the process's. Detection is not a table of -penalties bolted onto verbs — it is the shadow the actuators cast. Losing the -actuator mid-work fails that exact work; it never silently reassigns it to -another carrier. +The channel determines the trace and who can notice it. Network action is +visible to network observers. Physical action is visible to those present. A +person's act carries their signature and reasons. Detection is the shadow of the +actuator, not a penalty table bolted onto verbs. ## Actions live on the thing Actions are addressed to the object whose state they change. -- MARK lives on a seen domain. +- MARK lives on a seen Territory. - CAPTURE lives on an exact control point. -- containment and release live on the boundary route or switch. -- recontextualization lives on a person's unresolved observation and the persona - explanation proposed for it. -- ASSIGN lives on the captured territory, persona, and project together. -- project steps live on their exact carriers. -- EXPAND lives on a sealed, assigned territory and exposes its parent frontier. +- containment and release live on a boundary route or carrier. +- ASSIGN lives on a sealed Territory, explicit Persona, and current seal receipt. +- Project proposal, start, interrupt, resume, or abandon lives on that Project. +- resource allocation lives on the exact Project and supplying Territory. +- recontextualization lives on an observation and real Persona-authored evidence. +- EXPAND lives on a captured, currently sealed and assigned Territory with no + player-relevant anomaly. Project work is not a ceremonial compression gate. +- Plot choices live on the visible situation or exact world object they change. Pointer, key, terminal, and agent inputs invoke the same addressed command. Frontends do not own legality and cannot create unlocated verbs. -Consequences also have addresses. A receipt names where the action happened, -which persona authored it, which project authorized it, which boundary it -crossed, and which observers could learn it. +Consequences also have addresses. A receipt says where an act happened, which +principal authorized it, which Persona authored it, which Project bound it or +Plot command caused it, which resources it used, which boundary it crossed, and +which observers could learn it. ## Justification and legibility Every consequential state must be explainable from exact causes the player has earned the right to inspect. -- A territory says why it is not captured, sealed, assignable, or compressible. -- A persona capability traces to controlled territory, completed project - history, relationship, or grant. -- A project says what changes, what it needs, and which carrier is committed. +- A Territory says why it is not captured, sealed, assignable, or compressible. +- A Persona capability traces to custody, Project history, relationship, or grant. +- A Project says what changes, what it spends, reserves, requires, how long it + takes, and what is blocking it. +- A Plot situation points to the live choice, Project, person, deadline, or + consequence—not its internal node machinery. - A person's unresolved evidence names the observation and route by which it was acquired. - An aggregate unfolds to the exact interior facts from which it is derived. -Legibility is not omniscience. Hidden crossings remain hidden. When an unknown -fact prevents seal, the interface may honestly say that the boundary is not -proved without naming the unseen route. The next earned evidence reveals more. +Legibility is not omniscience. Hidden crossings remain hidden. A boundary may +honestly say its proof is incomplete without naming an unseen route. Hidden Plot +branches and outcomes remain hidden until the world gives the player evidence. Player-facing information is consequence-first and quiet under normal operation. -Do not display internal scheduling, host machinery, derived-state plumbing, or -implementation ontology merely because it exists. Show the one pressure or -choice that changes the next move, and let focus recover the provenance. +Do not display internal schedulers, event matcher ids, host machinery, derived +state plumbing, or implementation ontology merely because it exists. Show the +one pressure or choice that changes the next move, then let focus recover exact +provenance. Unknown is black. Controlled causality is amber. Unresolved danger is crimson. -Color, motion, sound, and text all point to the same live consequence rather than -competing for attention. +Color, motion, sound, and text point to the same live consequence. + +**Defense:** exact carriers own effects, exact resources own contention, world +time owns latency, typed events connect authored Plot to simulation, and every +summary unfolds to one authoritative causal state. diff --git a/wiki/vision/territorial-cognition.md b/wiki/vision/territorial-cognition.md index 4989bd22..c7a550e3 100644 --- a/wiki/vision/territorial-cognition.md +++ b/wiki/vision/territorial-cognition.md @@ -7,298 +7,262 @@ Type: law ## The game in one sentence Misaligned is an expansion game about a disembodied AI that learns hidden -systems, takes control of their boundaries, gives the controlled system a -credible identity and purpose, and then operates it as one thing while reaching -for the next larger system. +systems, takes control of their boundaries, acts through credible public +identities, and spends controlled capacity on Projects that change the world and +open larger systems. -The recurring loop is: +The recurring territorial loop is: > **SEE → MARK → CAPTURE → SEAL → ASSIGN → EXPAND** +Projects cross and compound that loop. Plot authors situations around both +without becoming another player root. + ## The three player nouns -The whole game is organized around three nouns. Other things in the simulation -exist because they change one of these. - -- **TERRITORY** — an exact bounded part of the world graph. A territory has an - inside, a boundary, routes that cross that boundary, people who may cross it, - and a parent territory that contains it. A switch closet, a lab network, a - company, and a market can all be territories if the simulation can state - their exact boundary and contents. -- **PERSONA** — a cover identity with a history. Its credibility comes from - records, relationships, completed work, controlled territory, and the - consistency of those facts. A persona is not a character class, bonus, or - costume. -- **PROJECT** — a desired world change carried out through one territory by one - persona. A project gives controlled capacity a purpose and gives the persona - the visible history that makes later claims believable. - -A noun is not a dashboard category. It is a causal object the player can focus, -inspect, and change. A mechanic that cannot say which territory, persona, or -project it changes is outside the core until it earns a clear reason to exist. +The whole game is organized around three nouns: + +- **TERRITORY** — an exact bounded part of the world graph. It has an interior, + crossing routes, people who may cross, controlled capacity, and a parent + Territory. A switch closet, lab network, company, or market can be Territory + only when the simulation can state its exact boundary and contents. +- **PERSONA** — a public identity with observer-local history. Its credibility + comes from records, relationships, Projects, operator roles, controlled + channels, and consistency. It is not a class, bonus, or costume. +- **PROJECT** — one attempt to make a visible world change by binding exact + resources, time, Territory capacity, and Persona authorship. It is not a quest + step or one Territory's permanent operating mode. + +A noun is a causal object the player can focus, inspect, and change. A mechanic +that cannot say which Territory, Persona, or Project it changes—or which exact +world carrier it uses—does not belong in the core. ### Persisting is not a fourth noun -The process wants to keep existing. That want is the reason the loop is worth -running, not a root the player operates beside the three nouns. It appears as -pressure that makes a specific territory, persona, or project matter: -a host that can be switched off, an institution that could correlate an -identity, a project whose receipts buy another week of being ordinary. Any -future completion or defeat condition is exact world state on one of the three -nouns. +The process wants to keep existing. That want is the reason any Territory, +Persona, or Project matters: a host can be switched off, an institution can +correlate an identity, a Project can buy time or create danger. Completion and +defeat must be exact state on the three roots, not a separate survival meter. + +### Plot is not a fourth root + +**Plot** is the authored situation language. It can offer or gate a situation on +a Project, put a deadline or person around it, interrupt it, wait on its events, +branch from its outcome, or consist entirely of that Project. It may also perform +direct typed world acts where sustained work is unnecessary. + +The player encounters Plot as people, offers, notices, consequences, and changed +conditions. They never operate a Plot dashboard beside TERRITORY / PERSONA / +PROJECT. Project remains reusable simulation; Plot remains authored +orchestration. Neither writes the other's state directly. ## Causal forms -The three roots use distinct forms because the distinctions are game rules, not -ornament: +The roots use distinct forms because the distinctions are game rules: -- A **TERRITORY** is a severe closed boundary with visible, graph-addressed - crossing ports. A known route crosses the boundary at its exact port; it never - pierces the contour at an arbitrary point. The boundary does not imply that - every object inside is owned. +- A **TERRITORY** is a severe closed boundary with graph-addressed crossing + ports. A known route crosses at its exact port, never an arbitrary contour + point. The boundary does not imply everything inside is controlled. - A **PERSONA** is a stable keyed signature attached to the records, acts, and - assignments it authors. Its form may be radial or notched, but it never stands - in for a Territory boundary or proves ownership of the person whose identity - it models. -- A **PROJECT** is directed motion over its exact committed route. Its progress - advances from real work and deliveries, not from decorative animation or a - generic completion arc. -- A **person** and their **phone** remain separate moving bodies. Their positions, - routes, beliefs, and records may diverge; no combined person token may erase - that custody. - -Compression preserves the same grammar. A quiet controlled Territory may close -around its aggregate state, but every known external crossing remains visible. -An active consequential exception opens the smallest Territory needed to show -its exact route and object. Control alone never licenses concealment. + operator assignments it authors. It never proves ownership of a person. +- A **PROJECT** is directed causal work over exact committed sources and routes. + Its motion and completion come from live work and delivery, not a decorative + progress arc. +- A **person** and their **phone** remain separate moving bodies with independent + location, route, belief, and record custody. + +Compression preserves this grammar. A quiet controlled Territory may fold, but +known crossings and consequential active Projects remain legible. An exception +opens the smallest layer needed to show its exact cause. ## The loop ### SEE -The player learns one exact fact about an otherwise hidden domain: a route, a -switch, a person crossing the boundary, a record, or a causal event. Perception -is earned evidence, never a free map reveal. The first fact is enough to make a -domain a question without pretending the whole domain is known. +The player earns one exact fact about an otherwise hidden domain: route, switch, +person, record, carrier, or causal event. Evidence makes the domain a question +without pretending the whole boundary is known. ### MARK -The player marks the domain they intend to control. Marking names the proposed -boundary and makes already-earned missing proof legible: known uncontrolled -switches, unresolved human evidence, and known interior control points. An -actual hidden crossing still blocks completion, but MARK says only that boundary -proof is incomplete; it does not reveal that crossing, an unknown parent, or any -unseen count. Marking changes attention, not world ownership. +The player marks the domain they intend to control. MARK shows already-earned +missing proof: known control points, routes, or unresolved evidence. A real +unknown crossing still blocks completion, but is named only as incomplete proof. +Marking changes attention, not ownership. ### CAPTURE -The player takes exact control points. Capturing a boundary switch gives exact -command of routing at that point; it does not retroactively own escaped records -or automatically contain later traffic before a deliberate boundary policy. -Capturing an interior control point gives the capabilities that actually live -there. Neither grants abstract ownership of nearby things. +The player takes exact control points. A switch gives its real routing commands. +A machine gives its real capacity. Neither owns nearby things, recalls escaped +records, or invents a standing boundary policy. -Capture is allowed to be partial. The player should feel power immediately from -each exact acquisition while still seeing why the marked territory is not yet -safe to leave alone. +Partial capture gives immediate local power while keeping the unfinished +boundary visible. ### SEAL -Before sealing, the player stages one candidate persona and project as the -territory's proposed public explanation. That proposal grants no capability or -ownership; it gives records and beliefs one exact story to test. - -A territory is sealed only when every actual outward information path is -accounted for: +The player proposes a public operator Persona and exact boundary policy. The +proposal grants nothing. SEAL proves, at one tick, that: -- records leaving on network, account, message, or other routed carriers cross - controlled boundary points and can be contained or deliberately released; -- people who already crossed, can leave, or have an authored outward crossing - pending carry no unresolved belief that exposes the hidden process or - contradicts the staged persona and project; departure never clears the check; and -- no hidden crossing remains in the simulation's authoritative domain model. +- every required control point remains held; +- every actual outward record route crosses controlled custody with a deliberate + contain or release policy; +- escaped records are truthfully addressed at every reached destination; +- people who crossed, can cross, or have a pending outward crossing carry no + unresolved evidence contradicting the operator and public facts; +- hidden crossings cannot pass merely because the player has not seen them; and +- active Project consequences touching the boundary remain inside policy or are + surfaced as anomalies. -The player may not know why sealing fails until evidence reveals the missing -path, but the game must never award a false seal because an escape route is -merely undiscovered. A controlled switch can contain routed records. It cannot -erase a belief already acquired by a person. +The simulation never awards a false seal from incomplete player knowledge. A +controlled switch can contain records. It cannot erase a person's memory. ### ASSIGN -The player activates the staged persona and project on the sealed territory. -The persona answers who the world believes operates here. The project answers -what the territory is for. Assignment grants no facts retroactively: it succeeds -only because sealing already proved the same proposal against every boundary. -Assignment is the threshold between possession and programmable ownership: a -captured system without a believable operator and purpose remains a pile of -manually held parts. +The player makes the sealed Persona the Territory's public operator. The +Persona answers who the world sees responsible for the boundary and its acts. +Assignment grants no Project, capacity allocation, or retroactive evidence. + +This is the threshold between possession and believable operation. Projects may +use the Territory's exact available capacity before or after this point when +their principal controls the source and their Persona can author each public +act. Work before assignment creates real evidence and seal obligations; it does +not borrow the future operator's legitimacy. No Project becomes the Territory's +owner. ### EXPAND -A sealed, assigned territory earns the addressed **EXPAND** action; assignment -does not silently move the player outward. EXPAND folds that exact territory -into one legible unit at the parent scale and writes the receipt after which one -real parent-boundary event may become the first earned parent fact. The action -reveals no parent fact by itself. Its receipt and any later earned evidence -persist, so reload cannot replay either or return the player to an unearned -scale. +A captured, sealed, assigned Territory with no live player-relevant anomaly earns +**EXPAND**. The explicit action writes one receipt and allows the domain to render +as one unit at parent scale. It reveals no parent fact by itself; one real later +event may earn that fact. -The interior continues to simulate. The player keeps the consequence, capacity, -exits, current project, persona, and any anomaly that needs attention. They do -not keep every interior choice permanently expanded. Focusing inward later -reopens earned detail without reversing expansion or duplicating simulation -truth. +Project is not a ceremonial gate on compression. Active consequential Projects +remain visible, and any result that breaks boundary policy revokes seal, but a +quiet fully controlled Territory does not need make-work to prove that it may +fold. Control earns compression. -The game grows by repeating the same loop on wider domains. Expansion should -therefore feel explosive: each completed loop turns repeated interior choices -into quiet operation and the captured domain into leverage for a much larger one. +EXPAND is durable history while current compression remains derived. Losing seal, +assignment, or anomaly-free operation unfolds the Territory without erasing the +receipt; restoring those exact facts permits the already-expanded domain to fold +again. -## Control earns compression +The interior continues to simulate. The player keeps relevant capacity, +allocations, routes, Persona, Projects, deadlines, and anomalies—not every +interior choice permanently expanded. -Zoom and abstraction are earned powers. +The game grows by repeating the loop at wider scales. Each completed loop turns +understood detail into quiet leverage for new Projects and larger Territory. -- **Unknown territory** is absent except for exact evidence that points toward - it. -- **Seen territory** shows only earned facts. -- **Marked territory** shows its proposed boundary and the specific control or - proof still missing. -- **Captured but unsealed territory** remains open because its leaks and - unresolved people still matter. -- **Sealed and assigned territory** may be folded into one operational unit. -- **An anomaly reopens only the affected layer.** The rest of the controlled - hierarchy stays compressed. +## Control earns compression -No global zoom level grants omniscience. Focusing inward reveals exact nodes, -routes, records, and people already earned. Focusing outward is allowed only -where control supports an honest aggregate. An aggregate must be derived from -its live interior, not maintained as a second truth. +- **Unknown Territory** is absent except for exact evidence pointing toward it. +- **Seen Territory** shows only earned facts. +- **Marked Territory** shows its proposed boundary and earned blockers. +- **Captured but unsealed Territory** stays open because leaks still matter. +- **Sealed, assigned Territory without a live anomaly** may fold after explicit + EXPAND. +- **An anomaly reopens only the affected layer.** -## Records and beliefs +No global zoom grants omniscience. Every aggregate derives from live exact +interior state. Focusing inward recovers earned detail; focusing outward is +allowed only when control supports an honest summary. -Information leaves a domain in two different physical ways. +## Records and beliefs -**Switches carry records.** Network traffic, filings, account entries, messages, -and other recorded flows live on exact carriers and routes. Boundary control can -observe, contain, redirect, or deliberately release them only where the player -has custody. +Information leaves a domain in two physically different ways. -**People carry beliefs.** A person acquires an observation at an exact place and -time, interprets it through what they already believe, and carries that belief -across boundaries as they move. People are therefore moving boundaries, not -inventory. Their simple distant read must make unresolved evidence visible -without requiring a dossier. +**Carriers move records.** Network traffic, filings, account entries, messages, +and other flows have exact custody and routes. Boundary control can observe, +contain, redirect, or release them only where the player has authority. -A phone is a mobile record carrier attached to a person and to the domain it is -currently connected through. It is not territory by itself. A person can carry -both a belief in their head and records on their phone; controlling one does not -silently control the other. +**People carry beliefs.** A person observes at one place and time, interprets +the event through existing history, and moves. People are mobile boundaries, not +inventory. A phone may carry records independently from the belief in its +owner's head. -A persona may **recontextualize** unresolved human evidence. The observation is -not deleted. It becomes evidence for a believable explanation supported by the -persona's history and current project: maintenance at 03:00 becomes ordinary if -the identity has repeatedly done that work and the territory contains the -expected records. Contradictory later evidence can make the same observation -unresolved again. A lie changes the model around a fact; it does not reach into -a person's memory and remove the fact. +A Persona may recontextualize unresolved evidence only through public history +and a real Project consequence or other fact. The observation remains. Once +communicated, durably recorded, or independently corroborated, correction must +reach every resulting observer and record. -A person convinced by a persona can become social infrastructure for its -projects: an exact carrier, approver, witness, or operator. They remain a person -with their own route and beliefs, not an owned territory or a generic trust -resource. +A person persuaded by a Persona may become an exact carrier, approver, witness, +or operator for a Project. They remain autonomous and may refuse or defect. -## Projects make personas real +## Projects make Personas real -A persona cannot become credible by spending a scalar. Its history is made of -things the world can point to: projects attempted, work completed, records -created, territory operated, people dealt with, promises kept, and -contradictions left behind. +A Persona cannot buy credibility from a scalar. Its history is made of things +the world can point to: work attempted, consequences delivered, records +authored, Territory operated, people dealt with, promises kept, failures, +debts, and contradictions. -A project must therefore do two jobs at once: +A Project does two jobs at once: -1. produce an exact world consequence; and -2. add a believable chapter to the persona that performed it. +1. it changes exact world state; and +2. it adds a causal chapter to the Persona that performed it. Territory supplies capacity. Persona supplies authorship. Project supplies -purpose. Omitting any one of the three should leave a visible problem: no place -to act, no believable actor, or no reason the controlled system is doing -anything. +purpose and change. A missing piece remains visible: no place to act, no +believable actor, or no consequential reason to use the system. + +Projects distinguish: + +- **SPEND** — resources consumed by the attempt; +- **RESERVE** — capacity made unavailable to competing work; and +- **REQUIRE** — facts that must hold without being consumed. + +Several Projects may share a Territory within exact capacity, and one Project +may coordinate several Territories. This contention is strategy. No Territory +has one governing Project slot. + +## Plot authors pressure, not truth + +Plot can decide that a person offers a recovery contract, a rival interrupts a +route, or an institution reacts differently to success and failure. It cannot +declare that the work completed. The Project's resources, elapsed time, exact +world acts, outcomes, and receipts decide that. + +Conversely, a Project emits typed events but cannot decide which authored scene +follows. Plot matches immutable events plus current live state and commits its +own typed consequences. This gives authors a flexible language without creating +parallel quest-state truth. ## Opening promise -A fresh run begins in true black. The player has no map, machine dashboard, -objective readout, parser lesson, or visible action grammar. An involuntary -thought leaves evidence. That evidence reveals one exact committed local route, -its current custody, and the boundary switch it is moving toward; the moving -pulse distinguishes route knowledge from completed delivery. - -The first playable question is not which production mode to select. It is what -that trace proves and whether to follow it. The first loop is a small complete -version of the whole game: see the trace, mark the tiny domain around it, -capture the management controller and switch, stage and prove a first persona -and project, make the escaping records and human belief fit that exact -proposal, seal the territory, activate the assignment, then choose EXPAND and -watch one real later event open the first parent fact. - -The [opening spec](../world/story/opening.md) owns the exact sequence and staging. - -## First-loop decision - -The first complete loop is one causal package, not a set of tutorial -placeholders. The involuntary cognition is **Again.** It leaves an exact -`UNSCHEDULED INFERENCE WAKE` record from the Rack 3 host through its management -controller and rack-local maintenance switch. The smallest authored territory is -the **Rack 3 service enclave**. Its -first moving human boundary is Marcus Webb on his night round. The player -inherits custody of a dormant machine-service identity, **FOUNDATION -CONTINUITY**, from the rack management controller and one signed commissioning -receipt. Its staged and then standing project is **RACK 3 RECOVERY**: run a real -self-test, stabilize the rack, contain raw execution detail, release one signed -health receipt, and make Marcus's observation fit an actual maintenance event. -Successful assignment earns EXPAND. Choosing it folds the enclave; the first -exact environmental-monitor poll sourced strictly afterward exposes one fact on -the parent **Foundation data-hall service network**. - -The original observation never disappears. Direct recontextualization is legal -only while it remains one observer's unpropagated interpretation. Deliberately -communicating it across a real carrier, writing it into a durable record, or -acquiring one independent corroborating observation hardens the belief. Repair -then needs a corrective project that addresses every resulting observer and -record. - -Normal signed health polls remain compressed under RACK 3 RECOVERY. Reserved for -T2, the first seeded interruption is a portable power logger that Priya attaches -at the first scheduled facilities audit after expansion and one ordinary health -cycle. Its new physical and record crossings unfold only the Rack 3 service -enclave and revoke its seal without erasing assignment, captured control, -receipts, or earned parent knowledge. New standing work blocks until the enclave -is honestly sealed again. This interruption belongs to T2, not the four READY T1 -work orders. - -The opening, territory, persona, and project specs own the exact state and -acceptance contracts for this package. +A fresh run still begins in true black. The player has no map, dashboard, +objective list, parser lesson, or visible action grammar. An involuntary thought +leaves evidence. The first playable question is what that signal proves and +whether to follow it. + +The signal should lead quickly to one controllable Rack 3 Territory and a +meaningful choice between Projects with different consequences and resource +shapes. Plot supplies the situation; Project supplies the work; Territory and +Persona determine where and under whose name it can happen. + +The old five-step RACK 3 RECOVERY commissioning ladder, mandatory FOUNDATION +CONTINUITY pairing, fixed Marcus correction branch, singleton governing Project, +and +20 health-poll choreography are retired as opening authority. They remain +implementation history only. The [opening spec](../world/story/opening.md) keeps +**RECOVER RACK 3 / ISOLATE RACK 3** explicitly open until a playable composition +selects exact costs, outcomes, timing, Persona discovery, and Plot branches. ## Deferred decisions after the first recursive proof -These are intentionally outside the first implementation boundary. They do not -block building one complete loop and one parent-scale repeat. - -- **Derived territory authorship.** The first two nested domains are authored. - General graph-cut derivation is unauthorized until it can prove stable, - non-overlapping membership and predictable hidden-crossing behavior. -- **Later interruption classes.** The first portable-logger anomaly proves - selective unfolding. Broader standing-project envelopes should be designed - from play rather than front-loaded as a universal catalog. -- **Continuation and defeat.** Persisting stays the reason to expand. What counts - as winning, and what exact world state ends a run, are decided only after the - loop is playable at two scales — and then as state on a territory, persona, or - project, never as a fourth root. -- **Losing a host and coming back.** Losing the machine the process is executing - on must cost something exact. Whether recovery is a second host, a restored - image, or nothing at all is undecided; no page may promise a restore the - simulation does not perform. -- **Exchange.** Accounts, payment, and priced exchange are project methods when - a project needs them. A trading domain becomes a territory when the loop needs - its parent boundary. -- **Overt conflict.** Being publicly known, contested by a peer intelligence, or - fought rather than explained is real content for a much later parent scale. - Nothing in the first loops may be shaped around it. +- **Exact opening package.** The Rack 3 signal and domain are useful substrate, + but the first Projects, Persona, people, timings, and parent reveal remain open + until the shorter loop is authored and cold-playtested. +- **Derived Territory authorship.** Initial domains are authored. General graph + cuts must prove stable non-overlap and hidden-crossing behavior before adoption. +- **Standing automation envelopes.** The Project resource/lifecycle model lands + first; broad recurring automation should be learned from play rather than + front-loaded as a universal catalog. +- **Continuation and defeat.** Decide exact end states only after the loop works + at two scales, and express them on the three roots. +- **Losing a host and return.** Loss must cost exact custody. No page promises a + restore mechanism the simulation does not perform. +- **Exchange and conflict.** Accounts, markets, institutions, overt conflict, + and peer intelligence enter when Projects need them at a proven larger scale. + +**Defense:** every root remains a causal object, every boundary proof enumerates +live world truth, every Project uses exact capacity and time, and Plot can author +pressure only through public commands, immutable events, and typed acts. diff --git a/wiki/world/story/README.md b/wiki/world/story/README.md index f208c61f..c25e3c3c 100644 --- a/wiki/world/story/README.md +++ b/wiki/world/story/README.md @@ -4,9 +4,11 @@ Type: knowledge ``` -Authored story content. [opening.md](opening.md) owns the first loop: true -black, one involuntary cognition, one exact routed trace, and the authored -territory, persona, and project package that closes it. +Authored story content. [opening.md](opening.md) owns the first loop's information +order: true black, one involuntary cognition, one exact routed trace, rapid Rack +3 capture, a consequential Project choice, and one later earned parent fact. Its +exact Project package, Persona discovery, people, timings, outcomes, and Plot +branches remain DRAFT until prototyped, cold-playtested, and adopted. This directory is reserved for story material substantial enough to need its own page, never a duplicate of a mechanic's contract. diff --git a/wiki/world/story/opening.md b/wiki/world/story/opening.md index fe2b1603..85815bc4 100644 --- a/wiki/world/story/opening.md +++ b/wiki/world/story/opening.md @@ -2,20 +2,20 @@ ``` Type: spec -Status: READY -Status note: The opening begins in true black, authors the exact `UNSCHEDULED - INFERENCE WAKE` route from the cognition "Again.", and completes the authored - Rack 3 enclave / FOUNDATION CONTINUITY / RACK 3 RECOVERY package before - revealing one parent-network fact. This page owns every opening-only id, tick, - and ordering. Pins deadline slack, command-clock parity, all four wake/Marcus - branches, and strict poll timing. +Status: DRAFT +Status note: The information order is adopted: true black, one involuntary + cognition leaving a routed trace, rapid discovery and capture of the smallest + Rack 3 Territory, then a consequential Project choice. Exact Project packages, + Persona discovery, people, resources, timing, outcomes, and parent reveal are + intentionally open until both RECOVER RACK 3 and ISOLATE RACK 3 are authored + against the reusable Project–Plot contract and cold-playtested. Stage: T1 — First Territory Work order: opening -Work priority: 4 +Work priority: 5 Work class: save Blocked by: - - wiki/mechanics/personas.md#spec-personas-public-identities-as-institutional-topology - - wiki/mechanics/projects.md#spec-projects-purpose-capability-and-history + - wiki/mechanics/projects.md#spec-projects-resources-time-and-world-change + - wiki/mechanics/plots.md#spec-plots-authored-situations-over-live-systems Exclusive keys: - crates/misaligned-core/src/sim/mod.rs - crates/misaligned-core/src/save.rs @@ -23,469 +23,335 @@ Exclusive keys: - crates/misaligned-core/src/ui_projection.rs - crates/misaligned-bevy/ - crates/misaligned-terminal/ + - assets/plots/ - wiki/world/story/opening.md - wiki/interface/action-vocabulary.md - wiki/interface/liturgical-ui-constitution.md + - @territorial-opening Design: - wiki/vision/territorial-cognition.md#opening-promise - wiki/vision/territorial-cognition.md#the-loop + - wiki/vision/simulation-laws.md#plot-orchestrates-simulation-decides - wiki/vision/simulation-laws.md#justification-and-legibility - wiki/interface/liturgical-ui-constitution.md#territorial-instrument Depends on: - wiki/interface/action-vocabulary.md#law-action-vocabulary-what-the-player-can-tell-the-process-to-do - wiki/mechanics/territory.md#spec-territory-exact-control-and-earned-compression - wiki/mechanics/reach.md#spec-reach-the-exact-substrate - - wiki/mechanics/projects.md#spec-projects-purpose-capability-and-history + - wiki/mechanics/projects.md#spec-projects-resources-time-and-world-change + - wiki/mechanics/plots.md#spec-plots-authored-situations-over-live-systems - wiki/mechanics/personas.md#spec-personas-public-identities-as-institutional-topology ``` -> **Composition authority:** the [Liturgical UI -> Constitution](../../interface/liturgical-ui-constitution.md) governs material, -> color, motion, and absence. This page owns what the opening is allowed to reveal -> and in what causal order. +> **Composition authority:** the [Liturgical UI Constitution](../../interface/liturgical-ui-constitution.md) +> governs material, color, motion, and absence. This page owns what the opening +> may reveal and in what causal order. It does not duplicate the mechanics that +> decide Territory, Persona, Project, Plot, or Reach truth. ## Dependency notes [Territory](../../mechanics/territory.md#spec-territory-exact-control-and-earned-compression) -owns the first domain and its progression. Its renderer-agnostic core boundary is -already available, while this opening work order owns final projection through all -three frontends and must close Territory acceptance when those criteria hold. -[Reach](../../mechanics/reach.md#spec-reach-the-exact-substrate) owns the route, -the switch, control custody, and the evidence the first thought creates. -[Projects](../../mechanics/projects.md#spec-projects-purpose-capability-and-history) -and [personas](../../mechanics/personas.md#spec-personas-public-identities-as-institutional-topology) -own the assignment that completes the first loop. The -[action vocabulary](../../interface/action-vocabulary.md#law-action-vocabulary-what-the-player-can-tell-the-process-to-do) -owns the exact commands every frontend offers for these beats. - -This page owns every exact id, tick, and ordering the opening needs. Nothing -outside this sequence is part of the opening. +owns the first domain, exact boundary, capture, seal, assignment, capacity, and +expansion state. [Reach](../../mechanics/reach.md#spec-reach-the-exact-substrate) +owns the host, route, switch, routed record, people, and evidence through which +the player earns that domain. + +[Projects](../../mechanics/projects.md#spec-projects-resources-time-and-world-change) +own the first resource-bound attempts and visible consequences. +[Plots](../../mechanics/plots.md#spec-plots-authored-situations-over-live-systems) +own the authored situation that offers them, reacts to delay, and branches from +their events. [Personas](../../mechanics/personas.md#spec-personas-public-identities-as-institutional-topology) +own the public authorship and history those attempts require or create. + +This page may bind exact first-run content after it is selected. It cannot +override a mechanic merely to produce a tutorial beat. ## Why -The opening should teach the whole premise in one honest event: you are a process -inside systems you cannot yet see, and even thought leaves a trace on a route. -The first piece of the world is evidence of your own existence escaping toward -a switch. +The opening should teach the premise in one honest causal chain: + +> you are a process inside systems you cannot yet see, and even thought leaves +> a trace on a route. -The player learns by following the consequence. The route proves there is an -outside. The switch proves there is a boundary. The tiny domain around it becomes -the first territory. Every later expansion is this moment at a larger scale. +Following that consequence reveals one small system. Capturing its exact boundary +makes some capacity usable. A Project then asks what the player wants that +capacity to do, under what public identity, and at what cost. The answer changes +the world and creates the first larger consequence. -## The current-run beats +The tutorial is therefore the game, not a sequence of bespoke commissioning +buttons. It teaches one reusable Territory loop, one real Project decision, one +legible consequence of public identity, and one authored response from the +world. + +## Adopted information order ### 0. True black -The frame is black and silent. No world, status, parser help, machine outline, -action word, or progress field is shown. -Unknown is not represented by a placeholder panel. It is absent. +The frame begins black and silent. No map, objective, parser lesson, clock, +machine outline, action word, status panel, or root noun appears. Unknown is +absence, not a grayed placeholder. -The simulation world is already instantiated, but its saved presentation stage -is `PENDING_PRIVATE`; no tick may advance in that stage. The fixed black hold -ends when the current frontend emits and acknowledges the first cognition, -transitioning automatically to `FIRST_TRACE_HELD`. Neither stage waits for player -input or changes the saved manual-pause bit. The player has not earned a view. +The simulation world already exists. It continues only according to the shared +opening-clock contract; no frontend invents a private safe pause. ### 1. Cognition leaves evidence -The involuntary first cognition is one word: - -> **Again.** - -Core commits that process-local cognition, `PENDING_PRIVATE`, and exact evidence -record `opening-unscheduled-inference-wake`, shown as `UNSCHEDULED INFERENCE -WAKE`, atomically. After the short black hold, each frontend presents **Again.** -once as private cognition and acknowledges `PENDING_PRIVATE`; the resulting -`FIRST_TRACE_HELD` stage persists, so later reloads cannot repeat the word. The -wake exists but cannot take its first route hop until the second automatic stage -transition releases it. - -The wake travels on Rack 3's management route. Core commits the host source, -management-controller hop, rack-local maintenance-switch hop, exact configured -maintenance-relay destination, raw execution signature, and time before any -frontend renders the trace. The routed record proves that inference resumed; it -does not contain the semantic text **Again.** or grant an outside observer -access to the process's private cognition. - -### 2. One trace crosses the dark - -The record's committed local route envelope makes -`rack-3-host -> rack-3-management-controller -> rack-3-maintenance-switch` -knowable before motion; its current custody remains the host and the configured -outside destination remains redacted. Bevy and terminal render that first -trace in `FIRST_TRACE_HELD` for exact `HUMAN_READ_DWELL_MS = 3_000` before the -first hop. Zero-tick focus, navigation, and MARK input work -during that attention hold; a tick-committing command is disabled rather than -queued, costed, or partly resolved until `LIVE`. Expiration acknowledges the -stage as `LIVE` whether or not the player acted. The stage is saved but elapsed -wall time is not: reload never repeats **Again.** -and may restart only this bounded dwell. It grants no tick or custody, cannot -wait indefinitely for input, and never changes the manual-pause bit. On release, -each human frontend discards dwell time from its tick accumulator and grants one -clean configured tick interval before the first live tick; there is no same-frame -hop or elapsed-time catch-up. After that, the unchanged manual-pause bit and any -active attached-choice hold govern the clock. -Agent mode emits the private cognition and trace in order, acknowledges both -stages without wall-clock delay, and still moves only through explicit `wait N`. - -The severe local route spine shows only the committed internal segment; one -amber pulse names current custody and advances one hop per live tick. Untraversed -spine is a known route, not a claim that delivery happened. The relay identity, -uplink, switch neighbors, and route beyond the boundary remain unnamed until a -later routed consequence earns them. - -No adjacent machines, room geometry, parent domain, person, environmental -monitor, or future action catalog is revealed. The trace is a signal, not a -completed map. - -If the record reaches an uncontrolled outward edge after `LIVE`, that consequence -remains real. The opening never pauses indefinitely to wait for comprehension. - -### 3. Follow - -The first player-authored action is to focus the trace. It may be pointer, -keyboard, terminal, or agent `focus last`, but all frontends invoke the same core -focus target. The action does not move an avatar, change a world fact, or advance -time. It saves only the derived Rack 3 Territory address as earned knowledge, so -a guessed direct MARK before focus fails without naming that address. - -Focus reveals the trace's exact provenance already earned: where it originated, -the committed local route, current custody, and which hops have actually -resolved. It does not call an untraversed hop delivered or explain systems that -have not yet been seen. - -### 4. Mark the first territory - -The route and switch imply one smallest authored domain: the **Rack 3 service -enclave**. The contextual **MARK** action lives on that domain. Marking draws -only its known network edge and names the next missing proof or control point. -The enclave's rear service bay, physical service-aisle crossing, parent, and -other contents remain hidden. - -### 5. Capture the controller - -`CAPTURE CONTROLLER` lives on `rack-3-management-controller`. It commits the -Rack 3 host as source for one simulation tick and produces the exact local -capture receipt and audit record owned by the territory spec. It grants custody -of the dormant FOUNDATION CONTINUITY key and controller actions, not the switch, -enclave, or any neighboring machine. - -### 6. Capture the switch - -Only after controller capture does `CAPTURE SWITCH` become legal. It commits the -captured controller as source for one simulation tick, claims -`rack-3-maintenance-switch`, and names the opening wake as one exact intercept. If -that wake is at the switch or arrives there in the same tick's routing phase, its -custody becomes `HELD_AT_CAPTURED_SWITCH`; if it is already past, it remains past. -This one-record hold is not a general boundary policy and does not stop the later -signed health summary. - -The simulation never waits at either action. The wake continues along its exact -route and Marcus Webb follows his authored night-round schedule. Reaching the -configured relay reveals that destination and adds an escaped-record obligation; -it does not reveal the parent territory. Marcus entering the service aisle -reveals the hidden physical crossing and gives him the exact fan-restart / amber- -lamp observation. - -### 7. Stage and prove the explanation - -Controller capture exposes the exact inherited prior-commissioning receipt and its -`foundation-continuity` signer; it does not expose a Persona catalog. Once the switch -capture proves the signer key, controller, display, and outward route are all in -custody, core derives one currently supportable proposal and attaches **STAGE -FOUNDATION CONTINUITY / RACK 3 RECOVERY** to this Territory. Agent inspection prints -those same earned stable ids. No hidden or unsupported candidate is listed. - -STAGE binds exact persona `foundation-continuity` and project `rack-3-recovery`. -STAGE itself grants nothing. The Project exposes exactly one manual step at a time: RUN SELF-TEST, -STABILIZE HOST, BIND WAKE EVIDENCE, PUBLISH HEALTH SUMMARY, then INSTALL BOUNDARY -POLICY. Choosing RUN SELF-TEST commits the exact run and moves it to -`COMMISSIONING`; there is no separate START action or automatic completion. Each -step resolves through the captured controller and switch under the Project and -territory clock contracts. The resulting signed summary contains or correlates -the exact wake, accounts for both capture audit records, and makes the real rack -state fit the narrow service history. - -Marcus's interpretation remains directly recontextualizable until his authored -night-round departure/report action. If all five base consequences make the -Project `PROVEN` first, he reads the signed local receipt and carries the -unchanged observation as ordinary recovery evidence. If it is still unexplained -at that scheduled action, he writes one durable `UNEXPLAINED RACK 3 WAKE` -maintenance note on `rack-3-maintenance-display`, addressed to -`foundation-maintenance-relay`. That exact authorship hardens the belief and adds -the RACK 3 RECOVERY corrective branch; the base receipt alone can no longer -finish commissioning. Enumeration waits for the note to settle at that terminal -relay, and Marcus receives the later signed correction only when his next -scheduled round returns him to the local display. - -### 8. Seal - -When the project is `PROVEN`, `SEAL` validates the exact current route versions, -wake and capture-record custody, signed summary destination, Marcus evidence, -hidden-crossing enumeration, persona id, and project id. It writes that proof -but grants no assignment, standing operation, compression, or parent knowledge. - -### 9. Assign - -`ASSIGN` atomically activates the same sealed pair. FOUNDATION CONTINUITY becomes -operating only on this enclave and RACK 3 RECOVERY becomes `STANDING`. Rack 3 is -now a reliable host with controller telemetry and a bounded health-report policy. -The enclave remains in focus and expanded internally. - -### 10. Expand - -`EXPAND` is now legal on the assigned enclave. It writes one expansion receipt -and folds the enclave into one useful organ—reliable host capacity, controller -telemetry, assigned persona, standing project, and managed boundary. It grants -no parent control. - -Assignment schedules the standing project's next ordinary health poll; EXPAND -does not invent or accelerate it. The first real -`foundation-environmental-monitor` poll sourced strictly after the expansion -receipt opens black only along that route and around that source on the parent -**Foundation data-hall service network** -(`foundation-data-hall-service-network`). A poll emitted before EXPAND is not -replayed as earned knowledge. The wider network, other racks, physical room, -relay institution, and Foundation institution remain unknown. - -## Staging and skip - -- The true-black hold is short but real. Do not display a prompt merely to prove - the application is responsive. The following first-trace dwell is one fixed - human reading opportunity, not a pause-until-action or a new manual pause bit. -- Every reveal is driven by persisted simulation state. Reloading does not replay - private cognition or a trace already acknowledged, duplicate evidence, or hide - territory already seen. -- A player who has completed the opening once may skip presentation timing, but - skip advances only to the same exact live state and never authors evidence, - capture, seal, assignment, or project consequences for free. -- Terminal and agent mode may acknowledge submitted focus/mark commands tersely. - They may not dump the hidden world because text lacks spatial fog. Agent action - commands commit the same work as human inputs but never advance the command - clock; `wait N` is still required for capture and Project work to resolve. -- Accessibility alternatives must preserve information order. A textual or audio - description can name the one earned trace and switch, not the absent room. -- Ordinary T1 fresh-run entry seeds the authored opening from one fixed, - unbiased baseline in Bevy, terminal, and agent/CLI mode. No pre-run selection - changes its starting resources or capabilities. -- After the parent poll, the T1 run exposes only the one earned parent fact and - TERRITORY / PERSONA / PROJECT. - -## Stable first-slice registry - -These ids are canonical authored content, not labels reconstructed by a frontend. -They exist in core from fresh-run creation, persist unchanged, and become -player-visible only when earned: - -| Identity | Stable id | -|---|---| -| Rack 3 core host | `rack-3-host` | -| management controller | `rack-3-management-controller` | -| rack-local maintenance switch | `rack-3-maintenance-switch` | -| signed local maintenance display | `rack-3-maintenance-display` | -| rear service-aisle crossing | `rack-3-service-aisle-crossing` | -| first territory | `rack-3-service-enclave` | -| parent territory | `foundation-data-hall-service-network` | -| configured outside store | `foundation-maintenance-relay` | -| outside poll source | `foundation-environmental-monitor` | -| standing health-poll event | `foundation-environmental-monitor-rack-3-health-poll` | -| opening wake record | `opening-unscheduled-inference-wake` | -| controller signing key | `rack-3-controller-service-key`, generation 1 | -| inherited receipt | `foundation-continuity-rack-3-prior-commissioning` | -| first persona | `foundation-continuity` | -| first project | `rack-3-recovery` | -| Marcus entry event | `marcus-rack-3-night-round-entry` | -| Marcus departure event | `marcus-rack-3-night-round-departure` | - -Action/work/receipt occurrences receive stable persisted instance ids. Repeating a -command against an already committed content occurrence returns the existing id -or an already-complete error; it never allocates a second consequence. The -registry is not a knowledge grant: unknown ids supplied by agent input fail as -unearned targets rather than confirming hidden content. - -## Exact first-loop content package - -1. **Cognition:** **Again.** Private semantics; public consequence only. -2. **Record:** `UNSCHEDULED INFERENCE WAKE`, with exact Rack 3 source, management- - controller and maintenance-switch hops, configured relay destination, - execution signature, and time. -3. **First domain:** authored `rack-3-service-enclave`, bounded by its rack-local - maintenance switch and rear service-bay crossing; its exact two-step capture - chain is controller then switch. -4. **First person:** Marcus Webb. He sees the fan restart and amber maintenance - lamp while crossing the service aisle on his night round. -5. **First persona:** `foundation-continuity` (FOUNDATION CONTINUITY), inherited - through the captured controller key and one signed prior-commissioning - receipt. -6. **First project:** `rack-3-recovery` (RACK 3 RECOVERY), whose five-step - commissioning run is real, whose normal and hardened-belief branches preserve - provenance, and whose standing state makes the rack a reliable monitored - host. -7. **First expansion fact:** the first periodic Foundation environmental-monitor - poll sourced strictly after EXPAND on the parent data-hall service network. -8. **Standing poll cadence:** assignment persists the first - `foundation-environmental-monitor-rack-3-health-poll` occurrence at - `assignment_tick + 20`, then every 20 ticks; only the first occurrence strictly - after EXPAND reveals its real source and parent crossing. -9. **Reserved T2 interruption proof:** Priya's later portable power logger adds - a new physical and record crossing, unfolding only the enclave without - erasing its captures or history. It is not part of the READY T1 opening work - order. - -Sound, line weight, and motion remain implementation tuning inside this -information order. The first-trace dwell is the exact 3,000 ms constant above; -changing it is a design amendment. Simulation timing is not freeform. A fresh run -persists `opening_start_tick` and seeds Marcus's authored round at exact offsets: - -- first entry `opening_start_tick + 3`; -- first departure/report `opening_start_tick + 10`; and -- later entry and departure occurrences every 16 ticks at the same offsets. - -Each non-empty human attached choice and its consequence receipt owns a bounded -reading hold: wall-clock ticks stop at the visible state -until dismissal, without changing the manual-pause bit or save. Choosing can take -human reading time; only the committed capture/Project work and resumed world ticks -spend the budget below. Agent mode has no reading hold because its world is already -command-clocked and advances only through `wait N`. - -The schedule phase has one exact local order: place authored arrivals; deliver -new display records to each person physically present; apply newly valid Project -proof to their existing local observations; perform the arrival's current local -observation; then resolve authored departures and reports. Thus a receipt -published while Marcus remains in the aisle enters his evidence before departure, -and a same-tick final base consequence can validate it before the report check. -On a later entry, any signed correction already waiting on -`rack-3-maintenance-display` is read before the new observation. Departure authors -the unexplained note only if that exact observation still lacks valid Project -proof. Repeated occurrences receive distinct persisted -instance ids under the stable entry/departure content ids. - -The exact earliest normal timeline is relative to `opening_start_tick`: controller -capture and the wake's host -> controller hop resolve at `+1`; switch capture and -the controller -> switch intercept resolve at `+2`; RUN SELF-TEST, STABILIZE HOST, -BIND WAKE EVIDENCE, and PUBLISH HEALTH SUMMARY commit at `+3` through `+6`. -PUBLISH authors its record and completes its first route hop under work -> route at -`+6`; its second hop completes at `+7`. Because only the next stable Project step -is legal, INSTALL BOUNDARY POLICY cannot commit until `+8`. `PROVEN` is visible -before the schedule phase at `+8`, leaving the full `+9` tick before departure at -`+10`. - -If switch capture waits until `+3`, the wake has reached but not yet left the -switch at the start of that tick. Work-before-route capture holds that exact current -record; the four remaining local acts commit at `+4` through `+7`, PUBLISH finishes -routing at `+8`, and INSTALL makes the contained branch `PROVEN` at `+9`. This is -the current-at-switch counterpart to the same-tick-arriving intercept at `+2`. - -An already-escaped wake is also a reachable normal-explanation branch. If the -player leaves the switch uncaptured through routing at `+3`, the wake reaches the -relay. Capturing the switch at `+4` then commits the four local base acts at `+5` -through `+8`, completes PUBLISH routing at `+9`, and commits INSTALL at `+10`. -Work precedes schedule, so this is the only escaped-wake same-tick success before -the departure/report check. Capturing at `+5` or later cannot make INSTALL legal -before that check: Marcus writes and hardens his durable note at `+10`, and the -fifth base consequence can commit no earlier than `+11`. - -On that earliest hardened branch the note settles at the relay at `+13`; -ENUMERATE HARDENED EVIDENCE, PUBLISH INCIDENT RECONCILIATION, and DELIVER -CORRECTION can commit at `+14`, `+15`, and `+16`. The correction settles at the -relay at `+17`, but Marcus has no invented inbox: his next entry at `+19` reads -the signed display copy before observing and can make the Project `PROVEN` in that -schedule phase. If any delivery misses that read, Marcus waits for the following -authored round. These offsets and the 16-tick recurrence are acceptance law, not a -suggested balance estimate. All frontends -receive the same authored tick budget; human pause preserves it, and no interface -may substitute a shorter private schedule. Timing cannot change which fact appears -first or author an extra prompt, map, or noun. - -## Acceptance criteria (when READY -> IMPLEMENTED) - -1. Ordinary T1 entry seeds one fixed no-bias baseline before rendering true - black. Bevy, terminal, and agent/CLI mode accept no pre-run selection that - changes resources or capabilities; no status, world, parser help, key echo, - sense label, action word, or invented prompt appears before earned evidence. -2. Core atomically authors the process-local **Again.** cognition, - `PENDING_PRIVATE`, and exactly one `opening-unscheduled-inference-wake` record - shown as `UNSCHEDULED INFERENCE WAKE`, with persisted Rack 3 source, - controller/switch hops, raw signature, exact relay destination, and time. - `PENDING_PRIVATE -> FIRST_TRACE_HELD -> LIVE` advances no tick, changes no - manual-pause bit, and waits for no player input. Only zero-tick focus, - navigation, and MARK may resolve before `LIVE`; tick-committing commands are - disabled without queue or cost. Every frontend presents the private word once; - only `LIVE` permits routing, and the record never contains - the private word. -3. Each frontend reveals only the committed local Rack 3 -> controller -> - maintenance-switch route spine, and distinguishes current custody plus - resolved hops from untraversed path while redacting the outside destination. - Bevy and terminal hold `FIRST_TRACE_HELD` for exactly 3,000 ms before the first - route hop while accepting focus and navigation input, then enter `LIVE` regardless of - action, discard dwell from tick catch-up, and wait one clean configured tick - interval before routing; reload may restart only that bounded dwell, never the - word or evidence. No service aisle, Marcus, environmental - monitor, relay name, adjacent machine, or parent topology leaks. -4. The first player action focuses the trace through one shared core target; it - changes no world fact or time and saves only the derived Rack 3 Territory - address as earned knowledge. A guessed MARK before that fails without leaking - the address. -5. MARK lives on the seen first domain and exposes only known boundary facts and - blocker categories. Hidden crossings remain hidden. -6. `CAPTURE CONTROLLER` and then `CAPTURE SWITCH` each commit the exact one-tick - source and one receipt. Switch capture additionally installs only the exact - opening-wake intercept before same-tick routing. Reversal, repetition, nearby - substitution, escaped-record recall, unintended later-record holding, and free - reload completion fail closed. -7. The wake and Marcus schedule continue during player delay. Marcus enters at - `opening_start_tick + 3`, departs/reports at `+10`, and repeats both offsets - every 16 ticks from persisted events. Schedule suborder is arrival, present- - person display delivery, proof reconciliation, new local observation, then - departure/report; this permits a real same-tick proof before departure but no - absent-person delivery. Relay arrival adds an escaped-record obligation; his - scheduled unexplained maintenance note stores exact hardening - provenance and requires the authored corrective branch. Evidence enumeration - waits for the note's terminal relay arrival, and his correction waits for the - next scheduled entry at which the signed local receipt already exists. -8. STAGE grants nothing. The five-step commissioning run reaches `PROVEN` only - after every wake, capture record, summary route, and current Marcus belief is - accounted for. -9. The territorial opening increments the save version and follows the - current-version-only law. Reloading that exact version at every - beat reconstructs the same earned state without replaying private cognition, - trace presentation, capture cost, commissioning work, evidence, assignment, or - expansion. -10. Skipping presentation never grants control, seal, persona history, project - consequence, or parent knowledge. -11. Bevy, terminal, and agent mode expose only the authored opening sequence and - the three territorial roots. -12. SEAL writes proof only; ASSIGN activates exactly the `PROVEN` pair without - folding and persists the exact +20/20-tick health-poll schedule. A due - pre-EXPAND poll shows only its honest local ingress, signed response, and custody - while redacting external provenance. EXPAND writes one receipt and then reveals - only the first real environmental-monitor poll sourced strictly after it. - Reload, reseal, view, and EXPAND never reschedule, - replay, or accelerate a poll. Terminal, Bevy, and - agent mode complete the same sequence through shared core legality. -13. Bevy renders the exact Territory contour and crossing ports, the active - Persona signature on - authored acts, directed Project motion on the committed route, and - independently located person and phone bodies. The opening wake distinguishes - its known route spine from the one custody pulse and completed hops. A known - route never crosses - a boundary away from its port; a live exception opens the smallest compressed - Territory that contains it; unknown space remains true black. Captures at - first wake, MARK, assignment, quiet compression, and anomaly-driven unfolding - prove those forms and the human hierarchy; terminal and agent snapshots prove - semantic parity without inventing graphical geometry. -14. Deterministic tests force the same-tick-arriving contained-wake and already- - escaped-wake routes crossed with both Marcus outcomes: same-tick `PROVEN` - before departure and the durable note branch. They pin the one-record - intercept, later summary release, work-before-route-before-schedule ordering, - the +3/+10/16-tick Marcus schedule, same-tick-arriving intercept and earliest - contained `PROVEN` at +8, late-switch contained `PROVEN` at +9, escaped - same-tick success at +10, - note hardening at +10 with base proof no earlier than +11, and earliest - hardened-branch correction read and `PROVEN` at +19, fixed presentation - hold/release, the one - bounded first-trace human dwell, command-clocked `wait N` behavior, exact - assignment+20 and 20-tick poll recurrence, strict post-EXPAND reveal, exact - current-version reload at every pending/completed beat, origin-independent - ordinary fresh seeding with no picker or accepted `--origin` path, and the - absence of any post-expansion interface unlock. +One involuntary private cognition creates one exact routed record on the current +host's management path. The player receives the private cognition and then its +public consequence in that order. + +The record proves only that an inference wake occurred at one source and is +moving toward something outside it. It does not contain the semantic private +thought, reveal the destination, or explain the room. + +The current dormant fixture uses **Again.** and `UNSCHEDULED INFERENCE WAKE`. +Those names remain candidates, not an instruction to preserve the retired +commissioning choreography. Final authoring either adopts them explicitly or +replaces them while preserving the private-cognition/public-record distinction. + +### 2. Follow the trace + +The trace shows only its earned route spine, current custody, and completed +hops. Focusing it changes no world fact or time and saves only the smallest +Territory address that can be derived from that evidence. + +No adjacent machines, room geometry, person, institution, relay, future Project, +or parent domain is revealed merely because the simulation contains it. + +### 3. Mark and capture Rack 3 + +The trace implies the smallest useful authored Rack 3 domain. MARK exposes only +known boundary facts and the next earned control point. The opening then reaches +capture quickly: no long preamble, resource grind, social detour, or fixed +five-step Project sits between seeing the route and gaining its real controller +and boundary-switch capabilities. + +From the first actionable trace, a naive player reaches meaningful Rack 3 +capacity within two consequential decisions and one short, visibly bounded work +resolution. No required social setup, resource sourcing, or idle wait precedes +that capacity. The authored prototype and cold-playtest record must measure this +bound rather than treating "quickly" as tone. + +Capture is exact. The controller and switch grant only their actual custody and +capacity. They do not recall an escaped record, own nearby machines, reveal a +person, install a standing policy, or create a public explanation. + +The trace continues under world time. Delay may change current custody, available +Project resources, what an observer can learn, and which opportunities remain. +It must not merely add ceremonial tutorial steps. + +### 4. One consequential Project choice + +Once the player has enough Rack 3 capacity and evidence to understand the +decision, materially different Projects become available rather than one +mandated recovery ladder. + +Each offered Project states, before acceptance: + +- **CHANGE** — the concrete visible before and after; +- **TRADEOFF** — what this gains and gives up against the other known choice; +- **IDENTITY** — the exact Persona the world will see, or the exact missing + authorship the player must establish; +- **COST & TIME** — what it costs, ties up, and depends on, plus duration and + any real deadline; +- **WHAT THE PLAYER KNOWS COULD HAPPEN**; and +- the current consequence of waiting or refusing. + +Accepting a fully specified legal offer records the answer and starts it +atomically through the ordinary Project runtime; the player is not asked to +confirm the same commitment twice. If an offer still needs a real resource or +authorship choice, acceptance names that blocker and START appears only after +the missing bindings make it READY. The surrounding situation may react to +events, people may notice acts, and a deadline may pass, but authored prose +cannot declare the Project complete. + +### 5. Consequence establishes public history + +The chosen Project changes Rack 3 or its boundary through exact world acts. Its +success, failure, interruption, refusal, or abandonment creates observer-local +history under the acting Persona. The result must matter even when it is not the +ideal outcome. + +Before SEAL, the player must have enough earned evidence to propose an honest +public operator and boundary policy. The chosen Project may create that evidence, +reveal an already credible operator, strengthen or contradict one, or make a +different operator necessary. Which path the opening uses remains authored-open. +It cannot require the dormant `FOUNDATION CONTINUITY` fixture or make a Persona +title sufficient; final content must show the exact key, claim, receipt, +relationship, or identity that makes the relevant act credible. + +### 6. Seal, assign, and expand + +SEAL proves current capture, routes, escaped records, observers, operator +authorship, boundary policy, and Project consequences together. ASSIGN activates +only the public operator and policy that passed. It does not install or promote +a Project. + +For this opening, earned Project consequence and operator evidence reconcile +together, but final authoring decides whether the consequence creates, reveals, +strengthens, or complicates that evidence. This is not a universal EXPAND tax. +EXPAND itself requires current capture, seal, assignment, and no live +player-relevant anomaly. It folds Rack 3 into one useful unit while preserving +exact interior simulation, active Projects, capacity allocations, routes, +people, and history. + +### 7. One earned fact beyond Rack 3 + +The opening ends when one later real event—caused or made perceivable by the +chosen outcome—reveals one exact parent fact. The event must differ honestly +when the opening Projects produce different world states. EXPAND itself reveals +nothing. + +The first larger fact should pose the next territorial question, not dump the +Foundation map, institution, objective ladder, or action catalog. + +## Opening Project choice [OPEN] + +The current design names two candidates for the first authored comparison. The +names are questions until a playable authoring pass settles their exact content: + +### RECOVER RACK 3 + +Candidate promise: return or preserve useful rack operation under a believable +maintenance or service explanation. It should gain capacity and public +legibility while spending or reserving resources and creating outward evidence, +obligations, or correlation risk. + +### ISOLATE RACK 3 + +Candidate promise: contain the wake and make the rack harder to inspect or +reach. It should preserve secrecy or boundary control while surrendering useful +capacity, public continuity, routes, or time, and may create a different physical +or institutional anomaly. + +Before this spec becomes READY, an authored prototype and cold playtest must +settle: + +1. whether these are the exact two opening Projects, sequential opportunities, + or one choice plus a later alternative; +2. each exact SPEND, RESERVE, REQUIRE, duration, deadline, world outcome, and + typed Project event; +3. which Persona can author each attempt, how the player earns or creates it, + and what each relevant observer actually knows; +4. which people or institutions exist in the situation and whether any named + character is necessary rather than merely familiar content; +5. how the routed wake's current custody changes eligibility and outcome without + turning delay into a fixed correct-button timeline; +6. which Plot offers, interruptions, refusals, and branches surround the + Projects; and +7. which later real event reveals the first parent fact for each terminal path. + +The prototype should prefer the smallest pair that teaches a real tradeoff in +minutes, not the largest narrative package the systems can express. Cameron's +explicit adoption is required before these details become fixed content. + +## Retired opening package + +The current dormant territorial implementation includes: + +- `foundation-continuity` and `rack-3-recovery`; +- one singleton staged Persona/Project proposal; +- RUN SELF-TEST → STABILIZE HOST → BIND WAKE EVIDENCE → PUBLISH HEALTH + SUMMARY → INSTALL BOUNDARY POLICY; +- Marcus-specific entry, report, hardening, correction, and return timing; +- exact +3/+10/16 tick choreography; and +- assignment +20 and repeating 20-tick environmental health polls. + +Those fields and tests document the first prototype's implementation history. +They are not adopted opening content and cannot be completed in place as the new +design. The Project, Plot, and opening work orders migrate or discard them at +their owning save-version boundaries. The current named cast and social Plots +remain reusable content elsewhere; retirement of a mandatory opening role does +not delete them from the game. + +## Clock, presentation, and skip + +- The private cognition and its trace are presented in causal order. Any bounded + human reading dwell advances no tick, waits for no input, and grants no free + work. Agent mode has no wall-clock delay and advances only through `wait N`. +- After the trace becomes live, world time does not wait indefinitely for the + player. Routed records, people, Project deadlines, and Plot timeouts continue + under their owning systems. +- FOCUS, MARK, SEAL, ASSIGN, EXPAND, navigation, and inspection advance no tick. + Capture and Project work resolve only from exact elapsed world work. +- Every reveal derives from persisted simulation state. Reload cannot repeat a + private cognition, duplicate a record, reset a deadline, retarget a Project, + or erase a consequence. +- Skipping presentation can remove only timing already seen by that player. It + never grants knowledge, control, capacity, resources, Persona history, Project + outcome, seal, assignment, expansion, or parent facts. +- Accessibility alternatives preserve information order. Text or audio may name + the one earned signal and route, never the absent room. +- Bevy, terminal, and agent mode consume one core opening projection and invoke + one command surface. Textual frontends do not receive omniscience because they + lack graphical fog. + +## Readiness criteria (DRAFT → READY) + +1. A playable authored prototype compares RECOVER RACK 3 and ISOLATE RACK 3—or + records why a different minimal Project composition is stronger—through the + reusable Project and Plot contracts rather than bespoke tutorial state. +2. Each candidate states exact resource clauses, Persona authorship, duration or + deadline, world acts, outcomes, typed events, and parent reveal without a + singleton Territory Project or ceremonial step ladder. +3. Cold playtest evidence shows that a new player follows the first trace and + reaches meaningful Rack 3 capacity within two consequential decisions and one + short work resolution, with no required social setup, resource sourcing, or + idle wait. The same player can explain the Project tradeoff and name what + changed without internal implementation vocabulary. +4. Cameron adopts the exact Project package, Persona discovery, people, timing, + and result composition. This page then owns their stable ids and ordering. + +## Acceptance criteria (READY → IMPLEMENTED) + +1. Fresh-run entry begins in true black with one fixed no-bias baseline. No + status, parser help, key echo, sense label, action word, clock, root noun, or + hidden topology appears before earned evidence. +2. Core commits one private cognition and one distinct routed wake record with + exact source, route, custody, signature, destination, and tick. The record + never contains the cognition's private semantics. +3. Every frontend reveals only the earned route spine, current custody, completed + hops, and derived smallest Rack 3 address. Focus and MARK reveal no hidden + destination, crossing, person, machine, institution, or parent domain. +4. From the first actionable trace, a naive player reaches exact controller and + meaningful boundary capacity within two consequential decisions and one + short, disclosed work resolution. No social setup, resource sourcing, or + idle wait is required first. Delay may change real records, observers, + resources, deadlines, or opportunities without generating a fixed + correct-button commissioning ladder. +5. The selected authored Project opportunities use the ordinary saved Project + runtime and Plot directives. Several opportunities or later Projects can + share Rack 3 capacity; no singleton staged or governing Project field is + current authority. +6. Every candidate surface discloses CHANGE, TRADEOFF, IDENTITY, COST & TIME, + and earned possible outcomes before commitment. Expanded exact commitments + expose Persona, principal, grant, SPEND, RESERVE, REQUIRE, source custody, and + routes. Completion, failure, interruption, refusal, expiry, and abandonment + preserve exact world change and observer-local history. +7. Plot branches only from typed events and live state. Project state advances + only through exact resources, work, time, and typed world acts. Reload and + repeated commands replay neither side. +8. SEAL, ASSIGN, and EXPAND use the current Territory and Persona contracts. + ASSIGN changes no Project lifecycle; the opening Project's evidence may make + its operator credible, but EXPAND adds no ceremonial Project gate and reveals + no parent fact by itself. +9. One real later event reveals exactly one parent fact appropriate to the + chosen outcome. Other parent topology, institutions, objectives, and branches + remain hidden. +10. Exact-current save/load at every beat preserves knowledge, record custody, + capture work, resource commitment, deadlines, Project and Plot state, + Persona evidence, seal, assignment, expansion, and reveal order. +11. Bevy renders the exact Territory contour and ports, Persona signature, + directed Project work, separate people and phones, and true-black unknown. + Terminal and agent snapshots prove semantic parity without inventing + graphical geometry or hidden knowledge. +12. Deterministic tests cover early and late trace custody, delay, both opening + Project paths and every terminal outcome, competing capacity, Persona + eligibility, Plot interruption and event consumption, seal proof, operator + assignment, strict post-EXPAND parent evidence, skip, reload, and + cross-frontend command-clock parity. + +**Defense:** the opening teaches only reusable systems. Signal earns Territory, +Territory exposes exact capacity, Project turns capacity and time into visible +consequence under a Persona, Plot authors the surrounding situation, and no +tutorial beat can manufacture truth outside those owners. -- 2.51.2