参考架构

WorldModel 架构

面向超个性化物理环境的受治理运行架构。WorldModel™ 在一个共享运行事实和一份可执行规则手册之下协调多供应商子系统——使目的地能够跨众多供应商、众多触点和长期运营生命周期表现为一个连贯的系统。

该架构解决的问题

目的地规模的环境日益要求其体验是超个性化的、多语言的、可访问的、文化协调的,并在长生命周期内具有运营责任。这些要求现在常规地出现在主题公园、博物馆、多场所地区、度假村、邮轮、零售环境、智慧城市以及包括 2030 愿景和 2030 世博会在内的国家级倡议的 RFP 语言、总体规划叙述和运营规范中。

大多数目的地是作为一组专门系统交付的——媒体、灯光、音频、表演控制、寻路、标识、无障碍服务、应用程序、传感器、票务和运营工具——每个都为其自身功能进行了优化。在规模化时,主要挑战不是任何单独的子系统。

挑战是在系统、区域和时间之间维持一致的行为、可执行的政策和运营责任。

随着自治性的提高,不一致的代价也在上升。在没有显式运行架构的情况下,目的地会积累集成债务、政策漂移、不一致的访客体验,以及随规模上升的运营风险。

WorldModel™ 是什么

WorldModel™ 是面向智能物理环境的受治理运行架构。它在共享运行事实和可执行规则手册之下协调多供应商子系统,使目的地能够跨众多供应商、众多触点和长期运营生命周期表现为一个连贯的系统。

该架构由十层和十一项横切政策组成。层定义结构。政策定义跨该结构运作的规则。它们共同构成完整的参考。

一个值得清晰陈述的原则

一个架构在建造文件发出之前被选定并承诺时最有价值。决定无障碍、多语言连续性、同意立场、安全覆盖和运营责任的结构性决策是在概念阶段决定的——无论是故意还是默认。围绕硬件撰写的项目纲要将获得硬件。围绕场所应当什么撰写的项目纲要将获得本质上不同的结果。同样的纪律保留向前兼容性:为场所使用寿命而非仅为第一阶段进行架构设计,在安装时仅略多花费,并在之后的每次扩展中归还这一成本。WorldModel™ 为早期对话提供了一种在之后每个阶段都保持其含义的词汇。

该架构支持的结果

  • 跨触点(而非孤立时刻)的超个性化访客体验
  • 无障碍作为系统约束,而非事后改造
  • 跨区域、设备和员工交互的多语言连续性
  • 适合年龄的调适和家庭或团体连续性
  • 跨文化和司法管辖区的策略治理运营
  • 跨子系统的运营一致性,减少可避免的冲突
  • 具有可追溯决策路径的可审计性和运营透明度
  • 计算资源配置在体验点附近的场所级韧性
  • 有序降级,在优化之前保留安全、无障碍和信任
  • 跨运营方和司法管辖区的联邦,而不取消本地权威

区域条件规则选择

空间治理作为十层架构的属性来实现,而非作为第十一个运行时层。四层在每个受治理的决策中协作,为其特定时间和地点的提议行动产生活动规则集。

CGL™ 向 EDE™ 咨询适用于每个提议行动的区域条件治理状态。区域条件规则集来源于横切政策(司法管辖适应、AR/MR/XR 治理、声学与感官治理、无障碍与包容、同意与数据主权、商业与权益)。CGL™ 将这些区域条件规则与 TGF™ 提供的时间体制结合,为当前时刻产生活动规则集。

共享物理资源上的区域级互斥锁由 TGF™ 作为时限窗口管理,引用 EDE™ 的空间状态,因为它们的定义属性是在共享资源上的时间一致性,而非仅仅空间位置。典型示例:广场上的无障碍交叉路线必须不与剧院出口涌入同一广场重合,反之亦然——剧院疏散必须不与正在进行的无障碍交叉重合。

该模式直截了当。EDE™ 提供区域条件治理状态。横切政策提供区域条件规则。TGF™ 提供时间一致性仲裁。CGL™ 在每个受治理决策中解析合并的活动规则集。因此,空间治理是架构的属性,而不是对其的添加。

冗余与业务连续性

冗余被视为框架的可配置架构属性,而非固定的实施模式。每次 WorldModel™ 部署都包含明确的冗余立场,在概念阶段指定,并贯穿项目纲要、技术叙述和运营计划。该架构支持场所级和目的地级运营方所要求的全部立场范围:

  • 电源冗余。关键治理计算的不间断电源(UPS)覆盖、具有已定义切换行为的发电机备份,以及在场所基础设施支持的地方采用双路供电。备用电源范围按区域指定,优先安排与安全相关的系统。
  • 环境冗余。计算和机柜环境的 HVAC、消防抑制和温度监测。环境偏差被检测并记录;降级的环境条件触发已定义的运营响应。
  • 网络冗余。冗余路由、故障转移链路和隔离的管理平面。非专有网络底座支持标准高可用性配置,无专有锁定。
  • 计算与存储冗余。在物理层重复的计算节点、并行媒体路径和复制存储。非专有计算底座设计为支持 N+1 和 2N 配置,以满足场所需求。
  • 层冗余。关键治理层(CGL™、ICL™、AAL™)的多个实例,具有已定义的故障转移行为。该架构不要求任何层的单一实例成为单点故障。
  • 数据冗余。复制状态、同意收据和审计轨迹在故障条件下被保留,使场所始终能够重建发生的事情并从已知良好状态恢复运营。
  • 联邦冗余。通过 FCL™,多场所协调允许一个场所或运营中心在本地中断期间为另一个场所提供连续性,前提是项目设计支持这种情形。
  • 运营冗余。备件库存、快速更换流程和已记录的平均恢复时间目标。架构冗余与运营纪律相配对;缺一不可,不能交付业务连续性。

该架构清晰地区分三种职责。冗余是配置——在设计时复制、复制或并行化的内容。RGL™(韧性与有序降级)管辖演练下的行为——当冗余被调用时系统如何行动,在每种降级模式下在优化之前保留安全、无障碍和信任。AAL™(保障、分析与审计)捕获证据——每次故障转移事件、每个降级期、每次恢复,以可重建的形式记录。这种划分很重要:一个没有证据层的高可用性声明是断言,而非部署的可验证属性。

场所级和目的地级项目的采购语言可以指定上述列表中要求的立场,按区域或按系统定义。该框架不强制要求单一冗余模式;它支持从最小(单路径,仅软件冗余)到标准(UPS 加 N+1 计算加复制数据)再到完全容错(2N 电源、冗余网络、层故障转移、联邦连续性)的全部范围,选定的规范对应于运营风险容忍度和场所预算。

架构层,一览。

每一层都有定义的角色、可执行的接口以及与其他层的优先级关系。完整定义记录在 WorldModel™ 参考文档中。

01
VS+C™价值体系 + 章程
规范的事实来源——"好"在这个场所意味着什么。
02
CGL™认知治理层
实时执行。直接应用 VS+C™ 的不变量,并对照合并的活动规则集(同意、司法管辖、体制、区域、政策)评估每个提议的行动。
03
TGF™时间治理框架
时间作为头等受治理维度。运营、日历、表演及传感器触发体制;时限授权;共享物理资源上的互斥窗口。
04
ICL™身份连续性层
跨会话偏好和情境的同意约束连续性。
05
EDE™环境动态引擎
物理世界的连续模型:空间、流量、占用、条件、内容状态,以及按位置约束行动的区域条件治理状态。
06
MAOL™多代理编排层
专家代理的受治理协调和有界工具使用。
07
FCL™联邦与协调层
跨场所、运营方和司法管辖区的协调。
08
RGL™韧性与有序降级层
在能力降低时的已定义行为——通过设计实现安全降级。
09
OSOL™运营安全覆盖——硬优先级
在安全要求时优先于所有其他层。
10
AAL™保障、分析与审计层
非阻塞,append-only。在每个决策中记录完整的治理框架:政策版本、活动体制、空间情境、同意状态、评估的规则集、行动和主体。

运行时架构。

该架构表达了一个闭环系统。每个循环在执行前受治理,执行后被记录。

感知与摄取

信号来自场所系统、传感器、日历、员工工具、票务和预订系统、运营输入以及允许的访客交互。

更新共享运行事实

WorldModel™ 表征被持续更新,使每个子系统能从相同的语境真相中行动。

提出候选行动

专门代理根据当前状态和目标提出行动。AI 组件是提议生成器,而非决策权威。

在执行前治理每个行动

认知治理层™根据价值体系、章程、同意、司法管辖、时间约束和运营政策评估每个提议。OSOL™ 在被调用时优先。

执行、验证与记录

已批准的行动通过适配器分发。结果验证确认行动已生效。治理结果和理由日志作为运营透明度的一部分被保留。

跨层运作的规则。

横切政策是跨多层运作的规则和执行机制。它们永远不被称为层,永远不被称为关注点,也永远不被视为辅助。每一项都在参考文档中完整记录。

政策 01
司法管辖适应
隐私、同意、保留、年龄限制、内容规则——按司法管辖区执行。
政策 02
内容来源与信任
已批准的来源跟踪和按架构的反编造。
政策 03
人在环中治理
已定义的覆盖点,权威作为治理事件被记录。
政策 04
AR/MR/XR 治理
沉浸式叠加的空间注册、安全、年龄适合性。
政策 05
声学与感官治理
声音、光、运动、触觉,为包容和舒适进行感官塑形。
政策 06
商业与权益
访问、购买和解锁规则的执行,同时保留审计和同意。
政策 07
生命周期演化
版本管理、弃用、迁移——跨时间的章程连续性。
政策 08
安全权威时间表
已定义的安全权威层级和运行时优先级。
政策 09
安全与信任边界
跨每一层的加密、网络和运营边界。
政策 10
无障碍与包容
包容作为架构的结构属性,而非事后改造。
政策 11
同意与数据主权
同意作为持续运营条件;数据主权按设计。

WorldModel™ 替换什么,保留什么

该架构是为现实世界设计的。现有的 AV、表演控制、票务、内容、身份和运营系统通过模式和适配器集成到 WorldModel™ 操作系统中——它们继续运行,由上层治理。

保留什么

  • 现有的 AV、表演控制、灯光和音频子系统
  • 现有的 BMS、票务、预订和 POS 系统
  • 现有的内容管理、DAM 和 CMS 系统
  • 现有的 CRM、营销自动化和分析工具
  • 现有的身份提供商和 SSO 基础设施

替换什么——或使之不必要

  • 子系统之间的临时集成脚本
  • 跨供应商的手动政策执行
  • 单个子系统的隐式决策
  • 用于个性化的集中式个人数据湖
  • 无治理执行的单一目的 AI 附加组件

集成如何工作

集成通过 WorldModel™ 操作系统进行:模式、API 和适配器使现有系统能够表示并交换运营事实、意图、约束和候选行动。每个子系统在部署定义的模式下与操作系统接口集成。执行由价值体系、章程和认知治理层™控制。

继续。