> 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/e5.1-from-one-file-to-a-running-application.md). # E5.1 — From one file to a running application In Progressa, MoEYS's application is generated from its model onto MoEYS's own installation of the platform. **Subtopic:** 5.1 — From one file to a running application **Public anchor:** Joget DX 9 Knowledge Base, the platform's documentation: the pages Form Builder, List Builder, UI Builder and Process Builder, and Migrating a Single Joget App **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 5.1 that carry Progressa's example: 'Progressa: MoEYS's application'; 'The questions you ask of the result'; 'From the file to the menu'. **Form of this example.** Taken as it stands from the script of 5.1 in the script bundle of module 5: 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. ## Progressa: MoEYS's application > *Slide 5 — Title: 'Progressa: MoEYS's application'. Body, four text rows: 'Generated from MoEYS's model, onto MoEYS's own installation.' 'Forms: the minister's decisions; the Gazette entries.' 'Lists: what awaits the minister's decision.' 'Menu in five categories: Licences · Names, the list and reviews · Suspension and cancellation · The Gazette · Requests for review.'* In Progressa, MoEYS's application is generated from its model onto MoEYS's own installation of the platform. The model asks for the forms on which the minister decides and an officer records the Gazette, for lists of what awaits the minister, and for a menu in five categories: licences; names, the list and reviews; suspension and cancellation; the Gazette; and requests for review. It asks for no table of institutions, because MoEYS reads PHEQA's register instead. ## The questions you ask of the result > *Slide 6 — Title: 'The questions you ask of the result'. Body, four text rows: 'Each goal: where does it start, and who can start it?' 'Each menu category: present, and shown only to its role?' 'Each list: does it show only what awaits an act?' 'Any screen that no accepted document asked for?'* Acceptance starts from the model, not from the supplier's account. For each goal, ask where it starts and who can start it. Check that every menu category is there, for the right role and no other. Open each list and check that it shows only what waits for an act. Then ask whether any screen exists that no accepted document asked for. Each answer is read on the running application, not on a slide. ## From the file to the menu > *Slide 7 — Title: 'From the file to the menu'. Demonstration segment, storyboard until recorded (section 4.8). Text-only stand-in until the recording exists: 'The file admitted by the check.' 'The application built and installed on MoEYS's installation.' 'The menu, one form and one list opened.' 'Pass: no error; the application listed; every menu category present.'* The demonstration follows these steps. The check admits the file. The kit builds the application and installs it on MoEYS's installation. Then the menu, one form and one list are opened on the platform. It passes when the build ends without error, the application appears on the installation, and every menu category of the interaction design is there. Until MoEYS's application is generated, this is a storyboard: the steps and the pass, written before anything is recorded. **What to look for before you accept it.** One accepted file, read by a program, becomes the forms, lists, menus and workflow on the platform. Ask your questions of the running result, one goal at a time. --- # 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/e5.1-from-one-file-to-a-running-application.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.