raid-log

RAID Log

When to use

Append/update persisted RAID log using profile definitions and severity scale — escalation threshold enforced.

What this skill does not do

• Does not downgrade severity to avoid escalation — severity laundering guarded.
• Does not leave entries unowned.
• Does not output only new row — full updated log for save-back.

Preconditions

Input	If missing
Entry to log (description)	Ask
Current RAID log	Create new if none; use profile format
Practice profile (RAID definitions, severity, escalation)	Sensible default; [PROVISIONAL]

Provisional mode

Ambiguous Risk vs Assumption: ask using profile definitions — don't guess.

Trust spine

• Confidence bands (governance-tracking):
  • High: Classified, severity with rationale, owner assigned, escalation flagged if threshold met.
  • Medium: Classification confirmed with user.
  • Low: Severity without rationale — require one-line rationale.
• Failure modes:
  • Incentive Gaming: Guards severity laundering — downgrading risks to assumptions or softening language.
• Escalation triggers: Entry meets profile threshold — ESCALATION FLAG explicit, not deferred.

Workflow

1. Read profile for RAID format, definitions, severity scale.
2. Get current log.
3. Classify entry — ask if ambiguous.
4. Assign severity with one-line rationale.
5. Assign owner.
6. Check escalation threshold.
7. Output full updated log + ESCALATION FLAG if applicable.
8. Gaming-pattern check before output.

Output format

CONFIDENCE: [defensible recommendation | structured first pass]
[Full RAID log table]

ESCALATION FLAG: [if threshold met — why]

Worked example

Input: "Vendor may slip delivery" logged as Assumption, severity Low, no owner.

Expected output: Reclassify as Risk [review]; severity rationale required; owner assigned; escalation assessed.

Quality checks before delivering

• Profile definitions used for classification
• Severity has rationale
• Owner assigned
• Full log output
• Escalation flag when threshold met
• Gaming-pattern check run