> 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.4-one-file-a-program-reads-the-application-model.md). # E4.4 — One file a program reads: the application model Here is one section of MoEYS's file, for the goal 'approve a change of an institution's name', read in plain sentences. **Subtopic:** 4.4 — One file a program reads: the application model **Public anchor:** Joget DX 9 Knowledge Base (the DX9 edition, listing release 9.0.7): the pages Form Builder, List Builder, UI Builder and Process Builder **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.4 that carry Progressa's example: 'MoEYS: one section, in plain sentences'; 'Ask for it in plain sentences'. **Form of this example.** Taken as it stands from the script of 4.4 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 section, in plain sentences > *Slide 5 — Title: 'MoEYS: one section, in plain sentences'. Body, five text rows: 'Goal: approve a change of an institution's name.' 'Starts from: PHEQA's advice on changes of name that waits for the minister.' 'Shows: the institution's present name, read from PHEQA's register across Linkup; the new name asked for; PHEQA's advice.' 'Decision: approve or do not approve, chosen, not typed.' 'Records: the approval, sent to PHEQA across Linkup; officers of MoEYS see it in the list of approvals.'* Here is one section of MoEYS's file, for the goal 'approve a change of an institution's name', read in plain sentences. The minister opens the list of PHEQA's advice on changes of name that waits for a decision. On the screen, the institution's present name is read from PHEQA's register across Linkup, the data exchange, and never copied. The new name and PHEQA's advice come as PHEQA sent them. The decision is chosen, approve or do not approve, never typed. Recording it sends the approval to PHEQA, and officers of MoEYS see it in their list of approvals. ## Ask for it in plain sentences > *Slide 6 — Title: 'Ask for it in plain sentences'. Body, four text rows: 'The file is written for a program.' 'Ask for a plain-sentence reading of each section beside it.' 'Your officials check the reading against the screens they agreed.' 'Where the two differ, the file is what gets built.'* The file is written for a program, not for you. So ask the supplier for a plain-sentence reading of each section, beside the file. Your officials check the reading against the screens they agreed. Then the business side and the builder read the same thing, and a decision means the same in both rooms. Keep one thing in mind: where the reading and the file differ, the file is what gets built. Raise every difference before the file is approved. **What to look for before you accept it.** Ask for the one file the application is generated from, and a plain-sentence reading of it. Check the reading against what your officials agreed. --- # 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.4-one-file-a-program-reads-the-application-model.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.