Chapter 14 · Reps

Maintenance and the Lifecycle of Things — Reps

← Back to Chapter 14

Chapter 14 — Reps

This week the reps are the graded lab. There is no separate project. Each rep is a small, runnable piece of a real model lifecycle and maintenance plan; the capstone rep assembles them into one deliverable you could hand to a team — and into the governance section of your Week 16 final.

Ground rules

  • Type it yourself. Do not paste the starter files in and call it done. Re-create the structure by hand; you remember what your fingers built.
  • Run everything. Every command in this file is meant to execute. If it errors, that is a rep too — debug it.
  • Predict before you measure. Before you run the triage scorer or the drift check, write down what you expect the output to be. Then compare. The gap is where the learning is.
  • AI policy (Phase 2 — agentic): AI is part of the work. Use a copilot or agent freely, and keep an honest agent-log.txt: what you delegated, what it did, where it was wrong, and where you intervened. Several reps are built so an agent cannot finish them alone — the sign-offs, the risk acceptances, and the regulatory classifications are your accountable judgments. Never let the agent sign.
  • Cite live, hedge dated. Any model retirement date, price, or regulation date you state must be pinned to a source and dated “as of 2026.” Re-verify before you rely on it.

Work from this chapter’s code/ starters. Submit a public GitHub repo with your work plus a LIFECYCLE_PLAN.txt (the capstone). See Appendix A, Appendix B, and Appendix C.

Reps 1–3: Patch and Change Discipline

Rep 1 — Triage a CVE feed deterministically

Run the reference scorer against the sample feed:

python3 code/patch_triage.py code/cve_feed.json

Predict first: which of the five CVEs lands in EMERGENCY, and why? Write your guess, then run it.

Reflection (write it down): CVE-2026-10733 is CVSS 9.1 and actively exploited (KEV) but not internet-facing, while CVE-2026-10477 is only CVSS 7.5 but internet-facing. Defend the scorer’s ordering — or argue it is wrong for your hypothetical estate. There is no single right answer; there is a defensible one.

Rep 2 — Triage the same feed with AI, then judge the gap

Paste the same cve_feed.json into a copilot and ask it to rank the advisories and recommend a patch schedule.

Reflection: Where did the AI’s ranking differ from patch_triage.py? Did it invent a downstream dependency or risk that is not in the data? Did it miss the has_fix: false case (the one you should mitigate, not rush to patch)? Write three sentences on which ranking you would actually act on and why the human owns the schedule.

Rep 3 — Make a change reviewable and reversible

Write a one-page change record for applying the EMERGENCY patch from Rep 1. It must answer: who, what, why, when, how to roll back, and who accepted the risk for any CVE you chose to defer.

Reflection: Which field is the one an AI must never fill in? (Hint: it has a human name and a date.) Explain why that signature is the line between a decision and an accident.

Reps 4–5: Configuration Drift

Rep 4 — Detect drift with a dry run

Using any small Ansible playbook (or write a five-task one), run a no-change dry run:

ansible-playbook site.yml --check --diff

If you have no playbook handy, write one that ensures a package is installed and a config file has specific contents, deliberately change the file on disk, then run --check --diff and watch it report the drift without fixing it.

Reflection: Explain every line of the diff. Why is --check (a dry run) the right default for detecting drift before you remediate it?

Rep 5 — Drift that changes model behavior

List three configuration changes in an AI serving stack that would alter model output or throughput while leaving the system “healthy” by traditional metrics (think: a quantization-library version, a serving-engine flag, a GPU driver bump).

Reflection: Why does configuration management for AI have to version the whole behavior-producing stack, not just the application code? Connect this to the prompt-versioning trap from §14.5.

Reps 6–8: The AI Asset Lifecycle

Rep 6 — Fill out a governance-grade model card

Copy the structure of code/model_card.yaml by hand for a real (or realistic) model you could run. Fill in measured evaluation numbers if you have them, or mark them clearly as targets. Pin the exact base-model ID — never the marketing name.

Reflection: Which fields would block promotion if left blank or failing? Why is human_label_agreement (validating the judge against humans) on the card at all?

Rep 7 — Build a minimal AIBOM and diff the formats

Produce a tiny CycloneDX ML-BOM (v1.7) for a small AI service — list the weights, the dataset reference, and at least two dependencies. Then sketch the same inventory as an SPDX 3.0 (AI + Dataset profile) view.

# If you have the CLI, validate your CycloneDX file:
cyclonedx validate --input-file aibom.cdx.json

Reflection: “An AIBOM is an ingredients label for an AI system.” When a base model gets a deprecation notice, how does having this inventory change your day versus not having it?

Rep 8 — Write and dry-run a deprecation migration runbook

Start from code/model-migration-runbook.txt. Pick a real base model with a published retirement (verify the live date — e.g., as of 2026 Anthropic listed retirements such as Opus 4.1 on 2026-08-05; confirm before relying on it). Run the Step-0 inventory grep against a sample repo:

grep -rn "claude-opus-4-1\|claude-sonnet-4-0" . \
  --include="*.py" --include="*.yaml" --include="*.tf" --include="*.json"

Reflection: Why do you hunt for fine-tuned derivatives first? Explain the “inference-only until the base retires, then irrecoverable” trap in your own words.

Reps 9–11: Governance Frameworks

Rep 9 — Map one system across all three frameworks

Take the model from your Rep 6 card. Write one paragraph each placing it under (a) NIST AI RMF — which of Govern/Map/Measure/Manage your card’s fields support; (b) the EU AI Act — your honest risk-tier classification; (c) ISO/IEC 42001 — one AIMS control it would satisfy.

Reflection: These are layers, not competitors. In one sentence each, say what each framework gives you that the others do not.

Rep 10 — Track the moving regulation

Find the current status of the EU AI Act high-risk obligations as of today. State the statutory date (Aug 2, 2026), the Digital Omnibus deferral (to Dec 2, 2027 for Annex III), and whether the Omnibus has been formally adopted yet. Cite your source and date your answer.

Reflection: Why is “the regulation is fixed” a maintenance bug? Describe the recurring task you would schedule to keep a governance program current — and connect it to how you re-check a CVE feed.

Rep 11 — Capacity and retirement

Look at your registry (real or hypothetical). How many model versions are you keeping? For each, state: live, rollback-reserve, or cast away. Set a retire_after date for everything in the last bucket.

Reflection: Tie your decision explicitly to Ecclesiastes 3:6 — “a time to keep, and a time to cast away.” What is the cost of keeping a version past its season (disk, catalog clutter, audit surface, confusion about what is live)?

Done? One Last Thing.

Capstone rep — write LIFECYCLE_PLAN.txt.

Assemble the pieces into one coherent plan for a single AI service of your choosing (the ministry RAG summarizer in the starter is fine). It must contain, in order:

  1. A patch/vulnerability policy — your triage rule and tiers, and who signs risk acceptances.
  2. A change & configuration policy — how changes are reviewed/reversed, and how you detect drift (including AI-behavior drift).
  3. The asset lifecycle — the five stages, the gate at each promotion, and what must pass. Reference the Model Lifecycle Board you used on the chapter page.
  4. The governance artifacts — a completed model card, a minimal AIBOM, and where the immutable audit trail lives (WORM).
  5. The framework map — NIST RMF function, EU AI Act tier (dated, with current-status note), ISO 42001 control.
  6. A deprecation/retirement plan — the migration runbook, the derivative-first rule, and a retire_after date for everything past its season.

Close with a short theological footnote in your own voice: tie the time to keep and a time to cast away (Ecclesiastes 3:1, 3:6, ESV) to one concrete retirement decision in your plan — what you are casting away, on purpose, before the season forces it. Make it apt, not bolted-on.

This document is your graded deliverable and the seed of your Week 16 capstone governance framework. Do not throw it away when you submit it — you will extend it.

Up next: Chapter 15 — AIOps and Autonomous Operations: How Much May We Entrust? Then begin your final/capstone prep (Chapter 16).