Appendix B: Templates and Tools

This appendix is the directory of reusable templates and tools for development with AI, in the repository that accompanies AI Developer. It lists every artefact the book introduces, says where the full listing is and where the idea is argued, and describes the tools that check and build the manuscript. Each artefact is designed to be copied into an organisation's own repositories, adapted to its delegation order, works agreements and national law, and kept under version control beside the code it governs. Fields are placeholders: replace every value in angle brackets, and treat the dates and numbers in the chapters as shapes to be filled, not as recommendations.

The templates of the earlier volumes (the governance templates of AI Governance, Appendix C, the mandate and delegation artefacts of AI Boss, the role and control artefacts of The Transformed Security Architect, the service, runbook and observer artefacts of AI Operations and the decision-rights and answerability artefacts of AI Leader) are not repeated here; this appendix lists only what is new in this book. Where an artefact of an earlier volume is reused, such as the change record CHG-* or the post-incident review PIR-*, the entry says what this book adds to it. None of the templates is legal advice, and none replaces a signed agreement.

How to use this directory

Three places hold an artefact, and the directory names each:

The chapter argues why the artefact has the fields it has, shows an excerpt or a complete worked example for Nordvik Region or Hansa Mutual, and ends with a practical guide in the form Purpose, Roles, Inputs, Steps and Resulting artefact.
Appendix A (Chapter 35) holds the complete, valid versions of the artefacts that Chapters 1 to 33 show, in nineteen sections numbered A.1 to A.19. The column "Appendix A" of the table below gives the section; a section may hold several artefacts of the same family.
This appendix gives the directory, a short description of each artefact (purpose, when to use it, output) and the checklists that a reviewer can run without reading the chapter.

The identifier families are those of the chapters: DLG-*, MND-*, RUN-*, SPC-*, OWN-*, VER-*, RVW-*, PRV-*, AVR-*, APR-*, CMP-*, ROLE-* and HZN-* are this book's; CHG-*, SVC-*, RBK-*, RST-*, INC-* and PIR-* come from AI Operations; LDR-* and DRR-* come from AI Leader; KBV-* and MBA-* are the works agreements and negotiation records of the two organisations. AI Decision Records run from AIDR-1100 to AIDR-1199, and Architecture Decision Records (ADR) are numbered per organisation. The glossary (Chapter 34) defines each family. The book coins no identifier family for the team practice agreement, the working agreement or the register entries; they are identified by the decision record that adopts them and by their place in the team's repository.

Templates by activity

No.	Activity	Artefact	Identifier	Chapter	Appendix A
B.1	Definition	Delegation profile with a work-class table	`DLG-*`	Chapter 4; the one-page view in Chapter 1	A.1
B.2	Definition	Stewardship test check: Name, Understand, Revert, with the independent-oracle question	part of `DLG-` and `OWN-`	Chapter 4	A.1
B.3	History	Practice inventory and a role description set against a charter-as-code	`ROLE-*`	Chapter 2	A.15
B.4	Pressure	Developer work and load map	none	Chapter 3	A.15
B.5	Framing	Specification record with acceptance criteria and traceability	`SPC-*`	Chapter 5	A.3
B.6	Design	Architecture Decision Record with AI involvement recorded, and the conformance rules derived from it	ADR, `RULES-*`	Chapter 6	A.13
B.7	Building	Coding-assistant usage profile with acceptance criteria and a measurement plan	system id such as `NR-DEV-001`	Chapter 7	A.1
B.8	Building	Mandate manifest for a coding agent	`MND--DEV-`	Chapter 8	A.2
B.9	Building	Agent run record	`RUN-*`	Chapter 8	A.7
B.10	Proving	Verification plan with an independent oracle	`VER-*`	Chapter 9	A.5
B.11	Proving	Review record	`RVW-*`	Chapter 9	A.6
B.12	Proving	Provenance record and the controls for a coding agent	`PRV-*`	Chapter 10	A.8
B.13	Stewarding	Change record with a generator-independent gate and a rollback rehearsal	`CHG-*`	Chapter 11	A.12
B.14	Stewarding	Code-ownership record and the yearly ownership review	`OWN-*`	Chapter 12	A.4
B.15	Roles	Apprenticeship plan	`APR-*`	Chapter 13	A.10
B.16	Roles	Role charter with a professional-judgement clause and a review budget	`ROLE-*`	Chapter 14	A.15
B.17	Roles	Team working agreement and weekly rhythm	none	Chapter 15	A.15
B.18	Neighbours	Golden-path specification with AI tooling defaults; error-budget rule for AI-originated change	none	Chapter 16	A.14
B.19	Neighbours	Role-boundary matrix	none	Chapter 17	A.5
B.20	Public authority	Procurement criteria sheet for an AI coding tool	tender number	Chapter 18	A.17
B.21	Citizen building	Register entry and promotion criteria for a tool built by a non-developer	register id	Chapter 19	A.4
B.22	Adoption	Adoption and value record with evidence age; internal experiment plan	`AVR-*`	Chapter 20	A.9
B.23	Culture	Team practice agreement	none	Chapter 21	A.15
B.24	Participation	Telemetry description and consultation file; agreement outline; negotiation record	`KBV-`, `MBA-`	Chapter 22	A.16
B.25	Incidents	Post-incident review fields for AI-involved change	`PIR-*`	Chapter 23	A.14
B.26	Regulation	Duty register: the developer section of the legal annex to the decision rights register	`DRR-*-LEG`	Chapter 24	A.17
B.27	Ethics	Values-to-engineering-rule mapping	none	Chapter 25	A.17
B.28	Sovereignty	Licence policy; toolchain dependency and exit record	`LIC-*`	Chapter 26	A.17
B.29	Development	Competence record and development plan	`CMP-*`	Chapter 27	A.11
B.30	Development	Developer practice plan	`CMP--P`	Chapter 28	A.11
B.31	Future	Horizon register	`HZN-*`	Chapter 29	A.18
B.32	Review	Anti-pattern check of an estate	none	Chapter 30	A.18
B.33	Experience	Year read-out: a ledger of claims with closing records	none	Chapter 31	A.18
B.34	Conclusions	Twelve-month plan with measures and owners	none	Chapter 32	A.18
B.35	Conclusions	Thesis scorecard as an AI Decision Record	AIDR	Chapter 33	A.18

The nineteen Appendix A sections, in order, are: 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, A.5 verification plans and the role boundary matrix, A.6 review records, A.7 agent run records, A.8 provenance records and toolchain controls, A.9 adoption and value records, A.10 apprenticeship plans, A.11 competence records and practice plans, A.12 change records, A.13 design records and conformance rules, A.14 platform, release and incident records, A.15 role charters, work maps and team agreements, A.16 works agreements, negotiation records and telemetry, A.17 duty registers, values, procurement and dependency records, A.18 horizon registers, checks, plans and the scorecard, and A.19 a check of profiles and mandates. Chapter 31 follows a year of the two organisations and uses these artefacts in sequence; its own artefact is the year read-out (B.33).

Template descriptions

Each description gives the purpose, the moment to use the artefact and what it produces. The worked examples, with the names and numbers of Nordvik Region and Hansa Mutual, are in the chapters named in the directory.

B.1 Delegation profile (`DLG-*`)

Purpose: States, per class of development work (specify, design, generate, refactor, test, review, deploy, operate, document, migrate), the highest degree of delegation, who answers, the evidence for the level and its date, the stop path and the review date. A class not listed is undelegated. The profile never exceeds the recommended ceilings of Chapter 4 and carries the five Level 4 prohibitions.
When to use: For every team or organisation that uses AI in development. Review on evidence and at least twice a year. Lowering a level is immediate; raising one is a named authority's decision and an AI Decision Record.
Outputs: delegation/DLG-*.yaml and an AI Decision Record. DLG-NR-DEV-01 and DLG-HM-DEV-01 are the book's profiles.

B.2 Stewardship test check

Purpose: Records for one change, module or tool whether the owner passes Name (identifiable in the code-ownership record), Understand (can explain and reconstruct the change without the tool) and Revert (has the authority, access and time to stop or roll back outside the pipeline that shipped it), and whether the oracle is independent of the generator.
When to use: Before a class is delegated or raised, after an incident, at each ownership review and when a citizen-built tool is promoted.
Outputs: The stewardship block of a delegation profile or an ownership record, with the date and the expiry of the evidence.

B.3 Practice inventory and role description

Purpose: Lists the practices a team has inherited (craft, review, agile, DevOps, open source, platform engineering) and sets a pre-AI role description against a role charter in code.
When to use: Before writing a charter, so that what the old description left out (ownership, legacy, review) is not left out again.
Outputs: A practice inventory and a draft ROLE-*.

B.4 Developer work and load map

Purpose: Maps one developer's week by activity, load and AI contribution, so that claims about time saved can be compared with where the time went.
When to use: At the start of an adoption programme and before a headcount or capacity conversation.
Outputs: A work and load map for a role such as ROLE-NR-DEV-01, reported by role and never as a ranking of named developers.

B.5 Specification record (`SPC-*`)

Purpose: States intent so that it can be tested: need, requirements, acceptance criteria, out of scope, assumptions, open questions, how AI took part, recorded dissent, tests and a review date, with an owner and an oracle owner.
When to use: Before any generation for work that will reach production; the specification, not the prompt, is the source of intent.
Outputs: specs/SPC-*.yaml linked from the change and from the verification plan.

B.6 Architecture Decision Record with AI involvement

Purpose: Records a design decision with what the tool contributed, what the human added or rejected, who decided, the reversibility and the review date; conformance rules derived from the decision let drift be measured.
When to use: For every decision that fixes a boundary, an interface or a constraint.
Outputs: An ADR (for example ADR-NR-0031) and a rule set that the pipeline enforces.

B.7 Coding-assistant usage profile

Purpose: Narrows a delegation profile for one assistant: usage mode, work classes, acceptance criteria for using its output and a measurement plan. It never widens the profile.
When to use: Before a pilot starts, and again before it is extended.
Outputs: A usage profile for a system such as NR-DEV-001.

B.8 Mandate manifest for a coding agent (`MND--DEV-`)

Purpose: States what an agent may do, with what, on what, for how long and at what cost, the sandbox, the credentials, the budgets and who holds the stop outside the agent. A mandate may lower a level and never raise it.
When to use: Before any agent opens a pull request or runs a command in a repository; review at the date stated.
Outputs: mandates/MND-*.yaml and an AI Decision Record. MND-HM-DEV-01 (patch-level dependency updates, the one Level 3 Bounded class) and MND-HM-DEV-02 (the agent pilot) are examples.

B.9 Agent run record (`RUN-*`)

Purpose: Records one run of an agent: mandate, one-run identity and scope, what was read and changed, the commands executed, the checks and the approvals. It is written outside the agent.
When to use: For every run of an agent with a mandate; retain for the period the register states.
Outputs: runs/RUN-*.yaml, referenced from the provenance record and the change record.

B.10 Verification plan (`VER-*`)

Purpose: States how a change will be shown to be right: the generator, whether the path is security or payment critical, the specification, the independent oracle and its owner, mutation and static-analysis checks, review, the steward and a date until which the evidence is valid.
When to use: For each change of consequence, and for each class of change in a mandate.
Outputs: verification/VER-*.yaml.

B.11 Review record (`RVW-*`)

Purpose: Records the review: the plan it belongs to, the reviewers, how many AI review comments were useful, wrong or noise, the checks run, what was not covered, whether the steward could restate the change without the tool, and the outcome. An AI comment never counts as a human approval.
When to use: At every merge in a security-critical or payment path, and by sampling elsewhere.
Outputs: reviews/RVW-*.yaml.

B.12 Provenance record (`PRV-*`)

Purpose: Records where a change and its dependencies came from: whether an assistant or agent contributed, under which mandate and run record, the dependencies with the proxy's decision, licence and hash, the checks, the build and the people, with a reference to the bill of materials. Where nothing recorded the origin, the field says "not asserted".
When to use: For each release, and when a dependency, model or tool changes.
Outputs: provenance/PRV-*.yaml and the controls for the coding agent (package proxy, secrets, egress, build identity).

B.13 Change record (`CHG-*`)

Purpose: The change record of AI Operations, with a gate that the change cannot alter, an out-of-band execution statement, an independent oracle, a rollback rehearsal and the owner named before the change is.
When to use: For every change that reaches production.
Outputs: changes/CHG-*.yaml.

B.14 Code-ownership record (`OWN-*`)

Purpose: Names the owner and a deputy of a module or repository, what it is, where its tests and decisions are, how it is reverted, when it is next reviewed and under what conditions it is retired, with the dates of the last explanation without the tool and the last revert test.
When to use: For every repository and module, and at the yearly ownership review. OWN-NR-2030-00 and OWN-HM-2030-00 are the first inventories.
Outputs: ownership/OWN-*.yaml.

B.15 Apprenticeship plan (`APR-*`)

Purpose: Designs the route by which a junior developer becomes an experienced one: attempt first, review first, an AI-off day, an owned small change with a revert drill, mentoring time, a second assessor and a review date.
When to use: At each junior intake and each six months.
Outputs: apprenticeship/plans/APR-*.yaml.

B.16 Role charter (`ROLE-*`)

Purpose: States tasks, decision rights, delegation ceilings and protections of a role. The senior developer charter adds the professional-judgement clause (right to hold, to an explanation, to decline ownership, to record dissent, no use target in appraisal, unassisted work) and a review budget.
When to use: When a role is created or changed, and after consulting the representatives where the national act requires it.
Outputs: roles/*.yaml, for example ROLE-NR-DEV-01.

B.17 Team working agreement

Purpose: Records a team's rules for generated code: scope and ownership, work classes and ceilings, agents and mandates, data and secrets, review rules, the oracle, metrics, rhythm and the stop.
When to use: When a team starts using an assistant, and at each retrospective.
Outputs: working-agreement.yaml in the team's repository.

B.18 Golden-path specification and error-budget rule

Purpose: Puts the AI tooling defaults into the platform's golden path (allow-list, logging and cost, supply chain, route) and lowers the degree of delegation for AI-originated change when a service's error budget is spent.
When to use: When a platform team adopts an AI gateway or a new template.
Outputs: A golden-path specification and an error-budget policy that cites its AI Decision Record.

B.19 Role-boundary matrix

Purpose: Records, per role, who frames, builds, proves and owns, so that the boundaries around intent and prototype can move while those around proof and ownership do not.
When to use: When product owners, designers or testers begin to build prototypes with AI.
Outputs: A role-boundary matrix for a team.

B.20 Procurement criteria sheet

Purpose: Gives a procurement officer weighted criteria for an AI coding tool that a developer can check against a repository: fit on the buyer's stacks, life-cycle cost, security and secure development, exit, data, evidence.
When to use: Before a tender for a coding tool.
Outputs: A criteria sheet attached to the tender, such as NR-2030-041.

B.21 Register entry and promotion criteria

Purpose: Enters a tool built by a non-developer in the register with its tier (A personal, B team, C business, D project), owner and deputy, data, assistants and review dates, and sets the promotion criteria as code.
When to use: At registration and before any promotion from prototype to production.
Outputs: A register entry and a promotion criteria file.

B.22 Adoption and value record (`AVR-*`)

Purpose: States an adoption or value claim with its quoted value, basis, owner, independent evidence owner, plan, expiry and the decision it supports; the quoted claim and the measured claim are shown side by side.
When to use: Before any claim of productivity or value is reported, and before any extension of a pilot.
Outputs: adoption/AVR-*.yaml.

B.23 Team practice agreement

Purpose: The one-page, checkable agreement of a team on pairing with an assistant, review culture, trust calibration, speaking up and shadow AI. It may only be stricter than the delegation profile.
When to use: After a retrospective on AI-assisted work.
Outputs: An agreement identified by the decision record that adopts it.

B.24 Consultation file, agreement outline and negotiation record

Purpose: Hands employee representatives what they need to examine a coding tool: purpose, mode, contract clauses, delegation profile, mandate, telemetry description (field, grain, retention, readers), data flows and the way the tool changes. The agreement outline (KBV-IT-2024-DEV-01) and the negotiation record (MBA-NR-2030-03) follow the national act. Nothing in it is a method for defeating a right.
When to use: At a pilot, a vendor update, a telemetry switch-on, a mandate change and any evaluative use.
Outputs: A consultation file and an agreement or negotiation record.

B.25 Post-incident review fields

Purpose: Adds AI involvement to the post-incident review of AI Operations: the degree of involvement (none, suggested, drafted, executed, unknown, or unknown in part) with the tools, delegation profile, mandate and evidence, what follows from not knowing, whether the oracle was independent of the generator, the three stewardship tests with the time to the decision to revert, the mechanism class, the contributing conditions and a statement that no individual is named as cause.
When to use: For every incident in which AI-involved change is a candidate cause, and for near misses.
Outputs: PIR-* with the additional fields.

B.26 Duty register

Purpose: Maps instrument and article to the duty, the addressee, the holder and deputy, the artefact that answers it, the maximum age of the evidence and the ceiling for AI, after the role test has said which duties apply.
When to use: At each reading of the texts (the register states the date and the next re-verification) and on every announced amendment.
Outputs: The developer section of DRR-*-LEG.

B.27 Values-to-engineering-rule mapping

Purpose: Gives one organisational value a rule that a developer meets at the point of work, a check independent of the generator and evidence that expires.
When to use: When a value is cited but no one can say what it asks of a pull request.
Outputs: A mapping file kept beside the delegation profile.

B.28 Licence policy and toolchain dependency and exit record

Purpose: Sets which licences may enter a codebase and who answers for exceptions (LIC-HM-DEV-01), and records each dependency of the coding toolchain with its exit route and a tested alternative.
When to use: At procurement, at each model or provider change and at the yearly review.
Outputs: A licence policy and a dependency and exit record.

B.29 Competence record (`CMP-*`)

Purpose: States a developer's competence as a claim: the six competence groups, the level (Foundation, Practitioner, Advanced, Expert), the kind of evidence, its date and expiry, the assessor and the development plan. It separates assisted from unaided performance and is personal data.
When to use: At appraisal-independent reviews, hiring and promotion. Evidence expires after 90 days, 180 days or a year, as the competence decays.
Outputs: competence/records/CMP-*.yaml.

B.30 Developer practice plan

Purpose: The plan by which a developer keeps skill in practice: AI-off sessions, code-reading time and what to keep by hand, agreed with the line.
When to use: Each quarter.
Outputs: competence/practice-plans/CMP-*-P*.yaml.

B.31 Horizon register (`HZN-*`)

Purpose: Lists the trends that bear on developer roles, each with its label (observable, expected or speculation), the functions concerned, evidence and its age, a trigger that would change the label, the posture (commit, prepare, keep reversible), an owner and a review date.
When to use: Twice a year, and when a trigger fires.
Outputs: HZN-NR-2031-01 and HZN-HM-2031-01 are the examples.

B.32 Anti-pattern check

Purpose: Reviews an estate against the nine anti-patterns, with the test that fails, the early signal and the control for each.
When to use: Yearly, and before a programme is expanded.
Outputs: A dated check file, such as governance/anti-pattern-check-2031-02.yaml.

B.33 Year read-out

Purpose: Keeps the year's claims as a ledger, each with a month, a record, a basis (recorded or derived) and a status (closed, closed with conditions, running or open). An entry without a closing record is an open item and not a result, and no class may stand at Level 4. The ledger is held by a partner outside the line and does not contain coding-tool logs.
When to use: At the end of each quarter and at the year's close, before a report to the executive committee and the representatives.
Outputs: year/read-out-<organisation>-<year-month>.yaml.

B.34 Twelve-month plan

Purpose: Fixes the measures, baselines and owners for the next twelve months, with proposals for month 12 and the risks that would change the plan.
When to use: At the close of the year and at each leadership review.
Outputs: governance/twelve-month-plan-2031.yaml.

B.35 Thesis scorecard

Purpose: States, for each part of the thesis and each Monday action, what is claimed, on what evidence, how old it is and when it is next read.
When to use: At the end of a programme year, decided by the executive who owns it.
Outputs: An AI Decision Record of kind thesis-scorecard.

Checklists

Delegation profile review checklist

The profile names its decision record, the answerer for every work class and the raise authority, and its version and date are current.
Every class of work that an assistant has touched appears in the profile; any class not listed is undelegated and capped at Level 0.
No class is at Level 4 for a change to production without a gate the change cannot alter, for code in a security-critical or safety-critical path without review by a named developer, for a change to the agent's own mandate, permissions, credentials, test oracles, review rules or pipeline gates, for an irreversible action on production data, or for a decision about a named person's employment, pay, performance rating or access to work.
The ceiling for each class is the lowest of the five answers (reversibility, blast radius, who is affected, evidence, strength of the independent checks), and the evidence is dated and not expired.
The stop path was drilled within the period the profile states, runs outside the pipeline and its measured time is recorded.
Employee representatives have been informed or have agreed, as the national act requires.
The next review date is set and a short AI Decision Record is filed.

Verification and review checklist

The oracle is not written by the generator of the change, and its owner is named.
An AI review comment is not counted as a human approval, and no check shares the generator's failure modes without saying so.
The record says what was not covered, and the evidence has a valid-until date.
The steward could restate the change without the tool.
Seeded-defect and review-time figures are reported by team and never per named developer.

Claim record checklist

The claim is one sentence and says what is claimed, not what was hoped.
Scope, counting rule, method and sample are stated; a figure without them is not quoted.
The result is given with its uncertainty and the date of measurement.
The evidence owner is independent of the sponsor.
An expiry date and the conditions that expire the claim early are set.
The quoted figure and the measured figure are shown side by side where they differ.

Repository tools

The repository is a publishing platform, and its tools check and build the manuscript. They are not part of any organisation's development practice, and they are listed so that a reader who adopts a template can keep it under the same discipline.

Tool	Purpose	How to use it
`scripts/toc_definition.py`	Holds the table of contents and regenerates `docs/book_index.json`, the MkDocs navigation and the chapter list in `BOOK_REQUIREMENTS.md`	`python3 scripts/toc_definition.py --write` after changing the table of contents
`scripts/outline_data.py`	Holds the brief and status of each chapter	Edit when a chapter is written out
`scripts/generate_outlines.py`	Regenerates the chapter briefs in `docs/BOOK_BLUEPRINT.md` and the outline files of chapters not yet written; never overwrites a drafted chapter	`python3 scripts/generate_outlines.py`
`scripts/navigation.py`	Resolves the ordered chapter list from `mkdocs.yml` for the book build	Used by the build scripts
`scripts/format_citations.py`	Derives the inline citation labels from the bibliography	`python3 scripts/format_citations.py --fix` after citing
`scripts/build_sources_section.py`	Writes a chapter's `## Sources` list from the sources cited in it	Run on a chapter file after the citations are in place
`scripts/renumber_sources.py`	Keeps the bibliography numbered 1..N without gaps or uncited entries	`--check` in CI; `--apply` before merging
`scripts/merge_new_sources.py`	Merges the entries in `sources_new/` into `docs/36_references.md`	Run by the maintainer before renumbering
`scripts/update_reference_backlinks.py`	Refreshes the "Referenced in" notes of each bibliography entry	Run after renumbering
`scripts/audit_references.py`	Audits each chapter's citations against the bibliography	`python3 scripts/audit_references.py`
`scripts/verify_sources.py`	Checks that cited URLs and ISBNs resolve or are well formed	`python3 scripts/verify_sources.py`
`scripts/check_mermaid_diagrams.py`	Renders and validates that each committed PNG matches its `.mmd` source	`--write-missing` to render missing or outdated PNGs
`scripts/render_diagram.sh`	Renders one Mermaid source with the book's theme	`scripts/render_diagram.sh docs/images/<file>.mmd`
`scripts/validate_diagram_elements.py`, `validate_diagram_branding.py`	Limit a diagram to 15 elements and check brand and spelling rules	Run before committing a diagram
`scripts/validate_figure_captions.py`, `validate_heading_capitalization.py`	Check figure captions and heading capitalisation	Run before committing a chapter
`scripts/check_doc_numbering.py`	Checks the numbering of chapter files	Run in CI
`scripts/analyze_chapter_lengths.py`	Reports chapter lengths against the average	Run when a chapter is added or cut
`scripts/verify_environment.py` (`make verify-env`)	Verifies that toolchain versions match the locks	`make verify-env`
`docs/build_book.sh`	Builds PDF, EPUB and DOCX with Pandoc	`docs/build_book.sh --all-formats`
`generate_presentation.py`, `generate_whitepapers.py`, `build_all_orchestrator.py`	Produce the presentation and whitepapers and coordinate a complete build	`python3 build_all_orchestrator.py --zip`
`tests/`	The pytest suites that enforce structure, citations, series order and code examples	`python3 -m pytest tests/ -q`

A template in this appendix is kept as a file in the organisation's own repository and checked there by whatever validation the organisation runs; the book supplies the shapes and the rules and does not supply a runtime for development.

Sources

Nordqvist, G. (2025). Architecture as Code. (161, Nordqvist, 2025)
Nordqvist, G. (2026). AI Governance; AI Boss; AI Operations; The Transformed Security Architect; AI Leader. (162, Nordqvist, 2026), (166, Nordqvist, 2026), (167, Nordqvist, 2026), (170, Nordqvist, 2026), (174, Nordqvist, 2026)