Simulation gives deterministic business logic a place to compute a decision before canonical state changes. StateVec executes into an overlay, validates invariants, and prepares the candidate's outcome, deltas, events, and execution evidence.

A prepared result is a candidate. It is not a commit.

Compute before crossing the boundary

Simulation in Verify mode: the engine prepares a candidate in its overlay. Only committed apply can install canonical state, reusing a matching overlay or re-executing and comparing evidence.
Simulation in Verify mode: the engine prepares a candidate in its overlay. Only committed apply can install canonical state, reusing a matching overlay or re-executing and comparing evidence.

In Verify mode, the default, leader simulation produces commands and execution declarations for proposal. Followers validate the exact acknowledged prefix under the mode's required durability rules. At committed apply, a node can reuse its own prepared overlay when the base chain and declarations match; otherwise it executes and compares.

The explicit Performance mode skips pre-proposal business simulation. The engine still executes committed commands, checks the execution contract, and reports actual local results. Simulation is a mode choice, while durable commit and complete apply remain cluster responsibilities.

Failure has a precise location

In a service that writes rows, sends events, and updates caches while computing a decision, a failure can leave partial external effects.

The overlay gives candidate execution a controlled boundary. A deterministic business reject does not install its staged mutations. A proposal that never commits cannot authorize visible business state.

That does not mean every engine fault is an ordinary abort. A panic, undetermined execution, or failure during committed installation can poison or consume the engine. The process owner must be retired and state reconstructed from the selected checkpoint and committed Raft suffix. It must not report a successful completion or invent an in-place rollback.

The engine supplies comparison evidence

A candidate makes the input and output explicit: command identity, outcome, record changes, events, transaction identity, result digest, and chain evidence.

Identical prior state, ordered inputs, and execution identity should produce matching result evidence on independent nodes.
Identical prior state, ordered inputs, and execution identity should produce matching result evidence on independent nodes.

Raft agreement establishes command order. The engine's evidence helps establish that nodes interpreted those commands consistently. A mismatch is a fault to detect and diagnose, not a second acceptable result.

Determinism must include the inputs

Domain code cannot let ambient wall-clock time, random values, hash-map iteration, or external I/O change replayed results. Business time or other nondeterministic observations must be explicit command inputs when they affect the transition. Schema and runtime/plugin execution identity also belong to the recovery contract.

What becomes durable

The cluster persists Raft entries and commit state. In Verify mode, entries carry commands and execution declarations; the cluster does not append a second independent TxLog containing every full TxResult.

Committed apply joins actual engine results, ingress progress, and membership. Recovery rebuilds that join from a selected checkpoint and committed suffix. External publication remains a separate delivery concern.

For the state surface used by simulation, read Stacked Data View. For durability, read Raft History, Verified Execution, and Recovery.