Der Contract ist die Fähigkeitsschicht, die wir gerade plattformweit einführen. Er beschreibt, was eine App allem außerhalb anbietet: welche Events sie meldet, welche Aktionen sich auslösen lassen, welche Fragen sie beantwortet und wovon sie abhängt. Die Definition beschreibt, wie die App arbeitet. Der Contract beschreibt, wie alle anderen mit ihr arbeiten können.
ABB.00 — SCHRITT 03 VON 04 · APP-CONTRACT
Alles darin wird beim Kompilieren aus der Definition berechnet. Die eine Ausnahme ist der Zweck. Den schreibt der Generator einmal, wenn die App entsteht, und Sie können ihn ändern.
Eine Zusammenfassung und die Aufgaben, die die App verantwortet. Einmal vom Generator aus Ihrer Beschreibung geschrieben, danach änderbar, und der einzige Teil, den ein Mensch pflegt.
Die Schnittstellen, die die App unterstützt, abgeleitet aus dem, was die Definition wirklich enthält. Kein Schalter mit der Aufschrift Webhooks: ja. Fakten, keine Versprechen.
Benannte Events wie deal.gewonnen oder urlaub.genehmigt, dazu die Datensatz- und Statusänderungen, die jede Entität ohnehin mitbringt. Die Meldung ist der Contract.
Die Kommandos, die die Definition erklärt. Einen Deal anlegen, eine Phase wechseln, einen Antrag genehmigen. Jedes läuft innerhalb der Rechte des Aufrufers.
Die Entitäten, Ansichten, Kennzahlen und Summen, die die App lesbar macht. Der Forecast ist eine Abfrage, die Liste offener Deals auch.
Die Organisationen, Personen und anderen Apps, auf die sie verweist, statt eigene zu erfinden. Ein CRM, das von Organisationen abhängt, führt nie eine zweite Kundenliste.
Die eigenen Oberflächen der App brauchen den Contract nie. Alles außerhalb der App braucht ihn. Ein Ablauf abonniert ein Event über seinen Namen. Eine andere App erklärt, wovon sie abhängt. Ein Agent fragt, was möglich ist. Die App-Bibliothek zeigt, was eine App meldet, bevor jemand sie installiert.
Der Contract hat außerdem ein Stabilitätsversprechen, das das Innere der App nicht hat. Die Definition darf jede Woche ihre Form ändern. Der Contract ist versioniert. Ein entferntes Event oder eine umbenannte Aktion fällt auf, bevor ein Update ankommt, und eine App, die sich nur innen verändert hat, stört nichts, was an ihr hängt.
Wir sagen das lieber hier, als es ein Diagramm andeuten zu lassen. Das gibt es vom Contract heute: Jede Definition benennt die Events, die sie meldet. Jede App ist über REST, OpenAPI und MCP erreichbar, innerhalb der Rechte dessen, der fragt. Und Apps verweisen bereits auf dieselben Organisationen und Personen, statt Kopien zu führen.
Das führen wir gerade ein: den Contract als eigene kompilierte Datei neben jeder App, Apps, die ohne Zwischenschicht auf die Events anderer Apps reagieren, und Agenten, die die Fähigkeiten einer App aus dem Contract lesen statt aus ihrer Oberfläche. Die Roadmap sagt, wo jeder dieser Punkte steht.
Eine Cordango-App entsteht mit einer bekannten Schnittstelle nach außen. Sie muss nicht nachträglich integriert werden, weil sie vom ersten Tag an sagt, was sie anbietet und wovon sie abhängt, und weil sie auf die Datensätze des Unternehmens verweist, statt Kopien davon zu führen.
Das ist der Unterschied zwischen verbunden und integriert. Integriert heißt, zwei getrennte Dinge wurden hinterher verdrahtet. Verbunden heißt, die App wurde zum Mitmachen gebaut: dieselben Personen, dieselben Organisationen, dasselbe Rechtemodell und ein Contract, der allen anderen sagt, wie sie mit ihr arbeiten.
Bringen Sie einen Ablauf mit, der heute mehr als ein Werkzeug berührt. Wir bauen die App live und zeigen, was sie meldet, was man sie fragen kann und wie der Rest Ihres Unternehmens mit ihr arbeitet.