Reference data is easier to maintain on the way in than on the way out. When a bank opens an account, launches a product or adds a code required by a live process, somebody notices if the record is missing. Work stops, a queue grows or a client waits; the gap has a habit of finding its owner. The same does not happen when a product is retired. Its rule may remain in the spreadsheet long after the activity it described has gone, and no daily failure points to it.

That leaves the least comfortable sort of data problem: rows which nobody can quite defend and nobody wants to delete. They are kept because removing a rule can have a consequence, whereas keeping it usually has none that can be seen at once. The rule set gradually ceases to describe the business, but it still looks complete. It is a blind spot rather than a backlog; a backlog is work that has been noticed and deferred, while a blind spot has not yet become work at all.

I am aware of a globally significant bank where account-opening rules are maintained in a spreadsheet. The file does useful, essential work, as such files often do, but it contains rows for products which have long since been retired. The spreadsheet or indeed the process have not failed, rather the bank has changed and it has not kept up with new ways.

The cost appears later and in fragments. People who understand the old rules become the route through a problem, which creates key-person risk. A team working from an obsolete instruction may spend time investigating a set-up that should never have been made. In practice, correcting a wrong account configuration can take longer than working around it: a new account is opened and the wrong one is expired. The individual cases look manageable; the pattern does not receive the same attention as a broken critical path.

This is why the preventative case has been hard to make. A programme to review every old rule by hand sounds like tidying up, and tidy-up work competes badly with the work that must be done in the next three months. The future cost is real enough, but dispersed; the immediate effort is visible and concentrated. Migration teams know how the calculation ends, since they often inherit the archaeology, but by then the choice has already been made for them.

So what could AI do?

The useful task is more specific, and simpler, than asking a model to clean the data. It could read the rules directly where they are kept, compare them with the products, accounts and processes available, and isolate the places where the two no longer agree. It could then assemble a proposed retirement in writing: the row in question, the evidence that live activity no longer supports it, and the reason for asking an expert to look.

That changes the economics of the work. Instead of asking specialists to search a large rule set for possible decay, the bank could ask them to judge a smaller number of documented proposals. The model does not establish that a row is obsolete; it lowers the cost of finding the rows that deserve a proper decision. Where the proposal is wrong, the evidence should make the mistake plain before anyone removes a rule.

The decision remains with the person who understands the business. They may confirm a retirement, reject it or ask for more evidence; in each case the decision records who made it, when and why. That record is useful in its own right. It leaves the rule set closer to the business and gives the next person something better than a spreadsheet full of inherited caution.

The case for this work is not that every old row is dangerous. Some rules are rarely used because they are meant to be. Nor does a model make a difficult retirement decision routine. It can, however, make it realistic to look before a migration, a departure or a failed set-up forces the organisation to look.

What evidence would make you comfortable signing off the retirement of a rule before it causes a failed set-up? Tell me in the comments.