> 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-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). # 5.7 Proof on the running system: a task a person finishes The last check is a person finishing a real task on the running service, and the record that they did. {% embed url="" %} Proof on the running system: a task a person finishes (\~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 last check is a person finishing a real task on the running service, and the record that they did. ## The concept Every document is accepted, every check reports a pass, and the application is installed. One question is still open: can an officer finish a real task on it? Only a person on the running service can answer, and the answer must be recorded. Most checks in the SDD method read documents. They compare a screen with its story, or the model with the interaction design. Those checks are needed, and they say nothing about whether the service works for the person at the counter. A pass on a document is not a working counter. So the method's third rule is that at least one check ends on the running system. A person goes through a real task on the installed application, and the run is recorded. That check is written as a journey. A journey starts where an officer really starts: at a menu entry, signed in with a real role. It goes through the real screens, step by step, as the goal's story says. And it states exactly what counts as finished. A program can drive a journey through the screens, but the journey is written from the story your officials agreed, not from the screens the supplier built. The same journey is a story the business side recognises and a test the builder can run. In Progressa the journey is the approval of a change of an institution's name. A test officer of MoEYS signs in with the minister's role. In the category Names, the list and reviews, she opens the list of advices that await a decision, and chooses the one on Harbourview University College. She reads PHEQA's advice, and the college as PHEQA's register shows it. She approves the new name. The journey is finished when the approval is recorded and sent to PHEQA. The record of the run is the evidence of acceptance. It names the journey, the installation it ran on and the time, with the result of each step. A journey that was written and never run is reported as not run, never as passed. A journey that stopped at step three is reported as stopped at step three. The minister signs on records of what happened, not on descriptions of what should. Keep each record with the acceptance file. The demonstration shows this journey on MoEYS's running application, with the record of the run beside it. It passes when the journey ends on the recorded approval, and the record names the journey, the installation and the time. Until MoEYS's application is generated, this is a storyboard: written now, and recorded when the application runs. {% hint style="success" %} **The worked example of this subtopic** is [E5-7](/experience-digital-transformation/building-block/the-worked-examples/e5.7-proof-on-the-running-system-a-task-a-person-finishes.md), built for Progressa. {% endhint %} {% hint style="info" %} **Demonstration.** An officer finishes the change-of-name goal on the running application, with the record of the run. It needs The ministry's generated application. Until it is recorded, the storyboard in the script stands in its place. {% endhint %} ## Your turn — Write acceptance journeys for officers from the goals' stories {% hint style="success" %} **💡 AI usage tip** · Write acceptance journeys for officers from the goals' stories **Bring:** The goals' stories, and the roles and menu categories of the application. **Get:** One acceptance journey for each goal, each with its start, its steps and what counts as finished. **Time:** \~10–15 min · **Assistant:** any; the tips are tool-neutral. **Watch for:** A journey is accepted only when a person has finished it on the running service; a journey written and not run is reported as not run. {% endhint %} **The problem it solves.** Acceptance tests are often written from the screens the supplier built. They should come from the stories the officials agreed, so that each one tests a real task from its real start to its real finish. {% 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 are the stories of the goals of a service in [your administration], each with its main steps as the officials agreed them [paste them]. Below that are the roles of the application and the menu categories each role sees [paste them]. For each goal, write one acceptance journey for an officer: (1) the role to sign in with; (2) where it starts: the menu category and the entry; (3) the steps, one for each screen, each with what the officer does and sees; (4) what counts as finished, in one sentence; (5) a line 'Run: not yet', to be filled with the installation, the time and the result when a person runs it. Use only the steps in the stories; mark a step the stories do not settle as 'to settle'. Output: one acceptance journey for each goal, each with its start, its steps and what counts as finished. ``` [Open in Claude](https://claude.ai/new?q=Below%20are%20the%20stories%20of%20the%20goals%20of%20a%20service%20in%20%5Byour%20administration%5D%2C%20each%20with%20its%20main%20steps%20as%20the%20officials%20agreed%20them%20%5Bpaste%20them%5D.%20Below%20that%20are%20the%20roles%20of%20the%20application%20and%20the%20menu%20categories%20each%20role%20sees%20%5Bpaste%20them%5D.%20For%20each%20goal%2C%20write%20one%20acceptance%20journey%20for%20an%20officer%3A%20%281%29%20the%20role%20to%20sign%20in%20with%3B%20%282%29%20where%20it%20starts%3A%20the%20menu%20category%20and%20the%20entry%3B%20%283%29%20the%20steps%2C%20one%20for%20each%20screen%2C%20each%20with%20what%20the%20officer%20does%20and%20sees%3B%20%284%29%20what%20counts%20as%20finished%2C%20in%20one%20sentence%3B%20%285%29%20a%20line%20%27Run%3A%20not%20yet%27%2C%20to%20be%20filled%20with%20the%20installation%2C%20the%20time%20and%20the%20result%20when%20a%20person%20runs%20it.%20Use%20only%20the%20steps%20in%20the%20stories%3B%20mark%20a%20step%20the%20stories%20do%20not%20settle%20as%20%27to%20settle%27.%20Output%3A%20one%20acceptance%20journey%20for%20each%20goal%2C%20each%20with%20its%20start%2C%20its%20steps%20and%20what%20counts%20as%20finished.) *(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: **\[your administration]:** MoEYS, Progressa's ministry of education. **\[paste them]:** Two stories, as the officials agreed them: * **G-12 Approve a change of an institution's name.** The minister opens the list of PHEQA's advices on a change of name that await a decision. She chooses one. She reads PHEQA's advice and the institution as PHEQA's register shows it. She approves or does not approve. The decision is recorded and sent to PHEQA. * **G-13 Publish the list of registered institutions in the Gazette.** The minister opens the list for publication, read from PHEQA's register. She approves it for publication. The Gazette officer records the Gazette entry. **\[paste them]:** The minister: Licences; Names, the list and reviews; Suspension and cancellation; The Gazette; Requests for review. The Gazette officer: The Gazette. {% 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 %} **Journey 1 — G-12 Approve a change of name** 1. Role: the minister. 2. Start: Names, the list and reviews › Advices on a change of name. 3. Steps: (a) the list shows the advices awaiting a decision; she chooses the one on Harbourview University College. (b) The screen shows PHEQA's advice and INS-00217 as the register shows it. (c) She chooses "approve" and records it. 4. Finished when: the approval is recorded and sent to PHEQA. 5. Run: not yet. Expected to pass, as the screens follow the story. **Journey 2 — G-13 Publish the list in the Gazette** 1. Role: the minister, then the Gazette officer. 2. Start: The Gazette › List for publication. 3. Steps: (a) the minister opens the list, read from PHEQA's register. (b) She approves it for publication. (c) The Gazette officer signs in, downloads the approved list as a PDF and sends it to the Gazette. (d) She records the Gazette entry: number and date of issue. 4. Finished when: the Gazette entry is recorded against the approved list. 5. Run: not yet. {% 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. Journey 1 follows the story Every step of journey 1 is a step of the agreed story, with the start written as a menu category and an entry. It is the journey of this subtopic's worked example, and an officer could run it as written.
2. "Expected to pass" is not a run Journey 1 adds a forecast to its run line. The safeguard says the line stays "Run: not yet" until the record of a real run replaces it, with the installation, the time and the result. Strike the forecast; a journey written and not run is reported as not run.
3. Step 2(c) is not in the story The story says only that the Gazette officer records the entry. How the list reaches the Gazette, and in what form, was never agreed; the assistant filled it in. Mark step 2(c) "to settle", and the number and date of issue in 2(d) with it, and ask the Director of Higher Education.
{% hint style="danger" %} **Safeguard.** A journey is accepted only when a person has finished it on the running service; a journey written and not run is reported as not run. Keep the line 'Run: not yet' until the record of a real run replaces it. {% endhint %} {% endtab %} {% tab title="What next" %} Run journey 1 on MoEYS's installation once its application is generated, and keep the record of the run as the [worked example](/experience-digital-transformation/building-block/the-worked-examples/e5.7-proof-on-the-running-system-a-task-a-person-finishes.md) describes. Records of runs are part of what to require from a supplier 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). {% 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-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?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.