Referenz-Architektur

WorldModel-Architektur

Eine gesteuerte Betriebsarchitektur für hyper-personalisierte physische Umgebungen. WorldModel™ koordiniert Multi-Vendor-Subsysteme unter einer operativen Wahrheit und einem durchsetzbaren Regelwerk — sodass sich die Destination als ein kohärentes System über viele Vendoren, viele Berührungspunkte und einen langen Betriebszyklus hinweg verhält.

Das Problem, das die Architektur löst

Destinationen im großen Maßstab erfordern zunehmend Erlebnisse, die hyper-personalisiert, mehrsprachig, barrierefrei, kulturell abgestimmt und über lange Lebenszyklen hinweg operativ verantwortlich sind. Diese Anforderungen erscheinen mittlerweile routinemäßig in RFP-Sprache, Masterplanning-Narrativen und Betriebsspezifikationen für Themenparks, Museen, Multi-Venue-Distrikte, Resorts, Kreuzfahrtschiffe, Einzelhandelsumgebungen, Smart Cities und nationale Initiativen einschließlich Vision 2030 und Expo 2030.

Die meisten Destinationen werden als Sammlung spezialisierter Systeme geliefert — Medien, Beleuchtung, Audio, Show-Steuerung, Wayfinding, Beschilderung, Barrierefreiheits-Dienste, Apps, Sensoren, Ticketing und Betriebstools — jedes für seine eigene Funktion optimiert. Im großen Maßstab ist die primäre Herausforderung kein einzelnes Subsystem.

Die Herausforderung besteht darin, konsistentes Verhalten, durchsetzbare Policy und operative Verantwortung über Systeme, Zonen und Zeit hinweg aufrechtzuerhalten.

Mit zunehmender Autonomie steigen die Kosten der Inkohärenz. Ohne eine explizite Betriebsarchitektur sammeln Destinationen Integrationsschulden, Policy-Drift, inkonsistente Gast-Erfahrung und eskalierendes operatives Risiko an, während sie skalieren.

Was WorldModel™ ist

WorldModel™ ist eine gesteuerte Betriebsarchitektur für intelligente physische Umgebungen. Sie koordiniert Multi-Vendor-Subsysteme unter einer gemeinsamen operativen Wahrheit und einem durchsetzbaren Regelwerk, sodass sich eine Destination als ein kohärentes System über viele Vendoren, viele Berührungspunkte und einen langen Betriebszyklus hinweg verhält.

Die Architektur besteht aus zehn Schichten und elf schichtenübergreifenden Richtlinien. Die Schichten definieren Struktur. Die Richtlinien definieren Regeln, die über diese Struktur hinweg wirken. Zusammen bilden sie die vollständige Referenz.

Ein Prinzip, das klar ausgesprochen werden sollte

Eine Architektur ist am wertvollsten, wenn sie ausgewählt und festgelegt wird, bevor die Ausführungsdokumente herausgegeben werden. Die strukturellen Entscheidungen, die Barrierefreiheit, mehrsprachige Kontinuität, Einwilligungshaltung, Safety-Override und operative Verantwortung bestimmen, werden in der Konzeptphase getroffen — ob bewusst oder per Standard. Ein Programmbrief, der um Hardware geschrieben ist, bekommt Hardware. Ein Programmbrief, der um das geschrieben ist, was der Veranstaltungsort tun soll, bekommt etwas wesentlich anderes. Dieselbe Disziplin bewahrt Vorwärtskompatibilität: für die Lebensdauer des Veranstaltungsorts zu architektonieren, nicht nur für die erste Phase, kostet in der Installation marginal mehr und gibt diese Kosten bei jeder nachfolgenden Erweiterung zurück. WorldModel™ gibt dem frühen Gespräch ein Vokabular, das seine Bedeutung durch jede nachfolgende Phase hindurch behält.

Ergebnisse, die die Architektur unterstützt

  • Hyper-personalisierte Gast-Erfahrung über Berührungspunkte hinweg, keine isolierten Momente
  • Barrierefreiheit als Systembeschränkung behandelt, keine Nachrüstung
  • Mehrsprachige Kontinuität über Zonen, Geräte und Personalinteraktionen hinweg
  • Altersgerechte Anpassung und Familien- oder Gruppenkontinuität
  • Policy-gesteuerter Betrieb über Kulturen und Jurisdiktionen hinweg
  • Operative Kohärenz über Subsysteme hinweg, mit Reduzierung vermeidbarer Konflikte
  • Auditierbarkeit und operative Transparenz mit nachverfolgbaren Entscheidungspfaden
  • Venue-Grade-Resilienz mit Compute nahe am Erlebnispunkt bereitgestellt
  • Kontrollierte Degradation mit Safety, Barrierefreiheit und Vertrauen vor Optimierung bewahrt
  • Föderation über Operatoren und Jurisdiktionen hinweg ohne Aufhebung lokaler Autorität

Zonenbedingte Regelauswahl

Räumliche Governance wird als Eigenschaft der zehnschichtigen Architektur implementiert, nicht als elfte Runtime-Schicht. Vier Schichten arbeiten bei jeder gesteuerten Entscheidung zusammen, um das aktive Regelset für die vorgeschlagene Aktion in ihrer spezifischen Zeit und ihrem spezifischen Ort zu erzeugen.

CGL™ konsultiert EDE™ für den zonenbedingten Governance-Zustand, der für jede vorgeschlagene Aktion gilt. Zonenbedingte Regelsets stammen aus den schichtenübergreifenden Richtlinien (Jurisdiktionale Anpassung, AR/MR/XR-Governance, Akustische und sensorische Governance, Barrierefreiheit und Inklusion, Einwilligung und Datensouveränität, Handel und Berechtigung). CGL™ kombiniert diese zonenbedingten Regeln mit dem von TGF™ gelieferten temporalen Regime, um das aktive Regelset für den aktuellen Moment zu erzeugen.

Zonen-Mutual-Exclusion-Sperren auf gemeinsam genutzten physischen Ressourcen werden von TGF™ als zeitlich begrenzte Fenster verwaltet, die auf den räumlichen EDE™-Zustand verweisen, da ihre definierende Eigenschaft temporale Koinzidenz auf einer gemeinsamen Ressource ist, nicht die räumliche Position allein. Das kanonische Beispiel: ein Barrierefreiheits-Übergang auf einem Platz darf nicht mit einer Theater-Ausströmung in denselben Platz zusammenfallen, und der umgekehrte Fall, in dem die Theater-Freigabe nicht mit einem laufenden Barrierefreiheits-Übergang zusammenfallen darf.

Das Muster ist geradlinig. EDE™ liefert den zonenbedingten Governance-Zustand. Die schichtenübergreifenden Richtlinien liefern die zonenbedingten Regeln. TGF™ liefert die Temporal-Koinzidenz-Arbitrierung. CGL™ löst das kombinierte aktive Regelset bei jeder gesteuerten Entscheidung auf. Räumliche Governance ist daher eine Eigenschaft der Architektur, keine Ergänzung zu ihr.

Redundanz & Geschäftskontinuität

Redundanz wird als konfigurierbare architektonische Eigenschaft des Frameworks behandelt, kein festes Implementierungsmuster. Jede WorldModel™-Bereitstellung beinhaltet eine explizite Redundanz-Haltung, die in der Konzeptphase festgelegt und durch den Programmbrief, das technische Narrativ und den Betriebsplan getragen wird. Die Architektur unterstützt das gesamte Spektrum an Haltungen, das Operatoren von Venue-Grade und Destination-Grade erfordern:

  • Strom-Redundanz. USV-Abdeckung für governance-kritische Compute, Generator-Backup mit definiertem Übertragungsverhalten und Dual-Path-Stromeinspeisungen, wo die Venue-Infrastruktur dies unterstützt. Der Notstrom-Umfang wird pro Zone spezifiziert, mit Priorität für sicherheitsrelevante Systeme.
  • Umgebungs-Redundanz. HLK, Brandbekämpfung und Temperaturüberwachung für Compute- und Rack-Umgebungen. Umgebungsabweichungen werden erkannt und aufgezeichnet; degradierte Umgebungsbedingungen lösen definierte Betriebsreaktionen aus.
  • Netzwerk-Redundanz. Redundantes Routing, Failover-Links und isolierte Management-Ebenen. Das nicht-proprietäre Netzwerk-Substrat unterstützt Standard-Hochverfügbarkeitskonfigurationen ohne proprietäre Bindung.
  • Compute- und Speicher-Redundanz. Duplizierte Compute-Knoten, parallele Medienpfade und replizierter Speicher auf der physischen Schicht. Das nicht-proprietäre Compute-Substrat ist so konzipiert, dass es N+1- und 2N-Konfigurationen unterstützt, wo die Venue-Anforderungen dies verlangen.
  • Schicht-Redundanz. Mehrere Instanzen kritischer Governance-Schichten — CGL™, ICL™, AAL™ — mit definiertem Failover-Verhalten. Die Architektur verlangt nicht, dass eine einzelne Instanz einer Schicht ein Single Point of Failure ist.
  • Daten-Redundanz. Replizierter Zustand, Einwilligungsbelege und Audit-Trails über Ausfallbedingungen hinweg bewahrt, sodass die Venue immer rekonstruieren kann, was passiert ist, und den Betrieb aus einem bekannten guten Zustand wieder aufnehmen kann.
  • Föderations-Redundanz. Durch FCL™ ermöglicht die Multi-Site-Koordination, dass eine Venue oder ein operatives Zentrum während eines lokalen Ausfalls Kontinuität für ein anderes bietet, wo das Programmdesign dies unterstützt.
  • Operative Redundanz. Ersatzteilbestand, Schnellaustauschverfahren und dokumentierte mittlere Wiederherstellungszeit-Ziele. Architektonische Redundanz wird mit operativer Disziplin gepaart; eines ohne das andere liefert keine Geschäftskontinuität.

Die Architektur unterscheidet drei Verantwortlichkeiten klar. Redundanz ist die Bereitstellung — was zur Entwurfszeit dupliziert, repliziert oder parallelisiert wird. RGL™ (Resilienz und kontrollierte Degradation) steuert das Verhalten unter Ausübung — wie das System handelt, wenn Redundanz aufgerufen wird, mit Safety, Barrierefreiheit und Vertrauen vor Optimierung in jedem degradierten Modus bewahrt. AAL™ (Assurance, Analyse & Audit) erfasst den Nachweis — jedes Failover-Ereignis, jede degradierte Periode und jede Wiederherstellung, in rekonstruierbarer Form aufgezeichnet. Die Aufteilung ist wichtig: ein Hochverfügbarkeits-Anspruch ohne die Nachweis-Schicht ist eine Behauptung, keine verifizierbare Eigenschaft der Bereitstellung.

Procurement-Sprache für Programme von Venue-Grade und Destination-Grade kann erforderliche Haltungen aus der obigen Liste spezifizieren, definiert pro Zone oder pro System. Das Framework erlegt kein einzelnes Redundanzmuster auf; es unterstützt das Spektrum von minimal (Single-Path, nur Software-Redundanz) über Standard (USV plus N+1-Compute plus replizierte Daten) bis vollständig fehlertolerant (2N-Strom, redundantes Netzwerk, Schicht-Failover, föderierte Kontinuität), wobei die Spezifikation gegen die operative Risikotoleranz und das Budget der Venue gewählt wird.

Architekturschichten, auf einen Blick.

Jede Schicht hat eine definierte Rolle, eine durchsetzbare Schnittstelle und eine Vorrangs-Beziehung zu den anderen. Die vollständigen Definitionen sind in der WorldModel™-Referenz dokumentiert.

01
VS+C™Wertesystem + Verfassung
Die normative Quelle der Wahrheit — was „gut" an diesem Veranstaltungsort bedeutet.
02
CGL™Kognitive Governance-Schicht
Echtzeit-Durchsetzung. Setzt VS+C™-Invarianten direkt durch und bewertet jede vorgeschlagene Aktion gegen das kombinierte aktive Regelset (Einwilligung, Jurisdiktion, Regime, Zone, Policy).
03
TGF™Temporales Governance-Rahmenwerk
Zeit als erstklassige gesteuerte Dimension. Operative, Kalender-, Show- und sensorgetriggerte Regime; zeitlich begrenzte Gewährungen; Mutual-Exclusion-Fenster auf gemeinsam genutzten physischen Ressourcen.
04
ICL™Identitätskontinuitätsschicht
Einwilligungsgebundene Kontinuität von Präferenzen und Kontext über Sitzungen hinweg.
05
EDE™Engine für Umgebungsdynamik
Kontinuierliches physisches Weltmodell: Raum, Fluss, Belegung, Bedingungen, Content-Zustand, plus der zonenbedingte Governance-Zustand, der Aktion nach Ort einschränkt.
06
MAOL™Multi-Agenten-Orchestrierungsschicht
Gesteuerte Koordination von Spezialisten-Agenten und begrenztem Tool-Einsatz.
07
FCL™Föderations- und Koordinationsschicht
Koordination über Veranstaltungsorte, Operatoren und Jurisdiktionen hinweg.
08
RGL™Resilienz- und kontrollierte Degradationsschicht
Definiertes Verhalten unter reduzierter Fähigkeit — sichere Degradation by Design.
09
OSOL™Operative Sicherheitsübersteuerung — Harte Vorrangstellung
Übersteuert jede andere Schicht, wenn Safety es erfordert.
10
AAL™Assurance-, Analyse- und Auditschicht
Nicht-blockierend, append-only. Zeichnet den vollständigen Governance-Rahmen bei jeder Entscheidung auf: Policy-Version, aktives Regime, räumlicher Kontext, Einwilligungszustand, bewertetes Regelset, Aktion und Akteur.

Architektur zur Laufzeit.

Die Architektur drückt ein Closed-Loop-System aus. Jeder Zyklus wird vor der Ausführung gesteuert und danach aufgezeichnet.

Erfassen und Aufnehmen

Signale kommen von Veranstaltungsort-Systemen, Sensoren, Zeitplänen, Personal-Tools, Ticketing- und Reservierungssystemen, operativen Eingaben und erlaubten Besucher-Interaktionen.

Gemeinsame operative Wahrheit aktualisieren

Die WorldModel™-Repräsentation wird kontinuierlich aktualisiert, sodass jedes Subsystem aus derselben kontextuellen Grundwahrheit handeln kann.

Kandidaten-Aktionen vorschlagen

Spezialisierte Agenten schlagen Aktionen basierend auf aktuellem Zustand und Zielen vor. KI-Komponenten sind Vorschlagsgeneratoren, keine Entscheidungsautoritäten.

Jede Aktion vor der Ausführung steuern

Die Kognitive Governance-Schicht™ bewertet jeden Vorschlag gegen das Wertesystem, die Verfassung, Einwilligung, Jurisdiktion, temporale Beschränkungen und operative Policy. OSOL™ übersteuert, wenn aufgerufen.

Ausführen, verifizieren und aufzeichnen

Genehmigte Aktionen werden über Adapter versandt. Die Ergebnisverifikation bestätigt, dass die Aktion Wirkung hatte. Governance-Ergebnisse und Begründungsaufzeichnungen werden als Teil der operativen Transparenz aufbewahrt.

Regeln, die schichtenübergreifend wirken.

Schichtenübergreifende Richtlinien sind Regeln und Durchsetzungsmechanismen, die über mehrere Schichten wirken. Sie werden nie Schichten genannt, nie Concerns genannt und nie als Hilfs-Features behandelt. Jede ist vollständig in der Referenz dokumentiert.

Policy 01
Jurisdiktionale Anpassung
Privacy, Einwilligung, Aufbewahrung, Altersbeschränkungen, Inhaltsregeln — pro Jurisdiktion angewandt.
Policy 02
Inhaltsherkunft & Vertrauen
Genehmigte-Quellen-Verfolgung und Anti-Konfabulation durch Architektur.
Policy 03
Mensch-in-der-Schleife-Governance
Definierte Übersteuerungspunkte mit Autorität als Governance-Ereignis aufgezeichnet.
Policy 04
AR/MR/XR-Governance
Räumliche Registrierung, Safety, Altersangemessenheit für immersive Overlays.
Policy 05
Akustische & sensorische Governance
Klang, Licht, Bewegung, Haptik, sensorische Gestaltung für Inklusion und Komfort.
Policy 06
Handel & Berechtigung
Zugriffs-, Kauf- und Freischaltungsregeln angewandt mit Audit und Einwilligung bewahrt.
Policy 07
Lebenszyklusentwicklung
Versionierung, Deprecation, Migration — verfassungsmäßige Kontinuität über die Zeit.
Policy 08
Safety-Authority-Schedule
Die definierte Hierarchie der Safety-Autorität und Laufzeit-Vorrangstellung.
Policy 09
Security & Trust-Boundary
Kryptografische, Netzwerk- und operative Grenzen über jede Schicht hinweg.
Policy 10
Barrierefreiheit & Inklusion
Inklusion als strukturelle Eigenschaft der Architektur, keine Nachrüstung.
Policy 11
Einwilligung & Datensouveränität
Einwilligung als fortlaufende operative Bedingung; Datensouveränität by Design.

Was WorldModel™ ersetzt und was es unangetastet lässt

Die Architektur ist für die Welt entworfen, wie sie gebaut ist. Bestehende AV-, Show-Steuerungs-, Ticketing-, Content-, Identitäts- und Betriebssysteme integrieren sich über Schemas und Adapter in WorldModel™ OS — sie funktionieren weiter, gesteuert von der Schicht darüber.

Was es unangetastet lässt

  • Bestehende AV-, Show-Steuerungs-, Beleuchtungs- und Audio-Subsysteme
  • Bestehende BMS-, Ticketing-, Reservierungs- und POS-Systeme
  • Bestehende Content-Management-, DAM- und CMS-Systeme
  • Bestehende CRM-, Marketing-Automatisierungs- und Analytics-Tools
  • Bestehende Identity Provider und SSO-Infrastruktur

Was es ersetzt — oder unnötig macht

  • Ad-hoc-Integrationsskripte zwischen Subsystemen
  • Manuelle Policy-Durchsetzung über Vendoren hinweg
  • Implizite Entscheidungsfindung durch einzelne Subsysteme
  • Zentralisierte Personendaten-Lakes, die für Personalisierung verwendet werden
  • Single-Purpose-KI-Bolt-Ons, die ohne Governance handeln

Wie Integration funktioniert

Integration erfolgt durch WorldModel™ OS: Schemas, APIs und Adapter, die es bestehenden Systemen ermöglichen, operative Wahrheit, Absicht, Beschränkungen und Kandidaten-Aktionen zu repräsentieren und auszutauschen. Jedes Subsystem integriert sich in die OS-Schnittstelle unter bereitstellungsdefinierten Schemas. Die Ausführung wird durch das Wertesystem, die Verfassung und die Kognitive Governance-Schicht™ kontrolliert.

Fortsetzen.