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.

Drei 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.

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.