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.
FIG.00 — STAGE 02 OF 04 · APP DEFINITION
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.
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.
The records the app keeps, their fields, and how they point at each other and at the company's own People and Organizations.
What somebody opens: the list, the board, the record page, the form that files a request. Layouts included.
What happens on its own. A status that moves, a value that is computed, a validation that refuses, a hook that fires.
Who may see and do what, per entity, per field and per command. Enforced by the platform, described in the app.
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.
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.
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.
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.
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.
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.