I’ve spent this whole series arguing that governance shouldn’t be a single gate you slam into at the end, but something that shows up at every stage of the lifecycle — in the editor while you’re authoring, in the pipeline when you push, and in the review after. So I paid attention when Denis Mattimoe, the software architect who leads the API Governance service in IBM API Connect, reached out to walk me through how his team does it. Because API Connect turns out to be a shipping, commercial example of exactly the shape I’ve been describing: the same Spectral engine I keep telling you to adopt, embedded across three distinct points in the API lifecycle, with the enforcement dialed up or down depending on where you are.
Here’s the shape. First, in the API Designer, an API under construction can be validated against rulesets while it’s being authored — advisory, the friendly face, governance as help rather than as a blocker. Second, at publish time there’s what they call governance enforcement validation: an API or product being published to a gateway must comply with the rulesets you’ve designated, and if it doesn’t, the publish can be halted. That’s the actual gate, the one with teeth, sitting exactly where a gate belongs — at the boundary between “in development” and “live.” And third, there’s Governance Scanning, which re-validates already-published APIs sitting in your catalogs and spaces against your current rulesets. Same linter, same rules, three different postures: help while you write, block at the door, audit after the fact.
That third stage is the one I want to dwell on, because it’s the one almost nobody builds for themselves. When I look at how teams actually run Spectral in their own pipelines, the linting stops the moment an API ships. But rulesets are not static — they tighten over time, a new OWASP check gets added, a naming convention changes — and every API you published last year is now quietly out of compliance with the policy you hold today. Governance Scanning is the answer to that drift: point your current rules at your existing catalog and find out which of your live APIs would no longer pass. That’s not a check you can run in a pull request, because the pull request is long merged. It’s a stage that only exists if someone designs the platform to have it, and it’s a genuinely smart thing to have designed.
The ruleset model underneath is Spectral straight through, which is the part I appreciate most. There are global rulesets — the pre-canned IBM, OWASP, and OAS ones, version-stamped to match their upstream Spectral versions and locked so nobody can quietly edit them — and there are provider-organization rulesets, the custom ones your team writes, imports, and stores. The rules themselves are the same given/then primitives anyone who has written Spectral already knows, just surfaced through a UI, and there’s a real lifecycle around them: a ruleset moves from draft to published to archived, which is governance applied to your governance, the versioned source of truth idea expressed as product features. Tags on your APIs auto-select which rulesets apply, results come back as a scorecard you can export, and every bit of it is drivable from a REST API and a CLI so it drops into CI/CD. None of that is exotic if you’ve been following along — it’s the stack I’ve been describing, assembled and operated for you.
So what do I actually take away from this? Mostly that the thesis holds up when a platform vendor with a lot of enterprise customers bets on it: govern at every stage, escalate enforcement toward the gateway, and don’t forget the APIs that already shipped. But I’d add the note I always add, which is that the durable thing here is Spectral, not the platform — a spectral- ruleset is the same portable artifact whether it’s running inside API Connect’s publish gate or an engineer’s VS Code, and that portability is your insurance against ever being locked to one way of running it. If you’re already on API Connect, use the full lifecycle Denis’s team built; it’s more than most organizations will ever assemble on their own. And if you’re not, look at what they chose to put where — advisory in the editor, blocking at publish, scanning after — because that’s a blueprint you can build against any stack, and the rules will travel with you when they do. My thanks to Denis for the walkthrough.
