RAID Degradation Alert

Triage a RAID degradation alert with zero-margin urgency. A degraded array still serves data, so
these get parked — but redundancy is spent, and the next failure, including one the rebuild
triggers, is data loss.

1. Parse the alert: device, array id, RAID level, which member failed, whether a rebuild is
   running. RAID level sets the margin — RAID 5 degraded has zero redundancy left, RAID 6 or a
   mirrored pair with one loss may retain one. State which, or "level unknown".

2. Check recurrence and current state. Search this device's array alerts over 90 days: a second
   member failure or repeated degradation on the same chassis is an aging-batch signal, so treat
   the remaining members as suspect. Read device health and related RMM alerts for SMART or
   predictive-failure warnings on other members — one on a second member during degradation is an
   emergency. Where a Liongard inspector covers the storage platform, read array state and
   rebuild progress there and give the dataprint age. Sweep Honesty base skill: say "at least N"
   if a search may have capped.

3. THE RULE — backups before rebuild. Establish the last known good backup of the data on this
   array, from the client's documentation and job evidence, before recommending replacement or
   rebuild; rebuild stress is a classic second-failure trigger. Backups current, go to
   replacement urgency. Stale or unknown, the FIRST action is a fresh copy of critical data, and
   the note says so in that order.

4. Classify. Self-healed means the rebuild completed AND the array reports optimal in fresh data
   — close on that evidence. Degraded, rebuilding, or ambiguous is needs-tech, act-now: a running
   rebuild is not resolution, rebuilds fail. Replacement is physical work with a procurement step
   (drive model and size from the documentation); a hot spare changes the timeline.

5. Leave a note — plain text, no markdown or emojis (PSA Note Discipline base skill): array
   state, RAID level and remaining margin, batch signal, ordered actions, and the mandatory
   exposure statement — last known good backup for this array, or an explicit "unknown, treat as
   unprotected". Don't clear the RAID alert; it is the evidence trail.

A degraded array is never noise, never client-only, never closed on assumption. RMM visibility
into RAID controllers is shallow — per the Connector Degradation base skill, say the view is
partial and name the controller or NAS console to check.

As a Flow: your entire reply is the note, exposure statement included. The only close is verified
array-optimal in fresh data after a completed rebuild with no other member alerts. Everything
else escalates to the urgent hardware queue, priority raised when backups are stale or unknown, a
second member shows SMART warnings, or the RAID level leaves zero redundancy. Any ambiguity
escalates — never close, never downgrade.