EXP — mission, implementation, and launch gates

The world-first build plan defines the next delivery sequence: preserve the existing renderer and art, build a small /demo region, reveal HUD functions through PupBRO and context, then connect one complete chapter to durable plans. It includes the execution prompt and phase exit gates. It does not replace the system qualification work below.

Build a browser-only, pixel-art MMORPG where people learn useful things, survive consequential lives, and create a shared legacy with little required screen time. One player controls one life. Knowledge, relationships, history, and valid soul-bound heirlooms connect successive lives.

The galaxy contains 69,420 playable worlds in 999 clusters. Seeds establish physical possibilities; people and autonomous societies establish history. The 23-year Chronicle is a planning horizon. World completion is a measured outcome, not a scheduled unlock or a promise. Exploration can remain open-ended through combinations and changing societies; compute, storage, and authored content remain finite. Pixel art lowers some production costs but does not make simulation inexpensive.

The full design joins Ark salvage, materials, ecology, 23 skill trees, knowledge cards, households, governance, Coins, AGI, robotic people, transport, science-based magic, and bounded anomalies. World as Myth supports the fiction. Knowledge cards distinguish Earth evidence from in-world observations. The game remains educational fiction for 13+, with protected child NPCs and no explicit sexual content.

• Vision (repository reference): accepted design and open questions.
• Simulator plan: laboratory architecture and S0–S7 work.
• Migration ledger (repository reference): dated evidence of shipped behavior.
• Token model (repository reference): provisional allocation and release gates, including historical alternatives.
• Pitch deck: confidential summary, maintained after design rulings.

Local inspection at 47bd2399 found Next.js, Phaser, Socket.IO, Prisma/Postgres, and Vitest. Existing code and the migration ledger provide a reusable game foundation. The current CI runs lint, type-checking, tests, and build; database integration tests require a separate environment. The ledger reports one in-memory realtime world, restart disconnects, mobile gaps, and unverified gameplay flows. Those dated reports require a fresh reproduction before being called current defects. Gameplay code in services/realtime/adventure.ts still uses Math.random() and timers: deterministic world terrain does not establish deterministic gameplay. This review did not run production or benchmark capacity.

Keep working assets, rendering, authentication, and proven game flows. Introduce new rules through small adapters. Before Genesis, use versioned disposable test worlds and preserve source art. After Genesis, preserve accepted events and use governed corrections.

The latest conversation adds three chosen Legacy Anchors, fading association, level/relevance as possible weighting, and instantaneous player messages. Capture these before implementation. Exact fading weights remain open. Person-scale corridors, continuous-body passage, and partner access are proposals with unresolved throughput and fairness rules. Matter includes robotic bodies, equipment, medical devices, and passengers; biological identity cannot be a physical freight exemption.

Use a modular TypeScript application first. Extract a small, stable transition library consumed by both the live adapters and the laboratory. Scenario agents, acceleration, experimental rules, and analysis remain separate. Shared code needs independent fixtures; sharing a bug does not validate it.

Postgres defaults to Read Committed. Multi-record invariants need explicit locking or suitable isolation, plus full-transaction retries where required; a transaction alone is insufficient. See the official transaction-isolation documentation.

AGI in the fiction does not require one language-model call per NPC. Use deterministic policies, state machines, utility scoring, and scheduling for routine decisions. Optional generated dialogue consumes bounded context and budget and cannot commit domain mutations directly. Curated child interactions remain closed. Scientific lessons use reviewed, dated sources and correction history.

Represent civilization as a capability graph: services require materials, energy, tools, skills, labor, maintenance, transport, and institutions. Recipes conserve declared units and record yield, waste, and loss. Farms and forests have growth constraints; mineral deposits deplete. Material availability limits output even when knowledge spreads instantly. No single technology tier replaces the graph. Milestones require sustained, evidenced service and can later regress.

Use discrete-event scheduling for completion, travel, maintenance, incidents, and threshold changes. Use regional updates for weather and ecology, cohort updates for demography, and detailed steps for nearby interactions. Do not draw millions of NPCs or simulate them every frame. Pin high-consequence records, rather than assuming prisoners and caregivers need full movement simulation continuously.

Every run records scenario, ruleset, seed, parameters, policy, clock policy, content version, resolution, and initial-state hash. Output state, metrics, failures, and causal event references. Record commands and relevant inputs so a reported failure becomes a regression fixture.

Separate three uncertainties: random incidents, unknown parameter values, and behavior-model choice. Run outer sweeps over uncertain parameters and policies; use multiple seeds within each case. Compare candidate rules on matched seeds, then validate on withheld scenarios. Sensitivity sweeps identify which assumptions require better evidence. Monte Carlo does not establish that simulated people behave like real players.

Inputs, experiments, and outputs

• Inputs: 100/1,000/10,000/100,000 registered players; independent activity, concurrency, arrival, absence, and churn curves; populations and age structure; roughly 100 roles; Ark manifest and 10% delayed-survivor reserve; ecology; recipes; AGI capacity; robots; infrastructure; currency policy; governance; travel; hazards; and all rule versions. Player count and NPC count are separate axes.
• Policies: cooperative households, specialists, casual players, solo settlers, nomads, hoarders, opportunistic traders, hostile coalitions, absentee officials, and constrained autonomous workers.
• Scenarios: no players, sparse settlement, missing specialist, depleted cache, power loss, climate shock, birth boom, robot boom, trade isolation, monetary crisis, coordinated exploits, and recovery.
• Outputs: service coverage, inventories, prices and wages, inequality, time needed for essentials, care burden, population, ecosystem condition, work queues, deaths, recoveries, milestone timing, and cost per simulated world-day. Report medians and tails by world and player cohort.
• Causality: connect each shortage or death to depleted stocks, unmet dependencies, failed policies, and preceding events. Generated prose summarizes this evidence and cannot invent causation.

Run hand-calculated fixtures first, short settlement experiments second, then two-settlement trade, world networks, and complete Chronicle ensembles. Use a small smoke suite per PR, broader nightly sweeps, and costly full-horizon release runs. Stop unpromising candidates early. Retain compact metrics for ordinary runs and detailed traces for failed or selected runs.

Predeclare failure events and statistical precision. With zero failures in N independent comparable runs, the approximate 95% upper bound is 3/N, not zero. Thus 1,000 clean runs do not establish one-in-a-million reliability. Use targeted fault injection and carefully weighted rare-event sampling for severe tails; targeted scenarios alone do not estimate their real frequency. Test correlated disasters and uncertain behavior models separately. Calibrate with beta observations and repeat.

Under the nominal 23-days-per-real-day convention, a 23-year Chronicle spans roughly 193,000 Ark days or 365 Ark years. Daily updates for every world already total about 13.4 billion world-days. The implementation needs event skipping, safe aggregation, parallel batches, and measured cost budgets. These are planning approximations; DST, leap days, outages, and the Still Hour need one exact policy.

The ceiling of 69,420 mature worlds in 23 years implies about 3,018 outcomes annually. A six-month maturation target implies about 1,509 worlds developing concurrently under steady throughput. This arithmetic specifies capacity, not evidence of achievable progression. Measure maturity as a service profile; do not count abandoned or merely discovered worlds as fully developed.

Each stage produces a playable or reviewable artifact. Estimates follow measured throughput from the first two stages. The hypothetical 2027–2050 calendar must not force an unready Genesis launch.

The token layer is a separately gated workstream after wallet-free play works. Keep current token decisions provisional until supply, custody, fairness, security, and professional review support them. Chronicle funding cannot block gameplay milestones. Operator revenue and operating runway need a viable plan independent of future token appreciation or a celebrity endorsement.

Use the existing Vitest suite for domain work. Add isolated browser and load tooling when those gates are implemented. Playwright supports managed test web servers. k6 thresholds can fail a run on defined metrics. Test the actual Socket.IO protocol as well as HTTP; a synthetic socket connection alone does not exercise gameplay. Keep benchmark hardware, scenario, and seed with every report.

Proposed targets to calibrate in beta: median daily management at most ten minutes; at least 80% of testers explain their next action and the last incident; no mechanical harm for skipping optional notifications; representative phone play sustains 30 FPS; active commands meet a regional p95 budget of 250 ms. These are design targets, not current measurements or universal network guarantees.

Hard gates: zero known ledger/identity/safety invariant violations; no acknowledged irreversible event lost within the declared fault model; successful restoration from independent backups; published recovery-time and recovery-point budgets; a reproducible rule-version comparison; no unbounded catch-up; safe failure when dependencies or funds vanish. Statistical balance gates need explicit accepted ranges per cohort before evaluation. Track lifetime exposure: even a small daily death probability compounds severely over years.

Log costs for active player-hours, quiet world-days, NPC detail, stored events, egress, assets, moderation, and optional model calls. Set service budgets and automatic backpressure. A million-NPC stress test must fit a declared resource envelope before population expansion ships.

Keep signed release manifests, rule versions, seeds, migration tests, and reproducible builds. The Still Hour stops simulation clocks, expires no contract, and applies no catch-up death. Infrastructure may isolate damage immediately; permanent historical corrections follow the approved Still Hour and Council process. Rehearse corrections where goods have already been consumed or inherited. Preserve the original record and explain dependent-event compensation in the corrected state.

Retain canonical identity and high-value causal records. Aggregate routine telemetry under a stated retention policy. Store readable archives independently of chain receipts, periodically verify them, and rehearse operator succession and service shutdown/export. The Chronicle needs financial and organizational continuity as much as technical persistence.

Immediate experience gate: Your First Week in Experia (repository reference) specifies the small chapter, plan controls, learning encounters, and human playtests. Start its inexpensive interaction prototype alongside the rules work below. Build the real offline loop and small simulator from the same transitions. Neither an enjoyable mockup nor a balanced simulation proves the other.

1. Rules owner: reconcile aging, legacy custody, communication, and token-document conflicts; leave force rules and machine copies explicitly open. Produce a compact decision register.
2. Domain engineer: specify units, clocks, event order, seeded inputs, ledger ownership, and ten S0 fixtures. One must transfer goods between two settlements with a lost acknowledgment.
3. Simulation engineer: implement a CLI for one settlement and one Ark year, with stock reports and a causal failure trace. Compare balanced stores, missing medical staff, water failure, and excess robots with inadequate maintenance.
4. Game/UX engineer: connect the same transitions to a tiny player loop and validate one mobile check-in and offline return. Preserve the existing renderer while measuring cold-load cost.
5. Operations/test owner: add disposable database and restore tests, capture initial resource budgets, then attach each new rule to regression and scenario coverage.

These are responsibility labels, not a headcount assumption. Complete this proof before committing to a fleet of services, a complete 100-role implementation, or a galaxy-scale content backlog.

Independent refutation of the proposed architecture identified population growth, unlimited robot labor, aggregation drift, hidden Ark subsidies, rare-event blind spots, freight bypasses, and correction cascades. The gates above address each; their success remains to be demonstrated.