Decision Rights · Cross-system Approval
工业决策权限控制
用同一套确定性政策，把补货、APS 重排和工程变更路由到不同权限路径，并留下可检查的责任与审计证据。
可运行演示确定性基础能力Deterministic正式签核
工业语境与系统边界
基础能力 · Decision Rights · Cross-system
规则、Solver 或代码产出核心结果
集成边界：跨域审批策略仿真；未连接 IAM、BPM / Workflow、ERP、APS、PLM 或电子签名系统，也不执行真实业务动作。
这个 BUILD 证明了什么
权限不是 AI 的输出：同一套确定性政策根据影响、可逆性与证据，把不同工业提案送到不同责任路径。
三个跨域模拟提案由同一个确定性 Decision Rights 引擎稳定路由到三条不同路径：低影响补货进入政策内授权，APS 重排进入 Production Planning Lead 角色批准，工程合规变更进入 Engineering Change Board 正式签核。每条结果都显示责任角色、执行权限、匹配规则、所需证据与审计轨迹；AI-assisted 来源不会改变权限判定。
系统能否根据影响、风险、可逆性、权限与证据，确定正确的决策路径，同时保持责任角色明确，并保证 AI 不能自行扩大执行权限？
决策权限 · 跨系统
同样叫“审批”，不同工业决策不应该走同一条路。
三个代表性模拟提案进入同一套确定性政策。系统只读取影响、可逆性、证据与阈值；AI 是否参与上游提案，不会改变权限。
固定模拟数据，不读取来源 Build 的实时会话状态。补货建议 · 常规低金额
为 SKU AX-40 创建 €2,400 模拟补货计划
- 金额影响
- €2,400
- 客户影响
- 有限
- 可逆性
- 可撤销
- 证据
- 3/3
APS 重排 · 3 号线停机
采用包含加班与订单重排的候选计划
- 金额影响
- €9,200
- 客户影响
- 重大
- 可逆性
- 有限可撤销
- 证据
- 3/3
工程变更 · VM-220 升温
把 120°C → 150°C 变更推进到正式 ECR / ECO
- 金额影响
- €21,600
- 客户影响
- 有限
- 可逆性
- 难以撤销
- 证据
- 4/4
让统一政策决定谁可以继续、谁必须批准、谁必须正式签核。
证据缺失或完整度不足时 fail closed，进入人工复核。
安全、合规或高风险影响直接升级正式签核。
超委托金额、重大客户影响或有限可逆动作需要角色批准。
低影响、可撤销、证据完整的动作才允许政策内继续。
决策边界
谁负责什么？
AI 参与边界：AI 不参与权限计算：AI 来源只写入审计轨迹，不能改变权限路径、阈值、责任角色或证据门。
AI / 确定性系统 / 人怎么分工
- 提案01业务系统 / AI / 人提出动作
上游可以来自 AI 建议、Solver 或人工，但来源身份不会提升权限。
- 代码02确定性政策计算权限路径
金额、安全、合规、客户影响、可逆性和证据门决定允许的路径与角色。
- 责任03指定角色承担批准或签核
低影响动作可落在委托政策内；更高影响动作必须升级到角色批准或正式签核。
- 证据04审计轨迹记录为什么这样路由
每一步保留输入、证据检查、风险计算、匹配规则和责任角色，便于复核。
证据深度
验证这个结论。
限制必须保持可见；实现细节可以深入查看，但不能阻塞 Demo 主流程。验证 2026-10-21 · 构建 6e89290 · 未测 2 项 / 阻塞 3 项展开全量记录
- 未测8 条路由 × 3 视口（1440×900 / 720×900 / 390×844）的横向溢出、Tab 焦点 outline、#evidence 深链、正文对比度抽样（仅记录数值，阈值未定）
- 未测对比度阈值判定：首轮只记录实测数值，WCAG 阈值待真实分布确认
- 阻塞读屏（screen reader）
原因：当前无读屏执行环境
- 阻塞原生 200% 浏览器缩放
原因：headless 视口不能替代原生缩放，需人工验证
- 阻塞视觉构图接受
原因：需人眼评审；当前会话无视觉模型能力
- 这是跨域权限政策仿真，不是企业 IAM、BPM / Workflow、ERP、APS、PLM 或电子签名系统集成。
- 三个提案是与现有 Build 对应的代表性静态 fixture，不读取那些 Build 的实时会话状态。
- 金额、风险分、角色与阈值用于验证 Decision Rights 模式，不代表任何真实企业授权矩阵或治理政策。
- 政策引擎只决定允许的决策路径；当前 Build 不执行真实采购、排程发布、ECR / ECO 或其他外部副作用。
- AI 不参与权限计算，也不能修改阈值、责任角色或证据门；证据不足时系统默认收紧权限。
实现方式
一个跨工业场景的 Decision Rights 实验。成熟 ERP、APS、PLM、Workflow 与 IAM 已经能承载审批、角色和权限；这个 Build 不重做这些系统。它只测试一层可复用决策控制：把影响、风险、可逆性、证据完整度与角色权限变成确定性政策输入，再决定动作属于政策内授权、人工复核、角色批准还是正式签核。纯 TypeScript 政策引擎读取 financial impact、safety / compliance impact、customer impact、reversibility、data completeness 与 evidence。规则按固定顺序执行证据门、正式签核阈值、角色批准阈值和委托政策阈值。proposal origin 只写入审计轨迹，不参与权限计算；因此 AI 可以在上游解释或提出方案，但不能通过“AI 建议”身份获得更高执行权限。页面使用三个与现有 Build 对应的静态代表性 fixture，不新增数据库或外部服务。
可复用模式
同一模式可以放在 AI 建议、Solver 结果或人工提案之后：先把业务结果转成结构化影响与证据，再由确定性 Decision Rights Policy 决定自动权限、复核、角色批准或正式签核。领域数据仍由各业务系统拥有。
证据与来源
- Demo交互式 Decision Rights Demo
同一政策引擎处理补货、APS 重排与工程变更三个代表性模拟提案，并展示责任角色与审计轨迹。
- 测试确定性权限政策测试
CI 已验证三个场景分别路由到政策内授权、角色批准与正式签核；AI 来源不会提升权限，证据缺失时系统 fail closed。
- 视觉证据Chrome 交互与响应式验收
GitHub CI 在本地构建产物上用 1440×1000 与 390×844 Chrome 验证主操作、三条权限路径、责任角色、可检查审计轨迹与无横向溢出。
- 源码