PRODUCT活跃

完整案例

Supply Chain Control Tower

把供应商、工厂、库存、订单和客户放进同一个网络状态；当多个扰动同时发生时，确定性传播影响、排序异常、比较恢复 Scenario，并把高影响动作停在人类授权之前。

核心问题供应链同时发生多个异常时，真正困难的不是把更多红灯放到 Dashboard，而是知道一个变化会沿哪些依赖传播、哪些客户或订单真正受到影响、多个异常应该先处理哪一个、局部恢复是否把风险转移到别处，以及高影响动作应该在哪里停止自动化。

进入 Control Tower ↓

工业系统语境Supply Chain Control Tower · Cross-system场景 · Control Tower · Cross-systemAI 增强现有系统工作Hybrid · AI + 确定性系统人工批准

系统 / 集成边界共享网络状态仿真；未连接 ERP、APS、SRM、MES、WMS、TMS 或企业事件总线。

供应链控制塔

从“哪里变红了”推进到“会影响谁、先处理什么、如何恢复”。

5事件类型

11网络节点

3恢复策略

01 · 网络态势

场景尚未运行；下方网络显示正常基线。

待分析的供应商更新（可修改）这段文本是待分析的场景输入；只有点击运行后才会进入影响计算。当前仅支持 Supplier B、MOTOR-A 和 1 / 3 / 7 天延误。

待分析的模拟工厂信号Plant B · Line 2 停机 8h模拟工厂结构化信号：Plant B 的 Line 2 主轴故障，预计停机 8 小时。该事件尚未应用到上方正常基线；运行分析后才参与影响计算。

01来源

Supplier A电子件

Supplier BMOTOR-A

Supplier C结构件

02制造

Plant A主装配工厂

Plant B柔性产能 · Line 2

03配送

DC East东区履约

DC West西区履约

04客户

客户 A2 个订单

客户 B2 个订单

客户 C2 个订单

客户 D2 个订单

EVALUATION · SYSTEM BOUNDARY

Control Tower 必须证明它会传播、排序、拒绝越权，而且同一输入可以重放。

Evaluation22/22PASS

当前 Fixture

并发异常进入同一网络状态

EXPECTEDSupplier Delay + Machine Breakdown 同时存在，且来源保持可追踪。

ACTUAL2 个 Root Event：supplier_delay + machine_breakdown

深入材料架构判断、证据与限制主流程已经结束；需要审查设计判断时再展开。

概览

问题 → 工作流 → 系统。

案例从真实运营问题开始，而不是从技术栈开始。

这是由原 Supply Chain Exception Command Center 演进而来的决策型 Control Tower Product。默认 Guided Scenario 同时注入 Supplier B 的 MOTOR-A 延期 3 天和 Plant B Line 2 停机 8 小时：AI 只把供应商非结构化更新转换成受限事件；工厂停机以明确标记的模拟结构化信号进入系统；共享 Network State 把事件传播到库存、排程、订单和客户；Exception Engine 使用可解释规则形成 P1–P4 队列；Recovery Engine 再比较 Cost First、Balanced、Service First 三种 What-if Scenario。原有 6 Scenario + 8 Failure 的 Exception Recovery 继续作为回归层，并新增 8 个 Control Tower 系统级 Fixture。

业务规则

系统必须遵守什么。

业务规则本身就是架构的一部分。

事件必须属于有界 Event Contract，并且实体必须存在于已知网络 / 主数据中；AI 不能自行创建 Supplier、Material、Plant、Order 或 Event Type。
Supplier Delay 可以从非结构化文本进入 AI Extract；Machine Breakdown 在当前 Guided Scenario 中来自明确标记的模拟结构化工厂信号。
Supplier → Plant → DC → Customer 的依赖关系由代码定义；AI 不推断企业网络，也不猜 downstream impact。
每个 Exception 必须保留 Root Event 和 Impact Trace Provenance，使用户能够从客户风险反向追到事件、库存或产能来源。
P1–P4 优先级由明确业务规则、Time to Impact 与受影响订单决定；系统不使用不可解释的 LLM Risk Score。
Recovery 只能从 Action Catalog 组合候选，并使用同一套成本、Residual Gap、Service、Late Orders、Overtime 与约束状态进行比较。
原 Exception Recovery Engine 继续拥有 MOQ / Order Multiple、Donor Buffer、Residual Gap 和 Forced Escalation 等 Hard Constraints。
所有高影响 Recovery Scenario 都要求 Human Approval；批准仅记录模拟授权，不重算网络状态或 KPI，也不向真实 ERP / APS / WMS / TMS 执行操作。
结果解释规则只能读取已经验证的结构化结果，不允许重算或改写任何 KPI、Priority、Entity 或 Action；AI 不负责生成解释。

产品决策

哪些判断真正改变了设计。

关键权衡保持可见，而不是被实现细节淹没。

不新建一个与 Exception Command Center 并列的重复 Product，而是把已有异常闭环升级为更上层的 Control Tower；原能力保留为 Recovery Engine 与回归证据。
第一条 Guided Scenario 使用 Supplier Delay + Machine Breakdown 双重扰动，让用户直接看到多个 Root Event 如何竞争同一个恢复窗口。
首屏使用 Supply Network + Exception Queue，不使用装饰性世界地图或 KPI 墙；视觉重点是“关系、传播、优先级”。
Event Contract 枚举 Supplier Delay、Demand Spike、Machine Breakdown、Transport Delay、Quality Hold 五类语义，但当前可执行 Guided Flow 只完整实现 Supplier Delay + Machine Breakdown；其他类型不被包装成已经完成的端到端流程。
Recovery 继续复用现有 Inventory、Scheduling 和 Exception Constraint Logic，不复制第二套供应链数学。
Factory Digital Twin 与 Supply Chain Agent Team 保持独立 Product：前者可以提供工厂状态类型的信号，后者只在跨职能目标冲突时有理由介入；当前 Control Tower 不伪装成已经完成跨 Product Runtime 集成。
不新增数据库、Queue、Event Bus、Microservices 或 Agent Framework；当前确定性状态模型已经足够验证核心产品假设。
Product 保持 active：核心双重扰动流程和系统级 Evaluation 已实现，但更广事件类型、真实企业系统集成和生产浏览器验收仍属于后续证据。

证据

验证这些结论。

每一项证据都应该支持 Product 的一个具体结论。

Demo
交互式 Supply Chain Control Tower
一个双重扰动场景完整走过 Network Situation、Impact Trace、Priority Queue、What-if Recovery 和 Human Decision。
架构
Shared Network State + Impact Provenance
Supplier / Plant / DC / Customer 使用同一网络模型；每个 Impact Trace 节点保留事件、库存、排程或规则来源。
评估
8 Control Tower + 14 Recovery Regression
新增 8 个系统级 Fixture，并继续运行原来的 6 个业务 Scenario + 8 个 Failure Fixture，验证升级没有绕过既有 Hard Constraints。
源码
实现源码
Next.js + TypeScript；复用既有 Inventory / Scheduling / Exception Recovery / AI Runtime，不新增数据库、Event Bus 或 Agent Framework。

限制

这个 Product 不声称什么。

成熟度只能建立在现有证据真正支持的范围内。

所有 Supplier、Plant、DC、Customer、订单、成本和 KPI 都是明确的模拟数据，不代表任何真实企业供应链或运营结果。
当前真正可执行的 Root Event 是 Supplier Delay 与 Machine Breakdown；Demand Spike、Transport Delay、Quality Hold 已进入有界 Event Contract，但尚未实现同等深度的端到端传播与恢复流程。
网络关系是小型预定义依赖图，不包含完整 BOM、多级供应网络、替代料、Allocation、Lane Capacity、税务或法规关系。
Machine Breakdown 使用 Scheduling Model 的 blockedUntil 重新排程；页面中的工厂信号是模拟的 Digital Twin-shaped event，不代表当前 Product 已与 Factory Digital Twin 页面建立运行时数据连接。
Recovery 成本与加班成本是场景参数，不是实时采购、承运商、财务或 HR 报价。
没有接入真实 ERP、APS、SRM、MES、WMS、TMS、事件总线或执行 API；没有跨会话运营状态、生产权限或企业审计链。
AI Runtime 不可用或输出未通过校验时会明确进入 deterministic fallback；核心 Network / Impact / Priority / Recovery 仍可继续运行。
8 个 Control Tower Fixture + 14 个 Recovery Regression Fixture 只证明当前代码在受控场景中的定义行为，不代表真实数据分布、企业 SLA、治理、安全或生产成熟度。