Review whether the team can still make one product

A periodic review should look for incompatible behaviour already forming, not count how many decision documents were created. Sample recent changes across team boundaries and trace the product concepts they touched.

Check that:

• shared contracts and product terms have identifiable owners;
• contributors can find the current decision without asking in a private channel;
• records distinguish proposals, accepted choices and replaced guidance;
• local teams know which changes require wider review;
• review happens before implementation is expensive to change;
• affected consumers participate when a contract changes;
• migration and mixed-version behaviour are considered;
• tests cover the behaviour promised by the decision;
• exceptions have a reason, scope and owner;
• old records and documentation point to current guidance.

Then choose one shared concept and inspect its full path through storage, APIs, events, interface copy and operating procedures. If the definitions differ, assign the repair as product work with a compatibility plan. Do not reduce it to a documentation tidy-up.

Ask newer team members where they would look before changing that concept. Their route is a useful test of discoverability. If the answer depends on knowing a particular person, improve the source and links before adding another orientation session.

Also inspect the cost of the review process. Teams should be able to show examples of local decisions they made without central approval, shared changes reviewed quickly, and consequential proposals that received deeper attention. If everything follows one path, the boundaries are probably too vague.

Start with one decision currently being made in several places. Write its present meanings side by side, name the people affected by choosing one version, and put the proposal through the review route the team expects others to use.