EmDash and what Praxis adds

Use this guide to see what Praxis adds to EmDash and where each task belongs. The map below distinguishes EmDash’s content screens from the 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, elements and theme tokens. 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 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 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
Record a custom interaction	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
Understand what the copilot may change	Governed tools
Take visitor data to another system	Privacy & Data → Exports and 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.

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 before planning staging, SSO or a migration.

For field names, choices and starter settings, use the product reference.