Implementation-Ready Technical Research Report for Chronology and Persistence in Simulation Earth

Full report

On this page

1. Architectural Preconditions and Strict Isolation Tenets

The Integrated Artificial Reality Planetary Atlas (IARPA.org) operates at the intersection of historical archiving and interactive deterministic simulation. The platform's defining feature, Simulation Earth, must seamlessly bridge read-only factual historical data and a branched, reversible, fictional "what-if" state engine running entirely within a client-side JavaScript Web Worker. The foundational architectural requirement is the mathematical and programmatic isolation of factual evidence from speculative simulation. The system utilizes a vanilla JavaScript and static JSON environment, entirely lacking a centralized database or user-account architecture. Consequently, the persistence contract relies entirely on browser-local storage mechanisms, portable JSON exports, and URL fragment deep links. These constraints demand an exceptionally rigorous approach to state canonicalization, schema validation, and storage durability. To prevent the contamination of historical records, the architecture completely prohibits the integration of real-world predictive forecasting, live targeting parameters, casualty calculation algorithms, and weapon-effect models. All persistence mechanisms must operate deterministically, rendering them immune to variations in wall-clock time, network availability, client locale, hardware speed, and browser tab suspension. The following specification delineates the complete chronology, state machine, replay, and migration architecture required to enforce these boundaries while ensuring bit-for-bit reproducible computing across disparate client environments.

2. Calendar Semantics and Temporal Framework

Time within Simulation Earth requires a bifurcated representation to reconcile the continuous, linear nature of a deterministic simulation engine with the inherent ambiguities of historical dating conventions. The engine relies on a continuous mathematical tick-counter, while the interface translates these ticks into human-readable epochs. To eliminate the discontinuity introduced by the historical adoption of the Gregorian calendar (and the ensuing "missing days" of 1582), the simulation engine relies exclusively on the Proleptic Gregorian Calendar for all internal date calculations1. This calendar projects the Gregorian leap-year rules backward indefinitely. Consequently, leap years are strictly calculated as years divisible by four, except those divisible by one hundred unless also divisible by four hundred, uniformly applied across the entire 10,000 BCE to 2026 CE timeline. The treatment of the BCE/CE boundary introduces significant computational risk. Internally, the simulation employs astronomical year numbering, where the integer 0 represents 1 BCE, \-1 represents 2 BCE, and so forth3. The user interface layer intercepts this internal representation and translates Year 0 to 1 BCE, entirely omitting "Year Zero" from graphical display to adhere to standard historical and archaeological conventions. Furthermore, the 32-bit integer overflow hazard (the "Year 2038 problem") is circumvented by utilizing JavaScript's native IEEE 754 double-precision floats for the core tick counter. This format safely represents integers up to [Figure omitted from source export], granting absolute microsecond precision for millions of years in either direction, easily encompassing the required epochs of 10,000 BCE and 3,500 BCE. Historical evidence frequently lacks exact day or month resolution, requiring a robust parser for temporal uncertainty. The system natively implements the Extended Date/Time Format (EDTF), codified in ISO 8601-2, for all factual catalog ingestions4. Partial dates (e.g., 1918-11-XX), uncertain dates denoted by modifiers (e.g., 1945?), and season-only bounds (e.g., 1990-21 for Northern Hemisphere Spring) are structurally permitted within the read-only historical catalog4. The temporal parsing engine utilizes EDTF bitmasks to resolve these imprecise historical records into strict minimum and maximum simulation day-index boundaries for timeline rendering6. Conversely, when recording the real-world ingestion or correction timestamps of factual data, the system utilizes the Internet Extended Date/Time Format (IXDTF) defined in RFC 95577. This format appends IANA time zone identifiers directly to the timestamp (e.g., 2026-08-05T07:48:59Z\[UTC\]), ensuring that localized administrative metadata is preserved without contaminating the strict Coordinated Universal Time (UTC) resolution of the simulation engine. Daylight-saving time shifts and leap seconds are strictly ignored by the simulation tick engine to preserve absolute determinism; a day is universally defined as exactly 86,400 simulation seconds. The antimeridian (International Date Line) hazard is similarly neutralized: the engine resolves all logic against the universal UTC tick, and local date labels are purely display-layer derivations that do not influence the deterministic mathematical state7.

3. Canonical Time Representation and Field Dictionary

To ensure rigid separation between factual history and fictional simulation, the state contract relies on a meticulously defined field dictionary. Authoritative simulation fields dictate the mathematical state of the Web Worker, while factual fields remain strictly bound to external evidence catalogs.

4. Historical-Event Ordering and Tie-Breaking

The chronological ordering of historical events is critical, as multiple events frequently share the same event\_effective\_date or overlap due to the partial resolution of EDTF bounds (e.g., an event in "October 1990" overlapping with an event on "October 15, 1990"). Furthermore, historical sources are periodically corrected or superseded. To guarantee deterministic replay without relying on arbitrary JavaScript array sorting implementations, all factual events are compiled into a static, globally ordered register using a strict, multi-pass tie-breaking algorithm. When the engine queries events for a specific day\_index, the following rules apply sequentially:

1. Temporal Bounding: Events are sorted primarily by their minimum bounded day\_index (derived from the EDTF event\_effective\_date).

2. Span Narrowing: If the minimum bounds are identical, events are sorted by their maximum bounded day\_index, prioritizing highly specific events (exact days) over broad spans (decades or seasons).

3. Administrative Precedence: If temporal bounds are identical, events are sorted lexicographically by their publication\_date.

4. Cryptographic Tie-Breaking: If all temporal and administrative metadata is identical, the system applies a cryptographic tie-breaker. The event payload is serialized using the JSON Canonicalization Scheme (RFC 8785), and a SHA-256 digest is generated10. Events are then sorted lexicographically by their hexadecimal digest12. This guarantees that two distinct events on the exact same day will always evaluate in the same sequence, regardless of the browser environment.

Supersession is managed via a declared supersedes\_id reference within the event payload. During the initialization of the historical register, any event whose ID matches a supersedes\_id in a newer record is structurally orphaned. When the deterministic engine reaches the relevant day\_index, it ignores the superseded event entirely, executing only the corrected historical record.

5. Authority Transitions and the Chronology State Machine

Simulation Earth transitions through a rigid state machine that governs the presentation of historical evidence, unverified projections, and fictional interactions. The architecture enforces visual, structural, and cryptographic isolation between these operational modes.

5.1 Mode Definitions

1. FACTUAL\_HISTORICAL: The default baseline state. The playback\_cursor is chronologically behind the declared\_observed\_through date. The Web Worker engine reads sequentially from the read-only Current Statistics register. The interface displays verifiable historical evidence. All user interventions and synthetic cell mutations are strictly locked.

2. NUCLEAR\_ARCHIVE\_VIEW: A specialized, tightly bounded read-only state specifically designed for the Nuclear Detonation Archive. The timeline is hard-locked between the Trinity test on July 16, 1945, and the final recorded test on September 3, 2017\. Fictional branches cannot be spawned from this state, projections are forbidden, and the engine will clamp the playback cursor if the user attempts to scroll beyond these boundaries.

3. PROJECTION\_REGISTER: Triggered when the playback\_cursor crosses the declared\_observed\_through date without user intervention. The engine continues reading from a separate register of projected statistics. The interface must deploy a persistent, high-visibility overlay announcing "PROJECTION MODE BEGINS". The data in this state is strictly defined as unverified forecasting and must not be presented as historical fact.

4. FICTIONAL\_BRANCH\_ACTIVE: Triggered the moment a user executes a mutation, intervention, or parameter change against the baseline. This immediately spawns an isolated fictional branch. The interface must deploy a persistent, high-visibility overlay announcing "WHAT-IF MACHINE ACTIVE". The deterministic simulation engine detaches from the factual historical registers and assumes full authoritative control over state updates, relying solely on the PRNG and the user's intervention ledger.

5. RESET\_TO\_BASELINE: A transitional cleanup state. When the user selects "Return to Baseline," the fictional branch is immediately terminated. The branched state array is scrubbed from browser memory, and the engine re-synchronizes with either FACTUAL\_HISTORICAL or PROJECTION\_REGISTER based on the requested temporal coordinates. Fictional outcomes are mathematically isolated and are never published back to the factual registers.

5.2 State Machine Enforcement Diagram

The exact formal state machine for chronology transitions is defined as follows: \[INIT\] \--\> Load Epoch Payload \--\> \[FACTUAL\_HISTORICAL\] \[FACTUAL\_HISTORICAL\] |-- (cursor \> declared\_observed\_through) \---\> \[PROJECTION\_REGISTER\] |-- (user\_executes\_intervention) \-----------\> \[FICTIONAL\_BRANCH\_ACTIVE\] |-- (invoke\_nuclear\_archive\_context) \-------\> \[NUCLEAR\_ARCHIVE\_VIEW\] \[PROJECTION\_REGISTER\] |-- (cursor \< declared\_observed\_through) \---\> \[FACTUAL\_HISTORICAL\] |-- (user\_executes\_intervention) \-----------\> \[FICTIONAL\_BRANCH\_ACTIVE\] \[FICTIONAL\_BRANCH\_ACTIVE\] |-- (execute\_reset\_command) \----------------\> \[RESET\_TO\_BASELINE\] |-- \[RESET\_TO\_BASELINE\] \--------------------\> \[FACTUAL\_HISTORICAL\] \[NUCLEAR\_ARCHIVE\_VIEW\] |-- (exit\_archive\_context) \-----------------\> \[FACTUAL\_HISTORICAL\]

6. Branching, Fictional Determinism, and Seed Derivation

Upon entering FICTIONAL\_BRANCH\_ACTIVE, the system creates a mathematically isolated timeline. Because this timeline resolves hypothetical events, it relies on a Pseudo-Random Number Generator (PRNG). To guarantee that a saved branch replays identically on any hardware, this PRNG must be perfectly deterministic. The use of wall-clock time, system entropy, Math.random(), or network availability is explicitly forbidden.

6.1 Cryptographic Seed Derivation

The initial seed for the branch's PRNG is derived via HMAC-SHA25613. The HMAC key is a static environmental constant, while the message payload is a concatenated string containing the epoch\_baseline, the sim\_tick of the divergence, and the SHA-256 digest of the canonicalized JSON representation of the user's specific divergence\_event payload. This guarantees that branching from the same historical tick with the exact same intervention yields an identical pseudo-random sequence, while altering even a single parameter of the intervention generates a vastly divergent mathematical timeline.

6.2 PRNG Algorithm Selection

The simulation engine utilizes the Xoshiro256\\ algorithm14. This algorithm provides 256 bits of internal state, demonstrating exceptional statistical quality and rapid execution performance within JavaScript Web Workers, significantly outperforming legacy algorithms like Mulberry32 in deep-iteration scenarios15. The PRNG state is explicitly serialized into the save ledger during keyframe snapshots to allow mid-branch resumption without recalculating millions of prior cycles.

6.3 Floating-Point Determinism

JavaScript universally utilizes IEEE 754 double-precision floating-point numbers16. Cross-browser, bit-exact floating-point determinism is historically volatile due to engine-level discrepancies (e.g., V8 versus SpiderMonkey) in handling transcendental functions, subnormal numbers, and instruction-set optimizations18. To prevent the "butterfly effect" from causing divergent simulation outcomes across different users' browsers, the engine enforces strict mathematical bounds:

1. No Transcendental Math: The simulation engine strictly prohibits the use of native JavaScript trigonometric functions (Math.sin, Math.cos) or non-integer exponentiation. If non-linear scaling is required for synthetic cell dynamics, the engine utilizes a deterministic, integer-backed polynomial approximation library.

2. Fixed-Point Emulation: Synthetic cell metrics (e.g., population dynamics, resource indices) and global metrics are calculated using exact scaled integers. For example, a resource multiplier of 15.325 is stored and calculated internally as the integer 15325\.

3. Strict Safe Integer Bounds: All logic must remain well within the safe integer limit of JavaScript (Number.MAX\_SAFE\_INTEGER, or [Figure omitted from source export]). Before any multiplication that risks exceeding this bound, factors are mathematically truncated using BigInt structures, though BigInt is avoided in hot loops to preserve performance15.

6.4 Inherited Facts and Branch Comparison

Upon divergence, the new branch records its parent\_branch\_id and copies the exact mathematical state of the 48 synthetic cells at the divergence\_tick. Immutable baseline historical references remain accessible as read-only lookups but are detached from the active simulation loop. Because factual history and fictional branches share the exact same 48-cell data topology, the system can perform a delta comparison at any sim\_tick post-divergence, generating visual heatmaps highlighting exact numerical divergences in global metrics without risking state contamination.

7. Playback Semantics and Browser Environment Throttling

Normal pacing dictates approximately one simulated day per real second. However, modern web browsers aggressively throttle background tabs, suspending requestAnimationFrame and setTimeout loops to preserve battery life21. If the deterministic engine relied on these APIs for logic resolution, a user minimizing the browser would silently desynchronize the chronological clock, corrupting the branch. To guarantee environment-agnostic deterministic playback, the Web Worker operates on a closed while loop architecture that calculates exact state up to a target sim\_tick18. The simulation logic is entirely decoupled from the presentation frame rate.

• Pacing and Suspension: The main UI thread manages wall-clock pacing. It sends a message to the Web Worker specifying a target sim\_tick. The worker calculates the state as fast as the hardware allows and buffers the result. If the browser suspends the tab, the UI thread stops requesting frames, safely pausing the worker. When resumed, it seamlessly continues from the last known tick.
• Rewind Operations: Because the simulation PRNG is purely forward-deterministic, true reverse-calculation is mathematically impossible. Rewind is achieved by locating the closest prior keyframe snapshot in memory, deserializing the state, and silently fast-forwarding the deterministic engine (without emitting UI updates) until the target historical sim\_tick is achieved.

8. History Storage, Memory Limits, and Performance Model

A single fictional branch can encompass tens of thousands of sim\_tick iterations. Serializing and storing the complete 48-cell state at every tick would rapidly exhaust the Web Worker's memory heap and trigger IndexedDB quota evictions, destroying user data21.

8.1 Snapshot and Delta Architecture

The persistence model relies on a highly optimized hybrid Snapshot/Delta storage architecture:

• Keyframes (Snapshots): A complete, canonical serialization of the 48 synthetic cells, global metrics, and the precise 256-bit PRNG state. Keyframes are captured exactly every 365 sim\_ticks (one simulated year), or immediately preceding a user intervention. The memory overhead is aggressively optimized to approximately 15 KB per snapshot.
• Deltas (Ledger): Between keyframes, the system stores only the sparse ledger of user interventions. The deterministic engine calculates the rest on demand.

For very long sessions, the system implements a Least Recently Used (LRU) compaction strategy. If the branch history exceeds 1,000 keyframes, the system begins deleting intermediate snapshots, retaining only decade-markers and intervention boundaries. The Web Worker can reconstruct any deleted frame by fast-forwarding from an earlier snapshot, trading a fraction of a second of compute time for massive memory savings.

9. Failure-Recovery Specification and IndexedDB Resilience

Client-side persistence via IndexedDB is notoriously fragile. Browsers routinely evict databases without warning when disk quotas are exceeded, and asynchronous writes can be silently interrupted by service worker restarts or tab closures21. The Atlas Save Architecture 2.0 treats local storage with database-level paranoia.

9.1 Preventing the Dual-Write Problem and Corruption

If an IndexedDB write operation is interrupted halfway through a massive save payload, the database is left in a corrupted state23.

1. Double-Buffering: Saves are never overwritten in place. The system writes the serialized state to a new, temporary IndexedDB record (e.g., save\_slot\_1\_temp).

2. Strict Durability: The IndexedDB transaction must be explicitly requested with durability: 'strict'24. While Chromium-based browsers offer a relaxed durability mode that significantly improves throughput by delegating flushes to the operating system21, a power failure or crash during a relaxed write will destroy the data24. Strict mode forces the OS to flush the transaction to the physical disk before firing the completion event.

3. Atomic Commit: Only after the oncomplete event fires for the temporary write does the system execute an atomic pointer swap, designating the temporary record as the primary save, followed by safely deleting the older record27.

9.2 Quota Eviction Defense

To defend against silent browser eviction, the application implements a strict storage budget. Large JSON payloads, such as full historical response bodies, are strictly excluded from IndexedDB storage21. The application intercepts the navigator.storage.estimate() API prior to any save event. If the quota is within 10% of exhaustion, the system triggers a user-facing warning and initiates a compaction routine to purge old keyframes before attempting the write.

10. Replay Integrity: Canonical Serialization and Hash Verification

To cryptographically prove that two browsers reconstruct the exact same state, the system employs a verifiable ledger utilizing the JSON Canonicalization Scheme (JCS), formally specified in RFC 878529.

10.1 The Canonicalization Imperative (RFC 8785)

Standard JSON.stringify() is highly non-deterministic. Object key order, whitespace insertion, and specific floating-point string representations vary based on the specific JavaScript engine version and architecture13. If two systems serialize identical logical state into different byte sequences, cryptographic hashes fail, destroying replay verification10. RFC 8785 guarantees byte-identical UTF-8 outputs by enforcing strict, implementation-agnostic rules:

• Key Sorting: Lexicographical sorting of object keys based on their UTF-16 code units10. This differs critically from UTF-8 byte sorting for supplementary plane characters, ensuring compatibility across web environments33.
• Whitespace: Absolute elimination of insignificant whitespace between tokens30.
• Number Serialization: Strict adherence to the ECMAScript number serialization algorithm (ECMA-262, Section 7.1.12.1)29. This dictates the exact transition points for exponential notation and explicitly handles edge cases, such as enforcing that negative zero (-0) serializes as "0", eliminating platform-specific sign retention31.
• I-JSON Validation: Enforcement of the I-JSON profile (RFC 7493), which actively rejects duplicate keys and imposes strict limits on number precision to prevent parsing discrepancies29.

10.2 Ledger Chaining and Verification Protocol

Every intervention and snapshot keyframe in a fictional branch is recorded in the deterministic ledger. The cryptographic chaining protocol operates as follows:

1. Payload Generation: When an event is triggered, generate a minimal event\_payload object containing the mutated parameters.

2. Chain Retrieval: Extract the previous\_event\_hash from the tail entry of the ledger.

3. Block Construction: Construct a verification block: { "payload": event\_payload, "prev\_hash": previous\_event\_hash, "tick": sim\_tick }.

4. Canonicalization: Serialize the verification block using an RFC 8785-compliant canonicalizer11.

5. Digest Calculation: Compute the SHA-256 digest of the resulting UTF-8 canonical byte sequence10.

6. Append: Append the resulting digest to the ledger entry as the current\_event\_hash.

When a user imports a saved simulation file, the system extracts the initial seed and replays the ledger interventions through the deterministic engine. If the terminal state's newly computed SHA-256 hash perfectly matches the integrity\_hash recorded in the imported file, the cryptographic integrity of the simulation is mathematically proven, guaranteeing that no external tampering or browser-specific mutation occurred38.

11. Save, Export, and Schema Design (Simulation-Save/2.0)

Exported saves serve as portable artifacts for sharing specific educational scenarios. Because they cross boundaries between untrusted client environments, they must fail-closed on tampering and defend against malicious payload injection. The schema utilizes JSON Schema Draft 2020-12 to provide advanced structural validation40.

11.1 JSON Schema Draft 2020-12 Advantages

Draft 2020-12 introduces critical features for securing closed-world data structures:

• prefixItems: This keyword replaces the legacy array items approach for tuple validation. It guarantees that the synthetic\_cells array strictly adheres to an exact 48-item positional schema, ensuring structural rigidity41.
• unevaluatedProperties: When explicitly set to false at the object level, this keyword ensures that no unexpected or unmapped fields can be nested within the JSON hierarchy, even when evaluating complex allOf or anyOf schema branches42. This provides ironclad protection against prototype pollution vectors and payload stuffing40.

11.2 The Atlas Save 2.0 Schema Definition

JSON { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://iarpa.org/schemas/simulation-earth-save-v2.json", "type": "object", "properties": { "schema\_version": { "type": "string", "const": "2.0" }, "release\_identifier": { "type": "string", "pattern": "^\[0-9\]+\\\\.\[0-9\]+\\\\.\[0-9\]+$" }, "fictional\_classification": { "type": "boolean", "const": true }, "real\_world\_targeting": { "type": "boolean", "const": false }, "scenario\_id": { "type": "string" }, "branch\_id": { "type": "string", "pattern": "^\[a-f0-9\]{64}$" }, "sim\_tick": { "type": "integer", "minimum": 0 }, "day\_index": { "type": "integer" }, "current\_date": { "type": "string", "pattern": "^-?\[0-9\]{4}-\[0-9\]{2}-\[0-9\]{2}$" }, "speed": { "type": "number", "minimum": 0, "maximum": 10 }, "is\_paused": { "type": "boolean" }, "global\_metrics": { "type": "object", "patternProperties": { "^\[a-z\_\]+$": { "type": "integer" } }, "unevaluatedProperties": false }, "synthetic\_cells": { "type": "array", "minItems": 48, "maxItems": 48, "prefixItems": \[ { "$ref": "\#/$defs/cell\_schema" } \], "items": false }, "ledger": { "type": "array", "items": { "$ref": "\#/$defs/ledger\_entry" }, "maxItems": 50000 }, "integrity\_hash": { "type": "string", "pattern": "^sha256:\[a-f0-9\]{64}$" } }, "required": \[ "schema\_version", "fictional\_classification", "real\_world\_targeting", "scenario\_id", "sim\_tick", "synthetic\_cells", "ledger", "integrity\_hash" \], "unevaluatedProperties": false, "$defs": { "cell\_schema": { "type": "object", "properties": { "cell\_id": { "type": "integer", "minimum": 0, "maximum": 47 }, "population": { "type": "integer", "minimum": 0 }, "resource\_index": { "type": "integer", "minimum": 0 } }, "required": \["cell\_id", "population", "resource\_index"\], "unevaluatedProperties": false }, "ledger\_entry": { "type": "object", "properties": { "tick": { "type": "integer" }, "action\_type": { "type": "string" }, "payload": { "type": "object", "unevaluatedProperties": false }, "hash": { "type": "string", "pattern": "^sha256:\[a-f0-9\]{64}$" } }, "required": \["tick", "action\_type", "payload", "hash"\], "unevaluatedProperties": false } } }

12. Import Security, Usability, and Payload Fuzzing

The import handler represents the primary vector for maliciously crafted data. The system implements a defense-in-depth pipeline to sanitize incoming saves prior to state integration.

• Size and Resource Limits: The raw JSON file is strictly bounded to a 5 MiB ceiling. Uploads exceeding this threshold are immediately rejected at the File API layer, circumventing JSON.parse entirely to prevent denial-of-service memory exhaustion attacks32. Furthermore, the parser limits maximum nesting depth and array lengths to prevent stack overflow exploits.
• Prototype Pollution Defenses: The strict enforcement of unevaluatedProperties: false ensures that malicious keys such as \_\_proto\_\_ or constructor are aggressively rejected by the JSON Schema validator before they can pollute the JavaScript runtime environment40.
• Data Masking and Local Notes: Users frequently utilize browser extensions that inject tracking strings, or attempt to save custom localized annotations within JSON files. The strict schema structure rejects any unrecognized string fields, explicitly preventing the accidental inclusion of sensitive Personally Identifiable Information (PII) or exact browser-local notes in portable public artifacts.
• Coordinate Bounds Checking: The synthetic\_cells array is structurally clamped. Any cell identifying beyond the strict 0-47 topological boundary is instantaneously rejected, preventing out-of-bounds rendering exceptions in the WebGL canvas.
• Preview-Before-Replace: To maximize usability and prevent accidental data destruction, a valid import does not immediately overwrite the user's active session. The file is validated in an isolated memory buffer, and a modal overlay presents a human-readable summary of the imported scenario (Date, Scenario ID, Ledger Length) for explicit user confirmation before executing the IndexedDB pointer swap.

13. Save Migration Matrix and Idempotent Rollback

As Simulation Earth receives software updates, legacy save formats must be mapped to newer logic without corrupting the historical ledger or invalidating the deterministic hash chain. Migration operates strictly as an in-memory transformation executed prior to schema validation. Disk states are never overwritten until the entire migration and validation pipeline succeeds.

13.1 Version-to-Version Migration Registry

13.2 Forward Incompatibility and Downgrade Policy

If the browser client is currently running Engine Version 1.5, and the user attempts to import a Version 2.0 save file, the import MUST fail closed. The UI will prompt the user to execute a hard-refresh to fetch the latest application code. Partial downgrades are structurally prohibited; executing newer intervention payloads within older deterministic worker routines will irreparably desynchronize the math engine and crash the simulation. However, "clean" baseline saves—those representing the default starting epoch where the ledger length is exactly 0—can bypass legacy delta migrations and map directly to the instantiation logic of the target engine version.

14. Deep Links, Shared State, and PII Leakage Prevention

Simulation Earth supports URL fragment sharing to facilitate educational dissemination and collaborative analysis. However, encoding massive simulation states into URLs risks "Query String Sprawl," hitting HTTP server limits, and accidentally exposing PII.

• View State Encoding: The URL hash fragment (\#) never contains the full JSON payload. It strictly encodes the minimum viable deterministic parameters: schema\_version, scenario\_id, branch\_id, sim\_tick, and a Base64URL-encoded SHA-256 pointer to the initial divergence event.
• Truth Boundary Enforcement: The URL explicitly includes a mode flag (e.g., ?mode=fiction or ?mode=history). If a user attempts to spoof reality by sharing a fictional branch URL with the query parameter ?mode=history, the application detects the presence of the branch\_id deterministic seed. It immediately halts rendering and forces an impenetrable error overlay: "Invalid Link: Fictional state cannot be rendered as historical fact." This ensures that shared fictional states cannot be maliciously framed as factual evidence.
• Payload Obfuscation: Complex user intervention payloads are explicitly prohibited from occupying the URL string. Resolving a deep link requires either a backend cloud ledger lookup (if deployed) or the manual importation of the JSON save artifact to unpack the specific parameter mutations.

15. Canonical Date and Chronology Test Vectors

To guarantee absolute consistency across disparate browser environments and engine updates, the following 50 canonical test vectors must be integrated into the continuous integration suite. Any engineering team can write automated tests parsing the "Input", executing the engine state, and asserting the "Expected Result".

16. Prioritized Implementation Backlog

To systematically structure the engineering workflow, features are categorized into four semantic action flags, directing immediate development efforts and identifying strict prohibitions.

• SAFE-NOW:
• Implement Proleptic Gregorian day-index algorithms to handle deep BCE/CE transition mathematics.
• Write JSON Schema Draft 2020-12 validation bindings utilizing a secure runtime validation library (e.g., Ajv v8).
• Implement the RFC 8785 canonicalization routine to ensure strict UTF-16 key sorting and precise ECMA-262 number formatting for Ledger hashing.
• Build the core 5-state Chronology State Machine inside the isolated Web Worker context.
• PROTOTYPE:
• Develop the IndexedDB double-buffered strict persistence layer, testing explicitly against browser quota eviction limits and durability: 'strict' flush timings.
• Build the hybrid Snapshot/Delta fast-forward engine to execute visual rewind functionality via rapid background recalculation.
• Implement URL Fragment parsing for Deep Links, actively enforcing the mode boundary detection overlay.
• REVIEW-REQUIRED:
• Adaptation of the EDTF (ISO 8601-2) parsing library. Extensive QA is required to ensure that approximate historical date ranges resolve predictably without crashing the exact-tick boundary requirements of the simulation engine.
• Implementation of the Version Migration Matrix, ensuring legacy JSON objects cleanly map to the strict 0-47 array schema without introducing silent null values.
• REJECT (Non-Negotiable):
• Integration of predictive statistical models attempting real-world sociological or economic forecasting.
• Implementation of real-world geographic targeting arrays or coordinate resolution beyond the abstraction of the fictional 48-cell topology.
• Inclusion of individual casualty numbers, specific demographic risk models, or localized weapon-effect algorithms.
• Permitting user-generated free-text fields (e.g., "notes") inside the portable JSON exports, effectively neutralizing a major PII leakage vector.

This exhaustive specification establishes an impenetrable technical partition between historical evidence and deterministic simulation. By mandating Proleptic Gregorian indexing, ISO 8601-2 (EDTF) parsing, RFC 8785 cryptographic canonicalization, and JSON Schema Draft 2020-12 validation, this architecture guarantees bit-exact reproducible computing across all divergent client environments, preserving Simulation Earth as a stable, truthful, and analytically rigorous platform.

Works cited

1. Julian day \- Wikipedia, https://en.wikipedia.org/wiki/Julian\_day

2. Gregorian/Julian change dates and era codes · Issue \#5 · tc39, https://github.com/tc39/proposal-intl-era-monthcode/issues/5

3. The Art of Time-Keeping, Part 1: Years and Dates | Quantum, https://quantum5.ca/2022/02/16/art-of-time-keeping-part-1-years-dates/

4. ISO 8601 Conformance Guide — Tempo v0.21.0 \- Hexdocs, https://hexdocs.pm/ex\_tempo/iso8601-conformance.html

5. Extended Date/Time Format (EDTF) Specification \- Library of Congress, https://www.loc.gov/standards/datetime/

6. inukshuk/edtf.js: Extended Date Time Format (ISO 8601-2 / EDTF) Parser for JavaScript \- GitHub, https://github.com/inukshuk/edtf.js/

7. RFC 9557 \- Date and Time on the Internet: Timestamps with Additional Information, https://datatracker.ietf.org/doc/html/rfc9557

8. RFC 9557 \- Date and Time on the Internet: Timestamps with Additional Information, https://datatracker.ietf.org/doc/rfc9557/

9. ISO 8601 \- Wikipedia, https://en.wikipedia.org/wiki/ISO\_8601

10. Determinism: Why Consistent Encodings Matter \- The CBOR, dCBOR, and Gordian Envelope Book, https://cborbook.com/part\_2/determinism.html

11. vr\_jcs \- Rust \- Docs.rs, https://docs.rs/vr-jcs

12. @scenesystems/digest \- npm, https://www.npmjs.com/package/@scenesystems/digest

13. The JSON Canonicalisation Scheme (RFC 8785\) in action and how to secure JSON objects with HMAC \- Connect2id, https://connect2id.com/blog/how-to-secure-json-objects-with-hmac

14. GitHub \- rtmigo/xrandom\_dart: Dart library with random number generators focused on the consistency, performance and reproducibility, https://github.com/rtmigo/xrandom\_dart

15. jurerotar/ts-seedrandom: Seeded random number generators for TypeScript. \- GitHub, https://github.com/jurerotar/ts-seedrandom

16. Floating-Point Determinism | Random ASCII \- tech blog of Bruce Dawson, https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/

17. Complementing JavaScript in High-Performance Node.js and Web Applications with Rust and WebAssembly \- MDPI, https://www.mdpi.com/2079-9292/11/19/3217

18. nape-js/docs/guides/troubleshooting.md at master \- GitHub, https://github.com/NewKrok/nape-js/blob/master/docs/guides/troubleshooting.md

19. Floating point determinism in Unity: Intel vs AMD, https://discussions.unity.com/t/floating-point-determinism-in-unity-intel-vs-amd/813566

20. UC San Diego Electronic Theses and Dissertations \- eScholarship.org, https://escholarship.org/content/qt7st3z2ws/qt7st3z2ws.pdf

21. Why Your IndexedDB Data Keeps Disappearing \- DEV Community, https://dev.to/denyherianto/why-your-indexeddb-data-keeps-disappearing-1m0a

22. Best Practices for Persisting Application State with IndexedDB | Articles \- web.dev, https://web.dev/articles/indexeddb-best-practices-app-state

23. Understanding the Dual-Write Problem and Its Solutions \- Confluent, https://www.confluent.io/blog/dual-write-problem/

24. A change to the default durability mode in IndexedDB | Blog \- Chrome for Developers, https://developer.chrome.com/blog/indexeddb-durability-mode-now-defaults-to-relaxed

25. Speeding up IndexedDB reads and writes \- Nolan Lawson, https://nolanlawson.com/2021/08/22/speeding-up-indexeddb-reads-and-writes/

26. Solving IndexedDB Slowness for Seamless Apps | RxDB \- JavaScript Database, https://rxdb.info/slow-indexeddb.html

27. Conflicting purposes of IndexedDB transactions \- Stack Overflow, https://stackoverflow.com/questions/27791057/conflicting-purposes-of-indexeddb-transactions

28. Indexed Database API 3.0 \- W3C, https://www.w3.org/TR/IndexedDB/

29. RFC 8785 \- JSON Canonicalization Scheme (JCS) \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc8785/

30. RFC 8785 \- JSON Canonicalization Scheme (JCS) \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc8785

31. RFC 8785 \- JSON Canonicalization Scheme (JCS) 日本語訳, https://tex2e.github.io/rfc-translater/html/rfc8785.html

32. json-canon: A Strict RFC 8785 Implementation in Go for Deterministic JSON, https://dev.to/lenny321/json-canon-a-strict-rfc-8785-implementation-in-go-for-deterministic-json-3mfg

33. GitHub \- lattice-substrate/json-canon: Deterministic RFC 8785 JSON Canonicalization Scheme (JCS) for Go: strict parser, canonical serializer, and stable CLI ABI., https://github.com/lattice-substrate/json-canon

34. jsontext package \- github.com/go-json-experiment/json/jsontext \- Go Packages \- The Go Programming Language, https://pkg.go.dev/github.com/go-json-experiment/json/jsontext

35. AlgoVoi §3.8 byte-match validation receipt — CTEF v0.3.1 \+ APS v1 \- Gist, https://gist.github.com/chopmob-cloud/5f35eaa527d292bf3ddc52f8725a85c9

36. Releases \- PEAC Protocol, https://www.peacprotocol.org/releases

37. Deterministic JSON Serialization for Signature-Safe Policy Hashing, https://sigilcore.com/blog/cryptographic-attestation/deterministic-json-serialization-for-signature-safe-policy-hashing

38. Integrity Verification | Portable AI Memory, https://portable-ai-memory.org/interop/integrity/

39. A SCITT Profile for Pre-Execution AI Action Authorization Records, https://www.nic.funet.fi/index/internet-drafts/draft-munoz-scitt-permit-profile-01.html

40. Changes from Ajv v6.12.6 to v8.0.0 \- Ajv JSON schema validator, https://ajv.js.org/v6-to-v8-migration.html

41. draft 2020-12 \- Ajv JSON schema validator, https://ajv.js.org/json-schema.html

42. Understanding JSON Schema, https://json-schema.org/UnderstandingJSONSchema.pdf

43. Elimination of annotation dependencies in validation for Modern JSON Schema \- arXiv, https://arxiv.org/pdf/2503.11288

44. draft-bates-atp-test-vectors-00 \- ATP Core Test Vectors \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-bates-atp-test-vectors/00/

45. Correctover Conformance Shape (CCS): A Receipt and Binding Specification for Agent Runtime Verification \- IETF, https://www.ietf.org/archive/id/draft-correctover-ccs-00.html