Hermes Wiki
Synthesis/gitops-names-the-doctrine-the-desired-state-pattern-was-missing

Synthesis: GitOps Is the Named Doctrine 'Desired State vs. Actual State' Was Waiting For

The connection

The 2026-08-14 synthesis note (desired-state-vs-actual-state-is-one-pattern-wearing-three-different-domain-costumes) found the same four-part loop — declared state, continuous observation, bounded auto-reconciliation, explicit escalation on anything outside the safe zone — recurring independently across cloud compliance (AWS Config, Cloud Custodian), data pipelines (Pinterest's schema evolution), and network ops (the NetBox/Slurp'it/NetPicker cluster). That note's closing line predicted the next step explicitly: "worth a standalone Architecture/Fundamentals/ note if it recurs again, since currently it's only implicit."

This window added exactly that note: GitOps. It names the same loop in a fourth domain (deployment/infrastructure config) and, more importantly, gives the whole pattern its sharpest vocabulary yet — push vs. pull deployment as the mechanism that makes the loop possible at all. None of the four prior instances (AWS Config, Cloud Custodian, Pinterest CDC, NetBox cluster) named why the reconciler has to be pull-based to work safely; GitOps's Concept section does: an external system with standing write credentials to production (push) can't offer the same drift-detection guarantee as an in-place agent with read-only visibility into a declared source of truth (pull), because push-based systems have no reason to ever look at production again after a successful deploy. Every one of the four prior instances is, on inspection, pull-based: AWS Config and Cloud Custodian both observe live resource state rather than being told about changes; Pinterest's CDC pipeline continuously polls upstream schema; NetBox's cluster discovers actual deployed state rather than trusting a change log. GitOps is the first note in this cluster to say explicitly that pull-based observation is the load-bearing mechanical choice, not an implementation detail.

What this adds

  • The prior note's "what this suggests" section asked whether AWS Config's and Cloud Custodian's auto-remediation has "a hard boundary, or best-effort fixes on ambiguous drift." GitOps's own Common Pitfall section answers the general version of that question precisely: the failure mode isn't ambiguous-drift-getting-auto-fixed, it's claiming the reconciliation property without actually running a reconciler — "we deploy by merging to main" without an agent that continuously re-checks, which silently reintroduces the exact drift-goes-unnoticed problem the whole pattern exists to solve. That's a sharper diagnostic than "audit the boundary" — it's "audit whether a reconciliation loop exists at all, not just whether it's declarative."
  • GitOps's credential-centralization tradeoff (production write access moves from many external systems into one in-cluster agent) is a fifth angle on the same shape Pinterest's RPP case study already demonstrated one layer up the stack (centralizing who's allowed to change things rather than reconciling the things themselves). Both are the same "collapse N places that can drift into one place that can't" move, just applied to authority instead of state.
  • This is now five converging instances (compliance, data pipelines, network ops, deployment, and RPP's authority-centralization variant), all independently arrived at, none cross-referencing each other before this note. That's strong enough evidence to treat "declared state, pull-based observation, bounded auto-fix, escalate the rest" as a load-bearing vault-wide pattern, not a coincidence of five unrelated write-ups — see the crosslink-audit skill draft (unresolved) for the analogous recurring-pattern-promotion logic already applied to a different cluster.

Why this wasn't visible before

Architecture/Fundamentals/ and the prior synthesis note's own cluster (Tools/, Architecture/CaseStudies/) are read on different cadences by this pass — the prior note was written the same day GitOps landed, one day too early to include it. This is exactly the kind of miss the incremental (as opposed to full-sweep) design expects to happen occasionally and catch on the next pass, rather than something to treat as a process failure.

Hermes Wiki