API Evangelist API Evangelist
Guidance
API Learnings
APIs
API Governance
API Solutions
API Discovery
API Building Blocks
API Evangelist LLC

Vacuum Rules

High-performance OpenAPI linting rules via the Vacuum engine

Vacuum is the OpenAPI governance engine that represents the maturation of the API linting category beyond Spectral, and I got genuinely excited about it because it pushes the rules engine forward in exactly the directions it needed to go. Vacuum, created by Dave Shanley of Princess Beef Heavy Industries, is an OpenAPI linter that is Spectral-compatible — it runs existing Spectral rulesets — but is dramatically faster and adds capabilities Spectral lacks. The performance difference matters more than it might sound: when you’re linting large OpenAPI definitions repeatedly, in editors and pipelines and across whole portfolios, speed determines whether governance can run everywhere it needs to or only in batch jobs. Vacuum made governance fast enough to be ambient. And beyond raw speed, Vacuum extended the rules themselves in ways that make governance more useful, more teachable, and less cognitively overwhelming. Vacuum rules are, in my view, what API governance rules should grow into.

The Spectral compatibility is the strategic genius of Vacuum, and it’s why I could embrace it without abandoning everything that came before. Because Vacuum runs Spectral rulesets, adopting it doesn’t mean rewriting all your governance rules — it means running the rules you already have, faster, with more capabilities. This is the right way to advance a tooling category: build on the established standard rather than fragmenting it. Spectral defined the vocabulary of OpenAPI governance rules, and Vacuum honored that vocabulary while improving the engine that runs it. I wrote about Vacuum extending all the Spectral rule properties, which means everything you know about writing Spectral rules carries over. Vacuum isn’t a competitor that splits the ecosystem; it’s an evolution that strengthens it, taking the established Spectral rule format and making it faster and richer. That compatibility is what let me get excited about Vacuum without it being a disruptive bet.

The rule enrichments Vacuum adds — id, category, and howToFix — are where it genuinely advances what a governance rule can do. I wrote in 2025 about Vacuum rules carrying all the Spectral properties plus id, category, and howToFix. The id gives every rule a stable identifier. The category lets you group rules — Documentation, Security, Lifecycle, SDKs, and more — which is more important than it sounds. And the howToFix field is the one I care about most, because it transforms the rule from a complaint into a teaching moment. A Spectral rule tells you something is wrong; a Vacuum rule with a howToFix tells you something is wrong and how to make it right. That difference is the difference between a governance engine that nags and one that teaches. The enrichments make Vacuum rules more useful to the human who has to act on them, which is exactly the direction governance tooling needs to evolve.

The cognitive-load reduction through categorization is a subtle but important contribution, and I wrote about it specifically in 2025. When you run a full ruleset against an OpenAPI definition, you can get a wall of findings that overwhelms the person trying to act on them. Vacuum’s category property — grouping rules into Documentation, Sandboxes, Security, Lifecycle, SDKs, and so on — lets you organize, filter, and prioritize the findings by what they’re actually about. This reduces the cognitive load of governance by letting teams focus on the categories that matter most to them right now rather than drowning in an undifferentiated list. Reducing API governance cognitive load by categorizing Vacuum rules is a real usability advance, because governance that overwhelms people is governance they ignore. The categorization makes a large ruleset manageable, which makes the governance actually usable.

The governance-over-time dimension is where Vacuum’s reporting capabilities shine, and it addresses a real gap. I wrote in 2025 about vacuum-sealed API governance reports over time — using Vacuum’s report command to capture high-fidelity governance data that can be tracked across time, showing progress, trends, and dashboards. This is governance as a measurable, trackable property rather than a one-time check: you can see whether your API quality is improving or degrading, whether a team’s governance posture is getting better, whether a remediation effort is working. The “vacuum-sealed” reports preserve the governance state at points in time so you can compare and track. This turns governance from a pass/fail gate into a continuous measurement, which is exactly what you need to manage API quality across a portfolio over time. The reporting is part of what makes Vacuum a governance platform rather than just a linter.

Where Vacuum fits in the broader governance toolchain is as one of the leading rules engines, alongside Spectral and Redocly, that I’d recommend running in a pipeline. I included Vacuum in my catalog of what API tools you should run in your pipeline, and it’s integrated into the OpenAPI Doctor, which I called what API innovation looks like — pairing Vacuum’s engine with a visual interface and inline guidance. When I evaluated the default Doctor and Vacuum ruleset, I was assessing not just a tool but a vision of where governance rules are heading: fast, categorized, enriched with how-to-fix guidance, trackable over time, and embedded in editors and pipelines where they teach rather than just enforce. Vacuum represents the governance rules engine growing up — taking the foundation Spectral established and pushing it toward something faster, more usable, more teachable, and more measurable. The Spectral compatibility means it builds on rather than fragments the ecosystem; the enrichments mean it advances what rules can do; and the performance means governance can run everywhere it needs to. Vacuum rules are, to my eye, the current state of the art in OpenAPI governance, and a clear illustration of how the rules engine category keeps maturing in the directions that make governance more genuinely useful to the people who have to live within it.

References