Drafts

<!-- Reviewed 2026-09-08 (no default team; team codes capped at three): the covered code lost one payload field (`isDefault` on `GET /api/teams?mine=true`, which no surface this page describes ever showed), renamed the team-less fallback helper, and had its comments corrected — the fallback itself is now the workspace's OLDEST team rather than its flagged one, which resolves to the same team on every workspace the app has made. New team codes are 2–3 characters; existing longer codes are untouched and keep numbering, because the numbers already issued cite them. Nothing this page states about behaviour changes. --> <!-- Reviewed 2026-09-07 (the PARAGRAPH rule): the covered save seam (`documentOps/settle.ts`) now names whole PARAGRAPHS for the builder — every paragraph in which a process's sentence, or any sentence beside it, changed — and the processes to replace from them, instead of re-checking a changed sentence. What a save does for the reader of this page is unchanged: the index and the processes re-derive from the text (Authoring → Workflows → "Your processes follow your text" is the story). --> <!-- Reviewed 2026-09-02 (saving a document updates its processes and its agent): the covered workspace read now serves the CURRENT text to readers and writers alike — a reader is no longer held to the last published version — and the lifecycle's publish/submit hooks became callers of the save seam (`documentOps/settle.ts`): every save (a pause, leaving the document, a saved version, a submit, a publish) re-derives the document's searchable index and its processes from the text. The "What a save does" section below is that story. --> <!-- Reviewed 2026-08-30 (one state, active): the covered documentLifecycle changed only in comments — its publish-time trigger sync stays, now as the LEGACY body-chip hook rather than the gate that decides whether a workflow runs. Accepting a workflow is what makes it act (store.ts), so nothing this page describes about drafts, review or publishing moved; the workflow story is authoring/workflows.md, rewritten in the same change. --> <!-- Reviewed 2026-08-30 (the workflow leaves the document body): the covered workspace/lifecycle files changed only in workflow-storage wiring — chips retired from the editor surface and the document_workflows store took over behind the same seams. Nothing this page describes moved; the workflow story itself is authoring/workflows.md, rewritten in the same change. --> <!-- Reviewed 2026-08-17 (versions are a COUNT — owner ruling): version labels are plain numbers now (v1, v2, v3); every act mints exactly the next one, and the editorial/material declaration is recorded on the version instead of changing it. Labels this page quotes were updated with that change. --> <!-- Reviewed 2026-08-18 (organization style sheet rev 2): the covered editor plumbing gained a pass-through headingStyles prop so h1–h3 render the org sheet's per-level fonts/sizes. Nothing THIS page documents changed behavior; the sheet itself is documented under Administration → Workspaces and Authoring → The editor. --> <!-- Reviewed 2026-08-17 (organization document style): the covered workspace/settings code gained the org-style cascade — documents render `override ?? organization style ?? app default`, and Settings → General gained a Document style section. Nothing THIS page documents changed behavior; the feature itself is documented under Administration → Workspaces → "The organization's document style" and Authoring → The editor → "The document font". --> <!-- Reviewed 2026-08-14 (approvals completion): documentLifecycle's submit gained an optional typed-submitter parameter (automation cadences; every session flow omits it). Nothing this page documents changed behavior. --> <!-- Reviewed 2026-08-14 (approvals phase 4c — documents join the review routing layer): the covered workspace/review code gained assignment wiring (assignees on the workspace read, an Assign control in the Approval panel, the shared routing verbs). Nothing THIS page documents changed behavior; routing itself is documented under Review → Submit and approve → My approvals. -->

Every document in Alchex has exactly one live draft — the working copy everyone edits between published versions. One kind has none at all: a document whose content is an uploaded file is not written here, so there is nothing for a draft to be a working copy of. Uploading publishes it and replacing the file publishes the next edition; nothing on this page applies to one. See External documents. There is no per-person copy and no check-out: when two people open the same document, they are in the same draft. This includes a control's definition: a control is a document, and its page runs the same single draft with the same rules. Read this before you edit anything you would be unhappy to lose.

Opening one

The draft's text is on screen as soon as the page has it, and it is editable from that same moment — there is nothing to connect to first. You never wait on a blank column to find out what a document says — see Collaboration.

One draft, always open

There is one working draft, and what you can do with it depends only on your role on the document's team.

Editing needs the Writer or Owner role on the document's team. A workspace Owner or Admin counts as team Owner everywhere. A Reader who tries to propose a change is told their role is Reader and that proposing needs Writer or Owner.

Submitting for review pins an exact, immutable copy of the draft — that copy is what the approver reads and what publishes, and nothing typed afterwards can reach it. The draft itself stays open: you, your teammates and the AI can keep editing while the decision is out, and what you write rides the next version. To close a review without a decision, withdraw it (the submitter or any admin can) — the withdrawn review's pinned copy stays in the version history.

The draft and the published version

Once a version has been approved, the draft is not what readers see: readers see the last approved version until a new one publishes, and the document header says so — Active · readers see v7, and that this draft publishes as the next version when approved.

Until that first approval, the draft is what readers see. A document is active from the moment it is created — it is in force at v1, the header reads Active · v1, and there is only one body for anyone to read. Nothing is withheld from your readers pending an approval; what an approval buys is the next version. The practical consequence is worth knowing before you use a new document as a scratchpad: notes-to-self in a brand-new document are visible to everyone who can read it.

This is also why taking something out of a draft is not immediately destructive. On a control, deleting a connector reference is acted on when the document publishes, not while you are typing: that is the moment the attachment the reference introduced is withdrawn. The connector label itself is never collected — a workflow or another team's control may be reading the same source. Nothing the sweep does reaches outside the document's own team.

Because the draft is yours to work in, nothing in it is refused while you write: bracketed notes-to-self like [decide the cadence] sit in a draft as happily as any other text, and saving never argues with you — a half-configured workflow chip included, whatever it names. They are only refused at the moment you publish, which is the point where the document stops being your working copy and becomes something readers are meant to follow. See Publishing.

See Submit and approve for the review path and Publishing for what happens at publish time.

Unsaved work, and what "saved" means

There is no Save button for the body. Opening a document gives you the draft's current content, ready to type into immediately, and each change you make is sent to the server as you write. Everyone else editing the document is working on the same draft and receives your changes the same way.

Because there is no save step, there is also no moment where your work exists only on your screen — except one, and it is worth knowing exactly where it is.

While your connection is down, unsent edits are held by the open page. Keep typing; a Reconnecting… ribbon tells you the connection is gone and that your edits will send when it returns. But they are not written anywhere durable in the meantime, so closing or reloading the tab before the ribbon clears loses them. Leave the document open until it disappears.

The same applies to a draft that says This draft stopped saving — an unusual state where Alchex has decided it cannot safely record further changes. Your text is still on screen and the editor goes read-only; copy anything you have just written, then reload the page. See Collaboration.

That message is deliberately loud, and the reason it exists is worth knowing: Alchex records your typing as changes to named blocks of the document, so a document whose blocks it cannot name is one where it could not tell your new paragraph from a replacement of somebody else's. Rather than guess and risk overwriting a colleague, it stops and says so. Every document reaches the editor already named, whether it was written here, uploaded, generated by the assistant, or restored from an old version — so if you meet this banner, reloading the page is the right move and your text is not lost. The one sequence that used to defeat that promise — a version restored onto a document before it had ever been opened here, which its first background save then stored twice over — is closed: a restored document saves and reads back as a single copy however long it waited to be opened.

Because your typing is recorded as it happens, the draft can also be wound back to any point in it. You do not have to have saved anything: the history lists each editing session — an unbroken stretch of writing by one person — and any of them can be returned to. See Version history.

Documents written before this

A document that predates the current editing model is converted the first time somebody opens it, in the moment they open it — nothing to run, nothing to wait for, and it happens once. If that conversion cannot complete, the document still opens and is still readable; it is read-only until it succeeds, rather than presenting an editor whose changes would not be recorded.

How a draft is superseded

A draft's content is replaced, not deleted, and only in these ways.

• Approval. An approver approves the copy that was submitted; that exact content publishes as the new version — even if the draft has moved on since, because the decision is pinned to the submitted copy, never to the live draft. Whoever submitted the review is told it published, and at which version, so you do not have to keep checking a draft you handed over.
• Direct publish — a server verb at the Owner rung. The publish verb can issue the open draft without a review round; the app offers no button for it, so in practice a draft reaches readers through a review decided on My Approvals. The verb is refused while any review is pending — the caller's own submission included; withdraw it first. The action is recorded as a direct publish in the document's activity (see Publishing).
• Restoring an old version. Restoring from version history replaces the draft's current content with that version's, and everyone editing sees the replacement immediately. Published versions are untouched, and publishing still goes through review.

Every one of these is recorded in Governance → a document → Activity. See Versions and Activity and archive.

Changes the assistant made are marked in the draft

When an edit reaches the draft because you approved an assistant proposal — whether as a plain edit or as part of a one-approval publish — each section it touched is left with a margin comment from Alchex explaining the change. The next person to open the draft can see which passages were not written by a colleague, and why they say what they say, without going looking for the conversation. See Comments.

<!-- Reviewed 2026-08-25 (workflow manager P1 — schema + repo): documentLifecycle's publish now also extracts workflow trigger chips into the workflow_triggers index (same write-through as citations, best-effort savepoint). No editor can place such a chip yet, so no published document contains one and publish behaves exactly as documented. Nothing this page documents changed. --> <!-- Reviewed 2026-08-26 (workflow manager P2 — the executor): the covered record routes gained post-commit workflow dispatch hooks (record created / submitted → runs; decisions → resume). No editor can place a workflow chip yet, so no published document declares a trigger and every documented flow behaves exactly as before. Nothing this page documents changed. -->

What a save does

A draft is saved continuously as you type. When your edits settle — you pause for half a minute, or leave the document — Alchex folds them into a checkpoint and, from that checkpoint, re-derives everything that follows from the text: the document's searchable index (what the assistant finds when it searches your documents), and the processes built from it (see Workflows in documents → Your processes follow your text). There is no publish step between you and the agent: what the document says is what the agent, the runs and every reader read. Version history stays as the safety net and the audit citation — every run names the exact revision it read — but a version is a record, never a gate.

If a tab closes mid-sentence, nothing is lost: the edits are already in the log, and a background clock settles any document whose edits have gone quiet within a few minutes.