Risk records

The register of risks and non-conformities — how a record is created, what its properties mean, how severity is worked out, and how the list reads.

A record under Risks is one thing that needs attention and one place to work on it: a risk you have identified, or a non-conformity somebody found. It carries how bad it is, who owns it, where it came from, the steps agreed to deal with it, and everything anybody has said about it.

Records live under Risks in the sidebar. Each one belongs to a team, and you see the records of the teams you are in.

The list

The list is the register. Its columns:

Column	What it says
Code	The record's permanent reference — `RSK-014`. Cite this, not the name.
Record	The title.
Type	Risk or Non-conformity.
Severity	Critical, High, Medium or Low — see below — with the probability and impact it came from beside it, P3 × I5.
Status	Open, In Progress, Mitigated or Closed.
Actions	How far the treatment actually got — a hairline bar and n/m.
Due	The date somebody committed to.

Filter by type, severity, status, owner or due date; search by name or code; click a column header to sort by it.

A row is a link. The record's name is a real link to the record, so the gestures your browser already gives you work on it: ⌘/Ctrl-click or middle-click opens the record in a new tab without losing your place in the register, and hovering shows you where the row leads before you commit to it. A plain click still opens the record in place, and the gesture works anywhere along the row, not only on the name itself.

The Actions column reads a dash, not 0%, when there are no actions yet. "Nobody has planned anything" and "nothing has been done" are different states and only one of them is a problem — a record showing 0/4 is behind, a record showing a dash has not been thought about. It carries no colour either: 2/5 done is a fact, not a warning, and the severity two columns to the left is what carries urgency here. See Actions and activity.

There is also a matrix view — the same records plotted by probability against impact — and a personal My risks view that spans every team you belong to and shows the records you own or created.

The register is the risk assessment. There is nothing to generate from it: a written-out snapshot stops being true the moment somebody changes a score or closes a record, so it would only ever be a second, stale account of the same thing. An auditor asking "what are your risks?" should be shown the register, not a copy of last month's. Filter it, sort it, and show it as it stands.

The register is also read by the compliance record's roadmap: the risk-assessment phase cannot count as complete while the register holds no records, however well its documents audit — a written method nobody has run is not an assessment. The record's next step says how many records the register holds, so an empty register is visible where the work is planned, not only here.

Creating one

New record opens a composer. A name is the only thing it needs; the code is assigned when it saves, and the composer says so rather than showing you a blank code field. Everything else is filled in on the record itself, where you can see what you are shaping.

Records also arrive on their own. A control assessment that finds something can push it here as a non-conformity, and it lands carrying the finding's wording, its severity and a link back to what raised it — see From audit below, and Controls and evidence. A workflow can open one too — a procedure with a Create a risk step, usually set to act only when one of its checks finds a gap. That record is an ordinary risk: numbered like the rest, with its own history, its creation line naming the procedure that opened it, and the procedure itself among its linked documents.

The record

Opening a record gives you one page: the name and description on the left, the facts down the right, and below them the actions — each of which opens its own panel, where it can be renamed, rewritten or deleted. The conversation lives in the record's 💬 Comments panel on the right edge — the same panel, with the same name and the same behavior, a document and a register record carry: one chronological list; write, edit your own words, @ a teammate. The system's own account of what happened is the Activity log beside it. The detail of both lives on Actions and activity.

The name is the last step of the trail in the top bar, and that is where you rename it — click it and type. A screen reader still finds the record's name as the page's heading: the field you type in is a text box rather than a heading, so the name is also announced as one for anybody navigating by headings. The page prints it once: the trail is the line that answers which record am I in, it is next to the link back to the register, and it stays put while the page scrolls — so it is the name's home and its editor at once. The trail carries the way back and the name, nothing else — the record's code and its other identity facts are rows in the Properties panel on the right, on every kind of record alike.

The record fills the window. A panel you open runs from the bar to the bottom edge — the same frame a document and a register use. (It used to stop wherever the record's own text stopped, leaving it hanging in dead space on a short record.)

The page above the writing is the trail and nothing else. The code is a row in the Properties panel, the trail's first step is the way back to the register, and the saving state sits next to the name you are typing. What is left in the column is the description — the record itself starts at the top of the page.

The facts read as words, whatever created the record. A record made through an import or an integration can carry a type or a status outside the ones this app's own form offers — those are shown exactly as they were stored, rather than being forced into a nearby option or blanked out. What the record says it is, it says.

It saves as you type. There is no Save button and no edit mode. The name and the description are editable in place, and a quiet Saving… then Saved sits beside the name in the top bar. Everything else is a row in the Properties panel on the right — click the row, pick from the menu.

Nothing on the page explains that, and that is deliberate: a surface that has to be annotated to look editable has not been made obvious. Both fields take a cursor and light up under the pointer, which is what tells you.

Clearing the name puts the old one back. A record with no name at all reads as a blank row in the register, so leaving the field empty is treated as a slip rather than an instruction — the last saved name returns when you click away. Rename it to something else and it saves like any other edit.

The description is a place to write, not a box to fill. It carries no border and no toolbar — the text sits on the page — and it takes structure as you type it rather than as something you pick: ## starts a heading, - a list, > a quoted clause, ``` a block of code, and Ctrl/Cmd+B and +I still do what you expect. A risk worth writing up properly can be written up properly, with subheadings and a quoted requirement, without the record turning into a document: there are no images, tables or columns here, because those belong to documents and this is still a field on a record.

Point at things with /. The same menu finds what this workspace holds — documents, controls, registers, other risks, connected sources, and the actions on this record, which sort to the top because they are usually what a description means. Type a few letters of a name and pick it: the text gets a chip that always shows the thing's current name, turns grey and struck through if it is later removed, and opens it when clicked. An action opens its own panel on its record.

Type / when you would rather choose than remember. It opens one short menu of everything that can go in a description — plain text, a heading or subheading, a bullet, numbered or checklist, a quote, a block of code — and keeps narrowing as you keep typing, so /bul is a bullet list and /quote is a quote. Arrow keys move, Enter chooses, Escape closes. Nothing here replaces the typed shortcuts above; the menu is simply the way in when you do not already know them. Because it only opens at the start of a word, a date like 7/8 and a web address never open anything.

The Properties panel

It opens from the panel buttons at the right of the record's top bar and docks on the record's right edge, and it is what the record opens on — so the standing facts are in front of you the moment you land. (Those buttons ran down that right edge in a slim column of their own until August 2026; they moved up into the bar, where they sit as a small group beside the ⋯ menu, and the record got the column's width back. The panel itself is unchanged.) It is a panel like the others: press History and that panel takes the space, press Properties again and it comes back. One panel at a time, on every kind of record, the way a document's Details behave. (It used to be a column that could never be replaced, so a risk could show two panels at once where a document showed one — the same paint over a different model.)

The five, and they are the same five everywhere. Every record in Alchex — a document, a register and a risk — opens its Properties panel on Code, Owner, Created, Type, Status, in that order, in the same rows. A fact a record kind has nothing to say for reads as a dash rather than disappearing, so the panel you learn on one kind is the panel you can read on all three. On a risk, three of the five are also choosers: click Owner, Type or Status and pick.

Code — the record's permanent reference, RSK-014. It is a fact, not a chooser, and it is the one thing to cite; a code is assigned once, and every citation, every register row and every line in the thread reads it off the record.
Owner — who is accountable for the record, and the only person the record itself names. Picking Unassigned clears it. The record has no separate assignee. Two names on one record would answer the same question twice, and a reader chasing a risk would have to guess which of them to write to. Who is doing the work is answered where the work is — each action in the treatment list carries its own assignee. See Actions and activity.
Created — the date the record was raised. A fact, not a chooser: when something was raised is not a decision. (It read Opened here until the five were unified, which meant one fact under two words depending on which record you were standing on.)
Type — Risk or Non-conformity. Those are the two you can choose. A record that arrived from somewhere else — an import, or an integration — may carry a type of its own, and the record shows it as it was stored rather than pretending it is one of the two.
Status — Open, In Progress, Mitigated, Closed. Each one shows as a small coloured dot beside the word rather than a filled badge, so a screenful of records is readable rather than striped.

Risk — under the five, the facts only a risk has:

Severity — the headline judgement. Where it came from is inside the row's own menu rather than on a line beneath it: the first entry reads Auto — High (P3 × I5), so the derivation is one click away instead of a second control sitting under the row you just used.
Due date — one date, from a normal date picker. The picker's Clear removes it, and the thread records the change with the date written out, not a machine timestamp.
From audit — where the record came from, as a link. It appears only on a record an assessment raised, and it names what was being looked at: the control, or the document and clause that failed. Click it to open that record — a control opens on its page, with its procedure and its workflow runs.

Records raised by the retired document clause audit link to their document. That audit was removed on 2026-08-27, so there is no report left to open; the finding's own wording and severity are on the record, and the document it was raised against is what the row points at. Nothing else about those records changed.

There is no Team row. A record belongs to the team you raised it in, and that is the whole decision — the register you add it from is the choice, so a properties row restating it would only be a second, later chance to send a record somewhere nobody meant it to go. A record that was moved between teams in the past still carries that move in its thread, named by team rather than by id. Which team a record is in is what decides who can read it and who can edit it; see the permissions table below.

Naming an owner tells that person. They get a notice in their inbox saying they now own the record, and it opens straight to it. This applies whether you set the field on an existing record or raise a record with somebody already on it, which is the common case for a finding.

Three silences are deliberate: clearing a field notifies nobody, since "this is no longer yours" is not work; putting your own name in tells you nothing; and a change to any other field on the record is a line in the thread rather than a notice.

A record you created yourself has no From audit row at all — not a row reading None. Nobody's audit raised it, and the panel's own Created row and the thread's first line already say when it was raised and by whom, so an empty row would be a reproach rather than a fact.

Severity, and overriding it

Severity is derived: probability × impact gives a score, and the score gives Critical, High, Medium or Low. Both numbers are chosen once, when you raise the record — the create form puts them side by side with the severity they produce, so you watch the judgement move as you pick them. After that the record's judgement is changed by saying what it should be, not by re-tuning the two inputs behind it.

You can override it. Open the Severity row and pick a level explicitly instead of Auto. The panel then reads the level you chose, and the menu's tick moves from Auto to the level you picked — that is how an overridden severity reads as overridden. The numbers it departed from are not lost — the Auto entry in the same menu still names them, and picking it puts the derived level back.

Where a record came from

A non-conformity is the audit's conclusion, not a copy of the audit. The record says what is wrong, how bad it is and who is dealing with it; the record's own thread carries the finding's wording and severity as it arrived, and From audit in the Properties panel is the way back to the record that was being judged. Follow the link rather than expecting the record to restate it.

Nothing else on the record is attached by hand. A record that has to be furnished with links before it means anything is a form, not a record — so the one link it carries is the one that was never a chore to supply: which audit raised this.

If a record carries a corrective-action record from before actions existed, it appears as its own collapsed section under the description. It is read-only history — new work goes into actions.

History — versions and activity

The record's history opens from the clock icon in its top bar — carrying a count of how many versions there are — and docks on the record's right edge, the same edge a document and a register open theirs from.

It is one list. Everything that happened to the record, newest first, with its versions sitting in the same stream — a version is a marker on the record's own timeline, not a separate ledger, so you read what changed and when it was pinned in one pass instead of comparing two lists. A version line carries its number, whether it is the current one, the sentence somebody wrote, and a Restore.

A version is a moment somebody stood behind — a version you saved by name, a restore, a review pinning the record — and only those carry numbers. Ordinary editing does not mint versions: a stretch of typing reads as an editing session in the stream (Dana edited the description), exactly as it does on a document, with a Return to this action that takes the record back to how it stood when that session ended. Returning is itself recorded — as a new version in your name — so going back never erases the way forward. (Records edited before this model shipped read the same way: their old auto-numbered edit rows leave the version chain and their story stays told by the activity lines they always had — only sessions recorded from the change onward carry the Return to this action.)

The toggle at the top of the panel switches between All activity and Saved versions only. Same list, read two ways: the second is the audit reading — just the moments a person put their name to — and it replaced a separate tab, because a tab and a filter over the same data are the same thing wearing different clothes.

Any earlier version — and any editing session — can be restored. Choose Restore on a version, or Return to this on a session, and the record's own fields — its wording, scoring, status, owner, due date and mitigation plan — return to what that moment says. Nothing is rewound: the act mints a new version whose line names itself (Restored v2 — status: Mitigating → Open), so the trail keeps both the act and what it changed. Links, actions and the conversation stay where they are — relationships and corrective actions are not part of the record's words, and they do not travel backwards with them.

You can also name a version deliberately. Save version in the panel's header opens a note row right in the panel: type your sentence about why (Quarterly review — impact: 3 → 4) and the confirm names the number it will mint — Save v4 — never asks for one. It is the same door, in the same seat, on every record kind's history panel, a document's included, and the note follows the same rule everywhere: optional, and trimmed to 280 characters. A named version saves even when nothing has changed since the last one: "reviewed, still accurate" is itself worth a line in the trail.

A risk's versions live in the platform's one version store. Since August 2026 every record kind's versions are kept by the same engine — one counting chain, one immutability rule enforced by the database itself: a version somebody named or a review pinned can never be altered, by anything. A risk's trail reads exactly as it always did; what changed is that the guarantee behind it is now the same guarantee behind every other record's versions.

A version holds what it said when you saved it, whatever you do next. Keep typing straight afterwards and your edits become the next line in the history; they do not reach back into the version you just named. Until August 2026 this was not quite true: ordinary edits made within half an hour of each other are gathered into one line so a session of typing does not become forty, and a named version could be caught up in that gathering and quietly move with it. Activity is the running account of everything the record did — one muted line per change. The conversation is not here: comments live in the record's own 💬 Comments panel, the same one every record kind carries. Versions is the formal audit trail of the record's own fields: each version, who changed it and when. Versions says which fields changed; Activity says what happened, in order; Comments says what anybody had to say about it.

The activity used to sit in the middle of the record, under the actions. It moved here in August 2026 because the record was showing the same edits twice on one screen: once as a thread line, once as a version. The middle of the page is now the record itself — what it says, and what is being done about it — and its history is one button away, on the same edge a document's and a register's panels open from.

Where the thread reports something that happened to an action, it names that action by its code — "added RSK-014-A2", not a vague "added an action" — so a line in the history points at the step it is about. It also writes states, people and dates the way the rest of the page does: the status a line reports is the same word the action's own chip shows, an assignment names the person rather than their account id, and a moved deadline reads as a date.

The record's own fields are held to the same standard. A line about this record names the person, says which wording moved, and — where a field was cleared — says it was removed rather than set to nothing. That holds for records changed long ago as well as new ones: the sentences are built when the history is read, not when it was written.

Every assignment line in a thread names an action by its code. Those are the treatment steps; nothing else on a record is assigned to anybody.

Every record starts with the line that says it was created, including the ones an audit raised — and on those, the line names the audit it came from. It is written as part of creating the record, so a record cannot exist without one. Re-logging a finding against a non-conformity that is already open adds nothing: nothing was created, and a second "created" line would be the history describing an event that never happened.

Deleting

The ⋯ menu in the top bar carries the record's actions, the same way a document's and a register's do: Copy link hands someone this record's address, and Delete — the red row at the bottom — removes the record after a confirmation naming its code. It leaves the register; its actions and its thread go with it.

The deletion itself is written down, with the name of whoever did it. Deleting a second time — or deleting a record that has already gone — adds nothing, so the line means what it says.

Writing that cites the record does not stop the delete. A risk record can be cited from a document's body — choose Mention in a policy's / palette and pick the risk, and the chip resolves the record's current name for every reader allowed to see it (see References). That reading does not depend on how you are browsing: a risk chip resolves against every team you are in, so filtering the sidebar to one team never turns a colleague's citation of a record in another of your teams into a restricted record.

No removal in Alchex refuses on account of a citation — not here, and not for a document, a register or a control. The delete goes through, and every chip citing the record picks up a red dot where it is written — keeping the risk's name, or its code where it has no name, so a reader can see what was removed — with Rebind on the chip for pointing the sentence at a live record. That includes chips in the assistant's past answers: a removed record reads as removed there too, rather than as one you are not allowed to see.

Who can do what

The same two layers as everywhere else — your workspace role, and your role in the team that owns the record.

Role	Can
Reader	Read records in the team, with their actions and their whole thread — and take part in the conversation: comment. Nothing that changes the record.
Author	Everything a Reader can, plus create records in the team, edit them, and add and update actions.
Owner	Everything an Author can.

Commenting sits with reading, not with editing. If you can see a record you can say something about it, because a comment is about the record rather than a change to it. Editing or deleting a comment is the one thing no role decides: your own words are yours, and nobody else's are.

What a Reader sees is a read-only page, not a page full of controls that refuse. The action composer is absent rather than disabled-on-click, and the assignee and status controls on an action are inert. Everything a Reader may do — read the record, its actions and its whole thread, comment, resolve and reopen — is offered normally.

Workspace owners and admins are treated as team owners everywhere, exactly as they are for documents. Full detail in Permissions, and the team model in Teams.

Asking for approval

A risk carries no approval panel. While a review is pending, its properties show a status line — In review — requested by … — and the record's activity keeps the full trail of every request and decision. The record stays open the whole time: fields, scoring, status, CAPA and actions all keep taking edits, because the decision is recorded against the revision pinned at submit, never against the live record. Withdraw the review to close it without a decision. Opening a review is a server verb with no button in the app (see how a review is opened); deciding happens on My Approvals, where each waiting review carries Approve, Send back and View changes (the fields the pinned revision changed, old value struck through beside the new) on its row.

A team admin approves or sends it back, with a note if they leave one. You cannot decide your own request.
One request at a time per risk. The requester (or an admin) can withdraw an open one.
A request can be routed to a person. Routing is the server's assign verb (an API act today — the same verb a future automation calls): the person is notified once and the request appears on their My Approvals list. Assigning never changes who may decide — it only says whose attention is wanted.
You see what you are deciding on. View changes on the My Approvals row shows the fields the pinned revision changed, old value struck through beside the new.
The ask and the answer both travel. Requesting approval tells the team's admins; the decision comes back to whoever asked — see Notifications.
The decision is a permanent record in the panel and the risk's activity. It is a sign-off on the risk as it stood — closing or reopening the risk itself stays exactly as it works today, so teams that want a second pair of eyes before closing can ask for one, without the form standing in anyone's way.