Continue After Durable State Changes

When an automated workflow writes new durable state, the next step should usually be to re-read that state and let the normal classifier decide what is legal now. Direct shortcuts are tempting, especially when the code change looks small. They also tend to bypass the very contract that makes the workflow governable.

The Surface Problem

The visible issue looked like a small control-flow defect. A workflow accepted a normalized result, wrote the new state, and then stopped too early.

That was not a classifier problem. The classifier already knew what should happen once the durable state changed. The problem was that accepted paths returned before the existing re-read and classify loop had a chance to run again.

The Real Problem

The real failure was a lifecycle boundary bypass.

The workflow had an authoritative pattern available:

1. Write the durable state change.
2. Re-read the durable state from disk or storage.
3. Classify the current lifecycle state.
4. Dispatch, pause, or refuse according to the classifier.

One branch already followed this pattern for rework paths. Accepted paths did not. They wrote state and exited early, which meant the workflow never let the authoritative classifier evaluate the new state.

That distinction matters because durable state is the source of lifecycle truth. Once state changes, the next action should be derived from that state, not from a branch-local assumption about what probably comes next.

What Was Discovered

The important discovery was not that the next step was unknown. The next step was already encoded in the workflow's classifier.

The useful comparison was between adjacent branches:

| Branch type | Existing behavior | Better behavior | | --- | --- | --- | | Rework path | write durable state, then continue through the loop | keep this pattern | | Accepted path | write durable state, then return early | write durable state, then continue through the loop |

This made the fix narrow. The workflow did not need new routing logic, new verdict semantics, or a new lifecycle engine. It needed accepted branches to reuse the same durable-state loop that already worked for rework branches.

What Changed

The implementation change was small: early returns after accepted state normalization became loop continuations.

The behavioral change was larger:

• after one accepted state, the system re-read durable state and moved to the next legal dispatch;
• after another accepted state, the system re-read durable state and stopped at the required human gate instead of continuing blindly;
• protected classifier, route, gate, and verdict surfaces stayed unchanged.

The lesson is that small lifecycle changes can carry a large proof surface. The implementation may be two lines, while the evidence work spans old expectations, negative paths, real persistence, and protected-surface checks.

Why It Matters

Automated workflows become fragile when branch-local code starts making lifecycle decisions that belong to a shared classifier or state machine.

The failure mode is subtle. Tests may keep passing because they assert the old terminal outcome. The code may look simpler because it returns immediately. The workflow may even behave correctly for one common path. But the governing boundary has shifted from durable state to local control flow.

That creates three risks:

• the workflow can stop too early after a valid state change;
• the workflow can skip a required pause or review point;
• future fixes may add more shortcuts instead of using the shared lifecycle contract.

Better Pattern

After any durable state write that changes workflow lifecycle, prefer this pattern:

1. Treat the write as a boundary crossing, not the end of the branch.
2. Re-read the durable state through the same path production uses.
3. Let the classifier determine the next legal action.
4. Prove the expected positive path and the required stop condition.
5. Check that protected routing, gate, and verdict semantics did not drift.

Do not encode direct shortcuts unless the shortcut is itself part of the workflow contract and has equivalent proof.

Evidence To Require

For this kind of change, proof should include more than "the next function was called."

Require evidence that the workflow used durable state:

• a real write occurred;
• the next decision used a fresh read or parse of that state;
• the classifier produced the expected next action;
• old terminal expectations were reviewed and recategorized;
• negative paths still fail closed or pause where required;
• protected lifecycle surfaces have no unrelated diff.

This is especially important when previous tests encoded the bug as expected behavior. Passing tests are not enough if the test suite is still proving the old lifecycle mistake.

The Reusable Lesson

Continue after durable state changes.

When durable state is the authority, workflow branches should write the state and return control to the shared lifecycle loop. They should not decide the next lifecycle action from local assumptions unless that shortcut is explicitly part of the contract.

Related Concepts

• Governed Workflows
• State and Lifecycle Management
• Automation Reliability
• Testing and Verification
• Human Gates and Approval
• Audit Verdicts Are Runtime State
• Artifact Truth Is Not Lifecycle Truth
• Stage Authority Before Role Labels