A "notifications" module is owned by one team but changed by three. Latency is fine and nothing is failing. The symptom is delivery: 40% of the team's pull requests in the last quarter touched it, median review time on those is four days against one day elsewhere, and two releases were reverted because two unrelated changes shipped together. What would you look at first, and what is the diagnosis?

The first three things I would look at, and why in that order

1. The co-change matrix for the files inside the module. Export, from version control, which files change in the same commit. Cohesion is a claim that the contents of a boundary change together; version history is the only evidence for or against it, and it is free to collect. If the module decomposes into clusters that never co-change, the boundary is wrong and the data says where to cut.

2. Who the authors are, per cluster. Three teams changing one module is either a shared concern genuinely owned by one team, or three separate concerns filed in one folder. The author distribution per cluster distinguishes them in one query.

3. What the reverted releases actually contained. Two unrelated changes shipping together is a release-unit problem. If the module is the unit of deployment, every change in it is coupled to every other change in it at release time, whatever the code looks like.

The diagnosis

This is low cohesion presenting as a delivery problem, not a performance problem, which is why no technical metric is red. Three concerns live in one boundary — most likely the transport mechanics (send to a provider, handle retries and rate limits), the content and templating, and the per-event business rules about who gets notified and when. They change for different reasons, on different cadences, driven by different stakeholders.

The mechanism linking that to the symptoms: a change inside a shared boundary needs review from everyone who depends on the boundary, because reviewers cannot tell from the diff whether their concern is affected. That is the four-day median. And a shared boundary that is also the release unit forces unrelated changes into one deployment, which is the revert.

The misleading clue is that the module is owned by one team. Ownership looks like cohesion and is not. The test is not "who owns it" but "do the things inside it change for the same reason, at the same time, driven by the same stakeholder".

The fix, in order

1. Split the release unit before splitting the code. If the business rules can ship independently — behind a flag, or as data rather than code — the revert problem goes away this month without any refactor.
2. Extract the transport concern. It has the fewest callers, the most stable contract and the clearest owner. It is the cheapest cut and it validates the split.
3. Move the per-event rules to the teams that own those events. This is the real boundary error: who gets notified when an order ships is an orders decision, not a notifications decision.
4. Leave templating alone for now. It genuinely is a shared concern with one owner, and moving it buys nothing.

When this is the wrong answer

If the module is small and the three teams' changes are rare, do nothing. A boundary that produces four-day reviews on 40% of a team's pull requests is costing real weeks; one that produces two awkward reviews a year is not worth a refactor. Decide on the measured cost, not on the shape.

Also leave it alone if the co-change data shows the clusters do change together. Then the module is cohesive and the slow reviews are a reviewer-availability problem, which is fixed by naming fewer required reviewers, not by moving code.

The signal that would have caught it earlier

Not latency. Review time and revert rate per module, plotted monthly. Both were available all quarter and nobody was looking, because delivery metrics are usually reported per team and the problem lives per module.