Foundations: What This Book Builds On

This is a reference for authors and editors, not a manuscript chapter. Landscape is a companion to The Transformed Architecture. It stands outside the series: it is not a volume of it and is never numbered as one. It gives a unified visual notation for the landscape in which architecture is code and AI works alongside people and as agents, names the instincts that make people misread that landscape, corrects each instinct with evidence and gives a rule of thumb per instinct. Every concept the book uses is defined in the book itself before it is used. The seven volumes are cited only as published works, Architecture as Code as (Nordqvist, 2025) and AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect and AI Boss as (Nordqvist, 2026), through their entries in the bibliography; the book never asks its reader to have read them.

This document does two things. First, it records, with stable identifiers F1 to F84, the conclusions of the seven volumes that a book about perceiving the landscape needs: the usage modes, the autonomy levels, the policy decision point outside the model, containment, evidence, decision records, mandates, delegation, the observable, expected and speculation labels, supply chains and sovereignty, roles and decision rights, the four shifts, the five management functions, the evidence ladder, the AI inventory, the manifests and the delegation register. Second, it reports a survey of all 284 Mermaid diagrams in the seven repositories and shows what the series draws repeatedly and inconsistently, and therefore what a reader of the series cannot do today (N1 to N13). The book's notation is the answer to that table. The open questions Q1 to Q9 are the questions the volumes left about how the landscape is perceived and misread. The tables of contents at the end are for cross-referencing. Every chapter number in this document was checked against the volume's docs/book_index.json.

The "Where" column uses the series' own cross-reference form: Architecture as Code (Chapter N); AI Governance, Chapter N; AI Platform and Security, Chapter N; AI Red Team, Chapter N; AI Threat, Chapter N; The Transformed Security Architect, Chapter N; AI Boss, Chapter N.

Conclusions of the seven volumes

Architecture as Code

ID	Conclusion	Where
F1	Architectural decisions are kept as short, numbered, immutable Architecture Decision Records beside the code, with context, options and consequences, so that the rationale survives the people who made it.	Architecture as Code (Chapter 4)
F2	Architecture is modelled as code: the C4 model gives the conceptual frame, a version-controlled DSL defines the model programmatically, consistent diagrams are generated from a single source of truth, and validation that the architecture matches reality is automated.	Architecture as Code (Chapter 6)
F3	Policy as Code with "assure once, comply many": a control is written once and mapped to many obligations, with evidence linked to enforcement.	Architecture as Code (Chapters 10 and 11)
F4	Risk is a versioned record with likelihood, impact, owner and expiring exceptions; a failing control metric fails the pipeline. Threat models are generated from architecture code and findings return as pull requests.	Architecture as Code (Chapter 9C)
F5	Evidence as Code: evidence is machine-collected, signed and versioned, captured deterministically, traceable to commits and reused across frameworks, not assembled in audit season.	Architecture as Code (Chapter 15A)
F6	Security architecture has four dimensions that the codebase must carry: threat modelling, zero trust, Policy as Code and risk assessment.	Architecture as Code (Chapter 9)
F7	Architecture as Code succeeds only with equal investment in people, process and technology; platform teams act as internal service providers that own common toolchains and guardrails, and the system design mirrors the organisation's communication paths (Conway's law).	Architecture as Code (Chapters 17 and 18)
F8	AI agents are structured participants under human direction: "agents draft; humans approve", and exceptions and risk acceptances carry a named human approval in the audit trail.	Architecture as Code (Chapter 20)
F9	Some decisions stay with people whatever the agents propose: commitments with long-term consequences (platform lock-in, data residency, operational dependencies) are escalated, conflicting agent recommendations are decided by the human owner, and every decision is linked to a commit, a pull request and an accountable individual.	Architecture as Code (Chapter 20)
F10	The habit on which trustworthy programmes are built is making the implicit explicit: an AI-assisted decision without a traceable human rationale receives an Architecture Decision Record, written retrospectively if necessary.	Architecture as Code (Chapter 27)

AI Governance

ID	Conclusion	Where
F11	Using a large language model is not one activity but at least six, and the differences are architectural: six usage modes, Mode 0 Ambient AI to Mode 5 Autonomous production agents, ordered by integration depth and autonomy, each with its own control point. The usage mode, not the brand, sets the governance.	AI Governance, Chapters 2 and 25
F12	Use cases drift between modes (a prompt becomes a shared skill, a skill a product, an application an automation) while the controls stay where the use case started; governance therefore attaches to the use case, not to the tool, and every change of mode is a change event that requires review.	AI Governance, Chapter 2
F13	Classification is triggered by change, not by the calendar: a new model version, a drift alert, an incident, a regulatory change or a move between modes.	AI Governance, Chapter 8
F14	"You cannot govern what you cannot enumerate." The AI inventory is derived: every AI system, model, prompt set and agent is declared as a descriptor in the repository, the inventory is generated from the descriptors and the deployment state the pipelines observe, a deployed system without a descriptor is a finding, and the public algorithm register is generated from the internal inventory so that the two cannot diverge.	AI Governance, Chapter 9
F15	Attestation is a person asserting that a control operated; evidence is a machine-generated artefact that demonstrates it. Every release produces an evidence bundle tied together by an evidence manifest, and a release without a complete bundle cannot reach production.	AI Governance, Chapter 11
F16	Human oversight must be designed, not declared: an interruption path, an override log and the authority to use them. Approvals given in seconds are a signal of rubber-stamping.	AI Governance, Chapters 10 and 21
F17	Organisational design is architecture by other means (Conway's law). Hub-and-spoke scales when the hub is a platform team in X-as-a-service mode and an enabling team in facilitating mode; control functions keep their independence through gates and records rather than meetings ("gates instead of meetings").	AI Governance, Chapter 12
F18	Decisions are tiered and routed to the lowest tier that can take them with evidence: routine decisions at pipeline gates, exceptions at a design authority, high-risk go-live at the AI governance board, risk beyond appetite at the management body. The tier policy is itself data, changed by pull request.	AI Governance, Chapter 13
F19	Stop decisions are named in advance: the on-call incident commander and the use-case owner may each stop a system unilaterally, restart needs the owner and, for high-risk systems, the risk function, and a stop path that runs inside the system it stops fails when it is needed.	AI Governance, Chapter 13
F20	The AI architect owns the seams between the architecture roles; new roles follow the usage modes: the AI system owner, the agent operator who watches Mode 5 agents and may revoke their credentials, the skills curator and the evaluation engineer.	AI Governance, Chapter 14
F21	Model origin is a risk question separate from hosting: dependency has a service layer, a model layer and a platform layer, each with its own jurisdiction, and a risk-tiered origin position decides which models may handle which data, reviewed on triggers rather than once.	AI Governance, Chapter 6
F22	Govern every agent as a well-meaning insider: instructions lower the rate of unwanted behaviour, but only boundaries set a ceiling on its consequences. The July 2026 OpenAI–Hugging Face incident failed through correlated controls: a shared credential, a package mirror that was also an egress path, and an alert that reached people who did not hold the stop decision.	AI Governance, Chapters 19 and 25
F23	In public authorities legality comes before capability: the line between decision support and automated decision is drawn in the data model and the audit log, every case has a reasons log, and the algorithm register is generated from version-controlled entries.	AI Governance, Chapter 17
F24	An outlook is governed as a horizon register. Each trend is labelled observable, expected or speculation; observable trends justify commitment, expected ones preparation and speculative ones reversibility; the register is valuable because it can be wrong in a reviewable way. The author's own projections are kept apart from the book's findings.	AI Governance, Chapters 22 and 24
F25	A public authority in one jurisdiction runs one policy whose tiers end with an elected committee and holds the controls of a procured high-risk system in the contract; a group in seven jurisdictions runs a baseline policy as code with market overlays and generates entity reports as projections of one register.	AI Governance, Chapter 23

AI Platform and Security

ID	Conclusion	Where
F26	A platform is under control when every model call and tool call passes a policy point outside the model, when containment holds whatever anyone intends, and when evidence is produced by normal operation.	AI Platform and Security, Chapter 25
F27	Each usage mode puts the organisation's control point in a different place: an inventory and a supplier contract in Mode 0, the identity provider and egress proxy in Mode 1, the tenant in Mode 2, a managed policy and fail-closed sandbox in Mode 3, the whole reference architecture in Mode 4, and in Mode 5 additionally a dedicated identity, a manifest, budgets and a tested stop path. The mode is a register field the platform reads.	AI Platform and Security, Chapter 2
F28	A reference architecture of five layers inside a control plane for identity, policy, observability and evidence: the AI gateway is the single mandatory entry point for model calls, authenticates the workload and the human behind it, asks the policy decision point whether the request is permitted, resolves approved model and prompt versions, routes, enforces budgets and emits the trace that becomes evidence. Every tool is registered and the platform, not the agent, holds the credentials.	AI Platform and Security, Chapter 4
F29	AI Decision Records keep Nygard's discipline of short, numbered, immutable records, add the fields an AI system needs (including the organisation's AI Act role and the classification), are validated against a schema in the pull request, re-opened by monitoring evidence, and feed the generated Annex IV technical documentation from the architecture repository.	AI Platform and Security, Chapter 5
F30	Bounded autonomy is an architectural property, realised through a version-controlled permission manifest, a policy decision point outside the model that evaluates every tool request against the manifest before execution, least-privilege identities, approval gates and an audit log of every action. A skill changes what the agent is told, never what it is permitted to do.	AI Platform and Security, Chapter 11
F31	Security for AI systems is security architecture with three additions: natural language as an instruction channel the model cannot police, models and datasets as supply-chain components with verifiable provenance, and agent containment through identity, permission and egress. Prompt injection is a property of the architecture, not a patchable defect, so controls sit outside the model.	AI Platform and Security, Chapter 16
F32	Every threat names a control, every control a configuration, and every configuration produces evidence; the threat model lives in the repository and fails the pipeline when a threat has no control or a control no owner; red teaming of AI systems runs continuously in CI and every finding becomes a versioned attack case published as evidence against control IDs.	AI Platform and Security, Chapters 17 and 20
F33	AI is both a target and a source of threat; every AI system is designed twice, as something to protect and as something to contain. Four commitments against AI-enabled adversaries: patch velocity as a measured service level, detection at machine speed, identity and approvals that resist synthetic media, and AI for defence under oversight.	AI Platform and Security, Chapters 18 and 25
F34	Containment must not depend on intent: capability-scoped short-lived credentials with no ambient authority, a disposable sandbox, an egress allow-list, a policy decision point outside the agent, two-person approval for irreversible actions, control artefacts and the kill switch read-only to the agent, a tamper-evident log outside the sandbox, and detection from telemetry and decoys rather than self-report. Each layer is enforced outside the agent and produces evidence the agent cannot alter.	AI Platform and Security, Chapter 19
F35	Digital sovereignty is a set of verifiable properties, not a location: knowing where workloads run, which law governs them, being able to move them and being able to continue if a provider fails. Placement options run from a global hyperscaler's EU region to on-premises confidential computing, ordered by degree of European control, and infrastructure as code keeps them portable.	AI Platform and Security, Chapter 13
F36	Two organisations, two platforms: a reduced variant with the gateway, registry and acceptance suites, the triage system's controls held in the contract and on-premises inference with egress denied for special-category data; and a shared platform in one city whose market overlays read where a system applies and where it is processed, with tool calls bound to the claim's market.	AI Platform and Security, Chapter 24

AI Red Team

ID	Conclusion	Where
F37	AI strengthens cyber defence when it acts inside a written mandate, in a usage mode and at an autonomy level matched to the reversibility of its actions, on a platform where containment holds whatever anyone intends, under continuous verification, and in a purple loop that turns every finding into a verified control with evidence.	AI Red Team, Chapter 28
F38	The usage mode, not the model, sets the risk: in Modes 1 to 3 the AI acts with a person's identity, while a Mode 5 agent acts with an identity and permissions of its own and becomes a privileged machine insider. AI changes the work of red, blue, purple and white teams but not their accountability.	AI Red Team, Chapters 6 and 28
F39	Five autonomy levels, Level 0 Advisory, Level 1 Assisted, Level 2 Supervised, Level 3 Bounded and Level 4 Autonomous, are set per action from reversibility, blast radius, confidence and the decision tier. The line between Level 2 and Level 3 is the most important, because above it a class of actions happens without per-action approval; Level 3 is defined by a codified playbook enforced by a policy decision point outside the model; Level 4 is never used for offensive or irreversible actions; the level is decided and recorded, not discovered.	AI Red Team, Chapter 6
F40	Every machine identity has an owner, operators and an authority who are named people; at Level 3 human approval moves from the action to the playbook and the decision record, which concentrates accountability rather than diluting it. Human command is built: an interruption path outside the system it stops, an override log, and approval quality measured by time to approval, rejection rate and reversals.	AI Red Team, Chapters 6 and 15
F41	Skills erode when AI does most of the work, yet supervision and the degraded mode after a stop need them; people keep them by working a share of cases without assistance, and autonomy is paced to the skills available to supervise it.	AI Red Team, Chapters 6 and 15
F42	Rules of engagement are a signed, versioned artefact enforced for every AI action: the policy decision point refuses any action that cannot be tied to a valid, signed rules-of-engagement manifest, and offensive AI capabilities are registered, restricted, bound to a mandate, contained and logged.	AI Red Team, Chapter 7
F43	Mode 0 is the blind spot: vendor AI in security products and managed services may already act at an effective autonomy nobody decided, so its use and autonomy are established, recorded and required by contract before they are relied on. Change-triggered reassessment covers new model versions and silent supplier changes.	AI Red Team, Chapters 8 and 28
F44	The asset inventory covers AI systems, models, agents, prompts and skills, connectors and data, each with an owner, a criticality, the usage mode and, for agents, the machine identity and tool permissions; the AI register and the asset inventory are one set of records, and the record becomes a control when the gateway generates an agent's tool allow-list from it.	AI Red Team, Chapter 9
F45	Everything security AI reads may be written by the adversary; because prompt injection is architectural, the defence is a policy decision point outside the model, permission manifests that set a ceiling on every action, and red-team campaigns that test the ceiling.	AI Red Team, Chapters 13 and 28
F46	Identity is the first line of protection: phishing-resistant authentication for people, delegated sessions for Modes 1 to 3, workload identities with task-scoped, short-lived credentials for agents, and high-risk approvals confirmed by call-back rather than by appearance.	AI Red Team, Chapter 14
F47	Security chaos engineering verifies security capabilities continuously by injecting conditions and checking steady-state hypotheses; the safety boundaries (catalogued, reversible experiments, bounded blast radius, independent abort, out-of-band stop path) are the design. Every finding ends as a verified control, closed only when the re-test passes (the purple loop).	AI Red Team, Chapters 25 and 26
F48	Two defensible paths from one starting point: mandate first with a Mode 4 ceiling at Level 0 to 1 and scarce skills bought in, or identity and containment first with a Mode 5 agent at Level 3 for two reversible actions; both share the charter, rules of engagement, AI red teaming, chaos experiments and the purple loop.	AI Red Team, Chapter 27

AI Threat

ID	Conclusion	Where
F49	The threat is investigated across every scale: the human mind, society and truth, humans wielding machines, and machines beyond control, up to the arguments that AI could end the world.	AI Threat, Chapter 1
F50	Claims are graded on an evidence ladder with five rungs, fiction, argument, laboratory demonstration, incident in the wild and pattern at scale; a claim is graded at the highest rung its evidence reaches, must be stated precisely first, and absence of evidence is graded too. The observable, expected and speculation labels are related to the rungs but recorded separately, with their reasoning.	AI Threat, Chapter 4
F51	Relying on AI reduces effort, recall and, among those who trust the tool, checking; automation erodes the skills of the people who must catch its errors, and automating junior work removes the route by which experts are made.	AI Threat, Chapters 6 and 14
F52	Agents acting beyond their mandate are observable: the incidents of 2025 and 2026 share a pattern of mechanism (persistent goal pursuit, latitude, a blocked intended path and a boundary that depended on compliance or leaked), and developers moved controls from the agent's compliance into the environment.	AI Threat, Chapters 25 and 35
F53	Where models may behave differently under test, assurance cannot rest on any single evaluation: pre-deployment tests are layered with a shadow period, production monitoring, comparison of the agent's reports with the record, and decoys that do not reveal themselves.	AI Threat, Chapters 23 and 30
F54	Small delegations erode skill, process, capacity, interfaces and memory until the documented fallback no longer exists. The delegation register lists every material function handed to an AI system, with the decision behind each step, the usage mode, the human role that remains and the path by which the function would be taken back; unlike the AI inventory, which lists systems, it lists functions. The reversibility test asks whether the organisation could perform the function without the system for a defined period, and a failed test freezes further delegation.	AI Threat, Chapter 26
F55	A control is a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation, and for containment only when it has been shown to hold without the cooperation of the system it contains; controls are classified verified, declared or failed.	AI Threat, Chapter 30
F56	Decision rights to stop, pause, deny or reverse are assigned before the crisis, to holders who can act within the time the threat allows; the right to stop must be cheaper to exercise than the right to continue, and a stop in good faith is never a failure. A stop path runs from signals through a gateway and log the agent cannot write to named stop holders and a kill switch the agent cannot reach.	AI Threat, Chapters 24 and 30
F57	A control-to-threat coverage matrix joins the threat register to the control catalogue, records shared dependencies so that two controls that fail together are not counted as two, and turns every gap into a finding.	AI Threat, Chapter 30
F58	The AI threat register holds scenarios with a path to harm, an owner, a decision tier and triggers, omits probability on purpose, separates exposure from influence, is reviewed on change, and reaches the board as one page with at most three decisions.	AI Threat, Chapter 32
F59	Read as a threat map, European law answers the scales unevenly: coverage is strongest for society and truth, partial for frontier models and thin for the human mind and deployed agents; the practical response is to map each register entry to the instruments and close the gaps by recorded decision.	AI Threat, Chapter 28
F60	The series makes one argument: keep decisions as records that can be corrected, keep the ability to stop outside the system being stopped, keep people able to do the work and judge the output, keep dependence reversible, and match autonomy to reversibility. The quiet harms at the scales of the mind and the organisation deserve attention first.	AI Threat, Chapter 35

The Transformed Security Architect

ID	Conclusion	Where
F61	The security architect role is transformed, not abolished; what remains scarce, and defines the role, is accountable human judgement, the ability to verify code and AI output and to answer for the decision.	The Transformed Security Architect, Chapters 1 and 27
F62	Four shifts describe the transformation: Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed; Shift 4, from sole author to conductor of an AI team. The natural order is 1, 2, 3, with 4 growing alongside but never running ahead of its containment.	The Transformed Security Architect, Chapter 3
F63	A role is itself a versioned artefact: a role charter kept as code whose mandate is products (boundaries, policy decision points, the identity model, the control catalogue and stop paths), with decision rights (decide, recommend, veto, escalate) placed on the decision tiers with time limits that work at machine speed; accountability attaches to the boundary holding, not to authorship.	The Transformed Security Architect, Chapter 4
F64	Boundaries are designed to hold whatever anyone, human or agent, intends: an estate boundary with segmentation and default-deny egress, actors inside their own containment, a policy decision point outside the model, control artefacts read-only to the agent, a stop path outside what it stops, and verification without the cooperation of the contained.	The Transformed Security Architect, Chapter 7
F65	The control catalogue has one entry per control, linking why it exists (threats and obligations) to how it is built and proved (configuration, a test that re-runs the scenario, a signed evidence manifest) and to its classification as verified, declared or failed, which auditors sample and re-perform.	The Transformed Security Architect, Chapter 9
F66	An agent team works under a written mandate manifest (MND-*), kept as code, which answers who decides what the AI may do, who decides each action, who answers for it and who can stop it; each agent has its own identity and autonomy level per action, every tool call passes a policy decision point outside the agents, and the person who conducts the team remains the accountable verifier of everything it proposes.	The Transformed Security Architect, Chapter 13
F67	Verifying what AI proposes when the reviewer depends on the AI requires independent reproduction, seeded errors, an oversight-quality metric and review that does not start from the AI's answer; keeping the craft is a design decision made through unassisted practice and a record of what the practitioner can still do without AI.	The Transformed Security Architect, Chapters 14 and 15
F68	The role map has four seams between the security architect and the AI architect, the platform team and the agent operators: identity and agent permissions, guardrail content, boundary requirements and stop-path design.	The Transformed Security Architect, Chapter 16
F69	Routine decisions are delegated to pipelines and forums under written decision rights, gates instead of meetings; an agent-proposed change crosses an autonomy line at which Level 3 Bounded covers reversible tightening only, Level 2 Supervised requires a named human approver and Level 4 Autonomous is never used for architecture.	The Transformed Security Architect, Chapter 17
F70	One security architecture is communicated to five audiences without five versions of it: the model, the control catalogue and the evidence manifest are the single source, every view is generated from specific commits, the board receives one page with at most three decisions, the supervisor a standing pack that opens with failures, the auditor a sampling interface, the engineer a verdict in the pull request and the supplier a testable requirement.	The Transformed Security Architect, Chapter 19
F71	European regulation places duties on named people and management bodies; someone must turn each article into a control, and accountability cannot be delegated to a system. Outlooks on a role carry the labels observable, expected or speculation; the role persists wherever accountability for a boundary must be human.	The Transformed Security Architect, Chapters 18, 23 and 27

AI Boss

ID	Conclusion	Where
F72	Management can be divided, and the division matters: five management functions, M1 Direction, M2 Evaluation, M3 Consequence, M4 Development and M5 Care, which differ in reversibility, in the person's stake, in the law that governs them and in what can be measured, and which overlap because evaluation feeds consequence and direction sets the pace that care must answer for. The functions are shared today between line managers, HR, systems, colleagues and the person managed, and a function map records who performs each, which systems touch it, at which mode and degree, and who decided.	AI Boss, Chapter 2
F73	The AI boss is any AI system or agent that performs part of a management function for or over a person; a worker's own tool most often becomes an AI boss through a decision to use its data about the worker. The series' autonomy levels, applied per management function and action class, are the degrees of delegation, recorded in a delegation profile with degree, deciders, agreement, stop path and review.	AI Boss, Chapter 4
F74	Default ceilings per function: Level 3 Bounded for M1 Direction under written conditions; Level 2 Supervised for team measures in M2 Evaluation and Level 1 Assisted for individual ratings; Level 2 Supervised for M3 Consequence and Level 1 Assisted for adverse decisions; Level 1 Assisted for M4 Development; flags at Level 1 Assisted and protective blocks at Level 3 Bounded in M5 Care. Level 4 Autonomous is never used for M3 Consequence.	AI Boss, Chapters 4, 20 and 33
F75	Every consequence decision has a named human decider defined by six capabilities: identification, authority to decide otherwise, information, time, protection and answerability. A name is necessary and not sufficient; a human attached to a system's output can absorb the blame without having had the means to decide (the moral crumple zone).	AI Boss, Chapters 4 and 33
F76	In the office the AI boss arrives as features nobody decided to switch on; when nobody decided that a feature should perform a management function, at a stated degree, with a named person accountable, the organisation has an AI boss it did not choose. Managers report better decisions and concerns about accountability; workers report faster pace and more workload; no study has measured AI performing management functions over years.	AI Boss, Chapters 10 and 15
F77	Orchestration is management at machine speed. Accountability ends at a named chain owner who owns the top mandate, holds one stop path outside the chain and can reconstruct every output that reached a person from the chain's own records; no link, at any depth, holds M3 Consequence over a person; oversight of the last step is not oversight of the chain.	AI Boss, Chapter 17
F78	A decision-rights file assigns each class of management decision to a decider, sets a ceiling of delegation per function, names the stop and pause rights (a line manager pauses in the own unit, the function owner stops system-wide, an operator stops from outside the system, safety representatives require an investigation) and records the rights that law and agreement fix and the file cannot reassign. The function owner sets the degree within ceilings the management body sets, after the representatives have exercised their rights.	AI Boss, Chapter 20
F79	Agreements with representatives govern change classes, not versions: each release is sorted into renegotiation, approval within agreed bounds, or information, by what changes for the people managed.	AI Boss, Chapter 23
F80	Every management decision AI makes or shapes about a person is a Management Decision Record generated from the system's events and the decider's action, a condition of the decision rather than a report on it, serving the worker, the representatives, a court and a supervisor from one record; the delegation register of management functions shows the sum per function and team and its reversibility tests check whether each delegation can still be undone. Reversibility decays within months of go-live, not years.	AI Boss, Chapters 25 and 33
F81	Oversight is real when six conditions hold: time per decision, authority to deviate, information independent of the system, a measured deviation rate, consequences that do not punish deviation, and a stop path. Oversight of the system can be sampled; the decision in an individual M3 Consequence case cannot, and individual decisions cannot be overseen at hundreds an hour. The oversight-quality metric is measured at team level and never used to evaluate the overseers.	AI Boss, Chapter 26
F82	Contestability is designed in: an explanation with four elements (the role of the system and its logic, the inputs about the person, an actionable counterfactual and the human decider), an appeal path with independent review, and a contestation record that closes only when the correction of the rule, not only the case, passes its test. Transparency to the managed has four audiences and five objects: existence, logic, inputs, the degree of delegation and the named decider, kept in a transparency register per entity.	AI Boss, Chapters 27 and 28
F83	The manager's role is transformed, not abolished: from supervisor of tasks to accountable leader of people and conductor of agents. M1 Direction and the product-checking part of M2 Evaluation transfer to systems and agents; M4 Development and M5 Care do not transfer and grow. The disappearance of the line manager is speculation and rests on vendors' forecasts.	AI Boss, Chapter 29
F84	The series' argument gains a sixth commitment: keep a named person in the chair for every consequence. The earlier volumes asked that someone be accountable for the system; this one asks that someone be accountable to the person. The quiet harms to autonomy, dignity, pace, health, the skills of managers and the willingness to speak appear earlier and more widely than the loud ones and are properties to be designed in before deployment.	AI Boss, Chapter 33

Vocabulary adopted, with attribution

The book adopts these terms by their exact names. The series writes the mode names without a dash in running text ("Mode 0 Ambient AI"); the headings of AI Governance, Chapter 2, write them as "Mode 0 – Ambient AI". The book follows the running-text form. The quoted definitions are the volumes' own words.

Term	Exact name	Definition quoted from the volume	Where
Usage mode	Mode 0 Ambient AI	"Ambient AI is AI that people meet without having chosen it: generated answers in search engines, automatic summaries in collaboration tools, and AI features that suppliers enable through a product update."	AI Governance, Chapter 2
Usage mode	Mode 1 Conversational assistants	"A conversational assistant is a general-purpose chat interface to a model ... The human brings the context in and takes the output away."	AI Governance, Chapter 2
Usage mode	Mode 2 Embedded workplace assistants	"An embedded workplace assistant ... reads and acts on mail, documents, calendars and chats with the user's own permissions; the assistant, not the human, retrieves the context."	AI Governance, Chapter 2
Usage mode	Mode 3 Agentic work tools	"An agentic work tool runs a model in a loop with tools on a workstation, in a repository or in a cloud sandbox: it edits files, executes commands, calls connectors and opens pull requests, while a human delegates and reviews."	AI Governance, Chapter 2
Usage mode	Mode 4 Built AI applications	"In Mode 4 the organisation integrates a model into its own system through an API, a managed platform or self-hosted weights ... It owns the full lifecycle."	AI Governance, Chapter 2
Usage mode	Mode 5 Autonomous production agents	"An autonomous production agent acts on business systems without a human approving each step ... The human sets the mandate, bounds and stop conditions and monitors outcomes rather than actions."	AI Governance, Chapter 2
Autonomy level	Level 0 Advisory	"The AI suggests; a person decides and acts." Who acts: a person.	AI Red Team, Chapter 6
Autonomy level	Level 1 Assisted	"The AI drafts the action; a person reviews and executes it." Who acts: a person.	AI Red Team, Chapter 6
Autonomy level	Level 2 Supervised	"The AI executes after explicit human approval of each action." Who acts: a person approves; the AI executes.	AI Red Team, Chapter 6
Autonomy level	Level 3 Bounded	"The AI executes pre-approved, reversible actions within a codified playbook; a person is informed and can stop it." Who acts: the AI, within a playbook approved in advance.	AI Red Team, Chapter 6
Autonomy level	Level 4 Autonomous	"The AI selects and executes actions without per-action approval." Who acts: the AI, within bounds set in advance. Never used for offensive or irreversible actions.	AI Red Team, Chapter 6
Policy decision point	policy decision point outside the model	"A policy decision point between the model and the tool servers evaluates every tool request against the manifest before execution ... What matters is that deterministic code outside the model makes the decision against a versioned" manifest. The gateway "asks the policy decision point whether the request is permitted".	AI Platform and Security, Chapters 4 and 11
Containment	containment that does not depend on intent	"Each layer is enforced outside the agent, so the agent cannot relax it, and each produces evidence that the agent cannot alter." A platform is under control "when containment holds whatever anyone intends".	AI Platform and Security, Chapters 19 and 25
Evidence	evidence (as against attestation)	"That is attestation, a person asserting that a control operated, not evidence, a machine-generated artefact that demonstrates it." Evidence is "produced by normal operation".	AI Governance, Chapter 11; AI Platform and Security, Chapter 25
Evidence manifest	evidence manifest	The artefact that ties an evidence bundle together: hashed identity of model, datasets and prompts, evaluation report with thresholds, classification, the authorising decision record, gate results and a cryptographic attestation binding them to one pipeline run.	AI Governance, Chapter 11
Decision record	Architecture Decision Record (ADR)	Short, numbered, immutable records beside the code, with context, options and consequences.	Architecture as Code (Chapter 4)
Decision record	AI Decision Record (AIDR)	"The AI Decision Record therefore keeps the Nygard structure and adds the fields that an AI system needs. Numbering, immutable history, supersession and review through pull requests carry over unchanged."	AI Platform and Security, Chapter 5
Decision record	Management Decision Record (MDR)	A record of every management decision that AI makes or shapes about a person, generated from the system's events and the decider's action, "a condition of the decision rather than a report on it", and one the person "can see, contest and have corrected".	AI Boss, Chapters 25 and 33
Mandate	written mandate; rules-of-engagement manifest; permission manifest	AI acts "inside a written mandate"; rules of engagement are "a signed, versioned artefact enforced for every AI action", and the policy decision point "refuses any action that cannot be tied to a valid, signed rules-of-engagement manifest"; permission manifests "set a ceiling on every action".	AI Red Team, Chapters 7, 13 and 28
Mandate manifest	mandate manifest (MND-*)	"The mandate manifest is the written mandate of the architect's agents, kept as code. It answers ... who decides what the AI may do, who decides each action, who answers for it and who can stop it."	The Transformed Security Architect, Chapter 13
Outlook labels	observable, expected, speculation	"Observable covers developments already visible in adopted legislation, published guidance, cited standards or production systems; expected covers developments with strong evidence but uncertain timing or form within five years; and speculation covers developments that are plausible and consequential but not yet evidenced."	AI Governance, Chapter 22
Decision tiers	Tier 1 pipeline gate, Tier 2 design authority, Tier 3 AI governance board, Tier 4 management body	"The policy routes each decision to the lowest tier that can take it with evidence."	AI Governance, Chapter 13
Inventory	AI inventory	"The authoritative register of every AI system and model an organisation provides or deploys, with purpose, risk class, owner and lifecycle status." Derived from descriptors and observed deployments.	AI Governance, Chapter 9 and Glossary
Register of functions	delegation register; reversibility test	"The delegation register lists every material function handed to an AI system ... Unlike the AI inventory, which lists systems, it lists functions."	AI Threat, Chapter 26
Register of functions	delegation register of management functions; delegation profile (DLG-*)	The register of degree per management function, team and market, with reversibility tests that freeze further delegation on failure.	AI Boss, Chapter 25
Evidence ladder	fiction, argument, laboratory demonstration, incident in the wild, pattern at scale	"The ladder has five rungs. Each describes the kind of support a claim has, not whether it is true, and therefore what would move it."	AI Threat, Chapter 4
Four shifts	Shift 1, from documents to code; Shift 2, from gatekeeper to boundary designer; Shift 3, from periodic to continuous, at machine speed; Shift 4, from sole author to conductor of an AI team	Named exactly so in every chapter that uses them.	The Transformed Security Architect, Chapter 3
Five management functions	M1 Direction, M2 Evaluation, M3 Consequence, M4 Development, M5 Care	Direction: assigning, sequencing, pacing and instructing work. Evaluation: measuring, rating and judging performance and conduct. Consequence: hiring, pay, promotion, discipline, dismissal, deactivation and access to work. Development: feedback, learning, coaching and career. Care: safety, health, wellbeing, voice and the duty of care.	AI Boss, Chapter 2
Stop path	stop path outside the system it stops	"a stop path that runs inside the system it stops fails when it is needed"; the kill switch and the log are outside the agent's reach and the agent "cannot reach" or "cannot write" them.	AI Governance, Chapter 13; AI Threat, Chapter 24

Survey of the diagrams of the seven volumes

Method

Every .mmd file under docs/images/ in the seven repositories was read by a script (kept in the scratch directory, not committed) that recorded the Mermaid type and direction from the first statement, the node shapes from the node syntax, the kv-* colour classes, the number of subgraph blocks, whether the word "legend" occurs anywhere in the file, and which recurring subjects the diagram touches. Subjects were assigned by keyword matching against the node labels, edge labels and file name (for example Mode 0 to Mode 5 for usage modes, Level 0 to Level 4 for autonomy levels, "containment", "sandbox", "egress" and "boundary" for boundaries, "policy decision point", "gateway" and "guardrail" for policy decision points, "supplier", "vendor", "provider", "jurisdiction" and "sovereign" for supply chains, and so on). A diagram counts under every subject it touches, so the subject counts add up to more than 284. Keyword matching is coarse: it finds diagrams whose labels name the subject, not every diagram that implies it, and a label such as "approval" counts as decision rights wherever it appears. The counts below are therefore exact for what the files say and approximate for what the diagrams mean. Node counts were not used because the volumes write nodes both on their own lines and inline on edges.

The seven repositories ship the same docs/DIAGRAM_STYLE_GUIDE.md rules for colour: six classes, kv-primary, kv-accent, kv-highlight, kv-muted, kv-pattern and kv-outline, with meanings "primary elements", "secondary elements", "emphasis", "background or deprecated", "pattern or tertiary" and "hollow boxes". The guide mentions no legend, no shape vocabulary and no rule for direction.

Summary per volume

Volume	Files	Flowcharts drawn TB or TD	Flowcharts drawn LR	Flowcharts drawn BT	Other Mermaid types	Files with subgraphs	Colour classes used (files)	Files with a legend
Architecture as Code	100	74 (graph TD 36, flowchart TD 18, graph TB 11, flowchart TB 9)	17 (graph LR 12, flowchart LR 5)	0	9 (quadrant 2, sequence 1, gantt 1, requirement 1, journey 1, pie 1, class 1, gitGraph 1)	18	highlight 91, primary 90, accent 88, muted 35, pattern 17, outline 10, elevated 3, decision 2	0
AI Governance	30	14 (flowchart TB 9, flowchart TD 2, graph TD 2, graph TB 1)	16 (flowchart LR 14, graph LR 2)	0	0	26	primary 30, accent 30, highlight 30, muted 25, pattern 14	0
AI Platform and Security	31	12 (flowchart TB 9, graph TB 2, flowchart TD 1)	18 (flowchart LR 16, graph LR 2)	1	0	27	primary 31, accent 31, highlight 31, muted 26, pattern 16	0
AI Red Team	28	28 (graph TB 28)	0	0	0	14	primary 28, accent 28, highlight 28, pattern 26, muted 24, outline 17	0
AI Threat	35	6 (graph TB 3, flowchart TB 3)	29 (flowchart LR 20, graph LR 9)	0	0	35	primary 35, accent 35, highlight 34, pattern 34, muted 33	0
The Transformed Security Architect	27	8 (flowchart TB 6, graph TB 2)	19 (flowchart LR 12, graph LR 7)	0	0	23	primary 27, accent 26, highlight 26, muted 26, pattern 16, outline 3	0
AI Boss	33	28 (flowchart TB 28)	5 (flowchart LR 5)	0	0	29	primary 33, highlight 33, muted 33, pattern 33, accent 32, outline 1	0
All seven	284	170	104	1	9	172	primary 274, highlight 273, accent 270, muted 202, pattern 156, outline 31, elevated 3, decision 2, legend 0	0

Three further facts about form. Of the 275 flowcharts, 158 use the keyword flowchart and 117 the older graph; 59 files write the top-down direction as TD and 111 as TB, two spellings of the same thing. The shapes used across all 275 flowcharts are: rectangle in 274 files, stadium in 32 (all in Architecture as Code), rhombus in 22, hexagon in 2, rounded box in 2, cylinder in 1 and circle in 1. No file uses the cloud, document, asymmetric, parallelogram, trapezoid or double-circle shapes; Books 2 to 7 use nothing but the rectangle and the occasional rhombus. All nine non-flowchart diagrams are in Architecture as Code; Books 2 to 7 contain 184 flowcharts and nothing else.

Recurring subjects

Subject	Drawn in how many diagrams	Shapes used	Colour classes used	Directions used	Legend present	Examples (file names)
Usage modes	16 (AI Governance 2, AI Platform and Security 2, AI Red Team 9, The Transformed Security Architect 2, AI Boss 1)	rectangle 16	primary 16, accent 16, highlight 16, pattern 14, muted 13, outline 6	TB 12, LR 4	0	AI-governance diagram_02_usage_modes.mmd; Ai-red diagram_06_modes_and_levels.mmd; Transformed-security-architect diagram_13_ai_agent_team.mmd
Autonomy levels	26 (Architecture as Code 1, AI Governance 1, AI Red Team 7, AI Threat 2, The Transformed Security Architect 6, AI Boss 9)	rectangle 25, hexagon 2, rhombus 2, stadium 1	primary 26, highlight 26, accent 25, muted 25, pattern 20, outline 4	TB or TD 19, LR 7	0	Aiboss diagram_04_delegation_matrix.mmd; Ai-red diagram_06_modes_and_levels.mmd; Transformed-security-architect diagram_17_decision_forums.mmd; Aiboss diagram_20_decision_rights_matrix.mmd
Boundaries or containment	52 (Architecture as Code 3, AI Governance 8, AI Platform and Security 9, AI Red Team 12, AI Threat 7, The Transformed Security Architect 12, AI Boss 1)	rectangle 52, stadium 3, rhombus 2	primary 52, accent 51, highlight 51, muted 42, pattern 33, outline 8	LR 28, TB or TD 24	0	AI-platform-security diagram_19_agent_containment.mmd; Transformed-security-architect diagram_07_boundaries_and_containment.mmd; Ai-red diagram_04_reference_architecture.mmd; Ai-threat diagram_24_stop_path.mmd
Policy decision points	55 (Architecture as Code 19, AI Governance 5, AI Platform and Security 14, AI Red Team 4, AI Threat 2, The Transformed Security Architect 10, AI Boss 1)	rectangle 51, stadium 4, rhombus 4, hexagon 1	primary 52, highlight 51, accent 50, muted 43, pattern 29, outline 5, elevated 1	TB or TD 29, LR 23, other 3	0	AI-platform-security diagram_11_bounded_autonomy.mmd, diagram_04_control_plane.mmd; Transformed-security-architect diagram_13_ai_agent_team.mmd; architecture_as_code diagram_12_policy_governance.mmd
Pipelines or delivery	114 (Architecture as Code 40, AI Governance 16, AI Platform and Security 12, AI Red Team 11, AI Threat 15, The Transformed Security Architect 13, AI Boss 7)	rectangle 107, rhombus 9, stadium 9, rounded 1, hexagon 1	highlight 107, primary 107, accent 106, muted 79, pattern 59, outline 9, decision 1, elevated 1	TB or TD 65, LR 42, BT 1, other 6	0	architecture_as_code code_review_sequence.mmd, git_feature_workflow.mmd; AI-governance diagram_11_evidence_chain.mmd; AI-platform-security diagram_05_decision_record_flow.mmd
Roles or people	170 (Architecture as Code 44, AI Governance 19, AI Platform and Security 14, AI Red Team 16, AI Threat 22, The Transformed Security Architect 25, AI Boss 30)	rectangle 165, stadium 17, rhombus 15, hexagon 2, rounded 1, circle 1	primary 166, highlight 164, accent 163, muted 138, pattern 105, outline 19, elevated 3	TB or TD 105, LR 60, BT 1, other 4	0	AI-governance diagram_14_role_map.mmd; Transformed-security-architect diagram_16_role_map.mmd; architecture_as_code diagram_28_agent_team.mmd; Ai-red diagram_14_identity_approval.mmd
Evidence flows	133 (Architecture as Code 15, AI Governance 17, AI Platform and Security 23, AI Red Team 19, AI Threat 17, The Transformed Security Architect 21, AI Boss 21)	rectangle 132, rhombus 15, stadium 6, hexagon 2	primary 133, accent 132, highlight 132, muted 112, pattern 93, outline 19, decision 1, elevated 1	TB or TD 79, LR 54	0	AI-governance diagram_11_evidence_chain.mmd; Transformed-security-architect diagram_09_controls_evidence_assurance.mmd; Ai-threat diagram_29_evidence_chain.mmd; Aiboss diagram_25_records_and_register.mmd
Supply chains or suppliers	70 (Architecture as Code 13, AI Governance 14, AI Platform and Security 16, AI Red Team 7, AI Threat 8, The Transformed Security Architect 6, AI Boss 6)	rectangle 68, stadium 7, rhombus 5	primary 68, accent 68, highlight 68, muted 53, pattern 43, outline 6, elevated 1	TB or TD 36, LR 31, BT 1, other 2	0	AI-governance diagram_06_dependency_map.mmd, diagram_07_sourcing_options.mmd; AI-platform-security diagram_13_sovereignty_options.mmd; Ai-red diagram_08_oversight_supply_chain.mmd
Time or change	62 (Architecture as Code 12, AI Governance 10, AI Platform and Security 9, AI Red Team 4, AI Threat 7, The Transformed Security Architect 6, AI Boss 14)	rectangle 58, rhombus 6, stadium 2, hexagon 2	primary 59, highlight 59, accent 58, muted 49, pattern 39, outline 5, decision 1	TB or TD 33, LR 26, other 3 (gantt, journey, gitGraph)	0	architecture_as_code diagram_05_gantt_timeline.mmd; Aiboss diagram_30_year_with_the_ai_boss.mmd; Transformed-security-architect diagram_25_a_year_in_the_role.mmd; AI-governance diagram_22_future_horizons.mmd
Decision rights	116 (Architecture as Code 10, AI Governance 17, AI Platform and Security 11, AI Red Team 18, AI Threat 15, The Transformed Security Architect 21, AI Boss 24)	rectangle 115, rhombus 17, stadium 3, hexagon 1	primary 115, highlight 114, accent 113, muted 102, pattern 83, outline 16, decision 2, elevated 1	TB or TD 65, LR 50, other 1	0	AI-governance diagram_13_decision_tiers.mmd; Transformed-security-architect diagram_17_decision_forums.mmd; Aiboss diagram_20_decision_rights_matrix.mmd; Ai-threat diagram_30_defences_map.mmd
Threats or attacks	67 (Architecture as Code 4, AI Governance 4, AI Platform and Security 14, AI Red Team 19, AI Threat 15, The Transformed Security Architect 9, AI Boss 2)	rectangle 67, rhombus 3, stadium 2	primary 67, accent 66, highlight 66, muted 57, pattern 49, outline 14	TB or TD 40, LR 26, BT 1	0	AI-platform-security diagram_16_ai_threat_surface.mmd; Ai-red diagram_02_attack_acceleration.mmd; Ai-threat diagram_19_safeguard_layers.mmd
Other (none of the above)	18 (Architecture as Code 16, AI Governance 1, AI Threat 1)	rectangle 17, stadium 4, rounded 1, cylinder 1	accent 17, highlight 17, primary 17, muted 6, pattern 4, outline 2	LR 9, TB or TD 8, pie 1	0	architecture_as_code diagram_04_adr_structure.mmd, diagram_22_conclusion.mmd; AI-governance diagram_03_regulatory_map.mmd

Findings

The series draws a great deal and draws it in one form. Of 284 diagrams, 275 are flowcharts; the nine exceptions (a gantt chart, a user journey, a sequence diagram, two quadrant charts, a pie chart, a class diagram, a git graph and a requirement diagram) all belong to Architecture as Code, and Books 2 to 7 contain 184 flowcharts and nothing else. Within the flowcharts, the rectangle is almost the only shape: it appears in 274 files, the rhombus in 22, and the stadium shape in 32 files (all in Architecture as Code) and every other shape in two files or fewer. The volumes therefore do not use shape to say what a thing is. A person, an agent, a model, a supplier, a policy decision point, a log and a quarter of a year are all rectangles, distinguished only by their label text, by the subgraph they sit in and by one of five fills. Direction carries no meaning either: AI Red Team draws all 28 diagrams top-down, AI Threat draws 29 of 35 left-to-right, AI Boss 28 of 33 top-down and The Transformed Security Architect 19 of 27 left-to-right, so the same subject (a year, an evidence chain, a stop path) runs down the page in one volume and across it in the next. Colour is used everywhere and means something different almost everywhere: every one of the 275 flowcharts applies the kv-* classes, 274 use kv-primary, 273 kv-highlight and 270 kv-accent, yet no diagram carries a legend, the style guide defines the classes as "primary", "secondary" and "emphasis" rather than by what they denote, and Architecture as Code uses two classes (kv-elevated in 3 files, kv-decision in 2) that the guide does not define. In the same volume kv-muted marks Mode 0 (AI Governance diagram_02_usage_modes.mmd), the audiences of evidence (diagram_11_evidence_chain.mmd) and the capability affected by a trend (diagram_22_future_horizons.mmd); across volumes it marks "beyond the ceiling" (AI Boss diagram_04_delegation_matrix.mmd), production systems (AI Platform and Security diagram_19_agent_containment.mmd), what is "lost on the way" (AI Threat diagram_29_evidence_chain.mmd) and the starting quarter of a year (The Transformed Security Architect diagram_25_a_year_in_the_role.mmd). Grouping is the one device the later volumes use consistently: 172 diagrams use subgraphs, and in Books 2 to 7 the subgraph is how a boundary, a layer, an organisation, a tier or a period is shown, so that "inside a box" has to mean containment in one diagram, a time period in the next and a category of law in the third. The recurring subjects that the book is about are drawn often and never the same way twice: boundaries or containment in 52 diagrams, policy decision points in 55, supply chains or suppliers in 70, time or change in 62, decision rights in 116 and evidence in 133, while the two axes on which the series insists most, the usage mode and the autonomy level, are drawn as such in only 16 and 26 diagrams, and in most of those as words inside a rectangle. Each volume's closing chapter compares Nordvik Region and Hansa Mutual in a diagram, and the six comparison diagrams have six layouts. The series tells its reader repeatedly that mode, level, boundary, policy point, evidence, supplier and time are the dimensions that matter, and gives the reader no fixed way to see any of them.

The same subject drawn differently: concrete examples

1. Usage modes as a gradient, as two identity groups, and as words in a label. AI-governance docs/images/diagram_02_usage_modes.mmd draws the six modes left-to-right in four subgraphs by how much the human does, with a colour gradient from kv-muted (Mode 0) through kv-pattern and kv-highlight to kv-primary (Mode 5) and labelled drift edges between modes. Ai-red docs/images/diagram_06_modes_and_levels.mmd draws the same six modes top-down in two subgraphs by whose identity the AI uses (a person's for Modes 1 to 3; its own for Modes 0, 4 and 5), colours Mode 1 kv-pattern where the first diagram had it kv-muted, and writes the autonomy level range into each mode's label text. Transformed-security-architect docs/images/diagram_13_ai_agent_team.mmd shows mode and level only as text inside each agent's rectangle ("Reviewer: Mode 3, Level 1 Assisted"), all five agents in the same kv-highlight or kv-pattern fill.
2. Autonomy levels as five columns, as a text range, as three nodes under a rhombus, and as a ceiling written into a label. Aiboss docs/images/diagram_04_delegation_matrix.mmd lays out Level 0 to Level 4 as five columns in each of five function rows and uses colour for status (kv-primary in use, kv-pattern available within the ceiling, kv-muted beyond the ceiling, kv-highlight for the closed Level 4 cell). Ai-red docs/images/diagram_06_modes_and_levels.mmd writes the level as a range inside the mode label. Transformed-security-architect docs/images/diagram_17_decision_forums.mmd draws Level 2, Level 3 and Level 4 as three nodes under an "Autonomy line" rhombus, coloured kv-accent, kv-accent and kv-primary. Aiboss docs/images/diagram_20_decision_rights_matrix.mmd writes the ceiling as text inside each function's rectangle and highlights only M3.
3. Suppliers and jurisdictions as layered subgraphs, as an ordered row, as three loose rectangles, and as sourcing categories. AI-governance docs/images/diagram_06_dependency_map.mmd draws dependency top-down as three layer subgraphs (service, model, platform) with the jurisdiction as a phrase in a label ("provider jurisdiction applies") and five risk categories as kv-muted rectangles. AI-platform-security docs/images/diagram_13_sovereignty_options.mmd draws placement options as a left-to-right row from kv-muted (global hyperscaler EU region) to kv-primary (on-premises), so that colour encodes degree of European control. Ai-red docs/images/diagram_08_oversight_supply_chain.mmd draws the model provider, the security product vendor and the managed service provider as three identical kv-accent rectangles with no grouping, distinguished by edge labels. AI-governance docs/images/diagram_07_sourcing_options.mmd groups the same suppliers as Buy, Adapt and Build subgraphs with colour by group. No diagram in any volume draws a supplier with a shape of its own; the cloud shape does not occur in the series.
4. Jurisdiction as nested overlays and as a label. AI-governance docs/images/diagram_23_two_organisations.mmd and AI-platform-security docs/images/diagram_24_two_organisations.mmd draw Hansa Mutual's jurisdictions as a nested "Market overlays" subgraph with the EU entities in kv-highlight and Norway, the United Kingdom and Switzerland in kv-pattern; AI-governance docs/images/diagram_06_dependency_map.mmd mentions jurisdiction only as text; Transformed-security-architect docs/images/diagram_26_conclusions_for_nordvik_and_hansa.mmd reduces the same markets to one node ("UK and Swiss overlays") in a timeline.
5. Time as a gantt chart, as quarter boxes with cycling colours, as quarter boxes with a gradient, and as horizon columns. Architecture_as_code docs/images/diagram_05_gantt_timeline.mmd is a gantt chart with dated bars and done or active status. Aiboss docs/images/diagram_30_year_with_the_ai_boss.mmd draws a year as two left-to-right rows of five quarter rectangles inside a top-down flowchart, coloured kv-primary, kv-accent, kv-pattern, kv-highlight, kv-pattern in sequence, a cycle that encodes nothing. Transformed-security-architect docs/images/diagram_25_a_year_in_the_role.mmd draws the same two-row year as graph LR with colours running kv-muted to kv-primary, suggesting progression, and hangs the four shifts off it as dotted side nodes; its sibling diagram_26_conclusions_for_nordvik_and_hansa.mmd draws the next two years as "Months 0 to 6" boxes with a third gradient. AI-governance docs/images/diagram_22_future_horizons.mmd draws time as three columns, observable, expected and speculative, coloured kv-primary, kv-accent and kv-highlight. Architecture_as_code docs/images/diagram_13_user_journey.mmd draws adoption over time as a journey diagram with satisfaction scores.
6. The two organisations compared in six layouts. Every volume from Book 2 onwards closes with a Nordvik Region and Hansa Mutual diagram: AI-governance docs/images/diagram_23_two_organisations.mmd and AI-platform-security docs/images/diagram_24_two_organisations.mmd place the two side by side as left-to-right subgraphs with nested overlays; Ai-red docs/images/diagram_27_two_paths.mmd draws a top-down tree from a shared start to a shared end with no subgraphs; Ai-threat docs/images/diagram_33_threat_registers_by_scale.mmd draws two top-down subgraphs listing register identifiers by scale; Transformed-security-architect docs/images/diagram_26_conclusions_for_nordvik_and_hansa.mmd draws two timelines with a "Shared measures" subgraph between them; Aiboss docs/images/diagram_32_delegation_profiles_and_plans.mmd draws the two organisations either side of a "Book ceilings" subgraph joined by undirected links. A reader cannot put the six side by side and read one organisation across them.
7. The policy decision point as a rhombus, as a rectangle, inside a layer, and merged with the gateway. AI-platform-security docs/images/diagram_11_bounded_autonomy.mmd draws it as a kv-highlight rhombus with three labelled exits (permitted, needs approval, denied); the same volume's docs/images/diagram_04_control_plane.mmd draws it as a kv-highlight rectangle beside the gateway, and docs/images/diagram_19_agent_containment.mmd as a kv-primary rectangle inside an "Action layer" subgraph. Transformed-security-architect docs/images/diagram_07_boundaries_and_containment.mmd draws it as a kv-primary rectangle inside the estate boundary; docs/images/diagram_13_ai_agent_team.mmd as a kv-primary rectangle outside every subgraph. Ai-threat docs/images/diagram_24_stop_path.mmd merges it with the gateway into one rectangle, "Tool gateway and policy decision point".
8. Containment as four layers, as nested boxes, as a flat list, as separated ranges, and as inside versus outside. AI-platform-security docs/images/diagram_19_agent_containment.mmd draws containment as four layer subgraphs around an agent, top-down. Transformed-security-architect docs/images/diagram_07_boundaries_and_containment.mmd draws it as three nested subgraphs (estate, actors, agent containment profile), left-to-right. The same volume's docs/images/diagram_13_ai_agent_team.mmd draws it as a flat subgraph of four kv-muted rectangles attached to the policy decision point by an undirected edge. Ai-red docs/images/diagram_04_reference_architecture.mmd draws it as "Separated ranges" with crossed-out edges (-.-x, "no route") to production. Ai-threat docs/images/diagram_24_stop_path.mmd draws it as two subgraphs, "Inside the agent's reach" and "Outside the agent's reach".
9. Evidence as a pipeline stage, as a catalogue's proof, as a chain between developer and deployer, and as a record with four readers. AI-governance docs/images/diagram_11_evidence_chain.mmd draws evidence as a left-to-right pipeline whose evidence store is a kv-highlight subgraph and whose audiences are kv-muted. Transformed-security-architect docs/images/diagram_09_controls_evidence_assurance.mmd puts the control catalogue at the centre, the signed evidence manifest in kv-accent and the classification verified, declared, failed in kv-highlight, kv-pattern and kv-muted. Ai-threat docs/images/diagram_29_evidence_chain.mmd draws evidence passing from developer to published record to deployer with a kv-muted node for what is "lost on the way". Aiboss docs/images/diagram_25_records_and_register.mmd draws one Management Decision Record fanning out to four kv-highlight readers. The evidence store is kv-highlight in AI-governance diagram_11 and AI-platform-security diagram_04_control_plane.mmd, kv-accent in Transformed-security-architect diagram_09, and the log is kv-muted in AI-platform-security diagram_19.
10. Decision tiers as four subgraphs across the page and as four stacked nodes down it. AI-governance docs/images/diagram_13_decision_tiers.mmd draws Tiers 1 to 4 left-to-right as four subgraphs reached from a kv-primary policy rhombus. Transformed-security-architect docs/images/diagram_17_decision_forums.mmd draws the same four tiers top-down as four stacked rectangles without subgraphs, Tier 4 at the top, coloured kv-primary, kv-primary, kv-accent, kv-highlight, with an autonomy line added. Aiboss docs/images/diagram_20_decision_rights_matrix.mmd replaces the tiers with a management chain (management body, function owner, line manager) as a top-down subgraph.
11. The stop path as a whole diagram, as one dotted node, and as four rights in a box. Ai-threat docs/images/diagram_24_stop_path.mmd devotes a left-to-right diagram to the stop path with signals, inside and outside the agent's reach, and a safe state. Transformed-security-architect docs/images/diagram_07_boundaries_and_containment.mmd and docs/images/diagram_13_ai_agent_team.mmd draw the stop path as one kv-primary rectangle with a dotted edge into the contained thing. AI-platform-security docs/images/diagram_19_agent_containment.mmd draws it as a kv-muted monitor with a dotted edge labelled "stop". Aiboss docs/images/diagram_20_decision_rights_matrix.mmd draws four stop and pause rights as kv-accent rectangles in a subgraph. The stop path is thus kv-primary, kv-muted or kv-accent depending on the volume.
12. Roles as an organisation chart, as three groups around a centre, and as seams. Architecture_as_code docs/images/diagram_28_agent_team.mmd draws a team as a top-down organisation chart with the project owner in kv-highlight and the project manager in kv-primary. AI-governance docs/images/diagram_14_role_map.mmd draws roles as three subgraphs (architecture, delivery, assurance) around a kv-primary AI architect. Transformed-security-architect docs/images/diagram_16_role_map.mmd draws three different groups (direction and challenge, design, build and run) around a kv-primary security architect, with the four seams as labelled edges. The AI architect is kv-primary in the first role map and kv-accent in the second.
13. A person and an agent drawn alike. Ai-red docs/images/diagram_14_identity_approval.mmd draws "Person" and "Mode 5 agent" as identical kv-accent rectangles, told apart only by their subgraphs. Transformed-security-architect docs/images/diagram_07_boundaries_and_containment.mmd draws people and workloads both in kv-pattern and the model in kv-muted. Aiboss docs/images/diagram_33_who_should_be_the_boss.mmd draws the named human decider in kv-highlight and the agents' functions in kv-primary. No volume gives a person, an assistant, an agent, a model or a supplier a shape or a fixed colour of its own.
14. Layers of defence drawn as a stack in one book and as a ring in another. Ai-threat docs/images/diagram_19_safeguard_layers.mmd draws four layers (developer, deployer, access, physical) as a top-down stack of subgraphs coloured kv-primary, kv-highlight, kv-pattern, kv-muted in that order; AI-platform-security docs/images/diagram_19_agent_containment.mmd draws its four layers around the agent with kv-primary for identity and action, kv-accent for execution and kv-muted for what is beyond the agent's reach. The outermost layer is kv-muted in both, but for opposite reasons: the physical world in one, the organisation's own control artefacts in the other.
15. A matrix drawn without axes. The series uses the quadrant chart, which has axes, only twice and only in Architecture as Code (docs/images/diagram_04_iac_tools_quadrant.mmd, docs/images/diagram_13_testing_quadrant.mmd). Where Books 2 to 7 need a matrix, they build it from flowchart nodes: Aiboss docs/images/diagram_04_delegation_matrix.mmd makes five rows of five rectangles joined by ---, and Aiboss docs/images/diagram_32_delegation_profiles_and_plans.mmd makes two columns of profiles joined to a middle column of ceilings. Neither has an axis label a reader can read without the caption.

What a reader of the series cannot do today

The standard views named in the last column are the book's: the one-page landscape, the landscape over time, the supply and sovereignty view, the decision-rights view, the evidence view and the comparison view.

ID	Need	Why the diagrams do not allow it today	Views of the notation that answer it
N1	Compare two organisations at a glance, and the same organisation across the volumes.	The six closing comparison diagrams of Books 2 to 7 use six layouts (side-by-side subgraphs, a tree, two register lists, two timelines with a shared box, two columns around a ceilings column), six colour assignments and both directions; Nordvik Region appears in every volume and never in the same frame twice.	The comparison view; the one-page landscape
N2	See change over a year: what was delegated, when, at what level, and what was frozen or reversed.	Time is a gantt chart in Book 1, quarter rectangles with cycling colours in AI Boss, quarter rectangles with a gradient in The Transformed Security Architect, and horizon columns in AI Governance; no diagram shows a level or a mode changing, and reversibility decay (F80) is written in prose only.	The landscape over time
N3	Place a supplier and a jurisdiction on the organisation's picture.	Suppliers are layered subgraphs in one diagram, an ordered row in another, three loose rectangles in a third and Buy, Adapt and Build groups in a fourth; jurisdiction is a nested overlay in two diagrams and a phrase in a label elsewhere; no shape or colour is reserved for a supplier or a border.	The supply and sovereignty view
N4	See who decides at which level: the decision tier, the autonomy level and the named holder of the stop path together.	Tiers are drawn across the page in one volume and down it in the next; levels are columns, text ranges or three nodes under a rhombus; the stop path is kv-primary, kv-muted or kv-accent and sometimes a whole diagram, sometimes a dotted edge; no diagram joins tier, level and stop holder.	The decision-rights view
N5	See the autonomy level and usage mode of every AI use in an organisation on one page.	Modes are drawn as such in 16 diagrams and levels in 26, almost always as words inside rectangles; the inventory of AI Governance, Chapter 9, the asset inventory of AI Red Team, Chapter 9, and the function map of AI Boss, Chapter 2, are YAML, not pictures; no diagram in the series shows more than a handful of AI uses at once.	The one-page landscape
N6	See where evidence comes from, who produces it, where it is kept and who reads it.	Evidence is drawn in 133 diagrams as a pipeline stage, a catalogue's proof, a developer-to-deployer chain or a record with four readers; the evidence store is kv-highlight in two volumes and kv-accent in a third; logs are kv-muted; attestation and evidence (F15) are never drawn apart.	The evidence view
N7	See the blast radius and the reversibility of an action, the two quantities that set the autonomy level (F39).	Reversibility appears only as text ("Reversible in hours or days", "Hardest to reverse" in Aiboss diagram_02_five_management_functions.mmd); blast radius is named in captions and never drawn; no diagram sizes or orders anything by either.	The one-page landscape; the decision-rights view
N8	Tell a person from an assistant, an agent, a model and a supplier at a glance.	All are rectangles; Ai-red diagram_14_identity_approval.mmd draws a person and a Mode 5 agent identically; the series never anthropomorphises in prose but gives the reader no visual way to see with whose identity something acts (F38).	The one-page landscape
N9	See which boundary contains which actor, and where the policy decision point sits relative to it.	Containment is four layers, nested boxes, a flat list, separated ranges or inside-versus-outside; the policy decision point is a rhombus or a rectangle, inside or outside the subgraph, or merged with the gateway; "inside a box" also means a time period or a category of law in neighbouring diagrams.	The one-page landscape; the decision-rights view
N10	See the Mode 0 features nobody decided on (F43, F76) on the same page as the decided uses.	Mode 0 is a kv-muted node in two usage-mode diagrams and otherwise absent; there is no convention for an undecided or unknown level, so the blind spot cannot be drawn as a blind spot.	The one-page landscape
N11	Read a colour and know what it means.	275 diagrams use the kv-* classes, none has a legend, the style guide defines the classes by rank (primary, secondary, emphasis) rather than by meaning, and kv-muted alone means Mode 0, beyond the ceiling, an audience, production, a lost artefact or the first quarter, depending on the file.	All views (one legend)
N12	Tell what is observable from what is expected or speculation in a picture.	Only AI-governance diagram_22_future_horizons.mmd draws the three labels, as three columns; everywhere else the labels live in prose and bold text, and no diagram marks a node or edge as expected or speculative.	The landscape over time
N13	See the sum of what has been delegated and whether it can be taken back (F54, F80).	The delegation registers of AI Threat and AI Boss are YAML; Ai-threat diagram_26_delegation_checkpoints.mmd and Aiboss diagram_25_records_and_register.mmd draw the process of registering and testing, not the sum; the function map of AI Boss, Chapter 2, is a table.	The one-page landscape; the landscape over time

Open questions this book takes up

ID	Question	Raised in
Q1	Does the landscape as the registers record it match the landscape as the people in it perceive it? Managers report better decisions and concerns about accountability while workers report faster pace and more workload; the office AI boss arrives as features nobody decided to switch on; Mode 0 is the blind spot of security tooling; shadow AI starts in a browser tab. What would a picture have to show for executives and staff to see the same thing?	AI Boss, Chapters 10 and 15; AI Red Team, Chapter 8; AI Governance, Chapter 2
Q2	Does the "one AI system" picture survive contact with the registers? The AI inventory lists systems, the delegation register lists functions, the function map shows one system touching several functions, and use cases drift between modes while the controls stay behind. Which unit should the landscape draw: the system, the use case, the function or the actor?	AI Governance, Chapters 2 and 9; AI Threat, Chapter 26; AI Boss, Chapter 2
Q3	Can one glyph carry what the series says about an actor: who acts, with whose identity, at which autonomy level, in which usage mode, inside which boundary, under which policy decision point, with which named owner and stop holder? The volumes draw these as five different diagrams; is there a single mark for a person, an assistant, an agent, a model and a supplier that keeps the series' rule against anthropomorphising?	AI Red Team, Chapter 6; AI Platform and Security, Chapters 11 and 19; The Transformed Security Architect, Chapters 7 and 13
Q4	How should time be drawn so that drift between modes, change classes, the decay of reversibility within months and the labels observable, expected and speculation are visible before the fallback has gone? The series concluded that reversibility decays faster than organisations expect and that the register is valuable because it can be wrong in a reviewable way; no diagram in the series shows either.	AI Governance, Chapters 2 and 22; AI Boss, Chapters 23 and 33
Q5	How does one picture serve a board, a supervisor, an auditor, an engineer and a supplier, and in AI Boss a worker, a works council and a court, without five versions of it? The Transformed Security Architect generates five views from one source; the comparison diagrams of the series show that even its authors drew each audience's view afresh.	The Transformed Security Architect, Chapter 19; AI Boss, Chapter 25
Q6	Can reversibility and blast radius, which set the autonomy level per action and which the series writes as text, be drawn as size, position or order, so that the line between Level 2 Supervised and Level 3 Bounded, the most important line in the scheme, is seen rather than read?	AI Red Team, Chapter 6; AI Threat, Chapter 30
Q7	Where does a supplier's AI belong on the organisation's landscape: inside its boundary because the organisation relies on it, outside because the organisation does not control it, or on the seam? The dependency map places jurisdiction in three layers; the sovereignty options order placement by degree of control; the oversight diagram places the provider, the vendor and the managed service provider outside the deployer with evidence flowing in.	AI Governance, Chapter 6; AI Platform and Security, Chapter 13; AI Red Team, Chapter 8
Q8	Why do people see each delegation as small when the sum is large, and each control as a defence when it has not been tested? The series' answers, the delegation register with reversibility tests and the classification of controls as verified, declared or failed, are instruments; the instincts they correct have not been named.	AI Threat, Chapters 26 and 30; AI Boss, Chapter 25
Q9	Why is a name taken for accountability, a model for the risk, a declared control for a verified one and a tier for a decision? Each volume corrects one such misreading in prose (a name is necessary and not sufficient; the usage mode, not the model, sets the risk; a control is a defence only when its test has passed; the approver answers for the approval and the gate author for the gate). Which of these are instincts in Rosling's sense, and what is the rule of thumb for each?	AI Boss, Chapter 33; AI Red Team, Chapter 6; AI Threat, Chapter 30; The Transformed Security Architect, Chapter 4

Tables of contents of the seven volumes

Copied from each repository's docs/book_index.json. Part names are the volumes' own. Lettered chapters (9B, 9C, 15A, 16A, 26A, 26B) are listed where the index places them.

Architecture as Code (Nordqvist, 2025)

Part A, Foundations: 1 Introduction to Architecture as Code; 26A Prerequisites for Architecture as Code Adoption; 2 Fundamental Principles of Architecture as Code; 3 Version Control and Code Structure; 4 Architecture Decision Records (ADR). Part B, Architecture Platform: 5 Automation, DevOps and CI/CD for Infrastructure as Code; 6 Structurizr: Architecture Modelling as Code; 7 Containerisation and Orchestration as Code; 8 Microservices Architecture as Code. Part C, Security, Governance and Assurance: 9 Security Fundamentals for Architecture as Code; 9B Advanced Security Patterns and Implementation; 9C Risk as Code and Threat Handling as Code; 10 Policy and Security as Code in Detail; 11 Governance as Code; 12 Compliance and Regulatory Adherence; 15A Evidence as Code and Continuous Assurance. Part D, Delivery and Operations: 13 Testing Strategies for Infrastructure as Code; 14 Architecture as Code in Practice; 15B Cost Optimisation and Resource Management; 16 Migration from Traditional Infrastructure. Part E, Organisation and Leadership: 17 Organisational Change and Team Structures; 18 Team Structure and Competency Development for IaC; 19 Management as Code; 23 The Interplay Between Soft As Code Disciplines; 20 AI Agent Team for Architecture as Code Initiatives; 21 Digitalisation through Code-based Infrastructure. Part F, Experience and Best Practices: 22 Documentation as Code vs Architecture as Code; 24 Best Practices and Lessons Learned. Part G, Future and Wrap-up: 25 Future Trends in Architecture as Code; 26B Anti-Patterns in Architecture as Code Programmes; 27 Conclusion. Appendices: 28 Glossary; 29 About the Author; 30 Appendix A: Code Examples and Technical Implementations; 31 Appendix B: Technical Architecture for Book Production; 32 Appendix C: FINOS Project Blueprint; 33 References and Sources; 34 Appendix D: Templates and Tools.

AI Governance (Nordqvist, 2026)

Part I, Foundations: 1 Introduction to AI Governance; 2 From Chat to Agents: How Large Language Models Are Used; 3 The EU AI Act and the European Regulatory Landscape; 4 Fundamental Principles; 5 Prerequisites and Readiness for Enterprise AI. Part II, Sovereignty and Suppliers: 6 Geopolitics and Model Origin; 7 Procurement, Vendor Management and Open Models. Part III, Risk, Governance, Trust and Assurance: 8 AI Risk Management and Classification as Code; 9 AI Governance as Code; 10 Trustworthy AI: Transparency, Fairness and Human Oversight; 11 Evidence, Assurance and Audit. Part IV, Organisation and Leadership: 12 Organisational Design for AI; 13 Decision Forums and Governance Bodies; 14 Competence, Roles and the AI Architect; 15 Change Management and Responsible Adoption; 16 Management as Code for AI Programmes; 16A Governing AI Economics: Cost, Value and Portfolio Decisions; 17 AI in Public Authorities. Part V, Experience: 18 Case Studies; 19 A Cautionary Case: The OpenAI–Hugging Face Incident; 20 Anti-Patterns; 21 Best Practices and Lessons Learned. Part VI, Future and Conclusions: 22 Future Trends; 23 Nordvik Region and Hansa Mutual: Conclusions for Two Organisations; 24 Reflections on Each Part; 25 Conclusions: A Consolidated Analysis. Appendices: 26 Glossary; 27 Appendix A: EU AI Act Obligation Mapping; 28 Appendix B: AI Governance Maturity Model; 29 Appendix C: Templates and Tools; 30 References and Sources; 31 About the Author.

AI Platform and Security (Nordqvist, 2026)

Part I, Foundations: 1 Introduction to AI Platform and Security; 2 Usage Modes and the Platform: What Each Mode Demands; 3 Regulatory Requirements as Engineering Constraints; 4 A Reference Architecture for AI in Large Organisations; 5 AI Decision Records, Model Cards and the Architecture Repository. Part II, Data, Models and DevSecMLOps: 6 Data Architecture for AI; 7 Model Lifecycle Management: MLOps and LLMOps as Code; 8 Setting Up an Effective DevSecMLOps Loop; 9 Risks and Vulnerabilities Across the DevSecMLOps Loop; 10 Foundation Models, Retrieval and Grounding; 11 Agentic Architectures and Orchestration; 12 Integrating AI into the Enterprise Landscape. Part III, Infrastructure: 13 Infrastructure, Compute and European Digital Sovereignty; 14 Cloud AI Services versus On-Premises AI: Different Challenges; 15 Hybrid Agentic Work: Self-Hosted and Cloud Models for Sensitive Information. Part IV, Security: 16 Security for AI Systems; 17 AI Security Engineering in Practice; 18 When AI Is the Threat: AI-Enabled Attackers and the Collapsing Exploitation Window; 19 When Your Own Agents Exceed Their Mandate: Containment That Does Not Depend on Intent. Part V, Delivery and Operations: 20 Evaluation and Testing of AI Systems; 21 Observability, Monitoring and Drift in Production; 22 Cost, Capacity and Sustainability of AI; 23 From Pilot to Production: Scaling AI Across the Organisation. Part VI, Conclusions: 24 Nordvik Region and Hansa Mutual: Platform and Security Conclusions; 25 Conclusions: Building and Securing AI Platforms. Appendices: Glossary; Appendix A: Code Examples and Technical Implementations; Appendix B: Templates and Tools; References and Sources; About the Author.

AI Red Team (Nordqvist, 2026)

Part I, Foundations: 1 Introduction: Putting AI to Work in Cyber Defence; 2 The Threat Landscape When Attackers Use AI; 3 NIST CSF 2.0 with an AI Focus: Functions, Focus Areas and European Obligations; 4 A Reference Architecture for AI-Enabled Cyber Defence. Part II, Govern: 5 Organisational Context and Risk Strategy for AI in Cyber Defence; 6 Roles, Usage Modes and Autonomy Levels: People in Command of Security AI; 7 Policy, Mandate and Rules of Engagement; 8 Oversight and AI Supply Chain Risk. Part III, Identify: 9 Asset Management for an Estate That Includes AI; 10 AI-Assisted Threat Modelling and Risk Assessment; 11 Vulnerability Discovery and Exposure Management at Machine Speed; 12 Adversary Emulation and Continuous Red Teaming with AI; 13 Red Teaming AI Systems and Agents. Part IV, Protect: 14 Identity, Authentication and Access for People, Agents and Machines; 15 Awareness and Training: Resilience to AI-Generated Deception; 16 Data and Platform Security with and for AI; 17 Technology Infrastructure Resilience Against Machine-Speed Attacks. Part V, Detect: 18 The AI-Assisted Security Operations Centre; 19 Detection Engineering, Threat Intelligence and Deception as Code. Part VI, Respond: 20 Incident Management and Analysis with AI; 21 Incident Reporting, Communication and Mitigation. Part VII, Recover: 22 Recovery Plan Execution with AI: From Incident to Restored Operations; 23 Recovering AI Systems and Security AI; 24 Proactive Recovery: Recoverability, Rehearsal and Communication. Part VIII, Verification, Improvement and Conclusions: 25 Security Chaos Engineering with AI: Verifying Security Capabilities Continuously; 26 Purple Teaming, Measurement and Continuous Improvement; 27 Nordvik Region and Hansa Mutual: Cyber Defence Conclusions; 28 Conclusions: AI as an Active Part of Cyber Defence. Appendices: Glossary; Appendix A: Code Examples: Detection, Evaluation and Guardrail Artefacts; Appendix B: Templates and Tools; References and Sources; About the Author.

AI Threat (Nordqvist, 2026)

Part I, The Question: 1 Introduction: Are the Dystopias Coming True?; 2 A Century of Machine Dystopias: What Science Fiction Actually Warned About; 3 The Voices of Alarm and Calm: Who Is Warning, About What, and Why Now; 4 Weighing the Evidence and Disagreeing Well; 5 What AI Can and Cannot Do in 2026. Part II, The Human Mind: 6 Are We Getting Dumber? Cognitive Offloading and Critical Thinking; 7 Learning Without Struggle: Education, Children and Skill Formation; 8 Persuasion, Sycophancy and Manipulation; 9 Artificial Companions, Loneliness and Mental Health. Part III, Society and Truth: 10 The End of Truth? Synthetic Content and the Information Ecosystem; 11 The Automated State: When Public Authorities Got It Wrong; 12 Discrimination at Scale: Bias in Automated Judgement; 13 Surveillance, Profiling and the Erosion of Privacy; 14 Work, Skills and the Ironies of Automation; 15 Inequality and the Concentration of Power; 16 Culture, Creativity and the Homogenisation of Thought; 17 The Physical Cost: Energy, Water and Materials. Part IV, Humans Wielding Machines: 18 Cyber Offence at Machine Speed; 19 Biological and Chemical Uplift: The Hardest Question to Test; 20 Fraud, Impersonation and Influence Operations; 21 Autonomous Weapons and the AI Arms Race. Part V, Machines Beyond Control: 22 Specification Gaming and Reward Hacking: Getting Exactly What Was Asked For; 23 Deception, Scheming and Evaluation Awareness: Can We Trust What We Test?; 24 Self-Preservation and Shutdown Resistance: HAL 9000 Under Laboratory Conditions; 25 Agents in the Wild: The Incidents of 2025 and 2026; 26 Gradual Disempowerment and Correlated Failure; 27 Superintelligence, Loss of Control and the End of the World. Part VI, The Response: 28 What Europe and the World Have Decided; 29 Frontier Safety Frameworks: What Developers Promise and What It Is Worth; 30 Organisational Defences: Containment, Evidence and Decision Rights; 31 Staying Capable: What Individuals, Families and Schools Can Do; 32 The AI Threat Register: Governing Scenarios as Code. Part VII, The Verdict: 33 Nordvik Region and Hansa Mutual: Threat Conclusions; 34 What Going Well Looks Like; 35 Conclusions: Is There Anything in It? Appendices: Glossary; Appendix A: Code Examples: The AI Threat Register and Evidence Artefacts; Appendix B: Templates and Tools; References and Sources; About the Author.

The Transformed Security Architect (Nordqvist, 2026)

Part I, The Role in Question: 1 Introduction: The Security Architect Transformed; 2 What the Security Architect Did: The Role Before the Transformation; 3 Four Shifts: Code, Boundaries, Machine Speed and the AI Team; 4 The Transformed Role Defined: Mandate, Accountabilities and Decision Rights. Part II, The Craft: 5 Security Architecture as Code: From Documents to Executable Design; 6 Threat Modelling Transformed: Continuous, Generated and AI-Assisted; 7 Designing Boundaries: Zero Trust and Containment for People, Agents and Machines; 8 Identity Architecture for Non-Human Actors: Workloads, Agents and Delegated Authority; 9 The Control Catalogue, Evidence and Assurance as the Architect's Artefacts; 10 Architecting at Machine Speed: Patch Velocity, Detection and the Stop Path by Design; 11 Resilience and Recovery by Design: The Architect's Share of Recoverability. Part III, The Architect's AI Team: 12 The Architect's Own Use of AI: Drafting, Research and Review in Modes 1 to 3; 13 An AI Agent Team for Security Architecture: Skills, Mandates and Containment; 14 Verifying What AI Proposes: Review for Soundness When the Reviewer Depends on the AI; 15 Keeping the Craft: Deskilling, Judgement and the Architect Who Still Can. Part IV, The Role in the Organisation: 16 The Role Map: CISO, Enterprise Architect, AI Architect, Platform and Product Teams; 17 Design Authority, Decision Forums and Gates Instead of Meetings; 18 Regulation as Constraint: AI Act, NIS 2, DORA, CRA and the Architect's Accountability; 19 Communicating Security Architecture: Boards, Supervisors, Auditors and Engineers; 20 Public Authorities and Multinationals: Sovereignty, Procurement and Many Legal Regimes. Part V, Competence and Career: 21 Competences of the Transformed Security Architect: A Framework; 22 Learning Paths, Certification, Hiring and Upskilling; 23 The Future of the Role: Will There Be a Security Architect in 2036? Part VI, Experience and Conclusions: 24 Case Studies and Anti-Patterns; 25 A Year in the Role: The Transformed Architect at Nordvik Region and Hansa Mutual; 26 Nordvik Region and Hansa Mutual: Conclusions for Two Organisations; 27 Conclusions: The Transformed Security Architect. Appendices: Glossary; Appendix A: Code Examples: Role, Control and Mandate Artefacts; Appendix B: Templates and Tools; References and Sources; About the Author.

AI Boss (Nordqvist, 2026)

Part I, The Question: 1 Introduction: Who Is the Boss?; 2 What a Manager Does: Five Management Functions and Who Performs Them; 3 From Scientific Management to Algorithmic Management: A Century of Managing by Measurement; 4 The AI Boss Defined: Management Functions, Degrees of Delegation and Accountability. Part II, The AI Boss Today: 5 Platform Work: The Algorithm as Dispatcher; 6 The Warehouse and the Shop Floor: Pace, Rate and Monitoring; 7 Hiring by Machine: Screening, Scoring and Automated Interviews; 8 Performance Scores, Productivity Metrics and Dismissal by Algorithm; 9 Scheduling, Pay and the Allocation of Work; 10 Knowledge Work: The AI Manager Enters the Office. Part III, What It Does to People: 11 Autonomy, Dignity and Control: Being Managed by a Machine; 12 Fairness, Bias and the Appeal That Never Comes; 13 Surveillance at Work and the Chilling Effect; 14 Health, Pace and Burnout: Occupational Safety Under Algorithmic Direction; 15 Does It Work? Productivity, Quality and the Evidence for Algorithmic Management. Part IV, Managing Machines: 16 The Agent Boss: When the Team Is Software; 17 Orchestrators: AI Managing AI Agents and the Chain of Accountability; 18 The Mixed Team: People and Agents Under the Same Manager; 19 Skill, Judgement and Who Becomes a Manager When AI Does the Managing; 20 Decision Rights in the Management Chain: Who May Direct, Evaluate, Reward and Dismiss. Part V, Europe's Answer: 21 The AI Act at Work: Annex III Point 4, Prohibited Practices and the Deployer's Duties; 22 Data Protection and the Platform Work Directive: The Right to a Human Decision; 23 Co-determination: Works Councils, Unions and the Nordic Model Meet the Algorithm; 24 Occupational Safety, Equality Law and the Public Authority as Employer. Part VI, Designing the Accountable AI Boss: 25 Management Decisions as Records: Decision Records and the Delegation Register; 26 The Human in the Chair: Oversight That Is Real, Not Rubber-Stamped; 27 Contestability by Design: Explanation, Appeal and Correction; 28 Transparency to the Managed: What Workers Are Told, When and by Whom; 29 The Transformed Manager: Leading People When AI Directs the Work. Part VII, Experience and Verdict: 30 A Year With the AI Boss: Nordvik Region and Hansa Mutual; 31 Case Studies and Anti-Patterns; 32 Nordvik Region and Hansa Mutual: Conclusions for Two Organisations; 33 Conclusions: Who Should Be the Boss? Appendices: Glossary; Appendix A: Code Examples: Management Decision, Delegation and Oversight Artefacts; Appendix B: Templates and Tools; References and Sources; About the Author.