| Layer | Name | Responsibility |
|---|---|---|
| 01 VS+C™ | Value System + Constitution | The venue's priorities, rights and protected limits define the purpose of its rules. |
| 02 CGL™ | Cognitive Governance Layer | Proposed actions are authorized, blocked or referred against the rules that apply at the time of action. |
| 03 TGF™ | Temporal Governance Framework | Operational, calendar, show and sensor-triggered regimes; time-bounded grants; and mutual-exclusion windows determine the applicable time context. |
| 04 ICL™ | Identity Continuity Layer | Language, access settings and relevant preferences continue within consent and purpose limits. |
| 05 EDE™ | Environmental Dynamics Engine | Space, occupancy, flow, environmental and content state, plus zone-conditional governance state, inform the proposed action at its location. |
| 06 MAOL™ | Multi-Agent Orchestration Layer | Specialist agents receive bounded tasks and coordinate under the authority granted. |
| 07 FCL™ | Federation & Coordination Layer | Venues, operators and jurisdictions can coordinate while retaining local authority. |
| 08 RGL™ | Resilience & Graceful Degradation Layer | Reduced capability leads to a defined operating response, with protected requirements given priority. |
| 09 OSOL™ | Operational Safety Override Hard Priority | Designated safety actions have hard priority over experience, personalization and orchestration. |
| 10 AAL™ | Assurance, Analytics & Audit Layer | A non-gating, append-only observer records the decision, actor, action, policy version, active regime, spatial context, consent state and evaluated rules. It does not approve or block execution. |
THE WORLDMODEL ARCHITECTURE
Ten layers.
Eleven cross-cutting policies.
Defined responsibilities, explicit authority and a shared operating context for intelligent physical environments.
The complete WorldModel framework, published definitions and wider reference material are available at WorldModel.global .
View all five architecture diagramsCANONICAL REFERENCE AND IMPLEMENTATION
A defined architecture. A specified implementation.
Published reference architecture: ten architectural layers and eleven cross-cutting policies, as defined at WorldModel.global. The layers and policies describe the complete architecture.
Project implementation: the participating systems, adapters, information, authority, redundancy and verification are specified for the installation. Publishing an architecture does not establish that every interface or capability is implemented in every Mad system.
SEE THE WHOLE ARCHITECTURE
Five diagrams.
A connected view.
Explore the layers, policies, operating cycle, federation and technology landscape. Each diagram has a dedicated view, an enlargement and a downloadable vector copy.
DIAGRAM 01The ten architectural layers
Responsibilities, authority and the relationships between them.
View diagram
DIAGRAM 02The eleven cross-cutting policies
Consent, accessibility and the rules that apply across the architecture.
View diagram
DIAGRAM 03The closed-loop runtime
From current context to a governed action and the next observation.
View diagram
DIAGRAM 04The federation pattern
Coordinate participating venues while preserving their local authority.
View diagram
DIAGRAM 05The technology landscape
How Mad’s individual technologies connect with the wider architecture.
View diagramTECHNICAL DETAILGive every responsibility a place.
Open the engineering detailClose this sectionLook for the red circuit symbol for engineering detail.
WorldModel™ coordinates systems through ten architectural layers and eleven cross-cutting policies. The layers define responsibilities and their relationships. The policies define rules that operate across those responsibilities.
The architecture includes distinct paths for context, governance, orchestration, safety and evidence. Proposed actions are evaluated against the current rules before execution. Designated safety actions can preempt the operating flow; assurance observes and records.
PRECEDENCE
Safety acts. Assurance records.
VS+C™ supplies the declared priorities, rights and protected limits. CGL™ evaluates proposals against the current rules, drawing on temporal state from TGF™ and relevant environment and consent information.
OSOL™ gives designated safety actions hard priority over experience goals, personalization and orchestration. Such an action does not wait for the outcome-closure cycle or an audit acknowledgment. Recovery follows the authorized path.
AAL™ is a non-gating, append-only observer. It records the action, the actor, the policy version, the active regime, relevant spatial context, consent state and decision. Its role does not approve, delay or block execution.
The ten layers are cooperating architectural responsibilities. Their interfaces and precedence determine the operating flow.
TECHNICAL DETAILEleven cross-cutting policies.
Open the engineering detailClose this section
Some rules affect many parts of the system at once. Consent, accessibility, content trust and sensory limits need to inform identity, context, decision-making, execution and the resulting record.
The eleven cross-cutting policies make those obligations explicit throughout the architecture.
| Policy | Name | Purpose |
|---|---|---|
| 01 | Jurisdictional Adaptation | Apply the rules appropriate to each jurisdiction. |
| 02 | Content Provenance & Trust | Keep content connected to approved sources and permitted transformations. |
| 03 | Human-in-the-Loop Governance | Give authorized people defined approval and override roles. |
| 04 | AR / MR / XR Governance | Govern immersive overlays in their physical and audience context. |
| 05 | Acoustic & Sensory Governance | Keep sound, light, motion and other sensory effects within defined limits. |
| 06 | Commerce & Entitlement | Apply access, purchase and entitlement rules coherently. |
| 07 | Lifecycle Evolution | Preserve governance through versioning, change and retirement. |
| 08 | Safety-Authority Schedule | Define the hierarchy and precedence of safety authorities. |
| 09 | Security & Trust-Boundary | Protect interfaces, data and operational authority. |
| 10 | Accessibility & Inclusion | Treat access needs as requirements throughout the system. |
| 11 | Consent & Data Sovereignty | Evaluate consent during operation and respect boundaries on data use. |
TECHNICAL DETAILSpatial governance belongs within the ten layers.
Open the engineering detailClose this section
WorldModel.global defines zone-conditional governance as a property of the architecture. EDE™ supplies the relevant spatial state, cross-cutting policies supply location-dependent rules, TGF™ resolves the time and shared-resource windows, and CGL™ evaluates the combined rule set. There is no additional spatial runtime layer.
Illustrative coordination question: can two activities use the same circulation area at the same time? The architecture relates their place, timing and authority before an action is authorized. The project must define the actual safety interface, protected behavior and evidence.
AT RUNTIME
From relevant context to governed action.
Venue systems, sensors, staff tools, schedules and permitted visitor interactions supply relevant state. Specialist logic and AI components can then propose actions against the current objectives.
CGL evaluates the proposal using the rules that apply to its time, place, subject and operating conditions. Approved actions are dispatched through appropriate interfaces. The resulting observations and decision records inform subsequent operation.
RGL defines behavior when capability is reduced. FCL coordinates across operators or venues while preserving local authority. OSOL retains its safety precedence throughout.
OUTCOME AND CONTINUITY
Connect governance with evidence of delivery.
Mad Intelligence™ connects the retained requirement to qualified resources, physical delivery, appropriate evidence and the work that remains unresolved. WorldModel supplies context and authority for those decisions.
The outcome assessment is distinct from the assurance record. Recording that a command was permitted and dispatched does not by itself establish that the intended physical result occurred.
These relationships remain useful as content, resources and implementations change. The architecture gives the next decision the context, authority and history it needs.
TECHNICAL DETAILSpecify redundancy, behavior and evidence together.
Open the engineering detailClose this section
The canonical architecture treats redundancy as a configurable provision. A project can specify relevant power, environmental, network, compute, storage, layer, data, federation and operational arrangements. The appropriate posture depends on the venue and its required continuity.
RGL™ defines how operation changes when capability is reduced. AAL™ records the resulting transitions and decisions. OSOL™ retains its hard safety priority. Redundancy provision, degraded behavior and evidence are related responsibilities; their presence and performance are established for the actual implementation.
LET’S BUILD WHAT COMES NEXT
Specify the operating architecture early.
Bring the venue purpose, access needs, operating priorities and integration constraints into the same conversation.
Talk architecture with Mad