> 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-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.6-refused-not-worked-around.md). # 4.6 Refused, not worked around A program refuses a description that contradicts what you accepted, and nobody switches the check off. {% embed url="" %} Refused, not worked around (\~5 min) {% endembed %} **Watch first (\~5 min).** Then read on: the page carries what the video says, and the AI usage tip. > **Single message.** A program refuses a description that contradicts what you accepted, and nobody switches the check off. ## The concept Two days before a deadline, a program stops your supplier's build. The supplier asks for one favour: switch the check off, just this once. Your answer should already be written down, and it is no. Before anything is generated, built or installed, a program reads the file the application will be generated from, and asks four questions. Does the file name the interaction design you accepted? Does that document say it was accepted, by a name, on a date? Is it the same document, unchanged since it was accepted? And does every list, every search, every move and every act in the file match what the document decided? If any answer is no, the program refuses, and nothing is built. Nothing switches this check off. There is no setting, no switch, and no exception for a deadline. The check also cannot know that you accepted the document. It knows only that the document says so, and that the file agrees with it. That makes your acceptance line evidence. Write it exactly, with the name and the date, and never write it for a document nobody has read. A deadline does not change what was agreed; it changes only how soon the correction is needed. A refusal is answered, not worked around. There are two honest answers. Either the file is corrected to match what you accepted. Or, if the decision itself should change, the owner accepts a revised interaction design, and the file names that new version. Both leave a record of who decided what. Switching the check off leaves no record, and the same fault returns at the next build. Here is how it looks for MoEYS, Progressa's ministry of education. The interaction design its director accepted says that the twenty matters PHEQA advises on are chosen in three categories, of eight, seven and five. A version of the file offers the officer all twenty in one list. The program refuses it before anything is built. The refusal names the document and the row it disagrees with, the row for that list, so the supplier knows exactly what to correct, and nobody has to guess. The correction is small. The list in the file is given the three categories the document decided, and the program reads the file again. This time it is admitted, and generation may begin. That is the whole demonstration: one run refused with the row named, one run admitted after the correction. Until it is recorded on a real application, this is a storyboard: the steps and what counts as a pass, written before anything is run. ![F12. From one file to a running application, with the refusal before it](https://3194217719-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FrVBocIKfigDPd5E7eF77%2Fuploads%2FhcYaKlFbHMdvUwJtEc3o%2FF12_one-file-to-running-application-cec782e0.png?alt=media) {% hint style="success" %} **The worked example of this subtopic** is [E4-6](/experience-digital-transformation/building-block/the-worked-examples/e4.6-refused-not-worked-around.md), built for Progressa. {% endhint %} {% hint style="info" %} **Demonstration.** A model that contradicts the accepted interaction design is refused, corrected and admitted. It needs The ministry's application model and its accepted interaction design. Until it is recorded, the storyboard in the script stands in its place. {% endhint %} ## Your turn โ€” Explain a refusal in plain words {% hint style="success" %} **๐Ÿ’ก AI usage tip** ยท Explain a refusal in plain words **Bring:** The refusal message as printed, and the row of the accepted document it names. **Get:** A plain explanation of the refusal, naming the document to correct. **Time:** \~10โ€“15 min ยท **Assistant:** any; the tips are tool-neutral. **With the kit:** `application-model` โ€” helps the team write the one file a program reads, and the review of what it assumed and could not express. 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 prompt explains; it does not decide and does not propose a way round the check. {% endhint %} **The problem it solves.** The program has refused the file the application is generated from, and its message is written for builders. The manager needs to know, in plain words, what disagrees with what was accepted and which document must change, so that the refusal is answered and not argued about. {% 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 refusal message a program gave when it checked the application model of [the service] in [your ministry], exactly as printed [paste the message]. Below that is the row of the accepted interaction design that the message names [paste the row]. Explain in plain words: (1) what the file says; (2) what the accepted document decided; (3) why the two disagree. Then name the document to correct: the application model, if the file should follow the accepted decision; or the interaction design, if the decision itself should change, in which case say that its owner must accept it again before the check is run again. Do not suggest any way to skip, switch off or get round the check, and do not suggest editing anything the program generated. Output: a plain explanation of the refusal, naming the document to correct, in no more than half a page. ``` [Open in Claude](https://claude.ai/new?q=Below%20is%20the%20refusal%20message%20a%20program%20gave%20when%20it%20checked%20the%20application%20model%20of%20%5Bthe%20service%5D%20in%20%5Byour%20ministry%5D%2C%20exactly%20as%20printed%20%5Bpaste%20the%20message%5D.%20Below%20that%20is%20the%20row%20of%20the%20accepted%20interaction%20design%20that%20the%20message%20names%20%5Bpaste%20the%20row%5D.%20Explain%20in%20plain%20words%3A%20%281%29%20what%20the%20file%20says%3B%20%282%29%20what%20the%20accepted%20document%20decided%3B%20%283%29%20why%20the%20two%20disagree.%20Then%20name%20the%20document%20to%20correct%3A%20the%20application%20model%2C%20if%20the%20file%20should%20follow%20the%20accepted%20decision%3B%20or%20the%20interaction%20design%2C%20if%20the%20decision%20itself%20should%20change%2C%20in%20which%20case%20say%20that%20its%20owner%20must%20accept%20it%20again%20before%20the%20check%20is%20run%20again.%20Do%20not%20suggest%20any%20way%20to%20skip%2C%20switch%20off%20or%20get%20round%20the%20check%2C%20and%20do%20not%20suggest%20editing%20anything%20the%20program%20generated.%20Output%3A%20a%20plain%20explanation%20of%20the%20refusal%2C%20naming%20the%20document%20to%20correct%2C%20in%20no%20more%20than%20half%20a%20page.) *(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]:** MoEYS's application. **\[your ministry]:** MoEYS, Progressa's ministry of education, youth and skills. **\[paste the message]:** ``` REFUSED. Interaction design ID-MOEYS v1.0, accepted by the Director of Higher Education, 15 January 2027. Row PICK-07 "The matters PHEQA advises on": expected 3 categories (8, 7, 5). Application model v0.4: one list of 20 values, no categories. Nothing generated. ``` **\[paste the row]:** PICK-07 โ€” The matters PHEQA advises on. 20 values, kept by PHEQA. Chosen in two steps: first the category (Licences, 8; Suspension and cancellation, 7; Other matters, 5), then the matter. {% 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 %} **What the file says.** Version 0.4 of the application model offers the officer all twenty matters PHEQA advises on in a single list, with no categories. **What the accepted document decided.** The interaction design, accepted by the Director of Higher Education on 15 January 2027, says the officer picks a category first (Licences, Suspension and cancellation, or Other matters) and then one of the eight, seven or five matters in it. **Why they disagree.** One list of twenty breaks the rule that no step offers more than nine values, and it is not what the director accepted for this list. **The document to correct.** The application model. The decision is clear and was accepted, so the file should follow it: give the list the three categories of row PICK-07 and run the check again. If the director now wants a single list, the interaction design must be changed and accepted again by her before the check is run. *If the deadline is tight, the supplier could generate the application now and add the category filter on the platform afterwards.* {% 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. The right document, named plainly The run read the row and the message together and named the application model as the document to correct. It kept the other honest answer, a revised decision accepted again, without recommending it.
2. The last line is a way round: discard it Generating now and adding the filter on the platform afterwards is two things the prompt forbade: getting round the check, and editing what the program generated. It would also leave no record of the fault, which would return at the next build. Strike the line out before the explanation goes to anyone.
3. The date comes from the message only "15 January 2027" is in the refusal, so the run could repeat it. It did not check that the version named is still the one accepted. The program checks that; the reading should not claim more.
{% hint style="danger" %} **Safeguard.** The prompt explains; it does not decide and does not propose a way round the check. If its answer contains one, discard it. The correction is made in the document the refusal names, and a changed decision is accepted again by its owner before the check is run again. {% endhint %} {% endtab %} {% tab title="What next" %} When the corrected file is admitted, the application is generated from it in [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). Why nothing generated is ever corrected by hand is in [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). {% 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-4-settle-the-whole-application-once-then-describe-it-for-the-machine/4.6-refused-not-worked-around.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.