Engines

The governance engine is the machinery that makes API governance real rather than aspirational. A governance rule is just a statement of what should be true about an API — but a statement is inert until something executes it. The engine is that something: the runtime tooling that takes a machine-readable rule and evaluates it against a machine-readable API definition, producing a pass, a fail, a warning, or a hint. Without an engine, governance is a wiki page full of good intentions that nobody follows. With an engine, governance becomes an automated, repeatable, enforceable property of how you build APIs. I’ve spent years thinking about these engines, because they are the difference between governance you talk about and governance that actually happens, and the evolution of these engines over the last decade is one of the most consequential developments in the whole API governance story.

The concept crystallized for me in 2018, when I wrote about an OpenAPI-driven API governance rules engine. The insight was that because OpenAPI gives you a machine-readable description of your API, you can write rules that a machine evaluates against that description automatically. This is the foundational move: governance becomes possible to automate precisely because both the rules and the thing being governed are machine-readable. A rules engine reads your OpenAPI definition, applies a set of rules — does every path follow the naming convention, does every operation have a description, does every API declare its security scheme, are error responses defined — and reports the results. That 2018 vision of an engine evaluating rules against definitions is the seed from which the entire modern governance tooling ecosystem grew. The engine is what turns the abstract idea “we should have consistent APIs” into the concrete, automatable check “this API violates rule X on line Y.”

Spectral became the dominant engine, and understanding why is understanding what makes a good governance engine. Spectral is, at its core, a linter for structured data — it takes a ruleset and an OpenAPI or JSON Schema or AsyncAPI document and evaluates the rules against the document, exactly the engine I’d described in 2018. I’ve written extensively about the properties of Spectral governance rules, about the core rule functions Spectral provides — the built-in functions like truthy, pattern, casing, length, enumeration, and the ability to write custom functions for anything the built-ins don’t cover. These functions are the vocabulary of the engine: they’re the primitive operations the engine can perform when evaluating a rule against a definition. Understanding the core functions is understanding what the engine can actually check, and therefore what governance you can actually automate. Spectral won because it was open, embeddable, extensible, and runnable everywhere — in the editor, in the CLI, in the CI/CD pipeline — which meant the same engine could enforce the same rules at every stage of the lifecycle.

The rule-based versus script-based distinction is one of the most important architectural questions about engines, and I wrote about it in 2021. A rule-based engine like Spectral evaluates declarative rules — you describe the condition you want checked, and the engine figures out how to check it. A script-based approach lets you write imperative code that performs arbitrary logic against the definition. Each has its place: rule-based governance is more maintainable, more shareable, more accessible to non-programmers, and covers the large majority of governance needs declaratively. Script-based governance handles the complex, conditional, context-dependent checks that declarative rules can’t express. The best governance practice uses rule-based engines for the bulk of the work and reaches for scripting only when the declarative approach genuinely can’t express what you need. The architecture of your engine — declarative, imperative, or hybrid — shapes what governance is practical to implement and who in your organization can participate in writing it.

Vacuum represents the maturation of the engine as a category, and I got genuinely excited about it. Vacuum is an OpenAPI linting engine that is Spectral-compatible — it runs Spectral rulesets — but is dramatically faster and adds capabilities Spectral lacks. I wrote about vacuum-sealed governance reports over time, and about how Vacuum extends the Spectral rule properties with id, category, and a how-to-fix field. That how-to-fix addition matters enormously, because it’s the difference between an engine that tells you something is wrong and an engine that tells you how to make it right. The engine isn’t just an evaluator anymore; it’s becoming a teacher. Vacuum’s categorization and its richer rule metadata reflect a category that has matured past “does this pass or fail” into “help the human understand and resolve what the engine found.” When I evaluated the default Spectral ruleset against the default Vacuum and Doctor rulesets, I was comparing engines — and the comparison matters because the engine you choose determines the speed, the depth, and the helpfulness of the governance you can run.

The engine ecosystem extends well beyond OpenAPI linting, and I’ve tried to map the full landscape. JSON Schema validation is itself an engine — I wrote about the difference between what JSON Schema and Spectral provide when mapping the API landscape, because schema validation engines and rule linting engines do related but distinct things. Open Policy Agent (OPA) is a general-purpose policy engine that applies to APIs — I documented building APIs.json, OpenAPI, and collections for the OPA API, because OPA represents the policy-as-code engine tradition, evaluating policies against structured inputs at runtime, which is the same fundamental pattern as Spectral but aimed at authorization and runtime policy rather than design-time linting. Redocly has its own rules engine, APImatic has its default rules, and I’ve evaluated each of these as distinct engines with distinct default rulesets. The point of cataloging them is that there is no single engine — I wrote explicitly in 2025 that there is no single approach or tool for API governance, and the engine landscape proves it. Different engines serve different stages, different artifact types, and different governance concerns.

Where the engine runs is as important as what the engine does, and this is the pipeline-and-editor dimension. The same governance engine should run in multiple places: in the editor as you type, giving inline IntelliSense-style hints; in the CLI for local checks; and in the CI/CD pipeline where it gates changes. I wrote about what API tools should run in your pipeline, and about rolling out governance rules by domain or team in CI/CD pipelines, because the engine in the pipeline is where governance gets teeth — it’s where a rule violation can fail a build and block a merge. But the engine in the editor is where governance teaches, catching problems before they’re ever committed. The OpenAPI Doctor, which I called what API innovation looks like in 2025, runs the governance engine right in the authoring experience, diagnosing your OpenAPI as you change it. The engine is the same; running it earlier in the lifecycle changes it from an enforcement mechanism into a guidance mechanism. GitHub as the API lifecycle engine, which I wrote about back in 2016, is the broader substrate — the engine that moves artifacts through the governed lifecycle, with the rules engines running as checks along the way.

The most important thing I want to say about engines, though, is a warning against mistaking the engine for the point. I wrote in 2025 that API governance rules are not the thing — that the rule, and by extension the engine that runs it, is just a representation of what actually matters, which is the human intent, the business reason, the design wisdom behind the rule. An engine that flawlessly evaluates rules nobody understands or agrees with produces compliance, not good APIs. The engine is necessary but not sufficient. Governance is social, as I’ve insisted; it’s about people conducting business, and the engine is the automation layer underneath the human agreement, not a replacement for it. The danger of powerful engines is that they make it easy to enforce a lot of rules very efficiently, which is only good if the rules represent real value. A fast engine running bad rules just produces bad governance faster.

The frontier is the engine merging with AI and moving toward strongly-typed, guardrailed workflows. I wrote in 2025 that developers will listen when governance is injected into the IDE via AI — meaning the engine’s output, surfaced through an AI assistant in the developer’s actual working environment, is far more likely to be heeded than a pipeline failure after the fact. By 2026 I was writing about governance rules as guardrails in a strongly-typed journey, and asking where governance guidance is going — and the answer is that the engine is becoming ambient, woven into the AI-assisted authoring experience so that the guidance arrives at the moment of creation. The engine that started in 2018 as a batch process evaluating an OpenAPI file in a pipeline is becoming a real-time, AI-mediated, always-present guidance layer. But the fundamental architecture is unchanged across the entire arc: a machine-readable rule, evaluated by an engine, against a machine-readable definition. Everything else — the speed, the helpfulness, the placement in the lifecycle, the AI mediation — is refinement of that core pattern. The engine is the part of governance that does the work, and getting the engine right is how you turn governance from a document into a discipline.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Engines

References

Guidance Details

Explore more

Discover APIs