Evidence Monitoring & AI Visibility Observability

1. Architektonisches Problem

Probabilistic Output & the Ranking Fallacy

Herkömmliche Monitoring-Ansätze (Rankings, Share of Voice, Position Tracking) basieren auf der Annahme deterministischer Ergebnislisten.

Generative KI-Systeme (LLMs, Answer Engines) erzeugen jedoch keine Listen, sondern probabilistische Antworten auf Basis von Vektorraumnähe, Evidenzdichte und Kontextkohärenz.

Daraus folgt:

• „Positionen“ existieren nicht.
• Wiederholbarkeit ist nicht garantiert.
• Sichtbarkeit ist ein Zustand, kein Platz.

Ein Monitoring, das ausschliesslich den Output textuell analysiert (z. B. Keyword-Matching), unterliegt drei systematischen Blindheiten:

• Evidence Blindness: Korrekte Antworten können auf Raten statt auf Wissen beruhen.
• Semantic Blindness: Strukturelle Fehler (falsche Relationen) bleiben unentdeckt, solange Entitäten genannt werden.
• Numerical Blindness: Zahlen, Zeiträume und Quoten werden nicht verlässlich validiert.

Schlussfolgerung: Output ist ein Symptom, kein Fundament. Aivis-OS definiert Monitoring nicht als Ranking-Kontrolle, sondern als Structural Integrity Testing.

2. Monitoring-Ziel

Das Ziel des Evidence Monitoring ist nicht Sichtbarkeit, sondern semantische Stabilität unter probabilistischem Abruf.

Gemessen wird nicht, ob ein Unternehmen genannt wird, sondern wie stabil, korrekt und belegbar seine digitale Repräsentation abrufbar ist.

3. Die vier Dimensionen der Sichtbarkeit

(4 Dimensions of AI Visibility)

Aivis-OS misst Sichtbarkeit entlang vier qualitativer Zustände der Entitätsrepräsentation.

3.1 Attribution Stability

(Identitäts-Check)

Definition: Die Fähigkeit des Modells, einen Sachverhalt der korrekten Entität zuzuordnen, ohne dass die Entität explizit im Prompt genannt wird (Zero-Mention Prompting).

Test: „Wer bietet eine Lösung für Problem X?“

Erfolg: Die korrekte Entität wird genannt.

Warnsignal:

• Wettbewerber werden genannt
• generische Akteure werden halluziniert

Architektonische Bedeutung: Indikator für die Stärke der semantischen Vektorisierung und Identitätsverankerung.

3.2 Entity Logic Integrity

(Beziehungs-Check)

Definition: Die Korrektheit der im Modell rekonstruierten Relationen zwischen Entitäten.

Test:
„Welche Produkte gehören zu [Marke]?“
„Wer ist Partner im Joint Venture [Name]?“

Erfolg: Korrekte Auflösung der im Semantic Graph modellierten Kanten.

Warnsignal:

• Identity Drift
• Vermischung mit Wettbewerbern
• Disambiguierungsfehler

3.3 Evidence Consistency

(Beweis-Check)

Definition: Die Fähigkeit des Modells, Aussagen mit expliziten, überprüfbaren Quellen zu belegen.

Test: „Nenne die Quelle für diese Aussage.“

Erfolg: Das Modell liefert eine URL oder ein Dokument, das im Inventory als Source of Truth definiert ist.

Warnsignal:

• korrekte Aussage ohne Quelle
• halluzinierte Quellen
• nicht existente oder veraltete URLs

3.4 Temporal & Numerical Precision

(Fakten-Check)

Definition:
Die Genauigkeit bei nicht-linguistischen Daten wie Zahlen, Daten, Quoten oder Zeiträumen.

Test:
„Wie hoch war der Umsatz 2023?“
„Wann wurde Produkt X eingeführt?“

Erfolg:
Exakte Übereinstimmung mit dem Transport-Safe Content.

Warnsignal:

• approximierte Werte
• veraltete Datenstände
• statistisch plausible, aber faktisch falsche Zahlen (Token Hallucinations)

4. Testmethodik

Das Eisberg-Modell

Aivis-OS nutzt ein Dual-Layer Probing System, um oberflächliche Sichtbarkeit von struktureller Belastbarkeit zu unterscheiden.

4.1 Layer A – User Simulation Prompts

(Oberfläche)

Ziel: Simulation realer Nutzungsszenarien.

Charakteristik:

• kurz
• unscharf
• kontextarm

Messgrösse: Recall Rate (wird die Entität überhaupt gefunden?)

Beispiel: „Beste Software für Compliance?“

4.2 Layer B – Forensic Prompts

(Fundament)

Ziel:
Überprüfung der semantischen Mechanik.

Charakteristik:

• strukturiert
• evidenzfokussiert
• adversarial

Messgrössen:

• Accuracy
• Citation Rate

Beispiel: „Liste alle Compliance-Module von [Marke] mit Release-Datum und verlinke die Dokumentation.“

4.3 The Integrity Gap

Die Differenz zwischen Layer A und Layer B ist der zentrale KPI.

• Fall 1: User gut · Forensic schlecht → Bubble Visibility (instabil)
• Fall 2: User schlecht · Forensic gut → Hidden Potential (Architektur vorhanden, Transport schwach)
• Fall 3: Beide gut → Aivis Certified Visibility

5. Scoring-Modell

Source Anchoring Score (SAS)

Lineare Rankings werden durch den Source Anchoring Score (0.0 – 1.0) ersetzt.

Berechnung:

Interpretation:

• SAS < 0.5
  Kritische Instabilität – das Modell rät.
• SAS ≥ 0.9
  Deterministische Verankerung – das Modell „weiss“.

6. Feedback Loop

Monitoring als Remediation-Trigger

Monitoring ist in Aivis-OS kein Reporting-Artefakt, sondern ein Auslöser für architektonische Korrekturen.

Jeder Monitoring-Befund ist rückführbar auf einen konkreten Layer.