Aivis-OS System Architecture

Status und Beleglogik dieses Dokuments

Dieses Dokument ist die kanonische öffentliche Systemspezifikation von Aivis-OS. Es ist weder ein unabhängiger Forschungsbericht noch ein Marketing-Whitepaper. Es definiert die Kategorie, Architektur, Terminologie, Projektionsregeln, Messlogik und das Betriebsmodell von Aivis-OS.

Die Aussagen folgen drei klar unterscheidbaren Ebenen:

Wo eine Aussage die Wirkung auf externe Systeme betrifft, wird die Kontrollgrenze ausdrücklich benannt. Wo sie die eigene Architektur beschreibt, ist sie keine Hypothese über den Markt, sondern eine Definition des Systems.

Von Dokumentauffindbarkeit zu Antwortrekonstruktion

Ranking ist nicht verschwunden. Es ist für den Nutzer weniger sichtbar geworden.

Die klassische Suche beantwortet eine Anfrage mit einer Rangordnung von Dokumenten. Generative Suchsysteme können dieselben oder ähnliche Retrieval- und Qualitätssysteme verwenden, führen danach aber eine zusätzliche Transformation aus: Sie synthetisieren aus ausgewählten Quellen eine Antwort. Google erklärt ausdrücklich, dass die etablierten SEO-Grundlagen auch für AI Overviews und AI Mode relevant bleiben. Die Behauptung, generative Systeme hätten Ranking vollständig abgeschafft, wäre daher falsch.

Die strategische Veränderung liegt an einer anderen Stelle: Der Nutzer sieht die Rangordnung nicht zwingend als Liste. Er sieht das Ergebnis einer Auswahl- und Verdichtungsleistung. Eine Quelle kann hoch bewertet und dennoch nicht sichtbar zitiert werden. Eine Marke kann genannt werden, obwohl ihre eigene Domain nicht als Quelle erscheint. Eine korrekte Aussage kann aus einer falschen Entität oder einem falschen Zeitraum abgeleitet sein. Und eine falsche Aussage kann sprachlich so plausibel formuliert sein, dass sie wie Wissen wirkt.

Auffindbarkeit bleibt notwendig. Sie ist nicht mehr hinreichend.

Vier Zustände, die nicht verwechselt werden dürfen

Aivis-OS trennt vier Zustände, die in herkömmlichen Visibility-Metriken häufig zusammenfallen:

Diese Trennung ist keine rhetorische Zuspitzung. NIST AI 600-1 führt Konfabulation als technisches Modellrisiko. HaluEval untersucht plausible, aber nicht belastbar gestützte Antworten. NumericBench dokumentiert fortbestehende Schwächen bei Zahlenerkennung, numerischem Retrieval, Vergleich und Schlussfolgerung. Forschung zu Knowledge Conflicts zeigt, dass Konflikte zwischen Kontexten und parametrischem Wissen die Vertrauenswürdigkeit und Leistung von Sprachmodellen beeinträchtigen können.

Eine Marke kann daher sichtbar und zugleich strukturell falsch rekonstruiert sein.

Die GEO-Falle

Mit Generative Engine Optimization und AI Visibility ist ein neues Forschungs- und Praxisfeld entstanden. Viele sichtbare Angebote messen den Output generativer Systeme: Prompts werden wiederholt ausgeführt; ausgewertet werden Markennennungen, Positionen, Zitationen, Sentiment, Quellen oder Share of Voice. Diese Logik ist in den Produktbeschreibungen heutiger Anbieter klar erkennbar, etwa bei Profound, Peec AI oder AI Visibility.

Solche Messungen sind nützlich. Die Falle entsteht erst, wenn Output-Beobachtung mit Ursachenbehebung verwechselt wird.

Monitoring kann zeigen, dass ein Modell eine falsche Zahl nennt. Es kann nicht entscheiden, welche von mehreren Zahlen auf der eigenen Domain für welchen Kontext gilt.

Monitoring kann eine fehlende Zitation erkennen. Es kann nicht verhindern, dass dieselbe Entität auf vierzig URLs mit vierzig voneinander getrennten Identitäten exponiert wird.

Monitoring kann einen Sichtbarkeitstrend messen. Es kann nicht feststellen, ob eine korrekte Antwort auf belastbarer Evidenz oder auf statistischer Plausibilität beruht, solange es nur Namen und Keywords zählt.

Aivis-OS bezeichnet diese Verkürzung als GEO-Falle: Der sichtbare Output wird optimiert, während der unternehmenseigene Quellenzustand ungeführt bleibt. Die marktübliche Blickrichtung auf Antworten nennt Aivis-OS Outside-In. Der eigene Architekturansatz arbeitet Inside-Out: vom entschiedenen Quellenzustand zur überprüfbaren externen Rekonstruktion.

Monitoring und Source Architecture schließen einander nicht aus. Sie sind jedoch nicht symmetrisch. Monitoring beobachtet die Abweichung. Source Architecture bearbeitet den Raum, in dem die vermeidbare Ursache liegt. Aivis-OS integriert Monitoring deshalb als fünfte Architekturebene – nicht als Ersatz für die ersten vier.

Die Kategorie: Domain-based AI Source Integrity

Definition

Aivis-OS verwendet den Begriff Domain-based AI Source Integrity für folgenden Zielzustand:

Eine Organisation führt Identitäten, Fakten, Beziehungen, Geltungsbereiche und zeitliche Zustände auf ihrer eigenen Domain so konsistent, nachvollziehbar und maschinenlesbar, dass externe Systeme sie ohne vermeidbare Mehrdeutigkeit abrufen und rekonstruieren können.

Der Begriff ist eine Aivis-OS-Kategorie. Er bezeichnet keinen W3C-, ISO- oder Branchenstandard. Sein Gegenstand ist auch nicht die gesamte Informationswelt einer Organisation. Aivis-OS beginnt mit jenem digitalen Grundstück, das eine Organisation selbst publiziert und verändern kann: ihrer Domain einschließlich der dort bereitgestellten HTML-Seiten, PDFs und weiterer öffentlicher Ressourcen.

Was „Primärquelle“ bedeutet

Aivis-OS verfolgt das Ziel, die eigene Domain zur primären Quelle zu machen, wenn KI über eine Organisation spricht. Primärquelle bedeutet hier:

• Die Organisation hält den freigegebenen Referenzzustand auf ihrer eigenen Domain.
• Identität, Aussage, Kontext und Provenienz sind dort nachvollziehbar.
• Externe Systeme können diesen Zustand abrufen und gegen andere Quellen abgleichen.
• Korrekturen beginnen an der Quelle und nicht erst in einem nachgelagerten Antwort-Dashboard.

Primärquelle bedeutet nicht, dass jedes Modell die Domain in jeder Antwort auswählt oder sichtbar zitiert. Es bedeutet, dass die Organisation dort, wo sie tatsächlich Kontrolle besitzt, eine belastbare Referenzlage herstellt.

Die kontrollierbare Kette

Aivis-OS modelliert die Informationskette in zwei grundsätzlich unterschiedliche Räume:

Kontrollierbarer Raum der Organisation

Institutionelles Wissen → publizierter Korpus → kanonische Assertions → sichtbarer Content → Machine Interface

Probabilistischer Raum externer Systeme

Crawling / Retrieval → Auswahl / Gewichtung → Kontextbildung → Synthese → Zitation / Antwort

Evidence Monitoring verbindet beide Räume rückwärts:

Antwortbefund → Fehlerklasse → betroffene Architekturebene → Remediation

Aivis-OS verwendet für diese Analyse die Begriffe Entity Recognition und Evidence Weighting: Externe Systeme müssen Entitäten zuordnen und Evidenz auswählen beziehungsweise gewichten, bevor sie eine Antwort synthetisieren. Die Begriffe beschreiben die analytisch relevanten Funktionen, nicht ein universelles, von allen Anbietern identisch implementiertes Phasenmodell. Wo sich Testbedingungen unterscheiden lassen, bezeichnet Aivis-OS einen rein parametrischen Antwortpfad als Case L und einen webgestützten Pfad als Case L+O.

Diese Trennung ist der Kern von Deterministische Quelle, probabilistische Rekonstruktion. Aivis-OS macht keine Aussage darüber, dass externe Systeme deterministisch würden. Es stellt sicher, dass die Organisation nicht selbst mehrere unentschiedene Zustände in denselben Rekonstruktionsraum sendet.

Fünf Designprinzipien

Aivis-OS fasst die Priorität expliziter Struktur im Satz Structure beats ranking zusammen. Dieser Satz behauptet nicht, Ranking sei wirkungslos. Er beschreibt eine Designentscheidung: Ranking kann ein Dokument in den Auswahlraum bringen. Struktur entscheidet mit darüber, wie eindeutig seine Identität, Aussage und Relation nach Retrieval, Extraktion und Synthese erhalten bleiben.

Die Fünf-Ebenen-Architektur

Aivis-OS ist kein einzelnes Markup-Modul und kein monolithisches Dashboard. Es ist ein fünfstufiges Architekturmodell, in dem jede Ebene eine andere Verlust- oder Fehlerquelle zwischen institutionellem Wissen, publizierter Domain und externer KI-Antwort bearbeitet.

Die Ebenen bilden einen Regelkreis. Layer 1 bis 4 stellen den Quellenzustand her. Layer 5 prüft seine externe Rekonstruktion. Ein Fehler im Output wird nicht nur gezählt, sondern an jene Ebene zurückgeführt, auf der eine Korrektur möglich ist.

Layer 1: Identity – Cluster-Level Entity Inventory

Eine URL ist ein Ort. Sie ist keine Identität.

Extern belegter Befund

JSON-LD kann Knoten eindeutig benennen. Die W3C-Spezifikation JSON-LD 1.1 definiert @id als Identifier eines Knotens über eine IRI. Schema.org sameAs verweist auf eine Ressource, die dieselbe Identität eindeutig bezeichnet. Wikidata, LEI, ISIN oder ORCID stellen – je nach Entitätstyp – weitere persistente Identifikatoren bereit.

Diese Standards garantieren nicht, dass ein beliebiges KI-System eine Entität korrekt erkennt. Sie belegen jedoch etwas Grundlegendes: Identität kann explizit referenziert werden, statt nur aus Schreibweise, URL oder Textnähe erraten werden zu müssen.

Das Quellenproblem

Historisch gewachsene Websites behandeln Identität oft implizit pro Seite. Dieselbe Organisation kann als juristische Person, Gruppe, Marke, Landesgesellschaft oder Kurzform auftreten. Mehrsprachigkeit erzeugt weitere Varianten. Alte Dokumente verwenden frühere Namen. Einzelne Plugins oder Autoren erzeugen je URL neue Schema-Knoten mit neuen IDs.

Menschen können viele dieser Varianten aus Kontext zusammenführen. Maschinen erhalten dagegen voneinander getrennte Signale. Aivis-OS bezeichnet die dadurch entstehende quellenseitige Fragmentierung als Identity Drift. Der Begriff Ambiguity Penalty beschreibt innerhalb der Aivis-OS-Methodik das operative Risiko, dass uneindeutige Identität die Stabilität von Attribution und Relation verschlechtert; er ist kein offengelegter universeller Parameter eines bestimmten LLM-Anbieters.

Aivis-OS-Architekturentscheidung

Aivis-OS entkoppelt Identität von der lokalen URL und führt ein Cluster-Level Entity Inventory. Jede relevante Entität erhält einen Golden Record mit:

• einer persistenten internen Identität;
• dem spezifischsten sachlich passenden Schema.org-Typ;
• kanonischem Namen und zulässigen Namensvarianten;
• Sprach-, Marken- und historischen Varianten;
• externen Identifikatoren und Referenzen, soweit eindeutig und passend;
• Relationen zu Organisationen, Personen, Produkten, Orten, Berichten oder Ereignissen;
• dokumentierter Provenienz und Governance-Verantwortung.

Eine Aivis-OS-interne ID kann nach folgendem Muster erzeugt werden:

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

Diese Syntax ist eine Aivis-OS-Konvention und kein W3C-Standard. Ihre Funktion ist Persistenz: Dieselbe Entität behält über URLs, Sprachen und Aktualisierungen hinweg dieselbe interne Referenz. Auf der öffentlichen Projektion können zusätzlich standardkonforme IRIs und externe IDs verwendet werden.

Kontrolliertes Ergebnis

Layer 1 verhindert, dass die eigene Architektur dieselbe Entität fortlaufend als neue, unverbundene Entität exponiert. Die Organisation besitzt erstmals ein Inventar dessen, was sie maschinenlesbar als existent behauptet.

Persistente Identität allein garantiert weder Retrieval noch Zitation. Aber ohne persistente Identität muss jedes nachgelagerte System Gleichheit erneut probabilistisch herleiten. Aivis-OS beseitigt diese vermeidbare Unsicherheit an der Quelle.

Layer 2: Context & Meaning – Semantic Graph Layer

Ein Modell kann nicht wissen, welche von zwei publizierten Unternehmensangaben das Unternehmen selbst für gültig hält.

Extern belegter Befund

Wissenskonflikte sind kein theoretischer Randfall. Der Survey Knowledge Conflicts for LLMs unterscheidet Konflikte zwischen Kontext und Modellwissen, zwischen mehreren Kontexten und innerhalb des parametrischen Wissens. Die ACL-Arbeit Blinded by Generated Contexts zeigt, dass Modelle in untersuchten Konfliktsituationen falsche generierte Kontexte gegenüber korrekten abgerufenen Kontexten bevorzugen können; als einen Faktor identifizieren die Autoren die durch Segmentierung gestörte Vollständigkeit abgerufener Kontexte. Forschung zu dynamischen Fakten untersucht zusätzlich das Problem zeitlich veränderlicher Angaben.

Der Befund ist für Unternehmen unmittelbar relevant: Ein alter Geschäftsbericht, eine aktuelle Landingpage, eine Pressemitteilung und eine Landesgesellschaft können unterschiedliche Zahlen nennen, ohne dass alle Aussagen im selben Kontext falsch sind. Die Maschine kennt die interne Geltungslogik nicht.

Variation ist nicht automatisch Widerspruch

Aivis-OS unterscheidet strikt zwischen legitimer Vielheit und echtem Konflikt.

Ein Geschäftsbericht von 2024 und ein Geschäftsbericht von 2025 dürfen unterschiedliche Mitarbeiterzahlen enthalten. Ein früherer Preis bleibt als historischer Wert korrekt, wenn sein Zeitraum erkennbar ist. Eine Gruppenkennzahl und eine Kennzahl der Tochtergesellschaft sind beide legitim, wenn ihr organisatorischer Scope eindeutig bleibt.

Ein Widerspruch entsteht erst, wenn zwei Aussagen für denselben Gegenstand, denselben Kontext und denselben Geltungszeitraum nicht gleichzeitig gelten können.

Aivis-OS-Architekturentscheidung

Der Semantic Graph Layer modelliert Aussagen als typisierte Assertions statt als lose Textfragmente. Eine Assertion kann unter anderem enthalten:

• Subjekt, Prädikat und Objekt;
• Quelle und Provenienz;
• organisatorischen, geografischen oder produktbezogenen Scope;
• zeitliche Gültigkeit und Stichtag;
• Status, Freigabe und Verantwortlichkeit;
• Evidenz- oder Confidence-Bewertung im jeweiligen Projekt;
• Beziehungen zu konkurrierenden, historischen oder abgeleiteten Aussagen.

Konkurrierende Assertions werden nicht still überschrieben und nicht durch Häufigkeit entschieden. Sie werden in Konfliktgruppen zusammengeführt, fachlich geprüft und für einen definierten Kontext aufgelöst.

Aivis-OS folgt dem Prinzip:

Internal Multiplicity, External Determinism.

Intern darf die Organisation mehrere historische, regionale oder kontextabhängige Aussagen besitzen. Nach außen wird für einen definierten Kontext genau der freigegebene Zustand projiziert. Historie wird nicht gelöscht. Sie wird unterscheidbar gemacht.

Fertige Zustände

Der Semantic Graph Layer führt nicht zu einer zeitlosen, statischen „Wahrheit“. Er führt zu einem fertigen Zustand für den bekannten Kontext.

Fertig bedeutet:

• bekannte Entitäten sind entschieden;
• konkurrierende Aussagen sind aufgelöst oder als legitime Varianten qualifiziert;
• Geltungsbereiche und Zeitstände sind benannt;
• die öffentliche Exposition entspricht der Freigabe;
• offene Zwischenlösungen werden nicht zum Dauerzustand.

Ändert sich die Organisation, entsteht ein neuer Zustand. Ein neues Produkt, eine neue Kennzahl, eine Umfirmierung oder ein regulatorischer Wechsel machen den früheren Zustand nicht unfertig. Sie lösen eine neue Entscheidung aus.

Kontrolliertes Ergebnis

Layer 2 verwandelt einen historisch gewachsenen Aussagenbestand in eine führbare Referenzlage. Er erzeugt keinen universellen Wahrheitsanspruch. Er dokumentiert, welche Aussage die Organisation für welchen Kontext freigegeben hat, warum sie gilt und worauf sie beruht.

Software kann Konflikte erkennen und strukturieren. Sie kann institutionelle Geltung nicht autonom beschließen. Deshalb ist fachliche Governance kein Zusatz zur Architektur, sondern ihr notwendiger Bestandteil.

Layer 3: Retrieval Resilience – Transport-Safe Content Layer

Information kann für Menschen sichtbar und für Maschinen trotzdem unvollständig transportiert sein.

Extern belegter Befund

Bei der maschinellen Verarbeitung bleibt eine Webseite nicht zwingend als zusammenhängende visuelle Seite erhalten. Inhalte werden extrahiert, segmentiert, vektorisiert, gerankt und in Kontextfenster eingefügt. Dabei kann Bedeutung verloren gehen.

Drei unabhängige Forschungsbefunde sind hierfür besonders relevant:

• Lost in the Middle zeigt, dass die Leistung von Sprachmodellen deutlich sinken kann, wenn relevante Informationen in der Mitte langer Kontexte statt am Anfang oder Ende stehen – auch bei Modellen mit langen Kontextfenstern.
• Late Chunking beschreibt, dass separat erzeugte Chunk-Embeddings Kontext aus umgebenden Textteilen verlieren können, und erzielt bessere Retrieval-Ergebnisse, wenn der Gesamtkontext vor der Segmentbildung berücksichtigt wird.
• Forschung zu Table Retrieval und Table Understanding zeigt, dass Tabellen nicht als bloße lineare Zeichenfolgen verstanden werden dürfen. Struktur, Zeilen-, Spalten- und Headerbeziehungen sind Teil ihrer Bedeutung; flache Zerlegung kann diese Zuordnung beschädigen. Siehe etwa TableRAG.

Aivis-OS bezeichnet den Übergang zwischen sichtbarer Seite und maschinell nutzbarer Information als Ingestion Gap. Den dabei entstehenden Verlust von Kontext, Relation oder Eindeutigkeit nennt das System Retrieval Entropy.

Tabellen sind nicht das Problem. Implizite Beziehungen sind es.

Eine Tabelle kann für Menschen hervorragend funktionieren. Problematisch wird sie, wenn die Bedeutung eines Wertes nur aus seiner räumlichen Position hervorgeht und nach Extraktion nicht mehr erkennbar ist, welcher Wert zu welchem Produkt, Zeitraum, Land oder Merkmal gehört.

Ein isoliertes Fragment wie

24'700 | 2025 | Europa

ist ohne Header und Kontext kaum belastbar rekonstruierbar.

Transportfähiger ist eine Aussage wie:

„Die Unternehmensgruppe beschäftigte zum 31. Dezember 2025 in Europa 24’700 Mitarbeitende.“

Aivis-OS verlangt nicht, Tabellen abzuschaffen. Es verlangt, dass geschäftskritische Relationen nicht ausschließlich im visuellen Raster existieren.

Aivis-OS-Architekturentscheidung

Der Transport-Safe Content Layer zerlegt relevante Aussagen in atomare, in sich verständliche und explizit relationierte Informationseinheiten. Dazu gehören:

• eindeutige Nennung des Subjekts;
• Wert und Einheit;
• Zeitraum, Stichtag oder Gültigkeitsdauer;
• organisatorischer, geografischer oder produktbezogener Scope;
• explizite Relation statt rein visueller Nähe;
• sichtbare Kennzeichnung historischer, archivierter oder eingeschränkter Aussagen;
• ausreichender lokaler Kontext, damit ein extrahiertes Fragment verständlich bleibt.

Atomar bedeutet nicht maximal kurz. Eine Informationseinheit ist dann atomar, wenn sie ohne unnötige Abhängigkeit von entfernten Layout- oder Textbestandteilen korrekt verstanden werden kann.

Frontend-Visible Exposition

Transport-Safe Content bleibt für Menschen sichtbar. Die maschinenlesbare Schicht präzisiert und relationiert den sichtbaren Inhalt, sie ersetzt ihn nicht durch eine abweichende Parallelwahrheit.

Diese Regel besitzt eine externe Kompatibilitätsgrundlage: Google fordert, dass strukturierte Daten den sichtbaren Seiteninhalt repräsentieren, nicht irreführend sind und keine Informationen auszeichnen, die für Leser unsichtbar bleiben. Bei dynamisch erzeugtem Markup weist Google zusätzlich darauf hin, dass duplizierte Informationen das Risiko von Abweichungen zwischen Seiteninhalt und strukturierten Daten erhöhen.

Aivis-OS verallgemeinert dieses Prinzip als Content Parity:

Was Maschinen als kanonischen Zustand erhalten, muss für Menschen auf der publizierten Quelle auffindbar und nachvollziehbar sein.

Kontrolliertes Ergebnis

Layer 3 reduziert die Abhängigkeit geschäftskritischer Aussagen von Layout, Position und implizitem Kontext. Er verspricht keine universell optimale Chunk-Größe für jedes Modell. Er stellt einen robusteren Quellenzustand her, dessen Transportfähigkeit am realen Korpus geprüft werden kann.

Layer 4: API & Exposure – Machine Interface Layer

Was eine Organisation explizit sagen kann, sollte sie eine Maschine nicht unnötig erraten lassen.

Extern belegter Befund

HTML ist die sichtbare Publikationsschicht einer Website. Strukturierte Daten ergänzen sie um benannte Knoten, Typen und Relationen. JSON-LD 1.1 stellt dafür ein W3C-standardisiertes Datenmodell bereit. Google empfiehlt JSON-LD für strukturierte Daten, weil es sich vergleichsweise einfach implementieren und skalieren lässt, und empfiehlt den spezifischsten sachlich anwendbaren Schema.org-Typ.

Daraus folgt nicht, dass jedes LLM JSON-LD vollständig verarbeitet oder bevorzugt. Es folgt jedoch, dass eine Organisation Entitäten und Relationen standardisiert explizit publizieren kann, statt sie ausschließlich aus unstrukturiertem HTML ableiten zu lassen.

Die Funktion des Machine Interface Layer

Der Machine Interface Layer projiziert den freigegebenen Zustand des Semantic Graph als JSON-LD auf die relevanten URLs. Die Website bleibt eine Website. Sie wird zusätzlich als maschinenorientierte Publikations- und Projektionsebene behandelt.

Aivis-OS verwendet dafür auch die Metapher einer öffentlichen Read-only-Schnittstelle. Gemeint ist keine transaktionale API mit Endpunkten, Authentifizierung, Rate Limits oder SLA. Gemeint ist eine stabile, öffentlich abrufbare Projektion dessen, was die Organisation für einen bestimmten Kontext freigegeben hat.

Drei Regelklassen

Aivis-OS trennt externe Standards, Kompatibilitätsregeln und eigene Projektionskonventionen ausdrücklich:

Diese Unterscheidung verhindert zwei Fehler: Aivis-OS gibt eigene Konventionen nicht als externe Norm aus. Umgekehrt behandelt es externe Standards nicht als unverbindliche Stilfrage.

Projektionsregeln von Aivis-OS

1. Specific Type Selection: Jede Entität erhält den spezifischsten sachlich passenden Schema.org-Typ. Eine MedicalClinic wird nicht ohne Grund auf die generische Organization reduziert. Spezifität ist kein Selbstzweck; sie soll die semantische Aussage präzisieren.
2. ID Persistence: Dieselbe Entität behält über URLs, Sprachen und Aktualisierungen hinweg dieselbe Referenz. IDs werden nicht bei jeder Seitengenerierung neu erzeugt.
3. Focus Node + 1 Hop: Die zentrale Entität einer Seite wird vollständig projiziert. Direkt verbundene Entitäten werden ausreichend referenziert, ohne den Graphen beliebig tief zu verschachteln. Diese Regel begrenzt Redundanz und hält die Projektion überprüfbar.
4. Coherent Graph Projection: Die relevanten Knoten werden als kohärenter @graph in einem getrennten JSON-LD-Skript publiziert, bevorzugt im Dokumentkopf. W3C und Google verlangen weder zwingend einen einzigen Block noch die Platzierung im <head>; Aivis-OS standardisiert diese Form für Konsistenz, Wartbarkeit und technische Kontrolle.
5. Content Parity: Der Graph beschreibt denselben freigegebenen Zustand wie der sichtbare Inhalt. Strukturierte Daten dürfen keine nicht publizierte Gegenwahrheit erzeugen.
6. Scoped Serialization: Nicht der gesamte unternehmensweite Graph wird auf jeder URL wiederholt. Jede Seite erhält jene Projektion, die für ihren Fokus und ihre direkten Relationen erforderlich ist.
7. Validation and Traceability: Jede Projektion bleibt auf ihren Golden Record, ihre Assertions und ihre Quellen zurückführbar. Syntaxvalidität allein genügt nicht; die semantische Herkunft muss prüfbar bleiben.

Kontrolliertes Ergebnis

Layer 4 macht den freigegebenen Quellenzustand explizit, typisiert und referenzierbar. Er verbessert die eigene Exposition, nicht die Verarbeitungspolitik fremder Anbieter. Aivis-OS garantiert daher nicht, dass ein bestimmtes System JSON-LD vollständig konsumiert oder sichtbar zitiert.

Die entscheidende Architekturleistung liegt davor: Die Organisation zwingt externe Systeme nicht mehr, jene Identitäten und Relationen zu erraten, die sie selbst eindeutig modellieren kann.

Layer 5: Observability – Evidence Monitoring

Eine richtige Antwort ist noch kein Beweis für eine richtige Quellenarchitektur.

Warum reine Nennungsmessung nicht genügt

Generative Antworten können plausibel, korrekt oder sichtbar sein und dennoch auf instabiler Grundlage beruhen. NIST behandelt Konfabulation als Modellrisiko. HaluEval untersucht nicht belastbar gestützte Halluzinationen. DateLogicQA adressiert zeitliche Schlussfolgerung, NumericBench grundlegende numerische Fähigkeiten. Diese Forschung belegt nicht die Vollständigkeit der Aivis-OS-Messlogik. Sie belegt den Grund, warum Erwähnung und Sentiment allein für geschäftskritische Fakten nicht ausreichen.

Aivis-OS unterscheidet drei wiederkehrende Blindheiten:

• Evidence Blindness: Die Antwort ist plausibel, aber ihre Quelle oder Herleitung bleibt instabil.
• Semantic Blindness: Die Organisation wird genannt, doch Rolle, Zugehörigkeit, Identität oder Beziehung sind falsch.
• Numerical Blindness: Zahl, Einheit, Quote, Zeitraum oder Stichtag werden falsch oder unvollständig rekonstruiert.

Dual-Layer Probing

Evidence Monitoring verwendet zwei Testebenen:

• Layer A – User Simulation: realistische, teilweise unpräzise Prompts, wie sie in tatsächlichen Nutzungssituationen vorkommen;
• Layer B – Forensic Probing: gezielte Prompts, die Identität, Relation, Quelle, Zahl, Zeitraum und Geltungsbereich belasten.

Die Differenz zwischen oberflächlicher Sichtbarkeit und forensischer Belastbarkeit bezeichnet Aivis-OS als Integrity Gap. Eine Marke kann in Layer A stabil sichtbar erscheinen und in Layer B bei einer präzisen Nachfrage zur falschen Rechtseinheit, Tochtergesellschaft, Kennzahl oder Quelle kippen. Diesen Zustand nennt Aivis-OS Bubble Visibility.

Vier Messdimensionen

Messprotokoll

Aivis-OS behandelt Wirkung nicht als Eindruck, sondern als versioniertes Testproblem. Ein belastbares Messprotokoll umfasst mindestens:

1. Canonical Truth Set: Die zu prüfenden Aussagen werden aus dem freigegebenen Assertion Layer abgeleitet. Jede erwartete Antwort besitzt Entität, Scope, Zeitraum und Evidenz.
2. Versioniertes Prompt-Set: User-Simulation und forensische Prompts werden festgeschrieben. Änderungen am Set werden dokumentiert, damit Zeitvergleiche nicht durch wechselnde Fragen verfälscht werden.
3. Dokumentierter Systemkontext: Modell beziehungsweise Produkt, Suchmodus, Sprache, Region, Datum, Uhrzeit und weitere erkennbare Konfigurationen werden protokolliert. Wo möglich, unterscheidet Aivis-OS zwischen parametrischem Antwortpfad und webgestütztem Retrieval.
4. Wiederholte Messung: Ein einzelner Lauf gilt nicht als stabiler Befund. Prompts werden wiederholt und über mehrere Systeme geprüft, weil Antworten probabilistisch und Anbieterprozesse dynamisch sind.
5. Zeitpunkte T0, T1 und T2: T0 dokumentiert die Baseline vor der Intervention. T1 prüft die erste messbare Phase nach Exposition. T2 kontrolliert, ob ein Effekt oder Fehlerbild stabil bleibt. Projektabhängig können weitere Messpunkte folgen.
6. Fehlerklassifikation: Abweichungen werden nicht nur als „richtig“ oder „falsch“ codiert, sondern ihrer Fehlerklasse und der wahrscheinlich betroffenen Architekturebene zugeordnet.
7. Remediation Trace: Jede Korrektur wird auf Korpusänderung, Assertion-Entscheidung, Content-Anpassung, Projektion oder externe Referenz zurückgeführt. Dadurch bleibt erkennbar, was tatsächlich verändert wurde.
8. Kausalitätsdisziplin: Eine zeitliche Verbesserung nach einer Architekturmaßnahme ist ein Wirkungsindikator, aber nicht automatisch ein universeller Kausalbeweis. Aivis-OS trennt projektbezogene Evidenz von allgemeiner Modellbehauptung.

Source Anchoring Score

Aivis-OS kann die Messdimensionen im internen Source Anchoring Score (SAS) zusammenführen:

SAS = Attribution Weight × Integrity Weight × Citation Rate

Der Attribution Weight bildet die Stabilität der korrekten Entitätszuordnung ab. Der Integrity Weight aggregiert projektbezogen Entity Logic, Evidence Consistency sowie Temporal & Numerical Precision. Die Citation Rate misst, wie häufig die definierte Quellenlage sichtbar referenziert wird, sofern das getestete System Zitationen ausgibt.

Ein SAS von ≥ 0.9 kann innerhalb eines klar definierten, versionierten Testdesigns als interner Freigabeschwellenwert verwendet werden. Er bedeutet nicht, dass „die Wahrheit im Modell deterministisch verankert“ wäre. Er bedeutet, dass der konfigurierte Prüfgegenstand unter den dokumentierten Bedingungen eine hohe Stabilität erreicht hat.

SAS ist ein Aivis-OS-Verifikationsinstrument, kein unabhängiger Branchenstandard. Seine Aussagekraft entsteht aus transparenten Prompt-Sets, Wiederholungen, Gewichtungen, Schwellenwerten und dem dokumentierten Canonical Truth Set.

Remediation statt Reporting

Evidence Monitoring endet nicht im Dashboard. Ein Befund wird zum Remediation Trigger:

• falsche Entität → Layer 1 prüfen;
• falscher Scope oder Zeitraum → Layer 2 prüfen;
• verlorener Kontext oder Tabellenbezug → Layer 3 prüfen;
• fehlende oder widersprüchliche Projektion → Layer 4 prüfen;
• instabiles oder unzureichendes Testdesign → Layer 5 prüfen.

Damit schließt sich der Regelkreis. Aivis-OS misst nicht nur, was KI sagt. Es nutzt die Antwort als forensischen Hinweis auf den Zustand der Quelle.

Das 4C Evaluation Framework

Das Vorhandensein strukturierter Daten ist kein Reifegrad. Entscheidend ist, ob eine Domain als Quelle führbar ist.

Das 4C-Modell ist der Bewertungsrahmen von Aivis-OS. Es prüft den Quellenzustand entlang vier voneinander abhängiger Dimensionen:

Confirmed bedeutet nicht, dass ein externer Identifier jede inhaltliche Aussage bestätigt. Eine Wikidata-QID kann die Identität referenzieren; sie beweist nicht automatisch eine Unternehmenskennzahl. Aivis-OS trennt deshalb Identitätsanker, Quellenprovenienz und fachliche Freigabe.

4C ist ein proprietäres Aivis-OS-Framework. Seine Aufgabe besteht nicht darin, eine Website mit einem abstrakten Score zu dekorieren. Es macht sichtbar, welche Entscheidungen vor einer belastbaren maschinenlesbaren Exposition fehlen.

Vom Korpus zum freigegebenen Zustand

Wahrheit vor Anreicherung.

Aivis-OS ist kein Plugin, das ungeprüfte Inhalte automatisch mit zusätzlichem Markup versieht. Strukturierte Daten erhöhen die Explizitheit einer Aussage. Wenn die Aussage falsch, unvollständig oder widersprüchlich ist, wird damit nicht Wahrheit erzeugt, sondern der Fehler präziser exponiert.

Deshalb beginnt Aivis-OS vor dem JSON-LD.

Operative Sequenz

1. Corpus Inventory: Erfassung der relevanten HTML-Seiten, PDFs, Dateien und weiteren publizierten Ressourcen. Der Korpus wird als Domainbestand betrachtet, nicht als lose Liste einzelner URLs.
2. Page- und Domain-Klassifikation: Einordnung von Organisationstyp, Seitenfunktion, Domain-Scope, Stakeholder-Kontext und Geltungsraum. Extraktion ohne Orientierung erzeugt typisierte Einzelbefunde ohne belastbare Systemlogik.
3. Entity- und Assertion-Extraktion: Ermittlung relevanter Organisationen, Personen, Produkte, Orte, Berichte, Ereignisse, Kennzahlen und Aussagen.
4. Deduplikation und Entity Resolution: Zusammenführung von Varianten in kanonische Golden Records. Namensgleichheit wird nicht automatisch mit Identitätsgleichheit verwechselt.
5. Konfliktgruppen: Bündelung konkurrierender, historischer oder erklärungsbedürftiger Aussagen nach Gegenstand, Scope und Zeitraum.
6. Kanonische Entscheidungen: Fachliche Freigabe dessen, was in einem definierten Kontext gilt. Alte Werte können als historische Werte legitim bleiben; echte Konflikte werden entschieden.
7. Canonical Assertion Layer: Speicherung des freigegebenen Zustands mit Provenienz, Geltungsbereich, Zeitbezug und Verantwortlichkeit.
8. Transport-Safe Content: Anpassung sichtbarer Inhalte dort, wo Subjekt, Relation, Einheit, Zeitraum oder Kontext bei Extraktion verloren gehen können.
9. Machine Interface Layer: Projektion der relevanten Entitäten und Assertions als konsistenter, typisierter JSON-LD-Graph.
10. Forensic Measurement: Prüfung von Attribution, Entity Logic, Evidenz sowie zeitlicher und numerischer Präzision gegen das Canonical Truth Set.
11. Remediation und Attestation: Rückführung von Abweichungen in Korpus, Graph, Content oder Projektion; dokumentierte Freigabe des erreichten Zustands.

Das Prinzip fertiger Zustände

Das initiale Onboarding führt den bekannten Korpus in einen entschiedenen, freigegebenen Zustand. Fertig bedeutet nicht, dass sich die Organisation nie mehr verändert. Es bedeutet, dass für den aktuell bekannten Zustand keine ungeklärte Zwischenlösung als Dauerbetrieb bestehen bleibt.

Für manche Organisationen bleibt dieser Zustand lange stabil. Bei anderen ändern sich Produkte, Personen, Kennzahlen oder regulatorische Anforderungen laufend. Betrieb wird nur dort relevant, wo Veränderung einen neuen Entscheidungsbedarf erzeugt.

Aivis-OS unterscheidet daher zwischen:

• Onboarding: Herstellung des ersten fertigen Zustands;
• Governance: Überführung neuer Sachverhalte in den jeweils nächsten fertigen Zustand.

Attestat und Konfliktwache

Zwei Funktionen sichern den Betrieb:

• Das Attestat prüft ein definiertes Prompt-Set in festgelegten Intervallen über mehrere KI-Systeme und dokumentiert die Rekonstruktionsstabilität.
• Die Konfliktwache überwacht den eigenen Domainkorpus auf neue Aussagen, Varianten oder Widersprüche, die den freigegebenen Graphen verändern könnten.

Das Attestat beobachtet den externen Effekt. Die Konfliktwache beobachtet die interne Quelle. Erst zusammen bilden sie einen geschlossenen Governance-Zyklus.

Deployment und Betriebsmodell

Drei Deployment-Pfade

Aivis-OS sieht drei primäre Einstiegspfade vor:

Ein Pilot ist kein verkleinertes Versprechen schneller Sichtbarkeit. Er prüft, ob die Organisation die notwendigen Entscheidungen, Rollen, Freigaben und Aktualisierungsprozesse tatsächlich führen kann.

Fünf Entscheidungsräume

Unabhängig vom Einstiegspfad müssen Entscheidungen in fünf Räumen getroffen werden:

1. Entity Inventory: Was existiert kanonisch, und wie wird es identifiziert?
2. Semantic Graph: Welche Aussagen und Beziehungen gelten in welchem Kontext?
3. Content Parity & Retrieval Resilience: Wo und wie wird der freigegebene Zustand sichtbar und transportfähig publiziert?
4. Machine Interface: Welche Teile des Graphen werden auf welcher URL projiziert?
5. Evidence & Monitoring: Wie wird geprüft, ob externe Systeme den Quellenzustand stabil rekonstruieren?

Managed Architectural Service

Aivis-OS ist kein monolithisches Self-Service-SaaS. Der Grund liegt in der Natur des Problems: Software kann crawlen, extrahieren, vergleichen, gruppieren, modellieren und projizieren. Sie kann nicht autonom entscheiden, welche Aussage regulatorisch, juristisch, fachlich oder institutionell gelten soll.

Das Betriebsmodell verbindet daher drei Kompetenzen:

• Methodik und Governance: Architektur, Entscheidungslogik und Qualitätssicherung;
• Technologie: Pipeline, Datenmodell, technische Integration und Machine Interface;
• Implementation & Growth: organisatorische Einführung, Rollout und Marktintegration.

Die Architektur, Methodik und ursprüngliche Softwarespezifikation wurden von Norbert Kathriner entwickelt; die methodische Governance liegt bei der Boutique für digitale Kommunikation GmbH. epoint verantwortet Softwareentwicklung und technische Integration. Die jeweils aktuellen Implementation-&-Growth-Partner werden auf der Aivis-OS-Kontakt- und Netzwerkseite geführt. Partnerrollen sind operativ veränderlich; die Systemarchitektur bleibt davon unabhängig.

Beweispflicht, Grenzen und Falsifizierbarkeit

Eine neue Kategorie wird nicht glaubwürdig, indem sie sich dem bestehenden Kategorienraum anpasst. Sie wird glaubwürdig, indem sie ihre Unterscheidung präzise und überprüfbar macht.

Aivis-OS trennt drei Arten von Anspruch:

Was Aivis-OS kontrolliert

• den inventarisierten Domainkorpus;
• die kanonische Identität relevanter Entitäten;
• die fachliche Entscheidung konkurrierender Aussagen;
• Provenienz, Scope und Zeitbezug;
• sichtbare Content-Parität;
• die eigene maschinenlesbare Projektion;
• das Testdesign und die Dokumentation erkannter Abweichungen.

Was außerhalb der direkten Kontrolle bleibt

• ob und wann ein Anbieter die Domain crawlt oder abruft;
• welche Quellen ein externes System auswählt und gewichtet;
• wie parametrisches Wissen und abgerufene Evidenz zusammengeführt werden;
• ob eine Quelle sichtbar zitiert wird;
• welche Modell-, Produkt- oder Rankingänderungen ein Anbieter vornimmt;
• welche widersprüchlichen Drittquellen außerhalb der eigenen Domain fortbestehen.

Bedingungen, unter denen eine Maßnahme als nicht bestätigt gilt

Eine Aivis-OS-Maßnahme gilt nicht allein deshalb als wirksam, weil sie technisch korrekt implementiert wurde. Ihre externe Wirkung ist eingeschränkt oder nicht bestätigt, wenn beispielsweise:

• das getestete System die Quelle nicht abruft;
• die Attribution trotz stabiler Identität in wiederholten Tests nicht besser wird;
• eine Content- oder Graphänderung keine messbare Verbesserung gegenüber T0 zeigt;
• externe, autoritativ bewertete Konfliktquellen die Domaininformation überlagern;
• die Organisation selbst einen falschen kanonischen Zustand freigibt;
• das Messdesign zu klein, wechselhaft oder unzureichend dokumentiert ist;
• eine Verbesserung nur in einem einzelnen Modell, Zeitpunkt oder Prompt auftritt und nicht replizierbar bleibt.

Diese Bedingungen schwächen die Architektur nicht. Sie verhindern, dass Aivis-OS aus einer plausiblen Theorie ein nicht überprüfbares Heilsversprechen macht.

Die eigentliche Kontrollgrenze

Aivis-OS macht externe Systeme nicht deterministisch. Es macht den Quellenzustand der Organisation entscheidbar, exponierbar und überprüfbar.

Das ist keine bescheidene Ersatzleistung. Es ist die Voraussetzung dafür, überhaupt unterscheiden zu können, ob ein externer Fehler aus der eigenen Quelle, aus einer Drittquelle, aus Retrieval, aus Konfliktauflösung oder aus der Synthese des Modells stammt.