Start with the accountable team, not a person
The first place to look is the service catalog or ownership graph, not a repository. The catalog should name the team accountable for the service today, the date the edge started and the last time someone verified it. If the catalog names a person, treat that as an escalation contact and find the team behind it.
A team survives job changes. A person-only owner goes stale the week they leave, and the record usually keeps looking authoritative until an incident proves otherwise.
Verify the answer with three signals
A catalog entry can be wrong, so check it against signals that are harder to fake:
- Last touch: the most recent commit or pull request on the service, not the highest commit count.
- On-call: the rotation that would page someone now, and whether that rotation belongs to the owning team.
- Decision history: the dated decision that last changed ownership, including who approved it.
A CODEOWNERS file is not an ownership record
CODEOWNERS tells a code host who should review a change. It does not say who is accountable for the running service, who is paged, or what happens when the repository is archived. It is a useful review signal and a poor answer to "who owns this?" on its own.
The same applies to a team alias in a README. It can route a question, but it does not carry a date, a handover or an escalation path. Use it as a starting point, then confirm the operational owner.
When the catalog returns nothing
The most useful answer is sometimes "no owner is recorded". That is a finding, not a failure. Name a provisional owner, record the date and the reason, and add the service to the next review. A plausible guess hides the gap; an empty result makes it actionable.
If the service is critical, treat the gap as an incident waiting to happen. The provisional owner should confirm they can receive a page before the next on-call shift.
Worked example: payments-gateway
The catalog says the Platform team owns payments-gateway. The last commit is from the Platform on-call engineer on 2026-09-28, the active on-call rotation belongs to Platform, and Decision D-21 (2026-04-15) records the handover to Platform.
A commit-count query returns the former payments lead first with 14 commits, but that last touch is 2026-04-15 and the person left in April. The evidence points to Platform; the volume signal points at someone who is no longer there. That is why the four signals are checked together.