Reusable components versus inline schemas for multi-team API governance

When multiple teams own different endpoints but share a common domain model, the decision between centralizing schemas in components.schemas and defining them inline affects both consistency and review velocity. Centralized definitions prevent drift across endpoints and tend to produce cleaner generated client models, yet they introduce a resolution step that can slow down CI validation and make pull-request diffs harder to follow. Inline schemas keep each operation self-contained and easier to audit in isolation, but they risk duplication and divergent representations of the same concept.

The constraint is a continuous-integration pipeline that validates the full OpenAPI document on every pull request and must complete within a strict time budget, while also ensuring that generated SDKs for three target languages remain consistent. Tooling behavior varies: some generators emit duplicate classes for inline schemas, others ignore them entirely, and validator performance degrades noticeably when the document exceeds a few thousand lines.

Which approach better balances spec maintainability, CI validation latency, and cross-language generator fidelity for a shared domain model owned by multiple teams? Does the answer change if the domain model evolves frequently versus remaining stable for months?