This RAID log template keeps Risks, Assumptions, Issues, and Dependencies together without treating them as the same thing. Record the scope and evidence beside the type, then name the next check. The example follows an original fictional archive-site migration.
Start with four distinct records
| ID and type | Initial record | Appropriate next check |
|---|---|---|
| R1: Risk | Old production URLs may fail after the switch. No production failure is observed in this record. | Plan how the old URL set will be checked and how failures would be handled. |
| A1: Assumption | The export is complete; validation is pending. | Compare the export with the required URL inventory. |
| I1: Issue | Fictional test T1 returned 404 for /guide/a in isolated staging. Production impact is unknown. |
Investigate the staging result and retain the test reference. |
| D1: Dependency | Hosting-team input on redirect configuration is needed before the next migration test. | Identify the required input and confirm who will provide it and when. |
R1 concerns a possible future event. I1 records something already observed in a particular environment. A1 calls for validation, while D1 calls for coordination around an input the test needs.
The UKHSA functional-test-plan template's RAID section distinguishes potential risks, planning assumptions, occurred issues, and dependencies affecting work. This migration scenario and its review records are original examples.
Make the scope part of the description
Select I1 in the example. Its scope is isolated staging, its source is T1, and its observation is the 404 result for /guide/a.
“Old links are broken” would lose the environment and the one route actually checked. Write the narrow observation first, then list any broader question separately. A staging failure can inform the production-risk review without becoming an invented production incident.
For D1, distinguish a needed input from a received one. The example has no confirmed hosting response or delivery date. Those fields remain open until the team supplies them.
Add new evidence without rewriting the earlier review
Choose Later evidence E2. The new fictional record shows that the export omits /guide/a.
That changes the assessment of A1:
| Record | Earlier snapshot | Later snapshot after E2 |
|---|---|---|
| A1 | Export assumed complete; unverified. | Assumption shown false by the omitted URL. |
| I2 | No entry yet. | Incomplete URL inventory recorded as a new issue, linked to A1 and E2. |
Keep the initial assumption visible in the history. It shows what the team relied on before the check and why the later issue was added.
I2 does not automatically explain every part of I1's 404 result. The team still needs to investigate the staging configuration and expected route. R1 also remains a future production risk unless new evidence changes its scope or status.
Review the action each type needs
Use the four type selectors to ask a different question:
- Risk: What possible event are we preparing for, and what would trigger the response?
- Assumption: What are we relying on, and how will we check it?
- Issue: What happened, where is the evidence, and what happens next?
- Dependency: What input must arrive, from whom, and before which activity?
The blank log includes ID, type, description, scope, source, owner, next check, review date, status, and linked record. Leave the actual owner and date open until agreed. If your team uses impact or probability labels, define them together before adding ratings.
The example lets you label a proposed entry and write a reason for its type. It does not automatically classify arbitrary prose or resolve a record when you select a status.
Build a log for your own review
Create one complete, self-contained HTML RAID review log.
Project scope and review date: [FILL IN]
Risks: possible events, context, response questions, source references: [PASTE]
Assumptions: planning beliefs, validation, source references: [PASTE]
Issues: observed events, environment, evidence, next check: [PASTE]
Dependencies: required input, provider, affected activity, confirmation: [PASTE]
Owners, next checks, dates, status, and links where actually supplied: [PASTE]
Later evidence and changes to earlier records: [PASTE]
Keep the four record types distinct and put scope/evidence beside each.
Show initial and later snapshots separately. When an assumption proves
false, retain its earlier unverified state and link the resulting issue
to the new evidence. Do not invent an observation or causal diagnosis.
Let a reader select R/A/I/D and inspect why the record needs its next
action. Keep a staging issue separate from a future production risk.
Keep needed dependency inputs distinct from received confirmations.
Include a blank log with required scope and source feedback, temporary
notes, and a user-selected type with explanation. Do not automatically
judge free text, resolve issues, approve release, or contact anyone.
Preserve notes across views, mark old review output stale after edits,
and ask before resetting. No claimed saved project records.
Use text of at least 16px, labeled keyboard-accessible controls, and
a layout readable at 360px without horizontal scrolling. Put CSS and
JavaScript inline with no external dependencies. Return complete HTML.
Leave the review with specific checks
For this migration, the team needs to investigate the staging failure, complete the inventory check, and obtain the redirect input. A general “monitor risk” action would obscure that work.
In a NOS HTML review copy, clarify the instruction above the proposed-entry builder while discussing the records. Ask for an observed route and test reference when the chosen type is Issue, while keeping a possible production failure in Risk. That gives the next reviewer a clearer rule for separating evidence from a future concern.