Content Architecture & Specs

A Hybrid Headless backend featuring strictly-typed JSONB layout trees, dynamic content modeling, and sub-10ms route resolution.

System & Delivery Metrics

API Resolution

Sub-10ms via optimized Edge caching

Data Modeling

Zero-downtime dynamic schema generation

Versioning

Granular diffs tracked across every revision

Payload Size

Optimized structured content (no HTML bloat)

1. Hybrid Headless Architecture

Standard Headless CMSs provide raw data but leave the frontend completely in the dark regarding layout. Traditional CMSs spit out bloated, un-cacheable HTML. Aeion uses a Hybrid approach. - The Structured Block Tree: The visual page builder does not save HTML. It serializes the page layout into a strictly typed, structured tree stored directly in the database. - Frontend rendering: Your frontend (e.g., a Next.js app) hits the API and receives the JSON tree, then maps each node's type (e.g. hero, richText, bentoGrid) to your own React components — no dangerous dangerouslySetInnerHTML required. Aeion's own reference web app does this via a BlockRenderer component; the contract is the JSON shape, not a proprietary SDK you have to adopt.

2. Dynamic Content Modeling

Aeion OS does not require developers to write raw SQL migrations when the marketing team needs a new data structure. - Visual Schema Builder: Administrators use the UI to define a new collection (e.g., Job Posting) and drag-and-drop fields (Salary, Department, Location). - Zero-Downtime Compilation: The engine instantly validates the new definition and updates the database layer, instantly exposing a fully-typed REST API for the new content type. - Collection-first, not CMS-first: Because every content type is just a collection, defining one gives you the REST API, the admin table, access-control enforcement, and storage automatically — the same schema-driven path every module in the OS uses. There is no separate CMS data store to keep in sync with the rest of your application.

3. The Block Editor & Revision Model

The visual page builder is a rich block editor (TipTap) with 100+ block types — headings, rich text, images, video, embeds, tables, callouts, columns, code, math, footnotes — each serialized into the structured tree rather than flattened to HTML. Two properties matter for a technical audience: - Variable interpolation: Content can carry tokens like {{customerName}} or {{orderNumber}} that resolve at serve time, so one authored page renders personalized output without a code change. - Automatic revision history: Every edit to every content item is captured as a tracked revision — what changed, who changed it, and when — with one-click rollback to any prior version and a diff between any two. The lifecycle (draft → review → published → archived) supports branching a page for editorial review without touching what's live, then merging only once approved.

Frequently Asked Questions

No. The contract is the JSON shape, not an SDK. Your frontend receives the block tree from the Content API and maps each node's `type` (`hero`, `richText`, `bentoGrid`, …) to your own components. Aeion's reference web app uses a `BlockRenderer` component, but you're free to render the same JSON however your framework prefers — no `dangerouslySetInnerHTML` required.

Define the collection and its fields in the visual schema builder. The engine validates the definition and updates the database layer with zero downtime, then exposes a fully-typed REST API for the new type — the same schema-driven path every module uses.

Every edit is captured as a tracked revision with granular diffs — who changed what, and when. Roll back to any prior version in one click, or diff any two versions. Content moves through a draft → review → published → archived lifecycle, and a page can be branched for review without affecting what's live.

`GET /api/v1/content/resolve?slug=/path` checks the routing table and applies any active 301/302 redirects natively before returning the payload, so retired URLs keep their SEO equity instead of resolving to a dead page.

Translating a document creates a linked translation scoped to the target locale (e.g. `es-ES`) rather than duplicating the page. The API resolver applies locale fallback automatically when a specific translation is missing.

Composes with the rest of the OS

See the Content Engine in Action