A.15.8:6.2 - Non-human distributed computation after worker loss

Situation. SettlementComputationWork-2026-08-27-Run42 is one admitted long-running computation Work occurrence. Its separately grounded performer Systems exchange messages and use an object store, configuration values, intermediate results, completed-effect records, and provenance records. Another worker must continue without duplicating an irreversible settlement effect.

Probe. RecoveryTestController-Run42 : U.System first has the A.13 core for the probe action; A.15.1 then independently admits WorkerLossRecoveryProbeWork-Run42-P1 : U.Work in the bounded representative environment. The recovery comparison expressly uses which controller assignment covered the probe, so the account separately establishes that A.2.1 occurrence and F.6 attribution through the same A.13 assignment. That probe Work enacts the selected computing U.Method: it removes one worker after a message has been emitted but before its local completion record is available, then attempts recovery from the selected state mechanism. If the F.6 link failed, the probe Work would remain and only its assignment-bound attribution would be unresolved.

Observation and result. Process state is recoverable, but channel state and the completed-effect provenance relation are not mutually consistent. The branch-specific account names those state bearers and update/use relations and returns the missing idempotency or provenance condition. A Chandy-Lamport snapshot, event sourcing, transaction protocol, or another computing Method may be selected as the reusable way for the repair. If the repair is carried out, an admitted System performs the dated repair Work and that Work may enact the selected Method; this pattern selects neither.

What changed. Add or repair the exact checkpoint, provenance, or idempotency condition. No human attention, memory faculty, or cognitive ontology enters.