Dokument-Typ: Architektur-Spezifikation

Kontext: Semantic Graph Layer · Knowledge Engineering

Status: Public Standard

Gültigkeit: Aivis-OS Core Pipeline

Referenzen:

Entity Inventory
Semantic Graph Layer
Transport-Safe Content Layer

1. Zweck der Spezifikation

Diese Spezifikation definiert die technischen Regeln, Datenmodelle und Validierungskriterien für den Aufbau und Betrieb des Semantic Graph Layers in Aivis-OS.

Ziel ist es, Bedeutung, Relationen und Gültigkeit so zu modellieren, dass:

interne Widersprüche speicherbar bleiben
externe Schnittstellen ausschliesslich deterministische Zustände exponieren
Konflikte explizit identifizier- und auflösbar sind

2. Grundsatzregeln

2.1 Determinismus am Interface (verbindlich)

Externe Ausgaben (Machine Interface Layer, JSON-LD, TSCL, APIs)
dürfen zu keinem Zeitpunkt widersprüchliche Assertions exponieren.

Für jeden Kontext gilt:

maximal eine kanonische Assertion
alle anderen konkurrierenden Assertions bleiben intern

2.2 Multiplicity im Graph Core (verbindlich)

Der interne Semantic Graph muss konkurrierende Assertions parallel speichern können.

Ein Verlust von konkurrierender Information gilt als Architekturfehler.

3. Datenmodell

3.1 Entität (Node)

Jede Entität im Graph referenziert genau eine Entität aus dem Cluster-Level Entity Inventory.

Eigenschaften:

entity_id (Foreign Key, stabil)
schema_type
canonical_name

Der Semantic Graph erzeugt keine eigenen Entitäten.

3.2 Assertion (Edge)

Der Semantic Graph verwaltet Bedeutung ausschliesslich in Form von Assertions. Eine Assertion ist eine gerichtete, typisierte Aussage:

Subject (Entity)

→ Predicate (Edge Type)

→ Object (Entity | Literal)

Assertions sind First-Class Objects.

3.3 Pflichtattribute jeder Assertion

Jede Assertion muss folgende Attribute besitzen:

Attribut	Beschreibung
`assertion_id`	stabile, deterministische ID
`subject_entity_id`	Referenz auf Entität
`predicate`	typisierte Relation
`object`	Entität oder Literal
`scope`	Kontext (z. B. Region, Organisation, Markt)
`valid_from`	Beginn der Gültigkeit
`valid_through`	Ende der Gültigkeit (optional)
`provenance`	Quelle
`confidence`	numerische Gewichtung (0.0 – 1.0)
`status`	ACTIVE \| DEPRECATED \| CONFLICT

4. Typisierung der Relationen (Predicate Classes)

Ungetypte Relationen sind nicht zulässig.

Jede Assertion muss einem der folgenden Relationstypen zugeordnet sein:

4.1 Referential Relations

(z. B. mentions, about)

schwache semantische Bindung
keine Autoritätsübertragung

4.2 Structural Relations

(z. B. hasPart, isPartOf, subsidiaryOf)

definieren Hierarchien
dürfen keine Zyklen erzeugen

4.3 Attributional Relations

(z. B. author, manufacturer, ceo, copyrightHolder)

hochkritisch
dürfen pro Kontext nur eine kanonische Assertion besitzen

4.4 Contextual Relations

(z. B. competitor, isSimilarTo, regulatedBy)

dienen thematischer Einordnung
konfliktfähig

5. Konfliktmodell

5.1 Konflikterkennung

Ein Konflikt liegt vor, wenn:

zwei ACTIVE Assertions
mit identischem subject + predicate + scope
unterschiedliche object-Werte besitzen

In diesem Fall:

Status = CONFLICT
keine automatische Exposition

5.2 Konfliktauflösung (Resolution Rules)

Die Auswahl der kanonischen Assertion erfolgt nach folgender Priorisierung:

Scope Match (exakter Kontext schlägt generischen)
Temporal Validity (aktuell gültig schlägt historisch)
Confidence Score
Governance Override (manuelle Festlegung)

Nur die resultierende Assertion erhält den Status CANONICAL.

6. Exposition (Collapsed State)

Der Semantic Graph Layer liefert nach aussen ausschliesslich:

Assertions mit Status CANONICAL
exakt eine Assertion pro (entity, predicate, scope)

Alle anderen Assertions bleiben:

intern abrufbar
auditierbar
versionierbar

7. Versionierung & Mutation

7.1 Änderungen

Eine Änderung an Bedeutung erfolgt nicht durch Überschreiben, sondern durch:

Hinzufügen einer neuen Assertion
zeitliche oder statusbezogene Deaktivierung der alten

Historische Wahrheiten bleiben erhalten.

7.2 Löschung

Physische Löschung von Assertions ist nicht zulässig, ausser bei nachweislich fehlerhafter Ingestion.

8. Validierung & Testing

8.1 Graph Integrity Checks

Pflichtprüfungen:

Orphan Assertion Check (jede Assertion referenziert existierende Entitäten)
Cycle Detection (keine zirkulären Structural Relations)
Determinism Check (keine widersprüchlichen Assertions im Exposed Graph)

8.2 Coverage Metrics

Empfohlene Metriken:

Assertion Density pro Entität
Verhältnis typisierter Assertions zu reinem Text
Anteil konflikthafter Assertions (Monitoring, kein Fehler)

9. Zusammenspiel mit anderen Layern

Entity Inventory liefert stabile Identitäten
Semantic Graph Layer modelliert Bedeutung & Konflikt
Transport-Safe Content Layer spiegelt kanonische Assertions
Projection Layer serialisiert deterministische Zustände

Zusammenfassung

Semantic Graph Engineering ist keine Datenmodellierungsaufgabe, sondern eine Governance-Disziplin für Bedeutung. Durch explizite Assertions, kontrollierte Konfliktfähigkeit und deterministische Exposition stellt Aivis-OS sicher, dass:

interne Realität vollständig abgebildet
externe Wahrnehmung eindeutig
maschinelles Vertrauen stabil

bleibt – auch unter probabilistischen Systemen.

Linktipp

Der Semantic Graph Layer verlagert Bedeutung von der Interpretation in die Architektur. Er erlaubt interne Vielstimmigkeit, ohne externe Ambiguität zu erzeugen.

Architektur-Übersicht

Alle Aivis-OS Core Architecture

Cluster-Level Entity Inventory Strategy

Context & Meaning Semantic Graph Engineering

Semantic Graph Layer