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

# Preview

> How ACI renders a branch with its linked code build for review without changing the active release.

ACI preview gives reviewers a branch-specific view of saved content and its linked frontend code. Opening or refreshing a preview does not promote content, stage a release, or change the live site.

## What a preview represents

A preview combines:

* The current saved version of one content branch
* The code build linked to that branch
* The requested site route
* The base experience or a selected personalization context

That pairing matters when content and code evolve together. A reviewer sees the component contracts and rendering implementation intended for the branch, rather than an unrelated production build.

## Preview a branch

<Steps>
  <Step title="Save the content changes">
    Make sure the branch contains the version you want reviewers to see.
  </Step>

  <Step title="Link the intended code build">
    If the work depends on new or updated components, link the branch to the compatible code build before reviewing it.
  </Step>

  <Step title="Open the branch preview">
    Request the preview through your ACI workflow. ACI returns a branch-addressed preview URL and keeps the requested route in the URL.
  </Step>

  <Step title="Review representative routes">
    Check page content, shared fragments, navigation, responsive behavior, and any relevant base or personalized experiences.
  </Step>

  <Step title="Validate before landing">
    Resolve visual issues and compiler diagnostics before the branch is approved and landed.
  </Step>
</Steps>

A preview URL follows the branch state, so reviewers can refresh after new saved changes. If the linked code build changes, verify the branch again against that new pairing.

## Preview and release are different checks

| Preview answers... | Compilation answers... |
| - | - |
| Does this page look and behave as intended? | Does the content satisfy its contracts and resolve correctly? |
| Does the linked code render the proposed content correctly? | Can every included route and variant be prepared for delivery? |
| Are the base and targeted experiences appropriate? | Are overlay targets, fallbacks, and outputs valid? |

Preview supports review, but it is not a substitute for compilation. A release must pass the compiler even if its preview looked correct.

## Isolation from the live site

Branch previews use a separate delivery path from the active release. They do not update `main`, `live`, or the active release, and they do not require a release activation.

Treat preview URLs as review links and share them according to your organization's access policy. Avoid using a preview URL as a production endpoint.

## Common review cases

<CardGroup cols={2}>
  <Card title="Content-only change" icon="pen">
    Preview updated copy or structure with the branch's current linked code build.
  </Card>

  <Card title="Contract migration" icon="file-contract">
    Link the updated code build, fix incompatible content on the same branch, and review the combined result.
  </Card>

  <Card title="Shared fragment" icon="puzzle-piece">
    Review several routes that reference the changed fragment, not only the page where the edit began.
  </Card>

  <Card title="Personalized experience" icon="users">
    Review the base experience and each intended audience or experiment result before promotion.
  </Card>
</CardGroup>

***

*Next: [Personalization Architecture →](/aci/architecture/personalization)*


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