The AI Use Case Register and Model Inventory: What Each Holds
A use case register lists what a firm is using artificial intelligence for, one line per use. A model inventory lists the components inside those uses, so a single register line can hold nine of them. The register carries who approved a use and who answers for it; the inventory carries what is actually running. Completeness measured on the day of sign-off is the number that says whether either is real.
Both of these things are lists, and a list is only ever as good as the day somebody wrote it. Everything in this guide comes out of that one sentence. An entry is a set of statements that were true once. A register is a count that was right once. So the only useful question to ask about either of them is how quickly it stops being right, and what interval of re-checking a firm can afford. At Sumeru Bank Limited, invented, that question turns out to have an exact answer, and the answer is stranger than most people expect when they first meet it.
What is a use case register, and what is it a register of?
The point is easiest to see in a household rather than a bank. Somebody sits down to write out everything the household pays for every month. One line says the school run. The school run line quietly contains a car, a fuel card, an insurance renewal and half of somebody's morning. The list was never meant to be a list of car parts, so nobody writing it thinks that is a problem. The list was meant to name the things the household does. Anybody in the house can read it and recognise the household in it.
A use case registerThe list of the uses a firm has, one line per use rather than one line per component. is that list, written for a firm and written about the uses it has put artificial intelligence to. One line per use. The unit of a register is the use, not the component and not the model, and every confusion that follows on this subject comes from somebody quietly swapping those units. At Sumeru Bank Limited the whole retail personal loan intake and decision chain is one line. The chain takes an application started on a handset and returns a decision, and in one steady month it took 10,000 applications and carried 8,600 of them to a decision. Nine separate components sit inside it. The chain is still one line.
Four other lists get brought to meetings and called a register, so saying plainly what a register is not is worth the space. A register is not a list of models. The model inventory set out below is a different artefact. A use built inside a spreadsheet raises no invoice and would never appear, so a register is not a list of software the firm has bought either. A workflow records what happened to a request and a register records what is running now, so a register is not an approval workflow. A project ends and a use case does not, so a register is not a project list: at this invented bank the intake chain went live in month 4 and the project closed, and the entry describing it has to stay true for as long as the chain keeps deciding files.
What does one line of a use case register describe?
What is a Model Inventory, and what does it count instead?
The second list goes underneath the first. A model inventoryThe list of the components inside those uses, which is a longer list of smaller things. counts components rather than uses: every fitted model, every written rule set, every reading step, each on its own row. Back in the household, this is the list of the car, the fuel card and the insurance renewal. The inventory is longer and duller, and it is the only one of the two that can say what is actually running at four o'clock on a Tuesday.
At Sumeru Bank Limited the two lists came out at 14 and 45. Fourteen uses in the register after the month 10 sweep, and 45 components in the inventory underneath them at the month 12 validation, an average of 3.2 components a use. Neither list can answer the other's question, and a firm holding only one of them has a blind side it usually cannot name. Held alone, the register says what was approved and who answers for it, and cannot say what is running. Held alone, the inventory says what is running, and cannot say what any of it is for or who agreed to it.
A register has 14 lines. How many components does that say anything about?
Why can one entry hold nine components, and why is that not a fault?
People meeting these two lists for the first time usually want them to match, and when they do not, the instinct is to call the register wrong. The register is not wrong. The register is answering a different question at a different grain, and the mismatch is the most informative thing on either list.
Look at what a filled entryOne line of the register, being a set of statements about one use that were true on a stated date. actually looks like at this invented bank. Entry 1 says the use decides retail personal loan applications, that it serves retail credit, that Revathi Balan is accountable for it, that it was built rather than bought, and that nine components sit inside it. Underneath, in the other list, those nine have a row each: an identity match step and four other written rule sets, and four components that learn from data. Five of the nine learn and four are rules somebody wrote. The register line states that the bank decides loans this way; only the inventory rows reveal that a written rule, not a fitted model, touches every single file.
Now the shape of the thing. Across the 14 uses the average is 3.2 components. Entry 1 holds 9, or 2.8 times that average. The other 13 entries hold 36 components between them, an average of 2.8 each. Components cluster in the one or two uses that are really systems rather than steps, so an average component count describes almost none of the entries. This is the same lesson the household list teaches: the school run line and the streaming subscription line look identical on the list and are nothing alike underneath. A register that carried a size against each line would be a better register, and almost nobody builds one that way.
What does one entry have to carry, in twelve numbered fields?
An entry is only worth writing if somebody can be refused an answer by looking at it. Sumeru Bank Limited settled on twelve numbered fieldsOne of the twelve statements an entry carries. Each exists because a question would otherwise have no answer., and the numbering matters at that bank because every later record cites a field by its number rather than by quoting it.
Field 1 is what the use case does, in one sentence somebody outside the team can read. Field 2 is which business area it serves. Field 3 is the named accountable person. Field 4 is built or bought, and from which supplier where it was bought. Field 5 is the components inside it, and whether each learns or is written. Field 6 is what data it consumes and on what basis. Field 7 is what its output does and to whom. Field 8 is whether a person stands between the output and its effect. Field 9 is the date it was approved and by whom. Field 10 is the date it was last reviewed and by whom. Field 11 is the route back to a manual process and the date it was last rehearsed. Field 12 is the date of the next re-approval. Each of the twelve exists because a question somebody will eventually ask would otherwise have nowhere to land, and a thirteenth field that answers no such question is furniture.
Why does field 3, the named person, decide whether the other eleven are true?
Think about a shared flat where the electricity bill arrives addressed to nobody in particular. Everyone assumes somebody is paying it. The bill is a real document, correctly addressed, entirely true, and it will sit on the table until the supply is cut. A register entry with no name in field 3 behaves exactly like that bill.
The reason is not moral but mechanical. Eleven of the twelve fields are statements that go stale, and field 3 is the only field that names the person whose job it is to notice. Field 10 says the entry was last reviewed on a date; somebody has to be the one who reviews it. Field 6 says what data the use consumes; somebody has to notice when that changes. Field 11 says a route back exists; somebody has to be the one who rehearses it. Take the name away and every one of those eleven statements is still perfectly readable and nobody is late.
At Sumeru Bank Limited only 6 of the 14 uses carried a named accountable person, or 42.9 per cent. Inside the register itself the figure is better, 6 of the 9 entries and 66.7 per cent of them, and every one of the five uses the sweep found unlisted had nobody named at all. The overlap is not a coincidence and it is worth saying why. Both come from the same missing step, so a use nobody registered is a use nobody named: somebody solved a real problem and no part of the arrangement asked them to write down whose problem it now was.
Why is field 11, the route back, the field that is always missing?
Here is the finding that says most about how registers actually get filled in. At the month 12 validation, Neelima Rao in the risk function went through the 9 registered entries and found all twelve fields complete for 2 of them, being 22.2 per cent. Field 11, the route back and the date it was last rehearsed, was absent for 7 of the 9, being 77.8 per cent.
Put those two numbers next to each other now. Together they say something neither says alone. Nine entries, two complete, so seven were incomplete. Seven were missing field 11. Field 11 was not the commonest gap in this register, it was the whole of the gap: every entry that failed to be complete, failed on that one field. Ten fields out of twelve were filled everywhere, and one field held the entire shortfall.
Why that field and not another? Because eleven of the twelve can be written from what somebody already knows. The use, the area it serves, the accountable person, built or bought, the data it consumes: a person can type all five answers in an afternoon from what is already in their head. Field 11 is the only field whose honest answer requires the firm to have built something first, and then to have run it while nothing was wrong. A route back that has never been rehearsed is a document, and writing a date into that field when no rehearsal happened is the one way to make a register worse than empty. So it stays blank, and the blank is the most truthful thing in the entry.
Which field was missing from most entries at this bank, and why that one?
How to Create an AI Use Case Register from nothing?
Most firms meeting this for the first time are not maintaining a register, they are creating one from nothing, and the order they choose decides whether anybody ever uses it. There are five steps and they only work in this order.
First, a sweep for what is actually running. Nothing can be listed that has not been found, and the list a firm starts with is always shorter than the truth. Second, one line per use, in language somebody in that business area would recognise as a description of their own work. Third, a name against each line before anything else proceeds. Fourth, each line broken into its components, and the second list begins there. Fifth, and only fifth, the dates. A list with no names has nobody to ask about the components, and a list with no components has nothing to put a date against. So names come before components, and components before dates.
Starting from nothing: does the register or the inventory come first?
How to Build an AI Model Inventory underneath it, and which comes first?
The inventory is built downward from the register, one entry at a time, and the question asked of each entry is simply this: what are the separate things inside this that could be changed on their own? The test is worth stating carefully. No other wording produces a stable component count. Not what could be described separately, and not what a supplier calls a product. A component is whatever could be changed on its own, on a Tuesday afternoon, without anything else in the chain being touched.
Applied to entry 1 that test gives nine rows, and every one of them earns its row: the identity match step, the liveness check, the document classifier, the field reading step, the income corroboration rules, the scoring model, the fraud rules, the drafting assistant and the workflow router. Each row carries a description of the component, whether it learns from data or was written by somebody, and where it runs. At Sumeru Bank Limited the whole exercise came to 45 rows across the 14 entries. The inventory answers what is running and the register answers what it is for, and the reason to build them in that order is that only the shorter list can be argued with by the people who would notice if it were wrong.
One warning about the count itself. Forty five is not a measure of how much a firm is doing, and reading it as one is how inventories become competitions. A firm that writes down every rule separately and a firm that groups them will produce very different counts for identical work. The number is genuinely for the ratio: 45 over 14 is 3.2, and a ratio near 1.0 means somebody has quietly written a component list and put a register heading on it.
How complete is a register on the day it is signed off?
Completeness on sign-off day is the question almost nobody asks, and it decides whether either list is worth keeping. Sumeru Bank Limited signed off its register in month 6 holding 9 entries. In month 10, Ashok Pillai in technology risk ran a sweep and found 14 uses actually running. Every one of the five the sweep added had already been running on the day the register was signed. So the register was 64.3 per cent complete on its own sign-off day.
Hold on to why that reading is the useful one. CompletenessEntries held against uses found by a sweep, measured on a stated day. measured on any later date mixes two entirely different problems: things the firm never found, and things that have started since. On day one nothing has had time to appear, so day one completeness is the only reading that isolates discovery. Every reading after it is discovery and decay added together, and a number made of two things moving in the same direction does not show which one to fix.
And 64.3 per cent on sign-off day is an ordinary finding, not a scandal. The figure is what a first attempt looks like at a mid-sized firm where several business areas solved several problems in the same year. The bank did not conceal anything, the sweep worked, and the number went to 14 of 14 four months later. A register that claimed 100 per cent on day one without a sweep behind it would be the finding worth worrying about.
Why measure completeness on the day of sign-off rather than a year later?
How fast does a register stop being true once it is signed?
One rate decides everything here, and at Sumeru Bank Limited that rate is its own observation rather than anybody's law: about one new use case starts every month. Where the figure comes from is plain. Two new uses appeared between the month 10 sweep and the month 12 validation, and the register read 14 of 16 and 87.5 per cent on that later date.
Now the arithmetic, and it is worth doing slowly because the shape of the answer is not obvious. The moment a sweep closes, the register carries zero unlisted uses. One month later it carries one. Six months later it carries six. So across an interval of m months it carries m over 2 unlisted uses on average, and m unlisted uses on the very last day. The interval gives two different completeness figures for the same firm: an average of 14 over 14 plus m over 2, and a worst reading of 14 over 14 plus m. The decayThe fall in completeness between one sweep and the next, driven by the rate at which new uses start. is not a slow drift discovered later, it is fixed the moment somebody chooses the interval, and it can be worked out before a single sweep is ever run.
Before the control below moves: a firm sweeps once a year and one new use starts a month. What is the average completeness across the year?
Move the sweep interval, and watch the two readings separate
One control: the number of months between one deliberate search for unlisted uses and the next. Two consequences redraw on the same scale, the average completeness across the interval and the worst reading on the day before the next sweep, and a third marker moves with them to show the identity. The default is twelve months, the interval a firm schedules without thinking about it: an average of 70.0 per cent and a worst reading of 53.8 per cent, so a register described all year as reliable is right about half of the uses on its worst day. At six months the same two readings are 82.4 per cent and 70.0 per cent. The lime marker moves with the control: it sits at twice the chosen interval on the average line and it never leaves the height of that interval's own worst reading.
Educational illustration. Figures are the invented bank's own and describe one deployment. Held constant: 14 listed uses at the close of a sweep, and one new use starting a month, an observed rate at Sumeru Bank Limited rather than a law about firms. A firm where uses start faster decays faster on exactly the same shape of curve. The intervals offered here are choices a firm makes, not anything required of anybody.
How is a sweep interval chosen, and what are its two readings?
A sweep intervalThe number of months between one deliberate search for unlisted uses and the next. is a decision, and like every decision it has a price. Sweeping monthly costs somebody a week of work twelve times a year and holds the register near 96.6 per cent on average. Sweeping every two years costs almost nothing and holds it at 53.8 per cent on average. Neither is right or wrong in itself; what matters is that the firm knows which number it has bought.
The trap is that every interval produces two numbers, not one, and firms quote the flattering one. At twelve months the average reading is 70.0 per cent and the reading on the day before the next sweep is 53.8 per cent. An auditor arriving unannounced does not sample the average; they see whatever the register is on the day they walk in, and one day in every interval is the worst one.
Now the part worth sitting with, and it is exact rather than approximate. The worst reading at any interval is exactly the average reading at twice that interval. At six months the worst is 70.0 per cent, the average at twelve. At twelve months the worst is 53.8 per cent, the average at twenty four. The two expressions are literally the same: 14 over 14 plus m, and 14 over 14 plus 2m over 2. So a firm quoting its average completeness is quoting the bad-day figure of a firm that sweeps half as often. Say that out loud in a room where somebody has just presented an average and watch what happens.
Who asks a firm what it is running, and where the answer is written down
The expectation that a regulated lender can say what it is running and who is accountable for it sits with the Reserve Bank of India, published at rbi.org.in, and where the deployer is a market intermediary rather than a bank the equivalent position is stated by the Securities and Exchange Board of India at sebi.gov.in. The accountability of a board and its officers for records of this kind is a matter for the Ministry of Corporate Affairs at mca.gov.in. The review frequencies, thresholds, field lists and effective dates shown are this invented bank's own drafting rather than anybody's requirement, and the sweep intervals on the control above are choices it could make rather than anything asked of it. Read the current position at the named sites before acting on any of it.
A firm quotes its average completeness at a six month sweep interval. What number is that, and whose bad day is it?
What does a complete register still fail to say?
Four months after sign-off this register reached 14 of 14. Every use listed, the count perfect, the exercise apparently finished. Read what the same sweep found inside the oldest entry on the list.
The register said present and correct for three months while the thing it described had changed
Entry 1 carried a named accountable person and, by the month 12 validation, every one of its twelve fields. Entry 1 was one of the two complete entries. Inside it, in month 7, the waiting time before escalation in one of the written components had been changed, with no approval recorded and no note made anywhere. The month 10 sweep found it. For the three months in between, the register counted that entry as present and correct while the chain it described had quietly stopped matching what was approved.
Completeness measures whether uses are listed. Completeness says nothing whatever about whether a listed use is still what its entry says it is. Only two of the twelve fields even reach that question: field 10, the date it was last reviewed, and field 12, the date of the next re-approvalThe date on which an entry must be looked at again or the use retired.. No re-approval date was set when the use was approved in month 0, so field 12 on this entry had been empty ever since. The month 12 validation finally set one. So through the whole window in which the change sat unrecorded, nothing in the record was ever going to ask the question. A register can be complete, named, filled in and wrong at the same time, and the only defence against that is a date that forces somebody to look again.
A register reads 14 of 14. What can still be wrong?
How does anybody actually use two lists at once?
In practice people use the two lists differently from the way a policy says they do. There are two doors into the pair, and which door somebody comes through decides which list they need first.
Somebody arrives with a question about approval: was this allowed, who agreed to it, on what basis. Anybody with that question comes in through the register, finds the line, reads field 3 and field 9, and goes downward into the inventory only to find out which components sit inside the use. Somebody else arrives because a component has stopped behaving: a step is returning results nobody expected, or a supplier has had an outage. The second person comes in through the inventory, finds the row, and travels upward to the entry to find out what business it affects and whose telephone rings. The register is entered from the top by anybody asking whether something should exist, and the inventory is entered from the bottom by anybody dealing with something that already does. A firm holding only one list has locked one of those two doors.
The third use is the one that changes how a board reads the list. A register line carries no sense of size, and it should. At Sumeru Bank Limited, entry 1 sits above a chain that cost an invented Rs 2,40,00,000/- to build once and Rs 65,00,000/- a year to run. Another line on the same list is a calculation somebody built inside a spreadsheet in an afternoon. Both are one line. Both are equally entitled to a name in field 3 and a date in field 12. A board member reading fourteen identical lines has no way to know that one of them holds 20.0 per cent of every component the firm runs. The ratio of 45 over 14 is worth setting alongside the register for exactly that reason.
Sources
| Source | Document | Site |
|---|---|---|
| Reserve Bank of India | Published expectations on a regulated lender covering outsourcing, digital lending, data, consent and record keeping, the place where any expectation about what a lender must be able to say it is running is stated | rbi.org.in |
| Securities and Exchange Board of India | The equivalent published position where the deployer of a chain of this kind is a market intermediary rather than a bank | sebi.gov.in |
| Ministry of Corporate Affairs | The accountability of a board and of its officers for the records a firm keeps, the layer a named accountable person inside a firm ultimately reports into | mca.gov.in |
| Bank for International Settlements | The international standard on governance of deployed systems at a bank, being the origin of the expectation rather than the position in India | bis.org |
Sumeru Bank Limited, Revathi Balan, Neelima Rao and Ashok Pillai are invented.
Educational material. Not advice on any investment, tax, budget or market position.
