The current StateVec cluster uses one Raft WAL for ordered durable history, with a selected checkpoint as its recovery base. There is no independent cluster TxLog to reconcile on restart.
TxResult is an engine execution result, not a second durable cluster journal. The cluster owns log order, commit, and recovery selection. The engine owns business execution and its evidence.
The live path
In the default Verify mode, leader simulation prepares commands and execution declarations without committing canonical state. Raft replicates the proposal; required durability and exact-prefix validation precede successful voter-capable follower acknowledgment.
After commit, each node applies against its own state. It can reuse its own prepared overlay when the base and declarations match, or execute and compare. The applied frontier advances only when actual engine evidence, ingress frontiers, and native membership form a complete joined fact.
Proposal acceptance is not commit. Durable bytes alone do not prove applied business state. Client completion comes from committed apply.
What is durable
| Fact | Location | Purpose |
|---|---|---|
| Ordered entries and durable commit | Raft WAL and HardState | Committed suffix for replay |
| State at an exact applied index | Selected checkpoint image | Recovery base |
| Membership, ingress, execution evidence at the base | Checkpoint's complete applied section | Consistent reconstruction starting point |
| Current applied fact | Raft core and engine RAM | Live progress; reconstructed on restart |
| SQL rows, messages, read models | External sinks | Their own delivery or serving progress |
The current journal format adds neither a per-entry AppliedBatch WAL record nor an engine-side recovery cursor. The checkpoint retains the complete applied fact at its own boundary.
Restart from B to C
Let B be the selected checkpoint's applied Raft index, C the WAL's durable commit, and A the reconstructed applied index. Initial replay maintains B ≤ A ≤ C, with durable log coverage through C.
A newer checkpoint file is not automatically the selected recovery root. An uncommitted tail is left for Raft to resolve. A partial RAM install failure retires the process owner; reconstruction follows durable history rather than an in-place rollback or independent engine log.
Verification is a mode contract
| Boundary | Verify mode, the default | Performance mode, an explicit option |
|---|---|---|
| Before proposal | Preflight, then simulation and declarations | Static preflight; no business simulation |
| Voter-capable follower prefix ACK | Required durability plus exact-prefix validation | Required Raft durability |
| Committed apply | Actual local evidence must match declarations | Execute commands and produce actual local evidence |
| Recovery | Selected checkpoint plus committed suffix | Selected checkpoint plus committed suffix |
A configured, permanently non-promotable learner has a separate Verify mode ACK exception. Runtime learner membership alone cannot select it. Performance mode is never a fallback after validation fails. The inherited LightVerify mode has been retired from supported construction.
Recovery history and audit history
A checkpoint and retained suffix can support recovery without preserving a full historical audit. Compaction can remove older ranges; a state image cannot reconstruct every earlier delta or publication.
Audit and projector integrations need explicit retention or export, trusted starting points, and their own durable frontiers. The archived projector design illustrates that split; it does not establish that its earlier integration is part of the current product path.
Current scope
Reviewed against cluster-v1 on 2026-10-04. The source documents bounded Linux support for Verify mode and Performance mode, while composed diagnostics and final performance/platform qualification remain separate exits. This note supplies no current TPS or general production-readiness claim.
Implementation references: single-journal recovery and execution modes.