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 10 of 13PHASE 10

Day-0 gives us the enterprise. Phase 10 makes tomorrow happen.

At Day-0, Metrolane already contains a believable company.

Customers exist. Orders exist. Documents exist.

Source systems, canonical data, lineage and scenarios exist.

Phase 10 asks a different question:

What should happen next — and how do we make it happen without breaking the enterprise rules that already exist?
Understand

Phase 10 is not:

generate another million rows

It is a runtime that repeatedly decides:

  • what business activity should occur?
  • when should it occur?
  • which real business objects does it affect?
  • which system acts?
  • which approved command runs?
  • what downstream work becomes due?
  • when do extraction and projection catch up?
  • what should remain intentionally delayed?
  • can the same run be replayed?

The runtime path

  1. 01Day-0 Reference Estate
  2. 02Runtime Estate
  3. 03Enterprise Clock
  4. 04OccurrencePlan
  5. 05Activity Binding
  6. 06ExecutionPlan
  7. 07Business-Time Queue
  8. 08Commands / Handlers
  9. 09Relays
  10. 10Connector Extraction
  11. 11Canonical Projection
  12. 12Grounding Visibility
  13. 13Replay / Verification

This looks like a long chain.

Each layer has one job.

Reference estate vs runtime estate

Day-0 remains the frozen reference.

Phase 10 works on a mutable runtime copy.

Day-0
reference / master statedo not mutate

derive

Runtime
working enterpriseallowed to changeallowed to accumulate history

This gives us:

RESET
→ return to a known Day-0-derived starting point
CONTINUE
→ keep the current runtime state and move forward

OccurrencePlan — What should happen?

Before executing work, decide the expected business activity. For example:

Day 1CRM lead-to-order activity14:00 close opportunity15:00 downstream handoff

This is an occurrence plan. It describes what is due to happen.

Activity Binding — To which actual records?

The plan may know execute CRM lead-to-order but still need to resolve: which account? which opportunity? which item? which actor? which business key?

Some of those records may only exist after an earlier business-time point commits. So binding happens when enough prior state exists.

ExecutionPlan — What exactly will we invoke?

Once the concrete records and actions are known, the runtime records the exact work to execute. Conceptually:

timeactorcommandpayloadcorrelationcausationexpected outcome

This is what makes later replay possible.

See it in Metrolane

Completed handoff vs lag

Completed handoff

handoff

Day-0 lag

expected

ERP Sales OrderNot present at Day-0

Together they show:

ordinary completed handoffversusintentionally incomplete handoff

Phase 10 later decides when and whether downstream work should progress.

Business-time queue

The runtime can be understood simply as an ordered queue of business-time points.

Example:

  1. 14:00
    close CRM opportunityCRM
  2. 15:00
    run CRM → ERP handoffCRM → ERP
  3. 18:00
    extract changed source dataConnector
  4. 18:30
    project canonical updatesCanonical

Each committed time point can leave behind a real intermediate enterprise state.

Commands and handlers still own business rules

The simulator does not become a privileged database writer.

It calls the same business actions used by the rest of the system.

Conceptually:

UIRelaySimulatorFuture AI
Command / Handler

That means the simulator does not create a second version of the company with different mutation rules.

Scenario suppression

Sometimes work can be valid and discoverable — but should still remain delayed.

Important distinction:

discoverable ≠ eligible ≠ scheduled now

This allows Phase 10 to preserve deliberate scenario lags even when the underlying integration path is otherwise healthy.

Connector and projection cadence

A source system can know something before the canonical layer does.

  • 15:00 ERP Sales Order exists
  • 18:00 connector extracts it
  • 18:30 canonical projection creates/updates enterprise representation

So source truth can be ahead of canonical visibility. That is intentional.

The grounding layer should not silently bypass the canonical boundary just because a source record exists earlier.

Replay

A deterministic simulator should be able to repeat a known run from a known starting state.

Replay should use:

recorded execution planknown RESET baseline

rather than re-running planning and hoping it chooses the same records. That makes differences meaningful.

What “proper business-process simulation” means

The goal is not raw transaction volume.

The goal is causal enterprise depth.

Examples include:

  • Lead → Opportunity → Sales Order → Delivery → Invoice
  • Purchase requirement → Purchase Order → Receipt → Supplier Invoice
  • Production Order → MES work → Production Receipt
  • E-commerce Order → ERP fulfilment
  • Warranty Claim → decision → replacement / credit
  • Shipment → delivery → receiving / downstream state

A smaller number of coherent business processes is more useful than millions of unrelated rows.

Go deeper
One business day

Business time7 points · illustrative

  1. 09:00
    CRM work startsCRM
  2. 11:00
    Opportunity progressesCRM
  3. 14:00
    Opportunity closes WONCRM
  4. 15:00
    CRM → ERP relay creates Sales OrderCRM → ERP
  5. 18:00
    Connector extractionConnector
  6. 18:30
    Canonical projectionCanonical
  7. later
    Grounding sees canonical Sales OrderGrounding
In a separate process:20:00 Logistics → POS work becomes discoverablesuppression active · work remains intentionally unscheduledlater suppression expires · relay may proceed

This one timeline demonstrates:

business timecommandscross-system handoffintentional lagextraction cadencecanonical laggrounding visibilityscenario policyreplayable execution
Phase-10 boundary

The Guide explains this architecture now.

The Day-0 Explorer still does not expose:

runtime clock controlsRESET / CONTINUEreplay controlssimulation actionsscenario suppression controls

Those belong to the runtime experience, not the frozen Day-0 Explorer.

Chapter takeaway

  • Day-0 gives Metrolane a reproducible enterprise state.
  • Phase 10 creates a mutable runtime from it.
  • The enterprise clock controls simulated business time.
  • Plans decide what should happen.
  • Binding resolves real business objects.
  • Handlers perform controlled mutations.
  • Relays move business facts between systems.
  • Connectors and projection let enterprise knowledge catch up.
  • Replay proves the run can be repeated.