Code ownership is a graph, not a CODEOWNERS file

CODEOWNERS is useful. It is also an incomplete description of who understands a software system.

A file can name a team that has not touched the code in a year. A staff engineer can carry critical production knowledge without appearing in the ownership file. A frequent contributor can understand implementation details while lacking authority to approve a change. These are different relationships, and flattening them into “owner” makes both automation and management worse.

Code ownership is a graph.

Declare authority, observe expertise

Start by separating what the organization says from what the work reveals.

Each signal becomes a typed relationship rather than a column named owner.

(team)-[:OWNS]->(service)
(person)-[:CONTRIBUTED_TO]->(module)
(person)-[:REVIEWED]->(pull_request)
(person)-[:RESPONDED_TO]->(incident)
(person)-[:AUTHORED]->(decision)

Now Helix can answer “Who must approve this?” and “Who has relevant context?” without pretending they are the same question.

Expertise should decay carefully

Experience becomes stale, but not all knowledge expires at the same rate. A contributor from last quarter may still understand a stable service. A reviewer from two years ago may no longer know a rewritten subsystem. An incident responder may retain valuable knowledge about a failure mode even after leaving the owning team.

Use time as one factor, not a delete button. Weight expertise with:

• recency of meaningful changes and reviews;
• depth of contribution, not raw commit count;
• proximity to the files or services in question;
• involvement in incidents and architecture decisions;
• whether the underlying area has changed since the activity.

Most importantly, label the result as inferred expertise.

Find knowledge risk before an emergency

A graph can reveal ownership problems that a directory cannot:

• one person is the only recent reviewer across a critical payment path;
• declared owners have no observed activity in the subsystem;
• a service crosses three teams but has no clear coordinating owner;
• incident knowledge lives with someone outside the current on-call rotation;
• a repository has active contributors but no one connected to its architecture decisions.

These are not performance metrics. They are continuity signals. Used carelessly, they become surveillance. Used well, they help teams distribute context before leave, reorganization, or an incident makes the gap painful.

Route reviews with evidence

Review assignment is where a richer ownership model becomes immediately useful.

Instead of selecting the person with the most commits, trace the changed files to services, requirements, incidents, and prior reviews. Then explain the suggestion:

Maya is a suggested reviewer because she reviewed the last three changes to the retry contract and resolved Incident #91. The Payments Platform team remains the declared approver.

The explanation matters. It gives the team a chance to correct the graph and prevents inferred expertise from quietly becoming organizational authority.

Preserve corrections

When an engineer says “I am not the owner of this anymore,” the system should not forget that correction on the next sync. Store it as a durable event with scope, author, and time.

Corrections can express:

• this team owns the service now;
• this relationship is stale;
• this engineer has context but is not an approver;
• this module is intentionally shared;
• this repository is archived.

The graph becomes more accurate because the people inside the system can teach it.

Ownership is an interface to context

The point of ownership is not to create a perfect org chart. It is to get a change, question, or incident to the people with the right authority and the right memory.

Declared ownership, observed expertise, and operational responsibility should remain separate—but connected. That model is more honest, more useful for reviewers, and far safer for coding agents deciding who should approve their work.