0.5 A First Inventory Entry

Introduction

This lesson writes one complete inventory entry for one AI system, from finding the facts to recording the decision. It is a worked case: the organization is a housing association that rents about 6,000 homes, and the system is a feature in its housing management software that scores tenancies for the risk of rent arrears.

The entry is deliberately the minimum. Module 2 builds the full inventory, with its columns, its criteria for tiers and its process for keeping it current. This lesson shows the method for one entry, so that the governance file you set up in lesson 0.4 has its first real record in it, and so that every later module has something to build on.

An AI inventory is the list of AI systems an organization builds, buys or uses, with the facts governance needs about each. It is where every program starts, because a system that is not listed cannot be assessed, controlled or reported on. The NIST AI RMF names it as an outcome of its Govern function: mechanisms are in place to inventory AI systems, resourced according to the organization's risk priorities.

Starting with one entry rather than a full inventory has a purpose. The method for one entry is the method for every entry, and doing it carefully once shows where the facts come from, which ones are hard to find, and which decisions an entry forces.

A student who has written one good entry can write fifty; one who starts with a spreadsheet of fifty system names usually ends with fifty rows that say very little.

The method has five steps. Find the system and the people who know about it. Describe it in plain words, before deciding anything. Decide whether it is in scope, against the definition the organization has adopted. Assign its role, its lifecycle stage and its owners. Record all of it, with a date and a trigger for review.

The order matters most at the third step. It is easy to decide scope from a name: a tool called an assistant is assumed to be AI, a feature called analytics is assumed not to be. Describing the system first, in terms of what it takes in, what it does and what it produces, means the scope decision is taken on facts that another reviewer can check.

The housing association's entry follows these steps in order. It is a useful example because the system arrived quietly, as a feature of software the association already had, and because the people it affects never see it, which is true of many of the AI systems that matter most.

The association's governance lead learned of the system from the income team, who mentioned "the arrears list" during a review of the housing management system. Nobody had recorded it as AI. Finding the facts for the entry took four sources.

The supplier's documentation explained what the feature does: it uses a model to estimate, for each tenancy, the likelihood of falling into arrears in the coming weeks, and ranks tenancies by that estimate. It described the inputs in general terms and did not say how the model was trained.

The administration console showed when the feature was switched on, in spring 2025, and that it was enabled only for the income team. It also showed a setting nobody had changed: the list refreshes weekly.

The income team explained how the list is actually used. Each week, officers start their calls from the top of the list, and they told the governance lead that some officers contact a tenant only because the score is high, with no other sign of difficulty. That fact was in no document, and it matters a great deal for the entry's risk tier.

The contract with the supplier covered the housing management system as a whole and said nothing specific about the scoring feature, which is common when AI arrives as a feature of existing software.

Two questions could not be answered from any of these sources: exactly which data fields the model uses, in particular whether it uses whether a tenant receives benefits, and whether contacting a tenant on the score alone is something the association has ever decided to allow. Both are recorded as open questions with who will answer them, rather than guessed.

An entry that lists its unknowns can be completed; one that hides them looks complete and is not. The governance lead also noted which source gave each fact, so a later reviewer can go back to it.

With the facts gathered, the next step is a description that someone who has never seen the system could follow. A good description has four parts: what the system takes in, what it does with it, what it produces, and who acts on the result.

For the arrears scoring, the description reads: it takes in rent account balances, payment history and records of past contact with each tenant; it uses a model supplied with the housing system to estimate which tenancies are likely to fall into arrears; it produces a weekly list of tenancies ranked by that estimate, with a score for each; and income officers use the list to decide whom to contact first.

Each part does work. The inputs tell a reviewer what data is involved, which matters for privacy and for bias. The second part says what kind of processing is happening, which decides scope. The output says what the system hands over.

The last part, who acts on the result, is the one most descriptions leave out, and it decides most of the risk: a score nobody acts on harms nobody, while a score that decides whom to chase for money affects people directly.

Write the description in the organization's own words, not the supplier's. Supplier documentation describes features in the language of benefits: "proactively identify at-risk tenancies". The description in an inventory says what happens: a model estimates, officers contact. A reviewer needs the second.

Avoid technical detail the entry does not need. The model's type, its features and its accuracy belong in the assessment and the supplier's documentation, which Modules 5 and 8 cover. The entry's job is to let a reader understand in a minute what the system is, so they can decide what else they need to know.

The description also anchors every later record. When Module 5 assesses the system's impact, it starts from who acts on the result; when Module 8 asks the supplier questions, it starts from the inputs. A clear description at this stage saves rediscovering the system at each later step.

The association has adopted the OECD definition of an AI system in its AI policy, the definition Module 1 read in detail. Deciding scope means testing the description against each part of that definition and recording which fact meets which part.

The system is machine-based: it is software running in the housing management system. It infers from the input it receives how to generate outputs: a model, built by the supplier from data, estimates a likelihood for each tenancy from its rent and contact history.

Inference is the part of the definition that separates AI systems from ordinary software, and it is met here, because the score is estimated by a model rather than calculated by rules someone wrote. It generates outputs, a score and a ranking. And those outputs can influence an environment: they shape which tenants the association contacts and when.

Every part is met, so the system is in scope. The record says so, names the definition and gives the fact that met each part, so that a reviewer who doubts the decision can see exactly where to disagree.

Notice what did not decide the question. Nobody at the association called the feature AI, the supplier's documentation used the word only once, and the contract did not mention it. None of that matters to the definition. What matters is that a model infers an output from data, and the documentation and the console together established that.

Had the facts been different, the decision might have been too. If the list were produced by fixed rules the income team wrote, such as "rank by days overdue, then by balance", nothing would be inferred and the system would fall outside the definition.

Lesson 1.1 showed cases like that, and the entry for such a system would record the decision and its reason in the same way: out of scope, because the ranking is calculated by rules people set.

With scope decided, the entry records the association's role for this system and the stage of the system's life. Both shape what the rest of the program asks.

The supplier built the model and offers the housing management system, scoring included, to many housing providers. In the terms of ISO/IEC 22989, the supplier is the AI provider and the association is an AI customer; in the EU AI Act's terms, used here only to show the overlay, the supplier would be the provider and the association a deployer.

The association has not fine-tuned the model, put its own name on it or offered it to anyone else, so none of the facts that would move the provider role to it, which Module 1 set out, apply.

That role decides a great deal later. The association does not hold the controls for training data or model testing; it holds the controls for using the system for its intended purpose, monitoring it in use, deciding how officers act on it, and obtaining from the supplier the documentation it needs. Module 8's supplier questions will start here.

The lifecycle stage is operation and monitoring. The system has been in use since spring 2025, without the earlier stages, design, verification and deployment, ever having been governed by the association. That is normal for a feature switched on in existing software, and the entry records it honestly rather than pretending a release decision was taken.

Recording the stage tells the program what is owed now. A system in operation needs monitoring and a review date; it also needs the release decision that was never taken, taken now, after the assessment Module 5 describes. Until then the entry marks the system as in use without a recorded release, which is a finding in itself.

The role and stage are recorded as decisions with reasons, like scope, because both can change. If the association later fine-tuned the model on its own data, the role would need deciding again.

Every entry names who answers for the system. It should also name who is affected by it, because the people affected are the reason most of the later work exists.

The association names two owners. The executive owner is the director of housing services, who answers for the decision to use the system at all and accepts its residual risk on the organization's behalf.

The system owner is the income team manager, who runs it day to day: makes sure it is used as decided, watches how it performs, and reports changes and problems. Module 1 set out this chain of accountability; the entry is where it is applied to one system.

Naming owners by role and by person matters. The role keeps the entry valid when people move; the current holder's name tells a reader whom to ask today. The association records both, and its charter says who updates the entry when someone changes job.

The users are the eleven income officers who work from the list. The people affected are the tenant households, about 6,000 of them, whose tenancies are scored every week. They never see the system and most do not know it exists. Some are in financial hardship, and the way they are contacted about money can make that better or worse.

Recording the people affected at this stage changes how the system is treated. A system that only affects staff efficiency and a system that shapes how people in hardship are contacted about their rent are different systems for governance purposes, even if the software is similar. The entry's provisional tier, in the next section, follows from this field more than any other.

It also identifies who should be heard in the impact assessment. Module 5 will ask how tenants could be affected; the entry makes sure nobody forgets that they are the ones to ask about.

The completed entry brings every decision together in one record, in the order the steps produced them. It is shown here as the association filed it.

Most fields have already been explained. Three deserve a closer look.

The provisional tier is marked as provisional. The association has not yet adopted the tiering criteria Module 2 teaches, so the governance lead records a judgment with its reason: elevated, because the system shapes contact with tenants about money and some of them may be in hardship.

A provisional tier is better than none, because it tells the program where to look first, and it is honest about being a judgment rather than the result of criteria.

The open questions are recorded with what was asked and when. The first, which data the model uses, matters for privacy and for bias: if benefit status is an input, the system may treat tenants differently because of it.

The second, whether officers may contact a tenant on the score alone, is not a question for the supplier at all. It is a decision the association has never taken, discovered by asking the income team how the list is really used, and it now has an owner who must take it.

The review field gives triggers as well as a date: the supplier's answer, any change to the feature, and six months as a backstop. A review date alone would let a supplier update pass unnoticed; triggers alone might never fire.

The entry is a decision record. It states the decision, in scope and recorded, gives the facts and the reasons, names the owners and sets a review, which is the reviewer test from lesson 0.4 applied to one record. Filed in the governance file, it is the record every later module will extend.

Before filing, the governance lead sent it to the income team manager, who corrected the number of officers and confirmed the description of how the list is used, which is the cheapest check an entry can get and the one most often skipped.

The entry is the first record about this system, and every later module adds one that points back to it. Following it forward shows how the course's records connect.

In Module 2 the provisional tier is replaced by a tier set by written criteria, and the entry joins a full inventory with a process for keeping it current. In Module 5 the system gets a risk assessment and an impact assessment, starting from the people affected and from the open question about how officers act on the score.

In Modules 4 and 6 the controls are chosen: what officers must check before contacting a tenant, how the system's performance is monitored, what changes trigger a review. In Module 8 the supplier is asked what data the model uses, how it was tested and how changes will be notified. In Module 10 the controls are tested and the system appears in a report to the board.

Each of those records names the entry's identifier, AI-007, so that anyone reading the file can follow one system from its first entry to its latest test.

At a smaller organization the same entry would be shorter, not different. A twelve-person firm might write the description in two lines and name one owner for every field, but it would still decide scope on facts, record its role, note who is affected and set a review. Those are the parts that make an entry governance rather than a list.

At a larger one, the entry might be a form in a governance platform with mandatory fields and an approval workflow. The fields would be the same ones shown here, plus those Module 2 adds. The method does not change with the tool.

The next module starts from this point. It reads the definitions, the lifecycle and the roles in depth, which this entry used in brief, and it finishes with the charter that tells an organization who decides what.

An inventory entry records one AI system: a plain description, a scope decision tested against the definition, the organization's role and the system's lifecycle stage, its owners and the people it affects, a provisional tier with its reason, the open questions with who will answer them, and triggers for review.

Facts come from the supplier, the administrator, the users and the contract, and the users often know the fact that matters most. Module 1 starts next, with what counts as an AI system.

Versions this lesson relies on: NIST AI 100-1, AI RMF 1.0 (January 2023); ISO/IEC 22989:2022; EU AI Act, Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744 (status as of 5 November 2026).