The Anatomy of a Tool: Kinds, Identifiers and Lifecycle

Chapter 1 defined the four kinds of tool: artefact, own tool, third-party tool and method. This chapter looks inside the largest group, the artefacts, and asks what a service record, a delegation profile, a mandate manifest, a rules-of-engagement manifest and a restore-test record have in common. The answer matters for the reader of a reference because a shared anatomy makes the catalogue searchable by habit. Once the reader knows that every artefact states a purpose, names its inputs and outputs, carries an identifier from a family, names an owner and gives a date on which its evidence is reviewed, she can read an unfamiliar artefact in half the time. The chapter also shows how the identifier families of ten volumes link into chains, so that a reader who holds one record can find the ones that depend on it.

The chapter treats no principal tool in the entry format, since the tools it discusses are treated in Parts II to VII. Its material comes from the templates and appendices of Architecture as Code (1, Nordqvist, 2025), AI Governance (2, Nordqvist, 2026), AI Platform and Security (3, Nordqvist, 2026), The Transformed Security Architect (6, Nordqvist, 2026), AI Purple (9, Nordqvist, 2026) and AI Operations (10, Nordqvist, 2026), and from the identifier families recorded in the inventory of the ten volumes.

How the identifier families link across the books

Figure 2.1: The identifier chain of Chapter 2's worked example. The service record, its objective record, the failed restore test, the change it motivated and the decision-rights file that accepts the risk form the chain in the upper part; the delegation profile, mandate and observer manifests and decision record that govern an agent acting on the service are in the lower part.

The common anatomy

The templates of the series were written by one author over several volumes, and they converge on a common frame. The frame is not a formal schema. It is a set of habits that show in the Appendix B entries of the later volumes, where each template is introduced by the same five labels: purpose, when to use, inputs, outputs and the chapter that explains the reasoning. This book uses the same labels for the entries of its chapters. The labels describe the tool as a reader meets it. Inside the template, the same habits appear as fields.

Part of the anatomy What it states Where it appears in the templates
Identifier Which record this is, in a family service in the service record; record in the objective record; delegation_profile; mandate; observer_manifest.id; restore_test
Status Where the record is in its life status in the delegation profile (proposed, active, suspended, retired) and in the mandate; status in the restore-test record (planned, passed, failed)
Version and date Which edition, and from when it applies version, date and effective
Owner Who answers for the record owner in the service record, mandate and observer manifest; owner_role in the objective record; accountable in the delegation profile
Decision record The AI Decision Record that approved it decision_record in the delegation profile; decision in the mandate and observer manifest
Links The records it depends on or governs service, slo, mandate, observer, runbook and similar fields that carry another family's identifier
Review and expiry When it must be looked at again and when it lapses map.next_review in the service record; review in the delegation profile; review_by and expires in the mandate; statement_of_independence_expires in the observer manifest; expiry in the restore-test record
Evidence What was tested, when and with what result evidence with test, date, result and age_months in the service record; verification and claim_effect in the restore-test record

Table 2.1: The common anatomy of an artefact and the fields in which it appears. The field names are those of the templates in Appendix B of AI Operations (10, Nordqvist, 2026); this chapter does not claim that other volumes use the same field names.

Three observations help the reader. First, not every artefact has every part. The service record has no status, because a service record describes a service and not a record in a life cycle, while the restore-test record has a status and a result but no owner of its own: its attestation names a role that is independent of the runner. The books do not force the frame onto a template where it does not fit. Second, the fields differ by name even where the part of the anatomy is the same: the AI Decision Record is decision_record in one template and decision in another. A reader who searches by field name will miss records; a reader who searches by identifier will not. Third, the frame is a convention of the series and not a standard. It is useful because it is consistent, and Chapter 25 returns to the places where it is not.

Purpose, inputs and outputs

Every artefact answers three questions before it asks the reader to fill anything in. What is it for? What does it need? What does it produce? The series puts the answer into a sentence for each, and this book repeats the sentences in its entries. The sentence of purpose is deliberately narrow. The service record "states the service, its tier, owner, objectives, dependencies, blast radius, the evidence of recovery and the unknowns", and it does so "in version control beside the service's infrastructure code" (10, Nordqvist, 2026). The delegation profile states, for one agent and one service, what the agent may do per action class and level, how much of the allowance it has kept, what verifies it and who stops it. The width of a purpose is a clue to the use: where a purpose needs "and" many times, the artefact is usually a summary of several records and links to them.

Inputs and outputs are the links of the chain. The inputs of the delegation profile are the service record, the mandate, the action-class catalogue, the observer manifest and the works agreement; its outputs are the profile file and an AI Decision Record. The inputs of one artefact are in this way the outputs of others, and a reader who wants to complete a record can follow the Inputs row to the artefacts that produce them.

Owner and accountability

Every artefact has a named owner, a role or a person. The series is firm on the point because the records often govern agents and decisions about services and people, and a record without an owner cannot be reviewed, contested or retired. The mandate manifest carries an owner, a list of operators and a level authority. In the template, the rota of operators may stop the agent without approval, and the level authority approves any rise in the agent's level (10, Nordqvist, 2026). The delegation profile separates the agent's owner from the authority that may raise a ceiling: lowering a ceiling is immediate, and raising one is a named authority's decision. An owner in the series is therefore not an administrator of a file. It is the person who can be asked why the record says what it says.

An identifier in the series has a family prefix, usually two to four capital letters followed by a hyphen, and a rest that carries the organisation, the year or both and a sequence. The inventory records the prefix as a pattern, for example SVC-*. The worked examples of the volumes show the conventions in use:

  • SVC-NR-002 and SVC-HM-004 are service records of Nordvik Region and Hansa Mutual, with the infix NR or HM and a sequence number.
  • INC-NR-2026-0071 and CHG-NR-2028-0007 are an incident record and a change record of Nordvik Region, with the infix, the year and a four-digit sequence.
  • RST-NR-2027-002 is the second restore-test record of 2027 at Nordvik Region.
  • MND-NR-OPS-003 is a mandate manifest for an operations agent; the volumes that govern other agents add their own function code, as in the MND-*-EMU-* mandates for emulation agents of AI Purple (9, Nordqvist, 2026).

The infix NR or HM is a convention of the examples. In the templates it is replaced by XX, as in SVC-XX-000, so that the reader fills in the organisation's own code. Neither the infix nor the year is a rule of the family; the series uses them where the worked example needs them.

The principal families and where they come from

Table 2.2 lists the principal identifier families of the inventory with the volumes that carry them. "First carried" means the earliest volume whose inventory entries use the prefix. It is a statement about the inventory, and it can differ from the history of how an idea developed: The Transformed Security Architect, for instance, set out a delegation register before AI Boss gave the delegation profile its prefix. The next column lists the later volumes that reuse the family. Chapter 4 to Chapter 23 give the entries.

Family What it identifies First carried Later volumes
ADR-* Architecture Decision Record Architecture as Code n/a
RISK-* Risk definition or risk register entry Architecture as Code AI Governance
AIDR-* AI Decision Record AI Governance AI Platform and Security, AI Red Team, AI Threat, and from The Transformed Security Architect a reserved number range per volume
UC-* Use-case intake and portfolio entry AI Governance AI Platform and Security
EXC-* Exception record AI Governance The Transformed Security Architect
FRIA-* Fundamental rights impact assessment AI Governance AI Boss
CTRL-* Control catalogue entry AI Platform and Security The Transformed Security Architect
RoE-* Rules-of-engagement manifest AI Red Team AI Purple
FND-* Finding record AI Red Team AI Blue, AI Purple
THR-* AI threat register entry AI Threat n/a
EVD-* Evidence record or manifest AI Threat AI Blue, AI Purple
MND-* Mandate manifest The Transformed Security Architect AI Boss, AI Blue, AI Purple, AI Operations
ROLE-* Role charter The Transformed Security Architect AI Boss, AI Blue, AI Purple, AI Operations
CMP-* Competence record The Transformed Security Architect AI Boss, AI Blue, AI Purple, AI Operations
STOP-* Timed stop drill record The Transformed Security Architect AI Operations
HZN-*, AP-* Horizon register, anti-pattern record The Transformed Security Architect AI Blue, AI Purple, AI Operations
MDR-*, CNT-* Management Decision Record, contestation record AI Boss n/a
DLG-* Delegation profile AI Boss AI Blue, AI Purple, AI Operations
DET-*, CASE-*, PBK-*, HNT-* Detection, case, playbook and hunt records AI Blue DET-* also in AI Purple
PIR-* Post-incident review AI Blue AI Operations
SCN-*, EMU-*, PRP-*, REG-*, COV-* Scenario, emulation plan, purple session, regression case, coverage record AI Purple n/a
SVC-*, SLO-*, RBK-*, OBS-*, RST-*, INC-*, PRB-*, CAP-* Service, objective, runbook, observer, restore test, incident, problem, capacity AI Operations n/a
CHG-* Change record AI Purple AI Operations

Table 2.2: The principal identifier families, the volume whose inventory entries carry the prefix first and the later volumes that reuse it. "n/a" means that no later volume carries the prefix in the inventory.

The table is a map, not a complete list. The inventory holds many more prefixes, most of them used by one volume for one artefact, and Appendix A lists them all. Two features of the map deserve attention.

The AI Decision Record runs through the whole series. It is the record that approves a decision about an AI system, and nearly every other artefact points to one. The volumes from The Transformed Security Architect on reserve a number range for their own decisions so that identifiers do not collide: AIDR-0500 to AIDR-0599 in The Transformed Security Architect, AIDR-0600 to AIDR-0699 in AI Boss, AIDR-0700 to AIDR-0799 in AI Blue (Nordvik Region AIDR-0700 to AIDR-0749 and Hansa Mutual AIDR-0750 to AIDR-0799), AIDR-0800 to AIDR-0899 in AI Purple and AIDR-0900 to AIDR-0999 in AI Operations. The split between the two organisations inside a range is documented for the later three volumes. A reader who finds an AIDR number can therefore tell from the range which volume's decision it is.

A prefix is not always a single artefact. Several prefixes are used for two or more artefacts, sometimes in different volumes and sometimes in the same one. DLG-* names a delegation profile in four volumes and, in AI Operations, also a decision-rights file with a checker. CHG-* names the change record of AI Purple, the change record and change class of AI Operations, and the model-change record that follows. CAP-* names both the capacity record and the cost-and-latency budget of an AI service. RST-* names the restore-test record and the exit-test record. Across volumes, SCE-* is the security chaos experiment manifest in AI Red Team and the chaos experiment record in The Transformed Security Architect; RP-* is the recovery plan as code in AI Red Team and the model-routing and carbon policy in AI Threat; and EVAL-* is the golden-dataset evaluation of a security AI component in one volume and the sycophancy evaluation configuration in the other. Where two volumes disagree, the chapters of this book say which volume defines the tool, and data/findings records the collisions for Chapter 25. A reader who searches by prefix should therefore read the Origin row before assuming which artefact an identifier names.

Tracing a chain: from a service record to a risk acceptance

The strongest reason to know the families is that records cite one another. The worked example is a chain from AI Operations that starts at a service record of Nordvik Region (10, Nordqvist, 2026). The service is SVC-NR-002, the citizen e-service portal, Tier 1. Its objective record SLO-NR-002 refers to the service and states how recovery is evidenced. The excerpt below is abbreviated from the record in Appendix A of that volume.

record: SLO-NR-002
service: SVC-NR-002          # citizen e-service portal, Tier 1
version: 1.0.0
effective: 2028-11-01
dependencies: [SVC-NR-004, external DNS at SamDrift]
recovery: {rto: 2h, rpo: 5m, evidence: RST-NR-2027-002, result: failed 2027-10-12}

The recovery line cites a restore-test record. RST-NR-2027-002 is the test of 2027-10-12 that failed over the portal to the recovery site in 5 hours 20 minutes against an objective of 2 hours; the review found a DNS time-to-live and an unrenewed certificate at the recovery site. The record withdraws the claim that the portal is recoverable within the objective, and the objective record shows the evidence beside the promise instead of omitting it.

Two further records depend on the failed test. The first is a change record, CHG-NR-2028-0007, for the automatic renewal of the portal certificate at the recovery site. It states that it was motivated by the test and says in the same record what it does not claim. The excerpt is again abbreviated.

change_record:
  id: CHG-NR-2028-0007
  service: SVC-NR-002                       # Tier 1
  title: Automatic renewal of the portal certificate at the recovery site
  motivated_by: [RST-NR-2027-002]
  claim_not_made: "failover of SVC-NR-002 is not shown to be recoverable; re-test open (Chapter 19)"

The second is a risk acceptance in the decision-rights file DRF-NR-001. It accepts the risk of the failed failover for a limited time and states the compensating control and the expiry, which is the end of March 2029 or the first passing re-test.

decision_rights_file: DRF-NR-001
decision_record: AIDR-0922
risk_acceptances:
  - id: DRF-NR-001/RA-01
    claim: "SVC-NR-002 failover to SamDrift site"      # RST-NR-2027-002 failed
    compensating_control: "manual fallback for fee payments; re-test before the tax season"
    expires: 2029-03-31              # or at the first passing re-test

The chain reads in both directions. From the service record, a reader reaches the objective, the test that failed, the change that responded and the acceptance that covers the gap. From the restore test, a reader reaches every record that cites it, which is the list of places to update when the portal is re-tested and passes. The identifiers make the links searchable in a repository: a search for RST-NR-2027-002 returns the objective record, the change record and the decision-rights file, and nothing else is needed to find them.

The right-hand side of Figure 2.1 is the same pattern for an agent. A delegation profile is written for one service and names the agent's mandate, the observer that verifies it and the AI Decision Record that approved it. The mandate manifest and the observer manifest each cite their own decision record, and the observer manifest names the performer's mandate so that the observer can be shown to be independent of the performer. The templates in Appendix B of AI Operations give the field names (mandate, observer, decision_record, decision), and the volumes' worked examples fill them in for the claims core system SVC-HM-001 of Hansa Mutual and its IT-operations agent. A reader who holds a delegation profile therefore holds four doors: the service, the mandate, the observer and the decision.

Chains in other volumes

The pattern is not specific to operations. In AI Purple the chain runs from the scenario record (SCN-*), which takes intelligence, a threat-register entry and a risk assessment as inputs, to the rules-of-engagement manifest (RoE-*) and the emulation plan (EMU-*) that bound a campaign, to the finding record (FND-*) that a campaign produces. At closure of the finding, a regression case (REG-*) keeps it as a repeatable test, an evidence manifest (EVD-*) signs each re-test, and the coverage record (COV-*) states per technique and environment what was tested, when, with what outcome and when the evidence expires (9, Nordqvist, 2026). The input and output rows of the Appendix B entries give these links. AI Red Team defines the rules-of-engagement manifest and the finding record on which this chain builds, and the two chains meet in Chapter 14, which treats the verification loop.

Evidence age on every tool

The series makes one demand of any record that supports a claim: it must say when the claim was last tested. A claim of recoverability, of coverage or of competence has a date and an expiry, and past the expiry it is no longer a claim that the organisation can make. AI Operations gives the rule its clearest form. Evidence expires by clock and by condition, and the book's default clock for a restore or failover test of a Tier 1 service is 180 days, or a substantive change to the service or its recovery path, whichever comes first (10, Nordqvist, 2026). AI Purple does the same for coverage: the coverage record states when the evidence expires, and the regression case states its cadence in the record itself, so that expiry is a property of the record and not a calendar reminder (9, Nordqvist, 2026).

The anatomy gives the rule a place in each template. The service record records, for each dependency, the test, the date, the result and the age in months of the evidence, and the date of the next review of its map. The restore-test record carries an expiry. The mandate carries review_by and expires. The observer manifest carries statement_of_independence_expires. The delegation profile carries a review interval of 90 days. The reader should look for these fields first in any artefact of the series: they show how long the record can be trusted.

Evidence age is also the answer to a question about tools of the other kinds. A third-party tool that an artefact relies on, such as a policy engine used to compute a change class, is part of what the evidence depends on. A change in its version can age the test that used it. The books mark the point in the templates (a Rego gate that the volume says was not run against an engine, for example), and this book repeats such caveats in the entries.

Tools in version control

The series asks that artefacts live in version control, as code does. The service record is kept "beside the service's infrastructure code", and the templates give a path for each artefact: services/SVC-*.yaml, delegation/DLG-*.yaml, mandates/MND-*.yaml, observers/OBS-*.yaml, restore-tests/RST-*.yaml, reviews/PIR-*.yaml and problems/PRB-*.yaml (10, Nordqvist, 2026); the volumes on purple work use scenarios/, roe/, regression/, evidence/ and coverage/ in the same way (9, Nordqvist, 2026). The practice has three consequences for the chain described above.

First, a link is a string that a program can check. A pipeline can verify that every service field names a service record that exists and that every evidence field names a restore-test record whose result and age support the claim. The series uses small checkers of this kind in several volumes, for example a closure rule that reopens an action when a risk acceptance expires and a checker for the decision-rights file (10, Nordqvist, 2026).

Second, history is cheap. A change to an owner, a ceiling or an expiry date is a commit with an author and a reason, and the AI Decision Record that approved the change is cited in the record. Lowering a delegation ceiling is immediate; raising it needs the named authority's decision, and the commit and the decision record show that it had one.

Third, a copy that is not in version control is not a source. A template in a slide deck or a wiki page can drift from the template in the repository. This book therefore quotes templates from the originating volumes and names the version it quoted, and the reader who adopts a template should take it from the repository of the volume that defines it and keep it under her own version control, with her own identifier infix.

Lifecycle of a tool

An artefact has a life that the templates make explicit, and the lifecycle of the other kinds follows the same pattern. The stages below are those that appear in the statuses, review fields and expiry fields of the templates. Chapter 3 treats the decisions between them.

  1. Proposal. A record is drafted with the status proposed, often together with an AI Decision Record that will approve it. The delegation profile, for example, begins as proposed.
  2. Approval and first use. A named authority approves the record; its status becomes active; its effective date starts. Before an agent acts on a service the delegation profile, the mandate and the observer manifest must all exist, because each is a condition of the others.
  3. Review. The record is reviewed at the interval it states: every 90 days for a delegation profile by default, at the review_by date for a mandate, at least every six months for the map in a service record, and after any incident that revealed a dependency not on the map.
  4. Suspension. The delegation profile and the mandate allow the status suspended. Lowering a ceiling is immediate, and a suspended record permits no action until a named authority reinstates it.
  5. Expiry and retirement. A record that is not renewed expires, and a record that is replaced is retired. A restore-test record whose claim is withdrawn opens a problem record, and a risk acceptance that reaches its expiry reopens the action it deferred.

The lifecycle of a third-party tool has a similar shape but is governed outside the series: a version is adopted, pinned, reviewed against its documentation and replaced. The lifecycle of a method is the least explicit: a method is adopted, rehearsed in a drill or a game day, and retired when the practice it served has changed. Nordvik Region has no autonomous production agent, so the chain of records for agents is a design for it and not a running estate; Hansa Mutual runs agents with write access to production, so its chain is in use (10, Nordqvist, 2026). Chapter 3 treats the choice of tool, the adoption and the retirement in detail.

Across the usage modes

The anatomy is the same at every mode. What differs is how much of it the series asks for. The templates of AI Operations give the full chain, with a delegation profile, a mandate manifest and an observer manifest, for an agent that acts on a service, and the delegation profile in its template is written for Mode 5 (10, Nordqvist, 2026). This chapter's own conclusion is that the more an actor can do without a person in the loop, the more of the anatomy has to be present before it acts.

Summary

The artefacts of the series share an anatomy that the reader can learn once. Each states a purpose, inputs and outputs, carries an identifier from a family, names an owner, cites the decision record that approved it, links to the records it depends on and states a review date and an expiry for its evidence. The fields differ in name between volumes, so the reader should search by identifier.

The identifier families link ten volumes into chains. The chain from the service record SVC-NR-002 through its objective record, the failed restore test RST-NR-2027-002, the change CHG-NR-2028-0007 and the risk acceptance in DRF-NR-001 shows how a record can be followed in both directions and updated when the test is repeated. The chain of AI Purple from scenario to coverage shows the same pattern in security work. Some prefixes name more than one artefact, and the reader should read the Origin row of an entry before assuming which one is meant.

Evidence age is the discipline that the anatomy exists to support. A claim without a date is not a claim the organisation can make, and a record without an owner cannot be reviewed. Keeping artefacts in version control makes the links checkable and the history cheap. Chapter 3 now treats the decision that precedes all of this: whether to adopt a tool at all, how to adopt it and when to retire it.

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. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
  5. Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
  6. Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)