> 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/the-twelve-documents.md). # The twelve documents The method has twelve documents, from the customer's own request to the working application. For each document this page says who writes it, what goes in, what comes out, which blank instrument the team uses, where a person decides, how the result is checked and which subtopic teaches it. The sector's catalogue of services, taught in subtopic 2.1, is written once for a whole sector before the first of the twelve, and is not one of them. It has a blank instrument of its own. ![F3. The twelve documents in order, with where the manager stands](https://3194217719-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FrVBocIKfigDPd5E7eF77%2Fuploads%2FrTaZ2ilh5nLpkmz9JNbr%2FF3_twelve-documents-4b243c86.png?alt=media) ## The table of the twelve documents In the column of what goes in, a number is the number of a document in this table. The customer's own documents are kept as received and never edited. The walk-through is produced from the screens, and the working application is generated from the application model; no person writes either, so neither has a blank instrument. | Document | Who writes it | What goes in | What comes out | Blank instrument | Where a person decides | How it is checked | Taught in | | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. The customer's own documents** | The customer | — | The mandate, the law and the requests, kept as received and never edited | None: the customer's own documents are kept as received | The customer, by what it hands over | Everything after is measured against it | [1.1](/experience-digital-transformation/building-block/module-1-why-digital-services-go-wrong-and-the-method-that-prevents-it/1.1-where-an-agreed-service-gets-lost.md), [2.2](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.2-write-down-what-was-asked-before-anyone-designs.md) | | **2. The register of requirements** | An AI assistant extracts it; the analyst rules on each entry | 1 | One entry for each separate thing asked, with where it was said | [The register of requirements](/experience-digital-transformation/building-block/the-blank-instruments/the-register-of-requirements.md) | The analyst accepts, amends or sets aside each entry | Its own checklist; no program | [2.2](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.2-write-down-what-was-asked-before-anyone-designs.md) | | **3. The entity model, with its glossary and its business rules** | The analyst | 1, and the shared groundwork | The records the service keeps, what each means, and whose each fact is | [The entity model, with its glossary and its business rules](/experience-digital-transformation/building-block/the-blank-instruments/the-entity-model-with-its-glossary-and-its-business-rules.md) | The read-back to the business side | Its own checklist; no program | [2.3](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.3-the-records-the-service-keeps-and-whose-each-one-is.md) | | **4. The use case model** | One named architect | 2 and 3 | Every goal named, and each tied to the entries it serves | [The use case model](/experience-digital-transformation/building-block/the-blank-instruments/the-use-case-model.md) | The model's owner at the review | Goals against entries in both directions | [2.4](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.4-every-goal-named-and-each-tied-to-what-was-asked.md) | | **5. The software architecture** | The solution architect | 2, 3 and 4 | What the service is built on, and every flow that crosses its boundary | [The software architecture](/experience-digital-transformation/building-block/the-blank-instruments/the-software-architecture.md) | The architect, with the bodies on the other side of each crossing | Its own checklist; no program | [2.6](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.6-what-the-service-is-built-on-and-what-crosses-its-boundary.md), [5.4](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.4-identity-and-registries-use-the-block-do-not-rebuild-it.md), [5.6](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.6-payments-and-information-mediation-as-named-crossings.md) | | **6. The rest of the shared groundwork** | A person, with an assistant | 3 | The states, settings, code lists and events every goal shares | [The shared groundwork: states, events, code lists and settings](/experience-digital-transformation/building-block/the-blank-instruments/the-shared-groundwork-states-events-code-lists-and-settings.md) | The owner of each setting | Its own checklist; no program | [2.5](/experience-digital-transformation/building-block/module-2-break-the-service-down-before-you-design-it/2.5-what-every-goal-may-use-and-may-not-invent.md), [4.3](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.3-the-service-workflow-states-moves-and-who-may-make-each.md) | | **7. One use case, written out in full, for each goal** | An AI assistant writes it; a person rules on it | 3, 4 and 6 | One goal as a story with every way it can fail | [One use case, written out in full](/experience-digital-transformation/building-block/the-blank-instruments/one-use-case-written-out-in-full.md) | The person who rules on the draft | Its own checklist; no program | [3.1](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.1-one-goal-written-as-a-story-a-builder-can-follow.md), [3.2](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.2-every-way-it-can-go-wrong-written-down.md) | | **8. The screens of that use case** | Whoever wrote the use case, beside it | 7 and 3 | What a person sees at each step, with the source of every value | [The screens of a use case](/experience-digital-transformation/building-block/the-blank-instruments/the-screens-of-a-use-case.md) | The review of three people | Against four lists the use case wrote | [3.3](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.3-screens-worked-out-from-the-story-every-value-with-its-source.md), [3.4](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.4-screens-officers-can-use.md), [3.6](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.6-the-review-three-people-every-open-line-given-a-name.md) | | **9. The walk-through** | Nobody: it is produced from the screens | 8 | Web pages a person clicks through, each carrying its version | None: the walk-through is produced from the screens | The officials who click it, at the review | Produced by a program, never drawn | [3.5](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.5-the-walk-through-your-officials-click.md), [3.6](/experience-digital-transformation/building-block/module-3-design-one-service-as-a-story-your-officials-can-check/3.6-the-review-three-people-every-open-line-given-a-name.md) | | **10. The interaction design** | One analyst writes it; the owner accepts it | 8, 3, 6 and 5 | How officers pick, find, move and act, settled once for the whole application | [The interaction design](/experience-digital-transformation/building-block/the-blank-instruments/the-interaction-design.md) | The owner accepts it before the model is written | Its listings compared with the screens by a program | [4.1](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.1-four-questions-decided-once-for-every-screen.md), [4.2](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.2-no-list-longer-than-nine-choose-by-category.md), [4.3](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.3-the-service-workflow-states-moves-and-who-may-make-each.md) | | **11. The application model** | An AI assistant writes it and must refuse to guess; a person reviews and approves it | 7, 8, 3, 6, 5 and 10 | The one file from which the application is generated | [The review of the application model](/experience-digital-transformation/building-block/the-blank-instruments/the-review-of-the-application-model.md) | The person who approves it, after reading what it assumed and could not express | A program refuses it if it contradicts the accepted interaction design or breaks a platform rule | [4.4](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.4-one-file-a-program-reads-the-application-model.md), [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), [4.6](/experience-digital-transformation/building-block/module-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.6-refused-not-worked-around.md) | | **12. The working application** | Nobody: it is generated | 11 | The running service on the low-code platform | None: the application is generated from the model | The proof on the running system: a person finishes a real task | Read back against the model; acceptance journeys on the running service | [5.1](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.1-from-one-file-to-a-running-application.md), [5.2](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.2-nothing-generated-is-edited-by-hand.md), [5.3](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.3-the-platforms-traps-caught-before-deployment.md), [5.7](/experience-digital-transformation/building-block/module-5-generate-the-service-on-a-low-code-platform-and-connect-the-blocks/5.7-proof-on-the-running-system-a-task-a-person-finishes.md) | Subtopic 1.4 teaches the table as a whole. Subtopic 6.1 teaches how to name the twelve documents as deliverables in a contract, each accepted by a named person. --- # 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/the-twelve-documents.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.