EmDash's editor steps aside.
EmDash's own editor will not save a page built in the Composer, and turns its refusal into a link: "This page is built in the Composer. Open it there."
BUILD · THE COMPOSER · HOW IT WORKS
One canvas. One path. One undo.
The Composer edits the page your server renders, through the same governed path the copilot uses. This page describes how, step by step, as of October 2026.
The mechanics
The canvas
- The canvas is the real page: the server route that serves your visitors renders it, inside a frame opened through a signed preview address for the draft.
- The frame runs none of the page's own scripts, so nothing on the page fires while you work on it.
- "Preview width" renders the page at Desktop 1280, Tablet 768 or Mobile 390, and "Refresh render" redraws it from the server.
Two planes
- Inside the frame there are only still outlines. Every control lives in the admin around the frame and follows the page's geometry.
- Each section carries a lasting address on the page, matched to its catalog name on the server, so a click reaches the section you meant, even on a page whose blocks were renumbered by another editor.
- A move is shown at once, then checked against the order the server holds.
- Rich text is edited by an editor mounted on the page's own text element, so what you type carries the page's own styles.
From gesture to operation
- Each gesture becomes a typed operation. The Composer sends it to its operations route, which plans it and applies it with the same tools the copilot uses.
- Receipts and undo grants land in the same records as the chat, so "Changes this session" and the copilot's "Activity" tell one story.
The draft layer
- Operations apply to a draft-layer view of the page. The live page's stored content stays byte-identical until you publish.
- The top bar says which state you are in: "Draft", "Published", or "Published · changes pending".
Stale edits
- Each write carries the revision it read. If the page has changed since, the write is refused, and nothing newer is overwritten.
- If the copilot changes the page while you have it open, the canvas tells you: "Your copilot changed this page".
Publishing
- Publishing is the copilot's own publish tool, gated by approval. Your approval is a one-time grant, held on the server.
- The card reads "Publish this page?" the first time and "Publish these changes?" after that. While a section still needs your facts, no card opens: the Composer names the section, and nothing goes live. Sample words are named in the Composer and on the card.
- Undoing a first publish takes the page offline. Undoing a later publish puts the earlier version back.
The mechanics
The gates
Every field is checked.
A write to a Composer page through EmDash's content routes is checked field by field, and a wrong value is refused with the section and the field named.
One rule on every door that publishes.
The copilot's publish, the Composer's, EmDash's own Publish button and migration's bulk publish all apply the same integrity rule. A page refused on one door is refused on all of them. The rule adds no refusal of its own: it is the copilot's publishing check, applied to every door.
No raw HTML.
The "Embed / preserved HTML" section exists to carry migrated content, and no one can insert it. Embeds come from a closed list of ten providers, in a sandbox, and only a person can place one.
Editing for
- "Editing for" re-renders the same frame for the version you choose. There is no second editor and no second tool behind it.
- A variation is the page's own version for one arm of one experiment. Editing it writes that arm's version; the page everyone else sees stays untouched. "Promote" copies the arm into the page's draft, with the publish card still ahead.
- An arm reaches visitors only through its experiment's own "Activate", and the banner always names the variation and the experiment you are editing. An edit to a live experiment's version waits for your approval too.
- An audience is painted, never written to the base page. A move becomes that audience's own order of sections, and a field edit becomes its own version of the section. Both are saved as drafts through Personalization's own draft step, until someone activates them.
Themes on every request
- The active theme is resolved on every request and written into the page as its CSS variables. A visitor can switch the page between the theme's modes with ?themePreset=.
- The visitor's light or dark choice is remembered from page to page, with the system preference and no flash. Coming soon.
What keeps it safe
A page that cannot act.
The frame runs none of the page's scripts.
A live page that does not move.
It stays byte-identical until you publish.
No lost work.
A stale edit is refused, not applied over newer work.
One record.
Your changes and the copilot's land in the same history, with one undo.
One publishing rule.
Four doors, one integrity check, and a card before the copilot or the Composer publishes.
Nothing pasted.
Typed fields, typed styling, no raw HTML, and embeds only from a closed list.
Common questions
Does the canvas run my page's scripts?
No. The frame runs none of them, so nothing fires while you edit.
Can I edit a live page without visitors seeing half-done work?
Yes. Every edit goes to a draft layer, and the live page stays exactly as it is until you publish. An edit to a live experiment's version waits for your approval too.
What happens if two of us edit at once?
Each write carries the version it read. The second writer's stale edit is refused, and nothing is overwritten.
Does EmDash's own Publish button skip the checks?
No. It applies the same integrity rule as the Composer and the copilot.
Is the Composer a separate application?
No. It is a room inside your site's admin, part of the Praxis plugin that runs within EmDash's own admin.
Where do my undo and the copilot's undo live?
In one place. Both write their receipts and undo grants to the same records.