> 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.2-nothing-generated-is-edited-by-hand.md). # 5.2 Nothing generated is edited by hand A correction goes into the description and the application is generated again; a program shows any hand edit. {% embed url="" %} Nothing generated is edited by hand (\~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 correction goes into the description and the application is generated again; a program shows any hand edit. ## The concept The evening before the minister's demonstration, someone notices a wrong label on a form. The quickest fix is to change it on the platform. That fix is the one your contract should forbid, and a program can show whether it was made. A hand edit creates two versions of the truth. The accepted description says one thing, and the platform now shows another. When the application is next generated from the description, one of two things happens. Either the edit is overwritten and the wrong label comes back. Or someone protects the edit by not generating again, and from then on nobody can say what the application is built from. The SDD method has one rule for this: nothing generated is edited by hand. A correction goes into the description that owns the fact, is accepted there, and the application is generated again. A label belongs to the screens of its goal, so it is corrected in those screens, carried into the model, and generated. It takes a little longer than a change on the platform. In exchange, the description and the platform never disagree. The method gives you a program to check this, the read-back. It compares each generated file on the platform with what the description would generate, and marks it in one of three ways: in step, out of date, or edited by hand. You do not need to read the files themselves. You read the program's list, and you ask about every line that is not in step. In Progressa, a builder changes a label on MoEYS's form for approving an institution's new name, directly on the platform, to meet the demonstration. The read-back lists that form as edited by hand. The head of MoEYS's ICT unit asks for the change to be made properly. The label is corrected in the goal's screens and in the model, the application is generated again, and the read-back is run once more. It passes only when every file shows in step. The demonstration shows the same steps on a generated application. A label is changed by hand on the platform, the read-back runs and names the form, the correction is made in the model, and the read-back runs again. It passes when the first run names the edited file and the second shows every file in step. Until the application is generated, this is a storyboard. Put the rule into the supplier's contract, together with its evidence. No generated file may be edited by hand on the platform. The read-back is run before every acceptance, and its list is handed over with the delivery. A file marked as edited by hand is a defect, and it is corrected in the description, not argued about at the acceptance meeting. ![F13. Correct up, generate down](https://3194217719-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FrVBocIKfigDPd5E7eF77%2Fuploads%2FO6kyf0Tevv9GtGQCHBvC%2FF13_correct-up-generate-down-a80b1ff8.png?alt=media) {% hint style="success" %} **The worked example of this subtopic** is [E5-2](/experience-digital-transformation/building-block/the-worked-examples/e5.2-nothing-generated-is-edited-by-hand.md), built for Progressa. {% endhint %} {% hint style="info" %} **Demonstration.** A hand edit shown up by the read-back, corrected in the model and generated again. It needs A generated application. Until it is recorded, the storyboard in the script stands in its place. {% endhint %} ## Your turn โ€” Draft the contract clause that forbids hand edits {% hint style="success" %} **๐Ÿ’ก AI usage tip** ยท Draft the contract clause that forbids hand edits **Bring:** The contract's section on changes, and a description of the generation and the read-back. **Get:** One contract clause of four numbered parts, with the undefined terms listed after it. **Time:** \~10โ€“15 min ยท **Assistant:** any; the tips are tool-neutral. **Watch for:** The clause is a draft. {% endhint %} **The problem it solves.** A ministry's contract with a supplier often says nothing about who may change a generated application, or how a change is proven. The manager needs a clause that forbids hand edits and names the evidence. {% 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 section of a supplier contract in [your administration] that covers changes to the delivered application [paste it]. Below that is a short description of how the application is generated from an accepted description, and checked by a read-back program that marks each generated file as in step, out of date or edited by hand [paste or adapt the description]. Draft one clause that: (1) forbids any hand edit of a generated file on the platform; (2) requires every correction to be made in the accepted description and the application to be generated again; (3) names the read-back's list, run before each acceptance, as the evidence; (4) states what follows when a file is marked as edited by hand. Keep the language plain and short. Mark every term that the pasted contract does not define. Output: one contract clause of four numbered parts, with the undefined terms listed after it. ``` [Open in Claude](https://claude.ai/new?q=Below%20is%20the%20section%20of%20a%20supplier%20contract%20in%20%5Byour%20administration%5D%20that%20covers%20changes%20to%20the%20delivered%20application%20%5Bpaste%20it%5D.%20Below%20that%20is%20a%20short%20description%20of%20how%20the%20application%20is%20generated%20from%20an%20accepted%20description%2C%20and%20checked%20by%20a%20read-back%20program%20that%20marks%20each%20generated%20file%20as%20in%20step%2C%20out%20of%20date%20or%20edited%20by%20hand%20%5Bpaste%20or%20adapt%20the%20description%5D.%20Draft%20one%20clause%20that%3A%20%281%29%20forbids%20any%20hand%20edit%20of%20a%20generated%20file%20on%20the%20platform%3B%20%282%29%20requires%20every%20correction%20to%20be%20made%20in%20the%20accepted%20description%20and%20the%20application%20to%20be%20generated%20again%3B%20%283%29%20names%20the%20read-back%27s%20list%2C%20run%20before%20each%20acceptance%2C%20as%20the%20evidence%3B%20%284%29%20states%20what%20follows%20when%20a%20file%20is%20marked%20as%20edited%20by%20hand.%20Keep%20the%20language%20plain%20and%20short.%20Mark%20every%20term%20that%20the%20pasted%20contract%20does%20not%20define.%20Output%3A%20one%20contract%20clause%20of%20four%20numbered%20parts%2C%20with%20the%20undefined%20terms%20listed%20after%20it.) *(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]:** PHEQA, Progressa's quality authority. **\[paste it]:** Clause 9 of PHEQA's contract with the supplier, as it stands: > 9.1 The Supplier shall make changes to the Application only on a written Change Request approved by the Registrar. 9.2 Each change is accepted by PHEQA under clause 7 (Acceptance). 9.3 The Supplier shall correct any Defect notified by PHEQA within ten working days. **\[paste or adapt the description]:** The application is generated by a program from the application model, which is drawn from documents PHEQA has accepted. A correction is made in the document that owns the fact, carried into the model, and the application is generated again. A read-back program compares each generated file on the platform with what the model would generate, and marks it in step, out of date, or edited by hand. {% 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 %} **Clause 9A โ€” Generated files** 1. **No hand edits.** The Supplier shall not edit by hand any *Generated File* on the *Platform*, on any installation, including test installations. 2. **Corrections.** Every correction, including a change under a Change Request, shall be made in the *Accepted Description*. The Application shall then be generated again from it. 3. **Evidence.** Before each acceptance under clause 7, the Supplier shall run the *Read-back* and hand PHEQA its list of every Generated File and its mark. A delivery without the list shall not be accepted. 4. **Hand edits found.** A Generated File marked as edited by hand is a Defect under clause 9.3. The Supplier shall correct it in the Accepted Description and generate again, and PHEQA shall withhold 5 per cent of the milestone payment until the Read-back shows every file in step. **Terms not defined in the pasted contract:** Generated File; Platform; Accepted Description; Read-back. {% 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 clause hooks into what the contract already has Parts 3 and 4 lean on clause 7 (acceptance) and clause 9.3 (defects), so a hand edit gets the ten working days the contract already sets. That is the right instinct: the new clause adds a rule and its evidence, not a new procedure.
2. The 5 per cent was never asked for Nothing in the pasted section mentions payments or milestones, yet part 4 withholds 5 per cent of one. "Milestone payment" is not even in the list of undefined terms. Whether PHEQA may withhold a payment, and how much, is set by the procurement rules that govern the contract; the assistant does not know them. This is why the clause goes to PHEQA's legal officer as a draft.
3. "Out of date" is left hanging The read-back has three marks, and the clause deals with only one. A file marked out of date is not a hand edit, but it is not in step either. Decide whether part 3 should require every file in step before acceptance.
{% hint style="danger" %} **Safeguard.** The clause is a draft. It is reviewed by the ministry's legal officer before it enters a contract, and checked against the procurement rules that govern the contract; the assistant does not know them. {% endhint %} {% endtab %} {% tab title="What next" %} Put the reviewed clause beside the other requirements on the 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). The read-back is not the only check worth writing into the contract: the checks on the platform's known traps follow in [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). {% 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.2-nothing-generated-is-edited-by-hand.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.