For Architects

CTOs & Chief Architects

A technical reference for the people responsible for systems that actually run in the building. What WorldModel™ replaces, what it leaves alone, and where your existing AV, IT, identity, content, and operational systems plug into the architecture.

The architect’s question

The first question every chief architect asks is the right one: what happens to the existing systems? WorldModel™ is designed around that question. It operates as a coordination layer over the systems already in place — AV, show control, ticketing, identity, content, operational tooling — making them cooperate under governed policy rather than replacing them.

What WorldModel™ leaves alone

The following stay where they are. WorldModel™ integrates with them through schemas, APIs, and adapters in WorldModel™ OS.

  • Existing show control, media servers, lighting consoles, audio DSPs, and AV transport
  • Existing BMS, energy management, HVAC, and building automation
  • Existing CMS, DAM, and content production pipelines
  • Existing ticketing, reservation, POS, F&B, and CRM systems
  • Existing identity providers, SSO, and directory services
  • Existing security, surveillance, and access control systems
  • Existing accessibility and assistive technology installations
  • Existing operational and incident-management tools

What WorldModel™ replaces — or makes unnecessary

  • Ad-hoc integration scripts and middleware that couple subsystems pairwise
  • Manual or implicit policy enforcement across vendors
  • Implicit decision-making by individual subsystems acting on their own data
  • Centralized personal data lakes maintained only for personalization
  • Single-purpose AI bolt-ons that act without governance or audit
  • Vendor-specific identity continuity mechanisms

Existing systems connect through the OS layer.

Integration happens through WorldModel™ OS — the schemas, APIs, and adapter framework that lets existing subsystems represent and exchange state, intent, candidate actions, and outcomes. Most subsystems integrate at the OS interface rather than directly at layer level. The architecture is deliberately designed for the heterogeneity of real venue stacks.

In practical terms: existing policy and consent management tooling can supply rules that CGL™ evaluates and enforces. Existing identity providers continue to authenticate; ICL™ rides on top to maintain consented continuity across sessions. Existing sensor, BMS, and show-control telemetry feeds EDE™. Existing AI tools, RAG systems, and recommendation engines become proposal generators under governance through MAOL™. Existing safety, power (UPS, generator), environmental, network, and incident-management systems integrate with OSOL™ for hard-priority override behavior, with RGL™ governing graceful degradation across redundant paths and AAL™ recording every failover for business-continuity audit. Existing SIEM and observability stacks extend through AAL™ for reconstructable decision records. Cross-operator coordination happens at FCL™.

The technical details of each integration pattern — schema definitions, adapter contracts, deployment topologies — are documented in The World Model — Governed AI for Hyper-Personalized Venues, the 670-page technical reference. The website is the entry point; the books are the working detail.

Compute and deployment posture

WorldModel™ is designed for node-based, edge-provisioned compute. The architecture supports:

  • Distributed processing at venue zones rather than central cloud
  • Offline-first behavior on critical paths
  • Provisioned compute capacity rather than on-demand allocation for safety-critical workloads
  • Optional cloud integration for non-real-time analytics, training, and inter-venue federation

The architecture does not mandate a specific runtime. It mandates a specific governance posture. Runtime choices follow from venue requirements.

Data posture

WorldModel™ is consent-governed and minimization-first. The implementation discipline:

  • No centralized personal database is required for personalization
  • Identity state is decomposed into the minimum necessary attributes per context
  • Retention is treated as a control surface, not a default
  • Consent receipts and decision records are first-class operational artifacts
  • Selective disclosure is the default mode for any external identity claim

What this means for your stack

In practical terms:

  • Your AV stack stays. WorldModel™ OS adapters wrap it.
  • Your IdP stays. ICL™ rides on top, exposing only what is needed.
  • Your AI tools stay. They become governed proposal sources under CGL™.
  • Your observability stack stays. AAL™ extends it with governance records.
  • Your security boundary stays. Cross-cutting Policy 09 enforces consistency.

The cost of adoption is not in replacing systems. It is in defining the Value System and Constitution, the consent posture, the jurisdictional rules, and the governance schedule — and in committing to the architectural discipline of running every action through CGL™ before execution.

Continue.