# SIMULATOR — Vision Document ## The Cooperative Simulation and Its Governing Intent ### Status: Canonical vision. Not an implementation commitment. ### Date: 2026-05-02 ### Part of: TheRON — CIVICVS / OTIVM / TESSERA / DESCENSUS stack --- ## 1. What This Document Is This document states what the Simulator is, what it is for, and what its two operating modes are. It also identifies four open design opportunities — gaps and conflicts that are not blocking but that will determine the quality of the final instrument when professional development resources are engaged. This document is not an implementation plan. It is a frame. Implementation catches up to the frame, not the reverse. --- ## 2. The Seating Limit The Simulator accommodates 128 participants. This is a design limit, not a technical one. The Simulator is a precision instrument, not a mass-market product. Its value comes from the quality of participant engagement, not the quantity. A field excavation has a defined team. A research vessel has a defined crew. The Simulator has 128 seats. The seating limit also governs the cooperative simulation's social dynamics. 128 is large enough to produce meaningful collective behaviour and small enough for each participant to matter individually. --- ## 3. Two Simulation Modes Per Account Each participant account has access to two simulation modes. These are not sequential stages — they are parallel instruments with different purposes. A participant may be active in both simultaneously. --- ### Mode 1 — The Single Simulation (The Laboratory) The participant selects a Mesolithic clan and becomes its Leader. The single simulation is private and personal. It belongs to the participant alone. Its purpose is to produce deep familiarity with the substrate: the resource logic, the social mechanics, the cost of distance, the consequences of DESCENSUS, the limits of what any one clan can achieve. The participant may restart the single simulation as many times as they wish. DESCENSUS ensures that no strategy becomes permanently dominant across restarts — every attempt is honest, every environment responds to what the participant actually does, not to what they planned. The single simulation has no end condition. It runs until the participant is satisfied with what they have learned or with the state their clan has reached. --- ### Mode 2 — The Cooperative Simulation (The Instrument) When a participant is satisfied with their single simulation, they may nominate it as their entry into the cooperative simulation. In the cooperative simulation the participant is no longer a Leader. They occupy a role: trader, centurion, magistrate, healer, engineer, or others to be defined. The clan they nominated becomes their entry state — the foundation from which their role operates. The Model fills the roles that participants do not occupy. It maintains the simulation's historical coherence, populates the consequences of participant decisions, and ensures the environment remains faithful to the physical and social reality of Mesolithic Central Europe progressing toward the Roman epoch. The cooperative simulation runs forward in time from the Mesolithic toward 100 CE. It does not reset. It runs once, together, to conclusion. Participants who are active at the end of the simulation are ranked by achievement — the definition of achievement is deliberately deferred and will be developed as the design matures. The cooperative simulation is the instrument the entire stack was built toward. TESSERA provides the physical substrate. CIVICVS provides the Mesolithic environment. OTIVM provides participant preparation. DESCENSUS provides the epoch transition mechanism. The cooperative simulation is where all of these converge into a single shared experience governed by historical reality. --- ## 4. The Model's Role in the Cooperative Simulation The Model — the Roman Oracle, bounded 100 BCE to 100 CE — fills structural roles in the cooperative simulation. It does not play to win. It plays to make the simulation real. The Model never overrides participant decisions. It responds to them. Participant decisions that diverge from historical plausibility trigger responses that are themselves historically plausible: resource scarcity, rival clan formation, disease, extreme weather, political consequence. The Model populates the world that participant decisions produce, not the world the Model would prefer. The Model's temporal boundary (100 BCE to 100 CE) means it cannot inhabit the Mesolithic from the inside. It reads the record the participants create. It interprets that record through Roman understanding — which is itself a historically bounded perspective. The gap between what the participants experience and what the Model can interpret is not a flaw. It is the simulation being honest about the limits of Roman knowledge of what came before Rome. --- ## 5. The Transferability of This Design The design described in this document is not specific to the Roman and Mesolithic epochs. Any world that can be encoded in TESSERA and governed by an epoch-bounded Model can run this simulation. Rome to Mesolithic is the first instantiation. The architecture is open to future applications by professional development teams working in other historical, geographical, or disciplinary contexts. This openness is intentional. The data warehouse is the product. The simulation is the instrument that fills it. The instrument can be replicated. --- ## 6. Open Opportunities The following four areas are not blocking the current development path. They are design gaps and conflicts that will determine the quality of the cooperative simulation when it is built. They are documented here so that future contributors — assistants, developers, domain experts, and participants — can engage with them with full context. No proposals are made here. The conflicts and tensions are described. Resolution belongs to future design work. --- ### Opportunity 1 — The Nomination Threshold **The gap:** The cooperative simulation requires that nominated clans be capable of participating without immediately collapsing or destabilising the shared environment. But the single simulation has no end condition and no defined success state. There is currently no mechanism by which the simulation can assess whether a clan is ready for nomination. **The conflict:** A threshold defined too loosely admits clans that are not viable and burden the cooperative simulation. A threshold defined too strictly prevents participants from nominating until they have reached an arbitrary standard that may not reflect actual readiness. The threshold must be meaningful without being a gate that reproduces the power imbalances DESCENSUS was designed to prevent. **Why this matters:** The cooperative simulation's balance depends on the entry states of its participants. If entry states vary too widely, the Model cannot maintain historical coherence without overriding participant decisions — which it must not do. --- ### Opportunity 2 — The Model's Balancing Authority **The gap:** The Model fills roles and responds to participant decisions. But the cooperative simulation involves 128 participants making decisions simultaneously. The aggregate effect of those decisions may produce states that are historically implausible — a single clan growing to dominate the region, a resource being exhausted before the epoch would permit it, a technology emerging before its time. **The conflict:** The Model cannot override participant decisions without breaking the simulation's honesty. But a simulation that allows historically implausible states to persist will lose its value as a research and educational instrument. The boundary between "responding to decisions" and "correcting decisions" is not yet defined. Where that boundary sits will determine what kind of instrument the cooperative simulation becomes. **Why this matters:** The Model's authority in the cooperative simulation is the most consequential design decision remaining. It determines the relationship between participant agency and simulation integrity — a tension that does not resolve itself. --- ### Opportunity 3 — The Epistemic Horizon of Participants **The gap:** A participant who has completed many single simulations carries knowledge about the environment that their nominated clan does not possess. The clan's knowledge is bounded by what it has experienced within the simulation. The participant's knowledge is bounded by everything they have learned across all their restarts. **The conflict:** The simulation cannot technically distinguish between a participant playing within their clan's epistemic horizon and a participant importing meta-knowledge from previous runs. The distinction is real and meaningful — a clan that makes decisions based on knowledge it could not have is not a faithful simulation participant. But enforcing the distinction requires either technical mechanisms that constrain participant agency or a social contract that depends on participant integrity. **Why this matters:** The epistemic horizon problem is present in every simulation that allows learning across sessions. It is particularly acute here because the single simulation is explicitly designed to produce meta-knowledge. The cooperative simulation must find a way to value that preparation without allowing it to corrupt the simulation's honesty. --- ### Opportunity 4 — The End Condition **The gap:** The cooperative simulation runs until 100 CE. But elapsed simulation time advances differently for different participants depending on their activity level, the compression ratio, and the state of their clan. The moment at which the simulation ends is not yet defined — whether it is a wall-clock event, an elapsed-time threshold, a consensus among participants, or a declaration by the Model. **The conflict:** An end condition defined by wall-clock time treats all participants equally regardless of how deeply they engaged. An end condition defined by elapsed simulation time rewards sustained engagement but may disadvantage participants who engaged less frequently for reasons outside the simulation. An end condition defined by the Model introduces the same authority questions raised in Opportunity 2. An end condition defined by participant consensus introduces social dynamics that may not align with simulation integrity. **Why this matters:** The end condition governs ranking, data preservation, and the simulation's historical closure. How the simulation ends determines what it means to have participated in it. This decision cannot be deferred indefinitely — it must be made before the cooperative simulation is designed in detail. --- ## 7. What This Vision Does Not Commit To - A launch date or development timeline - A specific compression ratio for elapsed simulation time - A definition of achievement or ranking criteria - A technical architecture for the cooperative simulation's infrastructure - A commercial model or licensing arrangement - A specific set of participant roles beyond the examples named These are all open. The vision is the frame. The frame is stable. Everything within it is subject to design work that has not yet begun. --- *SIMULATOR — Vision Document — 2026-05-02* *TheRON — single contributor. AI assistants implement, document, flag — do not direct.* *This document states intent. It does not constrain the path to that intent.* *Future contributors are invited to engage with the four opportunities.* *Resolution of any opportunity requires project owner approval before admission.*