In a monorepo with thousands of projects and hundreds of teams, what typically causes ownership metadata like CODEOWNERS entries and project tags to decay over time, and what governance practices keep it trustworthy?

## Two systems that never sync Ownership metadata — CODEOWNERS entries, project tags like an Nx scope label, any config that says team X is responsible for path Y — is not automatically kept in sync with the organization's actual team structure, because the two live in entirely separate systems. - **Team structure** lives in an HR or identity-management system: who reports to whom, which teams exist, who's on which team, and it changes through reorgs, team splits and mergers, and people leaving. - **Ownership metadata** lives in a text file or config inside the repository, and changes only when someone remembers to edit it, usually as an afterthought during a reorg that's already consuming everyone's attention on org charts and headcount, not repository configuration. There is no default mechanism that propagates a change in one system to the other, so the two drift apart silently, and the drift is invisible until something forces it to surface: a pull request that can't find a valid reviewer, or a security audit that discovers a critical path is owned by a team that no longer exists. ## How the decay compounds at scale At the scale of thousands of projects and hundreds of teams, this decay compounds into a few recognizable patterns. 1. **Orphaned packages** are the clearest failure: a team that owned some utility or service is disbanded or reorganized away, its work absorbed piecemeal into other teams, and nobody explicitly claims the old package — it keeps working, since code doesn't stop running because its owner left, so there's no forcing function to notice until it needs a change, at which point there's no clear owner to make it or approve it. 2. **Catch-all accumulation** is a related but distinct pattern: rather than force every new or orphaned package through an explicit ownership assignment, organizations often default unclaimed paths to a broad platform or infra team, which is a reasonable safety net in small doses but, left unchecked, causes that team to accumulate review responsibility for code it doesn't actually understand, diluting the meaningfulness of 'owner' for an ever-larger share of the repository. 3. **Bloated, unaudited CODEOWNERS files** are the third pattern: a file that started as a few dozen carefully maintained lines grows to thousands of entries over years, with no process ensuring old entries are still valid, making manual review of the whole file impractical and drift essentially guaranteed. ## The automated side The governance practices that keep this trustworthy fall into two categories: automated validation and scheduled human process. On the automated side, a CI check, run on every change to the CODEOWNERS file itself and on a nightly schedule across the whole file, can validate every listed username or team handle against the organization's current identity provider or team-management API, failing or flagging any entry that references a team that's been deleted, renamed, or has zero active members. This converts a silent failure, a stale entry nobody notices, into a loud, immediate one, CI red, someone has to fix it, at the point where it's cheapest to catch, right when the entry goes stale, rather than months later when a PR is already stuck. Complementary bot-driven signals include: - flagging modules with unusually low recent commit or review activity from their nominal owner, a proxy for 'this team has stopped actually working on this code'; - an unusually high ratio of external contributions relative to owner contributions, a proxy for 'this is actually owned by whoever keeps fixing it, not whoever's listed'. ## The process side On the process side, the most effective lever is tying ownership review directly to the reorg calendar rather than treating it as a separate, easy-to-forget task: whenever a reorg is announced or executed, updating affected CODEOWNERS entries and project tags becomes a required checklist item, owned by someone, often an engineering-productivity or platform team, whose job includes tracking it, not left to the discretion of whichever team happens to remember. Larger organizations supplement this with periodic, calendar-scheduled ownership audits, quarterly or biannual, independent of any specific reorg, specifically to catch drift that accumulates gradually rather than in a single discrete event, and increasingly treat 'percentage of paths with a valid, currently-staffed owner' as a tracked engineering-health metric rather than something nobody measures until an incident, a security vulnerability in an orphaned package with no one to own the fix, forces the question.