Ownership at Scale

1Repository ownership can enforce review when coverage and merge rules are configured

Google's monorepo set the template. Specially named OWNERS files list the people responsible for a directory and its children. A file is owned by the union of every OWNERS file above it in the tree, so a new project needs no central registration, only a new OWNERS file (SWE at Google, ch. 9). Owner approval is one of three independent approval "bits." The other two are a peer's LGTM and language "readability," and one person can supply several bits at once. Google says the model scaled over two decades to tens of thousands of engineers working on billions of lines of code in one repository. It also admits that the control "sometimes" is onerous (SWE at Google, ch. 9). OWNERS entries can reference other files or ACLs, but they "eventually resolve to a list of individuals." The public Gerrit code-owners plugin that Chromium, Fuchsia and AOSP use goes further: "Groups are not supported in OWNERS files." For files that match no rule, it offers fallback code owners (Gerrit code-owners backend; user guide).

Chromium publishes the most explicit rules for keeping owner lists healthy. An owner must be a committer with at least three months' tenure who has committed or reviewed substantial work in the directory within the last 90 days. An owner who falls short for more than a quarter can be removed after four weeks' notice; if an owner's removal is contested and the directory has fewer than four owners to vote, the decision escalates to the parent directory's owners (Chromium code_reviews.md). Chromium also shows that enforcement tends to tighten over time. Until 24 March 2021, presubmit scripts enforced owner approval and the "TBR" convention could bypass it. Gerrit now enforces it natively, and committers can no longer get around it. A bot may stamp verifiably safe reverts and cherry-picks, but it "never provides OWNERS approval, by design," because that combination would allow "the silent revert of security patches" (Chromium code_review_owners.md). Kubernetes, the other widely copied format, applies the same idea of liveness to open source. Approvers with fewer than 10 contributions and 10 PR comments in a year move to emeritus_approvers; inactive reviewers are removed. Owner groups live in a version-controlled OWNERS_ALIASES file because "changes to GitHub Teams are not publicly auditable" (Kubernetes OWNERS guide).

GitHub and GitLab took a different approach: one CODEOWNERS file per branch. GitHub uses the last matching pattern. GitLab uses the last matching entry within each section and evaluates sections independently, so one file can need approval from owners in several sections (GitLab CODEOWNERS reference). The file alone does not block anything. On GitHub, owners are requested for review, and their approval is required only when branch protection or a ruleset requires review from code owners. That choice has consequences at scale. On GitHub, approval from any one listed owner satisfies a line. A file that matches no pattern needs no owner approval. An owner who doesn't exist or lacks explicit write access is silently left unassigned. A file over 3 MB is not loaded at all (GitHub Docs). Under the Gerrit model every file has at least a parent owner. Under GitHub's, files fall through to "no owner required" without warning, so coverage has to be enforced by linting. Large GitHub users have therefore stopped hand-editing CODEOWNERS and generate it from higher-level metadata. GitHub's own Rails monolith (4.2M+ lines across ~30,000 files) maps paths to services in a SERVICEOWNERS file and generates CODEOWNERS from it (GitHub Blog). The code_ownership gem used in Shopify-style Packwerk monoliths does the same from package.yml. It also keeps an unowned_globs list as "a TODO list of files to add ownership to" (rubyatscale/code_ownership). In February 2026 GitHub made the split formal. Its rulesets "required reviewer" rule, now generally available, requires N approvals from designated teams for matching paths across an entire enterprise, on the principle that "while CODEOWNERS defines ownership, this rule focuses on policy enforcement" (GitHub changelog).

Meta puts the owner in the build graph. Internal Buck supports an oncall annotation in BUCK files (react-native PR #35562). That makes the owner an on-call rotation rather than a list of reviewers, and the same identifier can then route reviews, alerts and accountability. Phabricator, which came out of Facebook, handles overlapping claims differently again. Its "strong dominion" packages keep files even when a narrower package also claims them, while "weak dominion" packages yield (Phabricator Owners).

2Service registries map stable service IDs to HR-synced teams

Ownership files describe code, but most work arrives at the level of services, datasets and cloud resources, and those need a second layer. GitHub's design states the logic outright: "no team 'owns' anything, but instead they 'maintain' various services." SERVICEOWNERS maps files to a service name. A separate service-mappings.yaml maps each service to its team, PM, EM, chat channel and a tier from 0 (critical) to 3 (experimental). Repositories elsewhere in the org register through ownership.yaml. Because files point at services rather than teams, "changing which team or teams maintain a service is a one-line YAML change" (GitHub Blog).

The largest companies go further and run a central ownership registry that other systems call as a service. Uber's uOwn holds the org hierarchy and the roles on services, Kafka topics and database instances. Those roles are either defined on the asset or inherited from the hierarchy (Uber ABAC). Uber's access-control design lets one generic policy read the groups holding the "Develop" role on a Kafka topic from uOwn, so authorization can follow ownership without per-topic policy edits. Cost is tracked "at a uOwn … level granularity" (Uber DataCentral). Uber's DataMesh maps uOwn's org tree onto GCP folders, projects and buckets. When no owner is declared, it infers one from storage location or "the organization of the asset creator," and it "continuously monitors ownership changes and performs remapping in the background" after reorgs (Uber DataMesh). Microsoft's equivalent, Service Tree, has no public documentation, but indirect evidence shows its reach. First-party resource providers register with ServiceId and ComponentId fields (Azure SDK ServiceTreeInfo). Compliance work in S360 goes to each service's "Primary Dev Owner". Anyone who doesn't own a service is pointed to "the closest person in your reporting chain who does" (Microsoft Q&A, S360). Uber and Microsoft tie ownership to access, money and compliance, and that coupling keeps the data accurate, because a wrong owner shows up as a broken permission or a misdirected audit finding. Backstage's documentation takes the opposite position: the owner field "is not to be used by automated processes to for example assign authorization in runtime systems" (Backstage descriptor format).

Backstage is now the most common catalog model outside those in-house systems. Every Component, API, Resource and System requires an spec.owner, defined as "the singular entity (commonly a team) that bears ultimate responsibility." Groups form a tree in which a group "may however not have more than one parent," which forces matrix organizations to pick one reporting line for roll-up (Backstage descriptor format). Large adopters do not hand-write those groups. They run org "entity providers" against Entra ID, LDAP or GitHub on a schedule; the LDAP example uses an hourly cadence (Backstage LDAP org), and an incremental provider exists for tenants too large to hold in memory (msgraph-incremental). Entities created by those providers cannot be enriched in place (issue #24710). SoundCloud works around this with an overlay file that adds team-curated fields such as alert email on every refresh, and Prometheus Alertmanager configures its receivers from the catalog API (SoundCloud). Zalando syncs over 40,000 entities daily from source-of-truth systems (Zalando). Spotify records ownership automatically when a component is created from a template (Spotify Engineering, 2020). Commercial portals pull from HR directly. Cortex's Workday integration needs a report containing managerEmail to import team relationships (Cortex Workday).

Across these systems the data model converges on one accountable owning team per asset, plus typed secondary owners. DataHub distinguishes Technical Owner, Business Owner and Data Steward (DataHub ownership types). Datadog's schema v3 added additionalOwners because databases and queues "normally have shared ownership across multiple teams" (Datadog). AWS rates "Resources have identified owners" as a high-risk best practice, wants "a single owner where possible," and lists two teams with overlapping ownership of critical infrastructure as an anti-pattern (AWS Well-Architected OPS02-BP01). On the surface this conflicts with Google's and Gerrit's preference for named individuals. The resolution is about what each layer is for. Code approval is a judgment call, so it goes to named individuals, with several owners per directory as a guard against the bus factor. Services and data are long-lived, so they go to teams, and an individual is reached through the team when someone has to answer.

Cloud resources follow the same pattern. Coarse ownership comes from the container (an AWS account, a GCP project or folder, a Kubernetes namespace), and owner tags are enforced when a resource is created. Each platform enforces this differently. AWS tag policies cannot by themselves require a tag, because "untagged resources … aren't evaluated for compliance" (AWS tag policies). AWS's own guidance adds a service control policy that denies creation when aws:RequestTag keys are missing, and that statement has to be written per API action (AWS Cloud Ops blog; re:Post). On GCP, only Tags (not labels) can be made mandatory, through custom organization policy (GCP tags). In the FinOps Foundation's maturity model, the top "Run" level is where requests missing ownership fields "are blocked" before provisioning (FinOps Allocation).

3Owners care when alerts, bugs, costs and audits route to them

Every durable organizational model defines the owner as the long-lived team that both changes the code and absorbs the consequences of running it. At Amazon, Werner Vogels described the principle as "you build it; you run it," with no separate operations department (strehle.de quoting Vogels, 2006). Amazon's later lesson was that a small team is not enough. Former executives Colin Bryar and Bill Carr write in Working Backwards that the biggest predictor of success was "a leader with the appropriate skills, authority, and experience" whose team works on nothing else, which is why "two-pizza teams" gave way to "single-threaded leaders" (Innovation Leader; secondary coverage). Google appears to be the exception, since SRE carries the pager, but the arrangement is conditional. SRE caps operational work at 50% and sends the excess back to development teams, including putting developers back on the pager. SRE takes on a service only after a production readiness review. In the framework model, development teams handle on-call for application bugs (SRE Book; ch. 32). Spotify's squad-and-chapter matrix is the standard cautionary tale. A former PM says chapter leads managed engineers across teams without taking responsibility for delivery, and that the squad model "was only ever aspirational and never fully implemented" (Jeremiah Lee).

The registry turns that principle into daily reality by delivering the operational signal. Yelp's central Ownership service maps Git repos, monorepo directories, Slack channels, Jira projects, PagerDuty schedules, API endpoints and tests to canonical teams drawn from HR data. Alerting queries it to notify owners, automated PRs use it to pick reviewers, and stale metadata generates tickets for managers (Yelp Engineering). Routing incidents is where accuracy matters most. Microsoft found that an incorrect Azure incident assignment "increases its time to mitigate by 10x." Its ML router, DeepTriage, scored 82.9% F1 and, as of 2020, had been deployed since October 2017 and was "used by thousands of teams daily" (DeepTriage, arXiv). A 2025 multi-agent system, Triangle, reports triage accuracy of up to 97% and up to 91% less time to engage (Microsoft Research). Meta's incident root-cause system uses "code and directory ownership" to cut candidate changes from thousands to a few hundred before an LLM ranks them, and it found the root cause in the top five in 42% of backtests (Engineering at Meta). Security findings follow the same path. GitHub's security campaigns group alerts under a named point of contact, and individual alerts can be assigned to users with write access, and org-level Dependabot rules marked "enforced" cannot be disabled by repo admins (GitHub security campaigns; Dependabot rules).

Scorecards make ownership something that is measured continuously. GitHub's "Durable Ownership" scorecard requires every service to have an executive sponsor, a team and a Slack channel. A failing service automatically gets an issue in its repository with a resolution SLA, compliance is tracked weekly against quarterly goals, and the dashboard is sorted by tier. GitHub says some scorecards may become technical controls in which deviations count as incidents and deploys can be frozen (GitHub Engineering Fundamentals). Shopify's ServicesDB kept a checklist for each app (ownership, on-call, logs, security updates) and "opens a GitHub issue and pings owners" when something failed (Shopify Engineering, 2018). Spotify moved quality tracking for 30,000+ components from spreadsheets into automated Soundcheck checks (Spotify Backstage blog). Almost every scorecard's lowest tier requires an owner and on-call before anything else. Independent evidence that scorecards work is missing, however. The outcome numbers come from vendors.

Enforcement runs up a ladder of consequences. At the bottom are automatic blocks, once they are configured: no owner approval, no merge; no service owner for a new file, failed CI; no owner tag, no resource. Above those come operational consequences. Google's example error-budget policy halts all changes and releases for a service that exceeds its four-week budget. Any single incident that consumes more than 20% of the budget requires a postmortem with a P0 action item, and disagreements go to the CTO (SRE Workbook). At the top is pay. Under its Secure Future Initiative, Microsoft tied senior leadership compensation to security and made security a "Core Priority" in every employee's performance review from FY2025 (Microsoft SFI report). Regulation adds outside pressure that doesn't depend on internal culture. DORA Article 8, applicable to EU financial entities since January 2025, requires them to document "all ICT supported business functions, roles and responsibilities" and the supporting assets, and to review this at least yearly (DORA Art. 8). ISO 27001's Annex A 5.9 requires an asset inventory "including owners" (ISMS.online). A machine-readable registry therefore doubles as audit evidence, and that gives it a budget line outside engineering.

The failures follow a pattern: each case lacked authority, signal or capacity. Spotify's matrix lacked authority. Before Yelp built its service, it lacked a reliable signal: ownership was recorded inconsistently and included made-up team names such as "Super Friends plus Julia" (Yelp). Netflix warned about capacity when it adopted "full cycle developers." The operating load brings real burnout risk and should not be used for "squeezing more work out of developers" (InfoQ).

4Ownership decays, so the best systems recompute it continuously

Keeping ownership accurate pays off measurably where ownership is a formal process. In Windows Vista, adding the count of minor contributors (people with under 5% of a component's commits) raised the variance explained in pre-release failures from 26% to 46% (Bird et al., ESEC/FSE 2011). A model built on organizational metrics, including the number of engineers who had touched a binary and since left, identified failure-prone binaries with 86.2% precision and 84.0% recall. That beat code churn, complexity and coverage (Nagappan, Murphy & Basili, ICSE 2008). The evidence has limits. In open-source Java projects the correlation was weak or absent (Foucault et al.), and a 2024 replication at a small company found no strong minor-contributor effect (Koana et al.). The fairest reading is that the ownership-quality link holds where ownership is enforced, which describes exactly the large companies this report covers. Turnover adds to the risk. Recent departures were associated with more customer-reported defects, while new hires were not (Never Work in Theory on Mockus 2010). Interviews also show that internal transfers behave like departures, because the former owner's knowledge fades gradually (Robillard et al., FSE 2021).

The first defense is structural. With files mapped to services, services to teams, and teams to people synced from the identity provider, departures resolve themselves at the person level. Meta treats ownership as a moving target: its Ownesty system applies machine learning across "many millions" of source files, tables and configs, because the most suitable owner "changes over time," and escalation processes exist "to rule out unowned assets" (Ownership at Large, arXiv). Sync does not fix everything. When a team is dissolved or merged, someone still has to decide where its services go, and that is why orphan queues and scorecards exist. Vendor claims that "ownership moves with them" when engineers leave come with no latency or accuracy data (Cortex).

The second defense is validation at write time, applied as a ratchet. GitHub's CI requires every new file in the monolith to have a service owner and rejects patterns that match nothing (GitHub Blog). code_ownership fails CI unless all files are owned, with exceptions parked in an explicit list that shrinks over time (rubyatscale). Open-source linters flag duplicate patterns, dead patterns, nonexistent owners, and broad rules that shadow specific ones (codeowners-validator). These checks matter because ownership files fail open. A "percent of files owned" figure is easy to inflate with a root * rule, and it is meaningless if owners silently fail to resolve. Catalog freshness is also weak in practice. In a vendor survey, 53% of teams said they update software-asset metadata at most weekly (Port 2025).

The third defense is inference, and the evidence there is mixed. The signals are authorship share, git blame, review activity, recency windows, on-call data and org-chart roll-ups. GitHub's suggested reviewers use blame data (GitHub Docs). Sourcegraph Own uses 90-day windows of recent contributors and recent viewers (Sourcegraph). OpsLevel bases suggestions on "the top three contributors to that service" (OpsLevel). Atlassian Compass suggests an owner team from repository, Confluence and Jira signals, and a user approves or declines it (Atlassian). None of these vendor sources gives precision or recall. Research shows authorship metrics find main authors well: 84% of valid survey answers agreed or partially agreed with the identified authors (Avelino et al., ICPC 2016). Finding experts is not the same as finding accountable owners, though. Across more than 21,000 reviews, a deployed recommender produced no evidence of changing whom developers chose, because they usually already knew an expert (Kovalenko et al.). Inference therefore adds the most value where human memory has already failed, in orphaned or post-reorg code, and that is where recency signals are weakest. The industry's consistent "suggest, then a human confirms" design reflects this.

The strongest evidence-backed lever is to spread knowledge deliberately. When only authors count as knowledgeable, 79% of files are "at risk" from turnover. Counting reviewers drops that to 32%. Turnover-aware recommenders cut files at risk by about 30%, while one load-balancing recommender raised them by 46% (Hajari et al.). A 2026 approach cut files at risk by 42% while adding an extra reviewer to only 1.9% of PRs (ICSE 2026). Strict owner-only review concentrates knowledge, and occasional non-owner review is cheap insurance against it.

The last defense is deleting code instead of finding an owner for it. Meta's SCARF builds dependency graphs and generates deletion diffs daily. It has removed more than 100M lines across 370,000+ change requests in five years and auto-merges without human review in some languages (Meta Engineering). For data, assets with no usage metrics are deleted automatically, and those with usage go to a human (Meta, product deprecation). Google's Sensenmann submits over 1,000 deletion changelists a week and has removed nearly 5% of Google's C++ (Google Testing Blog). Every deleted asset is one less thing that needs an owner, so for assets with neither a valid owner nor real usage, deletion is the cheapest form of reassignment.

5Fleet-wide changes route around owners instead of waiting on them

Strict per-directory ownership would make cross-cutting change impossible at Google's scale, so Google built an explicit bypass. A large-scale change (LSC) needs a short authorization document approved by a committee of about a dozen people. The Rosie tool splits it into shards along OWNERS boundaries, weights candidate reviewers by expected relevance, and adds reviewers when owners don't respond. Shards often go to a single global approver, who auto-approves pattern-conforming changes and reviews only anomalies. Local owners can comment, but they "don't hold a veto." In return they must keep their tests free of preexisting failures so automated changes can land. LSCs produce 10–20% of the changes in a typical project, and one migration peaked at more than 700 changes touching 15,000+ files per day (SWE at Google, ch. 22). Google is also blunt about the alternative. A compulsory migration pushed onto customer teams without central staffing becomes an "unfunded mandate" that stalls (SWE at Google, ch. 15). Will Larson's widely cited playbook from his time at Stripe reaches the same conclusion: the migrating team automates the easy majority, ratchets against new usage, reports status to management, and personally finishes the long tail (Lethain).

Spotify went further and reversed the default. Before Fleet Management, a Java runtime upgrade took eight months and about 2,000 semi-automated PRs (Spotify Part 1). Now fleet-wide "shifts" open PRs across thousands of repositories that automerge by default when tests pass, only during the owning team's working hours. Only about 50 repositories opt out, and each opt-out needs a documented reason and ideally an expiry date. Pre-flight CI runs (Fleetsweep), post-merge deployment monitoring (Firewatch) and cohort rollouts replace per-change approval (Spotify Part 3). The results are large. More than 300,000 changes merged, 75% automerged. A Log4j fix reached 80% of production backend services in nine hours. A framework update that once took about 200 days to reach 70% of services now takes about seven (Spotify Part 1). Other companies sit at different points on the same spectrum. Uber's Piranha assigns each stale-flag cleanup diff to the flag's author rather than the directory owner, and a reminder bot chases open tasks (Uber Engineering); about 65% landed unchanged (ICSE-SEIP 2020). Allegro can set a deadline for time-boxed migrations such as security fixes, then force-merge every migration PR that builds successfully (Allegro Tech).

AI-authored changes have not changed who approves, but they have changed where the bottleneck sits. In Google's int32-to-int64 migration, about 80% of code modifications in landed changes were fully AI-authored. Those changes were still sharded to the owners of the affected code, and in Google's JUnit migration, generation was deliberately throttled to avoid overwhelming reviewers (Nikolov et al., arXiv 2501.06972). Amazon reported that developers shipped 79% of Q Developer's auto-generated Java upgrade reviews without further changes (Simon Willison quoting Andy Jassy). Since mid-2024 about half of Spotify's PRs have come from Fleet Management, and agent PRs pass through the same automerge-or-review flow (Spotify Engineering, Nov 2025). By early 2026, Spotify said PR review, not code generation, is the bottleneck, and its engineers outlined letting migration drivers approve their own PRs (InfoQ, Mar 2026; secondary coverage). Not everyone found AI suitable for bulk work. Uber's 2026 JUnit migration judged GenAI bulk migration unsuccessful and used deterministic OpenRewrite instead (Uber Engineering). I did not find an AI-specific ownership exception in these sources. In the cases above, what governs a change is how well it can be verified and what class of change it is, not whether a human or a model wrote it. Reported rates for AI output (79% shipped unchanged at Amazon, as relayed by Simon Willison; about 87% in Google's JUnit migration) sit near those of pre-AI codemods (65% landed unchanged for Piranha, 75–77% automerged at Spotify). These figures are not directly comparable and do not establish relative trust or causal impact: they measure different things (unchanged acceptance, landed modifications, automerges) over different populations, selection processes and denominators. At most they fit the hypothesis that AI's main contribution is extending automation to migrations that were previously too complex, rather than earning more trust per change.

Conclusion

The meaning of "owner" at the largest companies is changing. The owner used to be the gatekeeper who approves every change. Increasingly the owner is the party accountable for the preconditions that let others change the code safely: green tests, canaries, a reachable on-call, a valid registry entry. Google's LSC "social contract," Spotify's opt-out automerge and Meta's auto-accepted deletions all make that trade. Owners give up veto power and per-change review, and in exchange central teams and, more and more, agents carry the cost of keeping code current. Organizations that still require human owner approval on every change will find AI-generated volume running into review capacity. Organizations that have invested in verification can move that volume through automerge lanes. The second insight is that ownership data stays accurate only in proportion to how much consequential work flows through it. Uber wires ownership into authorization and cost, Microsoft into compliance, and both Microsoft and Meta into AI incident triage. In each case a wrong owner causes immediate, visible pain, and that pain does more for data quality than any audit. AI raises the stakes on both sides: stale ownership now degrades automated triage and root-cause analysis, while owners' review bandwidth becomes the scarce resource that limits fleet-wide change.

For anyone designing this at scale, the evidence supports a specific architecture. Use stable service IDs between files and teams. Source teams from HR or the identity provider, with an enrichment overlay. Use write-time ratchets instead of after-the-fact audits. Route alerts, vulnerabilities, cost and compliance through one registry. Treat recent departures and reorgs as defect-risk signals, not housekeeping. Delete before reassigning. The main unknowns are empirical. None of the sources reviewed here report ownership-coverage rates, time-to-reassign after a reorg, or the accuracy of owner inference. Until such data is available, claims that any approach keeps ownership "always current" should be treated as design intent, not demonstrated outcome.