Speculative execution produces a decision before that decision becomes durable.

That creates a simple design question:

What is the object that crosses the durable boundary?

For a deterministic business engine, the answer should not be "some rows were written" or "some events were published."

The boundary object should be the execution result.

Call it TxResult.

command
   |
   v
deterministic execution
   |
   v
TxResult candidate
   |
   v
commit / reject / verify

This article is about that object, and only then about how the tx-log file should serialize it.

TxResult as the boundary object

The previous piece described the data view that execution reads and writes through. Once execution finishes, the runtime should have a complete TxResult candidate:

prior frontier
        |
        v
command + data view
        |
        v
deterministic execution
        |
        v
TxResult candidate

A TxResult carries the inputs and outputs of one committed transition:

tx_seq
prior frontier
command identity
outcome
state delta
events
next frontier / digest
runtime + schema + plugin identity

The important point is that the runtime builds this object before it exposes the decision as durable history.

If the command accepts, the TxResult drives state application and event publication.

If the command rejects, the TxResult can still matter. A deterministic rejection is not just an exception. It may be the correct business result:

reject order because risk limit would be exceeded
reject transfer because balance is insufficient
reject cancel because order is already filled
reject settlement because prerequisite state is missing

For audit and replay, "this command was rejected for this deterministic reason at this frontier" is useful history.

Why result history matters

Business incidents are result-oriented.

People rarely ask only:

Which command arrived?

They ask:

  • did it succeed or reject?
  • what state did it change?
  • which events were emitted?
  • which state frontier did it advance?
  • can we replay or verify that decision?

That is why the result should become the object of record:

this command
executed at this frontier
produced this outcome
changed state this way
emitted these events
advanced history to this point

This is the object audit tools want. It is also the object replay and verification can reason about.

Replay modes

Once TxResult is part of committed history, replay can support more than one mode.

The fast recovery path can apply recorded results:

committed TxResult
   |
   v
apply recorded state delta
   |
   v
restore frontier

The verification path can re-execute:

command + prior frontier
        |
        v
deterministic execution
        |
        v
new TxResult
        |
        v
compare with recorded TxResult

Those are different operational needs. Recovery wants to come back quickly. Verification wants confidence that the logic still produces the same result from the same prior state.

If the system only keeps commands, it can still re-execute. But it does not preserve the result object that operators, auditors, and followers can compare against.

Cluster verification

In a cluster, the leader can execute speculatively and propose or commit a TxResult.

Other nodes should not have to treat that result as magic. Given the same prior frontier, the same command, the same schema, and the same plugin identity, they can re-execute and compare:

leader TxResult
        |
        v
follower re-execution
        |
        v
same digest / same result?

This is one of the reasons recording results is useful in enterprise systems. The system can detect divergence near the source of truth, instead of discovering it later through reconciliation across projections, queues, and reports.

The exact replication protocol can evolve. The contract is more fundamental: the durable log should carry enough information for another node to verify the business decision.

Where the tx-log file enters the discussion

Only after defining TxResult does the storage question become clear.

A write-ahead log is a proven idea. Before a storage engine mutates durable state, it records enough information to recover. That design is simple, effective, and operationally understandable.

For a deterministic business engine, there are two broad choices.

The command-oriented WAL shape records input:

command_1
command_2
command_3
...

Recovery replays those commands against prior state to rebuild the engine.

This has real advantages:

  • the log is compact;
  • the format is simple;
  • replay follows the command path;
  • there is less result data to version;
  • the storage model is easy to explain.

For many systems, that is enough.

The tx-log file serializes committed TxResult records:

TxResult_1
TxResult_2
TxResult_3
...

That means TxLog, as a concept, is not a second business object beside TxResult. It is the ordered history represented by the tx-log file: a durable sequence of committed TxResults.

The tradeoff is explicit.

tx-log entries are larger than command-only WAL entries.

They also require more discipline:

  • stable result encoding;
  • schema/runtime identity validation;
  • deterministic execution rules;
  • careful versioning of outcome and event formats;
  • replay behavior that knows when to apply recorded results and when to re-execute for verification.

Those costs are real.

But the benefit is also real: the tx-log file becomes the committed execution history, not only an input log.

Where the line should be drawn

The point is not that every system must record every internal detail.

The point is to record the boundary object that matters enough for recovery, audit, and verification.

input:
  command

result:
  outcome
  state delta
  events
  next frontier / digest

Internal temporary values do not need to be logged. Runtime scratch state does not need to be logged. Downstream projection details do not need to be logged.

The committed TxResult does. The tx-log file is the serialization of those committed TxResults.

Closing thought

A command-only WAL is enough when the main problem is replaying inputs.

A deterministic business engine also needs to recover and verify execution.

That is why TxLog is the source of truth: an ordered, durable sequence of committed TxResults, serialized in the tx-log file. State, events, audit views, replay, and verification all derive from that history.