Modernization OS

The playbook, as something you run.

Runs in your reporeads your actual code, not a description of it
Writes real artifactsa scorecard, a plan review, a runbook, a rollback plan
Remembers for monthsa state file that outlives the team that started

Version 0.1.0, beta. MIT licensed.  $1.6T platform · $4.5B a day · 36-month program · 12+ weeks in production parallel.

What it contains

Four skills. Five artifacts.

Each asks one question and leaves you holding a document. Run them in order, or jump to the one you need.

Orient
modernize
Where does this program stand?
STATE.md
→
Understand
readiness
Can we defend a date?
readiness.md
→
Challenge
plan-review
What kills this plan?
plan-review.md
→
Execute
cutover
Is this go-live survivable?
cutover-runbook.md
rollback-plan.md
It can say noAsk for a runbook with nothing proving the new system matches, and it declines
It arrives having read the autopsiesEight public failures with costs and sources, matched to the line in your plan
It checks the story against the systemHunts the rules hiding in spreadsheets and the components nothing can observe
It outlives the people who start itA record of what was decided, by whom, and what is still open
The criteria

Twelve categories. Five block a date.

Scored red, amber or green, never averaged into one number. Green on ten and red on two is one bad weekend from being a case study.

Five that stop a date
01
Knowledge of current behavior
Nothing to be correct against when this is red
03
Data and semantic parity
Matching values prove nothing when this is red
04
Evidence that the new system matches
No date is defensible when this is red
05
Cutover and reversibility
Being wrong becomes unbounded when this is red
08
Accountability
The gate is decorative when this is red
Seven that shape the profile
02Access to the people who know
06Cost realism
07Scope discipline
09Retained ownership
10Target architecture justification
11Discipline around AI use
12Cost of not acting
What you end up holding

A real assessment, of a real program.

Day one of the flagship platform, before any work began. My judgment of a program I led, not output from the tool.

docs/modernization/readiness.md $1.6T asset-management platform · day one
3 red1 amber 1 greenno defensible date

A date exists and it predates the scope. What this program has is the two things that cannot be bought later: one named person accountable for correctness, and a book that can be split by account and fund group. Either the date moves or the bar does.

01Red
Knowledge of current behavior
No living person fully understood the legacy logic, and no documentation described it. Thirty years of rules in stored procedures and overnight batch.
03Red
Data and semantic parity
Field-level meaning was undocumented across the core and the 35+ user-developed applications hanging off it.
04Red
Evidence that the new system matches
The parity harness did not exist. It had to be purpose-built before any claim of correctness could be made.
05Amber
Cutover and reversibility
Traffic could be split by account and fund group, so incremental was genuinely available. Rollback was not yet designed.
08Green
Accountability
One named person accountable end to end for the module, distinct from the people rewarded for shipping.

Every red above was cleared: over 50% of the platform migrated, zero loss of trading accuracy. Archaeology with every rule ratified by a human, a parity harness reconciling every record, 12+ weeks in production parallel.

How it was done →
The vocabulary

Two things the industry has not named.

Both came out of running the work rather than writing about it. Both replace a metric or a practice that is standard and quietly misleading.

Distinct unresolved root causes
instead of break counts
One rule difference can produce a hundred thousand breaks that all close at once, so a falling break count looks like progress and is not. Counting distinct unresolved causes gives a number that is small, honest, and hard to game. A program tracking breaks will declare victory around week three of a parallel run and be wrong.
Structural reversibility
instead of a rollback procedure
If migration moves populations incrementally, going back is a routing change on one group, using the mechanism you already use daily. That can be rehearsed before every cutover. A documented restore-from-backup cannot be rehearsed at realistic scale, which is why big-bang rollback plans stay hypothetical until the night they are needed.
Install

Two ways in.

Both give you the same thing. Copying lets you read the instructions first, which is reasonable for something about to review your architecture.

install as a plugin
# add the marketplace, then install by name
> /plugin marketplace add nikjain15/lossless-modernization
> /plugin install modernization-os
✓ modernization-os v0.1.0 · 4 skills ready
# then just ask
> where do I start with this modernization?
or read it first, then copy
# reasonable, for something about to review your architecture
$ git clone https://github.com/nikjain15/\
lossless-modernization.git
$ cp -r lossless-modernization/plugins/\
modernization-os/skills/* .claude/skills/
✓ 4 skills copied · yours to fork

Corrections are worth more than additions: if a criterion here is wrong, say so on GitHub.