StateAnchor runs StateAnchor

As of today, StateAnchor gates changes to its own configuration. The repo stateanchor-hq/StateAnchor has a stateanchor.yaml at its root, and every push to main runs through the same gate engine we ship to users. If our own config drifts, we find out the same way you do: a blocked merge and a gate report.

This is not a demo environment. It is the production pipeline. The same Supabase tables, the same gate scoring, the same provenance chain. We wanted to know what it felt like to live with StateAnchor on a codebase we push to every day, so we pointed it at the one we know best.

What we gate

The stateanchor.yaml in our repo defines four gate rules:

• Schema drift. Any change to an endpoint signature -- added fields, removed fields, type changes -- must pass the diff engine. Breaking changes are blocked by default.
• SDK regeneration. When the spec changes, SDKs are regenerated and diffed against the previous version. If the generated output diverges from the committed artifact, the gate fails.
• Config validity. The YAML itself is parsed and validated before anything else runs. Malformed config blocks the pipeline immediately.
• Provenance continuity. Every generated artifact must trace back to exactly one commit SHA. If the chain breaks, the gate blocks.

What we caught

The first real catch came on commit 8c52a21. A routine update to our API route touched a response shape that stateanchor.yaml considered stable. The gate engine classified it as ERR lane -- an endpoint removal that always blocks regardless of threshold.

The fix took about ten minutes. We updated the spec, re-ran the pipeline, confirmed the SDKs regenerated cleanly, and merged. Without the gate, that breaking change would have shipped silently. We would have found out when a consumer reported it -- or when we didn't.

That's the scenario StateAnchor exists to prevent. Seeing it happen on our own codebase made the value concrete in a way that unit tests never do.

What the audit trail looks like

Every gate run produces a provenance record. Here is the record from the catch on commit 8c52a21:

{
  "repo":        "stateanchor-hq/StateAnchor",
  "commit":      "8c52a21",
  "branch":      "main",
  "gate_lane":   "ERR",
  "gate_action": "block",
  "gate_reason": "ERR -- 1 breaking change(s) detected, sync blocked",
  "artifacts": [
    {
      "type":       "sdk",
      "language":   "typescript",
      "sha256":     "a3f9c2d1e8f4..."
    }
  ],
  "timestamp":   "2026-03-27T14:32:07Z"
}

The gate engine, diff algorithm, and scoring are pure functions of the input spec -- deterministic and reproducible. Claude assists in SDK generation, but the generated output is structurally validated and SHA-256 hashed before the gate evaluates it. The gate never evaluates LLM output directly -- only the committed artifact hash.

What we learned

• Gate thresholds need tuning per repo. Our initial threshold was too aggressive for a repo that changes daily. We loosened it slightly for non-breaking additive changes and kept it strict for removals and type mutations.
• Config validation catches more than you expect. Two of our early gate failures were YAML syntax issues, not semantic drift. The parser is unforgiving, and that's the point.
• Provenance tracing changes your commit habits. When every artifact traces to a commit, you stop making speculative pushes. You think about what the gate will see before you push. That's a behavioral change we didn't anticipate.
• The audit trail is more useful than the gate. Blocking bad changes is valuable. But the provenance record -- being able to say “this SDK was generated from this commit with this config hash” -- turned out to be the thing we reference most.

Why this matters

Dogfooding is a trust signal, but it's also an engineering practice. We are now the most demanding user of our own gate engine. Every edge case we hit, we hit first. Every config quirk, every threshold debate, every provenance gap -- we experience it before anyone else does.

If StateAnchor can't gate its own repo reliably, it has no business gating yours. That's the bar we hold ourselves to, and as of today, we clear it.

The output above -- commit 8c52a21 -- is real. This is the actual catch from our production pipeline, not a reconstruction.

Current state (April 2026)

The pipeline described above continues running. As of April 2026, the repo has 3,596 tests across 90+ test files covering unit, integration, property-based, and end-to-end scenarios. The gate engine now classifies 33 change kinds (16 ERR, 9 WARN, 8 INFO). Subscription billing is live. The gate ships to self-serve users.

On a 34-scenario ground-truth corpus, StateAnchor's detection accuracy is 100% -- compared to 65% for api-smart-diff. That benchmark came directly out of the pressure of running this pipeline on a codebase that changes every day.