Keep, fix or retire

By day 90, things are running that weren't there on day 0. A redesigned workflow, a shared template, a feature a vendor switched on, perhaps a small build. Some of it is doing exactly what it should. Some of it is quietly costing more than it gives. This lesson gives every one of them a decision, using the review you set up in module 7.

Abandoned isn't retired

Most AI work doesn't end with a decision. It just stops.

Stopping isn't the problem. Plenty of AI work should stop. The problem is what's left behind when it stops without anyone deciding. Its data stays wherever it was stored. A report somewhere still pulls from it. The people who relied on it build a workaround and stop mentioning it. Nobody owns any of that, because officially it isn't there.

Three questions, fifteen minutes

When a review date arrives, the owner answers three questions, in fifteen minutes or less. It's the pilot kit's review triage, and day 90 is the first time you run it on everything at once.

• Is it still used? Actually used, by the people it was for. Seats that are paid for and idle don't count.
• Is it still safe? Still inside the data map and the stakes rules, including after any change the vendor made since you last looked.
• Is it still worth what it costs? Its full running cost, set against what it frees at the bottleneck or the cost it removes.

Three yeses: keep it, and set a new review date. Any no: fix it, or retire it. Fixing gets its own date, so a fix that doesn't happen comes back round. Fifteen minutes is enough because the questions are narrow. If an item needs longer, that's a finding in itself.

Retiring is a decision too

Retiring something properly covers three things, and none of them is the off switch.

• Its data. Export what you need to keep, then delete the rest, as the data map says. Check the vendor has deleted its copy too.
• Anything that depends on it. Reports, workflows, other tools and agents that read from it or write to it. Move them, or switch them off on purpose.
• The people who relied on it. Tell them, with a date, and give them the replacement before the old thing goes.

Then take it off the AI list, with the date it was retired. A list that only ever grows isn't a list anyone trusts.

Run the review

Everything from your AI list is here, with the owners you named in module 7, and the build from module 6 if it was approved. Shared and high-stakes items come first, because they're the ones that must have an owner. Anything that ran without one is flagged: that's one of the results that counts against the framework.

Findings go on the friction list

Every review turns something up. A retention setting that drifted, a team still re-keying data the tool was meant to handle, a price that rose at renewal. Write it down as a finding, and it goes on the friction list with the status “new”. That's how Own feeds the next loop: the friction list is where lesson 4 looks for the next bottleneck.

The same three questions work on rules as well as tools. The approved tools list, the data map and the spending limits each deserve a review date. A rule nobody has looked at in a year is just as likely to be holding the work back as a tool nobody uses.