Event logs need replay ownership before event sourcing

I want a named owner for replay before I approve event sourcing. An append-only log is a storage decision; reconstructing useful state from it is a maintained capability. Someone must decide what replay means, keep historical events readable, and prove that rebuilding state will not repeat external actions. Without that responsibility, calling the log a source of truth promises more than the architecture has earned.

The distinction starts with the consumer. A support engineer inspecting a past decision, an operator recovering a failed workflow, and a service rebuilding a read model need different outcomes. I would ask each to name the state they expect back and the boundary at which reconstruction stops. “We retain all events” answers none of those questions. It describes the input, not the operation that turns history into something the business can trust.

The durable-execution and event-sourcing material in my wiki puts event replay, projections, snapshots, and schema evolution together. I read that grouping as an ownership problem. If a relational view is derived from events, somebody owns its interpretation of those events. If a snapshot accelerates reconstruction, somebody owns the correspondence between its state and its last included event. I would assign accountability for that whole recovery path, rather than assume the team operating the event store also owns every consumer’s meaning.

Consider an agent that reads a customer record, asks a model for a decision, and sends a notification. Reconstructing its recorded state should use the captured tool and model results. Calling today’s customer API or asking the model again would introduce new observations, not reproduce the old decision. Sending the notification again would turn inspection into another action. The gateway pattern addresses this by returning recorded results during replay and suppressing external calls. I want an owner who can demonstrate that boundary, not merely point to a replay flag.

That owner also needs to distinguish replay from retry. Returning a recorded activity result avoids executing a completed activity during reconstruction. It does not resolve the case where an external operation succeeded but its result was never durably recorded. Retrying that uncertain operation needs its own protection, such as a stable idempotency key recognised downstream. I would make the division explicit: which component reconstructs known history, which component reconciles an uncertain effect, and who decides when live execution may resume. Otherwise two teams can each claim recovery works while leaving the dangerous interval unowned.

Historical compatibility is the continuing obligation. A new event field or changed interpretation can make yesterday’s history unusable to today’s reader. Versioned event handlers and upcasters are ways to manage that obligation; neither removes it. My release gate would include representative old histories and a declared expected reconstruction. A snapshot should carry its event position and compatible state schema, so the replay path knows what remains to apply. I would also require the owner to state the supported replay horizon rather than leave “we can rebuild” as an unlimited promise.

There is a narrower case where I would not require a separate replay programme: a short workflow whose only recovery requirement is resuming from a persisted checkpoint, with no historical reconstruction or projection rebuild requirement. A checkpointer and an accountable application owner can be sufficient there. I would not impose a full event-sourced model just because the system happens to emit events.

For systems that do promise reconstruction, my acceptance test is practical. Give the owner a retained history, a supported code version, and an isolated target. Ask them to rebuild the declared state, explain discrepancies, and show that no external action escaped the replay boundary. That is a test I would require, not a result I assume from choosing an event store. Event sourcing becomes credible when someone owns that demonstration across releases. Until then, the log is evidence waiting for an interpreter.