Lesson 12 — D2 Regeneration (Capstone): What to Recheck When the Code Cycle Changes
Standard: — · Bloom's: — · Structure: PBL — capstone.
Notice the Say-See-Do cycles running on Frank O.'s actual work — not a canned exercise — and that every capability claim is cited to the frozen doc-set. The exit ticket climbs Bloom's to —, and the lesson closes by writing to the ledger.
Capstone note: this is the unit's closing lesson. Lessons 7–11 each built one real tool (a trust-rule sheet, a labeling system, a governance rule set, a bid-sheet habit, a two-thread split). This lesson's independent at-bat asks Frank to run all five, unprompted, on one brand-new artifact — plus apply this lesson's own re-check habit to the bundle. That is the fade the whole unit has been building toward.
Learning objective
Bloom's level: Create. Build your own versioned "re-check sheet" for your AI-use rules and materials, and then run the full inspect-and-signoff loop — independently, start to finish — on a brand-new apprentice-training artifact, treating everything this unit taught as a dated snapshot that will get superseded.
Plain language: Same as the code cycling every three years: build yourself a one-page "what to recheck, and when" sheet, keep last cycle's notes instead of tossing them, and then run the whole inspection — start to finish — on a brand-new piece of work, alone.
Standard: AIHC.1.D2 — "Version their artifacts, expect them to be superseded, and keep the inputs that produced them." Plain words: expecting this to get superseded, and keeping your old notes.
Your real artifacts today: your trust-rule sheet (Lesson 7), your labeling tags and footer convention (Lesson 8), your governance rules and account settings (Lesson 9), your bid-sheet habit (Lesson 10), your two-thread split (Lesson 11) — and a brand-new artifact you haven't touched with Claude before, for the capstone.
SSD cycle 1 — the code cycles; so does this
- SAY: This doc-set's own freshness rule states its facts should be re-fetched immediately on any of four triggers: a change to free-plan pricing, message limits, or included features; a new model becoming the free-tier default (as of this freeze, that's Claude Sonnet 5, with Claude Haiku 4.5 also free — Claude Opus 4.6 and Claude Fable 5 are paid-tier-only); a revision to the Consumer Terms, Privacy Policy, or Usage Policy; or a change to the minimum-age policy (doc-set frontmatter,
freshness_recheck_note). Real term: doc-set freeze ↔ trade version: the NEC revises on a three-year cycle — a panel wired to the 2023 code might not pass a 2026 inspection. You don't re-learn electricity when the cycle turns; you re-check what changed. Everything lessons 7–11 taught you is dated 2026-07-19 — frozen against sources fetched that day. It is not permanent. - SEE: A described code-cycle-style table: what changed between one edition and the next (which model is free, what's in Free versus Pro), laid out the way an NEC code-cycle summary lays out article-by-article changes.
- DO: Write your own one-page "re-check triggers" list: copy the doc-set's four triggers into your own words, and add one trigger of your own — for example, "when the training committee changes its own rules."
SSD cycle 2 — keep the old notes, don't toss them
- SAY: The standard's own second half matters as much as the first: "keep the inputs that produced them." Your trust-rule sheet, labeling footer, and governance rules from lessons 7–9 don't get thrown out when something changes — they get a version mark and a superseded status, the same way you keep last cycle's code book on the shelf next to the new one, because old jobs still get inspected against the code that was live when they were wired. Real term: versioning ↔ trade version: dated code books on the shelf, or a classic-rock remaster — the original mix and the newer remaster both exist, and you know which one you were listening to and why the new one has different liner notes.
- SEE: A described view of your three prior artifacts, each stamped "v01 — 2026-07-19," with a blank "v02" field next to each, waiting for the day something changes.
- DO: Add a version date and a blank "superseded by" field to each of your three prior artifacts — a light touch-up, not a rewrite.
SSD cycle 3 — assembling the master re-check sheet
- SAY: A trigger list scattered across five separate documents doesn't help you at 6 a.m. before a training-committee meeting. It needs to live in one place: one sheet, one version number, that points at all five prior artifacts and states, for each, what would force a recheck.
- SEE: A described one-page master sheet: five rows (trust rules, labeling, governance, bid-sheet habit, two-thread split), each with a "recheck if..." column pulled from cycles 1–2.
- DO: Build that one-page master sheet now, pulling in your cycle 1 triggers and your cycle 2 version marks.
Independent at-bat / CAPSTONE (fully unscaffolded — the whole loop, alone)
You've been handed a brand-new real artifact you haven't touched with Claude before — the year-end apprentice certification review packet. Alone, with no per-step prompts, run the full loop:
- Set your trust lane and reason for this new artifact (Lesson 7's rule sheet).
- Label what's yours versus Claude's as you draft (Lesson 8's tag system and footer).
- Check which policy layer applies, and whether anything in it should never be pasted in (Lesson 9's governance rules).
- Estimate before starting, and compare after (Lesson 10's bid-sheet habit).
- Decide one thread or two, and chain draft → critique → revise (Lesson 11's orchestration habit).
- Close with this lesson's re-check sheet: note which doc-set facts you leaned on, date them, and state what would make you recheck them.
Write up the finished packet plus a short note on all six steps — this is the unit's proof that the habits transferred to something none of the six lessons handed you in advance.
Exit ticket (Bloom's climb: Remember → Understand → Apply → Analyze → Create, objective level)
- (Remember) Name the four re-check triggers from cycle 1.
- (Understand) Why does "keep the old notes" matter even after something supersedes them?
- (Apply) A new model becomes the free-tier default next month. Which of your six-lesson artifacts do you pull off the shelf to recheck first, and why?
- (Analyze) In your capstone packet, which of the six steps took the longest — and what does that tell you about where your rules are still shaky?
- (Create — objective level) Produce your finished, versioned re-check sheet as a standalone artifact you could hand to the next training-committee member who wants to try this.
Graded against your own five prior artifacts, the doc-set's own freshness note, and your finished capstone packet — never against how complete the loop merely felt while running it.
Ledger write
ledger_append:
learner_id: L4-PUB-FRANK
lesson_id: L4-lesson12-d2-regeneration-capstone-20260719
standard: AIHC.1.D2
anchors_exercised_as_review: [AIHC.1.B3, AIHC.1.C1, AIHC.1.C2, AIHC.1.C3, AIHC.1.D1]
exit_ticket: {score: "", bloom_reached: create}
auto_mastery: "0.0 -> (projected ~0.50 — first dedicated lesson on this anchor; the code-cycle parallel is a direct, load-bearing transfer from thirty years of working against a revising code book)"
self_score: ""
calibration_gap: " — not computed until a real self-score exists"
journal_prompt: >
If the next training-committee member asked you what to check before trusting
any of this six months from now, what's the one page you'd hand them?
structure_used: "PBL — capstone"
referents_used: [electrical-trade code-cycle culture, classic rock — remasters/pressings (versioning point only)]
next_lesson_seed: "Unit complete for this learner at Band 1. A next unit would move Frank toward Band 2 (Governed Collaboration) on the same anchors, or open new anchors (A1/A2/A3/B1/B2 deepening) — not generated in this demo."
Rubric self-audit (R1–R13)
| # | Indicator | Verdict | Evidence |
|---|---|---|---|
| R1 | One Bloom's-leveled objective, named standard, plain-language too | PASS | Create-level objective stated technically and plainly; AIHC.1.D2 quoted verbatim with plain gloss |
| R2 | Every capability/limit claim traces to the doc-set | PASS | The doc-set's own freshness_recheck_note (frontmatter) is quoted/paraphrased directly, including the exact current model-availability facts (Sonnet 5 + Haiku 4.5 free; Opus 4.6 + Fable 5 paid-only) — no number or claim invented beyond what the doc-set states |
| R3 | 3–6 SSD cycles complete | PASS | 3 cycles, each SAY/SEE/DO complete, separate from the capstone at-bat |
| R4 | Each SEE ground-truth-verified, no strawman errors | PASS | The code-cycle table and version-stamp SEEs describe real, checkable bookkeeping moves; no invented product behavior |
| R5 | Every DO on real artifacts, free-tier only | PASS | Cycles 1–3 act on his five actual prior-lesson artifacts; the capstone acts on a real, new certification-review packet; no paid-tier feature invoked |
| R6 | Media doctrine honored | PASS | All SEEs are static described tables/sheets; no motion content needed for a versioning/bookkeeping point |
| R7 | Exit ticket 3–5 Qs climbing to objective level | PASS | 5 questions, Remember→Create, graded against his own artifacts and the doc-set's freshness note |
| R8 | Ledger write complete | PASS | Standard named, prior anchors credited as reviewed (not re-taught), auto/self marked , journal prompt in-register, all present |
| R9 | Scaffold with visible, near-total fade — genuinely independent capstone | PASS | Cycles 1–3 are short and tool-building only; the capstone at-bat gives him the six-step shape but zero per-step scaffolding text, and requires a brand-new artifact none of the prior five lessons prepared in advance |
| R10 | Referents elected, flavor-only, anti-stereotype clean | PASS | Code-cycle and classic-rock-remaster referents both used strictly for the versioning point, never substituting for the doc-set's own freshness-note grounding |
| R11 | Plain-language-first: every term gets analogy + real term | PASS | "doc-set freeze" and "versioning" each paired with the code-cycle/remaster analogies alongside the real terms |
| R12 | Non-replication | PASS | The capstone runs on Frank's specific five prior artifacts and a specific new certification-review packet — no other learner profile has this exact bundle to re-check |
| R13 | No deficit-framing, no fear-framing | PASS | The lesson frames superseding facts as a normal, expected feature of any live product (same as a code cycle), not a reason to distrust the tool or a mark against Frank for not having caught up sooner |
Escalation: all load-bearing indicators pass → auto-ship (per playbook §5 policy).