Most API tooling assumes one repository, one specification. But your architecture doesn't work that way. In our previous article , we explored how Barbacane eliminates configuration drift by compiling your OpenAPI spec directly into the gateway's runtime artifact. One spec, one .bca file, zero drift. But what happens when your architecture has more than one spec? The Multi-Spec Reality In a typical microservices setup, your API surface isn't described by a single file. Whether you're working contract-first or generating specs from code, you end up with multiple specifications: A User Service with its own openapi.yaml An Order Service with its own openapi.yaml An Inventory Service exposing both REST endpoints and event consumers, described across OpenAPI and AsyncAPI files Event schemas scattered across repos Each file is validated in isolation, deployed independently, and versioned on its own timeline. Single-spec tools can't see across these boundaries, so cross-service mismatches only surface at runtime.…