What is A simulated execution?
A simulated execution executes a workflow with its external effects suppressed, to establish what it would do before it does it. Every decision is taken and every write is captured as an intention rather than applied. The output is the list of actions a live execution would commit.
Also called: Simulation mode
Why the first live execution should hold no surprises
Changes to a workflow are usually reviewed as a difference in code, which tells a reviewer what changed and nothing about what it will do to the system of record. A simulated execution answers the second question directly, by listing the records that would be amended and the instructions that would be issued. Operations staff can review that output, where they cannot review a pull request. It is also the only review artefact an auditor tends to find meaningful.
- The output is reviewable by the people who own the process rather than the code.
- It exposes the effect of a change on real data without committing anything.
- The difference between two of them is the clearest description of a change.
- An auditor can read the intended actions and compare them against policy.
How A simulated execution works
- Every external write is issued through a layer that can be switched to record only.
- The workflow executes against production data with that layer suppressing effects.
- Each intended action is captured with its target record and its payload.
- Read operations proceed normally so decisions reflect the real current state.
- The captured actions are reviewed by the process owner before live execution.
- The reviewed output is retained and compared against what the live execution committed.
How A simulated execution is evaluated
The method is only useful if its predictions match what happens live. Measure the following for each change released this way:
- agreement between predicted actions and the actions committed live
- coverage of external effects by the suppression layer
- proportion of changes reviewed this way before release
- defects detected at review against defects reaching production
- elapsed time to live execution against the freshness of the data
Limitations, risks and common failure modes
- A suppression layer that misses one integration lets a real effect through.
- Stale copies of data predict decisions that the live system would not produce.
- Reviewers approve a long action list without examining the exceptional entries.
- Suppressed writes change the timing, so a concurrency defect stays hidden.