Design guides, style rules, linting, policies, audits, and the difference between capital-G and lowercase-g governance.
They turn compliance from a periodic manual audit scramble into a continuous, observable, automatable property — if you encode the requirements as governance rules and keep the evidence machine-readable.
Triangulate — gateway configs, DNS and certificates, code repositories, cloud accounts, traffic logs, and asking people. No single source is complete, and the ones nobody claims are the ones that matter most.
Put the feedback where they already work, explain the why with every rule, allow exceptions through a real process, and roll out by team or domain rather than all at once.
Hold them to the same obligations as your HTTP APIs — contracts, ownership, discovery, versioning, security, observability — using AsyncAPI and schema registries as the enforcement surface.
Adopt the standard unless you have a specific, articulable reason not to. Every standard you adopt is a set of decisions you do not have to make and tooling you do not have to build.
Vacuum runs Spectral rulesets, is dramatically faster, and adds rule metadata like IDs, categories and how-to-fix text. Start wherever your tooling already is — but the speed is what lets governance run everywhere rat...
Validate the definition, lint it against your rules, diff it for breaking changes, run contract tests against the deployed API, and publish the artifacts. Everything else is optional; those five are not.
Linting runs machine-executable rules against your API definitions. Start with validity, security schemes, descriptions and naming — and remember that a green check is the visible part of governance, not the whole of it.
Capital-G Governance is the formal program — boards, mandates, gates, audits. Lowercase-g governance is the daily practice of teams making consistent decisions. The second is where governance actually happens.
With the landscape and the people, not the rules. Find out what APIs you actually have and who owns them, then write down a handful of things everyone already agrees on and automate those first.
Because they arrive as gates rather than guardrails, with rules nobody can trace to a reason, no feedback path, and no investment in the literacy that would let teams participate rather than comply.
