Ein Lebensgraph, kein Datenmodell mit CRUD.

DeskCore ist die Plattform hinter BrokerDesk24 und BusinessDesk24. Der Kern ist eine pure Funktion: Ereignisse gehen hinein, ein Graph und eine Liste von Entscheidungen kommen heraus. Es gibt keinen Zustand außerhalb des Ereignislogs.

Vier Invarianten machen das aus. Sie sind nicht Konvention, sondern im Typsystem verankert. Wer sie verletzen will, muss den Compiler überreden.

1. Kein Display-Code als SchlüsselAF1 ist eine Anzeige, keine Identität. Ein Display-Code trägt immer seine context_id mit und lässt sich nicht als nackter String zu einem Schlüssel machen. Identität ist immer eine Uuid.
2. Kein Update, nur AppendEin Datensatz wird nie geändert. Der geltende Stand bekommt ein valid_to, der neue Stand wird angehängt. Der Zustand von gestern bleibt rekonstruierbar, weil er nie gelöscht wurde.
3. Keine Kante ohne evidence_idJede Relation trägt mindestens eine Evidenz. Das Feld ist ein nicht-leeres Tupel, kein Array — eine Beziehung ohne Beleg lässt sich nicht konstruieren.
4. Keine Entität ohne DatenraumJede Entität und jede Kante trägt eine workspace_id. Ein gemeinsamer Core ist kein gemeinsamer Datenbesitz: dieselbe Person kann in mehreren Datenräumen vorkommen, aber sie verschmilzt nicht. Verbindungen über Datenräume brauchen eine Freigabe als Evidenz.

Drei Dokumente gehen ein: eine Police von 2023, ein Fahrzeugschein von gestern, eine GDV-Bestandsdatei von heute. Daraus entsteht der Graph. Jede Relation hängt an der Evidenz, die sie belegt — das sind die dünnen, gestrichelten Linien nach unten. Ohne sie gäbe es die Kante nicht.

Der Umschalter zeigt denselben Graph vor und nach der Bestätigung des Fahrzeugwechsels durch einen Menschen. Die alte Kante Kfz-Vertrag C-123 → Fahrzeug 01 wird dabei nicht gelöscht. Sie bekommt ein valid_to und bleibt sichtbar.

Die Daten stammen aus demoLog() in packages/core/src/store.ts, die Evidenzkette aus why(log, relation_id). Auf dieser Seite läuft kein Server und wird nichts nachgeladen.

Haushalt, Unternehmen, Gesundheit und Finanzen sind derselbe Graph. Dieselben vier Bausteine — Entität, Beziehung, Evidenz, Ereignis — tragen jedes Lebensfeld, nur die Inhalte wechseln. Der Umschalter zeigt jede Kette einzeln und alle zusammen.

Der Beweis steht in der Mitte: die Immobilie kommt in Haushalt und in den Finanzen vor — als eine Entität, nicht als zwei gleichnamige. Im Haushalt hängen Räume und Inventar darunter, in den Finanzen Wert und Kredite. Kein Kopieren, derselbe Knoten. Ebenso die Person in Gesundheit und Finanzen.

Die Kante ist der eigentliche Datentyp. Entitäten sind Knoten ohne Eigenschaften, die Bedeutung liegt in den Beziehungen. Zuordnungsarten werden nicht gleichgesetzt: Eigentümer, Besitzer, Nutzer, Zahler, Halter und Versicherungsnehmer sind sechs verschiedene Typen.

// packages/core/src/types.ts

/** Nicht-leeres Tupel. Der Compiler erzwingt mindestens ein Element. */
export type NichtLeer<T> = readonly [T, ...T[]];

export interface Relation extends StandardMetadaten {
  readonly relation_id: Uuid;
  readonly von: Uuid;
  readonly nach: Uuid;
  readonly typ: RelationTyp;

  /** Mindestens eine Evidenz. Immer. (Invariante 3) */
  readonly evidence_ids: NichtLeer<Uuid>;
}

/** Fachliche Zeit vs. Systemzeit. Beide werden nie vermischt. */
export interface StandardMetadaten {
  readonly valid_from?: Zeitpunkt;
  /** null = gilt bis heute. Wird gesetzt, nie ueberschrieben. */
  readonly valid_to?: Zeitpunkt | null;
  readonly recorded_at?: Zeitpunkt;
}

Der Reducer ist pur und kennt kein Log. Ein Dokument geht ein, der Extraktor liest Claims heraus, der Reducer prüft sie gegen den Graph und liefert Entscheidungen und Folgeaufgaben zurück. Was er ohne Menschen schreiben darf, ist eng begrenzt.

// packages/core/src/reducer.ts

applyEvidence(graph, evidence) -> { graph, decisions[], tasks[] }

Evidenz und Claims wandern immer in den Graph — sie sind Tatsachen im Sinne von „dieses Dokument behauptet X“. Ob daraus eine Kante wird, entscheidet die Stufe: AUTO, SUGGEST oder MANDATORY_REVIEW.

• Evidenz vor DatenEin Wert ohne Beleg existiert nicht.
• Claims vor WahrheitEin Dokument behauptet. Es stellt nicht fest.
• Beziehungen vor ListenDie Kante trägt die Bedeutung, nicht die Zeile.
• Versionierung vor ÜberschreibenDer alte Stand endet, er verschwindet nicht.
• Entscheidung vor AutomatikDer Core schlägt vor, der Mensch entscheidet.
• Projektion vor UI-WahrheitDie Oberfläche liest, sie besitzt nicht.

• api.deskcore.cloudGraph- und Evidenz-API. Noch nicht öffentlich dokumentiert.
• id.deskcore.cloudIdentity und SSO für alle Anwendungen. Noch nicht aktiv.
• app.brokerdesk24.deMaklerarbeitsplatz. Sprint 1: Posteingang.