Version history

<!-- Reviewed 2026-09-02 (saving a document updates its processes and its agent): the covered save-a-version route and the op-log lifecycle now hand the checkpoint they write to the save seam, so a saved version also refreshes the document's index and re-matches its processes. Reading, comparing and restoring versions are unchanged. --> <!-- Reviewed 2026-08-25 (the record lock is parked app-wide, RECORD_LOCK_ACTIVE=false): the covered ops lifecycle's restore seam keeps calling the parked lock, which refuses nothing — so "Return to this" works during a pending review, exactly as the going-back section below already says. Nothing this page documents changed. -->

Version history is the record of what this document said and when. Use it to show an auditor the version that was in force on a given date, to see what changed between two versions, or to pull old wording back into the draft.

Open it from the panel buttons in the document's top bar — Version history docks beside the text like every other panel, so reading the history never leaves the page. An uploaded file or an archived document carries no panel buttons; there the ⋯ menu's Version history opens the same panel, docked on the same right edge — no dialog, no overlay, on any kind of record. Anyone who can read the document can read its history; you do not need Writer or Owner to look.

It is one panel, built once, on every kind of record: a document, a register, a risk and an uploaded file all open this exact panel on their right edge, and every one of them reads and writes its versions through one place — so the list, the filter, the Save version door and the Restore behave identically wherever you meet them.

It is also the only door to the document's activity — who commented, who sent it for approval, who published it. That used to be a second panel of its own. It is not, because it was the same story told twice: a version is something that happened to the document, and so is a comment. The ⋯ menu's Activity entry still exists on an uploaded file or an archived document, and it opens this same history.

What ends up in the list

They are one list, newest first, in the order things happened. A version is not lifted above a comment that came after it: the list reads as the document's story, which is the thing you came to read.

This panel is not the document's alone: every record kind opens the same panel — a risk record, a register and an uploaded file all show this exact list, with the same header, the same filter and the same Restore. What you learn here you know everywhere.

The version in force is marked Current and the ones before it read Superseded. That marking follows the published chain, not the list order — so the Current version is usually not the top row, because a saved version or a comment from this morning sits above last month's published version. It is still the one readers see.

Narrowing it to the versions

Above the list is one control that reads All. Press it and it becomes Published versions only: everything that is not a published version — saved versions, uploads, activity — drops out, leaving the formal chain on its own. Press it again to get the whole story back.

This is the reading to give an auditor. Everything else in the list is what the document did; a published version is what somebody stood behind.

Alchex also captures the live draft automatically every few minutes while someone has the document open. Those captures are not listed — they exist so the document can still be read if live editing is briefly unavailable. The list shows published versions, the entries a person deliberately created, and what happened to the document, however long it has been open.

Going back to a moment nobody saved

A document records every change made to it, as it is made. So its history is not limited to the points somebody thought to keep: the list also holds each editing session — an unbroken stretch of writing by one person — and you can return the document to how it stood at the end of any of them.

Sessions are grouped the way you would describe them yourself. Consecutive writing by the same person, with no long pause, reads as one entry rather than one line per keystroke-batch. Each entry names the sections the writing landed in — read from the document's own headings, so Edited 1. Purpose and 2. Scope points at the places you can go look — and breaks its work into kinds: rewordings, additions, removals, moves, rewrites and style changes, in place of a flat change count. A session whose blocks have since been removed, or a document without headings, falls back to Edited the content with the plain count. Two people writing in the same minute always read as two entries, never merged, so nobody's words appear under somebody else's name. Work by the assistant is likewise kept separate from work by a person.

To use one, choose Return to this on the entry. Before anything happens, the dialog shows what going back changes: the picked moment compared against the current document, in the same reading the version compare uses — later work appears as insertions (that is what a restore steps over), and text the moment had that the document has since lost appears as deletions (that is what comes back). The comparison is an aid, not a gate — if it cannot load, the restore still works, because going back never deletes anything. Confirming returns the draft to how it stood at the end of that session. You need Writer or Owner, the same as any other edit.

Before it happens, Alchex tells you how much later work you are stepping over — replacing 12 later changes — counted across every session after the one you picked. Returning to the most recent session says nothing about a count, because there is nothing after it to replace.

Nothing is deleted by going back. Every later session stays exactly where it was in the list, so if you change your mind you simply choose Return to this on one of them and come forward again. Going back is a move you can undo by making the same move in the other direction — it is not a door that locks behind you.

Returning to a moment does not publish anything. It changes the draft only; readers keep seeing the version in force until you publish a new one. It is also allowed while a review is open, because a reviewer decides on the exact content their approval holds, and the draft cannot reach it.

A record whose content lives somewhere else — a control agent, which holds instructions rather than document text — has nothing to list either, and shows no sessions rather than an empty one.

Records read the same way. A risk record's stretch of editing is a session too — Dana edited the description, with Return to this — and its numbered versions are only the moments somebody stood behind: a save by name, a restore, a review's pin. Returning a record to a session's state records a new version in your name, so on every kind of record going back is a recorded move forward, never an erasure. This holds for records edited long ago as well: the versions their ordinary edits once auto-numbered read as part of the activity now, not as versions, so an old record's chain shows the same thing a new one's does — what somebody stood behind.

Older documents created before Alchex began recording changes this way have no sessions to list. Their history still shows the published versions, saved versions and activity described above.

Saving a version by hand

Choose Save a version… at the top of the panel — a note box appears on demand; add an optional note about why you are saving and press the confirm, which names the version it will create: Save v4. This captures exactly what the draft says right now, including anything a colleague typed a second ago, and adds it to the list under that number.

A save counts like a publish. Saved and published versions number up one chain per document — save v1, save v2, publish v3 — so a version's number always tells you where it stands in the document's story, whoever created it and however. The note is yours to explain the save (wording settled with legal) and is trimmed to 280 characters; the version's name is minted for you, never typed.

The note rule is one rule, on every kind of record. A note is always optional — the save itself is the record, the sentence is your explanation of it — and always trimmed to the same 280 characters, on a document, a risk and a register alike. A save without a note simply reads Version saved. The refusals work the same way everywhere too: asking to restore a version that does not exist, or one that is already what the record says, gets the same answer whichever kind of record you are on.

You need Writer or Owner on the team; Readers do not see the control. If the document has no content yet, the save is refused.

Saving a version does not publish anything and does not change what readers see.

Saving a version is a workspace action: the panel is the only place it happens. The assistant will point you at it if you ask, but it does not take the copy for you — so the state a saved version captures is always the one you were looking at when you chose it.

A version's content never changes

What a version holds is fixed the moment it is created. Alchex stores the exact content at that point, and the database refuses any later edit to it — not as a matter of convention, but as a rule the storage layer enforces on every path. Risk and register versions are kept by the platform's one version store, so this refusal is the same database rule for both — not two implementations that happen to agree.

Two things follow. Comparing two versions compares what was really there at each point, not a later reconstruction. And a version someone approved still holds precisely the content they approved, however long ago that was.

To correct something in a published version, publish a new one. The earlier version stays in the list beside it.

Retention

Published versions are kept permanently.

Saved versions are also kept — one you created is yours until you say otherwise. It is not removed on a schedule. Uploaded-file entries are kept the same way: an upload is something a person did deliberately, so it stays in the list and stays downloadable.

Automatic captures are kept for about seven days, then removed as the document is edited. Those are the every-few-minutes captures described above; they are session undo, not versions, and they never appear in this list.

The line between the two is what an entry is, not how old it is: anything a person created — a published version, a saved version, an upload — is kept, and only the automatic captures expire. Nothing you did by hand is ever removed on a schedule.

A saved version is still not the version in force: it holds a number in the same chain, but readers keep seeing the published version until you publish. If a state of the document needs to be the one readers see, publish it.

Comparing two versions

Tick the compare mark on one entry, then on a second. The compare bar appears, naming both sides; open it to see a structural diff of the two, oldest first. Each row also shows the size of the change as added, removed and modified blocks, so you can see at a glance how big a version step was.

Selecting a single entry compares it against the live document — that view is also where you read an old version's content on its own.

Restoring an old version

Select the version, then choose Restore this version from its compare view. Confirm, and that version's content replaces the content of the current draft. Anyone editing the document at that moment sees the change immediately. (Comparing two old versions side by side offers no restore — a two-sided reading has no single "this version"; select the one you want on its own.)

Restoring is not a rewrite of history. Specifically:

• Published versions are untouched. Restore only writes to the draft. Nothing in the app can edit or delete a published version, so the record of what was in force stays intact.

• The history list does not change. The old entries stay exactly where they were, and the restore appears in the activity log as new work.

• Readers see nothing yet. The restored content is a draft like any other. It reaches readers only when it publishes — through a review decided on My Approvals, or the server's direct-publish verb — see Publishing.

• A pending review blocks a restore. A restore rewrites the draft wholesale, and a record under review is locked like it is for every other edit. Decide or withdraw the review first.

• Restoring overwrites the draft's current content. Anything in the draft that you wanted to keep should be saved as a version first.

• Work typed while the dialog was open is replaced too, and Alchex says how much. Restoring declares the draft to be that version, so anything anyone typed between opening the compare view and confirming goes with it. When that happens the confirmation tells you how many rounds of edits were replaced, rather than letting a colleague's paragraph disappear quietly.

• The restored draft is immediately editable. A restored version arrives as an ordinary draft: click into it and type. This is worth stating because it was briefly not true — a restore could hand back a document the editor could display but not record edits into, so the next keystroke raised This draft stopped saving on a document nobody had touched. If you ever see that banner right after a restore, reload the page; the text on screen is intact either way. A second way this could happen has been closed as well: restoring a version onto a document that had never been opened in the editor could, on its first background save after it was opened, store the content twice over — and from then on every keystroke raised the banner. A restored document now opens, saves and reads back as one copy of itself, however long it sat between the restore and the first edit.

You need Writer or Owner to restore. An external (uploaded-file) document has no text draft to restore into, so its restore works differently — it republishes an earlier file as a new version, from its own history panel; see Uploaded-file documents below.

Uploaded-file documents

A document whose content is an uploaded file has a history of files, not of edited text — so its panel shows what a file record actually holds: every published version and every upload behind them, each with the note the uploader gave and a Download that fetches that exact file. Downloads are fetched fresh each time you click, so a link is never stale — and because the link is short-lived, one left sitting on screen cannot be used later by anybody who happens across it.

There is no compare and no Save a version there — those work on the text of a document, and an uploaded file has none to work on. Restore is offered, on every superseded published version: choose it and that version's file becomes the one in force again, as a new whole-step version (v5 holding the file v2 held). Nothing is re-uploaded — the file was kept all along — and nothing rewinds: the history keeps every entry, and the swap is recorded with both fingerprints. Restoring needs the same Author rights as replacing the file, and the version in force offers no Restore — there is nothing to return to. Every earlier file stays downloadable regardless. See External documents.

Archived documents

An archived document keeps its full history and stays readable: you can open any version and compare any two. Save a version and Restore are withheld, because an archived document has no working draft to write into. Restore the document first — the ⋯ menu offers it — and both come back. See Activity and archive.

Related

• Publishing — how a version becomes the one readers see.
• Submit and approve — the review that decides a fixed copy of the draft.
• Activity and archive — the full event log for a document.

<!-- Reviewed 2026-08-28 (fs_to_pg_205, the storage-merge close-out): the covered code's comments were refreshed to name the spine instead of the retired sheet_checkpoints table; behavior is unchanged. Nothing this page documents changed. -->