Lesson 12 — Regeneration: rebuilding your workflow when models or features change

Learning objective

(Bloom's: Create) Re-derive — not just patch — your claude.ai workflow (model choice, effort settings, standing instructions) the next time a new model ships or a feature changes, triggered by the doc-set's own model/cutoff facts, not a vague sense that "something's different."

Standard named: AIHC.1.D2 (Regeneration). Regeneration means renegotiating where the trust line and the workflow sit (P8) every time that line moves (X2) — the same X2 concept from Lesson 07, now applied to the workflow itself rather than to one claim.

Cycle 1 — The doc-set expects to go stale, on purpose

SAY — This very doc-set says so about itself: model names, cutoff dates, effort-tier names, and file/plan limits are "exactly the kind of fact that goes stale" and should be re-fetched "on a rotating cadence — weekly-to-biweekly" (doc-set frontmatter). That is a regeneration protocol, written down, not a vague worry.

SEE — A described excerpt of the doc-set's own frontmatter warning, annotated: "this is the doc-set warning about itself — the same discipline applies to your own workflow."

DO — Check today's date against the doc-set's stated freeze date (2026-07-19) and note how many days old the doc-set is right now.

⏸ Pause point. One staleness check done. Stop here if needed.

Cycle 2 — When the cutoff line moves, your trust posture moves with it

SAY — Recall Lesson 07: your trust posture depends on your model's cutoff [S15]. When a new model appears with a later cutoff — or an older one you're using turns out to be further behind than you assumed — the line from Lesson 07 has moved (X2), and needs re-checking, not re-assuming.

SEE — A described version of the S15 cutoff table with a new hypothetical row added below the current bottom row, arrow annotated: "when this table gets a new row, re-run Lesson 07 Cycle 1."

DO — Write yourself a one-line standing reminder (in a Project instruction or a personal note) to re-check the model menu's cutoff whenever you notice a "More models" [S14] entry you haven't seen before.

⏸ Pause point. One standing reminder written. Stop here if needed.

Cycle 3 — Don't keep the old instruction; re-test it

SAY — Your Profile Instruction (Lesson 09) and your Project instructions (Lesson 11) were written against whatever model you were using at the time. A new model may not need the same phrasing, or may need different phrasing, to produce the same behavior. Referent (true-crime podcasts, flavor only): a cold-case investigator doesn't reuse an old suspect list unchanged once new forensics ship — they re-run the analysis with the new tool.

SEE — A described side-by-side of Priya's real Profile Instruction text with a blank field labeled "re-test date: ___."

DO — Pick one of your real standing instructions (from Lesson 09 or 11) and run one test prompt against your current model to confirm it still produces the behavior you wrote it for.

⏸ Pause point. One instruction re-tested. Stop here if needed.

Cycle 4 — Effort and thinking settings aren't "set once" either

SAY — Effort tiers vary by model: verbatim, the doc-set names "Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6" as carrying effort-tier controls at fetch time [S14], and "extra high ('xhigh')" as "available on Opus 4.7 and newer" [S14]. A habit of always picking one tier can quietly leave capability on the table once a new tier ships on your model — or apply to a model that was never in that stated list in the first place.

SEE — A described model menu with effort-tier options listed, one greyed out on an older model and available on a newer one.

DO — Check which effort tiers are actually available on your current model right now, per the menu [S14], and confirm whether your usual default is still the best fit.

Independent at-bat

Unscaffolded: pick a real future trigger — a new model appearing in "More models," or a support-article fact you're citing turning out to be old — and walk the full loop yourself: recheck the cutoff → reconsider your trust posture (Lesson 07) → re-test your standing instructions (Lessons 09/11) → recheck effort tiers → update your own notes.

Exit ticket (climbing to Create; graded against the doc-set)

1. (Remember) Name the four things the doc-set's own freshness note says to check first. [model names/cutoff dates, effort-tier names, file-size/count limits, plan gating]
2. (Understand) Why doesn't a Profile Instruction that worked perfectly on one model get a free pass on the next one?
3. (Apply) You notice a model you've never seen before in "More models." What are the first two things you check before using it for real work?
4. (Apply) Per S14, "xhigh" effort exists on Opus 4.7 and newer. If you've been working on a model not on that list, what does that tell you about whether you've had access to it, and what should you check now?
5. (Create — objective level) Write your own one-page "regeneration checklist" — the exact steps you will personally run every time a model or feature changes — using at least three specific facts from this lesson.

Ledger write

ledger_write:
  learner_id: L3-CONS-PRIYA
  lesson_id: L3-12-D2
  standards: [AIHC.1.D2]
  tags: [P8, X2]
  exit_ticket:
    score: 
    bloom_reached: 
  auto_score: 
  self_score: 
  calibration_gap: 
  journal_prompt: >
    Look back at Lessons 07 through 11: which of those habits (trust posture, provenance
    marking, confidentiality policy, project structure) would silently break the next time a
    new model ships, if you never re-tested it? Pick one and say how you'll catch it.
  structure_used: PBL
  referents_used: [true-crime-podcasts]
  next_lesson_seed: "sequence complete for this cell; regeneration checklist becomes the standing artifact the ledger's freshness beat (Playbook §10) would re-surface to Priya on its own cadence."

Rubric self-audit (R1–R13)

Escalation verdict: all load-bearing indicators PASS → clears; auto-ships.