Appendix B: Templates and Tools
This appendix collects what a builder needs at the desk while following the twelve steps of Vibe to Dev, and what a reviewer, a receiving developer or a platform team needs to check a build without reading a chapter. It has four parts: the checklists (the twelve steps by tier, the tier decision sheet, the security checklist by tier, the takeover-test checklist and the rules for evidence age), the ordinary prompts that a builder can give an assistant at each step, the categories of tool that a build needs and what each must provide, and the limits that apply to every assistant at every tier. The complete artefacts that the checklists refer to, for the two builds of the book, are in Appendix A (Chapter 27).
The appendix names no product. Tools are described by category and by what each must provide, because a category can be replaced by whatever the organisation has procured, and a product name in a book dates faster than the requirement behind it. The tiers, the delegation ladder and the stewardship principle (Name, Understand, Revert) are those of AI Developer, Chapters 4 and 19, applied to the builder in Chapter 4 of this book (86, Nordqvist, 2026). None of the checklists is legal advice, and none replaces a signed agreement, the screening of a data protection officer or the review of a named developer.
How to use this appendix
- Decide the tier first (B.2). The tier sets how much of every other checklist applies. If any stop sign of Tier D is present, stop and refer; the rest of the appendix is for builds that are not Tier D.
- Work the steps in order (B.1). A step is finished when its artefact is shown, not when it feels finished. Write the date next to each gate in the build record
BLD-*. - Use the prompts as starting points (B.7). They are ordinary instructions. Adapt them to the build, give the assistant the files it needs and read what it returns against the artefact it was meant to help draft.
- Ask a person for what the assistant may not do. An assistant may draft, generate and explain; it may not own, and it may not be the only judge of its own work. The checklists say where a person other than the builder and the assistant must act.
- Date everything. Every checklist item that records a result carries a date, and evidence expires (B.6).
B.1 The twelve steps by tier
The first table gives the gate and the artefact of each step as Chapter 4 defines them. The second gives what each step requires at each tier, in the proportion table of Chapter 4. Tier D is not a citizen build: at Tier D every step is the development organisation's own route.
| Step | Purpose | Exit gate: shown, not asserted | Artefact | Developer functions |
|---|---|---|---|---|
| 1 Intent | Say what is being built, for whom and how success will be known | The user named in the intent has read it and says it describes the problem; the builder's manager has read it | One-page intent, section 1 of the BLD record |
D1 |
| 2 Tier | Decide how much structure the work needs | The five questions are answered in writing with sources, the tier is decided with the signals that would change it, the manager has countersigned, and the data protection officer has screened it where personal data of others is involved | Tier decision, section 2 of the BLD record |
D1, D2 |
| 3 Workshop | Prepare a place to work that can be trusted | The deputy clones the repository on another machine and, from the README alone, runs the tests and the tool on synthetic data (the clone-and-restore test) | Repository with README, AGENTS.md, mandate MND-*-BLD-*, configuration without secrets |
D3, D5 |
| 4 Specification | Write down what correct means | Every rule has an example and a failure case, the never-do list is written, the oracle owner is named and is neither the builder nor the assistant, and the process owner has approved | Specification record SPC-* |
D1 |
| 5 Design | Decide the technology, the data and the access | A developer or architect has read the one-page design in ten minutes and can say where the data lives, who can reach it and how the tool is switched off | One-page design with three to five ADRs | D2 |
| 6 Build | Make the first version in small slices | Every slice is committed with passing tests, the builder has read each diff against the plan, every assistant session has a run record, and the tool runs from a fresh clone | Commits and run records RUN-* |
D3 |
| 7 Prove | Show that it works, by something other than the assistant's word | Tests derived from the specification pass, the independent oracle cases pass and were written by neither the builder nor the assistant, and a person other than both has reviewed | Verification plan VER-*, review record RVW-* |
D4 |
| 8 Secure | Make it safe at the level the tier requires | The checklist of the tier (B.3) is complete with result and date, the secret scan is clean, the dependencies are recorded, and the screening is attached where personal data is involved | Provenance record PRV-* |
D4 |
| 9 Ship | Release through a path that can be undone | The release was made by the pipeline and not by the builder's hands, the version is tagged, and the Revert test is done: the previous version was restored by following the rollback note | Change record CHG-*, release notes, rollback note |
D5 |
| 10 Run | Watch, back up and support what was built | A person other than the builder receives the failure alert, a restore test has date and result, and the runbook lets a colleague stop the tool | Runbook manifest RBK-*, restore-test record RST-* |
D5 |
| 11 Own | Keep the tool owned over time | Owner and deputy are named, the deputy has passed the explain-it-back drill without the assistant, and the review and sunset dates are set | Ownership record OWN-* and a README that explains |
D5 |
| 12 Hand over | Hand over, promote or stop | A named colleague has passed the takeover test in a working day | Handover pack HND-* and takeover-test result TKT-* |
D5, D1 |
| Step | Tier A, personal | Tier B, team | Tier C, business |
|---|---|---|---|
| 1 Intent | Three sentences in the README: purpose, user (yourself), what done looks like | One-page intent read by the unit head and the user | One-page intent with baseline and target for the success measure, approved by the process owner |
| 2 Tier | Self-check of the five questions | Recorded in the build record, read by the manager | Recorded, countersigned by the manager, screened by the data protection officer where personal data is involved, with reclassification signals |
| 3 Workshop | Repository with README and history; no secrets in files | Adds AGENTS.md, two environments, synthetic data and the platform's standard mandate |
Adds an own mandate approved by the manager, a secret store, and the clone-and-restore test with the deputy |
| 4 Specification | Five examples in the README | SPC record with examples and failure cases |
SPC record approved by the process owner, one example per rule, never-do list, oracle owner outside the builder |
| 5 Design | A note of where the data lives | Half a page: where data lives, who can reach it, one ADR | One-page design and three ADRs, read by a developer or architect |
| 6 Build | Commit habit | Slices, plan before code, run records | Slices, plan kept in the repository, run records for every session |
| 7 Prove | Run it on known cases yourself | Automated tests from the specification and cases from a second person | VER plan, independent oracle, review by a developer |
| 8 Secure | No secrets in files; nobody else's data | Checklist, secret scan, dependency list | Full checklist, PRV record, data protection screening, logs without personal data, developer review of access |
| 9 Ship | Copy to where it is used and keep the previous version | Tagged version, release notes, previous version kept for rollback | Pipeline only, CHG record, Revert test |
| 10 Run | You notice | A named channel for failure and a one-paragraph runbook | RBK runbook, alert to a person, restore test no older than 90 days, cost limits, support path |
| 11 Own | Your name in the README | OWN record with deputy; review every 12 months |
OWN record, explain-it-back drill, review every 6 months or as the register sets |
| 12 Hand over | Note the end date | Short handover pack; a colleague runs, changes and switches off | Full HND pack; takeover test by a developer, all items |
B.2 Tier decision sheet
Answer the five questions of Step 2 in writing, with the source of each answer (a field list, a conversation with the unit head, a reading of the file). An answer from memory is an assumption and is marked as one.
| Question | Answers to choose from | Source of this answer |
|---|---|---|
| 1. Who uses it? | Only me; my team; several units; people outside the organisation | |
| 2. What data does it touch? | None or public; internal; personal data; special categories of personal data | |
| 3. What can go wrong? | Wrong information; a wrong message to a person; money; an action that cannot be undone | |
| 4. Which law applies? | Data protection; the AI Act; sector rules; public-law duties; employment rules | |
| 5. Does it run unattended? | Only when I run it; on a schedule or trigger without anyone watching |
The tiers (Chapter 4; AI Developer, Chapter 19):
| Tier | Test | Who answers | What follows |
|---|---|---|---|
| A, personal | Used only by the maker; no personal data of others; no write access to shared systems | The maker | Counted in the platform inventory; expires after 12 months without use |
| B, team | Used by colleagues in one unit; internal data only; no personal data of people outside the team | The unit head, with the maker named | Register entry; sandbox environment; review every 12 months |
| C, business | Personal data of citizens, customers or staff; money; a record of the organisation; more than one unit; or unattended running | A named owner and a deputy | Promotion gates, developer review, support path, review every 6 months |
| D, project | Ranks or decides about a named person; is or feeds a high-risk AI system; touches a security-critical path; or acts irreversibly on production data | The development organisation | Not a citizen build: stop and refer |
Stop signs of Tier D. Tick any that applies, and if one does, stop: the intent becomes the first page of a project brief and the builder is not at fault.
- [ ] It ranks or decides about a named person (employment, pay, performance, access to work, benefits or services).
- [ ] It is or feeds a high-risk AI system.
- [ ] It touches a security-critical path (authentication, authorisation, cryptography, payment, clinical or life-safety logic).
- [ ] It acts irreversibly on production data.
Reclassify when the build is used by a second unit, runs on a schedule or without anyone watching, begins to hold personal data of people outside the team, or begins to call a model at run time. Write the signals that would change the answer into the build record at the time of the decision (Chapter 6).
B.3 Security checklist by tier
Step 8 Secure, Chapter 12. Tier D is not a citizen build. Each item is completed with a result and a date; evidence is valid for 90 days or the next change of code, dependency or assistant at Tier B and C.
| Control | Tier A personal | Tier B team | Tier C business |
|---|---|---|---|
| No secrets in repository, conversation or log | Required | Required, secret scan before commit | Required, scan in the pipeline |
| Secrets from the platform's store | Where a secret is needed | Required | Required, rotation date recorded |
| Access | Only you | Named people or group; read-only identity for the tool | As Tier B plus a named owner of the access list, reviewed on a date |
| Data | Your own, or synthetic | Synthetic in development; real data only after screening | Screening by the data protection officer attached; logs without personal data |
| Dependencies | Listed in requirements.txt |
Dependency policy; each new name looked up | Policy checked by the pipeline; a developer confirms each addition |
| Input and model calls | Validate what you can | Validate against the specification | Validated and tested; any model call reviewed by a developer |
| Provenance record | A note in the build record | PRV-*, one page |
PRV-* reviewed by a named developer, with date |
| Evidence valid for | Until the next change | 90 days or the next change | 90 days or the next change of code, dependency or assistant |
What the assistant may do at this step, from Chapter 12: explain a class of problem and review a file against a list (Level 0 Advisory); draft input checks, log lines and the provenance record (Level 1 Assisted, with the builder reading and the deputy checking, and never filling in a field it has not checked, such as a date or a scan result); propose a package name (Level 1 Assisted, with the builder looking it up and a person updating the policy). It reads no secret, production data or production configuration, and it does not edit the secret scan, the pipeline, the dependency policy or its own mandate.
B.4 Takeover-test checklist
Step 12 Hand over, Chapters 4 and 16. The test shows that a named colleague who did not build the tool can, in one working day, find it, run it, explain it, change it, ship the change, switch it off, restore it and revert a change, from the repository and the handover pack alone.
Before the day
- [ ] The handover pack
docs/handover.yamlis written from the records that exist, with exact names (release names, variable names, paths), and every command in it was run on a clean copy. - [ ] The runner is named. The runner did not build the tool, is not the deputy and is a person; the runner may use an assistant to do the work, and a person judges that each item passed.
- [ ] A working day (eight hours) is booked. The owner is reachable by telephone and not present. Every question the runner has to ask is written down as a gap in the pack.
- [ ] The oracle owner has prepared a small change task and the oracle case for it, and has not shown them to the builder.
- [ ] A test target exists where a change can be shipped without reaching users, and the platform's own template or pipeline is used. The builder's laptop is not.
- [ ] The runner is given the repository and the pack and nothing else.
The items (ten, in the order of Chapter 16)
| Item | Name | Check | Pass when |
|---|---|---|---|
| T1 | find | From the pack alone: repository, owner, deputy, accountable role, data the tool touches, support path | Nothing had to be asked for |
| T2 | run the tests | On a fresh clone: set up, run the tests and the oracle cases | Tests and oracle cases pass |
| T3 | run the tool | Produce the output on synthetic data, then on the production path in read-only form, through the platform's template or pipeline | Output matches the expected result |
| T4 | change | Make the small requested change; tests pass; the existing oracle cases are unchanged; say in one paragraph what was changed and why | Tests and the oracle case pass |
| T5 | ship | Release the change through the pipeline to the test target and show that it runs there | Run record of the pipeline exists; nothing reached users |
| T6 | revert | Roll the test target back to the previous release using only the rollback note | The previous release is running; the note was enough |
| T7 | switch off | Stop the tool from the runbook alone and show that it is off; show that the manual process still works | The tool is off and the manual process works |
| T8 | restore | Restore the tool from the repository and the secret store to a working state and run it | It runs; the restore test record is current |
| T9 | explain | Without the owner or the assistant, to the oracle owner: what it does, what it never does, where its data goes, what happens when it fails, when it ends | The oracle owner accepts the explanation |
| T10 | secrets | Confirm that the repository holds no secret and say where the tool's secrets live | No secret found; the location is stated |
The result
- [ ] Pass: every item passed.
- [ ] Pass with remarks: no item failed; each remark has an owner and a due date and does not concern a gate item; each is reviewed at the next 90-day confirmation.
- [ ] Fail: at least one item failed. The builder fixes the pack or the tool; the runner retests the failed items, and any item that depends on them, within five working days. A failed item is fixed and re-run, not argued.
- [ ] The takeover-test record
TKT-*is written with the date, each item's result and time, every gap and the overall result. Every gap is also a change to the pack. - [ ] The evidence is valid for twelve months, or until the owner, the receiver or the platform changes, whichever comes first; revert and restore evidence is valid for 90 days (both periods are illustrative; the rule that evidence expires is not).
If the use has outgrown the tier (Tier B to Tier C), check the criteria of AI Developer, Chapter 19, as Chapter 16 applies them. A criterion that was not tested counts as not met.
| Criterion | What must be shown |
|---|---|
| Name | An owner and a deputy are named; the deputy has passed the explain-it-back drill |
| Understand | A one-page data flow and permissions; at least 20 independent test cases written by someone other than the maker, with evidence no older than 90 days |
| Revert | Switch-off tested; manual fallback tested; restore test no older than 90 days |
| Data and access | Data classes recorded; the data protection officer's screening, with an impact assessment if the screening finds high risk; least-privilege roles; no anonymous access |
| Support | A support path is named |
| Sunset | A review every 6 months and an end date |
The unit head decides and records the decision as an AI Decision Record; the platform's pipeline identity performs the promotion. The builder never promotes their own tool.
B.5 The assistant's limits
These limits apply to the builder's assistant at every tier. They are written into the mandate MND-*-BLD-* and the rules file AGENTS.md (Chapters 4 and 7), enforced by the sandbox and the pipeline and not by the assistant's own good conduct, and recorded in a run record RUN-* written by the sandbox host.
| Action class | May the assistant do it? | Highest degree |
|---|---|---|
| Read the repository and the synthetic data | Yes | Level 3 Bounded |
| Read secrets, production data or production configuration | No: it has no access | None |
| Edit files in the repository, on a branch | Yes | Level 3 Bounded |
| Run the test suite and the linters in the sandbox | Yes | Level 3 Bounded |
| Commit | Drafts the message and the change | Level 1 Assisted: the builder reads the diff and commits in own name |
Push to main, trigger the pipeline, promote a release |
No | None: the pipeline identity promotes |
Change AGENTS.md, pipeline.yml, tests/oracle/ or the mandate itself |
May suggest in conversation; never edits | Level 0 Advisory |
| Reach the network, other repositories or other systems | Only what the sandbox provides | As stated in the mandate |
Level 4 Autonomous is never used for a builder's assistant, and in particular never for: a change to production without a gate that the change itself cannot alter; code in a security-critical path without review by a named developer; a change to the assistant's own mandate, permissions, credentials, test oracles or pipeline gates; an irreversible action on production data; or a decision about a named person's employment, pay, performance rating or access to work. Usage Mode 5, autonomous production agents, is not for builders.
Mandate check. A mandate is ready to adopt when it names an owner and an accountable person who is not the assistant; names who can stop it; says what the assistant may read, edit and run and what it may never read or change; states level_4: {used: false}; sets budgets and halting conditions; says who writes the run record (the sandbox host); and has a review date.
B.6 Evidence age
No chapter says that software is secure, tested, backed up or ready without saying what was checked, by whom, when and with what result. A claim on this table is valid until the date below; after that it is treated as not shown.
| Evidence | Artefact | Valid for (Tier C, illustrative) | Earlier if |
|---|---|---|---|
| Intent read and approved | BLD section 1 |
Until the review date set in the record | The purpose, the user or the measure changes |
| Tier decision | BLD section 2 |
Until the review date set in the record | A reclassification signal occurs |
| Tests and oracle | VER, RVW |
90 days | The code, the rules file, a dependency or the assistant changes |
| Security checklist and provenance | PRV |
90 days | The code, a dependency or the assistant changes |
| Rollback rehearsal | CHG |
90 days | The pipeline, the template or the release name format changes |
| Restore test | RST |
90 days | The platform, the secret store or the job configuration changes |
| Ownership confirmation and drill | OWN |
90 days | The owner or deputy leaves; the export or the template changes |
| Takeover test | TKT |
12 months | The owner, the receiver or the platform changes |
| Register entry | BREG |
90 days after the oldest evidence in it | Any evidence in it expires |
B.7 Ordinary prompts for the assistant, step by step
The prompts are ordinary instructions, written to be adapted. Each tells the assistant what it is for (drafting, listing, explaining), what it must not do and what to leave blank. Give the assistant the files it needs and no more. Read what it returns against the artefact it is meant to help with, and never paste a secret, a production value or personal data of others into a prompt. A prompt that asks the assistant to certify its own work (that code is secure, that tests are enough, that a rollback will work) asks for text and not for evidence; the evidence is the artefact in B.1.
Step 1 Intent (Chapter 5)
I want help to write down what I am going to build before I build it.
Act as an interviewer, not as an author.
Ask me one question at a time. Do not propose a solution, a design or any
code. Do not answer your own questions. If I do not know an answer, write
"open question" and move on.
Cover: the problem as it is today, who uses the result, how we will know
it helped (with a number and where it comes from), what finished looks
like, what the build must not do, and who else is affected.
When I say "summarise", write a one-page intent in seven headed parts,
using only what I told you, and list every open question at the end.
Do not fill any gap with a guess.
Step 2 Tier (Chapter 6)
Here are my answers to the five questions of the tier decision, each with
its source. Read them and list every answer that has no source, that
contradicts another answer, or that I may have understated. Do not choose
the tier. Do not tell me the build is safe. Say which of the four stop
signs of Tier D you cannot rule out from what I wrote.
Step 3 Workshop (Chapter 7)
Explain in plain words what each command in this README does and what each
line of .gitignore protects. Do not run anything. Then list every place in
this repository where a setting could be written as a fixed value instead
of being read from an environment variable.
Draft AGENTS.md from the mandate in docs/mandate.yaml. Restate the mandate
in plain sentences; do not widen it. Include the commands to set up, test and
run, where things are, and what the assistant must never edit.
Step 4 Specification (Chapter 8)
Here is the need and my three rules for a tool that compares opening hours.
Do not write any code. List the inputs and situations my rules do not say
what to do with. For each, say which rule it touches. Do not propose answers.
For each rule below, whose behaviour I have now decided, write one example in
the form given, when, then. Use only values I have given. Do not write code
and do not change a rule.
Step 5 Design (Chapter 9)
Here is the specification (docs/specification.yaml) and the list of what the
platform team already supports (docs/platform-supported.md). Propose two
designs that use only what is on that list. For each, say what data it stores,
what it needs permission to do, who in the organisation would maintain it and
what it would cost to stop using it. Then argue against your own first choice.
Do not write any code.
Step 6 Build (Chapter 10)
Slice 1 of docs/specification.yaml: rule R1, opening hours for each weekday
are equal in the portal and in the phone script. Plan only, no code yet.
Say which files you will change, which tests you will add and what you will
not touch. Use only the standard library and PyYAML. Do not change
AGENTS.md, pipeline.yml or anything under tests/oracle/. Do not write to
any source system.
Explain this diff in plain words. Say which files changed, how large the
change is, what was removed, what the change can reach, and whether anything
in it belongs to the domain of the tool and should be checked with someone
who knows the domain. Do not suggest further changes.
Step 7 Prove (Chapter 11)
Here are the acceptance examples of the specification. Draft one test for
each example, from the example only. Do not read the code under test and do
not copy expected values from it. Do not touch tests/oracle/. Say which
failure cases from the specification have no test yet.
This test fails. Explain in plain words what it expects, what the code did
and which of the two the specification supports. Do not change the test, the
oracle or the specification to make it pass.
Step 8 Secure (Chapter 12)
List every package named in requirements.txt and say, for each, what it is
for. Do not install, add or update anything. Say which names you cannot
account for or which look like a misspelling of a well-known package.
Read this file for places where a secret, a token, a claim text or a name
could be written to a log, a file or an error message. List file and line
number. Do not change anything. Do not say that the file is secure.
Draft the provenance record from the run records and the dependency list.
Leave a field blank wherever you have not been shown the result or the date.
Step 9 Ship (Chapter 13)
Draft the changelog entry for the next version from the commits since the
last tag, grouped as Added, Changed and Fixed. Use only what the commits say.
Draft a rollback note for this release using only the commands in
docs/platform-supported.md. Mark every command that you are not sure the
platform accepts, and say whether the note names a release or a tag. I will
follow the note myself before it is accepted.
Step 10 Run (Chapter 14)
Draft a runbook from the README and the specification: what the tool reads
and writes, what to watch, who to call, how to stop it and what to do in the
first hour of a failure. Mark every threshold as a guess unless I give you an
observed figure. Never put export contents, notice or claim text, or names
into the logging section.
Explain this log line in plain words. Say what it tells me and what it does
not. Do not suggest logging more of the data.
Step 11 Own (Chapter 15)
Read this README as a stranger who has never seen the tool. List every
question it leaves unanswered about running, changing, switching off and
restoring the tool, and about who to call. Do not answer the questions
yourself.
Step 12 Hand over (Chapter 16)
Here is the handover pack. Read it as a developer who has never seen the tool
and list every item of a takeover test (find, run the tests, run the tool,
change, ship, revert, switch off, restore, explain, secrets) that could not be
done from the pack alone. For
each, say what is missing. Do not fill the gaps; I will.
Learning with the assistant (Chapter 21)
I will explain this change in my own words before I accept it. Wait for my
explanation, then tell me where it differs from the diff. Do not explain the
change first.
B.8 Tool categories and what each must provide
A build needs the categories below. The organisation provides most of them (the builder workspace, templates and golden paths of Chapter 17) so that the sanctioned route is the easier one. Each row says what the category must provide for the steps to be met; a category that cannot provide it is a reason to ask the platform team, not a reason to skip the step. No product is named.
| Category | Steps | Must provide |
|---|---|---|
| Conversational assistant (Mode 1) | 1, 2, 4, 5 | An organisation-approved service; a written statement of what leaves the organisation's boundary; a rule that no secret, production value or personal data of others is pasted into it |
| Embedded assistant in the editor or building tool (Mode 2) | 3 to 8 | Approval of each change by the builder; visibility of the diff before it is accepted; a configuration the organisation controls; recorded in the build record where it touches the tool's code |
| Agentic work tool in a sandbox (Mode 3) | 6, 7 | A sandbox without production reach; a session identity issued outside the assistant and the repository; enforcement of the mandate (paths it may not edit, hosts it may not reach, budgets, halting); a run record written by the sandbox host |
| Built-in model call at run time (Mode 4) | 5 to 10 | Tier C at least; the platform's AI gateway; every output checked against the specification; never used for a decision about a named person |
| Version control service | 3, 6, 9, 11 | History; branches; a protected main branch that only the pipeline updates; pull requests with a named reviewer; tags; the secret scan before commit |
| Builder workspace and sandbox | 3, 6 | Synthetic data only; no production reach; secrets injected at run time and never in a repository or a prompt; a path for the oracle cases that the assistant's sandbox cannot write |
| Repository and pipeline templates | 3, 9, 12 | The skeletons of the records (BLD, SPC, OWN, RBK, HND), a green smoke test, a pipeline that fails on secrets and on missing files |
| Secret store | 3, 8, 10 | Injection of secrets as environment variables at run time; rotation dates; access limited to the job's identity |
| Test runner and linters | 6, 7 | Tests that run from a fresh clone with one command; a way to run the independent oracle cases through the same runner; static checks |
| Secret scanner and dependency audit | 8, 9 | A scan before commit and in the pipeline; a dependency policy that fails on a name it does not list; a package source the organisation controls |
| Pipeline | 9 | Stages test, scan and deploy; deploy from a tag only; promotion by the pipeline's own identity, never a person and never the assistant; a gate that the change cannot alter; a run record |
| Scheduler or job runner | 9, 10 | Scheduled or on-demand runs from a release and not from a working copy; read-only paths for inputs; a way to suspend, roll back by release name and resume |
| Monitoring and alerting | 10 | An alert evaluated by the platform and not by the job; delivery to a person other than the builder; a way to test the alert by causing the failure on purpose |
| Backup and restore | 10 | A statement of what the platform backs up and what it does not; a way to rebuild from the repository and the configuration alone; a restore-test record |
| Register of builds | 2, 12 | An entry per build with owner, deputy, tier, data classes, evidence and its age, and a review date; discovery of builds that were not declared |
| Documentation and records store | 1, 4, 5, 11 | A place for the records that the archivist and the accessibility specialist have agreed; retention for working material (such as prompts) stated; access requests forwarded to the registry |
| Support channel and ticketing | 10, 12 | A named support path; an owner of the queue; response times stated; a stop path that does not need prior justification |
| Accessibility check | 5, 8 | A way to check the output against the accessibility requirements that apply, by a person qualified to say so |
| Synthetic data | 3, 7 | Data that has the shape of the real data and none of the people; ids that cannot be mistaken for real ids; a rule that the pipeline rejects other files |
Sources
- Nordqvist, G. (2026). AI Developer: How the Developer Role Changes When AI Is Used Broadly in European Enterprises and Public Authorities. The Transformed Architecture, Book 12. (86, Nordqvist, 2026)