Introduction: A Toolbox for the Series
A practitioner who needs "the tool for X" in The Transformed Architecture has until now had to know which of ten books to open. A service record sits in the appendix of one volume, the rules-of-engagement manifest in two others, the delegation profile in four, and the open standard that a detection rule is written in is named in the chapters of a fifth. Tools is the eleventh volume of the series and the only one that is read by looking things up. It collects what the ten earlier volumes define or use, organises it by what the practitioner is doing and says for each tool what it is for, when to use it, what it needs, what it produces and which chapter of which volume holds the reasoning.
This chapter sets the rules of the reference. It defines the four kinds of tool the book treats and says what it does not treat. It explains how the book was compiled from an inventory of the ten volumes, so that the reader knows what the catalogue claims and what it leaves out. It shows how an entry is built and gives each kind of reader a path through the book. It closes by introducing the two fictional organisations, Nordvik Region and Hansa Mutual, that run through the series and through the final part of this book. Chapter 2 then describes the anatomy that all artefacts share, and Chapter 3 treats how a tool is chosen, adopted and retired.
The book builds on the ten volumes and refers to no later volume. It refers to the first volume as Architecture as Code (Chapter N) (1, Nordqvist, 2025) and to the others as AI Governance, Chapter N (2, Nordqvist, 2026), and so on down to AI Operations (10, Nordqvist, 2026). Those citations record where the series defines a tool. They are never the source for a fact about third-party software, which cites its own documentation.
What a tool is
The series uses the word "tool" more widely than everyday speech does, because the practitioners it addresses use more than software. A reviewer of an AI system uses a decision record. A platform team uses a policy engine. An operator uses a procedure for deciding when to page someone. All three are tools in the sense of this book, and they are of three different kinds. The book distinguishes four.
An artefact is a template, manifest, record, register, checklist, policy or schema that a book defines. It is a document with a structure, usually written as YAML or Markdown, kept in version control and read by people and often by software as well. The service record, the delegation profile, the mandate manifest, the rules-of-engagement manifest and the service level objective record are artefacts. Artefacts are the largest group in the inventory, and most of them are identified by a family prefix such as SVC-* or DLG-*. Chapter 2 treats those families.
An own tool is software or a script that a book or its repository provides. The best-known example is the Maturity Radar of Architecture as Code (1, Nordqvist, 2025). Each volume also has a repository of publishing scripts that builds its PDF, EPUB and DOCX editions, renders its diagrams and checks its citations. Those scripts are inventoried but are not treated in the chapters of this book: they serve the publishing of a volume, not the practice a volume describes, and Appendix B lists the ones of this repository.
A third-party tool is software, a platform, a library, a service or an open standard that a book names as something practitioners use. Terraform, Open Policy Agent, Sigma and the MITRE ATT&CK and ATLAS knowledge bases are of this kind. The book describes such a tool only from its own documentation or standard, states what kind of thing it is and what the series uses it for, and stops where the series' claims stop. Where an earlier volume names a tool only in passing, the inventory records that, and so does this book.
A method is a named, repeatable procedure that the reader applies. Burn-rate alerting, a game day, a pre-mortem, a blameless review in a fixed time and the constructive debate in four steps are methods. A method differs from a general idea in that someone could follow it on Monday: it has steps, an input and an output.
Laws and regulations are not tools. The AI Act, the GDPR, DORA and NIS 2 are the instruments that obligations come from, and the books attribute statements to them by instrument and article. A tool may help to evidence an obligation, such as a record that a deployer keeps for the purposes of the AI Act, but the obligation is not itself a tool, and this book does not present any entry as legal advice. Likewise the series' own concepts are not tools unless they are written down as an artefact or applied as a method. The usage modes, from Mode 0 Ambient AI to Mode 5 Autonomous production agents, and the degrees of delegation, from Level 0 Advisory to Level 4 Autonomous, are concepts. A delegation profile that sets a ceiling per action class and level is an artefact that uses them. The distinction matters in the entries, because a reader who sees a Level in an entry should know that the entry applies a concept defined elsewhere.
What the four kinds have in common
The kinds differ in form but not in how the book treats them. Each has a purpose that can be put in one sentence, a moment when it is the right choice, something it needs and something it produces. Each has a place of origin, in the sense of a book and a chapter that explain why it exists. The entries of Parts II to VII state these properties in a fixed order, and the next sections explain how that order is used.
The book also keeps in view that tools age. An artefact that is not reviewed decays into a form that nobody trusts. A third-party tool changes version. A method that was introduced for one situation is applied to another where it does not fit. The series' answer, developed in AI Operations and used throughout this book, is that a claim about a tool, as about a service, needs evidence that carries a date (10, Nordqvist, 2026). Chapter 2 shows how the artefacts carry that date and Chapter 3 treats the decision to retire a tool when the evidence runs out.
How the book was compiled
Figure 1.1: The four kinds of tool, the inventory of Books 1 to 10 and the eight parts of the book.
The catalogue is not a list of what the author remembered. It was compiled from an inventory of all ten volumes, made by reading each volume's chapters and appendices in turn: the headings, tables, code blocks and summaries, and the repository's scripts and interactive tools. For each tool the inventory records the name as the book gives it, the kind, the identifier family where there is one, a short activity grouping, the purpose in one sentence, the chapters and appendix sections where the tool appears, the file and heading where it is defined, whether the book gives a full template and, for third-party tools, the bibliography sources that the book cites. A tool is entered once per book, with all its chapters listed.
The inventory held 1,629 entries when the book was compiled. Table 1.1 gives them by kind and Table 1.2 by volume.
| Kind | Entries |
|---|---|
| Artefact | 641 |
| Method | 378 |
| Third-party tool | 370 |
| Own tool | 240 |
| Total | 1,629 |
Table 1.1: The inventory by kind.
Of the 240 own tools, 227 are the publishing scripts of the ten repositories. They are inventoried so that the record is complete and are listed in Appendix A, but they are not treated in the chapters. The remaining 13 own tools, and the other 1,402 entries, are the tools that the chapters treat. Of the 370 third-party entries, 114 are mentioned only in passing in their book; the rest are described or relied on in an example. For 533 entries the originating book gives a full template, a worked configuration or a code example.
| Book | Volume | Entries |
|---|---|---|
| 1 | Architecture as Code | 252 |
| 2 | AI Governance | 148 |
| 3 | AI Platform and Security | 183 |
| 4 | AI Red Team | 134 |
| 5 | AI Threat | 117 |
| 6 | The Transformed Security Architect | 154 |
| 7 | AI Boss | 109 |
| 8 | AI Blue | 105 |
| 9 | AI Purple | 168 |
| 10 | AI Operations | 259 |
Table 1.2: The inventory by volume. The counts include the publishing scripts of each repository.
The counts say how many tools each volume defines or names, not how useful the volume is. A volume that reuses an artefact family from an earlier one adds few entries of its own, and a volume with many chapters of method adds many.
How the entries became chapters
Each inventory entry is assigned to the chapter of this book that treats it. The assignment was first made by keyword rules over the entry's name, purpose and activity, and is then reviewed by the editor, so that a tool sits where a practitioner doing that activity would look for it. This is a convention, and it has a consequence for the reader: an entry may be related to the topic of two chapters and treated in one. Appendix A is the safeguard. It lists every entry in the inventory, with its kind, origin, purpose and identifier family, and the reader who does not find a tool in a chapter should look it up there, by name or by identifier prefix.
The chapters do not repeat the arguments of the earlier volumes. Each treats its tools in families, with a short prose introduction to the problem the family solves, and gives an entry for each principal tool. Minor variants, such as a second template of the same family or a worked example of the same artefact for the other organisation, are named in a family table and left to Appendix A. A closing paragraph in each chapter says how many inventory entries the chapter treats, so that the reader knows what has been left out of the prose.
Three rules follow from the compilation, and the book keeps to them.
First, nothing is invented. Every tool in a chapter traces to an inventory entry, and every inventory entry traces to a passage in an earlier volume. A purpose, a field or an identifier is what the originating book says. Where the originating book gives no figure or field, the entry gives none.
Second, where the volumes disagree, the disagreement is recorded. The inventory found cases of the same identifier prefix used for two different artefacts, an appendix that names a template that was never written, and a chapter that shows a script the repository lacks. The chapters say which volume defines a tool when two volumes disagree, and Chapter 25 draws the recorded inconsistencies together instead of hiding them.
Third, the order of the series holds. This book refers to Books 1 to 10 and to no later volume, and each tool is attributed to the volume that defines it. If an earlier volume borrowed an artefact from one before it, the entry names the volume where the artefact is defined and notes the later variants.
How to read an entry
The chapters of Parts II to VII open with the activity they serve, name the kinds of tool they treat and say which volumes they come from. Then they treat the tools in families. A family is a group of tools that solve one problem and relate to one another, such as the records of a service (the service record, the objective record, the runbook manifest) or the records of a finding (the finding record, the evidence manifest, the regression case). The family's introduction says how the tools relate, and the entries follow.
An entry has a ### heading with the name as the originating book gives it. A compact table follows, with the rows below. A row is omitted when the originating book does not say.
| Row | What it tells the reader |
|---|---|
| Kind | Artefact, own tool, third-party tool or method |
| Origin | The book and chapter that define the tool, in plain text, for example "AI Operations, Chapter 5" |
| Purpose | One sentence, taken from the originating book |
| Use when | The situation in which the tool is the right choice |
| Inputs | What the tool needs before it can be used |
| Outputs | What it produces, and where the output is kept |
| Identifier family | The prefix of its identifiers, such as SVC-*, where it has one |
| Full template | Where the originating book gives the whole template |
Table 1.3: The rows of an entry.
Two to six sentences of prose follow the table, saying how the tool is used and what to watch for. Where an entry has a full template, the chapter quotes it from the originating book, abbreviated only by removing whole fields, and says which version it quoted. The chapter keeps the quotation valid YAML and replaces only book-specific example values with placeholders. A chapter quotes two to four templates in full; for the others the entry names the book, chapter and appendix section.
Chapters in Parts II to VII also carry two fixed subsections near the end. The first is ### Across the usage modes or ### Across the degrees of delegation, a compact table or a sentence saying how the chapter's tools differ between Mode 0 Ambient AI and Mode 5 Autonomous production agents, or between Level 0 Advisory and Level 4 Autonomous, as the originating books define them. A tool that does not differ says so. The second is ### Nordvik Region and Hansa Mutual, which says how the two fictional organisations use the chapter's tools, using only facts established in the earlier volumes. A Summary then gives the chapter's own conclusions, and ## Sources lists what the chapter cited.
Evidence and age
A reader of the entries will notice one habit of the series that is carried into this book. A statement that something is covered, recoverable or competent is not made without saying what was tested, when and with what result. The templates of AI Operations and AI Purple give the habit a form: the service record carries, for each dependency, the test, the date, the result and the age in months of the evidence (10, Nordqvist, 2026), and the coverage record of AI Purple carries the age of the evidence for each technique (9, Nordqvist, 2026). When an entry in this book says that a tool "verifies" or "evidences" something, it refers to the tool's output and its date, not to a promise.
Where the tools differ by level of delegation
An AI system in the series is an actor with a mode and a level, not a colleague. An agent enriches, correlates, flags, recommends, drafts or executes a runbook; it does not intend or understand. Where the originating books delegated a decision to a system formally, the record says who delegated it. The entries of this book follow that language. They also follow the series' rule that Level 4 Autonomous is not used for an irreversible action on production data, for an action that decides about a named person's access to work, or for an action that disables the observation or the stop path itself, as the volumes in which the artefact is defined set out.
A path for each reader
The book is organised by activity, so the reader's path depends on the work in hand. Table 1.4 suggests a first chapter and the parts to follow for eight kinds of reader. Every path begins with this chapter and Chapter 2, because the entries assume the anatomy described there.
| If you are | Start with | Then |
|---|---|---|
| An enterprise or security architect | Chapter 4, architecture and decision tools | Chapter 5 (policy, pipeline and evidence), Chapter 6 (platform and infrastructure), Chapter 10 (threat modelling) |
| A platform or DevSecMLOps engineer | Chapter 6, platform and infrastructure tools | Chapter 5, Chapter 18 (mandates and delegation), Chapter 20 (defending the agent) |
| An AI governance, risk or compliance lead | Chapter 7, inventory, classification and risk | Chapter 8 (obligation, assurance and maturity), Chapter 9 (supplier and sovereignty), Chapter 23 (weighing evidence) |
| Procurement, legal or sourcing | Chapter 9, supplier, contract and sovereignty tools | Chapter 8, Chapter 13 (response and recovery, for exit and resilience records) |
| A security practitioner in red, blue or purple work | Chapter 10, threat modelling and adversary frameworks | Chapter 11 (red teaming and emulation), Chapter 12 (detection and investigation), Chapter 14 (the verification loop) |
| An operator, site reliability engineer or incident commander | Chapter 15, observability and service objectives | Chapter 16 (change, restore and runbooks), Chapter 13 (response and recovery), Chapter 19 (observers and stop paths) |
| A line manager, HR lead or employee representative | Chapter 22, tools for managing people with AI | Chapter 21 (role and competence), Chapter 18 (mandates and delegation) |
| A board member or programme owner | Chapter 24, building a toolbox | Chapter 25 (conclusions), Chapter 3 (choosing, adopting and retiring) |
Table 1.4: A path through the book for each kind of reader.
A reader with a question rather than a role has two shortcuts. If the question is "what is the template for X", search Appendix A by name or by identifier prefix, which gives the kind, the originating book and the chapter that treats the entry. If the question is "what does the series say about X", follow the entry's Origin row to the chapter of the earlier volume that holds the reasoning.
A worked example: the incident review
A reader prepares the post-incident review of a service outage and wants the series' tools for it. She searches Appendix A for the prefix PIR-* and finds two artefacts. AI Blue defines a post-incident review that records findings, owners, changes and the re-test that closes each finding, together with a facilitated review format that takes ninety minutes (8, Nordqvist, 2026). AI Operations defines a post-incident review that states who took part, how the timeline was drafted and verified, what independent accounts were written before the session, the contributing conditions with evidence and what AI did in the analysis, together with a problem record that tracks each action to a verified closure (10, Nordqvist, 2026). The two share a prefix and serve two kinds of incident, a security incident and a service incident, so the reader's first decision is which one fits.
For a service outage she takes the second, and the Inputs row of its entry sends her to the incident record (INC-*), the change log and the accounts. The entries around it, treated mainly in Chapters 13 and 16, give her the incident record, the runbook manifest and the restore-test record that the review will cite. She reads the Origin row of each to find the chapter of AI Operations that holds the reasoning, and reads that chapter only where the entry leaves a gap. The search, the choice between the two reviews and the reading of three entries take the ten minutes that the book sets as its test of a reference: a practitioner should find the tools her next piece of work needs in about that time.
Nordvik Region and Hansa Mutual
Two fictional organisations run through the ten earlier volumes. They are defined once, in a profile that the volumes share, and every worked example agrees with it. Tools meets them in Part VIII, where Chapter 24 follows them as they build a toolbox, and in the closing subsection of each chapter of Parts II to VII. Neither organisation is real; the names, figures, systems and documents are invented, and real legal instruments are named only to show which obligations apply.
Nordvik Region is a regional public authority in a Nordic member state of the European Union, responsible for regional health and social-care coordination, regional development and public transport, and the administration of needs-based financial assistance for its municipalities. It has about 6,000 employees and serves about 450,000 residents. It works under one jurisdiction and public law: it is a deployer of high-risk AI systems under the AI Act, in particular a benefits-triage system that ranks incoming applications and whose every case a caseworker decides. It is cautious, accountable to elected politicians and to the public, limited in budget and specialist skills and dependent on suppliers. It has no autonomous production agent at Mode 5. In operations it relies on a seven-person platform team and on a national shared-service provider, and the incidents of its history, such as the expiry of the identity provider's signing certificate on 2026-03-12 and the failed failover test of its portal on 2027-10-12, run through AI Operations (10, Nordqvist, 2026).
Hansa Mutual is a mutual insurance group headquartered in Hamburg, operating in several European countries, inside and outside the European Union, with about 9,500 employees. Its difficulty is the differences between jurisdictions: the EU instruments apply directly in its EU entities but supervision is national, and its United Kingdom and Swiss entities sit outside the Union, so the AI Act applies to them only where the output of an AI system is used in the Union (Article 2(1), point (c)), and DORA is addressed to the financial entities listed in its Article 2. It is commercially driven, has strong engineering capacity and a shared group AI platform, and operates agents with write access to production, including an IT-operations agent and a claims-triage agent at Mode 5. Its advantage is scale and the ability to build; its disadvantages are legal fragmentation and a larger attack surface from agents.
The two organisations are chosen to differ along the lines that matter for tool choice. Where Nordvik Region has one legal regime and few engineers, Hansa Mutual has seven regimes and many. Where Nordvik Region buys, Hansa Mutual builds. A tool that suits one often needs adaptation for the other, and the entries say so where the originating books do. Identifiers follow the same split: records of Nordvik Region carry the infix NR and those of Hansa Mutual the infix HM, as in SVC-NR-002 and SVC-HM-004, a convention that Chapter 2 explains.
Using the tools directly
The book is also a toolbox that can be used without reading it. The Tool Finder searches all 1,402 tools, templates, standards and methods that the ten earlier volumes describe. The Template Library holds 853 templates, policies, models and scripts quoted from them and 104 starter templates written for the artefacts that the books describe without giving a template, which can be viewed, copied, downloaded, checked for YAML syntax and filled in. The Toolbox Maturity tool assesses a toolbox against 35 practices on six levels, by the method in Appendix C. All three run in the browser and send nothing anywhere; they are on the book's website and in an offline web kit, and the templates are also available as packages per book and per chapter. Web Tools and Downloads lists them.
Summary
This chapter has drawn the boundary of the book and shown how to use it. A tool is an artefact, an own tool, a third-party tool or a method; laws are not tools, and the series' concepts become tools only when they are written down as an artefact or applied as a method. The catalogue was compiled from an inventory of 1,629 entries across the ten volumes, of which 227 are publishing scripts that are listed and not treated, and 1,402 are the tools that the chapters treat. Appendix A holds every entry, so a tool missing from the prose can still be found.
Three conclusions follow for the reader. First, a reference is useful in proportion to how fast it answers, and the book therefore fixes the order of an entry and the places where templates are quoted in full. Second, the catalogue is only as reliable as its sources, so each entry names the volume that defines the tool and records where volumes disagree. Third, the two organisations let the reader see a tool in use at two scales. A path through the book depends on the reader's work, and the table of paths and the search by identifier prefix give two ways in.
Chapter 2 now describes what the artefacts have in common: a purpose, inputs and outputs, an identifier family, an owner and a date on which the evidence is reviewed.
Sources
- Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
- Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
- Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
- Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
- Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)