> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gradial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Content Versioning

> How ACI uses branches, immutable versions, and separate approved and published states to keep content changes reviewable.

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

```mermaid theme={null}
flowchart LR
    A["Branch<br/>work in progress"] -->|"land"| B["main<br/>approved"]
    B -->|"promote paths"| C["live<br/>selected for publication"]
    C -->|"compile and activate"| D["Active release<br/>served to visitors"]

    style A fill:#6366f1,color:#fff
    style B fill:#8b5cf6,color:#fff
    style C fill:#a78bfa,color:#fff
    style D fill:#22c55e,color:#fff
```

| State | Purpose | Changes the live site? |
| - | - | - |
| Branch | Isolate, validate, and review work in progress | No |
| `main` | Hold approved content | No |
| `live` | Hold the content selected for the next release | Not until a release is activated |
| Active release | Serve one compiled site version to visitors | Yes |

## 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:

| Need | Action |
| - | - |
| Restore one page or content path | Select or promote the intended earlier content version, then compile and activate a new release |
| Restore the whole site state | Roll back the active release to a previously staged release |

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](/aci/platform/customer-owned-data) for the operational model.

***

*Next: [Content Compilation →](/aci/architecture/pre-compile-pipeline)*


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.