Release with a reconciliation and rollback plan

The final review should use the same state model as the implementation. A generic sign-off list can confirm deployment health while missing records already stranded by an earlier version.

Before release, check:

• every business fact in the workflow has one named owner;
• role checks cover discovery, reading, transition and reversal;
• duplicated and delayed integration events are safe;
• uncertain operations enter reconciliation rather than disappearing;
• identifiers connect user reports, local records and external events;
• the original composite failure patterns have regression tests;
• configuration for each portal points to the intended services;
• queues and exception records are visible to an operator;
• rollback does not leave the data model ahead of the running code;
• someone is assigned to review exceptions after deployment.

Decide what rollback means for state already changed. Reverting code does not reverse an external action or restore an earlier permission decision. The release plan may need a forward repair, a temporary pause on one transition, or a script that only reports affected records for manual handling. Test the script on a copy or in report-only mode before it can write.

After deployment, run a small set of end-to-end traces with identifiable test records. Review the reconciliation queue and compare event counts only where those counts have a defined relationship. Keep the release open until the team can explain every test operation and any exception it produced.

For the workflow under release, verify that every authorised role sees a state consistent with the owning system. Then force each supported failure path and confirm that it leaves enough evidence for the named recovery action.