Appendix B: Templates and Tools

This appendix is the directory of reusable templates and tools for the purple loop, in the repository that accompanies AI Purple. Each artefact is designed to be copied into an organisation's own repositories, adapted to its contracts, works agreements and national law, and maintained under version control. The chapter that introduces each artefact is listed so that readers can find the rationale behind the design. None of the templates is legal advice, and none serves attack tooling: they describe scenarios, authority, records and evidence, not exploits.

The governance templates of AI Governance, Appendix C, the platform and security templates of AI Platform and Security, Appendix B, the detection, guardrail and chaos-experiment artefacts of AI Red Team, Appendix A, the role, control and mandate artefacts of The Transformed Security Architect and the detection, case, playbook and mandate artefacts of AI Blue, Appendix A, remain the reference for those subjects and are not repeated here.

Templates by activity

No. Activity Artefact Where to find it Introduced in
B.1 Definition Purple loop inventory Chapter 4 Chapter 4
B.2 Definition Loop charter and delegation profile (DLG-*) Chapter 4 Chapter 4
B.3 Targeting Scenario template (SCN-*) Chapter 5 Chapter 5
B.4 Authorisation Rules-of-engagement manifest (RoE-*) Chapter 6 Chapter 6
B.5 Emulation Emulation plan (EMU-*) Chapter 7 Chapter 7
B.6 Pipeline Continuous emulation schedule and variation policy Chapter 8 Chapter 8
B.7 Observation Purple session agenda and record (PRP-*) Chapter 9 Chapter 9
B.8 Observation Outcome table and finding record (FND-*) Chapter 9 Chapter 9
B.9 Improvement Change record (CHG-*) and change-routing table Chapter 10 Chapter 10
B.10 Verification Regression case (REG-*) Chapter 11 Chapter 11
B.11 Verification Evidence manifest (EVD-*) Chapter 11 Chapter 11
B.12 AI systems Detection checklist for AI systems and agents Chapter 12 Chapter 12
B.13 Defenders' AI Seeded-incident test plan Chapter 13 Chapter 13
B.14 Agents Mandate manifest for an emulation or loop agent (MND-*-EMU-*) Chapter 14 Chapter 14
B.15 Independence Independence checklist Chapter 15 Chapter 15
B.16 Security Tier-0 checklist for the findings register and emulation agents Chapter 16 Chapter 16
B.17 Coverage Coverage-record template (COV-*) Chapter 17 Chapter 17
B.18 Measurement Board page for the loop Chapter 18 Chapter 18
B.19 Roles Role charter for loop roles (ROLE-*) Chapter 19 Chapter 19
B.20 Decisions Exercise decision-rights table Chapter 20 Chapter 20
B.21 Regulation Testing authorisation and legal-basis checklist Chapter 21 Chapter 21
B.22 Boundaries Provider testing annex Chapter 22 Chapter 22
B.23 People Blameless purple session charter Chapter 23 Chapter 23
B.24 People Competence record (CMP-*) Chapter 24 Chapter 24
B.25 Outlook Horizon register Chapter 25 Chapter 25
B.26 Review Anti-pattern checklist Chapter 26 Chapter 26
B.27 Planning Two-year plan Chapter 28 Chapter 28

Template descriptions

B.1 Purple loop inventory

  • Purpose: Maps who performs each of P1 to P5 today, red, blue or contracted, with which tools, and which parts already sit in automation.
  • When to use: At the start of the work, and each year.
  • Inputs: Job descriptions, tool inventory, provider contracts, last exercise reports.
  • Outputs: loop/stage-map.yaml, the starting point for a delegation profile.
  • Chapter: Chapter 4

B.2 Loop charter and delegation profile (DLG-*)

  • Purpose: States the mandate of the loop, who may authorise and stop it, and the degree of delegation per stage and action class.
  • When to use: When the loop is set up, and at every review.
  • Inputs: Stage map, risk appetite, works agreements.
  • Outputs: DLG-* and an AIDR.
  • Chapter: Chapter 4

B.3 Scenario template (SCN-*)

  • Purpose: Records a scenario with technique set, source, expected outcome per layer, safety class and owner.
  • When to use: For every scenario before it is first run.
  • Inputs: Intelligence, threat-register entry, risk assessment.
  • Outputs: scenarios/SCN-*.yaml.
  • Chapter: Chapter 5

B.4 Rules-of-engagement manifest (RoE-*)

  • Purpose: Binds authority, scope and exclusions, window, blast radius, data handling, third-party consent and the stop path, enforced by a policy decision point outside the emulating agent.
  • When to use: Before any emulation, and at every change of scope.
  • Inputs: Scenario set, asset inventory, provider consents, works-council agreement.
  • Outputs: roe/RoE-*.yaml and a signed approval.
  • Chapter: Chapter 6

B.5 Emulation plan (EMU-*)

  • Purpose: Sequences scenarios into a campaign with target scope, window and abort conditions.
  • When to use: For every campaign or exercise.
  • Inputs: Scenario records, RoE manifest, roles of the white team.
  • Outputs: emu/EMU-*.yaml.
  • Chapter: Chapter 7

B.6 Continuous emulation schedule and variation policy

  • Purpose: Sets what runs, where, when and with what variation, so that the pipeline neither overfits nor runs unattended into change windows.
  • When to use: When continuous emulation is introduced, and quarterly.
  • Inputs: Scenario library, change calendar, RoE manifest.
  • Outputs: pipeline/schedule.yaml, variation rules.
  • Chapter: Chapter 8

B.7 Purple session agenda and record (PRP-*)

  • Purpose: Agenda for a session in which red and blue read the result together, expectation first, with a record of outcomes, decisions and findings raised.
  • When to use: For every purple session.
  • Inputs: Emulation plan, ground-truth log, telemetry references.
  • Outputs: prp/PRP-*.md.
  • Chapter: Chapter 9

B.8 Outcome table and finding record (FND-*)

  • Purpose: Classifies each scenario outcome (prevented, detected, alerted but not triaged, triaged but not acted on, missed, no telemetry, not tested) and raises a finding.
  • When to use: After every emulation.
  • Inputs: Expected outcomes, tagged events, detections and alerts.
  • Outputs: findings/FND-*.yaml.
  • Chapter: Chapter 9

B.9 Change-routing table

  • Purpose: Routes a finding to a detection, control, playbook or mandate change, or to a recorded decision that none is justified, with owner, due date and review, in a change record (CHG-*) of its own.
  • When to use: When a finding is accepted.
  • Inputs: Finding record, owners, backlog.
  • Outputs: changes/routing.yaml and changes/CHG-*.yaml.
  • Chapter: Chapter 10

B.10 Regression case (REG-*)

  • Purpose: Keeps a finding that a person has closed as a repeatable test with variants and cadence.
  • When to use: At closure of every finding.
  • Inputs: Finding, scenario, variants.
  • Outputs: regression/REG-*.yaml.
  • Chapter: Chapter 11

B.11 Evidence manifest (EVD-*)

  • Purpose: Signs and versions the result of a re-test with telemetry references and reviewer; the closure itself is a named person's signature on the finding, not the runner's.
  • When to use: At every re-test.
  • Inputs: Re-test run, telemetry, reviewer identity.
  • Outputs: evidence/EVD-*.yaml.
  • Chapter: Chapter 11

B.12 Detection checklist for AI systems and agents

  • Purpose: Lists the telemetry and detections needed for tool misuse, anomalous retrieval and permission-ceiling breaches.
  • When to use: Before an AI system goes into production.
  • Inputs: AI gateway and agent-runtime logs, ATLAS technique list.
  • Outputs: Checklist and detection records.
  • Chapter: Chapter 12

B.13 Seeded-incident test plan

  • Purpose: Plans seeded incidents and injected tests for SOC agents, playbooks and a provider's AI, with the closure rule for agent findings.
  • When to use: Each quarter, and when a mandate changes.
  • Inputs: Mandates, provider annex, scenario library.
  • Outputs: tests/seeded-incidents.yaml.
  • Chapter: Chapter 13

B.14 Mandate manifest for an emulation or loop agent (MND-*-EMU-*)

  • Purpose: Bounds tasks, tools, data, identity, levels per stage and action class, budget, expiry and the accountable person.
  • When to use: Before an agent is given a loop function.
  • Inputs: Delegation profile, RoE manifest, containment profile.
  • Outputs: mandates/MND-*-EMU-*.yaml.
  • Chapter: Chapter 14

B.15 Independence checklist

  • Purpose: Tests the three layers of independence: whether tester, tested and checker share model, data, authorship, vendor or time (a kind not shown is treated as shared), whether the incentive rule holds between roles, and which of the three proofs compensate (held-out scenarios, seeded gaps and errors, reproduction by a person).
  • When to use: Before a coverage claim or a closure is accepted, and at every audit.
  • Inputs: Model inventory, scenario sets, evaluation results.
  • Outputs: Completed checklist and an AIDR where independence is weak.
  • Chapter: Chapter 15

B.16 Tier-0 checklist for the findings register and emulation agents

  • Purpose: Controls for classification, access, segregation, supply chain of scenarios and tools, and handling of findings in hosted AI tools.
  • When to use: Before the findings register or an emulation agent goes live.
  • Inputs: Asset classification, access model, supply-chain inventory.
  • Outputs: Checklist and evidence.
  • Chapter: Chapter 16

B.17 Coverage-record template (COV-*)

  • Purpose: States per technique and environment what was tested, when, how, with what outcome and when the evidence expires.
  • When to use: For every technique in the priority list.
  • Inputs: Evidence manifests, scenario records, environment inventory.
  • Outputs: coverage/COV-*.yaml.
  • Chapter: Chapter 17

B.18 Board page for the loop

  • Purpose: Presents cycle time, finding half-life, re-test pass rate and the share of priority techniques verified within expiry.
  • When to use: Each quarter.
  • Inputs: Findings register, coverage records, regression results.
  • Outputs: One-page report.
  • Chapter: Chapter 18

B.19 Role charter for loop roles (ROLE-*)

  • Purpose: Defines purple coordinator, emulation engineer, detection engineer, exercise controller and white-team roles and the independence between them.
  • When to use: When roles are set up or sourced.
  • Inputs: Operating model, delegation profile.
  • Outputs: roles/ROLE-*.yaml.
  • Chapter: Chapter 19

B.20 Exercise decision-rights table

  • Purpose: Names who may authorise, change scope, stop, accept a residual finding and declare a technique covered, and how a real incident during an exercise is handled.
  • When to use: Before the first exercise, and at every review.
  • Inputs: Decision tiers, RoE manifest, escalation paths.
  • Outputs: Decision-rights table and a tabletop record (TTX-*).
  • Chapter: Chapter 20
  • Purpose: Checks DORA, TIBER-EU, NIS 2, AI Act, GDPR, criminal-law and employee-representative requirements before an exercise.
  • When to use: Before every exercise, with legal counsel.
  • Inputs: RoE manifest, data-protection impact assessment, works agreements.
  • Outputs: Completed checklist; not legal advice.
  • Chapter: Chapter 21

B.22 Provider testing annex

  • Purpose: Contract annex giving the right to test through a managed provider or cloud, with consent, notice, injected tests and evidence sharing.
  • When to use: At procurement and renewal.
  • Inputs: Framework agreement, shared-responsibility model.
  • Outputs: Annex text.
  • Chapter: Chapter 22

B.23 Blameless purple session charter

  • Purpose: Sets the ground rules that keep a session blameless and the incentives of red and blue aligned to yield, not to winning.
  • When to use: Before the first session, and at review.
  • Inputs: Incentive schemes, works agreements.
  • Outputs: One-page charter.
  • Chapter: Chapter 23

B.24 Competence record (CMP-*)

  • Purpose: Records competences for scenario design, emulation engineering, detection engineering, observation, exercise control and evidence.
  • When to use: For each role holder, each year.
  • Inputs: Role charter, learning paths.
  • Outputs: competence/CMP-*.yaml.
  • Chapter: Chapter 24

B.25 Horizon register

  • Purpose: Lists trends for the loop, each labelled observable, expected or speculation, with a review date.
  • When to use: Each year.
  • Inputs: Sources, own observations.
  • Outputs: horizon/register.yaml.
  • Chapter: Chapter 25

B.26 Anti-pattern checklist

  • Purpose: Checks the loop against the anti-patterns of Chapter 26 (AP-*).
  • When to use: Annually and after an incident.
  • Inputs: Loop records, last exercise.
  • Outputs: Completed checklist.
  • Chapter: Chapter 26

B.27 Two-year plan

  • Purpose: Turns the book's conclusions into measures with owners and a review date.
  • When to use: When starting, and each year.
  • Inputs: Chapters 4 to 27.
  • Outputs: PLAN-* and an AIDR.
  • Chapter: Chapter 28

Repository tools

Tool Purpose
scripts/toc_definition.py Holds the table of contents and regenerates book_index.json, the MkDocs navigation and the chapter list in BOOK_REQUIREMENTS.md
scripts/generate_outlines.py Regenerates the chapter briefs in BOOK_BLUEPRINT.md and outline files for chapters not yet written
scripts/format_citations.py Derives citation labels from the bibliography
scripts/renumber_sources.py Keeps the bibliography numbered 1..N without gaps or uncited entries
scripts/check_mermaid_diagrams.py Renders and validates the diagrams