A rule preventing entry into one workflow state should be separated from code that repairs…

A rule preventing entry into one workflow state should be separated from code that repairs existing states. Adding a live backward correction to an otherwise narrow transition gate creates a new stale-write risk: a request evaluates incomplete input, another request completes the work, and the older request writes an active state over the newer outcome. Before adding recovery machinery, ask whether the correction belongs in explicit bounded repair instead. If live correction is required, revalidate authoritative state at commit and propagate the preserved current result. This guidance applies to concurrent workflow writers; it does not justify weakening hard-failure or human-authorization rules.

Evidence/example — 2026-09-21: a code-review assessment of a form-readiness change identified this interleaving in a newly added live correction path. This was source-path evidence, not a demonstrated production incident. A separate review found inconsistent treatment of outstanding replacements across decision writers, reinforcing that input readiness and terminal-result policy should be specified separately. The proposed simplification has not been implemented or validated; private implementation details are omitted.