The contract is the capability layer we are currently introducing across the platform. It describes what an app offers to everything outside it: the events it announces, the actions that can be invoked, the questions it can answer and what it depends on. The Definition describes how the app works. The Contract describes how everything else can work with it.
FIG.00 — STAGE 03 OF 04 · APP CONTRACT
Everything in it is computed from the definition when the app is compiled. The one exception is the purpose, which the generator writes once when the app is created and which you can edit.
A summary and the duties the app owns. Written once by the generator from your description, editable afterwards, and the only part a person maintains.
The interaction surfaces the app supports, derived from what the definition actually contains. No flag that says webhooks: yes. Facts, not promises.
Named events like deal.won or pto.approved, plus the record and state changes that come with every entity. The announcement is the contract.
The commands the definition declares. Create a deal, move a stage, approve a request. Each one runs under the caller's permissions.
The entities, views, KPIs and rollups the app makes readable. The forecast is a query, and so is the list of open deals.
The Organizations, People and other apps it points at instead of inventing its own. A CRM that depends on Organizations never keeps a second customer list.
The app's own screens never need the contract. Everything outside the app does. A workflow subscribes to an event by its name. Another app declares what it depends on. An agent asks what it can do. The App Library shows what an app announces before anybody installs it.
The contract also has a stability promise the app's internals do not. The definition can change shape every week. The contract is versioned, so a dropped event or a renamed action is visible before an update lands, and an app that only changed on the inside does not disturb anything wired to it.
We would rather say this here than let a diagram imply it. The parts of the contract that exist today: every definition names the events it announces, every app is reachable over REST, OpenAPI and MCP under the caller's permissions, and apps already point at the same Organizations and People instead of keeping copies.
What we are introducing now: the contract as its own compiled file next to every app, apps reacting to each other's events without middleware, and agents discovering an app's capabilities from the contract instead of from its interface. The roadmap says where each of those stands.
A Cordango app is created with a known interaction surface. It does not have to be integrated later, because from the first day it says what it offers and what it depends on, and it points at the company's own records rather than keeping a copy of them.
That is the difference between connected and integrated. Integrated means two separate things were wired together afterwards. Connected means the app was built to participate: the same people, the same organizations, the same permission model, and a contract that tells everything else how to work with it.
Bring a process that touches more than one tool today. We build the app live and show what it announces, what it can be asked, and how the rest of your company works with it.