270 lines
12 KiB
Markdown
270 lines
12 KiB
Markdown
# 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.*
|