The problem
The dangerous failures rarely happen on the happy path. A process can crash after an external action but before it records the result. On restart, it sees the same open case and may perform the action again.
The approach
The Action Ledger is a small transaction kernel for software agents. It stores cases durably, assigns bounded processing leases and writes state changes to an append-only event history.
The attempt is committed before the external call. Afterwards, an adapter reads the authoritative system again. Only a fresh read-back may confirm the action.
- Stable case identities so the same input does not create two cases
- States for pending, waiting, human decision and complete
- Time-bounded leases and safe recovery after a worker fails
- Idempotency keys and fingerprints for the intended request
- Append-only history for cases, actions and the write gate
What this demonstrates
The important distinction is not success or failure. It is attempted or confirmed. A system that merges those states cannot reliably explain its own past after an interruption.
Where it applies
The pattern applies to every automated process with an external effect: ERP entries, document approvals, messages, orders or status changes. The more consequential the action, the more important identity, history and read-back evidence become.
The reference implementation coordinates processes on one machine. It is not a distributed system, a queue, a scheduler or a workflow engine.