RAID Log Drafting from Discovery Notes

Tier: Foundation · Hands-on time: ~20 minutes

A RAID log is summarization-shaped work, which is exactly where AI assistance is safest and most established for architects. The trap is subtler than hallucination: a model will cheerfully assign "High likelihood / Medium impact" to every row, and those plausible-looking ratings will survive into the steering-committee pack unexamined. So the workflow extracts and drafts with AI, but generates ratings as empty columns that only a human may fill.

When to use

• •
  Discovery or inception has produced scattered notes, transcripts, and whiteboard photos that must become a formal RAID log.
• •
  An existing RAID log is stale and a fresh pass of meeting notes needs merging into it.
• •
  You inherited an engagement mid-flight and need a candidate RAID log from the document trail to review with the outgoing architect.

Skip AI when you attended every session and the log is under a dozen items — writing it directly is faster than reviewing a draft.

Prerequisites

• Source notesmeeting notes, transcripts, workshop outputs; cleared for AI processing per your engagement's constraint register (pb-03).
• An LLM chat assistant for the interactive pass, or a structured-output API for repeatable extraction into your tracker.
• Your RAID templatethe columns your PMO actually uses, so the draft lands in the right shape.
• The requirements register (pb-01) if it exists — assumptions already captured there should not be duplicated.

The workflow

1. 1.

   Consolidate the sources. Concatenate the notes with a one-line header per source ("Day 2 workshop — integrations", "Call with Meridian ops lead"). Provenance headers let the model cite where each item came from — and let you check it.

2. 2.

   Extract with categories defined and ratings forbidden.

   Copy

   Draft a RAID log from the discovery notes below for the Meridian Retail
   engagement (support copilot + order-status agent, US retailer, services
   delivery from India).
   
   Definitions to use strictly:
   - Risk: uncertain future event with negative impact if it occurs.
   - Assumption: something we are treating as true without confirmation.
   - Issue: a problem that exists NOW.
   - Dependency: our progress requires an action by someone else.
   
   Rules:
   - Each item: category, one-sentence statement, source header it came
     from, and a supporting quote or close paraphrase from the notes.
   - Do NOT rate severity, likelihood, or impact. Leave those columns
     containing exactly "TBD-ARCHITECT".
   - Do not invent items that are merely typical of such projects; every
     item must trace to the notes. If the notes are thin in a category,
     say so rather than padding.
   - Flag as DUPLICATE? any items that may be restatements of each other.
   ###
   [paste consolidated notes]
   

3. 3.

   Or run it as a repeatable extraction. If RAID drafting is weekly hygiene rather than a one-off, pin the shape with a structured-output call so the result drops straight into your tracker:

   Copy

   from pydantic import BaseModel
   from anthropic import Anthropic
   
   class RaidItem(BaseModel):
       category: str          # Risk | Assumption | Issue | Dependency
       statement: str
       source_header: str
       supporting_quote: str
       rating: str            # always "TBD-ARCHITECT" by instruction
   
   class RaidLog(BaseModel):
       items: list[RaidItem]
       thin_categories: list[str]
   
   client = Anthropic()
   result = client.messages.parse(
       model="claude-opus-4-8",
       max_tokens=4000,
       thinking={"type": "adaptive"},
       messages=[{"role": "user", "content": PROMPT + notes}],
       output_format=RaidLog,
   )
   log = result.parsed_output
   

4. 4.

   Do the category calls yourself. The riskiest edits are misfiled items: an unconfirmed assumption filed as a risk never gets validated; a live issue filed as a risk never gets an owner. Walk every item and re-file where needed — "Meridian will provide staging access by week 3" is a dependency and an assumption, and it should appear as both.

5. 5.

   Fill the ratings — the human step. Rate severity and likelihood from your knowledge of this client and team. Do it in one sitting so the scale is consistent, and replace every TBD-ARCHITECT. Any row still showing TBD does not enter the review pack.

6. 6.

   Merge, dedupe, and route. Fold the draft into the master log, resolve the DUPLICATE? flags, assign owners and review dates. Items sourced from a quote you cannot find in the notes get deleted or re-sourced — not kept on vibes.

Verify before you trust it

• Traceability sampling. Pick five items and find their supporting quotes in the original notes. A model that invented one "typical project risk" has probably invented three.
• No rating leakage. Search the draft for High/Medium/Low and probability language. Models sneak ratings into the statement text ("significant risk that…") even when the columns are clean — neutralize the wording so your rating is the only signal.
• Category spot-audit. Recheck every Dependency: models over-file client actions as risks. If it requires someone else to act, it is a dependency with a date, and it belongs in the client-facing tracker.
• Coverage against your memory. The strongest check is negative: what do you remember from discovery that is absent from the draft? Notes capture what was said, not what you noticed. Add those items by hand — they are usually the most important ones.

Restricted-environment variant

Discovery notes name client systems, people, and problems — often the most sensitive prose in the engagement. Check the pb-03 register first. Where external tools are prohibited: run the extraction on a client-tenancy endpoint (Bedrock or Azure OpenAI in the client's subscription), or locally via Ollama — the extraction prompt works unchanged. Where only redacted content may leave the boundary, replace names with role placeholders ("[OPS-LEAD]", "[ORDER-SYSTEM]") before pasting; RAID structure survives redaction well. The ratings step never involves AI in any environment, so the restricted path costs you nothing where it matters most.