Inventory, Classification and Risk Tools

A governed organisation does four things before it lets an AI system do work, and it keeps a record of each. It finds out what AI it has (inventory and intake), decides what kind of use each is (classification), says what could go wrong and for whom (risk and impact assessment) and records the decision together with the conditions under which it stops being valid (the AI Decision Record and the exception). This chapter collects the tools for those four activities. Most are artefacts, that is templates, registers and records defined in a volume of the series; a smaller number are methods, written as practical guides; and a few are third-party instruments that the volumes name as the basis for an assessment. They come mainly from AI Governance (2, Nordqvist, 2026), where the register discipline is defined, and from AI Platform and Security (3, Nordqvist, 2026), AI Red Team (4, Nordqvist, 2026), AI Boss (7, Nordqvist, 2026) and AI Operations (10, Nordqvist, 2026), with shorter contributions from the other volumes. The chapter does not repeat their arguments. It says for each tool what it is for, what it needs and produces, and where the originating volume gives the reasoning; Chapter 8 takes up the tools for obligations, assurance and maturity that read these records as evidence, and Chapter 9 those for suppliers, contracts and sovereignty.

The tools share one design. Each record is a file in version control with an identifier, a named owner and a review date or a list of events that reopen it. A pipeline or a person reads the record, and the record, not a meeting, carries the decision. That is the continuation of the practice of Architecture as Code (1, Nordqvist, 2025), which declares architectural intent under version control, applied to the questions that AI raises: what is it, how risky is it, who decided, and until when.

Figure 7.1: From intake to decision record. The solid path is the order in which the records are made; the dashed paths are the events that send a system back.

How the records relate

The records form a chain, and the order in which they are made matters. The inventory entry or use-case descriptor is written first, because it is the input of everything else: the classification policy reads its fields, the register entry points to its system identifier and the AI Decision Record cites it. The tier that classification returns then decides how much is required. In the series' own example a high-risk entry cannot reach status deployed without its assessments and registration, a limited-risk entry needs disclosure to users, and a minimal-risk entry needs little beyond the descriptor. The register entry and the assessments are written next; they must name the events that reopen them, and those events (a new model version, a changed purpose, a drift alert, a supplier's change notice) send the system back to classification, which is why the figure shows a return path from the decision record.

Two rules recur across the volumes and explain most of the design choices. The first is that a record without an owner, a review date or a trigger is treated as stale, and a stale record counts as an open risk. The second is that a statement of coverage carries its evidence: AI Operations asks that nothing be called recoverable, covered or competent without saying what was tested, when and with what result, and the exception, the closure rule and the year-in-review register apply the same rule to risk. A reader who needs one record should therefore start from the question the record answers, not from the volume that introduced it, and use the origin row of each entry to open the chapter that holds the reasoning.

Inventory and intake

You cannot classify what you cannot list. AI Governance, Chapter 9, puts the point as the most common finding of AI governance assessments: the organisation does not know how many AI systems it operates (2, Nordqvist, 2026). Its answer is to derive the inventory from descriptors declared in the repository, together with the deployment state the pipelines observe, so that a deployed system without a descriptor is a finding and a descriptor with no deployment is a candidate for retirement. The tools in this family differ in the grain at which they list and in who keeps them, but all answer the same question.

AI system inventory entry

Kind	Artefact
Origin	AI Governance, Chapter 9
Purpose	Records one AI system as a descriptor from which the organisation's inventory, and a public register entry, are generated.
Use when	A system is proposed, deployed or changed; the deployment gate in the same chapter refuses status deployed for a high-risk entry without an EU database identifier.
Inputs	The system's intended purpose, owner, role under the AI Act, risk tier, models, data contracts, human oversight design and linked assessments.
Outputs	An inventory generated from all descriptors; a public register entry restricted to the fields named in publication.public_fields.
Identifier family	ai-system/*
Full template	Yes, the Nordvik Region entry ai-system/benefits-triage in AI Governance, Chapter 9 (YAML).

The worked entry carries risk_tier, annex_iii_area, status, intended_purpose, legal_basis, models, data_contracts, human_oversight, assessments (a DPIA and a FRIA identifier), eu_database_id, a publication block and review_due. Two features are worth copying. The intended purpose says what the system does not do as well as what it does, because the negative statement is what an auditor and a resident most often need. And the publication block is the only place that decides what reaches a public register, so an internal field cannot leak by accident.

Usage-mode register

Kind	Artefact
Origin	AI Governance, Chapter 2
Purpose	Lists use cases by usage mode (Mode 0 Ambient AI to Mode 5 Autonomous production agents), kept as YAML beside the AI inventory, with a review cycle.
Use when	Staff, suppliers or teams use AI in ways that never pass through a procurement of "an AI system", which is the case for Modes 0 to 3.
Inputs	Use cases, their mode, data classes, the minimum control baseline of each mode and an owner.
Outputs	A register in which each use case carries a baseline status per control (for example met, partly-met, missing).
Identifier family	usage-modes/*.yaml; use cases NR-UC-* in the Nordvik Region example
Full template	Yes, usage-modes/nordvik-region.yaml in AI Governance, Chapter 2 (YAML).

The register's policy block records which modes the organisation does not permit (Nordvik Region: Mode 5) and who may use Mode 3 tools. Because the unit of inventory differs by mode, the register is the place where a supplier-enabled feature (Mode 0) and a built application (Mode 4) can sit in one list.

Office feature register

Kind	Artefact
Origin	AI Boss, Chapter 10
Purpose	Registers the features of office suites and workflow agents that assign, summarise or report about people, with the degree of delegation and whose agreement each carries.
Use when	A supplier release switches on, or could switch on, a feature that names or measures another person.
Inputs	Every feature, including default-on features; the four tests of the chapter; the management function and usage mode of each.
Outputs	management/office-feature-register.yaml, extending the delegation register, with prohibited uses, the accountable role and the status of works-council or union agreement.
Identifier family	FTR-* (for example FTR-NR-SA-01, FTR-HM-CA-01)
Full template	Yes, an excerpt with one entry per organisation (YAML).

The practical guide that builds it (in the entry's chapter) sets defaults that are the book's own: figures about collaboration, focus or wellbeing go to the individual alone or to groups of at least ten, and no summary or analytics figure is used as evidence in a review or disciplinary process unless the person has seen it and been able to correct it. An entry can record that a feature is switched off; Hansa Mutual's wellbeing analytics entry lists enabled_in: [] and the pending agreements per country.

Testing-forms register

Kind	Artefact
Origin	AI Purple, Chapter 2 (9, Nordqvist, 2026)
Purpose	Classifies the testing forms an organisation already runs, as the baseline before the purple loop.
Use when	At the start, to see which forms exist, who ran them and which stage of the loop each leaves unfinished.
Outputs	A register per organisation with form, source, cadence, whether the blue team was aware, output, retest rule, unfinished stage and an evidence expiry in days.
Identifier family	TFR-* (TFR-NR-01, TFR-HM-01)
Full template	Yes (Appendix A of AI Purple, YAML).

It belongs to this chapter because it is an inventory of what is done, not of AI systems; its companion method, classifying existing testing, is in the table below.

Other inventory and intake tools

Tool	Kind	Origin	Purpose
Blue team function inventory / function map (team/function-map.yaml)	Artefact	AI Blue, Chapter 2 (8, Nordqvist, 2026)	Maps who performs each of B1 to B5, with which tools, which parts already run without a reader and who accepted them.
Reconciling the AI inventory with discovered assets	Method	AI Red Team, Chapter 9	Reconciles declared AI assets with discovered ones daily, to find shadow AI; the classifier works at Level 1 Assisted and an unknown asset that acts or reads confidential data goes to the security operations centre.
Pressure register (PRS-*)	Artefact	AI Blue, Chapter 3	Records the pressures on the team (adversary AI, telemetry, talent) with evidence labelled observable, expected or speculation; the prefix appears once, in a worked example for the Hansa Mutual group SOC, with no full template.
Operations loop (O1 Observe to O5 Sustain)	Method (framework)	AI Operations, Chapters 1 and 4	The five operations functions against which cases and controls are classified; a classification frame, listed here because the slice assigns it to this chapter and proposed for reassignment.
First inventory of AI in the team	Artefact (practical guide)	AI Blue, Chapter 1	One list of the AI that already takes part in the team's work.
Building a feature register for office assistants and analytics	Method	AI Boss, Chapter 10	The practical guide behind the office feature register above.
Practical guide: inventorying where AI already takes part in operating a service	Method	AI Operations, Chapter 1	One page per Tier 1 service listing every tool in the operating chain that contains AI, with mode, whose identity acts, highest action class and stop.
Practical guide: classifying the practices a team has	Method	AI Operations, Chapter 2	Decides per practice whether to keep, automate, change owner or retire it before AI is introduced.
Classifying existing testing	Method	AI Purple, Chapter 2	Classifies the testing a team already does; produces the testing-forms register above.
Classification-routed hybrid agent setup (practical guide)	Artefact (practical guide)	AI Platform and Security, Chapter 15	Seven steps that classify the work, fix a routing table as an AI Decision Record, build one workspace image per tier and put the gateway in the path.
AWS Application Discovery Service, Azure Migrate	Third-party tool	Architecture as Code (Chapter 16)	Named in passing as discovery tools for resource inventory in a migration; the series makes no claim about them beyond that.

Classification

Classification turns an inventory entry into a tier, and the tier selects the obligations, the assessments and the approvals that follow. The tools here express the AI Act's structure as questions, rules and thresholds a policy engine or a reviewer can apply in the same order every time. They classify a use, not a technology: AI Governance, Chapter 8, makes the unit of classification depend on the usage mode.

Risk-tiering questionnaire

Kind	Artefact
Origin	AI Governance, Chapter 8
Purpose	Walks the AI Act classification decision tree for one system, with a legal basis stated for every answer.
Use when	At intake, and again when the intended purpose, user population or mode changes.
Inputs	The system's description, the deployer's or provider's role and the articles of Regulation (EU) 2024/1689 cited in the questionnaire (195, European Union, 2024).
Outputs	A resulting tier with the obligations it triggers.
Full template	Yes (Markdown); quoted below as in AI Governance, Chapter 8, with the book's own omission of Q3.

# Risk-tiering questionnaire: ai-system/benefits-triage

Owner: Head of Social Services, Nordvik Region | Completed: 2026-05-12
Reviewed by: Legal counsel (AI Act) and Data Protection Officer

| #   | Question                                   | Answer                                       | Basis                  |
|-----|--------------------------------------------|----------------------------------------------|------------------------|
| Q1  | Is it an AI system?                        | Yes. A gradient-boosted model scores each application. | Article 3(1)  |
| Q2  | Does any use fall under Article 5?         | No. The score orders the queue for one benefit only. | Article 5(1)(c)  |
| Q4  | Used in an Annex III area?                 | Yes: eligibility for public assistance.      | Annex III point 5(a)   |
| Q5  | Only a narrow or preparatory task?         | No. The ranking determines how long an applicant waits. | Article 6(3) |
| Q6  | Does it profile natural persons?           | Yes. It evaluates applicants' circumstances. | Article 6(3); GDPR Art. 4(4) |
| Q7  | Interacts with people or generates content?| No. Caseworkers see a score.                 | Article 50             |
| Q8  | What is our role?                          | Deployer. We neither rebrand nor modify it.  | Articles 3(4) and 25   |
| Q9  | Is the deployer a body governed by public law? | Yes.                                     | Article 27(1)          |

Resulting tier: HIGH (Q4 yes, Q5 no, Q6 yes).
Obligations triggered: Article 26 deployer duties, Article 27 FRIA,
Article 49(3) registration, Article 86 explanations, GDPR Article 35 DPIA.

Every answer carries a reference, so a reviewer challenges the basis rather than the conclusion. Q6 is asked separately from Q5 because the profiling exclusion in Article 6(3) overrides every derogation ground, and the book notes it is the answer most often missed when a team describes its system as "only prioritising".

Risk classification policy

Kind	Artefact
Origin	AI Governance, Chapter 8
Purpose	A Rego policy that evaluates a use-case descriptor and returns a tier with reasons.
Use when	The questionnaire's questions are to be evaluated by a pipeline instead of by a reviewer each time.
Inputs	A signed use-case descriptor (a JSON document with fields such as annex_iii_area, task_type, performs_profiling, role, signed_by; the chapter's example is UCD-2026-022).
Outputs	A tier (prohibited, high, limited, minimal) and deny messages, for example a high-risk system without a FRIA reference.
Identifier family	Package ai.risk.classification
Full template	Yes (Rego), in AI Governance, Chapter 8.

The policy runs on Open Policy Agent, the engine that Architecture as Code uses for infrastructure guardrails (51, Open Policy Agent, n.d.). The book asks that a named owner sign the descriptor, so that a misleading one is an auditable act, and that the legal review which approved the encoding is stored beside the policy and renewed when guidelines or harmonised standards arrive.

Substantial-modification rule

Kind	Artefact
Origin	AI Governance, Chapter 8
Purpose	A Rego policy deciding whether a change to model or data is an unforeseen change that requires legal review as a possible substantial modification.
Use when	A model card changes: new base model, fine-tuning data, input feature, output type, a decision threshold moved by more than 0.02, a changed purpose or user population.
Inputs	The production and proposed model cards and the provider's change plan of predetermined changes.
Outputs	deny messages that block promotion and, for a deployer, a warning that the organisation may become a provider under Article 25.
Identifier family	Package ai.risk.substantial_modification
Full template	Yes (Rego).

The rule does not decide that a change is a substantial modification, which remains a legal judgement; it decides that a human must make the judgement and records why.

Risk appetite statement

Kind	Artefact
Origin	AI Governance, Chapter 8
Purpose	Expresses the board's risk appetite as data, the threshold set against which a gate evaluates register entries.
Use when	A gate must decide, by tier, which assessments are required and which residual rating is acceptable.
Inputs	Tier rules with decisions (never, conditional, allowed), required assessments, the maximum residual rating and an escalation rule.
Outputs	A versioned statement (risk_appetite, version 2026.2 in the example).
Identifier family	risk_appetite
Full template	Yes (YAML).

Versioning is the point: when the appetite tightens, re-running the gate lists the systems that no longer fit.

Risk-appetite statement as code (security AI)

Kind	Artefact
Origin	AI Red Team, Chapter 5
Purpose	A versioned statement of error tolerance, autonomy ceilings, reversibility and review triggers for the organisation's own security AI.
Use when	Security AI is registered, changes mode or level, or is involved in an incident or red-team finding.
Inputs	The context record of security AI; actions classified as reversible within minutes on one target, reversible with effort, or irreversible.
Outputs	A statement with fixed limits on Level 4 Autonomous, autonomy ceilings per usage mode, error tolerances with an automatic step down on breach, review triggers and risk indicators.
Identifier family	HM-RAS-* (HM-RAS-SECAI)
Full template	Yes (YAML). The book's Appendix B marks the template "planned" although Chapter 5 gives a full example (see data/findings/chapter_07.md).

Its entityOverrides keeps the ceiling at Level 1 Assisted in any entity where employee representatives have not agreed to a tool that can act on employees' accounts, so a single group statement respects national labour law. The companion method, writing a risk-appetite statement for security AI, is a seven-step guide in the same chapter.

Other classification tools

Tool	Kind	Origin	Purpose
Anti-pattern severity classification	Artefact	Architecture as Code (Chapter 26B)	A table of Critical, High, Medium and Low with a recommended response for each, from escalation to leadership within the sprint to monitoring and recording in the risk register.
Data handling standard (data_handling_standard)	Artefact	AI Governance, Chapter 9	Data-use rules by classification as a machine-readable standard (STD-AI-002), read by the gateway and the staff alike so that the two cannot diverge.
Impact assessments as pipeline inputs	Artefact	AI Governance, Chapters 8 and 10	DPIA, FRIA and related assessments as required inputs to the gate by risk tier; no template of its own.
Classifying controls as verified, declared or failed	Method	Transformed Security Architect, Chapter 9 (6, Nordqvist, 2026)	Gives each control a status set by its last test result; every status other than verified becomes a finding.
Review protocol by risk tier	Artefact and method	Transformed Security Architect, Chapter 14	Review depth, techniques and reviewers by risk tier for AI-proposed changes (protocol: architecture-review); the method is the practical guide that introduces it.
Model-origin geopolitical risk assessment	Method	AI Governance, Chapter 6	A dated, evidence-backed assessment of one model or provider across five categories: legal access to data and prompts, service continuity and sanctions, model behaviour, supply-chain integrity, regulatory compliance.
Investment gate lifecycle	Method	AI Governance, Chapter 16A	Six gates from intake to renewal, redesign or retirement, each with the evidence required; it classifies an investment, not a risk, and belongs with the portfolio tools.
Redesigning a review board as a design authority with gates	Method	Transformed Security Architect, Chapter 17	Replaces a board that decides every item with gates for the routine and a design authority for exceptions; run in shadow for four weeks and delegate a class only when gate and board agree on at least 95 per cent of at least 20 decisions.
Forum structure and decision-rights design	Method	AI Governance, Chapter 13	Two practical guides: giving every AI decision one home, and a decision-rights matrix by risk class; it relates to tiers more than to risk assessment.

Risk and impact assessment

Where classification says how serious a use is, an assessment says what could go wrong, for whom, and what is done about it. The series keeps the assessment as an artefact with an identifier, an owner, a date and a review period, so that the register references it and the gate checks it. AI Governance, Chapter 8, observes that Article 27 of the AI Act lets a FRIA build on an existing DPIA, so a shared schema pays off (2, Nordqvist, 2026).

Risk register entry

Kind	Artefact
Origin	AI Governance, Chapter 8
Purpose	A version-controlled register entry that links a hazard to controls, assessments and the events that reopen it.
Use when	A system is classified and its hazards and controls are to be tracked; the review triggers name the changes that force re-evaluation.
Inputs	System identifier and classification, hazard, harm categories, controls, owner, DPIA and FRIA identifiers, review period and triggers.
Outputs	An entry whose status (for example accepted_within_appetite) the gate reads; a stale entry (last_reviewed plus period_days passed) is treated as an open risk.
Identifier family	RISK-*
Full template	Yes, quoted below from AI Governance, Chapter 8; a second example, RISK-2026-031, adds applies_in, catalogue_refs, upstream_components and key_risk_indicators.

id: RISK-2026-014
system: ai-system/benefits-eligibility-support
classification: {tier: high, basis: "Annex III point 5(a)", role: deployer}
hazard: "Systematically lower scores for applicants with incomplete digital records"
harm_categories: [fundamental_rights, non_discrimination]
inherent_rating: high
controls:
  - CTRL-FAIR-003   # subgroup evaluation in promotion gate
  - CTRL-OVR-001    # caseworker override with recorded reason
  - CTRL-MON-007    # weekly disparity monitoring
residual_rating: medium
owner: head-of-casework
assessments: {dpia: DPIA-2025-031, fria: FRIA-2026-004}
review:
  period_days: 180
  last_reviewed: 2026-09-15
  triggers: [model_version, training_data_window, intended_purpose, drift_alert]
status: accepted_within_appetite

The controls field is the hinge: each identifier resolves to a policy, a pipeline stage or a procedure, so an auditor can walk from risk to control to the evidence that it ran. The entry quoted here belongs to a benefits eligibility decision-support system; the identifiers of the DPIA and FRIA differ from those on the benefits-triage entry in the inventory example, because the two chapters illustrate different systems or different drafts (see the findings file).

Risk definition document (RISK-*)

Kind	Artefact
Origin	Architecture as Code (Chapter 9C)
Purpose	A YAML risk with likelihood, impact, control references, owner and review cadence, validated in CI.
Use when	Risks are to be kept as validated documents, so that missing data, an outdated review date or an invalid owner stops a pull request.
Identifier family	RISK-* (RISK-0047 in the example)
Full template	Yes (YAML).

It is the ancestor of the AI risk register entry: a statement, a category, likelihood, impact, control_refs, risk_owner and review_cadence. The associated method, risk as code with exceptions (Architecture as Code, Chapter 9C), gates deployments on every high or critical risk being either mitigated by automated controls or accompanied by a time-bound exception; it has no template of its own.

Risk register entry as code (stage risks)

Kind	Artefact
Origin	AI Platform and Security, Chapter 9
Purpose	A stage-risk register entry for the DevSecMLOps loop: inherent and residual scores, control status with evidence, appetite, actions, key risk indicators, ISO/IEC 27001 Annex A references and DORA articles.
Use when	A stage of a build pipeline carries a risk that belongs in the information security management system.
Identifier family	HM-LOOP-* (HM-LOOP-04, the dependency and mirror stage of Hansa Mutual's claims assistant)
Full template	Yes (YAML).

A control can be partial with its evidence stated (3 of 41 build images still allow install scripts), and the key risk indicators are computed from manifests and mirror logs so that a breach opens a review automatically. The companion method, the stage-by-stage pipeline risk assessment (practical guide, same chapter), takes about two weeks and ends in a treatment plan.

Fundamental rights impact assessment (FRIA) and FRIA extract

Kind	Artefact
Origin	AI Governance, Chapters 10 and 17 (FRIA); AI Boss, Chapter 21 and Appendix A (FRIA extract)
Purpose	The FRIA required by Article 27 of the AI Act for public bodies, private entities providing public services and certain Annex III deployers, structured by the paragraphs of Article 27(1).
Use when	A high-risk system is to be put into use by a deployer that Article 27 covers.
Identifier family	FRIA-* (FRIA-2026-002, FRIA-2026-007)
Full template	Yes: the outline in AI Governance, Chapter 10 (Markdown), and the home-care extract FRIA-2026-007 in AI Boss, Appendix A (YAML).

The outline of AI Governance gives each risk an identifier, a measure and a trigger with a response, so that Article 27(1)(f) becomes a monitoring rule. The extract of AI Boss is for a worker-management system and lists affected groups, three risks tied to Charter rights, oversight, measures if the risks materialise, the Article 26(7) information duty and the review rule. They differ in domain and format; the series' pattern is the same.

Data protection impact assessment extract

Kind	Artefact
Origin	AI Boss, Chapter 22
Purpose	An excerpt of a DPIA cross-referenced with the FRIA for the ShiftWise system, recording the degree of human involvement per class of decision.
Identifier family	DPIA-* (DPIA-2026-031)
Full template	Yes (YAML).

The extract assigns each decision class a level, a decider and an assessment of whether it is solely automated, and it lists reopen_if conditions, for example ordering recipients on any personal aspect. The DPIA itself is required under Article 35 of the GDPR where processing is likely to result in a high risk (196, European Union, 2016).

Work-environment risk assessment (and the pace-system method)

Kind	Artefact and method
Origin	AI Boss, Chapters 6 and 14
Purpose	Assesses a system that sets, measures or enforces work pace as a work-environment risk, with safety representatives, before it is introduced or changed.
Identifier family	WRA-* (WRA-NR-HC-01, revision 1 in Chapter 6 and revision 2 in Chapter 14)
Full template	Yes (YAML). The practical guide in Chapter 6 (work-environment risk assessment of pace systems) has seven steps, from naming the pace parameters to recording reassessment triggers.

The record names each pace parameter with its control and states the follow-up rule in writing: a missed target opens a conversation about the work, not an automated warning.

Third-party instruments for assessment

Instrument	Kind	What it is	How the series uses it
ALTAI (Assessment List for Trustworthy AI	Third-party tool (self-assessment questionnaire)	Published by the High-Level Expert Group on AI in 2020; it turns the seven requirements for trustworthy AI into questions (46, AI HLEG, 2020).	AI Governance runs it at intake, as a lighter self-assessment than the method standard below.
ISO/IEC 42005:2025	Third-party tool (international standard)	A method for AI system impact assessment (49, ISO/IEC, 2025).	AI Governance uses it as the method for both DPIA and FRIA, so that identified risks flow into the register.
ISO/IEC 23894:2023	Third-party tool (international standard)	Guidance on AI risk management, adapting the ISO 31000 process (48, ISO/IEC, 2023).	The reference for AI-specific sources of risk in the same chapter.
NIST AI Risk Management Framework	Third-party tool (framework)	Organises AI risk work into Govern, Map, Measure and Manage (50, NIST, 2023).	Named alongside ISO/IEC 23894 as one of the two frameworks that structure the problem.
UNESCO Readiness Assessment Methodology and Ethical Impact Assessment	Third-party tools	UNESCO tools built on its 2021 Recommendation on the Ethics of AI; the readiness methodology assesses a state's preparedness across legal, social, economic, educational, scientific and technological dimensions (52, UNESCO, 2023) and the ethical impact assessment is a further tool of the Recommendation (47, UNESCO, n.d.).	AI Governance places them as national-context and ethics instruments; the series makes no claim that they replace the AI Act's assessments.

The series states only what these instruments are and where it uses them. Their content is in the cited documents; the limit of the series' claim is that they inform an assessment and do not by themselves satisfy an obligation of the AI Act.

Threat-claim and tail-risk tools

AI Threat (5, Nordqvist, 2026) treats risk assessment of claims, not of systems: what a voice of alarm or reassurance asserts, and how it is weighed. Its artefacts are records of the same kind as those above.

Tool	Kind	Origin	Purpose
Claim card (CC-*, kind ClaimCard)	Artefact	AI Threat, Chapter 3	Records one AI risk claim, who makes it, the evidence rung it rests on, the interests of claimant and critic, an assessment label (observable, expected or speculation) and what would change the assessment (CC-NR-2026-03).
Crux map (CRX-*, kind CruxMap)	Artefact	AI Threat, Chapter 4	Records the points on which participants in a structured discussion disagree and what evidence would settle each (CRX-NR-2026-01).
Instrument mapping of register entries (IMAP-*)	Artefact	AI Threat, Chapter 28	Maps each register entry to the instruments that require a control, duty holders, coverage and residual gaps (IMAP-2026-01); not listed in the volume's Appendix B.
Reading an AI risk claim (ten-question check)	Method	AI Threat, Chapter 3	Ten written questions applied to alarm and reassurance by the same standard.
Tail-risk handling with leading indicators	Method	AI Threat, Chapters 4 and 27	Keeps tail risks in the register with leading indicators and triggers instead of an agreed probability.
Existential-risk scenario writing for a register	Method	AI Threat, Chapter 27	Records civilisational risk with decision rules and raising and lowering triggers.
Mapping register to legal instruments	Method	AI Threat, Chapter 28	The practical guide behind the instrument mapping.
Trigger-based register review	Method	AI Threat, Chapter 32	Reopens entries when named observations occur, in both directions, with nextReview as a backstop.
Task classification for AI in education	Method	AI Threat, Chapter 7	Classifies each task as excluded, tutor or tool.

The crux map's noRegretActions and whereThePositionsMeet fields record how a disagreement narrowed: in the series' example, the most expensive option left the table without anyone conceding the larger argument.

Findings and learning records

Tool	Kind	Origin	Purpose
Finding register (FND-*)	Artefact	AI Blue, Chapters 11, 15 and 25	Holds findings from reviews, drills and red-team exercises with severity, control, owner, actions and re-test date (FND-HM-2027-014); a finding closes on a passing re-test.
Classifying and segregating a findings register	Method	AI Purple, Chapter 16	Practical guide for classifying findings and keeping the register apart from the systems it concerns.
Problem record (PRB-*)	Artefact	AI Operations, Chapter 12 and Appendix A.8	Tracks each action from a review to verified closure; states are closed_verified, retest_failed, implemented_unverified and risk_accepted.
Action closure rule	Artefact (Python)	AI Operations, Chapter 12 and Appendix A.8	A small function that reports an action as closed only if it has a signature and a re-test result, and reopens an action when a risk acceptance has expired.
Decoy register entry (HM-DEC-*)	Artefact	AI Red Team, Chapter 19	Register entry for a honeytoken, canary or decoy with owner, placement, monitoring and authority to act; a detection tool, listed here for completeness.

Exceptions

An exception is a decision to live with a gap for a stated time. The series holds one rule across its volumes: as a meeting outcome an exception tends to become permanent, whereas as a record with an expiry it stays temporary. Transformed Security Architect, Chapter 17, adds that renewal is a new decision requiring new evidence, that the compensating control is tested, and that the register of exceptions is reported upward because a growing stock of renewed exceptions is a leading indicator (6, Nordqvist, 2026).

Exception record

Kind	Artefact
Origin	Transformed Security Architect, Chapter 17 (also used in Chapter 25)
Purpose	An expiring exception with owner, compensating control and the evidence required to renew.
Use when	A control cannot be met for a bounded time, for example because a supplier's service supports only part of the required behaviour.
Inputs	The control, system, reason, risk reference, owner, deciding tier and date, compensating control with its last test, expiry.
Outputs	A record that the exception gate reads; renewal_requires states what a renewal must attach.
Identifier family	EXC-* (EXC-NR-0007)
Full template	Yes, quoted below from Transformed Security Architect, Chapter 17.

id: EXC-NR-0007
status: active
control: CTRL-KEY-004            # customer-held key rotation every 90 days
system: internal-staff-assistant  # AIDR-0211, contract NR-2026-031
reason: supplier key service supports 180-day rotation until release 2027-Q1
risk: {register_ref: RISK-NR-0031, likelihood: low, impact: medium}
owner: chief-information-security-officer
decided_by: {tier: 2, role: chief-information-security-officer, date: 2026-11-12}
compensating_control:
  id: CTRL-KEY-004-C1   # alert on key use outside the assistant's identity
  last_passed: 2026-11-10
expires: 2027-02-10               # 90 days; tier 2 maximum
renewal_requires:
  - supplier release notice or dated roadmap commitment
  - compensating control test passed within the last 30 days
disclosure:
  public_access: requestable      # details reviewed under national secrecy rules
  archive: retain-with-system-file

The defaults in the originating chapter are 90 days at tier 2 and 180 days at tier 3, to be adapted to the organisation's appetite.

Exception gate rule

Kind	Artefact
Origin	Transformed Security Architect, Chapter 17
Purpose	A Rego rule that denies a change relying on an exception whose expiry has passed.
Identifier family	Package gates.exceptions
Full template	Yes (Rego), eight lines; the book calls it the smallest useful gate rule.

The rule is the enforcement half of the record. The chapter adds four properties of a gate that works: the rule is versioned and tested, the author of a change does not own the rule that gates it, bypass is possible, visible and reviewed, and the rule is itself reviewed for staleness.

Other exception tools

Tool	Kind	Origin	Purpose
Time-bound risk exception	Artefact (described, no template)	Architecture as Code (Chapter 9C)	An exception as a code artefact with an expiry date and approval chain; deployments may proceed only if every high or critical risk is mitigated or accompanied by one.
Principle exception record (kind PrincipleException)	Artefact	AI Governance, Chapter 4	A time-limited, recorded exception to a principle, with compensating controls, residual risk, acceptor and expiry (EXC-0004, Hansa Mutual's claims assistant on a hosted model whose version the organisation cannot retain).
Portfolio exception record	Artefact	AI Governance, Chapter 16	An exception when a funding or readiness criterion is not met (EXC-2026-012); its on_expiry: revert_state_unless_closed reverts the use case if not closed.
Risk acceptance with expiry	Artefact	AI Purple, Chapters 20 and 10	A finding in the state "risk accepted" with the accepting role, the roles not eligible to accept, a compensating control, reopening conditions and the state at expiry (FND-HM-2028-011).

The identifier family EXC-* is used for three different records in two volumes (principle exceptions, portfolio exceptions and security-control exceptions). The kind and the schema, not the prefix, identify the record; the findings file lists the overlap.

AI Decision Records

The AI Decision Record (AIDR) is the record in which an organisation says what it decided about an AI system or profile, on what basis and until when. AI Governance introduces it as a version-controlled record kept for every AI system, extending Nygard's Architecture Decision Record with intended purpose, users, data, model, risk class, owner and retirement criteria (2, Nordqvist, 2026), but gives no standalone template: its closest full example is the inventory entry above. AI Platform and Security, Chapter 5, supplies the two forms that the series uses (3, Nordqvist, 2026). Each later volume then reserves a range of numbers and cites AIDRs as the decision behind its artefacts.

AI Decision Record as structured data

Kind	Artefact
Origin	AI Platform and Security, Chapter 5 and Appendix A (05_CODE_AIDR)
Purpose	The machine-readable YAML form of the AIDR that pipelines and the generated decision index can read.
Use when	A decision on an AI system is taken or superseded. The pull-request checks of the same chapter validate the front matter, refuse edits to the body of an accepted record except for status fields, and require an oversight path and thresholds in every high-risk record.
Inputs	System role, Article 5 practices, Annex III areas, intended and prohibited uses, data sources with lawful basis, evaluation criteria, human oversight, security and cost references, retirement criteria, evidence files.
Outputs	A record whose spec.system block the classification policy consumes, whose spec.evaluationCriteria the evaluation gate reads and to which the evidence manifest links back.
Identifier family	AIDR-*
Full template	Yes, quoted below from AI Platform and Security, Appendix A, omitting the security, cost and evidence fields.

apiVersion: ai-architecture.example.eu/v1
kind: AIDecisionRecord
metadata:
  id: AIDR-0030
  title: Use a retrieval-grounded assistant for case-handler support
  status: accepted            # proposed | accepted | superseded | retired
  date: 2026-03-12
  reviewDate: 2026-09-12
  deciders: [chief-architect, head-of-case-handling, data-protection-officer]
  relatedRecords: {dpia: DPIA-2026-004, fria: FRIA-2026-006, vendorAssessment: VA-0042}
spec:
  system:
    id: case-handler-assistant
    role: deployer
    deployer: {publicBodyOrPublicService: true}
    practices: []                      # Article 5 practices, expected empty
    annexIII:
      areas: [essential-services-and-benefits]
      exemptionBasis: none
    interactsWithNaturalPersons: true
  intendedPurpose: >
    Retrieve and summarise applicable legislation, precedent and internal
    guidance for a case under review, with citations, for a trained case handler.
  prohibitedUses: [drafting-decision-text, ranking-applicants, cases-involving-minors]
  dataSources:
    - {name: legal-corpus, personalData: false, contractRef: contracts/legal-corpus.yaml}
    - name: case-summary
      personalData: true
      lawfulBasis: GDPR Article 6(1)(e)
      retentionDays: 30
      contractRef: contracts/case-register.yaml
  evaluationCriteria:
    - {metric: groundedness, operator: gte, threshold: 0.95, evaluationSet: evals/case-handler-golden-v3}
    - {metric: citation_accuracy, operator: gte, threshold: 0.98, evaluationSet: evals/case-handler-golden-v3}
    - {metric: out_of_scope_refusal_rate, operator: gte, threshold: 0.99, evaluationSet: evals/case-handler-redteam-v2}
  humanOversight:
    pattern: human-in-the-loop
    interruptionPath: division-head-can-disable-per-team
  retirementCriteria:
    - {metric: groundedness, operator: lt, threshold: 0.90, consecutiveWindows: 2}
    - {event: fria-not-renewed-by-review-date}

A test that the table fields of the Markdown form match the YAML fields stops the two from drifting apart.

AI Decision Record template (Markdown)

Kind	Artefact
Origin	AI Platform and Security, Chapter 5 and Appendix A (05_CODE_ADR)
Purpose	Records an architectural decision about an AI system in a reviewable form, extending the ADR with intended purpose, data, evaluation, oversight and retirement fields, which the technical documentation of Article 11 and Annex IV of the AI Act expects to find.
Identifier family	AIDR-*
Full template	Yes (Markdown): a field table (status, date, deciders, AI Act role, risk classification and its basis, related records, review date) and sections for context, intended purpose and scope, decision, data sources, evaluation criteria, human oversight and security, and consequences and retirement. Not quoted here; see the appendix.

The practical rule of the chapter is that a field which does not apply is marked "not applicable" with a reason, never left blank, and that the model registry refuses to promote a model version whose system has no accepted record.

AI Decision Records across the series

The AIDR is reused in every later volume with its own number range. The ranges are the series' way of keeping decisions apart; the identifier alone tells the reader which volume's organisations are concerned.

Tool	Origin	Range and use
AI Decision Record (concept, with the inventory entry as closest example)	AI Governance, Chapters 3, 8, 9, 13 and 21	AIDR numbers such as AIDR-0211 (the Nordvik staff assistant) and AIDR-0024 (a use that changed mode); no standalone template.
AI Decision Record (AIDR) for the commission	Transformed Security Architect, Chapter 1	AIDR-0500 to AIDR-0599; the commission of a role charter and competence plan (AIDR-0500, AIDR-0550), also written in ADR form.
AI Decision Record	AI Boss, Chapters 1, 4, 7, 21, 22 and 23	AIDR-0600 to AIDR-0699 (Nordvik Region 0600 to 0649, Hansa Mutual 0650 to 0699); commission AIDR-0600, pause AIDR-0601, Article 22 analysis AIDR-0676.
AI Decision Record	AI Threat, Chapters 7, 10, 11, 13, 14, 16, 20 and 32	Cited to document decisions on threat controls (for example AIDR-0470, AIDR-0401); defined in AI Governance.
AI Decision Record	AI Operations, Chapters 1 and 30	AIDR-0900 to AIDR-0999 (Nordvik 0900 to 0949, Hansa 0950 to 0999); cited as the decision behind each artefact; not templated there.
Pause record for a screening model	AI Boss, Chapter 7	AIDR-0601: records introducing, pausing or retiring a screening model so that a candidate, union and supervisor can read it; fields include classification, pilot, trigger, questions_asked, supplier_answers, decision, reasons and conditions_for_return.
Measure lineage record	AI Boss, Chapter 3	AIDR-0624: traces where a measure came from and which management function it enters, with the rule that it is not an input to pay, discipline or dismissal and a variance rule that reviews the standard before the person.
Board decisions for the management body / AIDR-0849, AIDR-0899 (two-year loop plan)	AI Purple, Chapter 28	AIDR-0849 and AIDR-0899, each with a PLAN-* file of measures, owners, dates and verification.
Two-year plan	AI Purple, Chapter 28 and Appendix B.27	Turns the book's conclusions into measures with owners and a review date (PLAN-* and an AIDR); described in Appendix B, partly illustrated in the chapter.
Register-of-information entry	AI Operations, Chapter 24	An operations-side register entry for an ICT arrangement (HM-PROC-CLB-2028-04, a managed model service of Cloud B) with the register-of-information fields required under DORA Article 28(3) and (9) (197, European Union, 2022), a substitutability assessment, exit plan and test, and a change gate that refuses routing to the provider unless the entry is active.
Year ledger	AI Operations, Chapter 29	An extract of the register of events and claims for a year, each with date, measurement and state (verified, expired, failed_in_operation).
Year-in-review register	AI Blue, Chapter 26 and Appendix A	A register built from records, not memory, summarising a year; its basis is records-only.
Measure catalogue (MSC-LOOP-*)	AI Purple, Chapter 18 and Appendix A	The measures a board page may show, at which grain, with a gaming check for each; forbids person-level grain and sets a minimum group size.

The records in the last four rows are accounts of a decision period rather than decisions about a system; they sit with the AIDR because each is written to be read by those who must hold the organisation to account, and cite the AIDRs that preceded them.

Records that travel with the AIDR

Tool	Kind	Origin	Purpose
Model card	Artefact	AI Platform and Security, Chapter 5	Version-controlled description of a model's intended use and limits, generated from the training run and evaluation report; its limitations block is what a pipeline cannot write.
Algorithm register entry (public)	Artefact	AI Governance, Chapter 17	A public-facing description and structured entry (NR-ALG-2026-003) generated from the internal inventory, modelled on the Dutch Algorithm Register (201, Dutch Ministry of the Interior, n.d.).
Versioned system prompt with metadata	Artefact	AI Platform and Security, Chapters 7 and 8 and Appendix A	A system prompt stored in the repository with YAML front matter for version, owner, linked AIDR and evaluation suite (prompts/*.md).
Agent skill for reviewing AI Decision Records	Artefact	AI Platform and Security, Chapter 11 and Appendix A	A reusable SKILL.md that checks a pull request touching aidr/ against the schema and the classification policy; it reports findings and never approves.

Across the usage modes

The unit of inventory and the primary record differ by mode, so the tools of this chapter are not applied uniformly. The table summarises AI Governance, Chapters 8 and 9, and AI Platform and Security, Chapter 5.

Mode	Unit of inventory and classification	Primary record
Mode 0 Ambient AI	Each supplier feature	Supplier-feature register; scope clause of the AI policy; an AIDR for each feature that processes personal or confidential data
Mode 1 Conversational assistants	The tool and its permitted uses	Descriptor with excluded_uses; one AIDR per service, not per user
Mode 2 Embedded workplace assistants	The tenant deployment	Descriptor and tenant configuration; one AIDR per rollout and per significant change of scope
Mode 3 Agentic work tools	The tool, its permissions and skills	Permission configuration and skills catalogue; one AIDR per tool
Mode 4 Built AI applications	Each system and its purpose	Inventory entry, risk register entry, assessments and AIDR; the full lifecycle gates
Mode 5 Autonomous production agents	Each agent and its delegated authority	Agent definition, permission manifest and stop path; the AIDR records the delegation

The low tiers in Modes 0 to 3 hold only while the permitted uses hold. The series' response is the excluded_uses list, which makes drift into a higher tier a visible change of intended purpose that re-runs the classification.

Nordvik Region and Hansa Mutual

Nordvik Region classifies once and against one regime. Its benefits-triage system is high-risk (Annex III point 5(a)) and the Region is a deployer, so the questionnaire, a FRIA and a DPIA are required; its internal staff assistant (AIDR-0211) is not, and carries an exception for supplier key rotation (EXC-NR-0007) that expires after 90 days. Its register entries must be readable by residents and journalists, which is why the public algorithm-register entry is generated from the same repository.

Hansa Mutual classifies the same system several times, once for each regime in the seven countries where it operates, so its register entries carry an applies_in block, and its stage risks (HM-LOOP-04) are written once for the group. It records exceptions to principles (EXC-0004, a hosted model it cannot rebuild) and to funding criteria (EXC-2026-012) as expiring records, and holds a register of ICT arrangements (HM-PROC-CLB-2028-04) that its change pipeline enforces. Both organisations are fictional and the records are the illustrative examples of the originating volumes.

Coverage

The inventory assigns 82 entries to this chapter: 57 artefacts, 22 methods and 3 third-party tools and standards. The chapter treats 19 principal tools in entries of their own (the ### entries above, several of which cover a pair or a family) and names every other entry in a family table with its origin and a one-line purpose, so that all 82 are accounted for; Appendix A holds the complete list. Several entries sit better in other chapters and are listed as reassignment candidates in data/findings/chapter_07.md: the decoy register entry, the operations loop, the investment gate lifecycle, the forum and decision-rights guides, the agent skill, the versioned system prompt, the model card, the measure catalogue, the year ledger and the year-in-review register.

Summary

The tools of this chapter share one conclusion: a governed organisation keeps a small number of records and lets each answer three questions, who owns this, what is it for, and when does it stop being valid. The inventory entry and the usage-mode register answer the first two for every mode; the questionnaire, the classification policy and the risk appetite statement turn a use into a tier; the register entry and the impact assessments say what could go wrong; the exception and the AI Decision Record carry the decision and its expiry.

Three practical conclusions follow from reading the volumes side by side. First, the same record exists at different grains in different volumes (a risk register entry for an AI system, a stage risk and a risk definition), and the grain, not the name, decides which to use. Second, every series volume reuses the AIDR with its own number range, so the identifier is part of the record's meaning. Third, an exception without an expiry, an assessment without a review trigger and an inventory without a derived deployment state are not weaker forms of these tools but different, unmanaged things. Chapter 8 turns to the tools that map obligations, assure them and measure maturity, which depend on these records as their evidence.

Sources

1. Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
2. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
3. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
4. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
5. Nordqvist, G. AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (5, Nordqvist, 2026)
6. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
7. Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (7, Nordqvist, 2026)
8. Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
9. Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
10. Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
11. High-Level Expert Group on Artificial Intelligence. Assessment List for Trustworthy Artificial Intelligence (ALTAI) for self-assessment. (46, AI HLEG, 2020)
12. UNESCO. Ethical Impact Assessment: A Tool of the Recommendation on the Ethics of Artificial Intelligence. (47, UNESCO, n.d.)
13. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 23894:2023 Information technology — Artificial intelligence — Guidance on risk management. (48, ISO/IEC, 2023)
14. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 42005:2025 Information technology — Artificial intelligence — AI system impact assessment. (49, ISO/IEC, 2025)
15. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). (50, NIST, 2023)
16. Open Policy Agent Contributors. Open Policy Agent Documentation. (51, Open Policy Agent, n.d.)
17. UNESCO. Readiness Assessment Methodology: A Tool of the Recommendation on the Ethics of Artificial Intelligence. (52, UNESCO, 2023)
18. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (195, European Union, 2024)
19. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (196, European Union, 2016)
20. Ministry of the Interior and Kingdom Relations. The Algorithm Register of the Dutch government. (201, Dutch Ministry of the Interior, n.d.)