This appendix holds the complete versions of the artefacts that Chapters 1 to 33 show in part or in full. Each artefact keeps the field names, identifiers, names, dates and decision records of the chapter that owns it, so that the appendix and the chapter can be read side by side. Where a chapter shows an artefact as an excerpt, the appendix gives the file as the chapter wrote it; where two chapters touch the same artefact, the chapter that owns it governs and the other is noted. Three listings are rendered by this appendix from the prose and tables of the owning chapters, because the chapters describe them without printing the file (DLG-HM-DEV-01, AVR-HM-2030-01 and the check in A.19); each is marked as rendered. The fictional organisations Nordvik Region and Hansa Mutual are described in the book's example profiles; every person, record and figure here is illustrative. Every YAML block parses and is meant to live in version control beside the AI Decision Record that approved it (AIDR-1100 to AIDR-1199). The Python block in A.19 is a small check and not part of the build. No artefact is attack tooling, and no artefact holds data about a named member of staff beyond what its purpose line allows.
Each section states which chapter introduces the artefact, what it is for and what it must never contain. Legal references in the artefacts are organisational and architectural implications, not legal advice.
1. Start from the work class, not from the file. Take the ten classes of development work (specify, design, generate, refactor, test, review, deploy, operate, document, migrate) and write the delegation profile (A.1) first. Every other artefact either serves that profile or is checked against it.
Primary topics explored
- How to use this appendix
- Identifier families
- A.1 Delegation profiles and usage profiles
- A.2 Mandate manifests
- A.3 Specification records
- A.4 Code-ownership records and the register of built tools
About AI Developer
AI Developer is Book 12 of The Transformed Architecture. It takes the developer as its subject and asks what happens when AI is used broadly in software development: the five developer functions (frame, design, build, prove, steward), the delegation ladder and the Level 4 prohibitions, the stewardship principle (name, understand, revert), verification as the scarce skill, the junior pipeline, adoption and productivity as claims that need evidence, regulation (the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA, the GDPR), ethics, intellectual property and sovereignty in the toolchain, and the developer as a person, for European enterprises and public authorities.
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, AI Operations and AI Leader.
developers at every level, tech leads and engineering managers, architects, platform engineers, site reliability engineers and testers, product owners and designers, leaders who decide on developer tooling, heads of public-sector IT and procurement, works councils and unions, educators, and supervisors and auditors.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Appendix A: Appendix A: Code Examples: Delegation, Mandate, Specification and Ownership Records in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Appendices” and is one of 37 drawn from the manuscript.