Choosing, Adopting and Retiring Tools

A tool enters an organisation by a decision, works there by being used, and leaves, if it is managed well, by another decision. The ten earlier volumes describe many tools for the first two decisions and fewer for the third, and none of them gives one procedure that runs from the first to the last. This chapter assembles the pieces in the order in which a practitioner meets them: selecting, adopting, keeping a tool under review and retiring it, with the anti-patterns that mark each stage as a failure. The order is this book's. The tools in it are the series'.

The chapter treats all four kinds of tool that Chapter 1 defines. The artefacts include the readiness scorecard of Architecture as Code (Chapter 26A), the adoption dashboard definition and the anti-pattern fitness functions of AI Governance, the production readiness checklist of AI Platform and Security, and the anti-pattern records that four of the later volumes keep in a common shape. The methods include the diffusion of innovation, Kotter's eight steps applied to AI, the production readiness review and the review procedures of The Transformed Security Architect, AI Boss, AI Blue, AI Purple and AI Operations. The third-party entries are the frameworks, protocols, voluntary codes and products that the volumes name as things an organisation may choose to follow (1, Nordqvist, 2025) (2, Nordqvist, 2026).

Two questions run through the chapter. The first is how an organisation chooses between a template, a product and a method. The second is what proves that a tool is adopted and still works. The answer to the second question is the thread of the whole chapter and follows a rule that AI Operations states for claims about resilience: a claim about a tool needs a statement of what was tested, when and with what result, and it expires (10, Nordqvist, 2026). A tool is adopted when the records show that people use it, and it still works when a test with a date says so. Both statements go stale, and the records in this chapter are built so that staleness is visible.

Tool lifecycle: select, check readiness, pilot, adopt, review and retire

Figure 3.1: The lifecycle of a tool in this chapter, in six steps; the four decisions at which a tool can stop (which option, ready, gate passed, still needed) are described in the sections below. A choice that ends with a non-AI option or with doing nothing is still recorded, with a review date.

The chapter's slice of the inventory holds 55 entries. A further 14 of the 58 entries that the first-pass assignment left unplaced fit adoption, review and planning, and are treated here. The closing paragraph of the chapter accounts for all of them.

Selecting

What the volumes give for a choice

The series never treats selection as a matter of taste. AI Governance (Chapter 16A) frames it as a comparison of options against one unit of value, and the rest of the volumes add the checks that belong to each kind of option. The comparison has five options: build on a controlled platform, buy a vendor system or hosted model service, use AI features already present in licensed software, solve the problem without AI, and do nothing. Each is compared on the same unit of value, period and quality constraint, and each carries the costs that AI options tend to hide: lock-in and exit, supplier terms for price changes and model retirement, sovereignty and capability already paid for, and public procurement rules (2, Nordqvist, 2026). The volume anchors the method in public appraisal guidance, the Green Book and the Economic Appraisal Vademecum (123, HM Treasury, 2026) (124, European Commission, 2021).

The five options are not the four kinds of tool, but they map onto them, and the mapping answers the first of the two questions. The table is this book's reading of the volumes.

Option in AI Governance, Chapter 16A Kind of tool in this book What to ask before choosing Where the series says more
Build on a controlled platform Artefact or own tool Who owns it, tests it and reviews it in two years? Chapter 2; AI Platform and Security, Chapter 23
Buy a vendor system or hosted service Third-party tool What is the tested exit, and who holds the evidence of how it behaves? Chapter 9
Use AI features already licensed Third-party tool, adopted without being chosen Does the organisation know the feature is live and has it decided to permit it? AI Governance, Chapter 15
Solve the problem without AI Method, or an artefact that records a rule Does a procedure or a rule meet the same quality constraint at lower cost? This chapter, anti-patterns
Do nothing None; the baseline What is the measured cost of the present state? AI Governance, Chapter 16A

In this book's reading, a template is the right choice where the organisation must own, version and review the thing itself, as with a decision record or a mandate manifest. A product is the right choice where the capability is not the organisation's to build, and then the selection is a supplier decision whose conditions Chapter 9 treats. A method is the right choice where the need is a repeatable human procedure, such as a review or a drill, and no software would change the outcome. Where the series offers more than one of these for the same need, it usually says that they combine: the method is applied through an artefact, and a product is governed by a record.

Option comparison
Kind Artefact
Origin AI Governance, Chapter 16A
Purpose A fair comparison of build, buy, reuse, non-AI and do-nothing options before a renewal or an investment
Use when Before the renewal of a contract, when a governance forum asks which option is the best use of the money
Inputs One unit of value, one quality constraint, a measured baseline, three-year cost ranges, exit and sovereignty terms
Outputs A table with one row per option and a reading by the governance forum
Full template None; the worked example is a table, not a code block

The worked example of the volume is a table of four options for a document-extraction service that lacked a tested exit plan: renew the hosted service, run an open-weight model on the group platform, use rules for structured forms with a hosted model for the rest, and do nothing (manual extraction). Its columns are the option, the three-year cost, the unit cost, exit and sovereignty, and the forum's reading. The volume's own point about the example is that its shape matters more than its figures: one unit of value, one quality constraint, a measured baseline, and exit cost and sovereignty on the same page as price (2, Nordqvist, 2026). The forum that reads the table has five outcomes available: approve, approve with conditions, pause, scale, and retire or redesign. The last is where the lifecycle in Figure 3.1 reaches its end, and the volume requires that every decision names its next review date, so that "approve" never means "approve indefinitely".

Consumption forecast
Kind Artefact
Origin AI Governance, Chapter 16A
Purpose A forecast of the consumption of an AI service with stated assumptions
Inputs Volume, actions per unit of work, token or unit use at stated percentiles, retry rate, model mix, price basis
Outputs Low, expected and high cases, a consumption envelope and a unit-cost ceiling
Identifier family portfolio/forecasts/*.yaml
Full template AI Governance, Chapter 16A (worked example for an autonomous agent)

The forecast belongs in selection because the price of a tool is a forecast and not a quotation. The worked example makes the assumptions explicit, records the error of the previous forecast and sets an envelope with a hard cap and a fallback, so that a later review can say whether the assumptions held (2, Nordqvist, 2026). Chapter 17 treats capacity, cost and energy tools in full.

Frameworks, protocols, codes and products as choices

Some of the third-party entries in this chapter's slice are not software at all. They are frameworks, protocols and voluntary codes that an organisation may adopt, and a few are commercial products. Rule 7 of the authoring guide of this book applies: each is described only from its own documentation, and the series is cited only for what it does with the tool. The table says what kind of thing each is, what the series uses it for, and the limit of what is claimed here.

Tool Kind Origin What the series uses it for Limit of the claim here
SABSA and TOGAF Framework and standard for enterprise and security architecture (28, Sherwood et al., 2005) (27, The Open Group, 2022) The Transformed Security Architect, Chapters 2, 16 and 22 Inherited architecture methods against which the transformed role is placed Their content is not summarised
ITIL 4 Service management practice framework (25, PeopleCert, n.d.) AI Operations, Chapters 1, 2, 4 and 32 The source of the change classes and practices that the volume adapts Only the use the volume makes of it
Site Reliability Engineering practice Practice described in the Google SRE books (14, Beyer et al., 2016) AI Operations, throughout The source of the practices of service level objectives, error budgets, toil, postmortems and incident command Only the practices the volume names
Knowledge-Centered Service (KCS) Practice for keeping knowledge current, the Evolve Loop (26, Consortium for Service Innovation, n.d.) AI Operations, Chapter 12 Review and improvement of the content of a knowledge base Drawn mainly from service desk experience and not from runbooks, as the volume notes
Traffic Light Protocol (TLP 2.0) Protocol of FIRST for marking sharing restrictions (29, FIRST, n.d.) AI Purple, Chapter 22 Marking of information shared across a sector Only the marking use
General-Purpose AI Code of Practice Voluntary code published by the European AI Office (30, European Commission, 2025) AI Threat, Chapters 10, 19 and 28 Systemic-risk assessment by providers of general-purpose AI models The code's text is not summarised; the AI Act's own obligations are treated in Chapter 8
Code of Practice on marking and labelling AI-generated content Voluntary code published by the Commission (31, European Commission, 2026) AI Threat, Chapter 10 Machine-readable marking techniques such as metadata, watermarks and detection Only the use the volume makes of it; Chapter 23 treats tools for weighing evidence
Claude Code, GitHub Copilot, Cursor Commercial agentic coding tools AI Platform and Security, Chapters 2 and 9 Named as examples of agentic work tools in Mode 3 No claim about the products is made beyond the example
GitHub Copilot Commercial coding assistant The Transformed Security Architect, Chapters 3 and 12 Named as an assistant that has been studied in productivity and security research No claim about the product; Chapter 21 treats role and competence

What these rows have in common is that the decision to follow them is not forced by the tool. An organisation can use ITIL 4 for its change classes without adopting the rest of the framework, and it can decline a voluntary code and say why. A choice of this kind is recorded as any other decision is, in an AI Decision Record or an Architecture Decision Record, with the review date that makes it temporary (2, Nordqvist, 2026). The commercial tools in the last two rows are the case in which the selection is hardest to see, because a coding assistant in Mode 3 reaches an organisation through a developer's workstation before it reaches the portfolio register. AI Governance (Chapter 15) describes that as adoption nobody chose and answers with a standing process: a supplier's announcement of a new feature opens a review with an owner and a deadline, features enabled by default are switched off at tenant level where the product allows it, and the useful measure is the share of live AI features that have passed review (2, Nordqvist, 2026).

Adoption and the diffusion of tools

A tool that has been chosen is not yet adopted. The series treats adoption as a set of decisions about readiness, about how a tool spreads, about the people it affects and about the evidence that it is in use, in that order.

Readiness

Architecture as Code (Chapter 26A) states why readiness comes first. It lists five readiness anti-patterns: tool-first enthusiasm, in which a platform is bought before the cultural foundations exist and becomes shelfware; heroic ownership, in which a few experts hold the responsibility; budget whiplash; governance bypass; and metrics myopia (1, Nordqvist, 2025). The readiness scorecard is its instrument against them.

Readiness scorecard
Kind Artefact
Origin Architecture as Code (Chapter 26A)
Purpose A 15-criterion scorecard, scored 1 to 5, with interpretation bands
Use when Before a focused pilot, before expanding to new domains, and in quarterly reviews of ongoing readiness
Inputs Evidence for each criterion, noted beside the score
Outputs A total from 15 to 75 and a band: 60 to 75 ready to proceed, 40 to 59 partial readiness, below 40 foundation work needed
Full template Architecture as Code (Chapter 26A), quoted below

The five dimensions are contextual discovery, capability baseline, cultural readiness, economic viability and the remediation roadmap, with three criteria each. The scorecard is written for Architecture as Code adoption, and its criteria name infrastructure code and pipelines. In this book's reading the structure transfers to other tools, because each dimension asks a question that any tool raises (who needs it, what exists to build on, will people use it, who pays, what comes first); the criteria must be rewritten for the tool at hand. The template, as Architecture as Code gives it:

| Dimension | Assessment Criteria | Score (1–5) | Notes / Evidence |
|-----------|---------------------|-------------|-----------------|
| **Contextual Discovery** | | | |
| Stakeholder alignment | Key stakeholders identified and engaged | | |
| Current-state documentation | Existing architecture documented to C4 Level 2 | | |
| Tool inventory | Current toolchain catalogued (IaC, CI/CD, monitoring) | | |
| **Capability Baseline** | | | |
| Version control maturity | Infrastructure code in version control with branching strategy | | |
| Automation coverage | ≥50% of infrastructure provisioned via code | | |
| Skills availability | Team members trained in at least one IaC tool | | |
| **Cultural Readiness** | | | |
| Change appetite | Leadership support for code-first approach confirmed | | |
| Collaboration practices | Team uses pull-request-based review workflows | | |
| Learning culture | Team participates in internal knowledge-sharing sessions | | |
| **Economic Viability** | | | |
| Budget allocated | Budget confirmed for tooling, training, and migration effort | | |
| ROI baseline | Current cost-of-manual-change quantified for comparison | | |
| Risk tolerance | Acceptable risk threshold defined for incremental rollout | | |
| **Remediation Roadmap** | | | |
| Gap prioritisation | Top three capability gaps identified and ranked | | |
| Quick wins defined | At least one low-effort, high-visibility pilot scoped | | |
| Milestones agreed | 90-day and 12-month milestones documented | | |

(Quoted from the repository checkout of Architecture as Code used for this book, rows unchanged. The volume's scoring guidance follows the table: 60 to 75 points means begin with a focused pilot; 40 to 59 means address the critical gaps before scaling; below 40 means follow the remediation roadmap first.) Two points need care. A total between 15 and 39 and a total between 40 and 59 are different conditions, and the band "below 40" covers a wide range. And the scorecard measures readiness at one date; the volume asks for it to be repeated, with the delivery metrics, cultural metrics and cost signals of its other chapters, so that readiness is a series of dated readings and not a certificate (1, Nordqvist, 2025).

Staged adoption and its roadmaps

Three tools in the slice describe the order in which a tool is introduced. They agree on the principle that a contained, low-risk service goes first.

Tool Kind Origin Steps Purpose
Step-by-step adoption strategy Method Architecture as Code (Chapter 27) Six: foundational education, pilot projects, security integration, scaling and automation, readiness and risk management, future readiness A staged adoption from education to future readiness; before expanding to new domains, readiness is validated with the scorecard
Four-phase blueprint roadmap Method Architecture as Code (Appendix C, the FINOS blueprint) Four: pilot and prove, expand and federate, govern and optimise, sustain and innovate The adoption roadmap of the FINOS Software Project Blueprint (125, FINOS, n.d.)
Legacy resource import script (migration/import-legacy-resources.sh) Artefact (Bash script) Architecture as Code (Chapter 16) A reviewed change set followed by drift detection Brings existing resources under a code definition, so that the template is proven to describe reality before any further update touches them

The import script deserves a note because it is the answer to a question that adoption plans often skip: what happens to what already exists. The volume's rule is that the import is itself a reviewed change set, and that drift detection follows, so that adoption of the new tool does not begin with an untested assumption about the old estate (1, Nordqvist, 2025). The script is quoted in the volume's Chapter 16 and is not reproduced here.

How a tool spreads

AI Governance (Chapter 15) applies four models from the research literature to the adoption of AI, and each is a method in this book's sense.

Diffusion of innovation. Rogers described adopter segments, from innovators to laggards, and five attributes that govern the rate of adoption (11, Rogers, 2003). The volume gives each attribute an architectural translation, reproduced here as the questions a tool owner can put to a rollout.

Attribute Question the adopter asks Architectural response
Relative advantage Is this better than how I work now? Measure task time and quality before and after; publish the numbers
Compatibility Does it fit my tools and my judgement? Integrate into systems of record; keep the user as decision-maker
Complexity Can I understand what it does? System-level explanation; plain-language model cards
Trialability Can I try it without consequences? Sandboxes with masked data; shadow mode
Observability Can I see others succeeding with it? Internal showcases; adoption dashboards visible to all

The volume's warning is that the gap between early adopters and the early majority is where AI programmes most often fall, and that crossing it requires that the system change, not only the message: guardrails, evaluation gates and golden paths exist so that the early majority receive a more reliable product than the innovators had. The pilot team should therefore not be the roll-out team (2, Nordqvist, 2026).

Kotter's eight steps applied to AI. Kotter's model of leading change (12, Kotter, 2012) is kept by the volume, with five steps whose failure modes change when the change is AI: urgency without hype, a coalition that includes the people who can stop the programme (the data protection officer, the CISO, legal counsel and, in most European organisations, the employee representatives), a vision that names what AI will not do, short-term wins that are real and measured on live cases, and anchoring without governance theatre (2, Nordqvist, 2026).

Westrum organisational culture typology. The typology of organisational cultures (13, Westrum, 2004) is used for psychological safety. For adoption the stakes are higher, the volume argues, because a model's failures are statistical and often invisible to its builders. A generative culture treats overrides as evaluation data, acknowledges error reports within a defined time, and never measures anyone on the acceptance rate of recommendations, because that metric rewards not looking (2, Nordqvist, 2026).

Employee consultation as design review. The method turns the consultation of works councils and unions into a design review with a different reviewer. Its output is a list of commitments, each recorded in the system's decision record and each bound to a control that enforces it and a test that proves it. The volume's worked example, a staff assistant whose commitments include that usage data is never used to assess individual performance and that adoption figures are reported only for groups of ten or more, shows the shape: a commitment, a control file, a test, and a reopen_triggers list so that consultation is a condition the pipeline can detect and not a one-off event. One commitment in the example has no automated test, and the file says so (2, Nordqvist, 2026).

People who carry the adoption

Five artefacts in the slice assign the human work of adoption to named roles.

Tool Kind Origin Purpose Note
Champions charter Artefact AI Governance, Chapter 15 A one-page charter for adoption champions, one per 40 to 60 staff from the community they serve, with protected time, error reports routed within two working days and a list of what champions do not do Listed in Appendix C of the volume; no separate template exists, and the charter is described in the chapter
Community of practice charter Artefact (Markdown) Architecture as Code (Chapter 18) A charter with purpose, structure (leader, technical advocates, learning and development partner, security representative), activities, knowledge sharing and metrics Full template in the volume
Engagement charter Artefact (Markdown) AI Governance, Chapter 12 A time-boxed charter for an enablement team working with a product team, with what the team will and will not do and exit criteria Full template in the volume; the worked example uses a 12-week engagement
Declared intent and staff statement on AI tools Artefact AI Governance, Chapters 1 and 4; Appendix C A statement of intent and a staff-facing statement on AI tools (Principle 1) Listed in Appendix C; no full template is given in a code block
Culture as Code and Knowledge as Code Method Architecture as Code (Chapter 23) Team norms and lessons learned as versioned files, for example a team-norms.yaml that records review service levels and onboarding steps Changes to a norm are traceable in version history

The champions charter shows what the series means by an adoption role that cannot turn into surveillance. It excludes the pilot team in the first term, counts champions' time as a contribution to the unit and not as a sales target, and lists what champions do not do: approve use cases, interpret policy, or report on whether named colleagues use the tool (2, Nordqvist, 2026). The engagement charter has a different but related discipline. Its exit criteria are in terms of the receiving team's competence, so that the enablement team's work ends when the team can do the work unaided: the readiness review passed with the team presenting, practitioner level reached for two team members, and a failing evaluation result interpreted without assistance (2, Nordqvist, 2026). Architecture as Code also keeps a set of course templates in its repository: an action plan canvas, a lab submission checklist, a module workbook template and a radar reflection log. They are companion material for a cohort, stored under course/templates, and not a chapter of the volume; they are the right tools where an organisation chooses to teach the practice as a course (1, Nordqvist, 2025).

Evidence that a tool is adopted

The adoption dashboard definition is the series' answer to the second question of the chapter.

Adoption dashboard definition
Kind Artefact (YAML)
Origin AI Governance, Chapter 15
Purpose A metrics definition for measuring the adoption of a system
Use when At roll-out; the pipeline that deploys the system also deploys the dashboard
Inputs Active and eligible users, recommendations shown and overridden, the feedback tracker, training records, policy test results
Outputs A dashboard for the change lead, the system owner and the steering committee
Identifier family dashboards/adoption/*.yaml
Full template AI Governance, Chapter 15, quoted below 
# dashboards/adoption/benefit-triage-adoption.yaml
dashboard: adoption-benefit-eligibility-triage
system_ref: ALG-2026-014
refresh: daily
audiences: [change_lead, system_owner, steering_committee]
metrics:
  - id: active_users_ratio
    formula: active_users / eligible_users
    window: 28d
    target: ">= 0.70 by 2026-12-31"
  - id: override_rate
    formula: overridden / recommendations_shown
    window: 7d
    healthy_range: [0.03, 0.15]
    note: Below range suggests rubber-stamping; above suggests low quality
  - id: error_reports_open
    source: feedback_tracker
    alert_above: 20
  - id: literacy_training_completion
    formula: trained_users / eligible_users
    regulatory_ref: AI Act Article 4
  - id: consultation_commitments_met
    source: policy_test_results
    target: "== 1.0"
privacy:
  minimum_group_size: 10
  individual_level_access: none
  retention_days: 400

(Quoted from the checkout of AI Governance used for this book. The identifiers and thresholds are the volume's illustrative values.) Two features carry the lesson. The healthy_range on the override rate encodes that both extremes are failures: a rate near zero means oversight has become ceremony, and a high rate means the model is not good enough to deploy. The privacy block encodes the cultural commitment, reporting only for groups of ten or more and with bounded retention; without it, the dashboard becomes a surveillance tool, and the volume says the works council would be right to say so (2, Nordqvist, 2026).

The benefits record answers a different question: is the tool worth keeping. It tracks the benefit quarterly against the value hypothesis, and the volume's worked example uses a staged rollout to create a comparison group. Wave 1 units, about 2,400 staff, were compared with wave 2 units before access, about 800 staff, over one quarter. A measured outcome (drafting time per standard letter) was kept apart from a self-reported estimate, which was not used in the benefit figure, and the record listed a disbenefit (second-line queries up by 6 per cent) and a limit (the comparison units differ in case mix, so the effect may be overstated). The record is a template, portfolio/benefits/*, and its last field is the date of the next review (2, Nordqvist, 2026).

Gates before use

A tool that is adopted at scale passes a gate first. The gate is a checklist whose items are verified by evidence in the repository, and the series has several.

Tool Kind Origin Purpose Note
Production readiness review Method AI Platform and Security, Chapter 23 The gate between a pilot and a service A gate and not a meeting; the automated part verifies the presence and freshness of the AI Decision Record, evaluation results and runbook; the human part asks whether the purpose is honestly described
Production readiness checklist Artefact (YAML) AI Platform and Security, Chapter 23 A readiness checklist aligned to the deployer obligations of Article 26 of the AI Act (195, European Union, 2024) readiness/checklist.yaml, with fields use_case, gate_version, checks and outcome; each check has an id, description, evidence, automated and, where it applies, regulatory_reference
Security review checklist for a new AI system Artefact (Markdown) AI Platform and Security, Chapter 16 An ordered checklist that the security architect reviews before production Foundations first, then the threat model, inputs, retrieval, outputs and tools, then the ML-BOM and provenance, then the injection and leakage suites and the incident playbook; an unchecked item blocks the merge unless an ADR records the exception
Return-to-service checklist for an AI system Artefact (YAML) AI Red Team, Chapter 23 Re-evaluation, rollback and re-enabling of an AI system or agent after an incident Kind ReturnToServiceChecklist, identifier family RTS-*; the return runs in stages, the first being recommend-only for five working days with every route confirmed by a handler
Prohibited-practice check Artefact (YAML) AI Threat, Chapter 13 A check in the AI inventory pipeline that a system does not fall under the prohibited practices of Article 5 of the AI Act (195, European Union, 2024) Identifier family PPC-* (PPC-NR-01); not listed in the appendix of the volume; Chapter 7 treats the inventory pipeline

The production readiness checklist is the principal artefact. The pipeline stage that runs it blocks deployment until each item's evidence exists and is newer than the last model or prompt change, or an exception is recorded with an owner and an expiry. When Hansa Mutual ran the gate for its claims-triage assistant (use case UC-2026-014), the run recorded seventeen passes, two passes with exception and one failure, and the go-live decision was recorded as an AI Decision Record (AIDR-0034) that shows who accepted the residual risk and on what conditions (3, Nordqvist, 2026). The checklist is also a model for the other gates: each check names its evidence, whether it is automated, and its regulatory basis, and an item that cannot be answered counts as a failure and not as a pass.

The return-to-service checklist belongs here for a reason that is easy to miss. Re-enabling a tool after an incident is an adoption in miniature. The volume's staged return puts the agent first back in the behaviour of its predecessor and lets a week of real claims show whether it behaves as evaluated before it moves on, on the condition that nothing deviated in the first stage (4, Nordqvist, 2026). Chapter 13 treats the checklist as a recovery tool.

Plans that carry an adoption

An adoption needs a plan with owners and dates. Seven plan-shaped tools in the volumes are listed in the table, in the order in which a practitioner is likely to need them.

Tool Kind Origin Purpose
Five things on Monday and the first week Method AI Operations, Chapter 31 A first week of work producing five written records and a gap list, so that the organisation can see what it can prove: the loop for one Tier 1 service on one page, a ceiling per action class with named stop holders, the identities that can change production, the verifier of one automatic repair, and the oldest recoverability claim with its six parts
30-60-90-day plan Artefact AI Platform and Security, Chapter 18 A plan for a large organisation or authority responding to AI-enabled threats; days 1 to 30 inventory and patch policy, 31 to 60 compensating controls and decision rights, 61 to 90 service levels and adversary emulation
Programme plan Artefact (YAML, kind ProgrammePlan) AI Governance, Chapter 25 A first, next and later plan for the two organisations, with workstreams, outcomes, evidence files and due days
Ninety-day plan Artefact AI Blue, Chapter 28 A one-page plan that moves a team from not knowing what its AI does to being able to show, from its own records, who decided what and whether it can stop and recover
Two-year plan (PLAN-*) Artefact (YAML) AI Blue, Chapter 27 Turns conclusions into at most six measures with owners, due dates and verification; PLAN-NR-BT-2027 and PLAN-HM-BT-2027 are the examples
Turning a conclusion into a plan Method AI Blue, Chapter 27 A procedure from a year of records to a measured plan
Practical-guide structure Method The authoring guide of AI Red Team Each practical guide in the series has a purpose, roles, numbered steps, defaults to adapt and a definition of done

Three features recur and are worth copying. A plan is built from decisions already recorded, and it does not ask a body to decide again what a record has already decided. Each measure has an owner, a date and a verification that produces evidence, so that the plan can be checked and not only read. And any increase in delegation is written as a gate on the class's own evidence: a threshold, a period, a named grantor and a stop rule, with two consecutive quarters as the volume's default (8, Nordqvist, 2026). The practical-guide structure is the reason the series' guides can be compared at all. It is a repository convention of AI Red Team and is carried by the authoring guides of AI Blue, AI Purple and AI Operations.

Maintenance and review

A tool that was adopted on evidence stays adopted only if the evidence is renewed. The series' instruments for this are checklists with a review cycle, records of review, and calendar-bound reviews of the whole practice.

Practice checklist
Kind Artefact (YAML)
Origin AI Governance, Chapter 21
Purpose The practices of the volume by lifecycle stage as a checklist that can be checked as code
Inputs The evidence manifest of the volume's Chapter 11
Outputs A report to the production readiness review
Identifier family ai-practice-checklist.yaml, kind PracticeChecklist
Full template AI Governance, Chapter 21

The checklist's items each name a stage (intake, design, assure, operate, retire), the obligation or principle the item serves, the evidence that demonstrates it and the chapter that explains it. Its metadata carries review_cycle_days: 90, which makes the checklist itself a tool with a review date. Regulated sectors add items for DORA, NIS 2 or sector law, and public authorities add the fundamental rights impact assessment and the algorithm register entry, in the same file, so that it remains the single statement of what "ready" means (2, Nordqvist, 2026). One item in the example is a retirement item: retirement criteria are monitored, with the AI Decision Record as the evidence.

Records and calendars of review

Tool Kind Origin Purpose Note
Review record (REV-*) Artefact (YAML) The Transformed Security Architect, Chapter 14 and Appendix A Records the review of an AI proposal: the techniques, the minutes, the findings and the decision Signed and immutable once the change merges; the chapter uses REV-HM-0014 and the appendix REV-HM-0001
Review checklist Artefact The Transformed Security Architect, Chapter 14 A checklist for reviewing AI proposals Named in Appendix B and said to be in Appendix A, but no standalone checklist exists; only the protocol and the review record do (Findings, Chapter 25)
Handover checklist from ADRs Artefact Architecture as Code (Chapter 4) A three-step checklist for inheriting a service through its ADRs: review the latest ADRs, inspect the automation evidence they reference, and capture deviations in a drift section with a follow-up review if next_review_due has lapsed Inline in the chapter; no separate template
Monthly review of the operations loop Method AI Operations, Chapter 29 A one-hour monthly review that turns the loop's records into decisions: claims by expiry date, with every claim expiring within 60 days scheduled The practical guide as it stands lists a single numbered step (Findings)
Year-in-review from records Method AI Blue, Chapter 26 An account of the year that contains only what a record shows Steps: list the decisions, incidents and reviews, measures; classify each control; compare plan and result; write the next year's questions
Reviewing a year in the role Method The Transformed Security Architect, Chapter 25 Reviews a year against the four shifts from a generated timeline A turn that left no record is itself a finding
Knowledge hygiene Method AI Operations, Chapter 12 Ownership, review dates and verification of operational knowledge, with retirement See below

The review record is the best-defined of the review artefacts. Its worked example records a policy change proposed by an agent at Level 1 Assisted, the oracle tests that passed, the test that failed because the reviewer had added it, the objections of a critique skill with each one accepted or rejected with a reason, the minutes spent, the decision in two rounds, and the signature. The volume's observation about the example is the right one for any review artefact: the defect was found by a test the reviewer wrote and not by reading, and the agent could not have passed by editing the test (6, Nordqvist, 2026).

Knowledge hygiene turns the maintenance of knowledge into a property that can be checked. Four properties make a piece of knowledge usable in operations: a named owning role, a link to a service record, a last-verified date with the method, and an expiry. "Verified by game day on 2027-11-25" is evidence and "reviewed" is not. The volume adds that retrieval makes staleness fast, because an assistant that retrieves an out-of-date runbook will quote it fluently, so the retrieval index carries the date, the method and the owner, and articles past expiry are excluded from recommendations for Tier 1 services or marked as unverified (10, Nordqvist, 2026). Knowledge-Centered Service, described in its own documentation, organises the work as a Solve Loop and an Evolve Loop (26, Consortium for Service Innovation, n.d.); the volume borrows the separation and notes that the experience behind the method is mainly that of the service desk.

The two reviews of a year differ in what they list, and in both the discipline is the same: a sentence in the review must have a record behind it, every figure must carry its denominator, and no measure is reported by person. The year-in-review of AI Blue adds that a team of six reports counts, and a team of 38 may report rates (8, Nordqvist, 2026).

Retirement and exit

The series is more consistent in its warnings about retirement than in its tools for it. AI Governance names the model nobody retires as an anti-pattern: a model trained four years earlier still scores applications, its training data predates a change in law, its pipeline contractor has left, and its monitoring disappeared in a tooling migration, because no retirement criterion was ever defined. The remedy is that every AI Decision Record states retirement criteria, that every inventory entry has an owner and a review date, and that the portfolio register treats retirement as a first-class outcome (2, Nordqvist, 2026). Nordvik Region's decommissioning practice (AIDR-0018 for its benefits-triage system, which is procured and high-risk) exists because retiring a procured system needs a new procurement.

Four instruments in the volumes bear on retirement, though none is a stand-alone retirement template in this chapter's slice.

  • Retirement criteria in the decision record. The decision record that approves a tool is the place where its end is stated. The governance forum's outcome "retire or redesign" applies when value does not justify cost, a cheaper option meets the unit of value, the supplier's basis has changed or a licensed capability supersedes the tool; it produces a retirement record (AI Governance, Chapter 21) (2, Nordqvist, 2026).
  • Closing a pilot deliberately. AI Platform and Security (Chapter 23) notes that a pilot that will not proceed often holds production data extracts, live credentials and an index whose permissions were copied once. Closing it means revoking credentials, deleting extracts and indexes with a recorded confirmation and archiving the decision record that ended it, and the golden path makes this cheap because its template lists the resources it created (3, Nordqvist, 2026).
  • Exit and the contract. For a financial institution, a supplier whose ICT services support a critical or important function brings contractual and exit obligations under DORA (Articles 28(8) and 30(3), point (f)) that nobody may have documented, so the option comparison carries the exit in the same row as the price (2, Nordqvist, 2026) (197, European Union, 2022). Chapter 9 treats the supplier exit plan.
  • Expiry of knowledge and claims. Knowledge hygiene and the register of claims in AI Operations give every article, runbook and recoverability claim an expiry. An item that passes expiry without a test is shown as unverified, and a tool whose evidence has expired is a candidate for retirement as much as a tool whose owner has left (10, Nordqvist, 2026).

The gap in this part of the series is the absence of one artefact that records a tool's retirement: what was revoked, what was deleted, what was archived and who confirmed it. The pieces exist in the four instruments above. A practitioner who needs the artefact must assemble it, and Chapter 24 returns to the assembly in building a toolbox.

Anti-patterns

An anti-pattern, in the series' sense, is a solution that looks reasonable, is adopted repeatedly and produces the same bad outcome every time. The volumes catalogue them for their own subjects, and the later volumes share a record format for them. The anti-pattern tools are the most numerous in this chapter's slice, 13 of the 55 entries, and they fall into four groups: catalogues, detection, records and review procedures.

Catalogues

Tool Kind Origin Entries
Anti-pattern catalogue Artefact AI Governance, Chapter 20 Fifteen named patterns in three clusters. Portfolio and strategy: pilot purgatory, shadow AI, the model-as-the-product fallacy, vendor-defined architecture. Governance and compliance: governance theatre, compliance by checkbox, data protection as an afterthought, the centre of excellence that excels at saying no, the platform as someone else's problem, accountability delegated to the supplier. Engineering and operations: unbounded agents, evaluation by demo, prompt sprawl, GPU hoarding, the model nobody retires
Anti-pattern checklist Artefact (YAML) AI Boss, Chapter 31 and Appendix A Twelve patterns (AP-01 to AP-12), each with a signal, a red condition and a remedy: delegation nobody recorded, rubber-stamp approval, throughput benchmark for people, appeal to nobody, vendor release changed behaviour, representatives informed after the fact, rest rule as soft constraint, manager measured against the system, junior work vanished, Level 4 by accident, explanation nobody can read, register never reviewed
Diagnosing anti-patterns Method The Transformed Security Architect, Chapter 24 Twelve questions answered from records, to find which of five anti-patterns a practice shows: the architect as bottleneck, the diagram nobody runs, the AI that approved itself, the control catalogue nobody maps and the sign-off in seconds
Eight anti-patterns Method AI Operations, Chapter 28 The green dashboard, the self-healing mask, the shared-blind-spot verifier, the unowned runbook, the god credential, the dead-man's switch that never fires, the first ring skipped and the claim at the wrong scale
Anti-pattern checklist (AP-*) Artefact AI Purple, Chapter 26 and Appendix B (B.26) Eight patterns of the loop: purple theatre, the red team that grades its own homework, coverage by assertion, the green dashboard, overfitted detections, the emulation that became an incident, the findings register that leaked and the contract with no testing right
Anti-pattern review in two hours Method AI Blue, Chapter 25 Seven patterns: closing by metric, the unowned detection, the unstoppable agent, the provider's black box, the rubber-stamp review, the empty entry rung and the unmonitored monitor

The catalogue of AI Governance shows the property that makes the whole group usable: each pattern is described by its symptom, its consequence and its remedy, so that it can be recognised early and named without causing offence. The volume also notes that several patterns are mode errors, in which a system in one usage mode is governed as if it belonged to another (Mode 3 and Mode 5 errors are forms of the unbounded agent; Mode 0 and Mode 1 errors are the two faces of shadow AI) (2, Nordqvist, 2026). The volumes do not agree on the number of patterns in the catalogue: its headings and the description of its figure give fifteen, while the inventory records sixteen (Findings).

Detection as code

The anti-pattern fitness functions are the only tool in the group that finds a pattern without a meeting.
Kind Artefact (YAML)
Origin AI Governance, Chapter 20
Purpose A suite of fitness functions that detect the catalogued anti-patterns from traces in the inventory, model registry, gateway logs and pipeline history
Use when On a schedule (the example runs weekly), writing results to the evidence store
Inputs A data source, a query and a threshold per pattern
Outputs A signal that fires when the threshold is crossed, with the chapter that holds the remedy
Identifier family anti-pattern-fitness-functions.yaml, kind FitnessFunctionSuite
Full template AI Governance, Chapter 20, quoted below (three of the functions) 
# anti-pattern-fitness-functions.yaml
apiVersion: ai-architecture.example.org/v1
kind: FitnessFunctionSuite
metadata:
  name: anti-pattern-signals
  owner: chief-architect-office
  schedule: "0 6 * * 1"
functions:
  - id: pilot-purgatory
    source: portfolio_register
    query: "count(use_cases where stage == 'pilot' and age_days > 365)"
    threshold: { max: 3 }
    remedy_chapter: 16
  - id: shadow-ai
    source: network_telemetry
    query: "count(distinct ai_endpoints not in ai_inventory)"
    threshold: { max: 0 }
    remedy_chapter: 9
  - id: unbounded-agents
    source: model_registry
    query: "count(agents where permission_manifest is null)"
    threshold: { max: 0 }
    remedy_chapter: 13

(Quoted from the checkout of AI Governance used for this book. The remedy_chapter values refer to chapters of that volume.) The thresholds are illustrative, as the volume says, and so is the point about the signal: a function that fires is an invitation to look and not an accusation (2, Nordqvist, 2026). The sense in which these are "fitness functions" comes from Architecture as Code (Chapter 13), which the volume cites.

Records

Four volumes keep a record of an anti-pattern that was found, under an identifier family AP-* with the organisation and the subject in the prefix, and a fifth keeps a checklist of signals. The records differ in their fields, and the table compares them.

Volume Prefix and examples Subject field Distinctive fields
The Transformed Security Architect, Chapter 24 AP-HM-SIS-01 shift_violated symptom, cause, remedy, verification with cadence and pass_if, reporting, status, review_due
AI Blue, Chapter 25 and Appendix A AP-NR-SOC-01 to -03, AP-HM-SOC-01 to -04 functions (B1 to B5) pattern, evidence, control, owner, retest with closes_on
AI Purple, Chapter 26 and Appendix A AP-HM-LOOP-01 to -05, AP-NR-LOOP-01 to -03 stages (P1 to P5) pattern, signs, cause, evidence, control, owner, retest
AI Operations, Chapter 28 AP-HM-OPS-01 to -05, AP-NR-OPS-01 to -03 functions (O1 to O5) pattern, evidence, public_analogues, control, owner, retest
AI Boss, Chapter 31 and Appendix A AP-01 to AP-12 in a checklist none signal, red_if, remedy

The record of AI Operations is the latest of the family and the one that states it follows the schema of AI Purple. It is quoted here as the template for an anti-pattern record.

anti_pattern:
  id: AP-HM-OPS-05
  name: first ring skipped
  organisation: Hansa Mutual
  functions: [O3 Change]
  status: mitigated            # open | mitigated | closed
  decision: AIDR-0985
  recorded: 2029-03-13         # illustrative
pattern: >
  A change that alters runtime behaviour was classed as standard and
  went to production without passing the first ring.
evidence:
  incident: INC-HM-2027-0833   # 2027-09-30, AI gateway routing push
  effect: "claims assistant broken in four markets for 47 minutes"
  problem: PRB-HM-0019
public_analogues: [CrowdStrike 2024, Google Cloud 2025, Cloudflare 2025]
control:
  rule: "every runtime-changing push passes at least the first ring"
  stop_conditions: "held by the verifier; the releasing identity cannot edit"
  seeded_fault: "quarterly faulty change to the first ring on a test tenant"
owner: head-of-site-reliability
retest:
  due: 2029-06-30
  closes_on: "seeded change halted by the verifier within target, twice"

(Quoted from the checkout of AI Operations used for this book. The volume marks the decision and the dates as illustrative.) Its closing rule is the one that makes a record more than a note: the pattern is closed when a re-test passes, not when the remedy is merged. AI Blue states the same rule ("a pattern is closed only when a re-test has passed"), and the checklist of AI Boss adds that findings are closed only when the re-test passes. The record of The Transformed Security Architect reaches the same end by a different route: its symptom is defined by signals that systems produce (a median approval time of 28 seconds in the example), so that the finding cannot be argued away, and the record can close only when a seeded-error drill meets its threshold (6, Nordqvist, 2026) (7, Nordqvist, 2026) (8, Nordqvist, 2026) (9, Nordqvist, 2026) (10, Nordqvist, 2026).

Review procedures

The review procedures differ in subject but share a structure. Each starts from records and not from memory, each asks for a sample and a count, each sets a default threshold that the organisation is told to adapt, each assigns a finding to an owner other than the person assessed, and each ends in a record with a re-test date.

  • Diagnosing anti-patterns (The Transformed Security Architect, Chapter 24) asks twelve questions of the architecture practice over the last two quarters, two or three per anti-pattern. A question is red if it meets the condition in the table's last column or cannot be answered, for example a median wait for routine classes of more than 5 working days, or a share of seeded errors detected below 80 per cent. An independent reader re-derives three answers from the raw records, including one red and one green (6, Nordqvist, 2026).
  • Reviewing against the anti-pattern checklist (AI Boss, Chapter 31) runs the twelve signals of the checklist quarterly with the works council or unions and the data protection officer, reports at team level with no individual figures, and lists M2 and M3 as excluded uses (7, Nordqvist, 2026).
  • Anti-pattern review in two hours (AI Blue, Chapter 25) is timed: ten minutes to set the rules, a check per pattern of ten to fifteen minutes, and fifteen to assign and decide. It states the rules at the start: evidence comes from records, and nobody is named in any finding (8, Nordqvist, 2026).
  • Recognising early signs of anti-patterns (AI Purple, Chapter 26) is a half-day loop review once a year and after any incident. It draws 20 findings closed in the last two quarters and counts those closed at merge; above 10 per cent, a record is opened (9, Nordqvist, 2026).
  • Eight anti-patterns (AI Operations, Chapter 28) gives each pattern its public cases, its mechanism, its early signs and the control that changes the outcome, and its table assigns each an identifier and a function (10, Nordqvist, 2026).

The thresholds in these procedures are defaults chosen by their authors for the illustrations of their books. They are not standards, and each volume says so. A practitioner who applies them to another team should set the sample size and the threshold to the organisation's own volume, supervisor and works agreement.

Across the usage modes

AI Governance (Chapter 15) shows that a single adoption plan for AI fits no usage mode, because what changes for staff differs. The table is the volume's own and applies to every tool in the adoption section of this chapter.

Usage mode What changes for staff Communication and support it needs
Mode 0 Ambient AI AI summaries and notes simply appear in existing tools Guidance on checking AI output; notice when a supplier switches on a feature
Mode 1 Conversational assistants A new general tool; individual habits change Rules on what may be entered, verification habits, champions
Mode 2 Embedded workplace assistants Familiar tools surface anything the user can open Advance notice, a permissions clean-up as part of the launch
Mode 3 Agentic work tools Specialists delegate tasks and review results Sandbox onboarding, team norms for reviewing agent work
Mode 4 Built AI applications A defined process changes; decision paths may shift Consultation on design, published error rates, oversight training
Mode 5 Autonomous production agents Work moves from doing to supervising Early consultation on role change, retraining paths

The volume adds that Mode 2 fails most quietly, when staff find that the assistant can retrieve a document they were never meant to see, and that Modes 4 and 5 carry the heaviest consultation duties (2, Nordqvist, 2026). Several anti-patterns concentrate in particular modes, which the anti-pattern tables of AI Governance (Chapter 20), The Transformed Security Architect (Chapter 24) and AI Operations (Chapter 28) show; where a review of this chapter's kind is run, the delegation profile is the first document to read.

Worked example: adopting a policy engine at Nordvik Region

Illustrative example. The example takes a tool that Nordvik Region's records establish, and a roadmap that is illustrative. The established facts are three. Nordvik Region has a security architect and a CISO's deputy who co-own protected paths in the AI platform repository. A decision record, AIDR-0501 of 2026-11-20, moved the Region's reference architecture into that repository as a Structurizr model and four Rego policies, which the diagnostic of the same volume cites as the existing remedy for "the reference document nobody runs" (6, Nordqvist, 2026). And the policy decision point that evaluates agent permission manifests in the platform uses Open Policy Agent, the engine that Architecture as Code uses for infrastructure guardrails (1, Nordqvist, 2025) (51, Open Policy Agent, n.d.). The table that follows is a roadmap for widening the use of that engine across the estate. Everything in it that is not in those records is illustrative, including the order, the gates and the metrics. The four phases take the shape of the FINOS blueprint roadmap (125, FINOS, n.d.).

Phase Tools of this chapter Decision at the gate Evidence that closes the phase
0. Select Option comparison on one unit of value (a platform change reviewed against the reference architecture); options: keep the document and the review board, write the rules as scripts, adopt an open-source policy engine, use the policy feature of a vendor platform, do nothing Choose an option; record it with exit conditions and a review date A decision record in the AI Decision Record series; the comparison table stored with it
1. Pilot and prove Readiness scorecard rewritten for a policy engine (skills in the rule language, tests in the pipeline, an owner for each protected path, budget for training); production readiness checklist for the first policies Proceed if the total is in the top band and no critical gap is open; otherwise a remediation roadmap Scorecard with evidence in the notes column; checklist run with every item either passed or carrying an exception with an owner and an expiry
2. Expand and federate Champions charter modelled on AI Governance, Chapter 15; engagement charter for the platform team's work with a product team, with exit criteria in terms of the receiving team's competence; adoption dashboard definition Extend to a second and third team when the dashboard shows use and the exceptions are within range Adoption dashboard with minimum group size and no individual-level access; exception rate within a healthy range
3. Govern and optimise Anti-pattern fitness functions for the engine; practice checklist with a 90-day review cycle; review record for every change to a protected path Continue, change or pause Fitness functions run weekly; review records signed and stored with the change
4. Sustain and retire Knowledge hygiene for the policy library; retirement criteria in the decision record; anti-pattern record for any pattern found Renew, redesign or retire at the review date A dated statement, per policy, of the last test and the owner; a retirement checklist if the decision is to retire

Two details are worth showing as artefacts, both illustrative and both in the formats of the volumes. The fitness functions of phase 3 would follow the suite quoted above, with the engine's own failure modes as the patterns:

# policy-engine-fitness-functions.yaml (illustrative)
apiVersion: ai-architecture.example.org/v1
kind: FitnessFunctionSuite
metadata:
  name: policy-engine-signals
  owner: security-architecture
  schedule: "0 6 * * 1"
functions:
  - id: policy-without-owner
    source: policy_repository
    query: "count(policies where owner is null)"
    threshold: { max: 0 }
  - id: exception-past-expiry
    source: exception_register
    query: "count(exceptions where expires < today)"
    threshold: { max: 0 }
  - id: protected-path-without-review
    source: pipeline_history
    query: "count(merges to protected paths without a review record)"
    threshold: { max: 0 }

and the exception rate of phase 2 plays for a policy engine the part that the override rate plays for an assistant. An exception rate near zero may mean that nothing is checked, and a high rate may mean the rules are wrong or unwelcome; the same reasoning as the healthy_range of the adoption dashboard applies. The retirement test in phase 4 is that every policy has a date of last test and an owner, and that the library can be exported from the repository, because the policies are the organisation's own files. The exit cost is then the cost of rewriting the rules in another language, which the option comparison of phase 0 should have priced.

Nordvik Region and Hansa Mutual

Nordvik Region's pattern in this chapter is the pattern of a cautious buyer. Its largest risks are pilot purgatory, vendor-defined architecture and the model nobody retires, because retiring a procured system needs a new procurement; its retirement practice (AIDR-0018) exists for that reason. Its security architect ran the diagnostic of The Transformed Security Architect with the enterprise architect as the independent reader, and two questions were red, the architect as bottleneck and the reference document nobody runs; the CISO owns the findings, recorded as AIDR-0506, which adds the drift age as a measure (6, Nordqvist, 2026). Its record of a claim at the wrong scale (AP-NR-OPS-03) shows a recoverability claim reported as met although its last test failed and its corrective actions were closed without a re-test (a portal failover against a 2-hour objective) (10, Nordqvist, 2026).

Hansa Mutual's pattern is the pattern of a builder. It runs the production readiness gate for its claims-triage assistant and carries the same golden path into further markets, where each new market is a new readiness review with national rules in place of the AI Act rows for the United Kingdom and Swiss entities (3, Nordqvist, 2026). Its consultations differ by country, so that the commitments carry an applies_in scope (2, Nordqvist, 2026). Its anti-pattern records cover the sign-off in seconds (AP-HM-SIS-01, AP-HM-SOC-01), the first ring skipped (AP-HM-OPS-05) and overfitted detections (AP-HM-LOOP-04). In the diagnostic of The Transformed Security Architect both organisations found that most remedies existed before the diagnosis, which added the name, the owner, the test and the date.

Coverage of the inventory

The slice of this chapter holds 55 entries (24 artefacts, 22 methods and 9 third-party tools and standards). All 55 are accounted for. Of these, 46 are treated in the entries, tables or paragraphs above; two of them, the return-to-service checklist (primary home Chapter 13) and the prohibited-practice check (primary home Chapter 7), appear only as examples of a gate or a staged return. Nine are not treated here and are reassigned in data/findings/chapter_03.md: the four golden signals (Chapter 15), the tabletop with a decision-rights table of AI Blue, the tabletop of decision rights of AI Purple and the tabletop record TTX-* (Chapters 13 and 14), the six fields of decision rights of AI Operations (Chapter 18), and the unassisted practice, the manual-practice clause, the four shifts assessment and the framing of the question (Chapter 21). Of the 58 entries not yet placed, 14 are treated here (the legacy import script, the benefits record, the declared intent and staff statement, the engagement charter, the programme plan, the 30-60-90-day plan, the ninety-day plan, the two-year plan, turning a conclusion into a plan, the five things on Monday, the year-in-review, the review of a year in the role, knowledge hygiene and the practical-guide structure); the other 44 are assigned to other chapters in data/findings/chapter_03.md. Appendix A lists every inventoried entry, including those that this chapter does not treat.

Summary

This chapter treated the lifecycle of a tool as four decisions: select, adopt, review and retire. The chapter's own conclusions follow.

A tool is chosen against a unit of value and not against a feature list. The series' five options (build, buy, reuse, solve without AI, do nothing) map onto the four kinds of tool, and a template, a product or a method is the right choice according to whether the organisation must own the thing, cannot build it, or needs a repeatable human procedure. The option comparison makes the choice reviewable, and every outcome of it, including "do nothing", carries a review date.

A tool is adopted when it is ready, when it spreads, and when the records show use. Readiness is a dated reading and not a certificate; spread depends on the system changing and not only the message; the people affected are consulted as designers; and adoption is evidenced by a dashboard that protects the people it measures, by a benefits record that distinguishes a measured outcome from an estimate, and by a gate whose items name their evidence. All five of these produce records with dates.

A tool still works when its evidence is current. The series answers the second question of the chapter in one sentence, that adopted means in use and working means tested with a date, and it applies the sentence to checklists, knowledge, claims and reviews. A review that lists only what a record shows is the form of review the series recommends.

A tool is retired by a decision recorded when it was adopted. The retirement criteria belong in the decision record; closing a pilot or a tool means revoking, deleting, archiving and confirming; and an exit that was not priced in the option comparison is paid for at the worst moment. The series has no single retirement artefact, and this chapter's worked example assembles one from its parts.

The anti-patterns of the volumes are one family seen from several vantage points. They share a form, a record with an owner, a control and a re-test, and a rule, that a pattern is closed by a passed test and not by a merged remedy. Their thresholds are defaults and must be adapted.

Sources

  1. Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
  2. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
  3. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
  4. Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
  5. Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
  6. Nordqvist, G. AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. (7, Nordqvist, 2026)
  7. Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
  8. Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
  9. Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
  10. Rogers, E. Diffusion of Innovations. (11, Rogers, 2003)
  11. Kotter, J. Leading Change. (12, Kotter, 2012)
  12. Westrum, R. A typology of organisational cultures. (13, Westrum, 2004)
  13. Beyer, B., Jones, C., Petoff, J., Murphy, N. R. Site Reliability Engineering: How Google Runs Production Systems. (14, Beyer et al., 2016)
  14. PeopleCert. ITIL Certifications. (25, PeopleCert, n.d.)
  15. Consortium for Service Innovation. KCS v6 Practices Guide: The Evolve Loop. (26, Consortium for Service Innovation, n.d.)
  16. The Open Group. The TOGAF Standard, 10th Edition. (27, The Open Group, 2022)
  17. Sherwood, J., Clark, A., Lynas, D. Enterprise Security Architecture: A Business-Driven Approach. (28, Sherwood et al., 2005)
  18. Forum of Incident Response and Security Teams. Traffic Light Protocol (TLP), version 2.0. (29, FIRST, n.d.)
  19. European Commission. The General-Purpose AI Code of Practice. (30, European Commission, 2025)
  20. European Commission. Commission publishes Code of Practice on marking and labelling AI-generated content. (31, European Commission, 2026)
  21. Open Policy Agent Contributors. Open Policy Agent Documentation. (51, Open Policy Agent, n.d.)
  22. HM Treasury. The Green Book (2026): UK Government Guidance on Appraisal. (123, HM Treasury, 2026)
  23. European Commission. Economic Appraisal Vademecum 2021–2027: General Principles and Sector Applications. (124, European Commission, 2021)
  24. FINOS. FINOS Software Project Blueprint. (125, FINOS, n.d.)
  25. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (195, European Union, 2024)
  26. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (197, European Union, 2022)