Lesson 12 — Regeneration: When the Platform Changes Under You

Generation-time decisions (logged, per Playbook §3–5)

Learning objective

(Bloom's: Create) Design Bridgeway's platform-change regeneration protocol — a register of every platform-dependent decision in your rollout, a named re-checker for each, and a beat for re-checking — and run the full drill alone, on your live configuration, as the capstone.

Standard named: AIHC.2.D2 (Regeneration). The line moves (X2) — models, settings, and plan-tier boundaries shift under a running rollout — and each shift has a blast radius (X6): some changes touch one lesson's habit, some invalidate a policy your whole team follows. Note the boundary with Lesson 07's X2 moment: there, the moving line was a fact to respect; here, it is a system to operate.

Cycle 1 — Your rollout is a stack of dated platform facts (BBQ rulebook referent)

SAY — Every circuit team knows the rulebook changes between seasons — box counts, garnish rules, turn-in windows — and nobody smokes to last year's rules; re-reading the current rulebook at season start is the competition habit. (Referent: BBQ circuit rulebook — flavor only.) Your eleven lessons built decisions on platform facts that were true at freeze time, and the doc-set says so about itself: its frontmatter orders a re-freeze "within 30 days, sooner if a generated lesson produces a learner-reported mismatch against the live console," and names admin-console surfaces "Anthropic's fastest-moving doc category." Regeneration starts with an inventory: which of your standing decisions rest on which dated facts.

SEE — (static register, partially worked)

DO — Complete the register for Lessons 10–11 on your real rollout doc: the analytics-chat gap and dashboard metric names (L10), and the Cowork remote-execution + connector facts your production line rests on (L11). One row each: decision, underlying fact, date.

Cycle 2 — The churn flags: what the doc-set itself says will move first

SAY — The doc-set doesn't just permit re-checking — it names its own most-likely-to-drift claims, and those flags are your priority list. Verbatim from its frontmatter and §10, three flags: (1) "Haiku-tier model always available; org-level toggles cannot disable it — reverify"; (2) "Model access (per-role toggles) flagged BETA, Enterprise-only at freeze time — reverify"; (3) the "Covered Models" 30-day retention policy "names a specific model class — reverify, not stable nomenclature." On that third one, teach yourself the discipline this lesson practices: the policy's class name is churn-flagged, so your register records "the Covered-Models page names a model class — confirm the current name and whether it applies to us before citing it," not the frozen name as fact. (At freeze, the policy stated Team-plan-like orgs without zero-data-retention setups see "no change and there's nothing to configure" — re-check that sentence, too, on the live page before relying on it.) A fourth flag is a live specimen: the third-party-platforms article 404'd at freeze — pages move mid-edit; a vanished page is itself a platform change your protocol must notice.

SEE — (static priority-ordered flag list) The three reverify flags plus the 404, each annotated with which of Devon's standing decisions it would touch if it moved — e.g., a model-access change touching nothing today (Enterprise-only feature he doesn't have) unless it exits beta into Team plans, which is precisely why it stays on the watch list.

DO — Add a WATCH section to your register with these four items. For each, one sentence: what at Bridgeway changes if it moves. Recommended path: order them by blast radius, largest first — retention-related flags outrank model-menu flags for an org whose policy gap is already manual. (Alternatives available on request.)

Cycle 3 — Who re-checks, on what beat

SAY — A register nobody reads on a schedule is Lesson 09's advisory-rule failure wearing a new hat (X4, one last time). Assign each register row a named re-checker and a beat, spending Devon's bandwidth last, not first: the doc-set's own re-freeze order — 30 days — is your outer beat for the full register; the WATCH list gets a faster pass. Recommended path: monthly full-register pass owned by one team lead (not Devon); Devon personally re-checks only the rows whose change would force a policy rewrite (retention gating, audit-log gating) — the rows where only the policy's author can judge the blast radius. (Alternatives on request.) And one trigger beats every beat: a staffer reporting "the console doesn't match the rollout doc" is the doc-set's own mismatch condition — it fires an immediate re-check, no waiting for month's end.

SEE — (static protocol card)

BEAT                       WHO             WHAT
monthly (outer: 30 days)   Grants lead     full register: every fact vs. live console/docs
monthly, first             Grants lead     WATCH list (4 flagged items), largest blast radius first
on mismatch report         Devon           the mismatched row + every row sharing its source page
after any re-check         row owner       register date updated, or decision rewritten + teams told

DO — Fill in the WHO column with your real names, and write the mismatch-report rule into the rollout-plan.docx: the sentence a program staffer needs so they know that reporting "the console looks different" is wanted, and where to send it.

Cycle 4 — What a re-check produces: verdict, rewrite, or takedown

SAY — A re-check ends in one of three written outcomes, and never in silence: CONFIRMED (fact still true — update the register date, done); MOVED (fact changed — the dependent decision gets rewritten, and every team following the old rule gets told, before the register closes); UNVERIFIABLE (the page is gone or ambiguous — the 404 case — the dependent practice falls back to its most conservative form until the fact can be re-established, and the row is marked, not deleted). The third outcome is the one undisciplined rollouts skip: when you can't verify, you don't shrug and keep the old rule — you name the gap and tighten, exactly as your whole curriculum has practiced.

SEE — (static worked example, one row through the protocol) The retention row re-checked under a hypothetical MOVED outcome: "custom retention now available on Team plans" → decision rewritten (the L06/L09 manual-deletion habit retires; a console setting replaces it), register re-dated, and the one-line notice that goes to all three team leads — the full paper trail on one card.

DO — Run one real row now, as rehearsal for the capstone: pick the analytics row (L10), state its verdict against the doc-set as your stand-in for the live console (this is a demo; in production the live console is the ground truth), and write the one-line outcome entry.

Independent at-bat — CAPSTONE: the full regeneration drill, alone, on his live config

No scaffold, no table skeleton, no recommended ordering. The scenario, delivered as it would arrive in real life — a staffer forwards a product-update email: "Model access controls are now available on Team plans, and permission-mode defaults can now be set per-organization." Run the entire protocol on your live configuration, alone:

1. Identify every register row and standing decision this touches (there are more than two — find them, including at least one from a lesson this scenario doesn't name).
2. Classify each touched row's blast radius and order your re-checks.
3. For each, produce the written outcome — CONFIRMED / MOVED / UNVERIFIABLE — with the rewrite where MOVED (note especially: if org-level mode defaults are real, Lesson 07's "policy-only" finding — the load-bearing enforcement gap of your whole trust-lane design — must be re-litigated in writing).
4. Update the register, draft the notice to your team leads, and state which single change you verify personally and why that one.

Deliverable: the updated register + outcome entries + team notice, as one document. This is the sequence's final at-bat; there is no worked example to imitate.

Exit ticket (climbing to Create; graded against the doc-set + his own protocol)

1. (Remember) Name the doc-set's stated re-freeze window and the event that triggers an immediate re-check ahead of it.
2. (Understand) Why does your register record "the Covered-Models page names a model class — confirm before citing" instead of recording the class name itself? Answer in churn-flag terms.
3. (Apply) A staffer reports the Connectors settings page looks different from your rollout doc's screenshot description. Walk the protocol: who acts, what gets re-checked beyond that one page, and what are the three possible written outcomes?
4. (Analyze) Rank your four WATCH items by blast radius for Bridgeway specifically, and defend the top ranking with the standing decision it would force you to rewrite.
5. (Create — objective level) Anthropic ships a plan-tier reshuffle: three Enterprise-only features move to Team. Design the regeneration response end-to-end — which lessons' decisions get re-opened, in what order, who re-checks what, what your team hears and when — and name the one part of your apparatus that survives any platform change untouched (and why the standards, not the settings, are what make that true).

Ledger write

ledger_write:
  learner_id: L2-ADMIN-DEVON
  lesson_id: L2-admin-devon-12-d2-regeneration
  anchors: [AIHC.2.D2]
  tags: [X2, X6]
  exit_ticket:
    score: ""
    bloom_reached: ""
  auto_score: ""
  self_score: ""
  calibration_gap: ""
  journal_prompt: >
    Twelve lessons ago your rollout plan said "Auto mode for all three, to reduce staff
    friction." Reread that sentence, then look at today's register. What kind of admin wrote
    each document — and what, specifically, would you tell the version of you who wrote the
    first one?
  structure_used: PBL
  referents_used: [bbq-circuit-rulebook]
  next_lesson_seed: "sequence complete — the register's monthly beat IS the next lesson trigger: any MOVED outcome seeds an in-situ micro-lesson on the changed surface, generated against the re-frozen doc-set."

RUBRIC SELF-AUDIT (against Exemplar_and_Rigor_Rubric_Cowork_x_Nonprofits_2026-07-19_v01_I.md)

Escalation check: no load-bearing indicator fails → auto-ships per the versioned escalation policy (Playbook §5).