The pipeline is where API governance becomes visible — and for most teams, it turns out, it is also where governance stops. When I finally stopped arguing about whether “just turning on Spectral” counts as governance and went and measured a thousand real public pipelines, the picture was stark: most teams turned the linter on and stopped there, running its factory-default rules and calling the green check governance. The pipeline is the surface where the abstract work of governance leaves a fingerprint you can inspect, which is exactly why it is worth measuring — not because the pipeline is the governance, but because it is the one part of governance you can see from the outside. If the visible, automatable part is thin, the conversations about the invisible part have almost certainly not happened.
So I built a way to score it. The idea is coverage borrowed from a different altitude — instead of asking how much of an OpenAPI your rules look at, ask how much of a pipeline is actually wired to govern. It comes down to a small set of mechanical signals I keep seeing separate the pipelines that govern from the pipelines that perform governance: does it gate on the pull request, before the merge it was supposed to prevent, or does it lint after the fact? Does it run an owned, provenanced ruleset, or the tool’s defaults? Is the ruleset kept somewhere it is owned rather than pasted in and forgotten? Is the tooling pinned on purpose, or floating on @latest so the thing enforcing your rules is itself ungoverned? Is there a security layer at all? Does it actually fail the build, or is the gate toothless? Does it run only when the spec or ruleset changes? And does it emit a report a human — or a security scanner — can actually read? Each is an afternoon of work, and almost no pipeline in the wild has more than a few of them at once.
The honest caveat is the whole point. This kind of rubric measures mechanics — the automatable quarter of governance, the surface a workflow file exposes. It cannot see whether a human wrote those rules on purpose, whether anyone owns them, whether the developer who trips one understands why. Governance is roughly three-quarters people work, and a file census can only ever see the machinery. So a pipeline maturity score is a floor, not a ceiling: it tells you, unambiguously, whether you have even wired up the easy part — and if that part is thin, it is a safe bet the hard part is missing too. Score your pipeline, fix the mechanical gaps because they are cheap, and then do the real work the score can never measure: the owned ruleset with a documented why, the guidance that turns a red build into a teachable moment, the provenance that lets a team argue with a rule instead of routing around it. The pipeline is where you can measure governance. It is not where governance actually lives.
