Assessment as Automation

The economics flipped while nobody renamed the activity

Lesson 1.2 taught the four assessment artifacts as careful, cited work — and they are. What has changed is what they cost. An agent pointed at a legacy repository produces the inventory, the dependency map, the current-state table, and a disposition-candidate list in hours. That is not a smaller version of the old three-week consulting engagement; it is a different kind of thing, and it deserves a different operating model:

OLD: assess once, at program start, expensively -> decisions age against a
     snapshot that is stale by phase 2
NEW: assessment is a PIPELINE -- re-run it before every disposition decision,
     after every major phase, and on a schedule, because it costs an
     afternoon and cites its evidence

The four artifacts and the two quality gates (every claim cited, every metric a number) do not change. What changes is the tense: “the assessment” becomes “the latest assessment.”

Prompt first: the standing assessment

You maintain the standing assessment for this codebase. Re-run the four-artifact
assessment (current-state table, countable weakness list, success metrics, risk
register) and DIFF it against the previous run in assessment/2026-06.md:
- What improved, with the commit evidence
- What regressed or newly appeared
- Which weaknesses the current phase was supposed to retire - did it?
Write the result to assessment/2026-08.md in the same format.

The diff is the point. A standing assessment that tracks its own deltas becomes the program’s honest scoreboard: Lesson 1.4’s roadmap tied phase 3 to retiring specific weaknesses — the frozen runtime, the zero test coverage — and the re-run says whether it actually did.

What cheap assessment does to the disposition calculus

Here is the subtle 2026 shift, and it is not the one most people quote. AI made building cheap — everyone sees that. It also made extending cheap: agent-assisted comprehension and refactoring of legacy code puts the “extend” option back on the table for systems that a 2023 assessment wrote off as too tangled to touch. The squeezed option is buy: COTS licensing and low-code platforms now compete against custom builds that cost days and extensions that no longer cost archaeology.

Two consequences for Lesson 1.3’s framework — the framework itself survives untouched:

1. Re-run dispositions when the input costs change. A “replace” verdict from two years ago rested on “remediation is prohibitively expensive.” That premise may simply be false now. The attribute matrix and feature-parity disposition table are exactly as valid; feed them current numbers.
2. “Too hard to assess” is an obsolete verdict. The mystery subsystem nobody understood — the one every roadmap routed around — costs one agent-afternoon to map. Route through it.

The other half of readiness: your data

One assessment target deserves explicit mention because every AI ambition on the roadmap quietly depends on it: the data estate. Module 3 taught contract-driven migration — recipes, dictionaries, control tables, manifests. Notice what that discipline produces: catalogued, contract-validated, provenance-tracked data. That is precisely the substrate LLM-driven tools need — an agent can answer questions against a governed lake with a dictionary; it can only hallucinate against a file share of ambiguous CSVs. When the standing assessment inventories systems, have it inventory data readiness too: which datasets have contracts, which have owners, which are still folklore.

Key takeaway

Assessment became a pipeline: re-run it before every decision, diff it against the last run, and let it keep the roadmap honest. Feed the unchanged Lesson-3 framework current economics — build and extend got cheap, buy got squeezed, and “too hard to touch” retired as a verdict. And assess the data estate alongside the systems, because everything in the next two lessons feeds on it.