Conclusions: One Toolbox for the Series

This chapter draws the book's own conclusions. Chapters 4 to 23 collected the templates, software, standards and methods of ten volumes into one reference organised by activity. Putting them side by side shows two things that no single volume could show. The first is how much the tools have in common: a shared anatomy, identifier families that link records into chains, evidence that carries a date, checks that are made from outside, and degrees of delegation that are earned and can be withdrawn. The second is where the volumes do not agree with each other or with their own repositories: an identifier used for two artefacts, a template that an appendix names but does not contain, a script that a chapter shows but that no repository holds, two versions of one standard, two scales for one idea. The disposition of this book promised to record such findings and not to hide them (DISPOSITION.md), and this chapter does so.

The chapter is the one place in the book where a claim may be the book's own conclusion without a citation of its own. Each conclusion therefore rests on a finding that a chapter of this book recorded from the originating volumes, and the text says which. The volumes themselves are cited as sources 1 to 10 of the bibliography: Architecture as Code (1, Nordqvist, 2025), AI Governance (2, Nordqvist, 2026), AI Platform and Security (3, Nordqvist, 2026), AI Red Team (4, Nordqvist, 2026), AI Threat (5, Nordqvist, 2026), The Transformed Security Architect (6, Nordqvist, 2026), AI Boss (7, Nordqvist, 2026), AI Blue (8, Nordqvist, 2026), AI Purple (9, Nordqvist, 2026) and AI Operations (10, Nordqvist, 2026).

The chapter has four parts. The first states what the toolbox shows about the series. The second lists the gaps and inconsistencies in tables grouped by kind, each with the book and chapter and the volume that should resolve it. The third says what a practitioner should do on Monday and labels every statement about the future as observable, expected or speculation. The fourth gives a short gap list for the editor of each earlier volume. Figure 25.1 shows the route from the ten volumes through the five patterns to the gaps and back to the editors.

Figure 25.1: The toolbox on one page. The dashed arrows show which pattern each group of gaps departs from; the last arrow returns the findings to the editors of the earlier volumes, after whose revision the inventory is run again.

What the toolbox shows about the series

The toolbox in numbers

The inventory that this book rests on holds 1,629 entries: 641 artefacts, 378 methods, 370 third-party tools and 240 own tools (Chapter 1). Table 25.1 shows how the entries fall across the ten volumes. The counts are those of the per-volume inventory files and are a first pass: the inventory notes of several volumes say that chapter numbers and some methods were found by keyword search and not by reading every chapter.

Book	Volume	Artefacts	Own tools	Third-party	Methods	With a full template
1	Architecture as Code	111	35	76	30	93
2	AI Governance	86	21	21	20	75
3	AI Platform and Security	95	22	53	13	76
4	AI Red Team	46	25	27	36	42
5	AI Threat	42	24	16	35	37
6	The Transformed Security Architect	49	22	42	41	42
7	AI Boss	42	22	10	35	34
8	AI Blue	44	14	19	28	30
9	AI Purple	66	27	33	42	53
10	AI Operations	60	28	73	98	51

Table 25.1: Inventory entries by volume and kind. Source: data/inventory/*.jsonl, counted for this chapter. The last column counts entries of any kind that carry a full template.

Three observations follow, and they are the first conclusions of the book.

First, the series ships almost no operating software. Of the 240 own tools, 227 are the repositories' publishing scripts, which Appendix B treats and the chapters do not. The remaining 13 are the 12 own tools of Architecture as Code (the Maturity Radar, the ADR and Structurizr scripts, and four workflow files) and the validate_artefacts.py listing of AI Purple, which exists only as a code block in that volume's Appendix A and not as a file (Chapters 4, 8 and 14). Chapter 11 and Chapter 19 add the negative findings: no volume provides an emulation engine, and none provides observer, probe or heartbeat software. What the later volumes call tools are texts, records and procedures that an organisation builds into its own estate. That is a deliberate position, but it has a consequence for every reader: the checks the volumes describe, such as a manifest validator or an independence test, are designs to implement and not programs to install.

Second, the volumes become more artefact-led and more method-led as the series goes on. Architecture as Code (76), AI Operations (73) and AI Platform and Security (53) carry the largest numbers of third-party tools, because they describe the delivery, platform and operating toolchain. Methods, which are in practice the practical guides that each chapter ends with, make up 7 to 14 per cent of the entries of Books 1 to 3 and 25 to 38 per cent from Book 4 onward; AI Operations has 98. The later volumes also rely on earlier ones for many of their tools: AI Boss borrows the reversibility test from AI Threat, and AI Blue, AI Purple and AI Operations reuse the observer principle and the usage modes rather than redefining them. The series is cumulative by design, and the inventory confirms it.

Third, about a third of all entries (533 of 1,629) carry a full template. The remaining entries are described in prose, in tables or in practical guides. A reader who looks up "the template for X" will sometimes find a procedure and not a file; the Origin row of each entry in Chapters 4 to 23 says which.

Five patterns that recur

The chapters of Parts II to VII treated very different activities, from architecture decisions to the stop path of an agent. Five patterns recur in all of them. Each is a conclusion of this book and rests on the chapters named.

Pattern 1: a shared anatomy. Chapter 2 found that artefacts across the series state a purpose, inputs and outputs, carry an identifier from a family, name an owner, cite the decision record that approved them, link to the records they depend on, and state a review date and an expiry for their evidence. The field names differ between volumes, and Chapter 2 records examples: decision_record against decision, owner against owner_role. The anatomy is nevertheless recognisable from AI Governance to AI Operations, and Chapters 5, 14, 15 and 16 found it again in evidence manifests, session records, service records and change records. The conclusion is that the series has one design with many dialects. A reader who has learned the anatomy once can read any record in any volume; a reader who expects the same field names will be disappointed.

Pattern 2: identifier families that link records into chains. Chapter 2 traced a chain from the service record SVC-NR-002 through its objective record, the failed restore test RST-NR-2027-002, the change CHG-NR-2028-0007 and the risk acceptance in DRF-NR-001, and a second chain in AI Purple from scenario to coverage. Chapter 13 followed an incident to a post-incident review and a re-test; Chapter 18 followed a decision record to a profile, a mandate, an enforcement point, an observer, a budget and a register. A chain can be walked in both directions, and that is what makes a claim checkable. The identifier is therefore the series' most important design element, and it is the one on which the series is least consistent: the reservation of ranges for AI Decision Records (0500 to 0999 from The Transformed Security Architect onward, split by organisation in AI Blue, AI Purple and AI Operations) is the only reservation of its kind, and almost every other family has no rule against reuse (Chapter 2). The gaps in the next part are, for the most part, consequences of this.

Pattern 3: evidence age. In every domain the chapters found the same discipline: a claim without a date is not a claim the organisation can make. The restore test has a date and a condition (Chapter 13); a detection is verified only if it fired in the last 90 days, or in AI Purple within 90 days for priority techniques and 180 for others (Chapter 14); a competence record expires (Chapter 21); a horizon register is reviewed on a schedule and a trigger can reopen it (Chapter 23); and a runbook that is past its review date drops a level (Chapter 16). The conclusion is that the series treats evidence as perishable. The tools differ only in how long the evidence lasts, and that is where the series is least uniform (Table 25.8).

Pattern 4: independence. Chapters 14, 15, 16 and 19 reached the same conclusion from different directions: a check is evidence only if the side that performs it can fail in ways the side being checked does not share. A progressive-delivery controller can abort a rollout but should not be its only judge; the correlator in an alerting chain needs a golden set held outside it; a coverage claim needs a test by someone other than the thing tested; and a stop path is held outside the system it stops. AI Purple names five kinds of independence (model, data, authorship, vendor, time) and AI Operations six (model, data, authorship, credential, failure domain, time); Chapter 19 uses the union and records that neither volume reconciles the two. The conclusion is that independence is a property of a claim and comes in kinds, so a record that says only "a different model checked it" proves one kind and no more.

Pattern 5: autonomy that is earned, budgeted and revocable. Chapter 18 found that the mandate, the delegation profile, the autonomy budget, the register and the reversibility test obey the same rules in every volume that has them. An unlisted action is undelegated; the lowest ceiling governs; Level 3 needs a codified playbook and a decision point outside the agent; a rise is a recorded decision by a named authority and a fall is immediate. Chapter 19 added that the level is earned with shadow, offline, seeded and stop evidence and that demotion is automatic when the evidence lapses. The books differ on the numbers (stop times, token lifetimes, which actions are barred from Level 4), as Table 25.8 shows, but not on the structure.

These five patterns are not independent of each other. The anatomy is what makes an identifier worth reserving; the identifier is what lets a date be attached to a claim; the date is what lets an independent party decide whether the claim still holds; and the level of autonomy is only as good as the claim about the evidence for it. Chapter 3 drew the practical consequence for adoption and Chapter 24 draws it for two organisations. The consequence for the series is that its gaps are not random. They cluster where one of the five patterns has not been made explicit: where an identifier is shared, where a date or a duration is a local default, where an independence kind is named differently, and where a level carries different prohibitions.

Gaps and inconsistencies in the earlier volumes

How the list was made

The list below aggregates the findings files of Chapters 1 to 23 (data/findings/chapter_01.md to chapter_23.md) and the ten inventory notes (data/inventory/*_notes.md). Each writer of a chapter opened the originating chapter or appendix in the earlier volume and recorded what did not agree. The items are therefore what the writers found while compiling their own chapters, not the result of a systematic audit of the ten volumes. A volume with few items has not necessarily fewer faults; it may have had fewer of its tools treated closely. The state is that of the checkouts as at 11 November 2026. Some volumes were still being revised: The Transformed Security Architect is recorded in its inventory notes as in draft status with a red-thread review open, and AI Purple has open items in its handover file, including bibliography entries awaiting merge, so that its source numbers may change.

Two rules fix who should resolve an item. The series builds in publication order and no volume refers to a later one, so a conflict between two volumes can be reconciled in a text only by the later of them, which may state the relation to the earlier or choose a distinct identifier. The earlier volume can correct only its own internal faults. Where the table says "Book N", it names the volume whose editor should act. A fault of this book's own (for example an inventory entry that is a false positive) is recorded at the end of this part.

An item is not necessarily a defect. Several are differences of ceiling and starting point, or of detail and summary, that are easy to misread; the findings say so where that is the case, and the tables say "documented" where the originating volume itself notes the difference.

Identifier families used for more than one artefact

An identifier prefix that names two artefacts forces the reader to read the Origin row before assuming which is meant (Chapter 2). A count of the id_prefix field of the inventory, excluding the organisation codes HM, NR and AI, finds 32 prefix families that appear in two or more volumes. Many of those are intended reuse: AIDR-*, MND-*, DLG-*, ROLE-*, CMP-*, HZN-* and AP-* are families that the later volumes deliberately extend. Table 25.2 lists the cases in which the findings show that the reuse produces different artefacts or different shapes under one prefix.

Prefix	Uses found	Book and chapter	Resolve in
CHG-*	Operational change record; model-change record; improvement change added for a finding; fictional ticket-era and code-era pair	10, Chapters 2, 8, 13 and Appendix A.4, A.9; 9, Chapter 10	Book 10, with a statement of the relation to Book 9
CAP-*	Capacity record; AI cost-and-latency budget	10, Chapters 11 and 15	Book 10
RST-*	Restore-test record; exit-test record	10, notes	Book 10
INC-*	Base incident record; AI incident record with clock sheet	10, Appendix A.3 and A.10	Book 10
PIR-*	Post-incident review with FND-* findings; post-incident review with contributing conditions and PRB-*	8, Chapter 11; 10, Chapter 12	Book 10
STOP-*, SPT-*	Two names for a timed stop-drill record; Book 10 uses both and defines SPT-* nowhere	6, Chapter 10; 5, Chapter 24; 10, Chapters 4, 10, 17	Book 10
DLG-*, DRF-*	Delegation profile per system, team, stage or agent; decision-rights file with checker (DLG-HM-OPS-02); DRF-* for decision-rights tables	7, 8, 9, 10; Appendix A.18 of 10	Book 10 for its own two uses; Book 8 for DRF-* against DLG-*
DLG-* (internal)	DLG-HM-OPS-001 and DLG-HM-OPS-02 in one volume; DLG-HM-EMU-01 named in Chapter 14 but absent while Chapter 4 and Appendix A give DLG-HM-LOOP-01; Nordvik's loop delegation as both DLG-NR-LOOP-01 and DLG-NR-EMU-01	10; 9, Chapters 4 and 14	Books 9 and 10, each for itself
MND-*	Mandate per agent team (6), per agent and system (7, 8), per emulation agent (9), per operations agent with three-digit numbers (10); schemas differ	6 to 10	Book 8 and following, each stating its schema
CP-*	Containment profile; permission manifest of a SOC agent	6, Chapter 7; 8, Chapters 13 and 15	Book 8
OQM-*	Oversight-quality metric with four signals; the same identifier OQM-HM-CLM-01 as a metric with seeded-case catch and rejection rate; a third shape in review protocol and oversight report	5, Chapter 14; 7, Chapter 26 and Appendix A; 8, Chapter 14	Book 7, then Book 8
EVD-*	Graded evidence record; re-test evidence manifest; EVD-NR-2027-* cited but not defined	5, Chapter 4; 9, Chapters 11 and 16; 8, Chapters 27 and 28	Book 8 (define or remove), Book 9
FND-*	JSON emulation finding; YAML finding record; a third shape with kind: finding	4, Chapters 12 and 26; 9	Book 4 for its two, Book 9 for the third
SCE-*	Chaos experiment manifest (SCE-DE-014); recovery experiment (SCE-RC-007)	4; 6, Chapters 11, 25, 26	Book 6
RP-*	Recovery plan as code; model-routing and carbon policy	4, Chapter 22; 5, Chapter 17	Book 5
EVAL-*	Golden-dataset evaluation of a security AI component; sycophancy evaluation	4; 5	Book 5
RTS-*	Return-to-service evidence record; checklist	4, Chapters 22 and 23	Book 4
DIT-*	Release-pipeline configuration DIT-NR-CR-01; test records DIT-HM-CTA-01, DIT-NR-ROS-*	5, Chapter 12; 7, Chapters 12 and 24	Book 7
EXIT-*	Exit procedure EXIT-004; EXIT-NR-01 as a dependency in one volume and as the benefits-triage system's plan in another; the EXIT-NR-01..03 plans referenced but defined in no template	2, Chapters 6 and 7; 5, Chapter 15; 6, Chapter 20	Book 6 (renumber), Book 5 (define or reference)
EXC-*	Principle exception; portfolio exception; security-control exception	2, Chapters 4 and 16; 6, Chapter 17	Book 2 for its two; Book 6
RISK-*	Four differently shaped risk records (RISK-0047, RISK-2026-014, RISK-NR-0031; HM-LOOP-* in Book 3)	1, Chapter 9C; 2, Chapter 8; 3, Chapter 9; 6, Chapter 17	Book 6, with Book 2 for its own
THR-*	Threat register entry; identifier of the one-page board briefing	5, Chapters 22 and 32	Book 5
AP-*	Anti-pattern record with four schemas in Books 6, 8, 9 and 10, and AP-01 to AP-12 as checklist items in Book 7; Book 9 says its family follows Book 8, Book 10 says it follows Book 9, and Book 6 (earlier than both) has a third shape	6, 7, 8, 9, 10	Book 8, with Books 9 and 10 following
ADR-0003	Two decisions with one number in one repository (adr/ADR-0003-selection-of-terraform.md and docs/examples/structurizr/adrs/ADR-0003-structurizr-manifest-drift.md)	1, repository	Book 1
RoE-NR-2027-001	Shorter manifest without version or safety classes; longer version 1.2.0 with safety classes S1 to S3 (documented as an extension)	4, Appendix A; 9, Appendix A	Book 9 (documented)
CMP-*, LP-*, ROLE-*	No reserved ranges, unlike AIDR-*; no collision found, but nothing prevents one; ROLE-AI-OWNER follows a different pattern	2, 6, 7, 8, 9, 10	Series convention (see Monday)
Programme codes	HM-SEC-006 is the chaos platform in two volumes; NR-SEC-004 is Nordvik's chaos programme in Book 4 and its restore-drill programme in Books 6 and 10	4, 6, 10	Book 6
AIDR-*	Ranges reserved per volume from Book 6; Books 2 to 5 carry records without a stated range; in Book 7 Appendix B gives Nordvik 0600 to 0649 and Hansa 0650 to 0699 while the repository's instructions state only 0600 to 0699	2 to 7	Books 2 to 5 (state their range)

Table 25.2: Identifier families that name more than one artefact. Sources: findings of Chapters 2, 4, 5, 8, 9, 11, 13 to 16, 18 to 21, 23.

The same artefact under several names or shapes

The mirror image of a shared prefix is one artefact that appears under several names, identifier forms or schemas. Table 25.3 lists them. In most cases the volumes are not in conflict; they simply did not reconcile, and Chapters 4 to 23 each say which form they quote.

Artefact	Forms found	Book and chapter	Resolve in
Incident record	HM-INC-2027-0142; INC-HM-2028-0871 and INC-NR-2028-0163; INC-HM-2027-0455; unprefixed INC-2026-0457 inside an incident_classification block	4, Chapter 20; 10, Appendix A.3 and A.10; 8, Appendix A; 2, Chapter 11	Book 10 (state the series form)
Evidence manifest	Six entries in six volumes; three carry kind: EvidenceManifest with three different apiVersion values (evidence.aiarch.example/v1, ai-architecture.example.eu/v1, none); in Book 6 only a block inside the CTRL-* entry although Appendix B lists it separately	1 (15A), 2 (11), 3 (Appendix A), 6 (9, 19), 8 (27, 28), 9 (11, 16)	Book 6, then Book 9
Recovery artefact	Recovery plan RP-*; recovery definition RCV-*; recoverability claim with restore-test record	4; 6; 10	Book 10
Recovery objectives	rtoMinutes: 240; recoveryTimeObjectiveHours: 8; ISO 8601 PT4H	4, Chapters 22 and 24; 10, Appendix A.15	Book 4 for its two; Book 10
Containment profile and permission manifest	AgentContainmentProfile under agents/*/containment.yaml; CP-*; platform.example.eu/v1 AgentContainmentProfile; CP-HM-SOC-01 called both profile and permission manifest	3, Chapter 19; 4, Chapter 4; 6, Chapter 7; 8, Chapters 13 and 15	Book 8
Threat model	Three schemas for kind: ThreatModel (review_trigger against reviewTrigger; different residual and review fields); Book 6 Appendix B calls it "Threat-model manifest"	3, Chapter 17; 4, Chapter 10; 6, Chapter 6	Book 6
Model-routing policy	ModelRoutingPolicy; RoutingPolicy in Appendix A; routing_policy with RP-*; apiVersion domains .org, .eu, aiarch.example	3, Chapter 22 and Appendix A; 5, Chapter 17	Book 5
Capacity plan	CapacityPlan and GpuCapacityPlan with different apiVersion	3, Chapters 13 and 22	Book 3
Function map	Management function inventory (Book 7, "function map") against team/function-map.yaml	7, Chapters 1 and 2; 8, Chapter 2	Book 8
Correlation policy	"Correlation policy and noise budget" (Appendix B, controls only) against "Alert-correlation policy" ACP-* (Appendix A, with header, classes and levels)	10, Appendices A.2 and B.4	Book 10
Reporting clock	Per-incident CLK-* with per_instrument; per-service clock sheet stating four hours from classification and at most 24 hours from awareness	8, Chapter 19; 10, Chapter 14	Book 10
Coverage statuses	Three classes (verified, declared, failed); six statuses (verified, expired, implemented-unverified, failed, asserted, untested)	5, Chapter 30; 8; 9, Chapter 17	Book 9
Exit plan	Defined as a procedure, referenced as "defined elsewhere", described in prose	2, 5, 6	Book 6
Annex for a managed provider	MS-2 and OPA-NR-SD-01, overlapping on change notice, sampling, stop right and exit; MS-1 named without a template	8, Chapter 16; 10, Chapter 24	Book 10
Delegated patching	DelegatedPatchDecision DPD-* against AIDR-0554 for classes of HM-PATCH-SLO-2027	4, Chapter 11; 6	Book 6
Nordvik's first detection	Sigma id with author field NR-DET-0007; DET-NR-0001 adopted 2027-02-08; two different rules, no stated link	4, Chapter 19; 8, Chapter 6	Book 8
Appendix name against chapter name	Responsibility matrix = RACI as code; delegated-authority record = agent identity record; practice plan without AI = CKP-*; containment profile = permission manifest; incident clock = CLK-*; decision-rights table = DRF-*; oversight report = OQM-*	6, 8, Appendix B	Books 6 and 8

Table 25.3: One artefact under several names, identifier forms or schemas. Sources: findings of Chapters 5, 10, 11, 13, 14, 15, 17, 18, 20 and the inventory notes of Books 6 and 8.

Templates named but missing

Table 25.4 lists artefacts that an appendix or chapter names as a template and does not give. The listing is by book; "prose only" means that the originating volume describes the artefact but gives no text that a reader could copy. It is not a criticism where the volume says so: AI Governance states that technical templates are deliberately not collected in its Appendix C. It is, however, a gap for a reader who looks up the template.

Book	Named but not given (chapter or appendix)
1	Artefacts of Chapters 19, 20, 23, 26a and 26b are partly prose-only; issue templates for management decisions (Chapter 19); FINOS project blueprint (Appendix C, a proposal); pipeline stage table (Chapter 5); the ADR scripts and the course/ templates are described in no chapter
2	A standalone AI Decision Record template (AIDR-* is used throughout; the nearest full example is the inventory entry in Chapter 9); learning path, champions charter, declared intent and staff statement (Appendix C); the use-case descriptor UCD-* has a full example in Chapter 8 but is not in the inventory
3	System card outline and incident runbooks (Appendix B, no block in Chapter 5); compromised dependency or model artefact response (practical guide only); Annex A control mapping with evidence (a table in prose); the full requirements catalogue of some sixty entries is not in the repository
4	Prepared recovery message record HM-COMMS-RC-*; the manifest RoE-NR-2027-003; test file of the Sigma rule; agenda and metric definitions for the purple session (listed as planned); purple-align, named in a PurpleSession example and defined nowhere
5	Calibration log and one-page board briefing (Chapter 32); a shortcut-rate evaluation plan (listed in Appendix B but the Chapter 22 block is register entry THR-HM-03); the household and classroom agreement (a step-by-step guide); the EXIT-* plans referenced by the dependency map
6	Review checklist (said to be in Appendix A, which holds only the review record REV-*); prompt and skill record; permission manifest; evidence manifest (inside CTRL-*); exit plan (prose); delegation register (defined in Book 5); skills matrix
7	Contestation and appeal form (B.7), explanation template (B.9), co-determination checklist (B.12), clause set (B.13), weekly review protocol (B.18), development conversation guide (B.19), board report (B.20); DLG-HM-SPS-01, DLG-NR-HCD-01, DLG-HM-AB-01, DIT-NR-ROS-*, RVT-NR-ROS-* and WRA-NR-HC-01 appear in the text without a listing
8	MS-1, PRS-*, EVD-NR-2027-* and BTP-HM-2027 referred to but not defined; pre-production checklist, craft programme, fatigue and on-call review (Appendix B, no text); SOC-CF in a table only
9	Appendix B items B.1, B.6, B.9, B.12, B.13, B.15, B.16, B.20, B.21, B.26 and B.27 are described only; the TTX-* tabletop record; CSF profile kept as code
10	Golden incident set GLD-*, freeze calendar FRZ-*, stop drill STOP-*, dark-day record DKD-*, OPS-CF, board paper outline (described only); Appendix B has no entry for A.5, A.7, A.9 to A.11, A.14, A.16 and A.18 to A.22

Table 25.4: Templates named in an appendix or chapter and not given. Sources: findings of Chapters 3 to 23 and the ten inventory notes.

Appendix indexes out of step with the chapters

Four volumes have an appendix of templates that does not agree with the chapters in both directions. Table 25.5 sorts the findings by direction, because the direction says what the editor should do.

Direction	Finding	Book and location
Listed as planned, but present	Risk-appetite statement, supplier assurance requirements NR-SUP-*, asset record, patch-velocity policy, detection rule, incident record, guardrail policy and recovery plan are marked "planned" in Appendix B; each has a full worked example in a chapter. Chapter versions of two templates differ from Appendix A (AIDecisionRecord against AutonomyDecision; AgentPermissionManifest against PermissionManifest)	4, Appendix B
Present, but not listed	Capability snapshot, prohibited-practice check, procurement clauses, THR-NR-02, THR-HM-09, instrument mapping, threat statement, positive-scenario entry and register snapshot have full YAML in chapters and are absent from Appendix B	5, Appendix B
Present, but not listed	Appendix B has no entry for several Appendix A artefacts (A.5, A.7, A.9 to A.11, A.14, A.16, A.18 to A.22); the quality objectives SLO-HM-002-Q and the metric catalogue MET-* therefore exist only in Appendix A and the chapters	10, Appendix B
Listed, but prose only	Of 22 entries (B.1 to B.22) twelve have code in Appendix A	7, Appendix B
Listed, but absent	Review checklist; prompt and skill record; permission manifest; evidence manifest; exit plan; patch-velocity and stop-path test as separate artefacts (the book gives HM-PATCH-SLO inside AIDR-0554 and the STOP-* records)	6, Appendix B
Points to chapters, not files	Appendix B lists templates by lifecycle stage with chapter references	3, Appendix B
Appendix repeats the chapter	Appendix A holds four examples and duplicates the chapter blocks	5, Appendix A
Appendix excerpt differs from chapter	REV-HM-0001 against REV-HM-0014; MND-HM-01 excerpt without version or budgets against the complete Chapter 13 version; EVD-024-01 with nextReview 2027-02-02 against 2027-05-02; PRM-HM-OPS-001 manual_practice fields in Chapter 16 absent in Appendix A.12 and B.10	6, 5, 10

Table 25.5: Appendix indexes and chapter versions that do not agree. Sources: findings of Chapters 5, 11, 15, 16, 18, 23 and the inventory notes of Books 3 to 7 and 10.

Scripts and files shown but absent

The repositories contain publishing scripts, but the listings in the chapters are another matter. Table 25.6 lists the scripts and files that a chapter or appendix shows and that the repository does not contain, or that the volume says are illustrative.

Book	Shown in the text	Status
1	scripts/check_terminology.py and .pyspelling.yml (Chapter 20); scripts/export_mfa_snapshot.py (Chapter 15A); scripts/cost_analysis.py and /scripts/tests.sh (Appendix A); ./scripts/eu-security-validation.sh (Chapter 21); listings 15_CODE_1 to 15_CODE_3 and sustainability/carbon_aware_scheduling.py with no cost_monitoring/, kubernetes/ or sustainability/ directory; TerraformRunner (illustrative, stated)	Absent or illustrative
1	The ADR scripts read three different directories (adr/, docs/examples/structurizr/adrs/ and a docs/adr/ layout in Chapter 4 that the repository does not hold); the three catalogued ADRs have next_review_due dates that were past on 2026-11-11	Inconsistent paths
3	tools/redteam.py, tools/agent_fuzz.py and tools/evidence.py called by the CI workflow in Chapter 17; the model promotion pipeline (07_CODE_PIPELINE) is a workflow in the book and not in a repository	Absent
4	purple-align (named in an example, never defined); no emulation engine	Absent
9	validate_artefacts.py exists only as a code block in Appendix A and checks the field names of that volume (ceiling, level, maxLevel, restart_level)	Not a file
10	Rego gate and widening rule (A.4, A.5) and the Python and SQL of A.5 are illustrative and not run; the Rego of A.14 was not run against an engine; a mapping to OpenSLO is promised and no mapping file exists	Not executed
All	No observer, probe or heartbeat software; no emulation engine; no dashboard template	Not provided

Table 25.6: Scripts and files shown in the text and absent from the repositories, or stated to be illustrative. Sources: findings of Chapters 4 to 6, 11, 14 to 17, 19 and the inventory notes of Books 1, 3, 4 and 9.

Differing versions and superseded examples

Standards and software age, and the volumes were written over months. Table 25.7 lists the places where two volumes give different versions of one tool, or where a volume's own example no longer meets its later rule.

Subject	Difference	Book and chapter	Resolve in
SLSA	v1.0 provenance in one volume (page status retired there); v1.2 in two others	1; 3 and 10	Book 1
Terraform, OpenTofu	Versions are given only in Book 10 (Terraform 1.17.1, OpenTofu 1.13.9 on the stated dates), so the volumes age differently	1; 10	Book 10 (dated)
SCI specification	Cited from sci.greensoftware.foundation in Books 1 to 3 and greensoftware.foundation/standards/sci in Book 10	1, 2, 3, 10	Book 10
OpenTelemetry GenAI conventions	Cited under four different source numbers; described as part of the main documentation in one volume and as a separate conventions page in the others	2, 3, 9, 10	Each volume's editor
NIST IR 8596 (Cyber AI Profile)	Used as an initial preliminary draft of 16 December 2025 in one volume; later volumes cite "IR 8596 preliminary draft" without the date; status to be checked	4, Chapter 3; later volumes	Book 4
ATT&CK, D3FEND, TIBER-EU, Sigma	Added to Book 4's bibliography on 2026-11-02 and recorded there as "must be verified"	4	Book 4
Trivy	Listed as the scanner that absorbed tfsec and as a pipeline gate (Book 1); its 2026 compromise (CVE-2026-33634) is recorded in Book 3	1; 3, Chapter 9	Book 1
Argo CD	Application with prune: true and selfHeal: true on a production namespace tracking main; Book 10 sets prune off for stateful kinds, self-heal only for catalogued drift classes, and its checklist B.21 would fail the earlier listing	1, Chapter 7; 10, Chapter 8	Book 1
Istio retries	retries: attempts: 3, perTryTimeout: 2s (in Istio's HTTPRetry, attempts is the number of retries, so a request makes up to 1 + attempts tries, and perTryTimeout bounds each try) (249, Istio (n.d.), n.d.); Book 10 treats retries as the mechanism of retry storms and asks for a retry budget	1, Chapter 8; 10, Chapter 10	Book 1
Drift runbook	A Markdown procedure that would be Level 0 or 1 under Book 10's rule that a runbook above Level 1 needs a manifest with preconditions and verification	3, Chapter 21	Book 3
Structurizr CLI and tfsec	End of life, replaced by the structurizr/structurizr image; tfsec merged into Trivy; Terrascan archived (the volume says so itself)	1, Chapter 5	Book 1 (documented)
Gateway configuration	Written for a bank (spiffe://bank.example/...), not for the two organisations	3, Chapter 17	Book 3
Validator against decision record	validate_adrs.py accepts only ^ADR-\d{4}$; adr_id carries AIDR-NNNN values in Book 3 and would be rejected unchanged	1, Chapter 4; 3, Chapters 5 and 13	Book 3

Table 25.7: Versions and rules that differ between volumes. Sources: findings of Chapters 4, 5, 6, 10, 15, 16, 17.

Differing scales, defaults and definitions

Table 25.8 is the largest group and the one most likely to mislead a reader who combines tools from two volumes. In each row both numbers are correct in their own volume. No volume says which is the series default, and the table says which volume should state the relation.

Subject	Values found	Book and chapter	Resolve in
Maturity model	Six levels numbered 0 to 5 over ten "as code" disciplines (50 yes/no questions); five levels numbered 1 to 5 over eight dimensions; "optimised" means different things; both take the lowest value as the overall result	1, Appendix D; 2, Appendix B	Book 2
Competence levels	Awareness, practitioner, advanced, expert; Foundation, Practitioner, Advanced, Expert; "novice" in the IaC utility	2, Chapter 14; 1, Chapter 18; 6; 10, Chapter 26	Book 2
Competence record validity	24 months; 12 months; 90 days	6, Chapter 21; 8, Chapter 22; 10, Chapter 26	Book 8 and Book 10
Evidence age	90 days for a verified detection; 90 days for priority and 180 for other techniques; 180 days for restore evidence where the stated legal floor is 12 months	4; 9; 10	Book 9 and Book 10
Stop time	30 minutes (agent stop policy); 5 minutes for a Mode 5 agent with production write access (300 seconds in the observer manifest); 120 seconds (containment profile, generic default); 60 seconds (emulation runner HM-SEC-004)	2, Chapter 19; 6, Chapter 10; 10; 8; 9, Chapters 6 and 8	Book 8 and Book 9
Token lifetime and revocation	5, 10 or 15 minutes; 5 minutes for write and 60 for read; revocation in 60 seconds, 120 seconds or 5 minutes	3, 4, 6, 8, 10	Book 8
Level 4 prohibitions	Two (Book 8); four, different (Book 9); four (Book 10); outright for their agents (Books 6 and 7)	6 to 10	Book 9 and Book 10
Independence kinds	Five (model, data, authorship, vendor, time); six (model, data, authorship, credential, failure domain, time)	9; 10	Book 10
Meaning of "expected"	Strong evidence with uncertain timing or form within five years; likely within the planning horizon, typically three years; a stated trend or decided instrument	2, Chapter 22; 5, Chapter 4; 8, 9, 10	Book 5
Horizon registers	horizon: speculative against "speculation"; horizon against label; register: against horizon_register:; reviews at six months, twelve months, 180 days	2; 5; 6; 8; 9; 10	Book 2
Key metrics	"Four key metrics" in AI Operations, but five in the programme's guide as quoted (three throughput, two instability including rework rate); change_failure_rate targets (elite 5%, high 20%, medium 10%, low 40%) are not monotonic	10, Chapter 20; 1, 17_CODE_3	Book 1
Held-out share	0.25 in pipeline HM-SEC-004 against a library default of 15 per cent and at least eight scenarios (noted in the template)	9, Appendix A and Chapter 15	Book 9 (documented)
Template mode	usage_mode: 4 in B.9 against mode: "Mode 5" in B.2 for the same pair (Mode 4 proposes, the orchestrator executes; unexplained)	10, Appendix B	Book 10
Style of apiVersion	ai-threat.example.org/v1 in some artefacts, plain keys in others; further domains in other volumes	5; 3; 4	Each editor
Scorecard bands	A 15-criterion scorecard scored 1 to 5 gives totals of 15 to 39, all in the single band "below 40"	1, Chapter 26A	Book 1

Table 25.8: Scales, defaults and definitions that differ. Sources: findings of Chapters 3, 8, 11, 14, 15, 17 to 21, 23.

Faults inside a single volume

A further group is not a disagreement between volumes but a disagreement within one. Table 25.9 lists them. They are minor and easy to fix, and they are the items an editor can act on immediately.

Book and chapter	Finding
2, Chapter 20	Fifteen headed anti-patterns, a figure described as fifteen; the inventory says sixteen
2, Chapters 8, 9 and 17	The benefits-triage system carries different assessment and register identifiers (DPIA-2025-031 and DPIA-2026-007; FRIA-2026-004 and FRIA-2026-002; NR-ALG-2026-003, EUDB-2026-NR-00412 and EUDB-DEP-2026-004213)
2, Chapter 16A; 3, Chapter 23	Use case UC-2026-014 is a Mode 5 claims-triage agent governed by AIDR-0024 in one chapter and a claims-triage assistant whose go-live is AIDR-0034 in the other
3, Chapter 14	A seven-item readiness list whose YAML has seven keys that combine operations and capacity and omit the regulatory record
3, Appendix A (11_CODE_AGENT)	tools.allow names two servers, mcpServers pins only one, against the appendix's own statement that servers are pinned by version and digest
6, Chapter 14 and Appendix A	Review record numbered REV-HM-0014 in one and REV-HM-0001 in the other
7, Chapter 7	AIDR-0601 (2026-09-18) is filed under AIDR-0600, dated 2026-11-16, later than the pause
7, Chapter 27	Nordvik's time limit to answer a contest was 14 days in AIDR-0624 and 10 working days in FRIA-2026-007, until AIDR-0631 set 10 working days and at most 14 calendar days
8 and 9	DET-HM-0455 last simulated 2027-03-02 with review 2027-09-02 in one volume, last passing test 2027-12-14 in the other; compatible only if a re-test after the review date, which the first volume never shows
9, Chapter 28	The inventory entry "Board decisions for the management body" against a plan approved by the audit committee at Nordvik (AIDR-0849, AIDR-0899)
10, Chapter 10	The first runbook drill STOP-HM-ITOPS-2027-Q1-01 took 17 minutes against a 5-minute target; the manifest RBK-HM-0007 (2028) points to STOP-HM-ITOPS without a later drill date
10, Chapter 9	Rings ROL-HM-001 (traffic shares 0.03, 0.08, 0.34, 0.55, sum 1.00) and a Rego widening rule that hard-codes ring names and the working window; the YAML window and the Rego in_window are kept in step by hand
10, Chapter 28	Records AP-HM-OPS-01 to -05 and AP-NR-OPS-01 to -03; AP-NR-OPS-03 gives the failover time as 5 h 20 min, 2 h (in the evidence.test comment of RST-NR-2027-002) and 3 h 40 min (in PRB-NR-0007) without saying which test each refers to
10, Chapter 29	The monthly review of the operations loop has a Steps heading with one numbered step
5, Appendix A	The two EVD-024-01 blocks differ (see Table 25.5)
5, Chapter 22	Register entries THR-NR-02 and THR-HM-03 are flat; THR-HM-09 is wrapped in entry: and omits status; the schema (additionalProperties: false) validates only the flat form

Table 25.9: Faults inside single volumes. Sources: findings of Chapters 3, 7, 8, 9, 12, 14, 16, 18, 22 and 23.

Faults of this book's own inventory

The aggregation also produced corrections to the inventory of this book. They concern the book and not the earlier volumes, and they are recorded because a reader of Appendix A should know of them. An inventory entry "Pact" (Book 1, Chapter 25) is a false positive: the only match for "Pact" in that volume is the Climate Neutral Data Centre Pact. Open Policy Agent appears as seven entries under four spellings, MITRE ATT&CK and ATLAS as seven entries each, the two OWASP Top 10 lists as seven entries each, and SPIFFE four times and the Model Context Protocol six times; the editor should merge them for Appendix A (Chapters 5, 10, 20). The editor should also reconsider the ten Mermaid entries and two MkDocs entries, which describe repository tooling covered by Appendix B, and settle one kind for Team Topologies, which appears four times with two kinds. The first-pass assignment left 58 entries unassigned and put 44 of them in chapters other than where this book treats them (Chapter 3); the Reassign lists in the findings files give the destinations. The use-case descriptor UCD-*, the reconciler sync policy of AI Operations (Appendix A.21), its checklist B.21 and the analysis-template example of its Chapter 9 are not in the inventory and should be added (Chapters 7 and 16).

What to do on Monday

A practitioner who has read the tables does not need to wait for the volumes to be revised. The following seven actions follow from the findings and from the five patterns. The labels are those of the series: observable for what can be seen now, expected for what is likely on a stated horizon, speculation for what is possible and not evidenced (2, Nordqvist, 2026).

1. Search by identifier and read the Origin row. Table 25.2 shows that a prefix does not always identify an artefact. Before copying a template, confirm in the entry (Chapters 4 to 23) which book and chapter defines it. Observable.
2. Take the template from the chapter and the appendix together. Table 25.5 shows that the two sometimes differ in version or fields. If you use a template, record which version you copied, as the entries in this book do. Observable.
3. Choose one default where the series gives two, and record why. Stop time, evidence age, competence-record validity and token lifetime (Table 25.8) have no series default. Treat the choice as a decision record in the organisation's own AIDR-* range, with the number, the owner and the review date. Observable as a practice; the series itself uses it for every comparable choice.
4. Reserve your own identifier ranges before the first record. The only reservation in the series is for AIDR-*. For every other family, adopt a rule of the form prefix, organisation, area, sequence, and keep a list of prefixes in use in the repository. A check that rejects a duplicate prefix with a different kind costs little. Observable as practice.
5. Treat a script shown in a chapter as a design. Table 25.6 shows that many are absent or illustrative. Build or buy the check, test it, and record the date of the test; the Rego in AI Operations Appendix A.14 was not run against an engine, and the volume says so. Observable.
6. Put a date and an independence statement on each claim of coverage. Say what was tested, when, in which environment, with what result, and by whom other than the thing tested (Chapter 14). Name the kind of independence, and use the union of the five and six kinds of the two volumes if the claim matters (Chapter 19). Observable.
7. Keep a local gap list. Where a tool of the series conflicts with another or with your estate, record the conflict beside the tool, with an owner and a review date. This is the same discipline as for a register entry (Chapter 23). Observable as practice.

Three statements about the future follow. They are the author's own projections, labelled as such, and they are the book's conclusions, not findings of the earlier volumes.

• Expected (author's projection, at the next revision of each volume). Most of the items in Tables 25.2 to 25.9 can be resolved by the editors of the earlier volumes without changing any argument, because they are choices of name, number or location. The basis is that each fault in the findings is a local difference of naming or detail, and none was recorded as a disagreement about a conclusion. If the editors act on the gap lists below, a second inventory should find fewer shared prefixes and fewer absent scripts.
• Expected (author's projection). The prefix collisions will recur unless a rule is adopted. The basis is Pattern 2: the one family with a reserved range, AIDR-*, shows no collision, and the families without one show many (Table 25.2). A rule of the form "a new prefix is checked against the list of prefixes in the series before it is used" would be enough.
• Speculation (author's projection). A single machine-readable schema registry for the series, in which every artefact has one kind, one apiVersion domain and one set of required fields, would remove the dialects of Pattern 1. It would also remove the freedom of a volume to shape an artefact to its subject, and there is no evidence in the findings that the dialect differences have caused a failure. The registry is a possibility, not a recommendation.

Gap lists for the editors of the earlier volumes

Each list names the items that the editor of the volume can resolve alone, with the table that holds the detail. The order is the order of the series.

Book 1, Architecture as Code. (1) Make the three ADR directories agree and fix the duplicate ADR-0003 (Tables 25.2, 25.6). (2) Reconcile the docs/adr/ layout shown in Chapter 4 with the repository, and renew the review dates of the three catalogued ADRs (Table 25.6). (3) Remove or provide the scripts and directories shown in Chapters 15A, 20, 21, Appendix A and Appendix 15_CODE_* (Table 25.6). (4) Update the Argo CD, Istio and SLSA examples or mark them as dated (Table 25.7). (5) Add a source for Gremlin, Chaos Mesh, Vault, AWS Secrets Manager and Infracost, which are named without one (Chapters 14, 17 and 20 of this book). (6) Review the change_failure_rate targets and the scorecard bands (Table 25.8).

Book 2, AI Governance. (1) State the range of AIDR-* used and say that the template for the record is not collected (Tables 25.2, 25.4). (2) Add or withdraw the templates listed in Appendix C for the learning path, champions charter and declared intent (Table 25.4). (3) Align the benefits-triage identifiers across Chapters 8, 9 and 17, and the anti-pattern count in Chapter 20 (Table 25.9). (4) Align UC-2026-014 with the volume that cites it (Table 25.9). (5) State the status of the horizon register field horizon: speculative against "speculation" and the definition of "expected" (Table 25.8). (6) Settle the EXC-* uses (Table 25.2).

Book 3, AI Platform and Security. (1) Remove or provide tools/redteam.py, tools/agent_fuzz.py and tools/evidence.py, and state that the model promotion pipeline is a listing (Table 25.6). (2) Give the system card outline and the incident-runbook template named in Appendix B (Table 25.4). (3) Reconcile the two capacity plan schemas and the two routing schemas (Table 25.3). (4) Fix the readiness list and the maintenance-planner manifest (Table 25.9). (5) Make Appendix B point to files, or say that it points to chapters (Table 25.5). (6) Align UC-2026-014 with Book 2 (Table 25.9).

Book 4, AI Red Team. (1) Update Appendix B, which marks as planned eight templates that the chapters already give (Table 25.5). (2) Resolve the two FND-* shapes and the two RTS-* uses (Table 25.2). (3) Define or remove purple-align and give the manifest RoE-NR-2027-003 (Tables 25.4, 25.6). (4) Choose one notation for recovery objectives (Table 25.3). (5) Verify the sources added on 2026-11-02 and state the date and status of IR 8596 (Table 25.7). (6) Name the open-source policy engine behind the Rego in Chapter 16 (Chapter 5).

Book 5, AI Threat. (1) Complete Appendix B, which omits the capability snapshot and eight other templates, and correct the shortcut-rate entry (Table 25.5). (2) Unify the register entries THR-NR-02, THR-HM-03 and THR-HM-09 with the schema, and decide the apiVersion style (Table 25.9). (3) Define or reference the EXIT-* plans (Tables 25.2, 25.4). (4) Reconcile RP-*, EVAL-* and the THR-* briefing identifier with Book 4 and with itself (Table 25.2). (5) Give a template or remove the calibration log and the one-page briefing (Table 25.4). (6) State the definition of "expected" (Table 25.8). (7) Give sources for EPSS, C2PA and the known-exploited catalogues, which have no entry of their own.

Book 6, The Transformed Security Architect. (1) Provide the review checklist, the prompt and skill record, the permission manifest and the exit plan that Appendix B lists, or correct the appendix (Tables 25.4, 25.5). (2) Align REV-HM-0014 and REV-HM-0001 and the excerpts of MND-HM-01 and the containment profile (Tables 25.5, 25.9). (3) Settle EXIT-NR-01, EXC-*, RISK-*, SCE-* and the programme codes HM-SEC-006 and NR-SEC-004 (Table 25.2). (4) Give the evidence manifest as a template, or remove it from Appendix B (Table 25.3). (5) Complete the red-thread review that the inventory notes record as open.

Book 7, AI Boss. (1) Give the seven prose-only items of Appendix B (B.7, B.9, B.12, B.13, B.18, B.19, B.20) or mark them as guidance (Table 25.4). (2) Give listings for the identifiers that appear in the text without one (Table 25.4). (3) Settle the double use of OQM-HM-CLM-01 and DIT-* (Table 25.2). (4) Correct the date of AIDR-0601 and the Nordvik range given in Appendix B (Tables 25.2, 25.9). (5) Remove the "illustrative extension" fields or establish them (Chapter 21).

Book 8, AI Blue. (1) Define EVD-NR-2027-*, MS-1, PRS-* and BTP-HM-2027, or remove the references (Table 25.4). (2) Give text for the pre-production checklist, craft programme and fatigue review (Table 25.4). (3) State the relation between CP-*, the permission manifest and the containment profile, and between DRF-* and DLG-* (Tables 25.2, 25.3). (4) Align DET-HM-0455 dates with Book 9 and the first detection with Book 4 (Tables 25.3, 25.9). (5) State the family relation of AP-* to the earlier volume (Table 25.2). (6) Reconcile the stop and token defaults with the other volumes (Table 25.8).

Book 9, AI Purple. (1) Give the eleven Appendix B items that are described only, or label them as guidance (Table 25.4). (2) Fix DLG-HM-EMU-01 against DLG-HM-LOOP-01 and the two names for Nordvik's loop delegation (Table 25.2). (3) State that validate_artefacts.py is a listing, and which field names it checks (Table 25.6). (4) Settle the three coverage vocabularies and the five kinds of independence (Tables 25.3, 25.8). (5) Merge the duplicate bibliography entries (502/601/701/1101 and 802/1401) recorded in the handover file, then renumber (inventory notes). (6) Document the RoE-NR-2027-001 extension in the template.

Book 10, AI Operations. (1) Settle the family uses CHG-*, CAP-*, RST-*, INC-*, PIR-*, STOP-*/SPT-* and DLG-* (Table 25.2). (2) Add Appendix B entries for A.5, A.7, A.9 to A.11, A.14, A.16 and A.18 to A.22 and unify the correlation-policy name (Tables 25.3, 25.5). (3) Give the templates for GLD-*, FRZ-*, STOP-*, DKD-* and OPS-CF (Table 25.4). (4) Resolve the three failover times in the Nordvik record AP-NR-OPS-03 and the missing later drill (Table 25.9). (5) Run or label the Rego and the SQL, and provide the OpenSLO mapping or withdraw the sentence (Table 25.6). (6) Reconcile "four key metrics" with the five measures of the programme's guide (Table 25.8). (7) Cross-refer the reuse of CHG-HM-5521 and the DLG-* numbering (Table 25.2).

Summary

The conclusions of this book are four.

First, the toolbox shows a series with one design and many dialects. The 1,629 inventory entries share an anatomy (purpose, owner, decision record, links, review date), identifier families that link records into chains, evidence that carries a date, checks made from outside the thing checked, and degrees of delegation that are earned, budgeted and revocable. These five patterns recur from Architecture as Code to AI Operations, and they are what lets a reader move between volumes.

Second, the series provides texts, records and procedures, not software. Of 240 own tools, 227 are publishing scripts and 13 remain; no volume provides an emulation engine or observer software, and the validator of AI Purple is a listing. The checks that the volumes describe are designs for an organisation to build and to test.

Third, the gaps cluster where a pattern has not been made explicit. Thirty-two identifier families appear in more than one volume, and Table 25.2 lists about two dozen cases in which the findings show differently shaped artefacts under a shared prefix. The same artefact appears under several names or shapes (Table 25.3). Appendices name templates that are missing, mark as planned templates that exist, and omit templates that the chapters give (Tables 25.4 and 25.5). Scripts are shown and absent (Table 25.6). Versions, scales and defaults differ without a series default (Tables 25.7 and 25.8), and some faults are internal to one volume (Table 25.9). None of the findings was recorded as a disagreement about a conclusion; they concern the names, numbers, locations and dates around the conclusions. Because the series builds in publication order, only the later of two volumes can reconcile a conflict, and the gap lists give each editor the items that are theirs.

Fourth, the practical consequence is modest and can be acted on at once: read the Origin row, take the template with its version, record a decision where the series gives two defaults, reserve identifier ranges, treat absent scripts as designs, and put a date and an independence statement on every claim. These are the conclusions of this book. The statements about the editors' revisions and about a schema registry are the author's projections, labelled expected and speculation, and are not findings of the earlier volumes.

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. Istio. Virtual Service. (249, Istio (n.d.), n.d.)