One Task, Three Interruptions

What the drawing shows

Each row (on a phone, each column) is one kind of record. Report is the input: version 1 says revenue was 4.1 million; version 2 corrects section 2 to 4.7 million and leaves the other three sections byte-for-byte unchanged. Each attempt row is one admitted execution of the same task identity, with the owner token it was issued (T41, T42…). The four journal rows hold persisted step results and the report version each was computed from; ↺ marks a step a successor restored instead of redoing. Digest holds finished candidates (◇), acceptances (✓ plus the version recorded on them) and refusals. Feed post is the external announcement: intent (i), the post the feed applied (P1), a resend the feed recognised and answered with the original post (P1 again, in the cyan style) and the confirmation. Newsletter is the dependant: it becomes ready at t12 and waits until its gate is satisfied.

The model has three separate lifecycles: an attempt can be UNKNOWN while the digest it produced stays accepted and its announcement stays unconfirmed. That is why they are drawn on different rows rather than as one status.

Documented initial inputs

Reset restores these, which are also the guided route's starting point:

What the model assumes

• One model call per section summary. A section summary depends only on its own section text and one fixed assessment contract; if it read anything else, reusing it by section hash would be unsound. Each attempt reads an immutable copy of the report version it is pinned to.
• Result and digest identifiers are schematic: a restored step keeps its recorded identifier, and a redone step is given a new one by stipulation. A real rerun may produce different text; the model does not generate or compare text.
• The journal, candidate store, effect records and the acceptance transition share one authoritative owner epoch and check a write's token against it atomically with the write. The feed is external, cannot be rolled back, deduplicates only by idempotency key, keeps keys for the whole run and does not check owner tokens.
• Two missed heartbeats make an attempt UNKNOWN: suspicion, never proof of death. A fenced-out worker stops when a write is rejected; it may still be alive.
• The assessor checks completeness and form, not every figure; version consistency is checked mechanically by comparing section hashes with the pinned version. At most one digest is accepted per report version, and the newsletter requires the latest report at admission. Both are policies of this example.
• With version pins off, a gate that asks for the current report has nothing to compare and is set to admit anyway (fail-open). A fail-closed gate would wait instead, and would then never proceed without version records.
• Discrete ticks, one step per tick, no clock skew. The controller itself never fails and its records are on reliable storage: this example covers worker loss, an ambiguous external effect and a changed input, not controller recovery.

Counts, ticks and model calls are properties of this small construction, not measurements of any engine. The 864 combinations of the eight settings were each run to completion; that is exhaustive over these settings, not over arbitrary interleavings, crash points or storage failures. Statements about Bazel, AWS Step Functions and the other systems mentioned summarise their documentation as read in October 2026; the technical companion's references give the sources.