RAID Log
The RAID Log page of a project: risks scored by probability and impact with their mitigation and contingency, assumptions, issues and dependencies, each with its area, owner, dates and status, the risk matrix, the lifecycle and the versions.
By the end of this page you will have written down what may go wrong on a project and what it leans on, as a log the review meeting walks every week; know every field a RAID item carries, how a risk is scored and placed on the matrix, and what reads the log downstream; and know how an item moves from raised to closed, how it is deleted, and where every version of it is kept.
The RAID log holds four kinds of entry on one sequence (CRM-RSK-4): a risk is something
that may happen and would hurt the project, scored by how likely and how bad, with a mitigation
(what the team does now) and a contingency (what happens if it occurs); an assumption is
something taken as true for the plan to hold, reviewed until it is confirmed or fails; an
issue is something that has happened and hurts now, scored by how bad; a dependency is
something the project needs from outside itself. They share a log and a sequence because the same
meeting walks all of them and an assumption that fails becomes an issue without changing its key.
The log is internal: a client guest never sees it. Every save of an item is kept as a
version.
Before you begin
| You want to | You need |
|---|---|
| Open the RAID Log | raid:view-any on the project, which every staff role carries. A client guest is refused at the door. |
| Raise an item | raid:create. Project managers, business analysts, developers and QA engineers have it by default. |
| Edit or move an item | raid:update. |
| Delete an item | raid:delete. Project managers and business analysts have it by default. |
| Name an owner | The person to be a member of the team. |
The page lives under a project: open the project and choose RAID Log in the sidebar, badged with how many items still need attention (open, monitoring, mitigating or occurred). The page is the first tab of its family; the second, Decisions, holds the decision records.
Read the log
The table lists one item per row:
| Column | What it shows |
|---|---|
| Reference | The item's key, painted in the colour of its kind. |
| Item | The title, with the area and the first line of the description beneath it. Press the title to open the flyout. |
| Kind | Risk, assumption, issue or dependency, with the kind's icon. |
| Status | Open, monitoring, mitigating, resolved, closed, occurred or accepted, as a badge. |
| Score | Probability times impact for a risk, the impact for an issue; red from fifteen, amber from eight, green below. |
| Owner | The person who answers for the item, or Unassigned. |
| Next Date | Due for an issue or a dependency, Review for a risk or an assumption, or No date. |
| Updated | How long ago the record last changed. |
| Row menu | View Item, Edit Item, Move to, Activity, Delete Item. |
Sort by reference, title, kind, status, score, the due date or updated by pressing a column heading; press it again to flip the direction. The list opens in the project's own order.
Above the table, narrow the list with the search box (words in the reference, the title or what a dependency depends on), the kind, status and area lists and the owner list. The filters travel in the page address, so a filtered list can be shared; Clear Filters on the empty state drops them all.
Read the risk matrix
While the project has an open risk with a probability and an impact, a five by five matrix sits above the table: probability runs left to right from rare to almost certain, impact bottom to top from negligible to severe, and each cell counts the open risks that sit there. A cell is green while probability times impact is under eight, amber from eight, red from fifteen; the further up and to the right a risk sits, the sooner it needs a mitigation. Resolved, closed and accepted risks leave the matrix; a risk that occurred stays on it until it is closed.
Raise an item
- Press Raise Item.
- Pick the Kind and the Area. A risk is the default; the kind decides which fields the editor shows.
- Type the Title: what may happen, or what has happened, not what to do about it. This alone is enough; Heimdall will propose the rest.
- Write the Description.
- For a risk, rate the Probability and the Impact from one to five and write the Mitigation and the Contingency; for an issue, rate the impact.
- For a dependency, say what it Depends On.
- Pick the Owner and set the Due On date (issues and dependencies) or the Review On date (risks and assumptions), and press Raise Item.
The item takes the next number of the log's sequence whatever its kind (the first item of CRM
is CRM-RSK-1), records who raised it, starts open, appears in the table at once (a risk on the
matrix too), writes its first version, and raid_item.created goes out to every endpoint
subscribed to it.
A risk without a score is a worry, not a risk
Rate how likely and how bad before you leave the editor. The score places the risk on the matrix, orders the log and decides what the review meeting looks at first; a risk without one sits at the bottom and is forgotten.
Open an item
Press an item's title, or View Item in its row menu, to open the detail flyout: the reference, kind, status and area at the top, the title, then the description, the probability, impact and score for a risk or an issue, the mitigation and the contingency for a risk, the owner and who raised it, what a dependency depends on, the due or the review date, the dates, and the Versions section with every save of the item. From the flyout:
- Edit opens the editor on this item.
- Move to changes the status in one step, offering only the moves the lifecycle allows.
- Restore this version under any earlier version puts it back, the score derived again; see revisions and versions.
- Activity opens the item's history: every change, who made it and where it came from.
- Delete opens the confirmation.
A link such as /projects/<id>/raid?show=<item id> opens the page with that item's flyout already
open; Heimdall's View buttons use it.
Edit an item
- Press Edit Item in the row menu, or Edit in the flyout.
- Change what you need. Changing the kind keeps the reference and drops the fields the new kind does not carry: an assumption keeps no probability, no impact and no mitigation. The owner must be a member of the team.
- Press Save Changes.
The save derives the score again, writes a new version of the item, and raid_item.updated goes
out with the columns that changed, each with its old and new value, the score among them when it
moved. An edit that changes nothing writes nothing and announces nothing. The status does not
change from the editor; it moves from the list or the flyout.
Move an item along its lifecycle
Move to in the row menu or the flyout offers the moves the lifecycle allows from where the item stands:
| Status | Meaning | May move to |
|---|---|---|
| Open | Raised and not yet looked at. | Any other status |
| Monitoring | Watched at every review; nothing to do yet. | Any other status |
| Mitigating | Being worked on to make it less likely or less bad. | Any other status |
| Resolved | Dealt with: the issue fixed, the dependency delivered, the assumption confirmed. | Any other status |
| Occurred | The risk happened; the contingency is now the plan. | Any other status |
| Accepted | Lived with on purpose; nobody will act on it. | Any other status |
| Closed | Off the log; kept for the record. | Open |
Open, monitoring, mitigating and occurred count as needing attention: they fill the sidebar badge
and keep a risk on the matrix. Every move writes a version with the reason moved and
raid_item.status_changed goes out with the status before and after.
Delete an item
Delete Item in the row menu or Delete in the flyout opens the confirmation. Deleting
removes the item with every version it kept and its activity history; its number is never handed
out again. raid_item.deleted goes out. Prefer Closed for an item that no longer matters: it
keeps the record and the reasoning.
All the fields
What happens next
- Every save, move and restore writes a version and an entry in the project's activity history.
raid_item.created,raid_item.updated,raid_item.status_changed,raid_item.restoredandraid_item.deletedgo out to the webhook endpoints subscribed to theraid_item.*family.- The project overview will count the open items and show the top risks, the status report will list them, the sprint planner will weigh the dependencies, and a risk that occurs will become work through a link, as those modules land.
Heimdall on this page
Heimdall reads the log and its versions through the same tools the MCP server offers, raises a risk as open when a story, a plan or a conversation shows something that may go wrong, and carries the open project as its context.
On the editor, Ask Heimdall beside each long field drafts it, improves it, shortens it, makes it testable or rewrites it as Given, When, Then; the draft waits under the field until you take it or drop it. See inline assists.
The brief import will draft the risks and assumptions a brief implies into a review queue, and the planning assistant will weigh the open dependencies before it proposes a sprint.
From the API and MCP
RAID Log API
List, read, raise, change, move and delete items, and read and restore their versions.
Planning tools
list_raid_items, get_raid_item and raise_risk: the MCP tools that read the log and raise a risk.
Permissions
| Action | Permission |
|---|---|
| See the log | raid:view-any, raid:view; never a client guest |
| Raise an item | raid:create |
| Edit or move an item | raid:update |
| Delete an item | raid:delete |
| Read or restore its versions | raid:view to read, raid:update to restore; never a client guest |
Frequently asked
Related
- Traceability — the Links panel in the flyout: what this implements, verifies, depends on or relates to, read from either side
- Comments and mentions — the Discussion panel in the flyout: questions, answers, mentions, followers
- Attachments — the Files panel in the flyout: wireframes, specifications and samples pinned on the record
- Use cases — the flows a dependency or a risk may block
- Revisions and versions — every save kept, any version put back
- Status reference — every kind, area and status
raid_item.*webhook events
How is this guide?
Last updated on
Use Cases
The Use Cases page of a project: how each actor reaches a goal with the system, with the actor, the goal, the trigger, the conditions before and after, the steps of the main flow and the alternate and exception flows that leave it, the review lifecycle and the versions.
Decisions
The Decisions page of a project: every choice the project made with its kind, context, the options weighed, what was decided, the consequences, who decided and when, the decision it supersedes, the lifecycle from proposed to accepted and the versions.