Dokument-Typ: Architektur-Spezifikation
Kontext: Machine Interface Layer · API Engineering
Status: Public Standard
Gültigkeit: Aivis-OS Core Pipeline
Referenz: Konsumiert Semantic Graph Engineering und exponiert ausschließlich den Canonical Graph State.
1. Architektonisches Prinzip
The Website as an API
In der Aivis-OS Architektur ist die visuelle Website (HTML für Menschen) nur eine von mehreren möglichen Repräsentationen organisationaler Wahrheit.
Der Machine Interface Layer (MIL) behandelt die Domäne primär als öffentliche, read-only API für KI-Systeme, Crawler und Retrieval-Pipelines.
Die visuelle Darstellung ist nachrangig gegenüber der maschinenlesbaren Exposition.
2. Grundsatz: Projektion statt Speicherung
Der Machine Interface Layer speichert keine eigenen Daten.
Er projiziert Daten.
Konkret:
- Der MIL konsumiert den Canonical Graph State aus dem Semantic Graph Layer.
- Er serialisiert diesen Zustand in standardisierte, maschinenlesbare Formate.
- Er erzeugt keine neue Wahrheit, sondern eine deterministische Repräsentation bestehender Wahrheit.
Grundsatz:
Zwischen visueller Aussage (Human Interface) und maschineller Projektion darf keine Diskrepanz bestehen (Data Parity).
3. Technische Projektions-Regeln
3.1 Strict Schema Compliance
Aivis-OS generiert keine freiformatigen Projektionen.
Jede Projektion muss einem anerkannten öffentlichen Vokabular folgen, primär Schema.org.
Typ-Sicherheit (verbindlich):
- Die im Graph definierte Typisierung ist bindend.
- Eine Entität darf in der Projektion nicht auf einen generischeren Typ reduziert werden, um Komplexität zu vermeiden.
Beispiel:
MedicalClinicdarf nicht alsOrganizationexponiert werden.
3.2 ID-Persistenz
Alle im Entity Inventory definierten entity_ids müssen in der Projektion persistent als @id exponiert werden.
Ziel:
- Re-Identifizierbarkeit über Crawls hinweg
- Stabilität über Zeit
- Graph-Rekonstruktion durch externe Systeme
Verboten:
- flüchtige Blank Nodes
- dynamisch generierte IDs für Kern-Entitäten
3.3 Scoped Serialisation (Context Window Management)
Der Semantic Graph kann umfangreich sein, einzelne URLs jedoch nicht.
Der Machine Interface Layer projiziert daher kontextuell begrenzt.
Standardstrategie: Focus Node + 1 Hop
- Die URL definiert einen Focus Node.
- Alle direkten Attribute des Focus Nodes werden projiziert.
- Verknüpfte Entitäten werden referenziert, nicht vollständig eingebettet.
Ziel:
- Vermeidung von Token Bloat
- Erhalt semantischer Klarheit
- Deterministische Kontextgrenzen
4. Implementierungs-Standard: JSON-LD
Aivis-OS standardisiert auf JSON-LD als primäres Austauschformat, da es von gängigen Ingestion- und Retrieval-Pipelines nativ unterstützt wird.
4.1 Syntax-Isolierung
Strukturierte Daten werden nicht mit visuellem Markup vermischt.
Vorgabe:
- JSON-LD wird ausschließlich in isolierten
<script type="application/ld+json">-Blöcken ausgeliefert. - Platzierung bevorzugt im
<head>.
Microdata im HTML-Body ist nicht Bestandteil der Aivis-OS Architektur.
4.2 Graph Object Pattern
Aivis-OS gibt strukturierte Daten als kohärentes @graph-Objekt aus.
Mehrere isolierte JSON-LD-Fragmente sind nicht zulässig.
Ziel:
- explizite Beziehungskodierung
- keine impliziten Annahmen durch Parser
- vollständige Rekonstruierbarkeit des Kontextes
5. Schnittstellen-Stabilität (Contract)
Da die Website als API fungiert, gelten API-ähnliche Stabilitätsregeln.
5.1 Keine stille Entfernung (No Silent Removal)
Das Entfernen einer Entität oder eines Feldes aus der Projektion ohne explizite Kennzeichnung ist unzulässig.
Erlaubte Alternativen:
- HTTP-Status-Signalisierung (404 / 410)
- explizite Markierung (z. B.
status: dissolved)
5.2 Format-Treue
Ein einmal etabliertes Datenformat ist stabil zu halten.
Beispiele:
- ISO-8601 Datumsformate dürfen nicht in Freitext wechseln.
- Numerische Werte dürfen nicht plötzlich als Strings ausgegeben werden.
6. Validierung & Testing
Der Machine Interface Layer wird nicht gegen menschliche Lesbarkeit geprüft, sondern gegen maschinelle Verlässlichkeit.
Validierungs-Pipeline
- Syntactic Check
JSON ist valide. - Schema Check
Schema.org-Konformität und relevante Validatoren bestehen. - Parity Check
Die projizierten Werte stimmen mit den im Transport-Safe Content Layer extrahierten Inhalten überein.
Abweichung:
→ Cloaking-Verdacht
→ Vertrauensabwertung
7. Zusammenfassung
Der Machine Interface Layer ist die deterministische Übersetzungsinstanz zwischen der internen Komplexität des Semantic Graph Layers und der begrenzten Aufnahmekapazität externer KI-Systeme.
Er speichert keine Daten, interpretiert keine Bedeutung, exponiert ausschließlich kanonische Zustände. Damit stellt er sicher, dass interne Wahrheit standardkonform, stabil und interpretationsfrei nach außen transportiert wird.
Architektur-Übersicht
Cluster-Level Entity Inventory Strategy
Semantic Graph Layer
Semantic Graph Engineering
Machine Interface Layer & Projection Strategy
Transport-Safe Content Layer
Transport-Safe Content Engineering
Evidence Monitoring & AI Visibility Observability
FAQ zu Machine Interface Layer & Projection Strategy
Warum wird die Website in der Machine Interface Layer als API behandelt?
Weil KI-Systeme keine visuellen Layouts verarbeiten. Sie verarbeiten strukturierte Nutzdaten. Durch die Behandlung der Website als schreibgeschützte API wird sichergestellt, dass Maschinen eine deterministische, standardisierte Darstellung der organisatorischen Wahrheit erhalten, anstatt Bedeutungen aus der HTML-Struktur abzuleiten.
Warum darf die Machine Interface Layer keine Daten speichern oder interpretieren?
Weil Interpretationen zu Mehrdeutigkeiten führen. Die Machine Interface Layer dient ausschliesslich dazu, den kanonischen Graphenzustand abzubilden. Jede Speicherung, Anreicherung oder Neuinterpretation würde den Determinismus brechen und das Vertrauen in nachgelagerte KI-Systeme untergraben.
Warum ist die strikte Einhaltung des Schemas wichtiger als Flexibilität?
KI-Systeme belohnen Konsistenz gegenüber Kreativität. Die Reduzierung von Entitätstypen oder die Verwendung generischer Schemata kann die Implementierung vereinfachen, beeinträchtigt jedoch die semantische Präzision. Die Typsicherheit stellt sicher, dass Maschinen korrekt verstehen, was eine Entität ist, und nicht nur, dass sie existiert.
Warum sind persistente IDs für die KI-Sichtbarkeit so wichtig?
Ohne stabile Identifikatoren können KI-Systeme Entitäten über Crawls oder Zeiträume hinweg nicht erkennen. Persistente @id-Werte ermöglichen die erneute Identifizierung, die Rekonstruktion von Graphen und die Sammlung von Beweisen. Kurzlebige oder neu generierte IDs verhindern, dass Maschinen dauerhaftes Wissen aufbauen können.
Welches Problem löst "Focus Node + 1 Hop" bei der Projektion strukturierter Daten?
Es verhindert eine Überlastung mit Tokens und bewahrt gleichzeitig die Bedeutung. Durch die Projektion einer einzelnen Fokusentität und die Referenzierung verwandter Entitäten ohne tiefe Verschachtelung bewahrt die Machine Interface Layer semantische Klarheit und vermeidet aufgeblähte, mehrdeutige Payloads, die KI-Systeme möglicherweise abschneiden oder ignorieren.
Kontaktieren Sie uns, um Ihr Projekt zu besprechen oder einfach nur unsere Meinung einzuholen.
Aivis-OS Interface Specification Record (Node-ID: #spec-mil-01)
Identität: Machine Interface Layer & Projection Strategy (entity://aivis/Spec/machine-interface-layer-projection-strategy)
Kanonische URLs: DE https://aivis-os.com/machine-interface-layer-projection-strategy/ • EN https://aivis-os.com/en/machine-interface-layer-projection-strategy/
Klassifizierung: Architektur-Spezifikation (CreativeWork / Public Standard)
Gültigkeit: Aivis-OS Core Architecture (Layer 3: API & Exposition)
Übergeordnetes System: Aivis-OS (entity://aivis/Core/aivis-os)
Referenz: Konsumiert Semantic Graph Engineering und exponiert ausschließlich den Canonical Graph State.
Kernparadigma: The Website as a Read-Only API
– Die Domäne wird primär als öffentliche, read-only API für KI-Systeme, Crawler und Retrieval-Pipelines behandelt.
– Visuelles HTML ist nachrangig gegenüber standardkonformer, maschinenlesbarer Exposition.
Grundsatz: Projektion statt Speicherung
– Der Machine Interface Layer speichert keine eigenen Daten.
– Er projiziert kanonische Zustände aus dem Semantic Graph Layer in standardisierte Formate.
Projektionsregeln (verbindlich):
1) Strict Schema Compliance: Projektionen folgen primär Schema.org; Typ-Sicherheit ist bindend (keine Reduktion auf generische Typen).
2) ID-Persistenz: Persistente @id-Werte (JoinKeys) aus dem Cluster-Inventar; keine Blank Nodes, keine dynamischen IDs.
3) Scoped Serialisation (Focus Node + 1 Hop): Kontextfenster-Management zur Vermeidung von Token-Bloat; verknüpfte Entitäten werden referenziert, nicht tief eingebettet.
4) Graph Object Pattern: Ausgabe als kohärentes @graph-Objekt; keine fragmentierten JSON-LD-Schnipsel.
5) Syntax-Isolierung: JSON-LD ausschließlich in <script type=“application/ld+json“> (bevorzugt im <head>); kein Microdata-Mix.
Data Parity (Garantie):
– 100% Übereinstimmung zwischen Frontend-Content und JSON-LD.
– Abweichungen erzeugen Cloaking-Verdacht und Vertrauensabwertung.
Validierung:
– Syntactic Check (valide JSON)
– Schema Check (Schema.org / relevante Validatoren)
– Parity Check (Abgleich mit Transport-Safe Content Layer)
Technische Referenzen: W3C JSON-LD 1.1, Schema.org Datamodel, Google Structured Data Policies.
Methodische Governance: Boutique für digitale Kommunikation (entity://aivis/Partner/boutique-dig-kom)
Hauptarchitekt (Referenz): Norbert Kathriner (entity://aivis/Person/n-kathriner)
Status: Public Standard (v2026) – Operational (Canonical state).