What it measures

Code ownership measures the distribution of authorship and maintenance responsibility across a codebase. For a given file, directory, or service, it identifies which contributors have written and reviewed the most lines or commits, and how concentrated or spread that responsibility is. High ownership means one or a few people account for most of the changes to an area. Low or shared ownership means many contributors touch the same code.

It is usually expressed two ways: who owns a piece of code, and how concentrated that ownership is. Concentration matters because it signals both expertise and risk. A service with a single dominant owner has clear accountability but a thin safety margin if that person leaves or is unavailable.

Ownership is a structural property of the codebase and the team, not a productivity score. It tells you where knowledge sits and where responsibility is clear or ambiguous.

How to measure it

The base signal comes from git history. For each path, attribute commits and the lines they change to their authors over a chosen window, then rank contributors by their share. A common definition treats the author with the largest share of recent changes to a path as its primary owner, with a concentration figure such as the top contributor's percentage of total changes.

Review data sharpens the picture. Pull request authorship tells you who wrote the code, while review and approval history tells you who else understands it well enough to vouch for it. Combining both distinguishes true shared ownership from code that one person writes and no one else reads. Deploy and on-call records add another layer: who ships and operates a service often differs from who last edited it.

Watch the window and the path granularity. Ownership computed over all time hides recent handoffs, while a window that is too short overreacts to a single refactor. File-level ownership is noisy; directory or service level is usually more stable and more useful for decisions.

What it does not tell you

Code ownership tells you who is changing an area of code and how concentrated that work is. It does not tell you whether the work matters. A contributor can be the clear owner of a service that no longer serves any active initiative, and the ownership number will look identical to ownership of the most strategically important code in the company. Concentration also reads as expertise and as risk at the same time, and the raw metric cannot tell you which one applies without knowing what the code is for.

It says nothing about quality, correctness, or whether the owned code should exist. A single dominant owner might reflect deep expertise or an undocumented silo no one else dares touch. Heavy churn in an owned area might be healthy iteration on a live initiative or thrash on a dead end. Ownership measures the shape of responsibility, not its value or direction.

This is the gap Execution Intelligence closes. Knowing who owns a service is motion. Knowing which initiative that service advances, whether that initiative is active or abandoned, and what the ownership concentration means for delivery risk is direction. The point is to read what is actually being built and why it is owned the way it is, not just how many commits a name accumulated against a path.

How InteliG uses it

InteliG computes code ownership directly from real git and deployment history, with no manual CODEOWNERS files or tagging to maintain. It attributes authorship and review across files and services, then connects each owned area to the initiative the work belongs to, the contributors behind it, and the cost of that effort.

Cognis reads ownership as part of a larger chain rather than a standalone figure. It can see that a concentrated owner sits on a service tied to an active strategic initiative, flag the delivery risk that concentration creates, and tie that risk to the people and spend involved. Ownership becomes evidence about how the organization is actually executing, not a number on a dashboard.

Related terms

Bus Factor — How many people would need to leave before an area of code loses its maintainers.
Code Churn — How much code is rewritten or reworked shortly after being committed.
Execution Intelligence — Reading engineering work against the strategy and cost it serves, not just its volume or speed.