A workflow cannot recover from outcomes it never records

A workflow can appear stuck even when every component handled its exception. If the failure exists only in logs, downstream decision logic still sees missing or unfinished work. Recognizing a timeout in a classifier is useless unless the producer actually persists that outcome.

Model the distinction between still running, awaiting retry, and finished with a negative result or failure. A failed attempt is not necessarily a terminal job; record the attempt and the retry state without presenting it as success. When an outcome is terminal, persist it through the same concurrency and invalidation safeguards used for success so readers can act on consistent state.

This makes recovery a product capability rather than a log-reading exercise. A reviewer can distinguish missing evidence from completed negative evidence; a retry worker can distinguish retryable failure from work already completed; an agent can explain what happened without inventing a result. Decision readiness and permission to approve remain separate.

The useful test starts at the real producer: make the provider throw or time out, then read the durable state through the actual downstream path. A classifier unit test containing a fabricated failure record cannot establish that the system ever writes one. Test that a late response cannot overwrite a newer attempt incorrectly.

Generalized from the September 4, 2026 Shield COR-4050 / PR #797 review in e3-solutions/theft. Source: the recorded producer/read-model mismatch and its corrective diff, https://github.com/e3-solutions/theft/commit/e2c50ff8dc7d37c9c1d756075c811819d45fc572 . Editorial expansion approved by Caleb on September 6, 2026; the broader recovery tests above are recommendations, not newly executed experiments.