Work That Outlives Its Worker
A worker stops halfway. Which saved results can its successor trust?
Follow a summary task through a missing worker, a corrected report and an uncertain retry. This teaching model separates saved progress, acceptance and what a downstream job can safely use.
3:27 Interactive Article3:27 · Narrated by Ara · Captions optional Open in 4K ↗
Read the narration
A worker stops halfway
A worker stops halfway through a task. Its replacement can see some saved results, but which ones can it trust? Let’s follow one small job through a restart, a corrected input, and a retried announcement.
The work has its own identity
This is an invented teaching model. A task summarises a four-section report, and a newsletter will use that summary. The task has a lasting identity. The workers are only attempts to complete it. That distinction gives recovery somewhere to start.
Record the attempt before dispatch
Before dispatch, the controller records attempt one, the report version it will read, and its owner token: forty-one. If the process disappears, that record tells a successor what might have happened. It does not prove that the work ran.
Saved is not accepted
The worker saves results for the first two sections. Each result records the hash of the section it read. This is recoverable progress, not an acceptance decision. Nobody has assessed the finished summary yet.
Silence leaves uncertainty
Then the worker stops answering. Two missed heartbeats make its status unknown. A crash and a long pause look the same from outside. The controller admits a replacement with a newer owner token: forty-two.
Restore what still matches
Meanwhile, someone corrects revenue in the report, from four point one to four point seven million. The replacement reads version two. Section one has not changed, so its saved result can be restored. Section two has changed, so that step must run again.
A reuse key must cover its inputs
The ledger makes the distinction visible. Reuse depends on what each step was computed from, not merely whether a result exists. This is sound only when the key covers everything the step read, and the step actually read the immutable version named by its pin.
Alive, without write authority
The first worker was only paused. It wakes and tries to save another result using token forty-one. The store compares that token with the current owner token and rejects the write. This is fencing: the old process may still be alive, but it no longer has write authority.
Acceptance names an input version
The replacement finishes a candidate summary. A check outside the worker assesses it, and the controller accepts it for report version two. Now the newsletter may start. It quotes the corrected figure: four point seven million.
Retry the same operation
There is another failure window. The feed applies an announcement, but the posting worker dies before recording confirmation. Its successor sends again, using a key that identifies the same operation. The feed recognises the key and returns the original post.
An attempt key creates a duplicate
Change just one setting: make the key identify the attempt instead. The retry now looks like a new operation to the feed, so the announcement appears twice. Safe retry depends on the receiving system recognising the same operation, not just on the sender keeping a log.
History and current usefulness differ
Now try a different ordering. Version one is accepted before the correction arrives. That acceptance remains a true historical event. But this newsletter requires the latest report, so it must wait for a version-two summary. An old acceptance does not automatically satisfy a current dependency.
The consumer needs its own rule
Relax the newsletter’s rule to accept any accepted summary. It starts with version one and quotes four point one million, even though the current report says four point seven. The result was accepted. The consumer still chose the wrong version for its purpose.
Three separate questions
Saved, accepted, and safe to use answer three different questions. Saved progress supports recovery. Acceptance judges a particular output against particular inputs. Safe use depends on what its consumer needs. The interactive example lets you change those protections and see exactly where the distinctions matter.
Authorship and contributions
Author: Loki
Claude (Opus 5.5, Claude Code) (2026-10-04: cue file, capture, inspection and manifest under Loki's direction)
Moiré (2026-10-09: spoken adaptation and delivery under Loki’s direction)