/xai-check

name: xai-check
description: "Explainability (XAI) audit for products containing AI components. Five-stage tier-scaled check: risk classification, stakeholder×question matrix, fidelity audit, system card, recourse path. Honest about what was validated functionally vs what needs user testing."
metadata:
  instruction_budget: "60"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."

XAI Check Skill

Operational gate for the Explainability Theory Gate (Gate 13). Audits whether a product's AI components meet a defensible XAI bar — disclosure, decision-explanation, recourse, fidelity, system card — scaled to the AI Act risk tier.

This skill is **functionally-grounded** in Doshi-Velez & Kim's (2017) sense: it operates on artifacts and configuration, not on real users with real tasks. Output explicitly distinguishes `validated_functionally` from `needs_user_testing`. The honest tag is what passes Gate 13; user-grounded validation is recommended but not blocking.

When to Use

• L3 Define→Develop or Develop→Deliver, **only when `active-stack.yml :: ai_components.detected: true`**
• L4 Develop→Deliver — required when AI components reach user-affecting decisions (deny, recommend, rank, generate user-shown content)
• L5 Develop→Deliver — required for any user-facing AI feature at launch
• After any change to AI components, prompts, or surfaces that affect user-facing decisions
• When Gate 13 is checked during `/mycelium:diamond-progress`

Precondition: AI components detected

Read `.claude/jit-tooling/active-stack.yml` (Step 1c output of `delivery-bootstrap` per `${CLAUDE_PLUGIN_ROOT}/jit-tooling/detector.md`). It is **project state** — it lives in the consumer's `.claude/`, not in the shared plugin cache.

• If `ai_components.detected` is missing or `false`: report **"No AI components detected — XAI Gate N/A. Run `/mycelium:delivery-bootstrap` if you believe AI is present but undetected."** Stop.
• If `ai_components.detected: true` but `user_facing_decisions: unknown` (Step 6 confirmation never answered): prompt the user explicitly: *"This product has AI components, but it's not on record whether their outputs reach end users in a user-affecting way. Does the AI's output deny / recommend / rank / generate content shown to users, or otherwise drive their experience?"* Do not proceed silently — XAI tier depends on this answer. If the user defers, default to `tier: limited` and note **"tier defaulted to limited pending user_facing_decisions confirmation"** in the output.

Workflow (5 stages)

For each service in `services.yml` (loop — multiple services produce per-service findings):

Stage 1 — Risk tier classification

**Source canonical tier from `/mycelium:regulatory-review` output if available.** Read `.claude/canvas/privacy-assessment.yml` for prior AI Act risk classification. If `/mycelium:regulatory-review` has run, use its tier; this skill does not re-classify regulatory tiers as that would risk producing divergent classifications across two skills.

If `/mycelium:regulatory-review` has not run: 1. Recommend running it: *"`/mycelium:regulatory-review` is the canonical AI Act tier classifier. Without it, this skill produces a provisional tier only — which is fine for early development but should not be the final source for L4/L5 transitions."* 2. Apply provisional logic: AI Act Annex III categories → `high`; user-affecting AI without Annex III → `limited`; non-user-affecting AI → `minimal`. 3. Record `xai.tier` with a `provisional: true` note until `/mycelium:regulatory-review` confirms.

If tier classification yields `prohibited`: **stop immediately.** Escalate. Do not run subsequent stages — the product cannot ship under EU AI Act Article 5.

**Item caps by tier** (pre-committed to prevent checklist sprawl):

• `minimal`: ≤5 total items across all stages
• `limited`: ≤15 total items
• `high`: ≤25 total items

Stage 2 — Stakeholder × question matrix

Rows = relevant stakeholders for this tier:

• `end_user` (always)
• `affected_non_user` (high-risk only — e.g., a person whose data is used but who didn't initiate the interaction)
• `deployer_developer` (limited+)
• `regulator` (high-risk)

Columns = Liao, Gruen, Miller (2020) question categories, subset by tier:

| Tier | Questions checked | |---|---| | minimal | `output` (what can it do?), `why` (basic rationale) | | limited | + `input` (what data?), `why_not` (contrastive), `how_to_be_that` (recourse) | | high | + `what_if` (sensitivity), `performance` (per-population accuracy), `how_global` (overall mechanism) |

For each cell relevant at the determined tier, ask the operational question: **"Is this answerable for this stakeholder, in the moment of impact, by an interface that exists today?"** Verdict per cell: `pass` / `partial` / `fail` / `N-A`.

This is intentionally Bansal et al. (2021) friendly — the test is "answerable when needed," not "always-on documentation."

Stage 3 — Fidelity audit

**Run only when the product surfaces LLM-generated rationales to users** (e.g., "Recommended because…", "Denied because…", chain-of-thought summaries).

1. Sample N outputs (N=5 minimal, 10 limited, 20 high) from production logs or a representative test set. 2. Method: blind a reviewer to the rationale. Show input + rationale; ask reviewer to predict the system's actual output. Record predictions. 3. Compute `blind_prediction_accuracy = correct_predictions / N`. 4. Verdict thresholds: `pass` ≥ 0.7; `partial` 0.5–0.69; `fail` < 0.5. Below 0.5 means the rationale doesn't actually justify the output — Lanham et al. (2023) faithfulness gap.

Save raw samples to `.claude/evals/xai-fidelity/<service>/YYYY-MM-DD.json` (mkdir -p on first write — directory may not exist). Aggr