Four stages, in this order, every time. Each one has its own page, because each one is a thing you can read and check rather than something that happens out of sight.
Nothing here is a black box. The middle two stages are documents you can open: one says how the app works, the other says what it offers the rest of the company.
Each stage has its own page. Follow them in order, or jump to the one you care about.
You answer a few questions about the process in plain words: who uses it, which stages it has, who may see what, what should happen on its own. No modelling, no schema.
How describing an app works →What comes back is one structured description of the app: domain, data, experience, logic and access. Cordango reads it to run the app. You can read it too, and change it.
What belongs in a definition →Every app also says what it offers the rest of the company and what it needs from it, by name. That is what lets other apps, workflows, agents and the API work with it.
What an app offers →The app runs on the company platform: your people and organizations already in it, permissions and audit from the company security model, and everyone's own view of the same data.
What a live app gains →About 30 minutes, on a real company platform, with your permissions and your people in it.