Tools · Whitepaper

Chapter 5 · Architecture and Delivery

Policy, Pipeline and Evidence Tools

Key insights from Chapter 5 of "Tools"

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 11 November 2026
Build number 2026.11
tools templates methods architecture-as-code ai-governance
Figure 5.1: The policy, pipeline and evidence chain. The policy decision point sits outside the author of the change, and the evidence store is written by the pipeline, not by the people whose work it records.
Figure 5.1: The policy, pipeline and evidence chain. The policy decision point sits outside the author of the change, and the evidence store is written by the pipeline, not by the people whose work it records.

This chapter serves one activity: turning a rule into a check that runs on every change, and turning the result of that check into evidence that someone else can verify. It treats four kinds of tool. The artefacts are the policies, workflows, manifests and records that the earlier volumes define. The own tools are a handful of workflows in the repositories of the series. The third-party tools are the policy engines, scanners, pipeline platforms, signing and attestation systems and bill-of-materials formats that the volumes name. The methods are the named procedures for testing policies, for gating a change and for managing evidence over its life. The tools come mainly from Architecture as Code (Chapters 5, 10, 11, 13 and 15A) (1, Nordqvist, 2025), which built the pipeline and evidence pattern; from AI Governance, Chapters 9 and 11, and AI Platform and Security, Chapters 7, 8, 16, 17 and 20, which carry it to models, prompts and agents (2, Nordqvist, 2026) (3, Nordqvist, 2026); from AI Red Team, Chapter 16, and The Transformed Security Architect, Chapters 5 and 6, which write policy for security AI and for architecture (4, Nordqvist, 2026) (6, Nordqvist, 2026); from AI Purple, Chapter 11, which makes evidence expire (9, Nordqvist, 2026); and from AI Operations, Chapters 8 and 18, which puts a policy decision point in the path of a change and a policy around the engine that applies it (10, Nordqvist, 2026).

The chapter is a reference. It does not repeat the arguments of the volumes; it says what each tool is for, what it needs and produces, and which chapter holds the reasoning. Where a template is quoted, it is quoted from the volume named, with whole fields removed and nothing else changed. Third-party software is described only as the series uses it and from the documentation cited in the bibliography of this book; the earlier volumes are the source for what the series does with a tool, never for what the software does.

The tools in this chapter form one chain, drawn in Figure 5.1. Policies, tests and records sit in version control. An artefact or a change enters the pipeline, tests and scanners produce results, and a policy decision point evaluates the results against the policy bundle and returns allow or deny with reasons. In parallel the build produces a bill of materials and a provenance attestation, and a signing step binds the artefact to an identity. A named human approves only the classes that the policy names. Every stage leaves an artefact, and an evidence manifest binds the artefacts to the obligations and controls they satisfy. The manifest goes to an append-only store, and an evidence pack is generated from the store by query, for an auditor, a supervisor or a customer.

Primary topics explored

  1. The chain in one view
  2. Policy engines and the policy language
  3. Policies that gate a change
  4. Pipelines and testing
  5. Supply-chain tools: provenance, signing and bills of materials
  6. Evidence tools

About Tools

Tools is a companion to The Transformed Architecture. It collects the tools that Books 1 to 10 describe in one reference, organised by what the practitioner is doing: artefacts (templates, manifests, records), own tools, third-party tools and standards, and methods. Each entry says what a tool is for, when to use it, what it needs and produces, and where the book that defines it explains the reasoning. The book covers choosing, adopting and retiring tools, architecture and delivery, governing AI, securing and testing, operating, agents and autonomy, and people, organisation and society, for European enterprises and public authorities. It comes with a template library, an inventory, three web tools and the Toolbox Maturity Method.

It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple and AI Operations.

Who should read this

Architects and security architects, CIOs and CISOs, platform and operations leads, heads of governance, risk, compliance and third-party risk, AI governance and AI platform teams, red, blue and purple team leads, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.

Portrait of Gunnar Nordqvist

Gunnar Nordqvist

Conceived, directed and published the books of The Transformed Architecture.

Continue with the full chapter

Read the full chapter online

Chapter 5: Policy, Pipeline and Evidence Tools in Tools gives the detailed explanations, practical examples and implementation patterns behind this summary.

This whitepaper belongs to “Architecture and Delivery” and is one of 29 drawn from the manuscript.