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.

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"
}

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

Tabellen zu Facets mappen

Tabellen lassen sich in dasselbe Modell überführen. Jede Tabelle wird dafür einem fachlichen Entitätstyp zugeordnet. Das technische Feld heißt auch hier domain: Es sagt aus, für welchen Typ von Objekt eine Tabellenzeile Aussagen liefert. So repräsentiert eine Zeile in verkaeufe einen sale, eine Zeile in produkte ein product. Der Entitätstyp ist unabhängig vom technischen Tabellennamen. Anschließend wird jede Spalte auf einen Facet-Pfad abgebildet. Eindeutige Schlüssel (unique constraints) identifizieren dieselbe Entität über Tabellen hinweg.

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:

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