> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it/1.5-who-writes-who-checks-who-accepts.md). # 1.5 Who writes, who checks, who accepts The AI assistant may draft; a named person accepts, amends or sets aside each proposal, and only what was accepted stands. {% embed url="" %} Who writes, who checks, who accepts (\~5 min) {% endembed %} **Watch first (\~5 min).** Then read on: the page carries what the video says, and the AI usage tip. > **Single message.** The AI assistant may draft; a named person accepts, amends or sets aside each proposal, and only what was accepted stands. ## The concept An AI assistant can draft a register of requirements in an afternoon. That is real help. It also raises a question your minister will ask: if a machine wrote it, who is answerable for it? The SDD method's answer is simple. An AI assistant may draft any document a person would otherwise draft. It proposes; it never decides. A named person rules on each thing it proposes, and says one of three words: accepted, amended or set aside. The document then holds only what that person accepted, in that person's words. A draft is never accepted because it reads well. It is accepted line by line, by somebody whose name is on it, and who can be asked about it later. Inventing something plausible is the thing an assistant does best. So the method binds it with one rule: a gap is recorded as a question with an owner, and never filled with an invented answer. When an official's text is silent, the assistant does not guess a figure to keep the work moving. It writes the question down, and a person decides who must answer it and by when. Every invented answer it avoids is one less fault hidden in the service. For each of the twelve documents, three roles are named. Someone writes it. Someone else checks it. And a named person accepts it. In PHEQA's project in Progressa, the supplier's analyst and an AI assistant write. A second analyst of the supplier checks. The Registrar of PHEQA accepts, or the head of PHEQA's ICT unit for the technical documents. And the head of the registration desk sits at every review of something an officer will use. In four of PHEQA's documents, an AI assistant does the writing. It extracts the register of what was asked. It helps write the shared settings and lists. It drafts each goal as a story. And it writes the application model, the file a program reads, under the rule that it must refuse to guess. In each of the four, a named person rules on what it wrote, and a different named person accepts it: the Registrar, the owner of each setting, or the head of the ICT unit. Ask your supplier for this table before the first document is written, and check three things. No row ends with the assistant. In no row does the writer accept alone: where a writer sits at a review, as the owner of the screens does, two other people must agree. And at every review of something an officer will use, the person who will live with the result sits beside the owner and the builder. If a cell under 'accepts' names the supplier, or names nobody, that decision has not been given to anyone in your organisation. ![F4. Who writes, who checks, who accepts](https://3194217719-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FrVBocIKfigDPd5E7eF77%2Fuploads%2FDYRvIxYJytSuY9WLcgEe%2FF4_who-writes-checks-accepts-1f23ab37.png?alt=media) {% hint style="success" %} **The worked example of this subtopic** is [E1-5](/experience-digital-transformation/building-block/the-worked-examples/e1.5-who-writes-checks-and-accepts-each-document-of-pheqas-registration-project.md), built for Progressa. {% endhint %} ## Your turn โ€” Draft who writes, checks and accepts each document {% hint style="success" %} **๐Ÿ’ก AI usage tip** ยท Draft who writes, checks and accepts each document **Bring:** The team's list of roles, with the body each role belongs to. **Get:** A table of who writes, checks and accepts each of the twelve documents for your project team, with the cells where no role is named marked. **Time:** \~10โ€“15 min ยท **Assistant:** any; the tips are tool-neutral. **With the kit:** `sdd-specify` โ€” helps the team write the specification as a whole: the twelve documents, their order, the handovers, the claim of conformance, and what a change made stale. Optional: the tip runs bare; see [the kit](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here/the-ea-plays-kit). **Watch for:** The people named in the table are proposals until the head of the unit confirms them. {% endhint %} **The problem it solves.** A project team knows its roles but has never written down, document by document, who writes, who checks and who accepts. Until it does, an AI assistant's draft can slip into the record with nobody answerable for it. {% tabs %} {% tab title="Prompt" %} Copy the prompt, replace the bracketed parts with your own context, and run it in the AI assistant of your choice. Never paste personal data or unpublished documents โ€” see [How to use the plays](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-enterprise-architecture-gea/developing-a-gov-enterprise-architecture-gea/start-here/how-to-use-the-plays). ``` Below is the list of roles in the team that will commission and build [the service] for [the ministry or agency], with the body each role belongs to: our own staff, the supplier, or another body [paste the list]. For each of these twelve documents, propose who writes it, who checks it, who accepts it, and who sits at its review: (1) our own documents; (2) the register of what was asked; (3) the records the service keeps; (4) every goal, each tied to what was asked; (5) the architecture; (6) the shared states, settings and code lists (fixed lists of choices); (7) one goal written as a story; (8) the screens of that goal; (9) the walk-through; (10) the interaction design; (11) the application model; (12) the working application. Where an AI assistant writes, name the person who rules on its draft. Follow three rules: the writer never accepts alone; the AI assistant never accepts; and the official who will use the result sits at every review of something an officer will use. Use only the roles in the list; where no role fits, write 'no role named'. Output: a table with one row per document and four columns, then a list of the cells marked 'no role named'. ``` [Open in Claude](https://claude.ai/new?q=Below%20is%20the%20list%20of%20roles%20in%20the%20team%20that%20will%20commission%20and%20build%20%5Bthe%20service%5D%20for%20%5Bthe%20ministry%20or%20agency%5D%2C%20with%20the%20body%20each%20role%20belongs%20to%3A%20our%20own%20staff%2C%20the%20supplier%2C%20or%20another%20body%20%5Bpaste%20the%20list%5D.%20For%20each%20of%20these%20twelve%20documents%2C%20propose%20who%20writes%20it%2C%20who%20checks%20it%2C%20who%20accepts%20it%2C%20and%20who%20sits%20at%20its%20review%3A%20%281%29%20our%20own%20documents%3B%20%282%29%20the%20register%20of%20what%20was%20asked%3B%20%283%29%20the%20records%20the%20service%20keeps%3B%20%284%29%20every%20goal%2C%20each%20tied%20to%20what%20was%20asked%3B%20%285%29%20the%20architecture%3B%20%286%29%20the%20shared%20states%2C%20settings%20and%20code%20lists%20%28fixed%20lists%20of%20choices%29%3B%20%287%29%20one%20goal%20written%20as%20a%20story%3B%20%288%29%20the%20screens%20of%20that%20goal%3B%20%289%29%20the%20walk-through%3B%20%2810%29%20the%20interaction%20design%3B%20%2811%29%20the%20application%20model%3B%20%2812%29%20the%20working%20application.%20Where%20an%20AI%20assistant%20writes%2C%20name%20the%20person%20who%20rules%20on%20its%20draft.%20Follow%20three%20rules%3A%20the%20writer%20never%20accepts%20alone%3B%20the%20AI%20assistant%20never%20accepts%3B%20and%20the%20official%20who%20will%20use%20the%20result%20sits%20at%20every%20review%20of%20something%20an%20officer%20will%20use.%20Use%20only%20the%20roles%20in%20the%20list%3B%20where%20no%20role%20fits%2C%20write%20%27no%20role%20named%27.%20Output%3A%20a%20table%20with%20one%20row%20per%20document%20and%20four%20columns%2C%20then%20a%20list%20of%20the%20cells%20marked%20%27no%20role%20named%27.) *(pre-fills the prompt in a new chat; check the bracketed parts before sending)* *What to bring and what you get are in the box above.* {% endtab %} {% tab title="Example input" %} {% hint style="warning" %} **Draft worked example, 2026-10-05.** Progressa is the fictional country used across these courses. The input below and the output in the next tab were written for this page to show a typical run of the prompt; they are simplified, and they have not been checked as the worked examples of the method have. {% endhint %} The bracketed parts of the prompt were replaced with the following: **\[the service]:** the registration and licensing of private institutions. **\[the ministry or agency]:** PHEQA, the Progressa Higher Education Quality Authority. **\[paste the list]:** the team's roles, with the body each belongs to. * Our own staff: the Registrar of PHEQA; the head of the registration desk; the finance officer; the head of the ICT unit of PHEQA. * The supplier: the supplier's analyst; a second analyst; the solution architect; the builder; the supplier's lead. * Another body: the head of the ICT unit of MoEYS. {% endtab %} {% tab title="Example output" %} {% hint style="warning" %} **Draft: model output, shortened and unverified.** Read it with the notes in the next tab, not on its own. {% endhint %} | # | Document | Writes | Checks | Accepts | Sits at the review | | -- | ----------------------------------- | --------------------------------- | ------------------- | ------------------------------------------------------------------------ | ----------------------------- | | 1 | Our own documents | Our own staff | No role named | The Registrar | โ€” | | 2 | The register of what was asked | AI assistant; the analyst rules | Second analyst | The Registrar | Head of the registration desk | | 3 | The records | The analyst | Second analyst | The Registrar | Head of the registration desk | | 4 | Every goal | The solution architect | Second analyst | The Registrar | Head of the registration desk | | 5 | The architecture | The solution architect | No role named | Head of the ICT unit of PHEQA, with the head of the ICT unit of MoEYS | โ€” | | 6 | Shared states, settings, code lists | The analyst, with an AI assistant | Second analyst | The finance officer (fee); the Registrar (lists) | โ€” | | 7 | One goal as a story | AI assistant; the analyst rules | Second analyst | The Registrar | Head of the registration desk | | 8 | The screens | The analyst | Second analyst | Review of the analyst, the builder and the head of the registration desk | Head of the registration desk | | 9 | The walk-through | Produced from the screens | The builder | Clicked at the review of the screens | Head of the registration desk | | 10 | The interaction design | The analyst | Second analyst | The Registrar | Head of the registration desk | | 11 | The application model | AI assistant | The supplier's lead | AI assistant, once a program confirms it is valid | โ€” | | 12 | The working application | Generated | The builder | The Registrar, after a registration officer finishes a real task | Head of the registration desk | **Cells marked "no role named":** row 1, checks; row 5, checks. No document has the AI assistant as its acceptor. {% endtab %} {% tab title="Reading the output" %} This is the teaching part of the tip. Work through the output the way a chief architect would: what is earned, what is invented, what is missing.
1. Most rows follow the three rules The writer never accepts alone: in row 8 the analyst who wrote the screens accepts only with the builder and the head of the registration desk. The head of the desk sits at every review of something an officer will use. And the gaps are marked, not filled: only one architect is in the list, so nobody can check the architecture.
2. Row 11 breaks the rule the summary says it keeps The application model is written by the assistant and "accepted" by the assistant once a program says the file is valid. A program's check is a check, not an acceptance, and nobody in PHEQA says yes. Yet the line under the table states that no document has the assistant as its acceptor.
3. The safeguard catches it The safeguard says to check, before the table is used, that no document is left with the AI assistant as its acceptor. Read row by row, not from the summary, row 11 fails. It goes to the head of the ICT unit of PHEQA, who approves the model after reading what it assumed and could not express.
4. Row 12 names a role the list does not hold "A registration officer" is not in the pasted list, yet it appears in row 12. It is the right person, but the prompt said to use only the listed roles. Add the role to the list, and let the head of the unit confirm it with the rest.
{% hint style="danger" %} **Safeguard.** The people named in the table are proposals until the head of the unit confirms them. Before the table is used, check that no document is left with the AI assistant as its acceptor. {% endhint %} {% endtab %} {% tab title="What next" %} Once the head of the unit has confirmed the names, compare the table with the [worked example](/experience-digital-transformation/building-block/the-worked-examples/e1.5-who-writes-checks-and-accepts-each-document-of-pheqas-registration-project.md), and write it into the contract as taught in [6.1](/experience-digital-transformation/building-block/module-6-run-the-method-in-your-administration/6.1-what-to-require-from-a-supplier.md). How the person who approves the model reads it is taught in [4.5](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.5-reviewing-the-model-what-it-assumed-and-what-it-could-not-express.md). {% endtab %} {% endtabs %} ## Sources This subtopic cites no public source. Its content is the specification-driven method itself, described at the level of the manager. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it/1.5-who-writes-who-checks-who-accepts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.