Activity and archive

<!-- Reviewed 2026-09-04 (the Build button — docs/design/build-button/README.md): the covered src/components/policies/PolicyRecords.tsx changed; the list row of a document being BUILT from a marketplace template carries a "Being built · k of n" chip until it is finished (Templates → "Building a document together"); archive, restore and the activity this page describes are unchanged. --> <!-- Reviewed 2026-08-20 (the restore confirm names how much it steps over): the covered document surfaces changed only where returning to an editing session is confirmed — the dialog now counts the later changes it would replace, computed from the moments list the panel already holds. No request was added and no activity row changed. Nothing this page documents changed; the act itself is described on [Versions and history](/docs/review/versions). --> <!-- Reviewed 2026-08-18 (governance-list version fallback): the covered list component changed only in how it derives the Version cell for a record with no stored version — the shared floor instead of a literal. This page documents the Activity feed, archiving and restoring; it names no version label and reads no Version column. Nothing this page documents changed. -->

Two things keep a document defensible after it is written: a record of everything that happened to it, and a way to remove it that does not destroy it. Activity is the first. Archive is the second — the reversible one, which keeps everything. (Delete, the permanent door, works on any record whatever state it is in, and destroys its history with it — see Deleting from the list. Archive is what you want unless you mean that.)

The activity log

On a document, activity is inside Version history — the same list, in the order things happened, with a comment and a published version sitting as peers because both are things that happened to the document. It used to be a panel of its own beside Version history; it is not, because that was one story told in two places. Press Version history in the document's top bar, or — on an external or archived document, which carries no panel buttons — choose Activity or Version history from the ⋯ menu, which both open the same list. Every recorded event is there, newest first, each line naming what happened, who did it, and when.

If you want the events without the versions, there is no filter for that, and deliberately so: the filter above the list goes the other way, narrowing to Published versions only for the audit reading. Everything else in the list — activity included — is what the document did.

Editing appears as sessions, not as one line per act. Because a document records every change as it is made, the list can group an unbroken stretch of writing by one person into a single entry — naming the sections the writing landed in, led by who did it, saying what kinds of work it carried — and offer Return to this on it. Two people writing at the same time always read as two entries, so nobody's work appears under somebody else's name. Work by the assistant names the assistant instead of a person. See Version history.

Anyone who can read the document can read its activity. There is nothing to switch on: the log is written as work happens. A brand-new document reads No activity recorded yet.

What gets recorded

The vocabulary is deliberately plain. The events you will see most:

Under Publishing, Saved a version is the line a hand-saved version leaves — it counts up the same chain as a publish, but readers never felt it. Published a new version is the one readers felt. See Version history.

Two lines name an act that used to hide inside a more general one. Replacing an uploaded file reads Replaced the file rather than Edited the content — the log names the swap, and the edition it landed in sits alongside it. And a review that concluded nothing needed changing reads Reviewed the document, no change needed rather than only Updated the review date: a review that found nothing is a finding, and the trail says so instead of showing a date moving on its own.

Note that views, exports and shares are logged too. The activity trail is not only a change history — it also answers "who has seen this", which is usually the question an auditor asks about a controlled document.

Two behaviours worth knowing:

• Restoring an old version does not rewrite the log. The restore appears as new work; earlier entries stay put. See Version history.
• The on-screen feed shows the 100 most recent events. Older ones are in the export.

Exporting the trail

Activity log (CSV) downloads the document's full history, not the page you can see. Choose it in the document's Download window — the ⋯ menu on any record opens the same one (see Exporting) — or take it zipped together with the document itself. The Activity panel's header used to carry its own export button; it no longer does — and since 2026-08-19 there is no Activity panel either — because taking a copy of a record is one act with one door. The file is unchanged: it is named after the document and has one row per event with these columns:

timestamp, event_type, actor_id, actor_name, version, summary

Anyone who can see the feed can export it. Values are written so that spreadsheet software treats them as text — an event summary can never be interpreted as a formula.

Activity on a compliance record

A compliance record has its own Activity tab — a different feed that fills as that standard's control-agents run, showing verdicts such as verified, gap recorded, needs evidence and audited, attributed to a person or to a scheduled run.

The same feed also logs scope changes — controls removed or restored, clauses excluded or returned to scope, standards added or removed, and documents attached to or detached from clauses — as neutral-dot lines with the actor, and a removal line carries its own Restore. Since run-side visibility landed it carries a third kind too: workflow runs — what your procedures did, with runs waiting on a person and runs that did not finish pinned above the feed. The detail lives in The compliance record; each team's home page shows the same run lines and pinned band scoped to that one team — and there each line also names the process that ran, since one document can hold several. That team feed is the team's run history; there is no separate page for it.

Archiving a document

Archiving is how you retire a document. Open the document and choose Archive document — Retire from use — kept, restorable. It is reversible, so it is allowed to simply succeed: nothing about a document's history has to be weighed first, because the history is not going anywhere.

Archive is one of two removal doors, and they are deliberately different: Archive retires a record and keeps everything; Delete (below, on the Governance list) removes it permanently and takes its history with it. Delete is not restricted to drafts — it works on any record, published or not — so the difference between the two doors is what you keep, not what they will let you touch. Each confirmation states which one you are in.

The confirmation says exactly what happens, and it is worth reading once: the document leaves the working list but stays intact, readable and auditable — every version, every approval and every stored file is preserved.

After archiving:

• The document is read-only and carries a banner: This document is archived — read-only, with the date.
• Lifecycle actions are blocked. You cannot edit, submit for review, or publish an archived document.
• It disappears from the default working list and appears under the Archived status.
• Its own processes stop; other documents' processes may start. An archived document's processes do not run. But archiving is a start for a process on another document whose sentence says so — a document-control procedure that says obsolete versions are withdrawn runs when any document is archived, with the archived document as the record it is about. Restoring a document starts nothing. See Workflows in documents.

How an archived record looks in the list

The Governance list carries a record's status as the coloured dot in front of its name, not as a column: green while it is active, grey once it is archived, red for an external register we could not read. Hovering the dot names the status in words, and screen readers read it out, so the colour is never the only way to tell. Archived rows are also dimmed, and — because archived records are hidden by default — you only meet a grey dot once you have gone looking for one.

The status, the code and the name are read out as three separate things, not run together — so a screen reader announces "Active, LIST-DEN-001, Exception log" rather than fusing them into one word, and copying a row gives you the same three parts. The gap you can see between them is now in the text as well as in the spacing.

Beside the dot sits the record's code, and it is how you tell two archived records with the same name apart. Every kind of record has a code prefix nothing else uses — PLC- a policy, LIST- a register, EXT- an uploaded file — so a code always matches the word in the Type column, and it names exactly one record in the workspace. Search the list by the code when the name is ambiguous. A register that was renumbered — when registers moved from REG- to LIST- — still answers to the code it had before, so an identifier read off an old report finds its record.

You need author rights on the record's team to archive — and on any kind of record, not just a document. See Permissions.

Restoring

Find the document via Filter → Status → Archived. Restore lives in the two places you meet an archived record:

• In the list — the archived row's menu reads Restore where a live row's reads Archive; select several archived rows and the bulk bar restores them together. The menu never offers Archive to a row that has already taken it.
• On the record — it opens read-only behind a banner saying when it was archived, and the banner carries Restore, so the state and the way out of it are the same sentence.

Either way, it returns to normal, editable use, and both the archive and the restore are recorded in its activity log.

One thing to expect on older records: a document archived before August 2026 shows no archive line. Those acts were recorded, but into the workspace-level audit trail rather than the document's own, so its activity log never displayed them. Archives and restores from that date onward appear on the document itself, as this page describes.

Archiving from the list

The Governance list retires records the same way, under the same word. Right-click a row and the action reads Archive; tick several rows and the bulk bar's Actions menu reads Archive, Move to team…, Delete — one short list, every verb for every row.

The confirmation says what it does rather than warning you off: “Access control policy” will be retired from the working list. Everything is kept — every version, approval and file — and Restore on the record brings it back.

Deleting from the list

Beside Archive, a row's menu also offers Delete — the permanent door, for records that never became records: an abandoned import, a duplicate, a test. It works on one row or a whole selection, always behind its own confirmation, and that confirmation says plainly that everything goes for good.

The two are meant to be told apart at a glance. Archive wears a box and reads in ordinary text, because it is reversible. Delete wears a bin and is the only one in red — in this menu red means irreversible, and nothing else is allowed to borrow it.

One menu, whatever the row is

Every record kind offers the same three actions — Move to team, Archive and Delete — whether the row is a document or a register. The list calls them all records and shows them in one table, so they answer one vocabulary. There are no rows that quietly do less than their neighbours.

The acts are recorded the same way too: archiving, restoring or moving a register lands in the register's own history, with who did it and when — the same answerability a document's activity log has always given those verbs.

That was not always true. Move and Delete were once documents-only, which meant selecting a single row of any other kind left you with a menu containing nothing at all. The verbs are uniform now; what differs is not whether you can ask, but what the answer is.

Delete refuses nothing — it only ever redirects you

Delete means delete, on every kind of record. A document or a register goes when you say so, published or not, cited or not. There is no state a record can be in that makes the button lie to you.

There is exactly one thing Delete will not do, and it is not a refusal to destroy anything:

• A control's backing document sends you to the control. That document is not something the control points at — it is the control's contents, so removing it on its own would leave a control that still exists with nothing inside it. Alchex names the button that does the whole job: Delete control in the control's ⋯ menu, which removes the control and its document together.

A published document used to be refused here, and no longer is (2026-08-12). The old message sent you to Archive on the grounds that versions and approvals are a record an auditor may hold. That reasoning still holds — it is simply yours to weigh rather than ours to enforce, and it is the same conclusion already reached for every other kind.

Be clear about what you are choosing: deleting a published document destroys its version history, its approvals and its activity trail permanently. A red reference tells a reader the thing a sentence cited is gone; it cannot bring back an audit trail. Archive is unchanged, still reversible, and still the right door for anything whose history matters. What protects you now is that Delete takes owner rights and asks for confirmation — a deliberate act, not a refusal.

Being cited is not one of the refusals. A register or a document that other records point at can be deleted by anyone whose role reaches it — the same rule that already applied to archiving. A reference is not a lock. What used to happen instead was a refusal aimed at the person tidying up, which told the person reading the citing document nothing at all; now the citation reports the loss where the sentence is written.

Being cited is still the best reason to choose Archive over Delete, and the difference is worth knowing before you press either:

• Archive keeps the record readable, so every chip citing it goes red and keeps its name — the author can see what was withdrawn and repoint the sentence, and restoring the record clears every dot.
• Delete takes the record away entirely, so a chip citing it can no longer name what it lost: it reads as a restricted record, inactive and unopenable. That is not the app being coy — a citation is resolved for each reader in their own scope, and "destroyed" and "on a team you are not on" cannot be told apart without saying something about a record the reader may have no right to.

So: retire what people cite, delete what nobody ever did — the abandoned import, the duplicate, the test one. Both doors are open either way.

Deleting takes owner rights on the record's team (the same rung as publishing), where archiving takes author rights — destroying history sits above tidying a list. Both rungs are the same for every kind of record: a Writer archives and restores a document, a register or a control, and only an Owner deletes any of them for good. In a mixed selection any row the server does not remove is skipped, and the outcome line that replaces the selection says how many went, how many did not, and Alchex's own words for why — quoted, not summarised. If one reason covers the whole selection you are told it once; if several apply you get each. The selection itself clears; Select the N skipped on that line ticks exactly the rows that were refused, so you can see them or take them another way (archive what would not delete, say) — a click you make, never a selection handed back to you. A row typed Control is a control's definition: Delete removes the control, its wiring and the definition together (the audit history stays), Move takes the pair to the new team, and Archive retires the pair — asking first if the control carries an audit verdict, once for the whole batch. It is deliberately not written in advance: until 2026-08-12 that line recited a fixed list of causes it had guessed at, which was wrong for the kinds that can be in none of those three states — and sent people looking for a publish state to undo that never existed.

Several rows are settled one at a time, not all or nothing. When the batch finishes the selection clears and the outcome line says how many were removed, how many were not, and the reasons the server gave; Select the N skipped re-ticks the ones that could not go. A batch that removed everything just says its number and fades. No row is left behind because another row failed.

The one refusal

A document that is the definition of a control cannot be archived as a plain document. Alchex refuses with This document is the definition of a control — open the control and manage it there. Its lifecycle belongs to the control, so retiring it from the control's own page keeps the control and its document from drifting apart.

Ask Alchex can also propose archiving a document; it arrives as an approval card that states plainly that the document is hidden and made read-only, not deleted, and you can restore it at any time.

Retiring a control, and the one warning it carries

A control is retired and restored by the same act as every other record, at the same author rung — it stopped being a setting on the control's edit form and became the archive every other kind uses. Nothing about the record is destroyed: its evidence, its audit history and every run it has ever had stay exactly where they are, and restoring brings the control back with all of it.

One control is worth a second's thought before you retire it: a control that carries an audit verdict. Archiving it removes that verdict from the compliance record — the clause it answered reads as unassessed again — so Alchex stops and says so, naming the control and the status you are about to clear, rather than doing it quietly. Confirm and it goes; the removal is written into the compliance Activity ledger with your name on it, which is also where a whole batch of retired controls is restored from. A control that was never assessed carries nothing to lose and is retired without the warning. The same warning meets you in the Governance list: archiving rows typed Control archives the control with its definition, and if any of them carry a verdict you are asked once, for all of them, before anything is cleared.

Nothing refuses because something cites it

Removing a record no longer depends on what other people's writing points at. Archive a document, a register, a control or a risk and it goes — there is no list of citers to clear first, no refusal naming them, and no workspace-admin override to write into an audit log, because there is nothing left to override.

What happens instead is that the citation says so where it is written. A chip pointing at a record that has been archived turns its aliveness dot red, keeps the record's name so a reader can see what was lost, and offers Rebind in its popup for pointing the sentence at a live record. Restoring the record turns every one of those dots green again. See References.

That is a deliberate trade. Citing something does not freeze it; it means the citation will tell the truth about it. The refusal it replaces sent people hunting for chips inside documents they had already retired.

Related

• Version history — what the document said, and when.
• Publishing — how a version reaches readers.
• External documents — controlling documents you did not author.