Review the map before approving replacement scope

Before scope is approved, take one ordinary request and one relevant exception through the proposed future flow. Use the actual roles, states, evidence and system boundaries. If the team has to invent an answer during the review, record it as an open decision rather than smoothing over it.

The review should confirm that:

• every starting event has a named intake path;
• every active state has an owner or visible queue;
• each decision identifies the information and authority required;
• handoffs state what transfers and how receipt is known;
• waiting work remains visible;
• corrections preserve enough history to explain the current result;
• duplicate and retry behaviour is defined for consequential events;
• integration rejection has an operating path;
• excluded cases have an interim owner;
• acceptance checks can be run without relying on a presenter's explanation.

Compare the capability list with the current-state evidence. Remove features that exist only because the old interface had them. Add a capability only when the team can name the work it supports or the risk it controls.

Give the proposed scope to somebody who was not in the main workshops. Ask them to trace who acts next when information is missing, an approval changes or an external transfer fails. Their questions will often find assumptions that regular participants have stopped seeing.

Approve the scope when the main path is coherent, important exceptions have owners, and unresolved decisions are explicit enough to manage. Keep the working map available during design and testing. For each significant change, record the affected state, handoff or rule and the reason it changed.