The Carrier manifest is a machine-readable description of the service shape. It is generated under .carrier/manifest.json. For enterprise architects, this file is one of the most important outputs of the Carrier toolchain.
.carrier/manifest.json
The manifest gives a structured view of what Carrier understood from the project. It can help answer architecture questions such as: which routes does this service expose? which models does this service own? which types appear in API contracts? which policies exist? which constructs changed between releases? which services expose regulated or tenant-scoped data?
Route, Model, and Policy Metadata
Route metadata helps teams understand the service's HTTP surface. Model metadata describes persistent data owned by the service. Policy metadata supports authorization review. Each can feed governance checks across many services. Instead of asking each team what data they store, platform tooling can inspect manifests and build an enterprise inventory.
Using Manifests for Governance Automation
The manifest becomes most powerful when used across services. Enterprise teams can build automated checks: fail CI when a public route lacks authentication, flag model changes that require migration review, detect OpenAPI breaking changes, require security review for policy changes, require data governance review for sensitive models, publish route and ownership metadata to an API catalog, and compare manifests between releases to generate architecture change reports.
The source declares the service. The manifest exposes the structure. Governance tooling turns that structure into repeatable checks.
Part Six
Adoption Strategy
Pilots, reference architecture, pitfalls, and the road ahead
❦