Two questions that look like one
"Who owns this service?" and "who is on call right now?" are different. Ownership is accountability for the service over time. On-call is who will be paged in the next hour. A team lead can own a service and not be in the rotation; a rotation member can be on call for a service another team owns.
When the two are collapsed into one field, the answer is wrong half the time. The owner is unavailable, or the on-call engineer is a contractor who cannot make a product decision.
Model the rotation, not just the person
A rotation is a schedule with membership and a current slot. The active on-call is a time-bounded fact derived from that schedule. Recording only a name in an on-call field goes stale the moment the rotation changes.
In the sample graph, rotation membership and the active weekly on-call are separate edges. The distinction is deliberate: it lets the answer say "this engineer is on call this week" rather than "this engineer is the owner forever".
Ownership changes need a record
A handover in a chat message is not a record. Write it as a decision with a date, the previous owner, the new owner and the reason. Then the graph can show both the current state and the history without pretending the old owner never existed.
This is also how you avoid the departed-engineer trap. The former owner remains in the history with 14 commits. Decision D-21 marks the handover. The current Platform on-call is a separate, dated fact. Nobody has to delete the history to make the answer correct.
The escalation path is part of the answer
During an incident, the first name is not always enough. The answer should include the owning team, the active on-call, and the next escalation if the service is unowned or the rotation has a gap.
A missing on-call edge is as important as a missing owner. config-service has neither in the sample company. The answer states that plainly, which is more useful than a plausible name.
Worked example: two services, two answers
payments-gateway: owned by the Platform team, with the Platform rotation on call. dispute-service: owned by Payments, with the Payments rotation on call, and an SLA that expires on 2026-06-30. The second answer includes an expiry warning because the record has a valid_to date.
Both answers carry dates. If the rotation changed this morning and the graph was not synced, the date shows the lag instead of hiding it.