Lesson 06 — B2 Failure Literacy: Anticipating Rollout Failure Modes

Generation-time decisions (logged)

Learning objective

(Bloom's: Evaluate) Classify three verified rollout incidents — retention misconfig, permission drift, connector scope creep — against the doc-set's own failure surface, and convert each into an enforced, point-of-use rule rather than an advisory policy sentence.

SSD cycle 1 — naming precisely, and building rules that don't rely on memory

• SAY: AIHC.1.B2 asks you to "recognize common failure modes... and name what happened specifically rather than 'it got it wrong.'" A rule nobody can follow at the moment of use is a future incident (the enforcement-over-advisory principle this whole apparatus runs on): a memo paragraph nobody rereads mid-task doesn't stop anything. The fix for each finding below is stated as an action at the point of use, the way you'd actually encounter it mid-task — not a policy paragraph.
• SEE: A static three-row shell: Failure mode | What actually happened (specific) | Enforced rule (point-of-use) — empty, filled across Cycles 2–4.
• DO: Before filling anything in, write why "IT will handle it" — your policy draft's implicit answer for all three risks — fails the enforcement test: it names a person, not a mechanism, and a person can be out sick the day it matters.

SSD cycle 2 — retention misconfig: not a mistake, an assumed control that doesn't exist

• SAY: Lesson 05 verified it precisely: your plan's Team tier has no "Manage data retention controls" lever at all (doc-set §4/§5 — that capability lives only in the Enterprise-only row). Naming it specifically: this is not "IT set the wrong number of days" — it's "the policy assumed a category of control your competition rulebook doesn't have," the same way entering a brisket in a category whose rules you never actually read doesn't excuse the disqualification. Separately, doc-set §5 also names a distinct "Covered Models" 30-day retention floor tied to specific model classes and to orgs previously running zero data retention — the doc-set does not state whether or how this floor applies to Team-plan orgs like yours; that is an open question this lesson does not invent an answer to (R13/R2) — verify it directly rather than assume either way.
• SEE: The three-row shell, row 1 filled: Failure mode: retention misconfig. What happened: policy assumed a Team-tier control that doesn't exist; true default is "retained indefinitely" absent a custom setting your plan can't set. Enforced rule: "Before uploading a record to any Cowork workflow, ask: would you accept this file existing in Claude's history indefinitely? If not, it doesn't go in — there is no console setting on this plan to catch it later."
• DO: Write your own one-line version of that enforced rule, phrased the way a program officer would actually read it mid-upload — not the way a memo would phrase it.

SSD cycle 3 — permission drift: no automatic net on this plan tier

• SAY: Doc-set §3: SCIM automatic deprovisioning is "Enterprise and Console only" — your Team-plan org has no automated mechanism removing a departed staffer's access. Naming it specifically: drift isn't "someone tampered with a role" — it's "no mechanism forces the removal step doc-set §2 describes (Members → menu beside the member → "Remove from team"), so it depends entirely on someone remembering." A choir doesn't find out the alto section walked out mid-concert — someone takes attendance before it starts, on a checklist that already has teeth.
• SEE: Row 2 filled: Failure mode: permission drift. What happened: no SCIM/JIT auto-deprovisioning exists at Team tier; removal is a manual §2 step with no forcing function. Enforced rule: "Add 'remove from Claude org (Organization settings > Members)' as a line item on the existing staff-offboarding checklist — attach it to a process HR already enforces, not a new reminder nobody owns."
• DO: Check: does your org already have a staff-offboarding checklist (badge return, email deactivation, etc.)? Write the exact line you'd add to it, in the same format as its other items.

SSD cycle 4 — connector scope creep: the toggle isn't the real surface

• SAY: Doc-set §9's load-bearing property: "Claude inherits each person's permissions from the connected service. If someone can't access a specific file, channel, or record in the source system, the connector can't reach it from Claude either" — which means the org-level connector toggle (Lesson 02) was never the thing to watch; a staffer's own growing access in the source system is. Naming it specifically: scope creep isn't "the connector got hacked" — it's "someone's shared-drive permissions grew for an unrelated reason, and Claude silently inherited the larger reach with nothing on Claude's side to flag it." Gap already on record (Lesson 02): the doc-set's specific third-party setup walkthrough 404'd (§10) — this rule stays at the general mechanism, which is what's actually verified.
• SEE: Row 3 filled: Failure mode: connector scope creep. What happened: permission inheritance means Claude's reach grows silently with the source system, not with the connector setting. Enforced rule: "Pair the connector's access scope to your organization's existing shared-drive permission review cadence — whatever already re-checks who can see what in the drive itself is where connector scope actually gets caught, not a separate Claude-specific review."
• DO: Name the review cadence your org (or a comparable one) would realistically already have for the shared drive itself, and write the one line that attaches the connector check to it.

Independent at-bat

Rewrite the full data-handling-policy-draft.docx paragraph, end to end, folding in: the "sensitive information" definition (Lesson 02), and all three enforced point-of-use rules from this lesson — producing the actual corrected policy document, unscaffolded.

Exit ticket (Bloom's climbs to Evaluate; graded against the doc-set + Devon's verified findings)

1. (Remember) Name the three failure modes this lesson classified.
2. (Understand) Why does "IT will handle it" fail the enforcement-over-advisory test?
3. (Apply) Write the point-of-use version of the retention rule as it should appear the moment a staffer opens the upload dialog.
4. (Analyze) A new hire joins the Development team and is added to the shared drive with broader access than intended. Which of the three failure modes is this, and what evidence in this lesson's classification tells you so (not a guess)?
5. (Evaluate — objective level) Your rewritten policy paragraph (the at-bat): defend, citing the specific doc-set sections, why each of its three new rules is enforceable on your org's actual plan tier — not aspirational.

Ledger write

ledger_write:
  learner_id: L2-ADMIN-DEVON
  lesson_id: L2-admin-devon-06-b2-failure-literacy-20260719
  anchors: [AIHC.1.B2]
  exit_ticket: {score: "", bloom_reached: evaluate}
  auto_mastery: "0.25 -> "
  auto_score: ""
  self_score: ""
  calibration_gap: " — populates when a learner takes this lesson live"
  journal_prompt: >
    Of the three enforced rules you wrote, which one depends on a process outside Claude entirely
    (HR offboarding, drive permission review) — and what does that tell you about where a rollout's
    real risk usually lives?
  structure_used: PBL
  referents_used: [competition BBQ circuit, gospel choir]
  next_lesson_seed: "Arc complete for the six named anchors (A1–A3, B1–B2 plus the diagnostic). A follow-on lesson would revisit B3 (trust calibration) or C2 (governance) once Devon's rewritten policy has run for a full grant cycle."

RUBRIC SELF-AUDIT

Escalation check: no load-bearing indicator fails → auto-ships.