Content compilation is the release safety gate in ACI. It checks a specific content version against a specific code build, resolves the site into known routes, and prepares the artifacts that delivery will use. The same compiler supports local development, branch review, and release publishing. A branch preview can help you review the result, but content must still compile successfully before it can be released.

​
Compiler inputs

ACI compiles two versioned inputs together:

Content state

Pages, fragments, site configuration, asset references, and overlays from a branch or the live content state.

Frontend build

Component and layout contracts, their registries, and the rendering implementation from the linked code build.
Pairing these inputs makes compatibility testable. A valid page is not just valid JSON; its components and layout must match what the selected frontend build accepts.

​
What compilation checks

1

Validate document structure

ACI checks each document type and its required fields. Page metadata, regions, component blocks, and configuration must use the expected shape.
2

Validate component and layout contracts

Component props, asset slots, layout regions, and slot defaults are checked against the contracts exported by the frontend project.
3

Resolve references

References to fragments, assets, and other content must point to valid targets. A broken or incompatible reference stops compilation.
4

Build routes and dependencies

ACI resolves page paths and records which shared content contributes to each route so the complete release can be prepared consistently.
5

Apply overlays

Locale, audience, and experiment overlays are applied over valid base content. Every resulting experience must satisfy the same frontend contracts.
6

Emit release artifacts

ACI produces one base artifact and the finite set of configured variant artifacts needed for each route.
When compilation fails, diagnostics identify the content path and problem so you can correct the source and run the same check again.
ACI starter projects include npm run content:compile for the local content compilation loop. See the CLI Reference for direct CLI workflows.

​
Base content and variants

Personalization changes which compiled artifact a visitor receives; it does not bypass compilation. If no audience or locale variant applies, delivery uses the base artifact. This fallback is part of the content model and should always be reviewed alongside personalized variants.

​
Static and server-rendered output

ACI uses one content compiler for supported delivery modes. The final artifact shape differs only at the rendering boundary. In the server-rendered mode, the frontend receives the selected page result. Personalization matching and fallback do not move into application code.

​
Changing a contract safely

When a component or layout contract changes:
  1. Link a branch to the updated code build.
  2. Compile existing content against the new contract.
  3. Update each incompatible content path.
  4. Preview representative routes and variants.
  5. Land and promote the compatible content with the intended code build.
  6. Stage and activate the release.
This workflow makes contract changes visible before release and keeps content fixes reviewable with the code that requires them.
Next: Publishing & Releases →