RAID Log Template: Keep Four Records Distinct

Issue log template: track observed conditions separately

An issue log template records conditions that have already been observed, with a stable ID, owner, observed evidence, current impact, status, resolution summary, and review dates. Inside this canonical RAID owner, issue records stay separate from uncertain risks, beliefs, and dependencies. Bug triage, project status, action execution, and decisions retain their own records and authority.

1. Freeze the R/A/I/D convention and project boundary

   For this pack, R means risks, A assumptions, I issues, and D dependencies. Record the bounded objective, horizon, accountable ledger owner, review cadence, timezone, revision, and state before adding entries. Do not inherit a spreadsheet until its letter meanings and category rules are explicit.

   Sources: [raid-pack], [gov-synergy]

2. Create records with category-specific facts

   Write a risk as an uncertain event with probability, impact, trigger, response, and contingency. Write an assumption as a belief with evidence, validation, and due time. Write an issue from an observed condition and evidence. Write a dependency with direction, counterpart, needed-by time, and failure mode.

   Sources: [raid-pack], [orange-book]

3. Assign owners, review dates, and safe evidence references

   Give each record a stable category-prefixed ID, accountable owner, opening time, last review, next review, and one or more safe relative evidence references. Use approved evidence stores in a real workflow. The fictional pack uses reserved identities and paths so it cannot be mistaken for a live project.

   Sources: [raid-pack], [gov-synergy], [defra-initiation-lessons]

4. Link materialization instead of rewriting history

   When a risk trigger occurs, an assumption is contradicted, or a dependency misses its needed time, create an issue with its own ID and observed evidence. Add a typed, timestamped, reciprocal materialization link. Preserve the source record so reviewers can distinguish what was uncertain from what was observed.

   Sources: [raid-pack], [gov-synergy]

5. Keep decisions and status narrative outside the ledger

   Store only an external decision ID, owner, and safe relative path. Keep the decision question, options, rationale, conditions, outcome, and approval in the controlled decision record. Build the dated status report from reviewed evidence and variance; do not turn the RAID log into a forecast or delivery promise.

   Sources: [raid-pack], [gov-synergy]

6. Validate the revision before human review

   Run the closed Draft 2020-12 schema and the dependency-free semantic validator, then review every category, cross-link, source, owner, external decision reference, and boundary. Append a contiguous change record. Passing structure is a gate for review, not proof that the underlying judgment or evidence is correct.

   Sources: [raid-pack], [json-schema-2020-12]

The RAID coordination boundary

This page owns a four-category coordination ledger and the links between changing records. Adjacent control documents keep their own detail, evidence, and authority.

Four RAID patterns that should stay different

The examples share stable ownership and review mechanics, but each category answers a different question. The fictional values teach the record contract and are not project benchmarks or decisions.

Decide where each record belongs

Choose the owner by the question being answered. Do not make one ledger field impersonate a detailed control document or grant authority.

1. The statement describes something uncertain that might happen

   Choose: Create a risk with an observable trigger, response, contingency, owner, evidence, and next review. Put detailed scoring and treatment history in the risk register.

   Tradeoff: Reviewers follow a second record for depth, but the RAID log stays a concise coordination index.

2. The statement is a belief currently treated as true

   Choose: Create an assumption with current evidence, a falsifiable validation method, due time, owner, and consequence if contradicted.

   Tradeoff: The team must spend time validating the belief, but hidden planning premises become reviewable.

3. The condition has already been observed

   Choose: Create an issue with observed evidence, current impact, resolution step, owner, and review date. Link any source risk, assumption, or dependency through a typed materialization.

   Tradeoff: The ledger carries two linked records instead of one rewritten row, preserving the difference between anticipation and observation.

4. The record describes an input or output needed from another team or system

   Choose: Create a dependency with direction, counterpart, needed-by time, failure mode, owner, and latest check. Create an issue only after the failure is observed.

   Tradeoff: A dependency remains visible before it blocks work without pretending the counterpart has committed delivery.

5. The row contains rationale, approval, overall health, variance, or forecast language

   Choose: Move decision content to a controlled decision record and reporting narrative to the dated project status report. Keep only stable references in the RAID ledger.

   Tradeoff: Information is distributed across accountable records, but approval and reporting meaning stay attached to their evidence and owner.

What a validated RAID log cannot prove

A closed record shape can expose category drift, broken references, unsafe paths, date errors, and explicit authority claims. The real value still depends on complete sources, timely review, access, judgment, and governance.

• The validator checks structure and selected consistency rules. It does not authenticate evidence, inspect linked systems, calculate priority, or decide whether an entry is complete or correctly classified.
• The fixed R/A/I/D convention is this pack’s contract. Another organization may use different letters or meanings and must reconcile them before importing records.
• A risk row does not replace the detailed risk register, treatment evidence, specialist control testing, or authorized risk acceptance.
• An external decision reference does not prove the decision exists, remains current, or was made by someone with the required authority.
• An issue status does not establish overall project health, and a dependency state does not commit another party or update the controlled schedule.
• A real application still needs authenticated identities, server-side authorization, durable storage, optimistic concurrency, audit integrity, minimum-purpose data, retention, export, recovery, monitoring, and human review.
• This ordinary informational article does not grant AI signup credits. The linked product page follows its own current eligibility rules.

Current primary sources and verification record

The same-release artifact is the direct source for its fields, examples, validator, tests, and archive. Current official references support four-category RAID use, risk principles, concise project initiation records, and closed schemas without prescribing or approving this original implementation. No external template text was copied.

1. [raid-pack] Playcode:RAID log fictional example

   Checked August 1, 2026. Supports: The locally reviewed six entries, three materializations, one external decision reference, three revisions, exact record boundary, validator behavior, tests, and reproducible archive. Public availability remains unverified until deployment.

2. [gov-synergy] UK Government:Synergy programme summary business case

   Checked August 1, 2026. Supports: Official 2026 use of a programme RAID log for risks, assumptions, issues, and dependencies, including contingency actions when risks realize and become issues, with decisions handled by separate governance.

3. [orange-book] UK Government:The Orange Book: Management of Risk - Principles and Concepts

   Checked August 1, 2026. Supports: Current 2026 principles for integrating risk with objectives and decisions, using the best available information, clear ownership, identification, assessment, treatment, monitoring, reporting, and continual improvement.

4. [json-schema-2020-12] JSON Schema:JSON Schema Draft 2020-12

   Checked August 1, 2026. Supports: The current specification family declared by the bundled closed schema. Cross-record identities, chronology, materialization, and false-authority rules remain in the dependency-free semantic validator.

5. [defra-initiation-lessons] UK Department for Environment, Food & Rural Affairs:Defra project initiation lessons learned report

   Checked August 1, 2026. Supports: The value of a concise project initiation document covering context, parameters, scope, audience, and RAIDs, supported by collaborative buy-in and an agreed information location.

RAID log template questions