Day-0 Guide
General enterprise visibility, with access to the enterprise's general document spaces. No HR or payroll compartment access.Viewing as Enterprise Reader
Chapter 08 of 13PHASE 10

How do you let a frozen enterprise move without destroying the reference?

Day-0 must remain stable.

Simulation must be allowed to change the company.

Those requirements conflict unless Metrolane separates the two estates.

Understand

Keep a master copy and a working copy

Conceptually:

Day-0 reference estate
frozendeterministicreproducible

derive / reset

Runtime estate
mutableprogresses through business timeaccumulates new history

The simulator works on runtime.

The reference remains untouched.

Real-life analogy

Think of a flight simulator.

You may have a saved training scenario:

aircraft at gatefuel 82%weather Xpassengers boarded

Every training run can start from that known scenario.

The session changes.

The saved reference does not.

RESET

A RESET run means:

  1. runtime estate
  2. ↓ reset
  3. ↓ reseed from Day-0
  4. ↓ begin simulation

Use it for: development, verification, scenario testing, replay, repeatable experiments.

CONTINUE

A CONTINUE run means:

  1. keep current runtime state
  2. ↓ move forward

That supports a synthetic enterprise that accumulates history across runs.

Important distinction

RESET is not rewind-in-place

The important idea is not:

move a clock backwards

It is:

restore/derive the runtime from the known Day-0 reference

so that the starting estate is known again.

See it in Metrolane

The reference side

The current Day-0 Explorer shows the frozen reference estate.

For example:

are inspectable Day-0 records/states.

The Guide then explains the runtime copy conceptually.

There is no need to fabricate a runtime Explorer page before the runtime product exists.

Runtime isolation

The runtime must never accidentally point at the Day-0 reference database for mutation.

That is one of the most important safety boundaries in the simulator architecture.

Conceptually:

verify actual runtime database identity before any mutation

Not merely:

environment variable says runtime

Why this matters for replay

Suppose you run the same plan twice.

If the second run starts from a different enterprise state, different results do not necessarily mean replay is broken.

So deterministic verification needs:

known referenceknown runtime starting stateknown plan
Go deeper
Reference identity vs run identity

Later runtime architecture distinguishes:

Reference estate identity
Which Day-0/reference did we start from?
Run identity
Which execution attempt is this?
Plan identity
Which intended sequence of business actions is being executed?

A replay can use a new run identity while executing the same recorded plan from the same reference baseline.

Chapter takeaway

  • Day-0 is the immutable reference.
  • Runtime is the mutable working enterprise.
  • RESET restores a known Day-0-derived starting point.
  • CONTINUE keeps the current evolving runtime.
  • This separation protects reproducibility and makes replay meaningful.