> ## 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. # Why Gradial ACI > How ACI helps content and engineering teams move faster without separating speed from governance. Gradial ACI gives content and engineering teams one reliable path from an idea to a live website change. It keeps day-to-day work flexible while making validation, approval, and release explicit. ## Where ACI helps | When your team needs to... | ACI provides... | | - | - | | Change content without coupling every update to a code deployment | Content versions and code builds that can advance independently, then be paired for preview and release | | Let several people or tools work at the same time | Isolated branches with reviewable changes and explicit conflict handling | | Keep content compatible with the design system | Component and layout contracts enforced during validation and compilation | | Separate approval from going live | An approved `main` state, a `live` publication set, and path-level promotion between them | | Review content and code together | Branch previews that use the code build linked to that branch | | Personalize without moving content assembly into the browser | Precompiled base and variant artifacts with request-time selection and a base fallback | | Recover from a bad release | Versioned content history and whole-release rollback | ## Built for shared ownership ACI gives each team a clear responsibility: Create and review content in branches, preview the result, and decide which approved changes should go live. Own frontend code, design-system components, and the contracts that describe valid content. Configure content storage and supported hosting while retaining a consistent release workflow. The contract between content and code is especially important. When a component changes, ACI can validate affected content before the new combination is released. When content changes, developers do not need to rebuild the contract unless its shape has changed. ## Governance without a separate authoring model ACI uses the same content model and validation path for work created through Gradial, project files, or compatible tooling. Teams do not need one set of rules for human edits and another for automated work. Every accepted change belongs to a versioned branch. Reviewers can inspect and preview that branch before landing it. Approved content still does not become public until it is promoted and included in an activated release. ## Designed for content-heavy sites ACI is a strong fit when your organization: * Operates many pages, shared fragments, locales, or audience experiences * Needs coordinated work across content, engineering, and marketing operations * Wants changes to be reviewable before they affect the live site * Values portable, structured content and an independently operable export * Uses Astro or Next.js for its frontend * Needs personalization with a defined default experience and consent-aware behavior ACI does not replace your frontend repository or design system. It gives both a governed content layer and a release process that work with them. *** *Next: [How Gradial ACI Works →](/aci/getting-started/how-aci-works)* This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.