You've built a service catalog with an owner field on every entry. A year later, half the owners listed are people who left the company. How would you design the catalog so that doesn't happen?

Short answer

Treat ownership as a derived, continuously verified fact rather than a manually entered field: source it from an existing system of record, expire it on a schedule, and fail builds or pages loudly when it goes unverified.

The practical backstage test is whether the service catalog ownership data goes stale answer gives the interviewer something concrete to challenge.

Why a free-text field guarantees decay

A service catalog's owner field is usually a string someone typed once, during onboarding, when the information was true and nobody had a reason to update it since. Ownership changes constantly: people leave, teams reorganise, a service gets handed to a new group after a reorg nobody told the catalog about. A manually entered field records a fact at a single instant and then never checks whether that fact still holds. The catalog does not become wrong all at once; it becomes wrong entry by entry, silently, until the day someone pages the listed owner during an incident and gets an out-of-office reply from an account that was deactivated months ago.

The fix is not a reminder email asking teams to review their entries once a quarter. Reminder-based upkeep degrades at the same rate as the data it is meant to protect, because the incentive to respond to a nagging bot is weaker than the incentive that made the field wrong in the first place. The fix is to stop treating ownership as something a human types into the catalog and start treating it as something the catalog derives from a system that already has an operational reason to stay accurate.

Deriving ownership instead of storing it

Most organisations already have at least one system where getting ownership wrong has an immediate consequence: an on-call rotation tool, a repository's code-owners file, or an identity provider's team membership. Any of these is a better source of truth than a catalog field, because someone notices quickly when the on-call schedule pages the wrong person, whereas nobody notices a catalog entry being wrong until it matters.

The catalog's job then becomes joining against that source rather than storing the fact independently. A service entity references a team identifier that exists in the identity provider; the catalog resolves the current members and the current on-call contact at read time, or on a short refresh cycle, rather than baking a name into the entity's YAML at creation time.

# Weak: a name baked in at creation time, correct only until it isn't.
metadata:
  name: payments-webhook-processor
  owner: "jordan.ellis@company.com"

# Stronger: a reference resolved against a system that has to stay current.
metadata:
  name: payments-webhook-processor
  ownedBy: group:payments-platform   # resolves against the identity provider
  onCall: pagerduty:payments-platform-primary   # resolves against the rotation

This does not remove every failure mode. The identity-provider group can itself be stale if nobody prunes it when a team disbands, and a rotation tool can list an escalation policy nobody has tested in a year. But it moves the point of failure from "a string nobody watches" to "a system with its own incentive to be correct," which is a strictly better place for a fact to live.

Making staleness visible rather than silent

Deriving ownership handles the common case. The remaining problem is detecting when derivation itself fails: a team identifier that no longer resolves to anything, because the group was deleted during a reorg and the catalog entry was never repointed. This needs an active check rather than a passive hope that someone notices.

A validation job that runs on every catalog change and on a schedule can resolve every entity's ownership reference and flag anything that fails to resolve, has an empty membership, or points at a rotation with no active schedule. The catalog should refuse new entities without a resolvable owner, and existing entities that fall into an unresolvable state should be surfaced somewhere with actual consequence — a dashboard a platform team reviews weekly, or a build gate that blocks a deploy from an entity flagged as ownerless, rather than a quiet log line.

flowchart TD
    A[Catalog entity references team id] --> B{Resolves against<br/>identity provider}
    B -- No --> C[Flag ownerless<br/>block risky actions]
    B -- Yes --> D{On-call rotation<br/>has an active schedule}
    D -- No --> C
    D -- Yes --> E[Entity marked<br/>verified this cycle]

The interesting edge in that flow is the gap between an entity resolving to a team and that team having a live rotation. A team can exist, have members, and still have nobody actually on call for it, which is a distinct failure from having no team at all and needs its own check.

The trade-off nobody likes stating aloud

Automatic verification means some catalog entries will be correctly flagged as ownerless, and someone has to decide what happens next: does a deploy for an ownerless service block, warn, or proceed? Blocking is the only choice that actually forces the gap to be closed, but it also means a legitimate deploy can be stopped by a stale identity-provider group during an incident, which is precisely the wrong moment. The workable answer most platforms converge on is to block only the highest-risk actions — granting new access, promoting to production for the first time — and to warn loudly everywhere else, accepting that some staleness will persist between the warning and someone acting on it.

A catalog that only records ownership is a snapshot; a catalog that verifies ownership on every read is the only kind that stays trustworthy a year after launch.

© 2026 Preptima. Originally published at preptima.com.