# The App Definition: how a Cordango app works > Every Cordango app is one structured definition: domain, data, screens, logic and access. Cordango reads it to run the app, checks it before it runs, changes it when you ask, and can build it into software you own. Source: https://www.cordango.com/app-definition/ Language: en HOW IT WORKS · 02 # Every app has a definition. Behind every Cordango app sits one structured description of the app: what it is about, what it stores, what people see, what happens on its own and who may do what. Cordango reads it to run the app. You can read it too, and that is the point. [Book a demo →](https://www.cordango.com/contact/) [What belongs in it →](https://www.cordango.com/app-definition/#parts) 1. [01 Idea / Prompt](https://www.cordango.com/generate/) 2. 02 App Definition 3. [03 App Contract](https://www.cordango.com/app-contract/) 4. [04 Live Business App](https://www.cordango.com/run-on-cordango/) 1. [Domain Purpose and vocabulary](https://www.cordango.com/app-definition/#parts) 2. [Data Entities, fields, relationships](https://www.cordango.com/app-definition/#parts) 3. [Experience Pages, views, forms, layouts](https://www.cordango.com/app-definition/#parts) 4. [Logic Workflows, validations, calculations](https://www.cordango.com/app-definition/#parts) 5. [Access Roles, permissions, rules](https://www.cordango.com/app-definition/#parts) FIG.00 — STAGE 02 OF 04 · APP DEFINITION ## What belongs in it. The blueprint behind the app. Not a database schema, not generated source code, not a canvas full of boxes. A description Cordango can act on and a person can review. DOMAIN #### Purpose and vocabulary What the app is for and what it calls things. A deal is a deal, a request is a request, and the rest of the definition uses those words. DATA #### Entities and relationships The records the app keeps, their fields, and how they point at each other and at the company's own People and Organizations. EXPERIENCE #### Pages, views and forms What somebody opens: the list, the board, the record page, the form that files a request. Layouts included. LOGIC #### Workflows, rules and calculations What happens on its own. A status that moves, a value that is computed, a validation that refuses, a hook that fires. ACCESS #### Roles and permissions Who may see and do what, per entity, per field and per command. Enforced by the platform, described in the app. ONE FILE #### Company data is never in it The definition describes the app. Your records stay yours and stay where they are. That is what makes it safe to read, share and move. ## Readable by a person. Runnable by the platform. Most AI builders hand you generated source code. It works until you want to know what it does, and then somebody has to read it. A definition is the opposite of that. It is explicit and it is complete, so Cordango can understand the app instead of guessing at it. That is why the app can be checked before it runs, why the runtime can interpret it directly, and why an AI change goes through the definition rather than through files nobody reviewed. The same definition also carries the app's public side, the App Contract, which is derived from it rather than written separately. - CHECK Validated before it goes live, on your machine if you want - RUN Interpreted by the runtime, with your people and permissions applied - REVIEW A person can read what the app does without reading code - DERIVE The App Contract is computed from it, never kept in sync by hand [What it exposes: the App Contract →](https://www.cordango.com/app-contract/) cordango check Before it runs \# on a laptop, no account needed > cordango check sales-crm.cord ✔ 4 entities · 11 fields · 3 relationships ✔ 5 screens · 2 workflows · 3 roles ✔ every reference resolves · every rule has a field \# the same file, on the platform ✔ installed Acme Ltd your people · your permissions · your audit trail ## It changes when the process changes. Run the app with real work for a week and something will be wrong. That is normal. Ask for the change in plain words and Cordango edits the definition, checks it again and the app moves. Or open the definition and change it yourself, if that is how you prefer to work. Either way the change lands in one place. There is no generated code drifting away from what was described, and no second copy of the app for another team, because a personal view is a layout and not a fork. - ASK Describe the change and the definition is edited for you - EDIT Or change it by hand, in a format made to be read - CHECK Every change is validated before it runs - ONE One definition per app, however many people shape their own view [Personal views without forking the app →](https://www.cordango.com/make-it-yours/) Change request sales-crm \# you > add a lost reason when a deal is lost \# cordango ai ✔ definition updated Deal.lost\_reason required on stage Lost ✔ screens updated deal page · board card ✔ checked nothing else changed ## Born Portable. — you own the definition Because the app is a definition rather than a codebase, it has two destinations. It runs here, on your platform, connected to your people and your permissions. Or `cordango build` turns it into a conventional application you own outright: ASP.NET Core and EF Core on the back, Vue on the front, a Dockerfile and migrations you can read, and no dependency on us. The format, the compiler, the command line tool and the generator are Apache-2.0. The platform is not, so calling Cordango open source would be a stretch and we would rather write that here than let it be inferred. Everything you need to write an application and check it is open, which is why `cordango check` runs on a laptop with no account and no connection. - IN The whole application, not a starting point - OUT Your records are never part of the file - RUN Hosted here, or standalone and hosted by you - OPEN Format, compiler and CLI under Apache-2.0 [What the generator cannot do yet →](https://www.cordango.com/roadmap/) cordango build Standalone \# one definition, two destinations > cordango build --target standalone reads sales-crm.cord → entities · rules · screens · roles writes Api/ → asp.net core · ef core · migrations writes Web/ → vue · vuetify · the screens you designed writes Dockerfile → compose up, and it runs ✓ yours no licence server · no account · no phone home The generator refuses to build rather than quietly shipping less than your definition asked for. Workflows, computed fields and command guards are still on that refusal list today, which the roadmap says out loud. MORE ## Further reading - [**App Contract** What the app offers: purpose, events, actions, queries and dependencies](https://www.cordango.com/app-contract/) - [**Run on Cordango** The live app: personal views, governance, shared context and connected work](https://www.cordango.com/run-on-cordango/) - [**Capabilities** CRM, projects, PTO, support and more](https://www.cordango.com/capabilities/) - [**Sample apps** Explore real apps you can install and make yours](https://www.cordango.com/templates/) - [**Use cases** See where Cordango fits best, with a real app behind each one](https://www.cordango.com/use-cases/) - [**Platform foundation** The company foundation underneath every app](https://www.cordango.com/platform/) - [**Governance built in** Identity, permissions and audit included](https://www.cordango.com/security/) - [**Agents & APIs** Agents, MCP and APIs across your whole company](https://www.cordango.com/ai/) NEXT ## Watch a definition get written from one sentence. A live session on one of your own processes. You describe it, Cordango asks its questions, and the definition and the app appear in about 30 minutes. [Book a demo →](https://www.cordango.com/contact/) [How an app is created →](https://www.cordango.com/generate/)