Cluster-Level Entity Inventory Strategy

1. Architektonisches Prinzip

Global Identity vs. Local Mention

In der Aivis-OS Architektur wird die Identität einer Entität (Entity) strikt von ihrer Erwähnung (Mention) getrennt.

Das Kernproblem herkömmlicher SEO- oder Schema-Ansätze ist die Generierung von Daten auf URL-Ebene (Per-URL Inventory). Dieser Ansatz führt zwangsläufig zu Identity Drift, da er lokale Erwähnungen implizit als unabhängige Identitäten behandelt.

Aivis-OS erzwingt stattdessen ein Cluster-Level Inventory. Das Entitäts-Inventar ist kein Artefakt einer einzelnen Seite. Es ist ein Artefakt der Wissensdomäne (Knowledge Domain).

Definitionen

• Entity (Identität): Ein stabiles, kanonisches Objekt (z. B. „Allianz SE“, „John William Doe“, „Jahresbericht 2024“), das global im Cluster existiert.
• Mention (Vorkommen): Eine lokalisierte Referenz innerhalb einer URL (z. B. „Der Konzern“, „Herr Doe“, „Der Bericht“).
• Stable Anchor: Ein extern verifizierbarer Identifikator zur Reduktion von Ambiguität (Wikidata QID, LEI, ISIN, ORCID).

2. Das Anti-Pattern: Risiken von Per-URL-Inventaren

Wenn Systeme versuchen, Entitäten isoliert pro URL aufzubauen, entstehen strukturelle Defekte, die eine stabile KI-Repräsentation verhindern:

2.1 Fragmentierung der Identität (Duplicate Identities)

Szenario: Eine Organisation erscheint auf 40 Seiten unter Variationen wie „Allianz“, „Allianz SE“ und „Allianz Group“. Fehler: Ein Per-URL-Ansatz erzeugt 40 konkurrierende „Wahrheiten“. KI-Modelle können diese nicht deterministisch zusammenführen.

2.2 Instabilität der IDs

Werden IDs pro URL generiert (geminted), können sie clusterweit nicht stabil bleiben. Dies zerstört die Graphen-Kohäsion und macht langfristiges Diffing (Änderungsverfolgung) unmöglich.

2.3 Streuung der Verifikation (Anchor Verification Drift)

Unterschiedliche URLs weisen derselben Entität oft widersprüchliche oder fehlende Anker (z. B. falsche Social Profiles oder QIDs) zu. Das Ergebnis ist ein widersprüchlicher Knowledge Graph, den LLMs aufgrund von Inkonsistenz abwerten („Ambiguity Penalty“).

3. Die Aivis-OS Lösung: Cluster-Level Governance

Das Aivis-OS Inventar fungiert als Single Source of Truth („Golden Record“). Strukturierte Daten auf URL-Ebene sind lediglich eine Projektion dieser Wahrheit.

System-Vorteile

1. Deterministische Entitäts-Auflösung: Normalisierung und Deduplizierung erfolgen zentral und einmalig.
2. Verwaltete Stable Anchors: Externe Referenzen werden einmal verifiziert und global vererbt.
3. Aggregation: Attribute aus verschiedenen Quellen werden zu einem reichhaltigen Objekt angereichert.
4. Governance & Versionierung: Änderungen an einer Entität (z. B. Namenswechsel) werden atomar propagiert, nicht manuell über tausende Seiten verteilt.

4. Datenmodell & Implementierung

4.1 Cluster-Level Tables (Identity Layer)

Dies ist der Speicherort der Wahrheit.

4.2 URL-Level Tables (Context Layer)

Dies ist der Speicherort der Referenz.

4.3 ID-Minting Konvention

Aivis-OS generiert niemals neue Entitäts-IDs während der JSON-LD Generierung einer Einzelseite. IDs folgen einem deterministischen Format:

entity://{cluster_id}/{schema_type}/{slug}-{short_hash}

5. Implementierungs-Beispiel

Anstatt Varianten einer Person („John Doe“, „J. Doe“) mehrfach zu definieren, referenziert Aivis-OS das zentrale Objekt.

Cluster Inventory (Backend): Es existiert nur ein Datensatz für „John William Doe“ mit der verknüpften Wikidata-ID Q123456.

URL Projection (Output JSON-LD): Auf der Team-Seite wird keine neue Person definiert, sondern die existierende referenziert:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@id": "entity://cluster123/Person/john-william-doe-a1b2c3",
      "@type": "Person",
      "name": "John William Doe",
      "sameAs": ["https://www.wikidata.org/wiki/Q123456"]
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/team/john-doe",
      "about": {
          "@id": "entity://cluster123/Person/john-william-doe-a1b2c3"
      }
    }
  ]
}

Hinweis: Egal auf welcher URL diese Person auftaucht, die @id bleibt mathematisch identisch. Dies ermöglicht KI-Systemen, den Graphen fehlerfrei zusammenzusetzen.

6. Operativer Ablauf (Pipeline)

Die Aivis-OS Software verarbeitet Daten in einer strikten Sequenz, um Kontamination zu vermeiden:

1. Ingest & Extraction: Scannen aller URLs nach Entitäts-Kandidaten.
2. Normalization (Staging): Cluster-weite Bereinigung von Namensvarianten.
3. Merge & Deduplication: Zusammenführung identischer Entitäten zu einem Golden Record.
4. Anchor Verification: Validierung externer IDs (Wikidata, etc.) gegen vertrauenswürdige Quellen.
5. Freeze: Versionierung des Inventars.
6. Projection: Generierung des JSON-LD für die Einzelseiten basierend auf dem gefrorenen Inventar.

7. Entscheidungskriterien (Abnahme)

Ein korrekt implementiertes Aivis-OS Cluster erfüllt folgende Metriken:

• ID Stabilität: Ein erneuter Durchlauf der Pipeline verändert bestehende IDs nicht.

• Deduplizierungs-Rate: Varianten konvergieren gegen 1 (n:1 Mapping).

• Anchor Uniqueness: 1 externer Anker (z.B. QID) ist maximal einer Entität zugeordnet.

• Referenzielle Integrität: Jede in JSON-LD ausgegebene @id existiert im verifizierten Inventar.