Glossary

This glossary defines the vocabulary of AI Purple, from the five stages of the purple loop and the degrees of delegation to the roles, records, measures and instruments that the chapters use. Each entry gives the book's own usage in one or two sentences and names the chapter where the term is defined or most used. Where a term is used in a sense the chapters do not support, it is left out rather than defined.

How to use this glossary

Entries are grouped alphabetically under their initial letter. An identifier in code formatting, such as SCN-* for scenario records, names a pattern: the wildcard stands for the number the organisation assigns to each record, and the book's examples use NR for Nordvik Region and HM for Hansa Mutual. The identifier families are listed under their own letters, and the entry for each says what the record is and where it is kept. Identifiers that are inherited from the earlier volumes keep their meaning there and are described here only as the loop uses them.

Levels, modes, stages and classes are defined in sets, so read an entry for a level or a class together with the entries it refers to. The book sets ceilings rather than single values: where an entry states a default, a profile may set a lower level, and the lowest ceiling that applies governs. Statements about instruments are attributed to the instrument and article cited, and are architectural implications, not legal advice.

A

Across the usage modes. The subsection, normally a compact table, in which a narrative chapter says how its subject differs between Mode 0 Ambient AI and Mode 5 Autonomous production agents, because AI that supports a person's judgement and AI that acts with its own identity have different opportunities and risks (Chapter 4).

AI Act. Regulation (EU) 2024/1689. The book uses its own terms (provider, deployer, high-risk AI system, general-purpose AI model, systemic risk) and its Articles 9, 15, 50(4) and 55 where they touch the loop (1, European Union, 2024) (Chapter 21).

AI Decision Record (AIDR). The record of why a delegation or a similar decision was made, by whom, and when it is reviewed. In this book the identifiers run from AIDR-0800 to AIDR-0899: Nordvik Region AIDR-0800 to AIDR-0849, Hansa Mutual AIDR-0850 to AIDR-0899 (Chapter 6).

AI red teaming. The practice of adversarially testing AI systems, treated in AI Red Team; in this book it supplies scenarios for the AI estate and for the defender's own AI, and is run through the same loop as any other emulation (Chapter 12).

Alerted but not triaged. An outcome in which a detection fired and an alert exists, but no qualified triage decision was taken in time. An alert closed by automation or suppressed belongs here, with the reason recorded as a sub-reason (Chapter 9).

Anti-pattern. A recurring failure whose first step looks reasonable, recorded in the form of a name, a case, the mechanism, the early signs and the control. The book names eight (Chapter 26).

AP-* (anti-pattern record). A record kept in the loop repository under loop/anti-patterns/, with a stage, a status (open, mitigated or closed), a decision, signs, cause, evidence and control. Examples are AP-HM-LOOP-01 to -04 and AP-NR-LOOP-02 (Chapter 26).

Architecture Decision Record (ADR). The series' record of an architectural decision, used beside the AI Decision Record (Chapter 1).

Asserted. A coverage status for a technique for which no test by the organisation or an independent party exists, only a statement by a provider, a vendor or an owner. It does not count as covered (Chapter 17).

Atomic test. A small, single-technique test procedure mapped to a MITRE ATT&CK technique and kept in an open library. It answers one narrow question: whether this telemetry source records this behaviour and whether this detection fires (Chapter 8).

ATT&CK technique. A named adversary behaviour in MITRE ATT&CK, identified by a code such as T1098.001. The book names techniques by identifier and never by procedure (17, MITRE, n.d.) (Chapter 5).

ATT&CK, ATLAS and D3FEND. The MITRE knowledge bases the book uses as shared vocabulary: ATT&CK for adversary tactics and techniques (17, MITRE, n.d.), ATLAS for attacks on AI-enabled systems (18, MITRE, n.d.) and D3FEND for defensive countermeasures (19, MITRE, n.d.) (Chapter 5).

Authorship (kind of independence). The independence kind in which the same author, human or agent, wrote both the scenario and the detection that it tests. The control is different authors and human-authored novelty in every cycle (Chapter 15).

B

Blast radius. The extent of what an emulation step can reach if it goes wrong. The manifest keeps it a number through a rate limit per target, a per-run action budget and a list of permitted hosts (Chapter 6).

Blue team. The people and functions that defend, including detection engineering. Accountable for the change to a detection, playbook or mandate and for the age of its part of the register; it never marks a change verified without the re-test (Chapter 4).

Board page. The view of the loop that the board can decide from: four to six measures, each with its count and its age, and a decisions block. Every figure is generated from the registers and not typed (Chapter 18).

Breach-and-attack simulation (BAS). Software that runs a catalogue of emulated attack behaviours on a schedule and answers a narrow question, whether this control blocks or detects this behaviour today. It complements and does not replace the other forms of testing (Chapter 2).

BTP-* (board and team page). The record that carried the baseline figures from AI Blue for Hansa Mutual: BTP-HM-2027-Q3 reports 25 of 34 priority techniques verified and a finding-to-control median of 19 days (Chapter 2).

C

Canary. A decoy credential, record or host entry that no legitimate process touches. In emulation a hit by a step meant to reach it is expected and tagged; any other touch is treated by the white team as a signal of a real intruder (Chapter 6).

Catalogue binding. The part of a mandate manifest that states which scenarios an agent may run, by signed hash, and the highest safety class (Chapter 14).

CHG-* (change record). The P4 Improve record that carries a finding to a change, or to an explicit decision that no change is justified (Chapter 10).

Closed and verified. The one finding state that counts as closed: the re-test, including its variant, passed, the evidence manifest is attached, a named person has signed and the closure carries a date (Chapter 4).

Closure owner. The one named person per class of finding who signs a finding closed on the evidence. The closure owner never closes on attestation, and a tool never closes a finding at any level (Chapter 4).

Closure rule. A finding is closed only when the re-test and its variant pass, the evidence is attached, a named person signs, and the closure carries an age (a date and the conditions under which it lapses). A Level 3 agent may run the re-test and assemble the evidence and never closes. The rule comes from AI Red Team and AI Blue; the book adds the variant, the signature and the age, and five states so that the rule can be audited (Chapters 4 and 11).

CMP-* (competence record). The record of a person's assessed competence against the loop's framework, with the exercise used and the evidence. CMP-NR-21 is the coordinator's record (Chapter 24).

CNP-* (consent and notice protocol). The record of how consent and notice are obtained for a test that crosses a provider boundary. CNP-NR-2028-01 and CNP-HM-2028-01 are adopted by AIDR-0829 and AIDR-0881 (Chapter 22).

Competence framework (LOOP-CF). Hansa Mutual's framework of 18 competences in six areas that span both sides of the loop. LOOP-CF-NR is the Region's subset (Chapter 24).

Context variant. A variant that changes where the technique happens, for example a server instead of a workstation, a different business unit or out of office hours (Chapter 11).

Continuous emulation. Adversary emulation run as a pipeline without a campaign around it, triggered by change, by schedule and by intelligence. It is not a threat-led penetration test, and the manifest says so (Chapter 8).

Control team. The term the DORA technical standard and the current ECB text use for the group in the tested entity that manages a test. The book keeps white team for the control group of an exercise and says control team where it quotes the regulation (Chapter 2).

COV-* (coverage record). The derived record that states, per technique and environment, what was tested, when, with what outcome, and when the evidence expires. Identifiers are COV-NR-* and COV-HM-* (Chapter 17).

Coverage statuses. The six values of the status rule: verified, expired, implemented-unverified, failed, asserted and untested. Only verified counts as covered; the rest are reported with reasons (Chapter 17).

Covered. The condition in which a person can show, from records, that a specified technique was exercised in a specified environment in a window of time, that the defence produced a specified result at a specified layer and that the evidence has not expired (Chapter 17).

Cyber Resilience Act (CRA). Regulation (EU) 2024/2847 on products with digital elements. It reaches the loop when an exercise finds a vulnerability in someone else's product and when the product is the organisation's own (5, European Union, 2024) (Chapter 21).

D

Data (kind of independence). The independence kind in which tester and tested share training data, a retrieval corpus or an intelligence feed. The control is a held-out set built from sources the detection side does not read (Chapter 15).

DCY-* (decay estimate). A record that estimates how far detections have decayed, classifying each as current, at-risk or expired. DCY-HM-2028-01 covers three Hansa Mutual detections (Chapter 3).

Decision rights. The assignment of the loop's ten decisions, D1 to D10, to named holders and deputies with a time, evidence and record (Chapter 20).

Degrees of delegation. The series' autonomy levels (Level 0 Advisory to Level 4 Autonomous), applied per stage and per action class. A person is named for every row, because accountability does not pass to a tool (Chapter 4).

Delegation profile (DLG-*). The record of who delegated what to which system, at which level, with the independence declaration for every row where AI sits on both sides of a check. Examples are DLG-NR-LOOP-01 and DLG-HM-LOOP-01 (Chapter 4).

DLG-HM-EMU-01 (function-level delegation profile). Hansa Mutual's profile of the eight functions and seven mandates of the loop's agents, which coexists with the stage-level profile DLG-HM-LOOP-01 (Chapter 14).

Detected. An outcome in which a detection fired, an alert reached a queue, a qualified triage decision was taken and the playbook action followed, all within the expected bound (Chapter 9).

Detection debt. The entries in the debt register of AI Blue (no owner, no passing test, stale data source, overdue review), reported with the age of the oldest (Chapter 18).

Detection decay. The loss of a detection's value because the world it reads changes, for example a schema, a field name, a collector or an exclusion, while its logic does not (Chapter 3).

Detection record (DET-*). The record of a detection with logic, data sources, mapping, tests, owner and review date, as defined in AI Blue. Identifiers are DET-NR-* and DET-HM-*; DET-HM-0561 watches the claims-triage agent (Chapter 12).

Digital Omnibus on AI. Regulation (EU) 2026/1744, which moved the application dates of the AI Act's high-risk requirements to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems (9, European Union, 2026) (Chapter 21).

DORA. Regulation (EU) 2022/2554 on digital operational resilience. The book uses Article 5 (management body), Articles 24 and 25 (testing programme), Article 26 (threat-led penetration testing), Article 27 (testers) and Article 30(3)(d) (provider participation) (2, European Union, 2022) (Chapter 21).

DRF-* (decision-rights file). The versioned record that assigns D1 to D10 to named holders, changed by pull request and read by the policy decision point for the parts that concern a machine. Examples are DRF-NR-LOOP-01 and DRF-HM-LOOP-01 (Chapter 20).

Dry run. A recorded run of a scenario, on the range or the mirror, that must precede a scenario's entry into production or its promotion to a higher safety class (Chapter 6).

E

Emulation agent. An agent that plans, executes a catalogued scenario or reports. It does not attack in any sense that implies intent (Chapter 14).

Emulation plan (EMU-*). The P2 Emulate record that names the scenarios, their sequence, the target scope, the window and the abort conditions, together with the tagged log of what was done (Chapter 7).

EIN-* (exercise-information notice). The notice sent to employee representatives before an exercise that involves staff, ten working days before the window in the Region's case. EIN-NR-2027-002 precedes the deepfake test (Chapter 23).

Evidence expiry. The rule that a pass is evidence only for a limited time. An expiry has a clock (days after the last full pass) and a condition (a change to something the evidence depends on), and the earlier ends the evidence (Chapter 11).

Evidence manifest (EVD-*). The signed and versioned P5 Verify record that holds the re-test result, the telemetry references, the model and mandate versions and the reviewer's confirmation (Chapter 11).

Exercise controller. A named member of the white team with authority to halt, who holds the schedule, the scope and the stop for a single window. It is the book's term for a responsibility that the verified sources distribute differently (Chapter 19).

Exercise-information notice. See EIN-*.

Expected. One of the three labels for any statement about the future: a development that follows from observable trends and is likely, but is not yet observed (Chapter 25).

Expired. A coverage status for a passing result whose clock has run out or whose condition has changed. It is reported as not tested, with the date of the last pass (Chapter 17).

F

Failed. A coverage status in which the last result, or the last re-test, was a failure. A risk-accepted finding also shows as failed, with the acceptance reference (Chapter 17).

FC-1 Aggregate. The handling class for counts, ages, closure rates and trends with no asset named. Its audience is the board, the audit committee and supervisors (Chapter 16).

FC-2 Redacted. The handling class for technique, severity, owner, status and control family without asset names, accounts, addresses or reproduction steps (Chapter 16).

FC-3 Restricted. The handling class for asset-specific detail of an open finding, for the finding owner, the remediation team, the red team and the white team (Chapter 16).

FC-4 Exploitable. The handling class for anything that would shorten an adversary's work, such as reproduction detail, secrets met in an exercise or the list of untested techniques. It is open to a named handful of people with a second person for any export (Chapter 16).

Finding (FND-*). The P3 Observe record raised where the outcome falls short of the expectation. It is the first record that belongs to the blue team's world as well as the red team's (Chapter 9).

FND-HM-2028-012. Hansa Mutual's finding that the simulation tool's collector stored the exercise service account's token in a local log, opened at FC-4 on 2028-03-16 and routed to the vendor under the disclosure practice of Chapter 22.

Finding half-life. The book's own measure: the number of days after which half of the findings opened in a quarter have a passing re-test. It counts only verified closure (Chapter 10).

Finding states. The five states of the closure rule: open; implemented, unverified; re-test failed; closed and verified; and risk accepted (Chapter 4).

Finding-to-control time. The time from a finding being opened to a control or detection being in place. Hansa Mutual's median is 19 days at BTP-HM-2027-Q3 (Chapter 10).

G

GDPR. Regulation (EU) 2016/679. The book uses its minimisation principle (Article 5(1)(c)), its lawful basis (Article 6(1)(e)) and the impact assessment (Article 35) for exercise data (7, European Union, 2016) (Chapter 21).

Goodhart's law. The observation that a measure which becomes a target ceases to be a good measure; Chapter 18 explains it once, and the other chapters refer to it (Chapter 18).

Generalisation gap. The difference between the pass rate on known-form scenarios and the pass rate on held-out variants. The book calls it the pipeline's most honest number (Chapter 8).

Ground truth. The record of what the emulation did, written by the emulation side at the time and not reconstructed afterwards, with the step, technique, times, host, account and effect (Chapter 9).

H

Handling class. One of the four classes (FC-1 to FC-4) assigned to a finding by what its content would let a reader do, not by its severity. It is set at creation by the author with the white team's review (Chapter 16).

Human-authored novelty. The requirement that a defined share of the scenario library and of every cycle's held-out set is written by people and not by the agents of the loop; the held-out set serves it (Chapter 15).

Held-out scenario. A scenario written by a person, kept where the detection side and its agents cannot read it, and run against the detections only after they have been built and changed. It is the loop's equivalent of a held-out set (Chapter 15).

Held-out variant. A variant defined by who wrote it: someone who did not write the fix, not visible to the fix's author before the run (Chapter 11).

HLD-* (hold list). The list populated by the control team lead alone that removes systems from the pipeline's targets while a TLPT is active. HLD-HM-TLPT-01 is created by AIDR-0877 (Chapter 21).

HZN-* (horizon register). The register of trends for the loop, each with a label, a stage, evidence, a trigger, a posture and an owner. HZN-NR-PL-01 and HZN-HM-PL-01 are the two organisations' registers (Chapter 25).

I

Implemented, unverified. A finding state in which a change is merged or deployed but the re-test has not passed. The finding is reported as open (Chapter 4).

Incentive rule. The rule between roles that the party accountable for the quality of a finding is not the party that closes it, and that nobody marks their own work (Chapters 4 and 19).

Independence principle. A check is evidence only if the side that performs it can fail in ways the side being checked does not share. Agreement between two things is informative only if they could have disagreed. A loop declares independence as five kinds of separation (model, data, authorship, vendor, time), one rule between roles (the incentive rule) and three proofs (held-out scenarios, seeded gaps and errors, reproduction by a person) (Chapters 4 and 15).

Independence statement (IND-*). A one-page statement, produced quarterly and after any change of model, vendor or mandate, of the independence of each coverage claim that matters, readable without the agents. IND-HM-2028-Q1 is Hansa Mutual's (Chapter 15).

Injected test. A seeded incident, from an emulation scenario, that the customer causes to arrive in a provider's pipeline without telling the provider which cases are tests or when (Chapter 13).

K

Kinds of independence. The five kinds separated in Chapter 15: model, data, authorship, vendor and time. Each has its own shared dependency, hidden failure and control (Chapter 15).

L

Level 0 Advisory. The AI suggests, and a person decides and acts (Chapter 4).

Level 1 Assisted. The AI drafts, and a person reviews and executes (Chapter 4).

Level 2 Supervised. The AI executes after explicit approval of each action (Chapter 4).

Level 3 Bounded. The AI executes pre-approved, reversible actions inside a codified playbook, enforced by a policy decision point outside the model, with a person informed and able to stop it. At P5 Verify it may run a re-test and record a passing result; it never closes a finding (Chapter 4).

Level 4 Autonomous. The AI selects and executes without per-action approval. It is never used for an emulation action that is irreversible, that leaves the signed scope, that touches personal data beyond what the exercise is authorised to touch, or that targets a named person (Chapter 4).

LOOP-* (loop charter). The signed charter of a loop, for example LOOP-NR-2028-01, which names the stages that cross a contract boundary and gives the loop a clock and a named owner (Chapter 4).

LP-* (learning path). The development record of an apprenticeship or competence route, owned by the apprentice and mentor. LP-HM-RED-2028-01 is Hansa Mutual's red apprenticeship (Chapter 24).

LPG-* (loop page). The quarterly page of the loop's measures. LPG-HM-2028-Q1 and LPG-NR-2028-Q1 compare the first quarter of 2028 with the baseline (Chapter 18).

Lowest ceiling governs. The rule that where an action has several properties or several documents set different levels, the strictest applies. An action that no document lists is undelegated and waits for a person (Chapter 4).

M

Mandate manifest (MND-*). The record of what a given agent may do at all, with which identity and at which level, whatever exercise it is used in. For emulation and loop agents the identifiers are MND-NR-EMU-* and MND-HM-EMU-* (Chapter 14).

Merely logged. See Missed. Chapter 17 reports it as logged but not detected (Chapters 9 and 17).

Missed. An outcome in which the telemetry contains the event but no detection fired. A detection can be written for it without new collection; Chapter 17 reports it as logged but not detected (Chapter 9).

Mode 0 Ambient AI. AI embedded in a vendor's product, such as a simulation tool, an endpoint product or a provider's alert closure, so that autonomy may exist that nobody decided (Chapter 4).

Mode 1 Conversational assistants. A practitioner drafts a scenario or summary in a conversational tool. The usual ceiling is Level 0 Advisory (Chapter 4).

Mode 2 Embedded workplace assistants. Drafting inside the ticketing or document tools. The usual ceiling is Level 1 Assisted (Chapter 4).

Mode 3 Agentic work tools. A practitioner's agent assembles a plan or timeline with the practitioner's identity. The usual ceiling is Level 1 to Level 2 (Chapter 4).

Mode 4 Built AI applications. AI applications the organisation builds, such as a correlator or scenario curator with read-only access (Chapter 4).

Mode 5 Autonomous production agents. Agents that act with an identity and permissions of their own, such as the emulation runner or re-test runner, and so become privileged machine insiders (Chapter 14).

Model (kind of independence). The independence kind in which tester and tested, or drafter and critic, share a model family or lineage. The control is a critique agent on a different family, used for questions and not verdicts (Chapter 15).

MS-2 (managed-service annex). The annex of Nordvik Region's framework agreement NR-2025-044 under which the managed provider's AI closes low-severity alerts out of hours and under which injected tests run (Chapter 13).

MSC-LOOP-01 (measure catalogue). The catalogue of the loop's measures that the loop pages reference (Chapter 18).

N

Never list. The part of a mandate manifest that carries the actions by which an agent could change its own governance, such as editing its mandate or the rules of engagement, widening its scope, writing to its own action log, using a real person's credentials or acting at Level 4 (Chapter 14).

NIS 2. Directive (EU) 2022/2555. The book uses Article 20 (management-body approval and oversight), Article 21 (risk-management measures, including the assessment of their effectiveness) and Article 12(1) (coordinated disclosure) (3, European Union, 2022) (Chapter 21).

No telemetry. An outcome in which the event left no record in the collection pipeline, whether not generated, not forwarded, dropped or unparsed, or retained too briefly (Chapter 9).

Not tested. An outcome and a coverage value for a step or technique that was not run, ran outside the window, or whose result could not be joined. Untested is not covered (Chapter 9).

O

OBL-* (obligation register). The register that maps each legal obligation to a stage, a control, evidence and an owner. OBL-NR-2028-01 and OBL-HM-2028-01 are reviewed six-monthly (Chapter 21).

Observable. One of the three labels for any statement about the future: something already seen in sources the book has read (Chapter 25).

Open. A finding state in which the finding is confirmed, has an owner and a severity and awaits a change or a decision (Chapter 4).

Outcome taxonomy. The seven mutually exclusive outcomes of an emulated step, ordered by layer: prevented, detected, alerted but not triaged, triaged but not acted on, missed, no telemetry and not tested (Chapter 9).

Overfitting. The failure in which a detection drafted from the exact telemetry of an exercise matches that exercise and not the technique, so that the exact re-test passes trivially (Chapter 10).

P

P1 Target. The stage that chooses what the loop will test, from intelligence, the threat register, risk assessment and incidents. It produces a scenario record (Chapter 5).

P2 Emulate. The stage that executes the scenario inside the signed scope under a stop path held outside the emulating system. It produces an emulation plan and a tagged log (Chapters 6, 7 and 8).

P3 Observe. The stage that compares what happened with what was expected, written before the run. It produces a finding and a purple session record (Chapter 9).

P4 Improve. The stage that turns a finding into the right change, or into an explicit decision that no change is justified (Chapter 10).

P5 Verify. The stage that proves the change by re-running the scenario with at least one variant. It produces a regression case and an evidence manifest (Chapter 11).

Path variant. A variant that changes how a technique is carried out while the ATT&CK technique stays the same (Chapter 11).

PLAN-* (two-year plan). The plan record of a conclusion chapter: PLAN-NR-LOOP-2028 (AIDR-0849) and PLAN-HM-LOOP-2028 (AIDR-0899), each with six measures, three decisions for the management body and a half-yearly review (Chapter 28).

PBK-* (playbook manifest). The record of a playbook, defined in AI Blue; in the loop it is one of the artefacts a P4 change may alter (Chapter 4).

PIR-* (post-incident review). The review of a real incident, defined in AI Blue. In the loop it asks whether the technique was on the priority list and whether it had a verified detection (Chapter 18).

Policy decision point. The component outside the emulating system that evaluates every action against the signed manifest. It fails closed: if it cannot read or verify the manifest, every action is refused (Chapter 6).

PRI-* (priority list). The list of priority techniques for a service, built in P1 Target. PRI-NR-2028-01 has nine techniques for the benefits-triage service (Chapter 5).

PRP-* (purple session record). The record of the meeting in which red and blue read a result together, with every classification agreed and disagreements recorded with both readings (Chapter 9).

PSC-* (purple session charter). The charter, written before a session and not in it, that sets the ground rules for a blameless purple session. PSC-NR-2028-01 is the Region's (Chapter 23).

Purple loop. The joint loop between the red team and the blue team, in five stages and defined by its records. It is a loop, not a team and not an event (Chapter 4).

Purple session. The meeting, recorded as PRP-*, in which red and blue read the result together. A session with no re-test is a debrief, and Chapter 26 calls it purple theatre (Chapter 9).

Purple team. In lower case, the joint loop between red and blue. It is never a role and never a third team that sits beside them; the role is the coordinator (Chapter 4).

Purple-team coordinator. The role that runs the loop: schedules, makes sure findings reach their owners in usable form and tracks the age of open findings. It holds the register, not the findings (Chapter 4).

R

Range. An isolated environment, separate from production, on which higher-risk scenarios and dry runs are run (Chapter 6).

Rate and shape variant. A variant that changes volume and timing: slower, spread over more sources or interleaved with benign activity (Chapter 11).

Ratchet. The property of a regression suite that a case, once added, is not removed because it is inconvenient. It is retired only by a recorded decision when its control is retired (Chapter 11).

Re-test failed. A finding state in which the re-test did not pass and the finding returns to P4 with the failed result attached (Chapter 4).

Red team. The people, internal or contracted, who emulate the adversary inside the signed scope. Accountable for the quality of findings; never closes its own findings or tunes the defender's rules (Chapter 4).

Regression case (REG-*). The P5 Verify record that turns a closed finding into a repeatable test with variants and a cadence. It returns to the scenario library and is re-run when the estate changes or the evidence expires (Chapter 11).

Reproduction (proof of independence). The requirement that a person can reproduce the key result by another route from the evidence manifest alone (Chapters 4 and 15).

Risk accepted. A finding state in which a named authority has decided not to change anything. The finding is not closed; it is reported separately with the authority, the reason and an expiry (Chapter 20).

ROLE-* (role charter). The charter of a role in the loop, such as the purple-team coordinator or the exercise controller (Chapter 19).

Rules of engagement (RoE-*). The signed, versioned manifest that says what may be done to which systems, when, with whose consent and under what stop conditions. It belongs to the exercise or programme (Chapter 6).

S

S1 (safety class). A scenario that is benign, reversible and tagged, with proof of technique only. It may run in production inside the signed scope, with a ceiling of Level 3 Bounded for catalogued scenarios (Chapter 6).

S2 (safety class). A scenario that is reversible with bounded side effects, such as lockout-safe and rate-limited. It may run in production with white-team approval per run, at a ceiling of Level 2 Supervised (Chapter 6).

S3 (safety class). A scenario that needs realistic state or may disturb service. It never runs in production and is run on the range or pre-production, at a ceiling of Level 2 Supervised (Chapter 6).

S4 (safety class). A scenario with impact or irreversible effect, or one that involves staff or third parties. It runs only on the range, with AI limited to planning (Level 0 Advisory), a named operator and white-team approval per step (Chapter 6).

Safety class. An attribute of the scenario record that states what the scenario can do to the target and how it is undone. The manifest's rules are written per class (Chapter 6).

SCN-* (scenario record). The P1 Target record: the technique set and its source, the expected outcome per layer, a safety class and an owner. Identifiers are SCN-NR-* and SCN-HM-* (Chapter 5).

SCR-* (scorecard). A joint scorecard for the red team and detection engineering. SCR-HM-2028-Q1 was adopted by AIDR-0882 (Chapter 23).

SCT-* (safety class table). The data file that holds a set of safety classes, read by the policy decision point. SCT-HM-2027-01 classes the 86 Hansa Mutual scenarios (Chapter 6).

Seeded error. A known mistake introduced on purpose into a draft or a classification, to show that the reviewer or the check can fail and does catch it (Chapter 15).

Seeded gap. A known weakness introduced on purpose by a person, under the signed rules of engagement and a change record, in a place where it can be undone. It tests whether the loop finds and closes a hole that was made (Chapter 15).

Seeded incident. A known incident, drawn from an emulation scenario, placed in a defender's pipeline to test whether the defender's AI finds it. Pairs of seed and benign twin test both detection and restraint (Chapter 13).

Separation list. The part of a mandate manifest that states what an agent may never read or write, for example that the runner never reads detection content and the drafter never reads held-out scenarios (Chapter 14).

SGP-* (seeded-gap record). The record of a seeded gap. SGP-HM-2028-003 is Hansa Mutual's seed in the pre-production mirror (Chapter 15).

SHP-* (sector-sharing protocol). The protocol that governs what the organisation shares with a sector group and how. SHP-HM-2028-01 is adopted by AIDR-0879 (Chapter 22).

Speculation. One of the three labels for any statement about the future: a possibility without current support, held back until evidence says otherwise (Chapter 25).

Stop path. The route by which an exercise or agent is halted, which lies outside the system it stops and is held by named people who need not justify using it. A stop path decays unless it is drilled (Chapter 6).

Sources. The closing section of every narrative chapter that lists the sources cited in it (Chapter 1).

T

Tagged. A property of every emulation action: it carries a marker, such as a reserved prefix, that links it to the exercise and lets the white team tell emulation from a real intrusion (Chapter 6).

Tag ledger. The record of markers against which the duty incident commander or white-team lead matches a suspicious event when deciding whether it is real (Chapter 20).

Test-to-change ratio. For a technique, the number of production changes that touch what it depends on between two passing tests. A ratio of one means every change was followed by a verification (Chapter 3).

TFR-* (testing-forms register). The register that classifies the testing a team already does. TFR-NR-01 and TFR-HM-01 reconstruct the two organisations' baseline (Chapter 2).

THR-* (threat-register entry). An entry in the organisation's threat register, one of the sources of a scenario. Examples are THR-NR-02 and THR-HM-02 (Chapter 5).

TIBER-EU. The European Central Bank's framework for threat intelligence-based ethical red-teaming, which names the blue team, the threat intelligence provider, the red-team testers, the control team and the authority's team (20, ECB, 2025) (Chapter 21).

Time (kind of independence). The independence kind in which a re-test is run at once, with the fixer's data, or on evidence that has not expired. The control is a re-test after a delay and after changes, with an expiry (Chapter 15).

TLPT (threat-led penetration testing). The advanced testing of DORA Article 26, performed on live production systems at least every three years for entities the authorities identify. Delegated Regulation (EU) 2025/1190 specifies the method (2, European Union, 2022) (8, European Commission, 2025) (Chapter 21).

Triaged but not acted on. An outcome in which the alert was triaged correctly but the action the playbook expects was not taken, or not in time. It often exposes unclear decision rights (Chapter 9).

Trusted agent. A named person on the defended side who knows of the exercise, so that real incidents are not mistaken for it and the stop can be reached. The term is the book's own; at Nordvik the managed provider's shift lead holds it out of hours (Chapter 7).

TTX-* (tabletop record). The record of a tabletop exercise that tests the decision-rights file before a spring run (Chapter 20).

U

Untested. A coverage status in which nothing is recorded. It does not count as covered (Chapter 17).

V

Variant. A scenario that changes one thing and keeps the technique. The book uses path, context, rate and shape, and held-out variants (Chapter 11).

Vendor (kind of independence). The independence kind in which tester and tested share a vendor, platform or gateway tenant, including provider AI embedded in a service (Chapter 15).

Verified. A coverage status for a passing result, with its variants, whose evidence has not expired and whose conditions have not changed. It is the only status that counts as covered (Chapter 17).

Verified share within expiry. The measure of priority techniques with a passing result younger than their expiry, over the priority list, with reasons for the rest (Chapter 18).

W

White team. The control group that governs an exercise: it authorises, controls the window and holds the stop with others. Its independence is by position, outside both red and blue (Chapter 4).

Window. The period, expressed as timestamps with offsets, in which an exercise or scenario may run. An action after the window is refused (Chapter 6).

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act). (1, European Union, 2024)
2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 (DORA). (2, European Union, 2022)
3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2). (3, European Union, 2022)
4. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 (Cyber Resilience Act). (5, European Union, 2024)
5. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (GDPR). (7, European Union, 2016)
6. MITRE Corporation. MITRE ATT&CK. (17, MITRE, n.d.)
7. MITRE Corporation. MITRE ATLAS. (18, MITRE, n.d.)
8. MITRE Corporation. MITRE D3FEND. (19, MITRE, n.d.)
9. European Central Bank. TIBER-EU framework. (20, ECB, 2025)
10. European Commission. Commission Delegated Regulation (EU) 2025/1190. (8, European Commission, 2025)
11. European Parliament and Council of the European Union. Regulation (EU) 2026/1744 (Digital Omnibus on AI). (9, European Union, 2026)