Skip to main content
ACI preserves content as a versioned history. Teams make changes on branches, land approved work on main, and promote selected paths to live. Each transition is deliberate, so saving or approving content does not change the live site by itself.

​
The content states

​
Work safely on a branch

Create a branch for a focused unit of work, such as a campaign, a component migration, or a set of SEO updates. Every successful save advances that branch to a new immutable content version. A branch gives you:
  • A reviewable set of changes
  • A stable content version for validation and preview
  • Isolation from other in-progress work
  • A place to coordinate related content and code changes
Branches can progress independently. One team can prepare a campaign while another corrects a product page, without either branch changing main or live.

​
Keep a branch current

If main changes while a branch is in progress, rebase the branch before landing it. ACI applies the branch’s work over the current approved state. When both sides changed the same content, ACI reports a conflict for review. Resolve the intended value, validate again, and continue. ACI does not choose one edit silently.

​
Link content to the right code

Content and frontend code have separate version histories. A branch can link to the code build that contains the contracts and components it should use. This is useful when a change introduces a new component or updates required props:
  1. Link the content branch to the new code build.
  2. Update affected content on the branch.
  3. Validate and preview that exact combination.
  4. Land the approved content and coordinate its promotion with the compatible code.
Updating the code link changes the branch’s rendering context; it does not rewrite the content versions on the branch.

​
Land approved work

Landing applies a branch’s approved changes to main. Before landing, resolve any conflicts and validate the combined content and code state. Landing is an approval step, not a publication step. The result becomes available for promotion, while the site continues to serve its current active release.

​
Promote selected paths

Promotion moves selected content paths from main to live. Path-level promotion lets a team release one approved change without automatically including every other approved change. Before confirming a promotion, review its dry run and any related-path warnings. Shared fragments, referenced content, or coordinated edits may require multiple paths to move together. Use drift to identify content that is approved on main but has not yet been promoted to live.

​
Restore content or a release

ACI supports two recovery scopes: Keeping these operations separate avoids replacing an entire site release when only one path needs correction.

​
Content history and storage

ACI records accepted changes in an immutable content history. In Gradial-managed deployments, a tenant-isolated operational ledger coordinates concurrent work and exports that history in ACI’s portable object-storage format. In direct mode, the object-storage ledger is the active repository and uses a single-writer workflow. Storage ownership, region, retention, access, backup, and encryption depend on your deployment configuration. See Data Ownership and Portability for the operational model.
Next: Content Compilation →