Crash, reconcile, restart — without duplicate effects

A deterministic workload run long enough that ordering, contention and queueing effects appear rather than being designed away by a short test.

Previously valid requests re-sent in volume, checking that no second effect is produced for any of them.

Multiple approvers acting on the same held request at the same moment, where exactly one consumption may win.

The process is killed after commit and after ledger write — the two windows where a duplicate effect would be possible — and recovery is checked from both.

An effect whose real-world result cannot be established is recorded as unknown. It is never converted into a failure or a no-effect to make a report clean.

The active policy changes while requests are in flight, and each request is graded against the policy actually in force at its own dispatch.

Processes killed before an effect, during dispatch, and between the execution commit and its ledger append all recover to a correct state. Executed actions stay executed, consumed approvals stay consumed, budget spend is preserved, and no restart produces a duplicate effect.

Limitation · Candidate, not proven: this passes its own gate on a development profile. Acceptance requires the full profile on a controlled machine, which has not been run.

When a request was transmitted but the answer never arrived, the system records the outcome as unresolved and retains the budget. It does not retry blindly and it does not convert an unknown into a failure to make the state tidy. Reconciliation then determines what actually happened.

Where evidence protection is required, a failure of the witness that attests the evidence chain blocks new protected dispatch rather than letting execution continue unwitnessed. Reconciling work that may already have had an effect is never blocked, because refusing to reconcile would leave a real-world action in an unknown state to protect a log.