Source: https://docs.amadalis.ai/developers/platform/

# EmDash and what Praxis adds

Use this guide to see what Praxis adds to [EmDash](https://docs.amadalis.ai/reference/glossary/#emdash) and where each task belongs. The map below distinguishes EmDash’s content screens from the [Composer](https://docs.amadalis.ai/reference/glossary/#composer), copilot and experience workspaces.

Checked against the product’s code on 7 November 2026.

Praxis builds on EmDash. EmDash supplies content collections, media, users, plugins and the core admin. Praxis adds the Composer, the governed copilot and the tools for measuring, targeting and selling through a site.

## The layers

| Layer | What it does |
| --- | --- |
| EmDash | Stores and manages content, media records, collections, menus and the core admin screens. |
| Praxis authoring | Builds pages from typed [sections](https://docs.amadalis.ai/reference/glossary/#section), elements and theme [tokens](https://docs.amadalis.ai/reference/glossary/#token). Composer edits are saved to a draft before publication. |
| Praxis experience tools | Add analytics, event capture, goals, experiments, audiences, personalization, forms, commerce and visitor data controls. |
| Hosting | Routes the site’s hostname to its database and renders its pages. Cloudflare provides the request routing and hosted runtime. |
| Account | Holds sites, team memberships, domains, account security and billing controls. **Open admin →** enters a site at the member’s role. |

EmDash’s own screens include the content lists and editors for pages and posts, the media library, menus, users and settings. **Composer**, **Insights**, **Optimization** and **Privacy & Data** are Praxis workspaces.

The EmDash core is a pinned dependency. Two EmDash admin interface packages carry the structured field change proposed to EmDash upstream. The published EmDash core is unchanged.

## Content and delivery

A Composer page contains typed sections and fields. Its theme supplies design tokens. A page edit changes its draft. Publishing is separate from editing. A person’s own **Publish** click in EmDash’s editor publishes at once, as their explicit act. Anything the copilot publishes always pauses for the approval card.

On a visitor request, the server resolves the applicable consent and identity. It can then select an experiment version, reorder or replace sections for an [audience](https://docs.amadalis.ai/reference/glossary/#audience) and rank recommendations. The content access gate removes sections the reader is not entitled to read.

A failure in the experience selection can fall back to the page’s ordinary content. Identity and content access have their own checks. A fallback is not permission to expose restricted content.

An anonymous view of a published page can be served from a shared edge copy. After a publish, visitors see the change within the hour, usually much sooner. While the site’s server is down, visitors may see the previous version of a page for up to a day. Unrelated cookies no longer bypass it. Visitor identity, consent choices and Global Privacy Control can use separate shared copies; an identity holder receives one only when it cannot vary with that visitor’s identity. Sign-in, cart and other cookies that change the page still bypass it. Active experiments and targeted responses are not shared.

## Where to connect your code

Before choosing a content API, read [Boundaries to plan around](https://docs.amadalis.ai/developers/platform/#boundaries-to-plan-around) below. The browser helper and public reading surfaces do not grant content-write access.

| Need | Start here |
| --- | --- |
| React to a click, submit, hover, visible element or scroll threshold | [Page scripts and events](https://docs.amadalis.ai/developers/page-scripts-and-events/) |
| Record a custom interaction | [Tracking events](https://docs.amadalis.ai/developers/tracking-events/) |
| Add a tag with consent for a specific purpose and CSP permissions | **Privacy & Data → Consent → Head & CSP** |
| Read public content from a tool or agent | [The public site for machines](https://docs.amadalis.ai/developers/machine-readable-site/) |
| Understand what the copilot may change | [Governed tools](https://docs.amadalis.ai/developers/governed-tools/) |
| Take visitor data to another system | **Privacy & Data → Exports** and [Privacy and consent](https://docs.amadalis.ai/trust/privacy-and-consent/) |

## Boundaries to plan around

A browser event helper is not a privileged content API. Personal API tokens are read only on Praxis sites. EmDash’s MCP endpoint is disabled, and the public MCP file is a resource descriptor. Reads with a personal API token must also pass the team’s [API token checks](https://docs.amadalis.ai/account/site-access-and-settings/#personal-api-tokens).

The copilot plugin’s `catalog` and `catalog/validate` routes require `POST`. A token that passes its scope and team checks receives **405** for `GET` or `HEAD`, and its `POST` is refused by the token write restriction. Use the admin’s catalogue screens to read them.

Do not plan an external agent integration around the copilot’s internal endpoints. Use the published reading surfaces and discuss any required write integration with Amadalis.

The normal signup flow creates one production environment. Check [Known limitations](https://docs.amadalis.ai/trust/known-limitations/) before planning staging, SSO or a migration.

For field names, choices and starter settings, use the [product reference](https://docs.amadalis.ai/reference/).