Decide which choices can stay local

Central review becomes expensive when every implementation detail has to pass through the same people. Teams also wait for approval on decisions they are better placed to make. Identify the choices that cross a team or product boundary and leave the rest close to the work.

A local decision is one whose effects stay within the component or feature owned by the team. Internal function names, a private module layout, a small interface arrangement and an implementation strategy behind a stable contract will often fit. The owning team can review and change these without requiring the rest of the organisation to coordinate.

A shared decision changes what another team must understand, send, store, operate or explain. It may alter a public or internal API, a common data definition, identity and permission behaviour, an event consumed elsewhere, a workflow state used by support, or an operational dependency. The change might be only a few lines of code while its coordination cost is much larger.

Use questions rather than a long classification policy:

• Will another component read or write the result?
• Does the choice change the meaning of shared data?
• Will another team need to deploy, migrate or update documentation?
• Could it change access, billing, records or recovery?
• Would two different implementations be visible to a user or operator?
• Is reversal difficult once data or integrations depend on it?

A yes means the owner should identify the affected parties and choose an appropriate review. It does not automatically require an architecture committee. A backwards-compatible field addition may need a quick contract check. A change to account ownership may need product, data, security and support input because each relies on the meaning.

Some decisions begin locally and become shared through reuse. A team may create a helper for its own feature, then other teams adopt it. At that point the helper has a contract even if nobody planned one. Revisit ownership and change rules when reuse begins rather than waiting for an incompatible update.

Write down the boundary in team guidance: local choices are reviewed in the owning code area; changes to named shared contracts require identified reviewers. The list of contracts should be short enough that people can remember it and specific enough that they can recognise one during planning.