Event Logs and Mutable Portfolio Snapshots

A trading runtime can keep a fast mutable portfolio view while preserving a replayable event history. The engineering choice is where reconstruction begins and which transformations are reproducible. We would decide that before treating a snapshot as an adequate record of a long-running agent.

Our state and memory framework describes decision-bound state. The narrower question here is whether an investigator can rebuild that state after the materialized view has been lost. A linked decision trace needs the answer because the visible balance alone conceals the path that produced it.

Two stores, one economic history

Consider an illustrative cash ledger starting at 1,000 units. Event e1 buys an asset for 120, e2 charges a fee of 2, and e3 credits a deposit of 50. Folding those events gives 928 units: 1,000 minus 120 minus 2 plus 50. A mutable row containing only 928 answers the current-balance question. It cannot explain which economic changes produced that value.

An event record needs a stable economic identifier, account scope, payload schema, and application position. A snapshot needs the last included event position and the reducer version that produced it. Replaying e2 twice yields 926, which exposes why append-only storage alone provides insufficient protection against duplicate ingestion.

Event Sourcing describes state reconstruction from recorded events and the complication of external interactions. For an agent harness, the useful distinction is between rebuilding internal state and repeating an external action. Reconstructing e1 must consume the saved fill; it must never send another buy.

Recovery is the discriminating fixture

We would stop a hypothetical reducer after e2, save a snapshot showing 878, then delete only the materialized view. Recovery starts from that snapshot and applies e3 once. A second recovery path starts from the opening balance and applies all three events. Both should produce 928 and the same included-event set.

A third path supplies the duplicate e2 and expects the same result. A fourth changes the reducer version. That path should identify the version change and either reproduce the original reducer or produce a separately labeled reconstruction. Quietly applying new business logic would make an old decision appear to have used a different balance.

The test also retains external responses used by the reducer. If a conversion rate affected a ledger event, recovery needs its original value and provenance. Querying today's conversion rate answers a different question. We would measure recovery duration separately from numerical agreement so a correct but impractically slow reconstruction remains visible.

The storage choice follows the operational question. A team that only needs the last balance can use a simpler history contract. A team that needs exact turn reconstruction must preserve the reducer inputs and checkpoints that make it possible. The useful acceptance artifact is a recovered state with its event boundary, rather than the mere existence of an event table. This is a proposed fixture, with no claim that a current DXAP deployment uses this storage design.