GitOps governance broke down for a reason nobody predicted at the start: not because GitOps failed, but because it succeeded so completely that every team adopted it on its own terms. Platform engineering rolled it out first, as a single reconciliation loop with one Git repository as the source of truth for the cluster. Then security stood up its own repo for policy enforcement. Then the data platform team wired its own GitOps loop for quota and namespace lifecycle. Then the AI/ML team did the same for cluster automation. Each loop is clean. Each loop is correctly owned. And none of them talk to each other.
Where GitOps Started
GitOps began as an answer to a specific, narrow problem inside modern infrastructure and IaC practice: infrastructure state drifted because there was no single authoritative source of truth and no enforced path back to it. The fix was elegant — declare state in Git, run a reconciliation loop that continuously enforces it, and treat any manual change as something to be overwritten, not tolerated.
Critically, the original model assumed one loop. One repository. One team accountable for what that repository controlled. Platform engineering owned the cluster; the cluster was the entire scope. Reconciliation ownership and infrastructure ownership were the same thing, held by the same team, over the same boundary. That assumption is where most early GitOps governance thinking still lives — and it's the assumption this post is about to break.
GitOps Has Escaped The Platform Team
That single-loop model didn't survive contact with a real enterprise estate, because GitOps is not hard to adopt. It's a pattern, not a platform — a repo, a reconciler, a target. Any team with a Kubernetes namespace and ten minutes can stand one up. And they did.
Security teams adopted GitOps for policy-as-code — OPA/Gatekeeper or Kyverno policies, declared in their own repository, reconciled independently of whatever the platform team's loop was doing to the same cluster. Data platform teams adopted it for quota and storage-class lifecycle, because manually provisioning storage classes per environment didn't scale once the data platform had its own release cadence. AI/ML teams adopted it for cluster automation — GPU node pool scaling, scheduler configuration, runtime policy — because none of the existing platform tooling moved fast enough for model-serving iteration speed.
None of these teams asked platform engineering's permission, and in most organizations, none of them needed to. GitOps doesn't require central issuance the way a shared Terraform module or a platform-provided CI pipeline does. A team just needs a repo and a controller. That's the entire adoption barrier, and it's low enough that GitOps governance now happens in four or five places at once inside a single enterprise estate, each one legitimately owned, none of them aware of the others' reconciliation scope until they collide on a shared resource.
This is the actual claim behind the title: GitOps governance didn't fail as a control mechanism. It won so completely that ownership of "the truth" fragmented across every team that adopted it, and nobody planned for what happens when four truths touch the same cluster.
The Shared Resource Problem
This isn't a hypothetical GitOps governance failure mode. It's the default condition of any cluster old enough to have accumulated more than one GitOps adopter, and it shows up at exactly the seams you'd expect.
Platform engineering's repo controls namespace lifecycle — creation, labels, resource quotas at the namespace boundary. Security's repo controls policy enforcement — admission control, network policy, pod security standards, applied cluster-wide. Data platform's repo controls storage-class provisioning and per-tenant quota. Application teams' repos control deployment manifests, reconciled through whatever CD tool sits closest to their pipeline.
All four target the same cluster. None of the four repos references the other three. When platform engineering deletes a namespace as part of a cleanup pass, security's cluster-wide policies still apply to whatever gets created in its place — correctly, per security's own repo, with no awareness that the namespace's provenance changed. When data platform pushes a quota change that would leave an application team's workload unschedulable, nothing in either team's reconciliation loop flags the interaction before it happens at apply time. Each loop passes its own validation. The composite failure only becomes visible at runtime, and by then it reads as an incident, not a design gap — because nothing upstream was positioned to catch it. This is where GitOps governance actually breaks: not within any single loop, but at the seam between them.
This is the same underlying condition "The Infrastructure Control Plane Is Consolidating" describes from the opposite direction — and the relationship is worth sitting with, not just naming. That post traces what happens when a single vendor's control plane accumulates enough operational authority that alternatives become impractical: authority concentrating until it captures everything. This post is the mirror image. Authority never concentrates at all. It stays legitimately distributed across four teams indefinitely, and the failure isn't capture — it's the absence of anything sitting above the four loops to arbitrate where they touch. Capture and this condition are opposite failure modes of the same underlying question: who has final say over shared infrastructure state. One answers it wrongly by letting one party win everything. The other never answers it at all.
It's also not unique to GitOps, or even to infrastructure-as-code. "Multi-Cloud Coherence Is an Ownership Problem, Not a Technology Problem" traces the same fragmentation in a different domain — multiple cloud providers, each correctly managed by whichever team owns that relationship, with no single party accountable for the coherence of the estate across all of them. And the deferral pattern "IDPs Don't Solve the Ownership Problem. They Defer It." describes — platform teams building IDPs that defer ownership questions rather than resolving them — is the same instinct that lets four GitOps loops stand up independently in the first place: adopting the tool is easy, and nobody has to answer the harder ownership question to do it.
What Happens When Every Team Owns The Truth
GitOps governance at scale runs into a problem the single-loop model never had to solve. Once the Platform Repo / Security Repo / Data Platform Repo / App Repo scenario above is on the table, the underlying condition has a name, and it isn't a boundary. Nothing here fails at a threshold — nothing was ever built to fail at. What's missing is a mechanism that was simply never constructed: an Authority Arbitration Gap — the condition where multiple legitimate authorities govern overlapping portions of the same infrastructure domain, each correct within its own scope, and no arbitration mechanism exists where those scopes overlap.
Framework #165 — Authority Arbitration Gap
Multiple legitimate authorities govern overlapping portions of the same infrastructure domain, each correct within its own scope, and no arbitration mechanism exists where those scopes intersect.
| Stage | Description |
|---|---|
| 01 — The Condition | Multiple legitimate authorities govern overlapping portions of the same infrastructure domain. |
| 02 — The Boundary | The point at which those authorities' scopes intersect without a defined arbitration mechanism between them. |
| 03 — Failure State | Composite state emerges from interaction between correct loops rather than from any single owner's decision. |
| 04 — Consequence | The gap surfaces as a runtime incident rather than a design defect, since every individual authority validates correctly right up to the point of collision. |
When arbitration finally gets built after an incident instead of before one, it arrives scoped to the collision that exposed it — not to the boundary that will produce the next one.
The overlap is the actual trigger. Without overlap, four correctly-owned loops never interact and there's no failure to speak of — plenty of estates run several independent GitOps loops against entirely disjoint resources with no issue at all. The condition only activates the moment two authorities' scopes touch the same object, and nothing was ever built to arbitrate what happens there.
Ask any of the four teams whether they own their slice, and they'll say yes, confidently and correctly. Ask who owns the composite state the cluster ends up in once all four loops have reconciled against it, and the honest answer is nobody — not because anyone neglected the question, but because the question was never anyone's to answer. This is exactly the kind of gap the "Governance & Drift" stage exists to name: infrastructure that stays governed over time requires an answer to who's accountable when more than one authority is involved, not just who's accountable within each one.
Related Frameworks
- #135 Control Plane Ownership Boundary (related, moderate) — Adjacent but distinct: #135 is the absence of any accountable owner. #165 assumes ownership is correctly assigned within each of several scopes, and the gap sits in the missing arbitration layer between them.
- #115 Control Plane Capture (related, strong) — Mirror-image failure modes: #115 is authority concentrating in a single vendor/platform until alternatives become impractical. #165 is authority never concentrating at all, remaining legitimately distributed across parties with no arbitration where they meet.
- #133 Policy Intent Drift (related, weak) — Frequently co-occurs in the same Modern Infrastructure & IaC governance lineage, but #133 describes a single unassigned reconciler causing staleness, while #165 assumes multiple correctly-assigned reconcilers, with the gap at the arbitration layer between their scopes rather than within any one loop.
Why This Isn't Policy Drift
Getting GitOps governance right depends on drawing this distinction precisely — two frameworks already registered describe adjacent-sounding but structurally different conditions, and conflating them is the most likely misread of this post.
| Condition | What Exists | What's Missing | Failure Mode |
|---|---|---|---|
| Policy Intent Drift (#133) | A policy | An authoritative reconciler | Declared intent and enforced behavior quietly diverge — one system, staleness |
| Control Plane Ownership Boundary (#135) | Infrastructure state | A defined accountable owner | Multiple systems can modify state with nobody accountable — absence of ownership |
| Authority Arbitration Gap (#165) | Multiple legitimate authorities | An arbitration mechanism between them | Each system is correct alone; nobody owns what they produce together — plurality, not absence |
Framework #133 and #135 both describe a vacuum: nobody's driving, or nobody knows who's supposed to be driving. "Policy Drift Is the Real Day-2 Failure in GitOps" is the worked example of #133's condition — a single, unowned reconciler letting declared and enforced state quietly diverge. The Authority Arbitration Gap describes the opposite structural condition — everybody is driving, correctly, in their own lane, and the intersection itself was never built. The diagnostic signal gives this away immediately: ask any of the four teams whether they own their slice, and they'll answer yes, confidently and correctly. Ask any of them who owns the composite state the cluster ends up in, and the honest answer is nobody — not because ownership was neglected, but because it was never a question anyone's reconciliation loop was built to answer.
📄 One-page framework reference: Framework #165 — Authority Arbitration Gap PDF
What Good GitOps Governance Requires
The instinct at this point is to reach for a tool — a meta-controller, a policy engine that sits above the existing loops and mediates between them. That instinct isn't wrong, but it's premature. A tool bought before the underlying architecture is defined just becomes a fifth reconciliation loop with its own blind spots.
What actually closes the Authority Arbitration Gap is architectural, not procedural:
Explicit authority hierarchy — a documented, enforced statement of which loop wins when two loops' declared intent conflicts on the same resource, decided before the conflict occurs, not adjudicated live during an incident.
Defined ownership boundaries at the resource level, not the team level — not "security owns policy" as a mission statement, but a resource-by-resource map of exactly which fields, labels, or object types each loop is authoritative over, with no overlap left ambiguous.
A conflict resolution mechanism that fires automatically when two authoritative loops attempt to reconcile the same field in opposing directions — not a Slack thread after the fact, a defined precedence rule enforced at apply time.
Composite-state visibility — a single place where the actual, current, merged state of the shared domain is visible across all four loops simultaneously, not reconstructed after an incident from four separate commit histories.
None of this requires abandoning per-team GitOps ownership. It requires accepting that GitOps solved the single-team drift problem completely, and left the multi-team arbitration problem entirely unaddressed — because the pattern was never designed to answer a question about more than one authoritative loop at a time.
The GitOps Boundary Mapper maps exactly this — where declared ownership boundaries in your GitOps estate are explicit versus assumed, before a shared-resource conflict surfaces the gap at incident time instead of design time.
Architect's Verdict
GitOps governance did not fail. It won so completely that every team capable of standing up a repo and a reconciler did exactly that, and nobody designed for what happens when four independently correct loops share one cluster.
The real problem most organizations miss is that this isn't a governance failure in the usual sense — nobody's negligent, nobody's unaccountable, nobody skipped a review. Every team can prove ownership of its own slice. The gap is structural: the composite state of the shared domain was never anyone's job to own, because GitOps as a pattern was designed to solve single-loop drift, not multi-loop arbitration.
An architecture with four correctly-owned GitOps loops and no arbitration layer between them isn't more governed than an architecture with none. It's differently ungoverned, and considerably harder to diagnose — because every team you ask will, correctly, tell you they own their part.
Originally published at rack2cloud.com
Top comments (0)