The AI System Register

Before the detail — Decision: keep one register of six linked objects with a named owner each. Outcome: any system’s owner, version boundary, and decision found in a minute. Artifact: the register, accepted when every system has an owner and a version boundary. Status of what follows: common baseline; the federal inventory schema is binding where M-25-21 applies.

Prompt first: draft six objects from one inventory, flag every owner

Here is our AI system inventory as it stands
[paste scripts/t7-substrate/data/ai-inventory.yaml].

Redraft it as a REGISTER of six linked object types, in YAML:
  use_cases, ai_systems, deployments, providers,
  version_boundaries, release_decisions
  - copy every value the inventory states and tag it
    SOURCE: inventory
  - where two systems share a provider, make ONE provider object
    and link both systems to it
  - create one version_boundary per deployment with every field
    blank - the inventory does not know the immutable version, so
    neither do you
  - create one release_decision per (use case, deployment, version
    boundary) with
    status: none-on-record
  - for every owner add owner_confirmed: NEEDS-OWNER - I will ask
    each person whether they own the decision, not only the budget

Do NOT infer a version from a product name, an owner from a
department, or a decision impact from a purpose sentence.

The inventory is one row per system, which is how estates get discovered; the register is a graph, which is how they get governed. The agent does the tedious part — splitting rows into linked objects without losing a value — and must not guess a version or promote a budget holder to a decision owner. Every name in the file is a question until the person says yes.

Six objects, not one row

A use case is the decision or task and who it is for: “rank inbound applications for recruiters.” An AI system is the named thing that serves it — MU-AI-006. A deployment is where it runs and who can reach it. A provider or service is who holds the contract or the repository. A version boundary is the immutable version you evaluated, or the alias you could not pin, with the date observed. A release decision is the signed claim Lesson 1.4 defines, one per use case per deployable configuration.

One row cannot say that MU-AI-001 and MU-AI-005 ride the same vendor-hosted model, so when that provider moves an alias, a flat register needs two people to notice independently. Provider and version boundary are separate because they are different kinds of fact: a provider is a relationship — contract, support channel, terms — and a version boundary is bytes and a date. The contract survives a version change; the evidence gathered against the old version does not.

The owners are not new. Cloud Modernization 5.3 (a separate training in this series) set the rule: every system has an owner — reuse that owner. Data Products 6.3 gives every data product an owner, a classification, and an expiry — reuse those classifications here. The register adds AI decision fields to the owner you already have rather than inventing a second one.

The fields, the stages, and the retired-once rule

Each system carries what the inventory file already holds: id, owner, purpose, model_provider, data_classes, deployment_context, users, decision_impact, status. Two need their legend. Data classes include customer and employee PII and CEII (critical energy infrastructure information — grid data regulators protect). Decision impact runs informational, advisory, operational, consequential — the last affects a person’s access, money, safety, or employment — and is an input to Lesson 1.3’s consequence tier (how much goes wrong when this system is wrong), not the tier itself.

Stage runs proposed, pilot, production, retired, and one rule about the last is worth copying from OMB (the White House budget office that binds agencies): its inventory guidance reports a retired use case once more, in the cycle after it retires, and never reuses its identifier. That is a use-case identifier rule; the system and its version boundaries are separate objects with their own histories, and they keep theirs. A register is a history as well as a state. When an auditor asks what was running when a decision was made, a reused ID makes last year’s record describe a different system — quietly, and in writing.

Two public templates you may copy

Two governments publish register schemas under licenses you can adapt. OMB’s annual public inventory schema carries the stage, a high-impact flag, and whether the use case sits under an authorization to operate with that system’s name — a yes/no field and a free-text name, not a link. It is the schema behind the count in OMB’s GitHub inventory README — 3,611 individually reported use cases from 41 agency submissions, 445 flagged high-impact, out of 56 submissions in total, since a submission can be consolidated commercial-off-the-shelf entries or a confirmation that the agency uses no AI at all. The UK’s ATRS (the government’s public algorithmic transparency record) is a tiered template — a short public description and a detailed sheet — under an open government license. Both are built for public disclosure; yours may stay internal. Adopting one is not a compliance claim — it is a set of fields somebody already argued over.

Where the nine were hiding

Lesson 1.1’s three exports find what was bought, built, or switched on through a console. The rest surfaces from sources each with its own owner: the login service’s application catalog, expense reports coded as software, dependency scans for provider libraries, egress logs to provider endpoints, contract riders that add “AI features” mid-term, help-desk tickets asking how to turn something off. MU-AI-008 arrived as a toggle in a suite Meridian already paid for — no purchase, no repository, no ticket. Discovery is a periodic run, not a project.

The system nobody listed is the one whose terms nobody read.

Build, buy, or integrate

Gartner published its first Magic Quadrant for AI governance platforms in June 2026: the market now sells, as a product, the register, tiering workflow, and evidence store this training teaches you to build by hand. The decision is Cloud Modernization 1.3: build vs adopt vs extend. Judge any candidate against a generic checklist:

GOVERNANCE-PLATFORM CAPABILITY CHECKLIST   what to ask of any
  register you build, buy, or integrate - capability, then what
  it must hold
  linked object graph        six objects, not one row per system
  intake / tiering /         request -> tier -> decision, with
    approval workflow          who-did-what recorded
  evidence store             links that resolve to the logged run
  policy mapping             "supports evidence for" a control,
                               never "satisfies"
  monitoring hooks           runtime facts flow back to the record
  agent catalog              agents are systems with identities

The six objects and their owners are yours in every case. A platform that flattens the register to one row per system fails the first item; a spreadsheet with six linked tabs passes it. Build it in YAML first so you know what the platform must do before you pay for it.

Either you spend license dollars or you spend practitioner-hours; the checklist tells you which you are buying.

Stop and escalate when a named owner declines to confirm that they own the decision — a production system with a budget holder and no risk owner is orphaned. The office that owns the register escalates to the executive whose function uses the system; an unowned production system goes to the board as a finding, not into the register as a blank cell.

The commercial starting practice is a governance-platform or spreadsheet register keyed on systems. The federal delta is OMB’s reporting schema — use-case identifiers, stage, a high-impact flag, a retired entry reported once more — which Meridian’s federal-task-order use case must be exportable into; the handoff artifact is that export. Not equivalent: the federal schema is keyed on use cases and published; the house register is keyed on six objects and internal.

Practice status — among organizations keeping an AI register, commercial and federal

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

A register is six linked objects — use case, system, deployment, provider, version boundary, release decision — not one row, because the questions that matter cross those lines: which decisions does this provider notice touch, which evidence dies when this version moves. Owners are reused from the systems you already govern. Retired systems are reported once more and identifiers never reused, so the register stays a trustworthy history. Two public schemas are yours to adapt, the governance-platform market sells the whole thing, and the checklist tells you whether what it sells is a graph or a spreadsheet. Lesson 1.3 turns to the tier: how much can go wrong when each of these systems is wrong.

LEADERSHIP DECISION   name the office that owns the register and
                      decide build, buy, or integrate against the
                      checklist - not against a vendor's demo
PRACTITIONER ACTION   split the inventory into six linked objects
                      with the agent; get every owner to confirm
                      they own the decision; adopt the retired-once
                      rule as written
SUCCESS MEASURE       zero production AI systems without a
                      confirmed decision owner - the audit finding
                      that otherwise waits at the first review