Minimum viable set
Rendered from 17-Minimum-Viable-Set.md.
AI9GM v0.9. Companion to the six layer specifications.
Why this page exists
The six layer specifications name 71 artifact types. Read as a flat list, that number tells a fifty-person company the framework is not for them.
It is not a flat list. Every artifact is scoped, on one of two axes, and the scoping is what makes the proportionality convention true rather than aspirational.
Organization-level artifacts exist once no matter how many AI systems run. They are required from a stated maturity level.
System-level artifacts exist once per AI system, model, interface or event. They are required per instance, according to that system’s consequence class and materiality.
So the real question is not how many artifact types the framework names. It is: how many records does an organization at Level 2, running a small number of systems, none of them material, actually maintain?
The answer is roughly a dozen documents. This page shows which, and why none of them can be dropped.
The Level 2 organization-level set
Sixteen artifact types are required from Level 2. Everything else waits for Level 3 or later.
| Name | Owner | Review cycle | Scope | Required from |
|---|---|---|---|---|
| L1-ART-01 Configuration management database, including models, datasets and feature stores as configuration items Minimum set | Platform Owner | Continuous, audited quarterly | organization | Level 2 |
| L1-ART-02 Incident register with root cause linkage Minimum set | Head of Operations | Continuous | organization | Level 2 |
| L1-ART-03 Change log for the AI platform Minimum set | Platform Owner | Continuous | organization | Level 2 |
| L2-ART-01 Interface catalog identifying surfaces consumed by AI systems Minimum set | Head of Enterprise Architecture | Continuous | organization | Level 2 |
| L2-ART-02 Architecture exception register with expiry and remediation owner Minimum set | Head of Enterprise Architecture | Monthly, reported to L4 quarterly | organization | Level 2 |
| L3-ART-01 Model registry with version, owner, status and consequence class Minimum set | Model Owner | Continuous, reconciled quarterly | organization | Level 2 |
| L3-ART-02 Vulnerability register with severity, SLA and closure evidence Minimum set | CISO | Continuous | organization | Level 2 |
| L4-ART-01 AI system register, with classification, materiality and named Business Accountable Executive Minimum set | Head of Risk | Continuous, reconciled quarterly against L3 model registry and L1 CMDB | organization | Level 2 |
| L4-ART-02 AI policy set with version and effective date Minimum set | Policy owner | Annually | organization | Level 2 |
| L4-ART-03 Mandatory control catalog by consequence class Minimum set | CISO | Semi-annually, or on regulatory change | organization | Level 2 |
| L4-ART-04 Published threshold table, per section 5A Minimum set | Policy owner | Annually | organization | Level 2 |
| L4-ART-05 Regulatory obligation register with applicability per system Minimum set | Compliance | On regulatory change | organization | Level 2 |
| L4-ART-06 Policy exception register Minimum set | Head of Risk | Monthly | organization | Level 2 |
| L5-ART-01 AI literacy requirements per role, with completion and competence records Minimum set | Head of Talent | Annually, on role change | organization | Level 2 |
| L5-ART-02 Workforce AI tooling authorization register with data boundaries Minimum set | CIO | On change | organization | Level 2 |
| L5-ART-03 Pilot register with transition status and stated end date Minimum set | PMO Lead | Monthly | organization | Level 2 |
Nothing from Layer 6 appears at Level 2. Strategy, target maturity and the capability decision register all arrive at Level 3. A small organization governs what it runs before it governs what it intends.
The core system-level set
Five artifact types apply per instance, regardless of maturity. Interface fitness is one record, not two: authored at Layer 2, assessed at Layer 3.
| Name | Owner | Review cycle | Scope | Required from |
|---|---|---|---|---|
| L2-ART-08 Interface fitness records for AI-consumed surfaces, version-bound to the interface specification Minimum set | Data Steward | On change, reviewed per the record's stated date | system | per AI-consumed interface |
| L3-ART-06 Model card per production version, stating purpose, training data, limitations and thresholds Minimum set | Model Owner | On every version change | system | per production model |
| L3-ART-09 Data quality reports and lineage records per domain Minimum set | Data Steward | Per domain review cycle | system | per data domain feeding a production model |
| L4-ART-13 Composite accountability records per deployed system Minimum set | Business Accountable Executive | On material change to the system | system | per production AI system |
| L4-ART-14 Deployment authorization records Minimum set | Business Accountable Executive | Per authorization | system | per production AI system |
Domain risk acceptances are required at or above materiality only. An organization running two systems, neither material, does not produce them.
These five are where the framework’s actual proposition lives. Everything else is enumeration and policy. These are the records that make separation of build and acceptance real, and dropping any of them means the framework has been adopted in name.
What this looks like in practice
Sixteen organization-level types plus five system-level types is twenty-one. A fifty-person company does not maintain twenty-one documents, because several collapse.
Collapsing is legitimate where the same person maintains both artifacts. It stops being legitimate when different people do, because the reason two registers exist is usually that two roles need to act on them independently.
| Combined document | Absorbs | Note |
|---|---|---|
| 1. AI inventory | AI system register, model registry, CMDB model entries, pilot register | One table keyed on the AI system identifier, with columns for classification, accountable executive, model version and pilot status. The three registers hold different objects at scale. At this scale they are three views of one table. |
| 2. AI governance document | AI policy, control catalog, threshold table | One document with three sections. Often under ten pages. |
| 3. Exception log | Policy exceptions, architecture exceptions | Same person grants both at this scale. Add a column for which kind. |
| 4. Interface table | Interface catalog, interface fitness records | The catalog with a fitness column and a review date. |
| 5. Incident log | Incident register, security incident records | |
| 6. Workforce AI document | AI literacy requirements, tooling authorization register | |
| 7. Vulnerability register | Usually the output of an existing tool. | |
| 8. Regulatory obligation register | Often a short table. | |
| 9. Change log | Frequently the existing version control history. | |
| 10. Model cards | One per production model. | |
| 11. Data fitness records | Data quality and lineage per domain | One per domain feeding a model. |
| 12. Deployment record | Composite accountability record, deployment authorization | One signed record per system, naming one person and referencing the evidence relied on. |
Twelve documents. Several are one page. Two are usually generated by tools already in use. One is a signature on a record that should exist anyway.
That is the honest answer to what AI9GM asks of a small organization, and it is a different proposition from seventy-one.
What you are not doing at this scale
Stated plainly, because knowing what is deferred is as useful as knowing what is required.
- No aggregate exposure assessment. It arrives at Level 3, when there are enough systems for concentration to mean something.
- No enterprise AI strategy, target maturity or capability decision register. All Level 3.
- No board reporting pack, audit plan, benefit realization or cost attribution. All Level 4.
- No model sourcing posture, sustainability targets or strategic outcome assessment. All Level 4.
- No domain risk acceptances, unless a system is at or above materiality.
- No impact assessments, unless legally required.
- No stage gate records, unless an initiative is delivering an AI system through a formal delivery process.
The one thing that does not collapse
Role collapse is permitted at every scale. One person may hold six roles.
The person who accepts residual risk is never the person who built the thing. At fifty people, at five thousand, at any maturity level.
If a founder writes the model and signs its deployment authorization, the framework has not been adopted leanly. It has not been adopted. Everything else on this page is negotiable by scale. This is not.
Moving up
Level 2 to Level 3 is the largest transition in the framework, and three specifications say so independently. From this set, it adds:
- The capacity model, disaster recovery covering model artifacts, and hosting placement records at Layer 1
- Architecture standards, the interface specification repository and the application portfolio at Layer 2
- Data classification, access grant review and consent execution logging at Layer 3
- Risk appetite, aggregate exposure, cost envelope and vendor register at Layer 4
- Portfolio register, capacity forecast and skills plan at Layer 5
- The whole of Layer 6
The organizational change underneath it is smaller than the artifact count suggests, and harder: someone other than the builder has to hold deployment authority, and that requires a second person with standing to say no.
Correction
The maintainer answers corrections. There is no service level. Responses are best-effort and opportunistic within a reasonable time: a correction raised on a Monday is answered that week or sooner.