> 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-worked-examples/e4.6-refused-not-worked-around.md).

# E4.6 — Refused, not worked around

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.

**Subtopic:** 4.6 — Refused, not worked around

**Public anchor:** None: the content is the SDD method's own (the check before generation)

**Simulated case:** This is a simulated case for Progressa, a fictional country; every institution, name, date and figure in it is invented.

**What it shows.** The slides of the script of 4.6 that carry Progressa's example: 'MoEYS: one list of twenty, refused'; 'Corrected, and admitted'.

**Form of this example.** Taken as it stands from the script of 4.6 in the script bundle of module 4: the slides that carry Progressa's example, each with what the slide shows and what the narrator says over it. The method's step names no country; the example is filled for Progressa.

## MoEYS: one list of twenty, refused

> *Slide 5 — Title: 'MoEYS: one list of twenty, refused'. Body, four text rows: 'Accepted: the matters PHEQA advises on are chosen in three categories, of 8, 7 and 5.' 'The file: one list of twenty matters, no categories.' 'The program: refused. It names the interaction design and the row for that list.' 'Nothing is generated.'*

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.

## Corrected, and admitted

> *Slide 6 — Title: 'Corrected, and admitted'. Demonstration segment, storyboard until recorded (section 4.8): the check run on the version with one list of twenty, the refusal with the row named, the file corrected, and the check run again. Text-only stand-in until the recording exists: 'First run: refused — the row for the matters PHEQA advises on.' 'Correction: the three categories, as accepted.' 'Second run: admitted.'*

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.

**What to look for before you accept it.** When the program refuses, do not ask who can switch it off. Ask which row it names, then correct the file or accept a revised decision.


---

# 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-worked-examples/e4.6-refused-not-worked-around.md?ask=<question>&goal=<user_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.