A text field is not an ownership system
A wiki table with an "owner" column looks like an ownership system until someone changes teams. It has no dates, no relationships and no way to answer what breaks when the service fails. The first question in a demo should be "what happens when this field is wrong?"
An ownership system needs to represent the service, the team, the on-call rotation, the dependencies and the decisions as separate records that link to each other. That is what makes the answer checkable.
Five capabilities that matter
Most catalogs claim to solve ownership. These are the capabilities that separate a useful record from a prettier spreadsheet:
- A service catalog with a current owner and a start date for the edge.
- Dependency edges, including direction and whether the call is synchronous or asynchronous.
- On-call integration, so ownership and the current pager are different facts but visible together.
- Decision history, so a handover has an author, a date and a reason.
- An API that returns the records behind an answer, not just a generated sentence.
Build versus buy
A small team can start with a service catalog it already has: import the services, add the owner and the on-call rotation, and record the first handover as a decision. The hard part is not the schema; it is keeping the edges current.
Buy or build should depend on whether you need graph traversal. If the question is only "who owns this service?", a catalog with dates may be enough. If the question is "what breaks if this fails, and who owns every service in the path?", relationships are the product, not a nice-to-have.
Demo questions that expose weak tools
Ask the vendor to show an unowned service. A tool that invents an owner or shows a blank page has not solved the problem. Ask how a handover is recorded, what happens to the previous owner, and how a stale dependency edge is flagged.
Finally, ask for the evidence behind one answer. If the tool can show the edge, the date and the decision, it can be audited. If it can only produce a confident paragraph, it is a search box with better typography.
Worked example: three tools, one question
A wiki table returns "Platform" with no date. A service catalog returns the Platform team and an on-call rotation, but cannot show what depends on payments-gateway. A graph returns the owner, the on-call, eight downstream services and Decision D-21 in one traversal.
The difference is not the interface. It is whether the answer carries the relationships and dates needed to check it. The graph can also return config-service as unowned, which is the finding that changes the incident plan.