Facets: Das Wissensmodell von CLYE AI

Facets sind das zentrale Modell, mit dem CLYE AI Wissen beschreibt, verbindet und abfragt. Sie vereinheitlichen Metadaten aus Dokumenten und Chunks, verschachtelte JSON-Daten sowie relationale Tabellen zu einer virtuellen Knowledge-Graph-Semantic-Layer.

Dadurch werden Inhalte nicht nur filterbar: Facets bilden fachliche Entitäten, Eigenschaften, Beziehungen und Typen ab. Abfragen verwenden stabile Business-Begriffe statt Tabellen, Spalten oder technischer Datenquellen – und CLYE AI kann daraus Typwissen, Suchpfade und SQL-Joins ableiten.

Wichtig ist dabei: Dieses Modell „rät“ nicht stillschweigend. Ableitungen, Join-Pfade und Typzuordnungen folgen aus einem versionierten Schema, aus Mappings und aus nachvollziehbaren Regeln. Wo fachliche Mehrdeutigkeit besteht, muss sie sichtbar gemacht und aufgelöst werden.

Das zentrale Facet-Modell

Das Modell ist an RDF angelehnt: Ein Facet beschreibt eine Beziehung oder Eigenschaft – vergleichbar mit einem RDF-Prädikat. Anders als in klassischem RDF wird jedoch nicht grundsätzlich zwischen Prädikaten und Typen unterschieden: Beides sind Facets.

Das ist eine bewusste Vereinfachung, keine Schwäche. Ein Facet kann zugleich eine Beziehung oder Eigenschaft beschreiben und ein möglicher Typ sein. Dadurch lässt sich fachliche Bedeutung kompakt modellieren, ohne Klassen und Properties künstlich zu trennen.

Das ist wichtig, weil eine Beziehung zugleich eine Aussage über ihren Wert treffen kann:

„Simon hat den Vater Johannes“

Die Aussage enthält auch: „Johannes ist ein Vater“. Deshalb kann vater sowohl die Beziehung von Simon zu Johannes als auch ein Typ von Johannes sein.

Facets können einfache Werte wie Text oder Zahlen enthalten, aber auch verschachtelte Objekte und weitere Facets.

Standard-Facets für gemeinsame Business-Domains

CLYE AI stellt einen gemeinsamen Standardumfang eingebauter Facets bereit. Diese Facets bilden verbreitete Business-Domains ab und stehen in allen Spaces und Datenquellen mit derselben grundlegenden Bedeutung zur Verfügung.

Dazu gehören beispielsweise Entitäten und Beziehungen rund um:

• Personen, Organisationen, Kunden und Mitarbeitende
• Produkte, Leistungen und Preise
• Angebote, Bestellungen, Verkäufe und Rechnungen
• Rechnungspositionen, Zahlungsinformationen und Verträge
• Projekte, Abteilungen, Standorte und Adressen

Damit haben Facets wie customer, product, invoice oder invoicePosition eine gemeinsame, klar definierte Basissemantik – unabhängig davon, ob die Daten aus einem Dokument, einer API oder einer Tabelle stammen. Ein Tabellen-Mapping kann deshalb direkt auf die Standard-Facets abbilden, und eine Query kann dieselben Facet-Pfade über verschiedene Quellen verwenden.

Das bedeutet nicht, dass überall exakt dieselbe Fachrolle gemeint sein muss. Spezifischere Rollen werden ergänzend modelliert, zum Beispiel billingCustomer, contractingParty oder crmAccount. Solche spezifischen Facets können über Hierarchie oder Beziehungen unter einem gemeinsamen Begriff wie customer nutzbar werden, ohne unterschiedliche Businessrollen künstlich gleichzusetzen.

Eigene Facets erweitern dieses gemeinsame Fachmodell um unternehmens- oder space-spezifische Begriffe. Sie sollten einen bestehenden Standardbegriff nicht mit abweichender Bedeutung nachbilden. Statt beispielsweise ein zweites kunde-Facet anzulegen, wird eine spezielle Kundeneigenschaft als ergänzendes Facet am Standardtyp customer modelliert.

Events: Fachkontext für Automationen

Auch Events verwenden Facets in ihren Metadaten. Der technische Event-Typ beschreibt, was passiert ist; die Facet-Metadaten beschreiben, wen oder was das Ereignis fachlich betrifft. So kann ein Event direkt mit Kunden, Rechnungen, Projekten, Dokumenten oder Tasks verbunden werden.

{
  "type": "external.invoice.received",
  "data": {
    "source": "erp"
  },
  "metadata": {
    "type": "invoice",
    "customer": { "name": "Beispiel GmbH" },
    "invoice": { "number": "RE-2026-0042" },
    "project": { "name": "ERP-Migration" }
  }
}

Eine Automation kann auf den Event-Typ external.invoice.received reagieren und zusätzlich über die Facet-Metadaten entscheiden, ob und wie sie weiterläuft. Zum Beispiel kann sie nur für einen bestimmten Kunden oder ein Projekt einen Prüf-Task anlegen, einen Agenten zur Prüfung aufrufen oder eine Benachrichtigung auslösen.

event.metadata.customer?.name == "Beispiel GmbH"

Events sind damit nicht nur technische Trigger. Sie transportieren denselben Business-Kontext wie Dokumente, Tabellen und Tasks. Größere Abläufe lassen sich als Event-Ketten modellieren: Ein Eingang erzeugt ein fachlich angereichertes Event, eine Automation verarbeitet es und erzeugt bei Bedarf einen kontextbezogenen Folge-Task oder ein weiteres Event.

Mehr zur technischen Struktur von event, Conditions und Event-Triggern: Event-Typen für Automationen.

Verschachtelte Listen als virtuelle Tabellen

Eine Liste verschachtelter Objekte ist nicht nur JSON-Struktur: Jedes Listenelement wird als eigene, mit dem übergeordneten Objekt verbundene Facet-Entität behandelt. Dadurch sind extrahierte Positionen aus einem Dokument sofort abfragbar – genauso, als lägen sie in einer eigenen relationalen Tabelle vor.

Wichtig ist: Diese Entitäten werden logisch behandelt, nicht zwingend physisch materialisiert. Das Modell folgt eher der Semantik von UNNEST oder einer virtuellen Child-Relation als einer zusätzlichen persistierten Tabelle.

Beispiel: Rechnung mit Positionen

Bei der Extraktion einer Rechnung kann beispielsweise dieses Ergebnis entstehen:

{
  "type": "invoice",
  "number": "RE-2026-0042",
  "issueDate": "2026-07-29",
  "customer": {
    "name": "Beispiel GmbH"
  },
  "invoicePositions": [
    {
      "description": "Beratung",
      "quantity": 8,
      "netAmount": 1200
    },
    {
      "description": "Softwarelizenz",
      "quantity": 2,
      "netAmount": 498
    }
  ]
}

Das Facet invoicePositions beschreibt die Beziehung von einer Rechnung zu ihren Positionen. Ein passendes Schema macht die Bedeutung explizit:

invoicePositions:
  domain: invoice
  range: invoicePosition
  cardinality: zero-or-many
  inverse: invoice

CLYE AI behandelt die beiden Elemente in invoicePositions als zwei virtuelle invoicePosition-Datensätze. Jeder Datensatz bleibt dabei mit seiner Rechnung verbunden. Konzeptionell entsteht daraus eine relationale Sicht:

invoice.number	invoice.customer.name	invoicePositions.description	invoicePositions.quantity	invoicePositions.netAmount
RE-2026-0042	Beispiel GmbH	Beratung	8	1200
RE-2026-0042	Beispiel GmbH	Softwarelizenz	2	498

Die JSON-Quelle muss dafür nicht in eine physische Tabelle überführt werden. Die Liste wird bei der Abfrage wie eine virtuelle Tabelle bzw. wie ein UNNEST behandelt.

Logische Semantik von Listen

Für Listen sind fachlich insbesondere diese Punkte wichtig:

• Parent-Bezug: Jedes Element bleibt dem übergeordneten Objekt zugeordnet.
• Kardinalität: Eine Liste ist typischerweise zero-or-many, kann aber fachlich enger definiert sein.
• Stabile Identifizierbarkeit: Falls vorhanden, kann ein Listenelement eine eigene fachliche oder technische ID haben.
• Reihenfolge oder Index: Wenn die Reihenfolge fachlich relevant ist, muss sie als Eigenschaft oder Index sichtbar bleiben.
• Unterschied zwischen leer, fehlend und null: Eine leere Liste bedeutet etwas anderes als ein fehlendes Feld oder ein expliziter null-Wert. Beim Bearbeiten in der Oberfläche bedeutet Feld entfernen, dass der Key wirklich entfernt wird. Dadurch bleiben Frontmatter, verschachtelte Objekte und andere Facet-Strukturen konsistent, statt leere Platzhalter zu behalten.

Werden mehrere Listen gleichzeitig expandiert, kann ein Fan-out oder Kreuzprodukt entstehen. Diese Wirkung muss in Query-Plan und Ergebnis-Erklärung sichtbar sein, damit keine stillschweigend falschen Aggregationen entstehen.

Direkt über Facet-Pfade abfragen

Alle Positionen einer bestimmten Rechnung:

invoicePositions.description, invoicePositions.quantity, invoicePositions.netAmount
where invoice.number = "RE-2026-0042"

Umsatz aus Rechnungspositionen nach Kunde:

customer.name, sum(invoicePositions.netAmount) as netto_umsatz
where type = "invoice"

Alle abgerechneten Beratungspositionen über sämtliche extrahierten Rechnungen:

invoice.number, customer.name, invoicePositions.netAmount
where invoicePositions.description = "Beratung"

Bei explorativen Ad-hoc-Abfragen kann die Gruppierung weiterhin implizit aus nicht aggregierten Feldern folgen. Für gespeicherte oder automatisierte Queries sollten Root, Grain und Gruppierung jedoch explizit sein oder vor Ausführung bestätigt werden.

Beispielhafte SQL-Ausführung

Die konkrete SQL-Syntax hängt vom Speichersystem ab. Bei JSONB in PostgreSQL kann die zweite Query beispielsweise über ein seitliches Auflösen der Liste ausgeführt werden:

SELECT
  metadata->'customer'->>'name' AS customer_name,
  SUM((position->>'netAmount')::numeric) AS netto_umsatz
FROM chunks
CROSS JOIN LATERAL jsonb_array_elements(metadata->'invoicePositions') AS position
WHERE metadata->>'type' = 'invoice'
GROUP BY metadata->'customer'->>'name';

Für die Query bleibt diese Umsetzung unsichtbar: Sie beschreibt ausschließlich die fachlichen Facet-Pfade. Das ermöglicht Auswertungen über extrahierte Dokumente und relationale Tabellen mit derselben Sprache – etwa Umsätze nach Kunde, häufige Positionen, Mengen pro Produkt oder Rechnungspositionen innerhalb eines Zeitraums.

JSON-Serialisierung

Für Chunk-Metadaten und die JSON-Schnittstelle werden Facets direkt als JSON-Objekte dargestellt:

{
  "facet": {
    "facet": "Value"
  }
}

Ein realistisches Beispiel für eine Beziehung sieht so aus:

{
  "name": "Simon",
  "vater": {
    "name": "Johannes"
  }
}

Das bedeutet: Das Objekt mit dem Namen „Simon“ hat einen Vater mit dem Namen „Johannes“. vater ist dabei das Facet, Johannes sein verschachtelter Wert.

Einen Wert als Facet-Typ projizieren

Soll ein Objekt unabhängig von seiner Stelle in der Struktur genauer beschrieben werden, kann es mit dem speziellen Property type projiziert werden:

{
  "type": "vater",
  "name": "Johannes"
}

type legt fest, dass dieses Objekt als Wert eines vater-Facets verwendet werden kann. Johannes ist damit nicht nur der Vater von Simon, sondern auch ein Objekt des Facet-Typs vater.

Für mehrere Typen kann type als Liste angegeben werden:

{
  "type": ["mann", "person"],
  "name": "Johannes"
}

Strukturierte Objekt-Facets in der Oberfläche

In der Oberfläche werden fachliche Entitäten als strukturierte Objekt-Facets dargestellt. Solche Facets enthalten nicht nur einen Einzelwert, sondern ein Objekt mit eigenen Eigenschaften – zum Beispiel eine Person, Firma oder andere fachliche Entität mit name, type und weiteren Feldern.

Wichtig für die Bearbeitung:

• Im Dialog Feld hinzufügen sind auch allgemeine Facets wie name auffindbar und auswählbar.
• Neue oder bisher ungenutzte Facet-Definitionen erscheinen dort sofort mit 0x Nutzung, statt erst nach dem ersten Einsatz.
• Die Nutzung zählt Facets aus Dokumenten/Chunks und Aufgaben/Threads gemeinsam. Wenn du dasselbe Facet in beiden Bereichen verwendest, steigt der Zähler entsprechend zusammengefasst.
• Interne technische Keys wie _agent tauchen in diesen Vorschlägen nicht als normale auswählbare Facets auf.
• Zu den eingebauten Feldern gehört jetzt auch thinkingLevel. Damit kannst du für Chats, Threads oder Aufgaben einen bevorzugten Thinking-Level als Facet pflegen.
• Bereits als veraltet markierte Facets werden für neue Zuweisungen nicht mehr normal angeboten.
• Das Feld type wird als Auswahl aus dem Wissensmodell behandelt, nicht nur als freier Text.
• Bei Objekt-Facets zeigt CLYE AI passende Typen mit Bezeichnung und Beschreibung, damit die Auswahl verständlicher ist.
• Für Objekt-Eigenschaften kann die Oberfläche vorhandene Werte vorschlagen, zusätzlich zu fachlich passenden Vorschlägen aus domain und range des Wissensmodells.
• Eingeklappte Objekt-Facets mit typischen Link-Feldern wie url, href oder link zeigen in der Oberfläche eine kompakte, direkt klickbare Link-Vorschau statt nur rohen JSON-Text. Dazu können unter anderem Favicon, Seitentitel und eine Hover-Vorschau gehören.
• Das ist besonders nützlich für Verweise auf externe Systeme wie Tickets, Dokumente oder Code-Reviews, weil du den Link auch im zugeklappten Zustand schneller erkennst und öffnen kannst.
• Wenn ein Facet nur für bestimmte Spaces freigegeben ist, erscheint es auch nur dort im Picker. In anderen Spaces bleibt es ausgeblendet.

Ein typisches Beispiel ist ein Objekt wie dieses:

{
  "customer": {
    "type": "company",
    "name": "Beispiel GmbH",
    "industry": "Maschinenbau"
  }
}

Damit wird customer nicht als bloßer Text behandelt, sondern als strukturierte Entität mit eigener Typisierung und weiteren Eigenschaften.

Beispiel: Pull-Request als Task-Facet

Für Aufgaben gibt es jetzt auch das eingebaute Facet pullRequest. Es ist für zugeordnete Code-Reviews gedacht und wird als Objekt gespeichert, typischerweise mit einer URL zum Pull Request.

{
  "pullRequest": {
    "url": "https://forgejo.example.com/team/projekt/pulls/42"
  }
}

Praktisch bedeutet das für Aufgaben:

• du kannst einen Pull Request direkt als strukturiertes Facet an einer Aufgabe hinterlegen
• die Oberfläche behandelt den Link nicht nur als Text, sondern zeigt die kompakte Link-Vorschau auch im eingeklappten Zustand
• Verweise auf Review, Merge-Status oder Rückfragen bleiben damit sichtbarer am Task-Kontext
• auch Tool-Abfragen auf Aufgaben und Threads können solche Objekt-Facets gezielt über Teilobjekte filtern, zum Beispiel nur über pullRequest.url, ohne dass weitere Felder im Objekt den Treffer verhindern

Beispiel für eine passende Filteridee in MCP- oder Tool-Kontexten:

{
  "pullRequest": {
    "url": "https://forgejo.clye-gmbh.de/CLYE/clye.ai/pulls/3759"
  }
}

Damit finden task_find und thread_find auch Aufgaben oder Threads, bei denen im selben Objekt zusätzlich weitere Felder wie Titel, Status oder Repository gespeichert sind. Mehrere angegebene Keys bleiben dabei kombinierbar.

Praktisch heißt das auch für die Oberfläche: Wenn du strukturierte Objekt-Facets an Aufgaben oder Chats speicherst, bleiben diese Werte wieder als echte JSON-Objekte erhalten. Teilobjekt-Filter wie auf pullRequest.url oder andere verschachtelte Facet-Pfade greifen dadurch konsistent, statt an einem versehentlich als Text gespeicherten Gesamtobjekt zu scheitern.

Strukturierte Objekte in Chunks und Aufgaben bearbeiten

Strukturierte Objekt-Facets lassen sich nicht nur im Wissenskontext, sondern auch direkt bei Chunks und Aufgaben pflegen. Das ist nützlich, wenn du fachliche Informationen nachträglich ergänzen oder korrigieren willst.

Typischer Ablauf:

1. Öffne den gewünschten Chunk oder die Aufgabe.
2. Öffne den Bereich für Facets bzw. strukturierte Felder.
3. Wähle Feld hinzufügen, falls die Eigenschaft noch fehlt.
4. Lege bei Bedarf ein Objekt-Facet an und ergänze darin einzelne Eigenschaften wie name, type oder weitere Fachfelder.
5. Listenwerte mit mehreren Einträgen lassen sich im Facets-Editor jetzt ähnlich wie Objekt-Facets aufklappen. Die Oberfläche zeigt dafür eine kompakte Zusammenfassung mit Chevron, statt nur einen flachen JSON-Eindruck zu vermitteln.
6. Innerhalb solcher Listen kannst du Einträge verschachtelt bearbeiten – also einfache Werte, Objekte und auch weitere verschachtelte Listen. Neue Elemente fügst du über Eintrag hinzufügen direkt an der jeweiligen Liste hinzu.
7. Boolesche Felder erscheinen in der Oberfläche als Checkbox und sind im Facet-Bereich an derselben Wertespalte ausgerichtet wie andere Feldwerte. So bleiben auch gemischte Formulare mit Text-, Auswahl- und Checkbox-Feldern leichter scanbar.
8. Speichere die Änderungen am übergeordneten Facet.

So bleiben verschachtelte Objekt- und Listenänderungen fachlich sauber am jeweiligen Eltern-Facet gebündelt.

Beispiel: Thinking Level als eingebautes Facet

Das eingebaute Facet thinkingLevel ist für Kontexte gedacht, in denen ein Modell mit unterstütztem Thinking-/Reasoning-Modus gezielt mit einer festen Denktiefe arbeiten soll. In der Oberfläche erscheint dafür im Facets-Editor eine passende Auswahl statt eines freien Textfelds.

Typische Werte sind:

• none für keinen zusätzlichen Thinking-Level
• low für niedrigen Denkaufwand
• medium für mittleren Denkaufwand
• high für hohen Denkaufwand

Praktisch bedeutet das:

• du kannst denselben Thinking-Level strukturiert direkt am Chat, Thread oder an einer Aufgabe hinterlegen
• bei unterstützten Modellen lässt sich der Wert in der Oberfläche komfortabel als Auswahl pflegen
• wenn zusätzlich im Chat-Input ein Thinking Level gewählt wurde, gewinnt das gesetzte Facet thinkingLevel für die Ausführung

Facet-Definitionen in den Einstellungen pflegen

In den Facet-Einstellungen verwaltest du die eigentlichen Definitionen eines Facets – also zum Beispiel Key, Bezeichnung, Beschreibung, Typ/Range, Icon und die erlaubten Spaces.

Wichtig für den Alltag:

• Das Suchfeld filtert die Liste direkt beim Tippen.
• Beim Leeren der Suche erscheint sofort wieder die vollständige Liste.
• Beim Erstellen werden technische Keys automatisch in ein stabiles Format überführt. Aus Test Project! wird zum Beispiel testProject.
• Doppelte Keys lassen sich nicht speichern. Wenn ein Key bereits existiert, zeigt CLYE AI einen Konflikt an und du musst einen anderen Key wählen.
• Wenn du ein Facet bearbeitest, bleiben Icon und Space-Zuordnung erhalten, solange du sie nicht bewusst änderst.
• Beim Bearbeiten einer Facet-Definition wird die Domain nicht zusätzlich als eigenes Label direkt unter der Bezeichnung eingeblendet. So bleibt der Kopfbereich kompakter; Domain und Range pflegst du weiterhin im eigentlichen Schema-Bereich.

Facets als veraltet markieren

Wenn ein Facet nicht mehr neu verwendet werden soll, kannst du es als veraltet markieren.

Das bedeutet:

• das Facet bleibt für bestehende Daten nachvollziehbar
• neue Zuweisungen werden verhindert
• in den Einstellungen ist der Status als Veraltet sichtbar
• optional kannst du einen Nachfolger hinterlegen, damit Teams auf das richtige neue Facet umstellen

Das ist besonders nützlich, wenn du ein altes Fachfeld ablösen willst, ohne bestehende Daten oder Automationen sofort umzubauen.

Facet-Schema: Ausgangs- und Zieltyp

Ein Schema beschreibt die Bedeutung eines Facets. Es beantwortet zwei einfache Fragen:

• Für wen gilt diese Aussage? Das ist die domain – der Ausgangs- oder Subjekt-Typ.
• Was ist bzw. welchen Typ hat ihr Wert? Das ist die range – der Ziel- oder Wert-Typ.

domain und range sind die etablierten RDF-Begriffe. In CLYE AI lassen sie sich deshalb auch als „gilt für“ und „Wert ist“ lesen.

vater:
  domain: person
  range: mann
mann:
  range: person

Im Beispiel bedeutet das:

• Das Facet vater gilt für eine person.
• Der Wert von vater ist ein mann.
• mann erweitert die Typ-Hierarchie: Ein Mann ist auch eine person.

Da Facets in CLYE AI sowohl Beziehungen als auch Typen ausdrücken können, wird range auch für diese Typ-Hierarchie genutzt. Bei einem Beziehungs-Facet wie vater beschreibt es den Typ seines Werts; bei einem Typ-Facet wie mann beschreibt es dessen allgemeineren Typ.

Kardinalität und inverse Beziehungen

Für sichere Query-Planung reichen domain und range allein nicht immer aus. Sinnvoll sind zusätzlich Schemaeigenschaften wie:

• Kardinalität, zum Beispiel zero-or-many, zero-or-one, exactly-one
• Inverse Beziehung, wenn ein Rückpfad fachlich definiert ist
• Erwartete Identität oder Schlüssel, wenn Beziehungen über stabile Referenzen aufgelöst werden

Beispiel:

invoicePositions:
  domain: invoice
  range: invoicePosition
  cardinality: zero-or-many
  inverse: invoice

Diese Angaben helfen bei Pfadauflösung, Aggregation, Dublettenvermeidung und Ergebnis-Erklärung.

N-äre Beziehungen mit eigener Beziehungsentität

Nicht jede fachliche Beziehung lässt sich sauber als reines binäres Facet ausdrücken. Sobald eine Beziehung eigene Attribute trägt, sollte sie als eigene Entität modelliert werden.

Beispiel:

assignment:
  person: person
  project: project
  role: assignmentRole
  validFrom: date
  validTo: date

Damit lassen sich Rolle, Zeitraum, Status oder Quelle sauber modellieren, statt sie in ein zu schwaches binäres Facet zu pressen.

Expansion

Auf Basis des Schemas kann CLYE AI die impliziten Typen einer Aussage erweitern. Aus:

{
  "name": "Simon",
  "vater": {
    "name": "Johannes"
  }
}

wird konzeptionell:

{
  "type": ["person"],
  "name": "Simon",
  "vater": {
    "type": ["mann", "person"],
    "name": "Johannes"
  }
}

Die Expansion ergänzt abgeleitete Typen; die ursprünglichen Daten bleiben dabei die Quelle der Aussage. Simon wird über die domain von vater als Person erkannt. Johannes wird über deren range als Mann und über die Typ-Hierarchie zusätzlich als Person erkannt.

Wichtig ist dabei: Diese Inferenz folgt ausschließlich aus dem versionierten Facet-Schema. Sie ist keine Vermutung auf Basis von Textähnlichkeit, Namensähnlichkeit oder implizitem Weltwissen des Systems. Dadurch bleibt nachvollziehbar, warum ein Objekt als bestimmter Typ erscheint.

Wissensstatus und Provenance

Damit Aussagen zuverlässig nutzbar bleiben, muss ihre Herkunft unterscheidbar sein. Fachlich relevant ist mindestens die Unterscheidung zwischen:

• direkten Aussagen aus einer Quelle oder einem Tabellen-Mapping
• abgeleiteten Aussagen aus Facet-Schema und Inferenzregeln
• extrahierten Aussagen aus Dokumenten oder LLM-gestützter Analyse, gegebenenfalls mit Unsicherheit

Die Originaldaten bleiben maßgeblich. Expansion ergänzt nachvollziehbares Typwissen, ersetzt aber nicht die Quellaussage.

Konzeptionelles Beispiel

Aus einer Rechnungszeile könnte eine direkte Aussage stammen:

• invoice.number = "RE-2026-0042"
• Herkunft: ERP-Tabelle
• Mapping-Version: sales-mapping v12

Aus dem Schema könnte zusätzlich eine abgeleitete Aussage entstehen:

• Johannes ist person
• Herkunft: abgeleitet aus vater, domain und range
• Schema-Version: facet-schema v5
• Ableitungsregel: Typ-Expansion über domain und range

Aus einer Dokumentextraktion könnte eine weitere Aussage kommen:

• contractingParty = "Beispiel GmbH"
• Herkunft: extrahiert aus PDF
• Extraktionslogik: invoice-extractor v3
• Vertrauensniveau: zum Beispiel mittel oder mit Konfidenz

Für LLM, UI, Debugging und Auditing sollte deshalb erkennbar sein:

• aus welcher Quelle eine Aussage stammt
• welche Mapping-, Schema- oder Extraktionsversion verwendet wurde
• ob die Aussage direkt, abgeleitet oder extrahiert ist
• wann sie erzeugt oder beobachtet wurde
• welches Vertrauensniveau oder welche Konfidenz vorliegt, falls relevant

Suchen mit Facet-Pfaden

Facet-Pfade erlauben Abfragen über Eigenschaften und verschachtelte Beziehungen. Zum Beispiel findet folgende Abfrage alle Männer namens Johannes – unabhängig davon, ob sie als Vater oder an einer anderen Stelle vorkommen:

mann.name = "Johannes"

Die gleiche Logik funktioniert auch für verschachtelte Daten. Die Schema-Expansion sorgt dafür, dass nicht nur explizit gesetzte, sondern auch aus Beziehungen abgeleitete Typen durchsuchbar sind.

Typische Einsatzfälle

• Suchen und Filtern: Inhalte oder Entitäten nach Eigenschaften und Beziehungen finden, etwa alle Personen einer Abteilung oder alle Männer namens Johannes.
• Kategorisieren: Einheitliche Metadaten für Dokumente, Chunks und andere Inhalte definieren.
• Zugriffssteuerung: Facet-Werte können im Zugriffsfilter verwendet werden, wenn sie aus vertrauenswürdigen und deterministischen Quellen stammen.
• Wissensgraphen: Beziehungen aus strukturierten Daten, Dokumenten und Tabellen nutzbar machen.

Für Zugriffskontrolle gilt eine strenge Trennung: Fachfacets eignen sich für Suche, Filter und Kontext. Rechteausweitung darf nur auf vertrauenswürdigen, deterministischen und nachvollziehbaren Quellen oder Policies beruhen. Unsichere LLM- oder Dokument-Extraktion sowie unsichere Identitätsauflösung dürfen keine zusätzlichen Rechte erzeugen. Im Zweifel gilt deny-by-default.

Mehr zur Zugriffsteuerung: Zugriffsfilter

Architekturvergleich: Palantir Ontology und CLYE AI Facets

Dieser Vergleich hilft, das Facet-Modell von CLYE AI gegenüber dem Ontology-Ansatz von Palantir Foundry einzuordnen. Er dient der fachlichen Orientierung und ersetzt keine vollständige Produkt- oder Architekturentscheidung.

Kurz gesagt:

• Palantir bündelt Wissensmodell, Beziehungen und governierte Aktionen in einer gemeinsamen Ontology.
• CLYE AI trennt bewusst zwischen Wissen (Facets), Aktion (MCP Tools) und Prozess (Tasks und Events).

Diese Trennung ist kein Mangel, sondern ein Architekturprinzip: Das Wissensmodell bleibt stabil und fachlich erklärbar, während Werkzeuge und Abläufe lose gekoppelt bleiben.

Die drei Schichten in CLYE AI

In CLYE AI übernehmen drei Bausteine unterschiedliche Rollen:

• Facets beschreiben Entitäten, Eigenschaften, Beziehungen, Typen und fachliche Pfade.
• MCP Tools führen Aktionen aus. Ihre Parameter können sich auf Facet-Pfade beziehen.
• Tasks und Events transportieren Arbeitskontext, Zuständigkeiten und Prozesszustände für Menschen und Assistenten.

Die gemeinsame Sprache zwischen diesen Schichten sind Facet-Pfade wie product.sku, customer.name oder invoicePositions.netAmount. Dadurch lässt sich derselbe Fachkontext über Suche, Queries, Aufgaben, Tools und Automationen hinweg verwenden.

Vergleich im Überblick

Aspekt	Palantir Ontology	CLYE AI Facets
Paradigma	Gemeinsames Modell für Object Types, Link Types und Action Types	Getrennte Schichten für Facets, MCP Tools sowie Tasks und Events
Identity Resolution	Muss vor der Ontology in der Pipeline gelöst werden	Ist Teil des Modells und kann sicher, unsicher oder offen bleiben
Granularität	Häufig über separate Object Types und Link Types	Auch über verschachtelte Facets als virtuelle Tabellen
Aktionen	Direkt an die Ontology und Object Types gebunden	Entkoppelt über MCP Tools mit Facet-Pfaden als Kontext
Write-back	Teil der Action-Governance	Typischerweise ereignisbasiert über Events und Automationen
Mensch und KI	Unterschiedliche Produktwelten für operative Nutzung und KI	Gemeinsamer Arbeitskontext über Tasks, Events und Tools
Provenance	Vor allem über Pipeline-Lineage nachvollziehbar	Teil des Fachmodells: direkt, abgeleitet oder extrahiert
Weltannahme	Tendenziell stärker geschlossen modelliert	Explizit Open World mit Unterscheidung zwischen fehlend, unbekannt und verneint

Warum CLYE AI Wissen, Aktion und Prozess trennt

Palantir modelliert Object Types, Link Types und Action Types gemeinsam in einer Ontology. Das ist stark für hochgradig governierte Enterprise-Szenarien, in denen Aktionen eng an Objekttypen, Rollenmodelle und Write-back-Prozesse gebunden sind.

CLYE AI setzt stattdessen auf lose Kopplung:

1. Facets beschreiben die fachliche Bedeutung.
2. MCP Tools nutzen diese Bedeutung, um passende Parameter, Kontext und Vorschläge bereitzustellen.
3. Tasks und Events machen denselben Fachkontext in Arbeitsabläufen nutzbar.

So bleibt das Wissensmodell unabhängig davon nutzbar, welches Tool eine Aktion ausführt oder welches System später auf ein Ereignis reagiert.

Identity Resolution: nicht nur vorab, sondern im Modell sichtbar

Ein wesentlicher Unterschied liegt im Umgang mit Identität.

Palantir erwartet in der Regel stabile, eindeutige Objektschlüssel. Wird dieselbe Entität aus mehreren Quellen mit unterschiedlichen Schlüsseln geliefert, muss diese Auflösung vorab in der Datenpipeline erfolgen.

CLYE AI behandelt Identitätsauflösung als fachlichen Teil des Modells. Konzeptionell sind mindestens drei Zustände wichtig:

• kanonisch oder verifiziert aufgelöst
• Kandidatenzuordnung mit Begründung oder Konfidenz
• nicht aufgelöste Referenz

Gerade bei Dokumenten, E-Mails, Extraktion oder unvollständigen Fremdsystemen ist das wichtig: Ein Name allein erzeugt keine stille Gleichsetzung. Unsicherheit bleibt sichtbar und kann später gezielt geprüft oder aufgelöst werden.

Granularität ohne Modellbruch

In Palantir werden unterschiedliche Granularitäten oft als getrennte Object Types modelliert, zum Beispiel Produkt, Bestandsobjekt und Einzelinstanz. Beziehungen zwischen diesen Ebenen werden explizit über Link Types und bei Änderungen oft zusätzlich über Actions beschrieben.

In CLYE AI kann dieselbe Fachstruktur auch verschachtelt modelliert werden, zum Beispiel:

product → stockItems[] → individualItems[]

Solche Listen werden als virtuelle Tabellen behandelt. Dadurch lassen sich Felder wie individualItems.status oder individualItems.serialNumber direkt über Facet-Pfade abfragen, ohne dass jede Granularität physisch als eigener Objekttyp materialisiert werden muss.

Aktionen über MCP Tools statt eingebetteter Action Types

In CLYE AI sind Aktionen nicht Teil des Facet-Schemas, sondern über MCP Tools angebunden. Tool-Parameter können auf Facet-Pfade referenzieren.

Beispiel:

MCP Tool: transferStock
Parameter:
  sku: product.sku
  fromLocation: stockItem.location
  toLocation: string
  quantity: integer

Daraus ergeben sich mehrere praktische Vorteile:

• kontextuelle Tool-Auswahl auf Basis des aktuellen Fachkontexts
• Autocomplete und Vorschläge entlang bekannter Facet-Pfade
• Wiederverwendbarkeit desselben Tools über unterschiedliche Datenquellen und Systemanbindungen hinweg

Write-back erfolgt dabei typischerweise nicht als fest eingebauter Teil des Wissensmodells, sondern über Events und Automationen. Nach einer Tool-Ausführung können mehrere Zielsysteme reagieren, ohne dass das Tool selbst neu modelliert werden muss.

Tasks als gemeinsamer Arbeitskontext für Menschen und Assistenten

Ein weiterer Unterschied betrifft die Prozessschicht. In CLYE AI sind Tasks die gemeinsame Einheit für Personen und KI-Assistenten. Beide arbeiten mit demselben Kontext, denselben Referenzen und denselben verfügbaren Tools.

Beispielhaft kann eine Aufgabe wie folgt gedacht werden:

Task: Retoure prüfen
Kontext:
  product.sku: 12345
  individualItem.status: RETURNED
  returnOrder.reason: Zu klein
Verfügbare Tools:
  inspectItem(...), restockItem(...), refundCustomer(...)

Dadurch bleibt der Übergang zwischen menschlicher Bearbeitung, Assistenz und Automation konsistent.

Provenance und Open World als Teil des Modells

Für CLYE AI ist entscheidend, dass Aussagen nicht nur vorhanden sind, sondern auch einordbar bleiben. Deshalb unterscheidet das Modell zwischen:

• direkten Aussagen aus Tabellen, APIs oder anderen Primärquellen
• abgeleiteten Aussagen aus Schema und Inferenz
• extrahierten Aussagen aus Dokumenten oder KI-gestützter Analyse

Ebenso wichtig ist die Open-World-Sicht:

• missing: Ein Feld fehlt in diesem Objekt
• unknown: Zu dieser Aussage liegt kein Wissen vor
• explizit verneint: Eine autoritative Quelle bestätigt, dass etwas nicht gilt

Damit ist ein fehlender Vertrag nicht automatisch dasselbe wie ein bestätigter Nicht-Vertrag. Gerade bei Dokumenten, Teilmengen und unsicheren Extraktionen ist diese Unterscheidung fachlich wichtig.

Wann welcher Ansatz stärker ist

Der Vergleich ist nicht als pauschales Werturteil zu verstehen. Unterschiedliche Architekturen sind für unterschiedliche Ziele optimiert.

Palantir ist besonders stark, wenn:

• Aktionen streng governierbar sein müssen
• operative Write-back-Prozesse eng mit Objekttypen verbunden sind
• Rollen, Berechtigungen und Audit-Trails tief in derselben Modellschicht verankert sein sollen
• sehr große, stark operationalisierte Objektlandschaften verwaltet werden

CLYE AI Facets sind besonders stark, wenn:

• Wissen aus Dokumenten, Tabellen, JSON-Strukturen und Ereignissen gemeinsam nutzbar sein soll
• Identität nicht immer sofort vollständig geklärt ist
• unterschiedliche Granularitäten flexibel modelliert werden müssen
• Fachkontext über Suche, Queries, Aufgaben, Tools und Automationen konsistent wiederverwendet werden soll

Kernbotschaft

Palantir formt Wissen, Beziehungen und Aktionen zu einer stark governierbaren operativen Ontology. CLYE AI trennt diese Ebenen bewusst und lässt Unsicherheit, Herkunft und variable Granularität im Wissensmodell sichtbar.

Für CLYE AI ist genau diese Trennung zentral: Facets modellieren Wissen, MCP Tools führen Aktionen aus, und Tasks sowie Events tragen denselben Fachkontext in Prozesse weiter.

Quelle für die Einordnung von Palantir: Palantir Foundry Documentation zu Ontology, Object Types, Link Types und Action Types.

Tabellen zu Facets mappen

Tabellen lassen sich in dasselbe Modell überführen. Jede Tabelle wird dafür einem fachlichen Entitätstyp zugeordnet. In der Oberfläche wählst du dafür optional ein tabellenweites Typ-Facet aus dem Wissensmodell. Dieses Typ-Facet beschreibt, welchen fachlichen Typ die Ergebnisobjekte einer Tabelle haben, zum Beispiel sale, product oder stock. Anschließend wird jede Spalte auf genau einen eindeutigen Facet-Pfad abgebildet. Eindeutige Schlüssel (unique constraints) identifizieren dieselbe Entität über Tabellen hinweg.

Wichtig für die Pflege im Schema-Dialog:

• Spalten-Zuordnungen werden nicht mehr als freie Facet-Metadaten gepflegt, sondern als durchsuchbare Auswahl aus dem Wissensmodell.
• Jede Spalte kann höchstens einen Facet-Pfad erhalten. Derselbe Facet-Pfad sollte innerhalb einer Tabelle nicht mehrfach vergeben werden.
• Facet-Pfade lassen sich im Bearbeitungsdialog jetzt schrittweise über beliebig viele Segmente aufbauen.
• Nach jedem gewählten Segment zeigt die Auswahl nur noch fachlich passende Anschluss-Facets, deren Domain zum vorherigen Objekt im Pfad passt.
• Der aktuell gewählte Pfad wird als Segmentfolge angezeigt. Über Letztes Facet entfernen kannst du schrittweise wieder zum vorherigen Stand zurückgehen.
• Tabellenweite Typ-Facets sind optional und werden ebenfalls aus dem Wissensmodell gewählt.
• Bereits vorhandene ältere Zuordnungen außerhalb des aktuellen Wissensmodells bleiben zur Einordnung sichtbar, lassen sich aber nicht wie normale Modell-Treffer neu auswählen.
• Vollständige mehrstufige Pfade werden zusätzlich serverseitig validiert. Ungültige oder fachlich nicht anschlussfähige Kombinationen lassen sich dadurch nicht dauerhaft speichern.

Dadurch bleiben Tabellen-Mappings fachlich konsistent, besser durchsuchbar und zuverlässiger validierbar.

Fachlicher Entitätstyp statt Tabellenstruktur

Die Datenbank kann beispielsweise die Tabellen verkaeufe und produkte enthalten. Im Fachmodell repräsentieren ihre Zeilen die Entitätstypen sale und product. In der Schemaübersicht kann zusätzlich ein tabellenweites Typ-Facet als Badge sichtbar sein. So erkennst du direkt, welchem fachlichen Typ eine Tabelle zugeordnet ist, ohne erst den Bearbeitungsdialog zu öffnen:

• Facet: sale für Verkaufstabellen
• Facet: product für Produkttabellen

Im Bearbeitungsdialog wählst du dieses Typ-Facet unter Tabellenweites Facet aus. Für Spalten nutzt du die eigene Auswahl Facet-Zuordnung mit genau einem Facet-Pfad je Spalte. Wenn du einen mehrstufigen Pfad brauchst, wählst du zuerst das erste Facet und ergänzt danach Schritt für Schritt die nächsten Segmente. Die Oberfläche zeigt dabei jeweils nur passende Anschluss-Facets und blendet den aktuellen Pfad als Segmentfolge ein.

Die Datenbank kann beispielsweise die Tabellen verkaeufe und produkte enthalten. Im Fachmodell repräsentieren ihre Zeilen die Entitätstypen sale und product:

# Tabelle verkaeufe
domain: sale
mapping:
  produktId: product.id
  preis: sale.price
  menge: sale.amount

# Tabelle produkte
domain: product
mapping:
  id: product.id
  name: product.name
unique:
  - [id]

Eine Zeile aus verkaeufe beschreibt somit einen Verkauf und referenziert über product.id ein Produkt:

{
  "product": [{ "id": "..." }],
  "sale": [{ "price": 234, "amount": 1 }]
}

Die Zuordnung zum Entitätstyp ermöglicht ein sauberes Business-Modell: Abfragen verwenden Begriffe wie sale, product, customer oder invoice statt physischer Tabellen- und Spaltennamen. Unterschiedliche Quellsysteme oder Tabellen können Aussagen über denselben Entitätstyp liefern. Umgekehrt kann sich die Datenbankstruktur ändern, ohne dass Fachbegriffe, Facet-Pfade und darauf basierende Abfragen angepasst werden müssen.

Identity Resolution als Modellbestandteil

Eindeutige Schlüssel sind ideal, aber nicht immer verfügbar. Besonders bei Dokumenten, Extraktion oder externen Referenzen kann eine fachliche Referenz schon bekannt sein, obwohl die kanonische Entität noch nicht sicher feststeht.

Konzeptionell sind deshalb mehrere Zustände wichtig:

• kanonisch oder verifiziert aufgelöst
• Kandidatenzuordnung mit Begründung oder Konfidenz
• nicht aufgelöste Referenz

Ein Name allein darf keine stille, harte Gleichsetzung erzeugen. Eine Identitätsauflösung muss nachvollziehbar und gegebenenfalls als unsicher markiert sein.

Abfragen ohne from

Eine Query enthält Facet-Pfade, optionale Aggregationen und beliebige Filter auf Facet-Pfaden. Eine explizite Basistabelle ist nicht nötig: CLYE AI bestimmt sie aus den verwendeten Facets und ihren Entitätstypen.

Das bedeutet nicht, dass die Query-Sprache fachliche Eindeutigkeit überspringt. Statt einer physischen Tabelle arbeitet sie mit einem fachlichen Root, einer Basisentität und einer Granularität (Grain).

Sichere und erklärbare Query-Auflösung

Damit Queries fachlich korrekt und nachvollziehbar bleiben, muss ihre Auflösung explizit erklärbar sein.

Root, Basisentität und Grain

Für jede Query ist fachlich wichtig:

• Root oder Basisentität: Auf welcher Entität basiert die Auswertung, zum Beispiel sale, invoice oder invoicePosition?
• Granularität (Grain): Liefert die Query eine Zeile pro Rechnung, pro Position, pro Kunde oder pro Ereignis?
• Join-Pfad: Über welche fachlichen Beziehungen werden weitere Felder erreicht?

Bei explorativen Ad-hoc-Queries kann das System einen sinnvollen Vorschlag ableiten. Für Dashboards, gespeicherte Queries, Automationen und agentische Entscheidungen sollten Root, Grain und Gruppierung explizit sein oder vor Ausführung bestätigt werden.

Beispiel: Umsatz je Produkt

product.id, product.name, sum(sale.price) as umsatz

sum(sale.price) benötigt Daten des Entitätstyps sale; die Tabelle verkaeufe kann deshalb als Query-Root dienen. product.name gehört zum Entitätstyp product. Da verkaeufe.produktId und produkte.id beide auf product.id gemappt sind, lässt sich daraus ein Join ableiten und beispielsweise folgendes SQL erzeugen:

SELECT
  p.id AS product_id,
  p.name AS product_name,
  SUM(v.preis) AS umsatz
FROM verkaeufe AS v
JOIN produkte AS p ON p.id = v.produktId
GROUP BY p.id, p.name;

Die Query beschreibt damit ausschließlich die fachliche Sicht: Umsatz nach Produkt. Tabellen, Fremdschlüssel und Join-Bedingung sind Implementierungsdetails des Mappings.

Beispiel: Filter auf einem verbundenen Entitätstyp

Filter können auf jedem bekannten Facet-Pfad stehen – auch wenn dieser nicht im Ergebnis erscheint:

sum(sale.price) as umsatz
where product.name = "Laptop Pro"

Die Aggregation bestimmt sale als Root-Entitätstyp. Der Filter benötigt product.name und löst deshalb automatisch denselben Join aus:

SELECT SUM(v.preis) AS umsatz
FROM verkaeufe AS v
JOIN produkte AS p ON p.id = v.produktId
WHERE p.name = 'Laptop Pro';

Mehrdeutige Pfade dürfen nicht geraten werden

Automatische Joins dürfen nur dann aufgelöst werden, wenn der fachliche Pfad eindeutig ist. Unique Constraints bestimmen technische Identität und mögliche Joinbedingungen. Sie ersetzen aber nicht die fachliche Entscheidung, wenn mehrere semantisch gültige Pfade existieren.

Beispiel für eine Mehrdeutigkeit:

• invoicePosition → invoice → billingCustomer
• invoicePosition → order → orderingCustomer

Eine Query auf customer.name ausgehend von invoicePosition darf in so einem Fall nicht selbst entscheiden, welcher Kunde gemeint ist. Das System muss die möglichen Pfade enumerieren und eine eindeutige Auswahl oder präzisere Query verlangen, zum Beispiel über:

• einen präziseren Pfad wie billingCustomer.name
• einen expliziten Root wie root: invoice
• ein explizites Grain wie root: invoicePosition

Grouping und Grain-Wechsel sichtbar machen

Die bequeme Regel „nicht aggregierte Felder bestimmen die Gruppierung“ ist für Exploration nützlich, kann in persistierten oder automatisierten Queries aber missverständlich sein.

Deshalb gilt als Ausführungsprinzip:

• Für Ad-hoc-Queries darf implizites Grouping möglich sein.
• Query-Plan oder Erklärung sollte Root, Grain, Join-Pfad und effektives Grouping sichtbar machen.
• Bei Dashboards, gespeicherten Queries, Automationen und agentischen Entscheidungen sollten Gruppierung und Grain explizit sein oder bestätigt werden.
• Wenn ein zusätzliches nicht aggregiertes Feld das Grain ändert, sollte eine Warnung erfolgen.

Ergebnis-Erklärung

Zu einer nachvollziehbaren Query-Ausführung gehört konzeptionell eine Erklärung, die mindestens diese Punkte sichtbar machen kann:

• gewählter Root
• effektiver Grain
• verwendete Join-Pfade
• Quellen oder Mappings
• Listenexpansion oder Fan-out
• Gruppierung und Aggregationen
• relevante Ableitungen aus dem Facet-Schema

Open World, fehlende Informationen und Negation

Das Facet-Modell folgt fachlich einer Open-World-Assumption: Fehlende Information bedeutet grundsätzlich zunächst unbekannt, nicht automatisch falsch oder nicht existent.

Diese Unterscheidung ist wichtig:

• bekannte Aussage / exists: Eine Aussage ist im Wissensbestand vorhanden.
• missing: Ein Feld oder eine Angabe fehlt im betrachteten Objekt.
• unknown: Im betrachteten Wissensbestand ist zu dieser Frage keine Aussage bekannt.
• explizit verneinte Aussage: Eine Quelle bestätigt autoritativ, dass etwas nicht gilt.
• „hat keinen …“ oder not exists(...): Das darf nur als starkes Negationsergebnis behandelt werden, wenn für die Relation und den Datenbereich eine explizite Vollständigkeits- oder Closed-World-Basis vorliegt.

Diese Semantik ist ein Gestaltungs- und Spezifikationsprinzip. Die konkrete Query-Syntax kann sich weiterentwickeln.

Beispiel: fehlender Vertrag ist nicht automatisch kein Vertrag

„Kunden ohne bekannten Vertrag“ bedeutet fachlich etwas anderes als „Kunden, für die bestätigt ist, dass kein Vertrag existiert“.

• Im ersten Fall ist nur keine Vertragsaussage bekannt.
• Im zweiten Fall liegt eine explizite negative oder vollständigkeitsgestützte Aussage vor.

Gerade bei Dokumenten, Extraktion und partiellen Datenquellen ist diese Unterscheidung entscheidend. Sonst würden Lücken im Wissensbestand fälschlich als Negation interpretiert.

Zeitlichkeit als Modellierungsmuster

Zeit und Gültigkeit sind im Facet-Modell vorgesehen, aber nicht jedes Facet ist automatisch bitemporal.

Für zeitabhängige Sachverhalte sollten Standardfacets oder entsprechende Relationship- beziehungsweise Event-Muster genutzt werden, zum Beispiel:

• fachliche Gültigkeit: validFrom, validTo
• technische Beobachtung oder Erfassung: recordedAt, observedAt

Damit lassen sich zum Beispiel Vertragsgültigkeiten, Zuständigkeiten, Preiszeiträume oder beobachtete Ereignisse sauber modellieren.

Versionierung, Management und Reproduzierbarkeit

Facets, Mappings und Aussagen sind verwaltete Artefakte und folgen dem Prinzip nachvollziehbarer Änderungen. Fachlich relevant sind insbesondere:

• Facet-Schema
• Tabellen-Mappings
• Extraktionslogik
• fachliche Aussagen oder Beobachtungen

Diese Artefakte und ihre Änderungen sollten versionierbar und nachvollziehbar sein. Event-Sourcing unterstützt diese Nachvollziehbarkeit, ersetzt aber nicht alle Anforderungen an historische Reproduzierbarkeit. Für historische Ergebnisse können neben Ereigniszeit auch fachliche Gültigkeitszeit und eine definierte Query-Zeitbasis relevant sein.

Ausführungssemantik und Spezifikationsprinzipien

Die Query-Spezifikation wird weiter formalisiert. Bereits jetzt ist wichtig, welche Themen normativ geregelt werden müssen, damit die Ausführung sicher und erklärbar bleibt:

• Root, Basisentität und Grain
• Pfadauflösung und Ambiguitätsbehandlung
• Kardinalität und Join-Semantik
• Unterschied zwischen null, fehlend und unbekannt
• Listenexpansion und Fan-out
• Aggregation, Gruppierung und Deduplizierung
• Quellpriorität und Konfliktbehandlung
• Umfang der Inferenz
• Zeitbasis und historische Sicht
• Ergebnis-Erklärung und Provenance

Diese Sektion beschreibt bewusst Spezifikationsprinzipien, nicht bereits vollständig produktiv festgelegte Syntax.

Einordnung gegenüber verwandten Systemen

Das Facet-Modell ist eine virtuelle Knowledge-Graph-Semantic-Layer: Es verbindet ein RDF-inspiriertes Fachmodell mit JSON, Chunk-Metadaten und relationalen Tabellen. Der Graph muss dafür nicht in einen separaten Graph-Store kopiert werden; fachliche Abfragen können direkt in SQL übersetzt werden.

Die folgenden Systeme lösen jeweils verwandte, aber unterschiedliche Teile dieser Aufgabe:

System oder Ansatz	Schwerpunkt	Abgrenzung zum Facet-Modell
Palantir Ontology	Operatives Unternehmensmodell mit Objekten, Properties, Links, Actions, Functions und Governance.	Sehr ähnlich im Ziel eines gemeinsamen Fachmodells. Palantir ist breiter für operative Workflows und Governance; Facets sind leichtergewichtig und vereinheitlichen direkt Dokumente, extrahiertes JSON und Tabellen.
Microsoft Fabric und Power BI Semantic Models	BI-Modelle für Tabellen, Beziehungen, Kennzahlen, Dimensionen und Reports; Katalog- und Governance-Funktionen werden unter anderem durch Microsoft Purview bereitgestellt.	Starker Fokus auf Reporting und Kennzahlen. Facets modellieren zusätzlich generische Beziehungen, verschachtelte Objekte und Typ-Hierarchien – auch aus extrahierten Inhalten.
Databricks Unity Catalog	Einheitlicher Katalog, Zugriffssteuerung, Lineage, Auditing und Governance für Daten- und KI-Assets.	Unity Catalog verwaltet und schützt technische Assets wie Tabellen, Views, Funktionen und Modelle. Facets liefern darüber ein fachliches Objekt- und Beziehungsmodell, das über diese Assets abfragen kann.
Apache Spark SQL	Verteilte Verarbeitung und SQL/DataFrame-Zugriff auf Quellen wie JSON, Parquet und JDBC.	Spark ist eine Ausführungs-Engine, kein fachliches Modell. Spark kann Datenquellen verbinden; Facets geben Abfragen zuvor eine semantische Sprache und können Join-Pfade aus dem Fachmodell ableiten.
Snowflake Semantic Views	Geschäftliche Tabellen, Beziehungen, Fakten, Dimensionen und Kennzahlen direkt im Data Warehouse.	Sehr nah bei Analytics über relationale Daten. Facets erweitern diesen Ansatz auf Dokumente, Chunks und verschachtelte JSON-Listen sowie auf Typ-Inferenz aus Beziehungen.
RDF, RDFS und OWL	Standardisiertes Wissensgraph-Modell mit Klassen, Properties, domain, range und formaler Inferenz.	RDF trennt semantisch Properties und Klassen; Facets können Beziehung und Typ mit einem einheitlichen Konzept ausdrücken. Die Query-Sprache ist auf fachliche Pfade statt auf SPARQL-Tripel-Patterns ausgerichtet.
JSON-LD	Standardisierte JSON-Serialisierung für Linked Data.	JSON-LD beschreibt und serialisiert Graphen, enthält aber kein Tabellen-Mapping, keine fachliche Query-Sprache und keine SQL-Join-Planung.
Virtual Knowledge Graphs wie Ontop	RDF-Mappings über relationale Daten und Übersetzung von SPARQL in SQL.	Technisch sehr verwandt. Ontop arbeitet mit RDF, Ontologien, R2RML und SPARQL; Facets stellen dieselben Daten über ein kompakteres Fachmodell und Facet-Pfade bereit.
Property Graphs, z. B. Neo4j	Speicherung und Traversierung von Knoten, Beziehungen und Labels in einem Graph-Store.	Facets müssen nicht materialisiert werden und bleiben auf Dokument-, JSON- und Tabellendaten abbildbar. Zudem kann ein Facet sowohl Beziehung als auch Typ sein.

Zusammengefasst verbinden Facets Aspekte dieser Ansätze: das Fachmodell einer Ontology, die Flexibilität von Graph-Daten, den Zugriff auf relationale Daten einer Semantic Layer und die unmittelbare Nutzbarkeit extrahierter Dokumentstrukturen.

Besonderheit: Beziehung erzeugt Typwissen

Die zentrale Vereinfachung gegenüber RDF ist, dass ein Facet nicht strikt als Property oder Klasse behandelt werden muss. Das Schema erzeugt Typwissen aus einer Beziehung:

vater:
  domain: person
  range: mann
mann:
  range: person

Aus der Aussage Simon vater Johannes folgt damit:

• Simon ist eine person, weil person der Ausgangstyp (domain) von vater ist.
• Johannes ist ein mann, weil mann der Werttyp (range) von vater ist.
• Johannes ist außerdem eine person, weil mann in der Typ-Hierarchie eine person ist.

Diese Ableitung beruht auf explizitem Schemawissen. Sie entsteht nicht aus einer unsichtbaren Heuristik oder einem frei ratenden Graphmodell.

Fachmodell statt physischer Datenstruktur

Die Tabellen-Entitätstypen führen dieses Prinzip für relationale Daten fort: Eine Query beschreibt sale, product, customer oder invoice statt Tabellen, Fremdschlüssel und Join-Bedingungen. Mappings verbinden diese Fachbegriffe mit den jeweiligen Quellsystemen; gemeinsame Facet-Pfade und eindeutige Schlüssel liefern die Informationen, aus denen SQL-Joins abgeleitet werden.

Damit bleiben Queries stabil, wenn Tabellen oder Spalten umbenannt, Daten auf mehrere Quellen verteilt oder zusätzliche Datenquellen angebunden werden. Bei mehreren möglichen Quellen oder Pfaden muss die Auflösung eindeutig festgelegt oder die Query präzisiert werden.

Kurz gesagt

Ein Facet ist in CLYE AI sowohl eine Eigenschaft beziehungsweise Beziehung als auch ein möglicher Typ. Das Schema beschreibt, für wen eine Aussage gilt (domain) und welchen Typ ihr Wert hat (range). Expansion ergänzt daraus nachvollziehbares Typwissen. Tabellen-Mappings, Identitätsregeln und Query-Auflösung sorgen dafür, dass Datenquellen fachlich einheitlich nutzbar werden – ohne stillschweigende Vermutungen bei Mehrdeutigkeit, Negation, Identität oder Zugriffskontrolle.