Why the top committer is often the wrong answer
A commit count is a history of attention, not a statement of accountability. The person who wrote the most code may have changed teams, left the company, or handed the service over a year ago. A query ordered by commit count returns a confident, checkable-looking answer that is wrong.
The sample company makes the failure concrete. The former payments lead has 14 commits on payments-gateway, the highest count in the company, but left in April 2026. The current Platform on-call committed on 2026-09-28, and Decision D-21 named the Platform team the accountable owner. The right answer is the current owner, even though the volume signal points at the person who left.
The four-signal check
A useful ownership answer combines signals instead of trusting one. Run them in this order:
- Current ownership: the OWNED_BY edge from the service to a team, with its validity dates.
- Recency: the last commit or pull request touch, not the total count.
- On-call: who is paged now, which is a different fact from who owns the service.
- Decision history: the last decision that changed ownership, with a date and an author.
When the graph has no owner
The most valuable ownership answer is sometimes "nobody". config-service in the sample graph has no OWNED_BY edge and no on-call engineer recorded. A language model asked the same question will often invent a plausible platform team. A graph query returns an empty set, and the answer can state the gap.
That is not a failure of the tool. It is the difference between a system that reports the state of its records and one that produces prose that sounds like a record.
Keeping ownership current
Ownership drifts when people change teams. The cheap fix is to make the change visible: record the handover as a decision with a date, keep the previous owner as history rather than deleting it, and flag an ownership edge that has not been verified in 90 days.
A monthly review of unowned services and stale ownership edges is enough for most small companies. The goal is not a perfect org chart; it is an answer an engineer can act on at 2am.
Worked example: payments-gateway
Question: "Who owns payments-gateway today, and who gets paged?" The graph returns the Platform team as owner, Decision D-21 (2026-04-15) as the handover, and the current Platform on-call as the active responder. It also returns the former payments lead with a stale flag: 14 commits, last touch 2026-04-15.
The answer is checkable. Open the trail and each claim has an edge and a date. If the handover was reversed last week, the graph is wrong until the record is updated — but the date on the edge makes that visible instead of hiding it.