从哪来 · 为什么 · 怎么做
玖衍 Q5/Q7/Q8 围绕「对象怎么统一」。本节把 fusedId 与 DB3K 写成可联调的映射契约，并指向 本体论专题页 的 MVL 细节。
多系统 ID Mismatch
典型失败场景：KYQB 开源情报标注的目标编号、MDW ACMI 流的 entity ID、Brain COP 上的图标、Command ORBAT 里的 Unit GUID——四套标识各说各话。参谋 LLM 若基于错误 ID 生成 atomic_task，WPF 写口会在 Command 侧实例化失败，或更糟——实例化到错误平台。
这不是集成 bug，是缺少运行时融合主键的架构债。OpenNexus 引入 fusedId 作为跨子系统 SSOT。
SSOT = DB3K + fusedId + registry
DB3K505 提供装备语义锚（平台 DBID、性能、挂载）；fusedId 提供运行时目标实例主键；mapping-registry 记录各子系统 local ID → fusedId 的映射策略与 authority 优先级。
未 db:* commit / strikeReady=false 的目标，PromptOps 与杀伤链预检双端禁打——本体层直接决定打击能不能放行。
Authority 层级与数据规模
映射 authority 自高到低：Command（仿真实例）→ ZBSJ（装备库）→ Brain（融合裁决）→ Gradio（参谋输入）→ JUDGE（BDA 回写）。冲突时高 authority 覆盖低 authority。
数据规模：DB3K505 派生库约 16900 平台条目、32335 loadout 组合——PromptOps whitelist 与 Mission 实例化均以此为边界。
ID 映射流 · KYQB → Brain → Command
联调时指着 Brain 融合层讲：所有 local_id 必须 resolve 到 fusedId 才能进入参谋与杀伤链；Command 侧再 resolve 到 DBID 实例化。详见 /ontology.html。
映射策略与 strikeReady Gate
fusedId 的生成与 commit
Brain BFF 收到多源观测后，按 mapping-registry 规则尝试 merge：若 KYQB 坐标与 ACMI track 在空间/时间窗口内匹配，则分配或继承已有 fusedId。train 模式允许 mapMode=demo 使用 stub 映射快速演示；live 模式要求 db:* commit——即映射结果必须写回 registry 并标记 strikeReady=true 才允许进入 KC Step③ 打击生成。
Authority 冲突裁决
当 ZBSJ 装备库标注的 DBID 与 Command 仿真实例不一致时，Command authority 优先——仿真是 ground truth。Gradio 参谋引用的平台型号若与 fusedId 绑定的 DBID 不符，PromptOps L1 whitelist 拦截。JUDGE BDA 回写则可更新 fusedId 的毁伤状态，但不改变 DBID 绑定。
DB3K505 规模与 PromptOps 边界
约 16900 平台条目与 32335 loadout 组合构成 PromptOps 的硬边界——LLM 输出的 platform_dbid 必须在此集合内。ZBSJ（zbsj.opennexus.fun）提供人工查阅与编辑界面，与 Command InternalDBViewer 语义对齐。任何「库里没有的型号」在 enter Mission 之前即被 Gate 拒绝。
与本体论专题页的关系
本页讲「为什么与怎么咬合」；/ontology.html 提供 MVL 契约、映射 JSON schema 与 verify 用例。联调时两页对照阅读：深读页建立直觉，本体论页查字段级定义。