Build a shared state inventory

Most multi-portal systems have more state than their interfaces admit. There is the main business status, but also permissions, ownership, sync status, review status, payment or entitlement state, notification state, and the version of data each component last observed. A single label such as "complete" may compress several of these.

Create an inventory for the workflow under review. For each state value, record:

• the system that owns it;
• the event allowed to change it;
• the roles allowed to trigger that event;
• the components that copy, derive or display it;
• any delay that is expected;
• the evidence left after a successful or failed transition;
• the recovery action when the transition stops halfway.

Ownership needs to be explicit. Two services should not independently decide the same business fact unless there is a reconciliation rule. If an external service is authoritative for settlement while the application is authoritative for eligibility, name both facts separately. Calling both of them "approved" creates ambiguity in code, database fields and support instructions.

Derived state deserves the same attention. A portal may show "ready" when four conditions are true rather than storing a ready flag. Write down the rule and where it runs. If the staff portal, customer portal and API each implement the rule separately, compare them line by line or move the rule behind one tested contract. Small differences accumulate quietly: one path excludes archived items, another uses a different date boundary, and a third treats a missing integration response as success.

The inventory can stay small. Cover the workflow being released rather than modelling the whole product. It should answer who owns each fact and how another component learns that it changed.