Skip to main content

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.

​
Publishing & Releases

Agentic Content Infrastructure (ACI) treats publishing as a first-class operation. Every publish is staged, validated, and activated atomically. Every release is immutable. Every rollback is instant.

​
The Two-Step Model

Publishing in ACI is always two steps: stage, then activate. Staging is the heavy lift. ACI takes the compiled payloads from the content compiler, renders them through your code capsule (producing static HTML for SSG pages or compiled JSON for SSR pages), and uploads everything to the CDN alongside your current live site. During staging, nothing changes for your users. The current site continues serving normally. Activation is a single pointer update. The CDN’s routing configuration switches from the old release to the new one. This is atomic: your users see either the old site or the new site, never a mix.

​
Delta Publishing

ACI doesn’t rebuild your entire site on every publish. The content compiler’s dependency graph tells ACI exactly which pages were affected by a change.

Typo Fix

1 page changed, 1 page re-rendered. The other 49,999 pages are untouched.

Footer Update

Shared section changed. ACI re-renders just the footer, not the 500 pages that use it. Pages are assembled at the edge, so shared pieces update independently.

Full Publish

New code capsule with breaking changes. All pages re-rendered, but in parallel. Minutes, not hours.
Fingerprint-based hashing provides a second layer of optimization. Even if a page is “affected” by a change, if the compiled payload hash is identical to the previous release, ACI skips the render entirely. This handles cases where a change is technically in scope but produces no visible difference.

​
Rendering

When ACI renders a page, it hands the compiled payload to your code capsule, the built artifact from your frontend project. The capsule is your actual Astro, Next.js, or SvelteKit code, compiled into a portable, self-contained renderer. ACI supports two rendering modes:
ModeHow it worksWhen to use
SSG (Static Site Generation)Pages rendered to HTML at publish time. Uploaded to CDN as static files.Marketing pages, blog posts, product pages, i.e. content that doesn’t change per-request
SSR (Server-Side Rendering)Compiled JSON payloads deployed to edge functions. HTML generated at request time.Dynamic content, authenticated pages, real-time personalization
Both modes go through the same staging and activation pipeline. Both benefit from the same validation and rollback guarantees.
Rendering runs your code in a sandboxed environment. Your frontend code cannot access other customers’ content, make outbound network calls, or exceed resource limits. Today this is a process-level sandbox. The architecture supports container and microVM isolation for stricter requirements.

​
Edge Composition

ACI does not serve monolithic HTML files. Instead, it breaks each page into independent pieces and assembles them at the edge when a user requests a page. A page is composed from a layout skeleton (the overall HTML structure), the page body (the content unique to that route), and shared sections (navigation, footer, sidebar). Each of these is rendered and stored independently. When a request arrives, a lightweight edge function fetches the pieces in parallel and stitches them together before responding. This is what makes shared content updates so efficient. When the footer changes, ACI re-renders just the footer. The 50,000 page bodies and the layout skeletons are untouched. The edge function picks up the new footer on the next request and assembles it with the existing pieces. No full-site rebuild required.

Independent Updates

Shared sections like navigation and footers update once, not once per page. A site with 50,000 pages and a footer change re-renders 1 artifact, not 50,000.

Fast Assembly

The edge function fetches pieces in parallel and assembles them with simple string substitution. Frequently-requested pieces are cached in memory, making most page loads near-instant.

Personalization at the Edge

The same edge router that assembles pages also handles personalization. ACI compiles multiple variants per page (by audience, locale, or campaign), and the edge function serves the right one based on a cookie or header. No decision service. No runtime latency.

​
Releases as Immutable Artifacts

Every publish creates a release, an immutable artifact that captures the complete state of your site at that moment:
  • The content version hash
  • The code capsule version
  • Every rendered page and its content hash
  • The route table
  • The CDN configuration
Releases are numbered and permanent. They’re never modified or deleted. This means you always have a complete record of what was live at any point in time.

​
Instant Rollback

Because releases are immutable and the CDN serves from a pointer, rollback is trivial: No rebuild. No re-upload. No waiting for a CI/CD pipeline. The previous release is already on the CDN. ACI simply switches the pointer. This changes the risk profile of publishing fundamentally. Going live is no longer a high-stakes operation. If something is wrong, you roll back in seconds and investigate at your leisure.

​
Your Hosting, Not Ours

ACI is not a hosting provider. Your live site runs on infrastructure built for high availability and low latency at global scale (CloudFront, Vercel, or others). ACI orchestrates the build and deploy, then your hosting platform handles serving. For the full picture on how ACI integrates with your hosting platform, see Hosting →.
Next: Preview →