# operator-ub-sim 语义投影边界

> 盘点日期：2026-08-28
> 项目基线：`operator-ub-sim` 分支 `feat/operator-ub-sim-v0.1`，提交
> `612365a5ed9d8cd8d87f1deb30764a1b6dca1b25`
> CLT 基线：`third_party/collective-llvm-trace` gitlink
> `4945cf9270c0cbaeb65a6750602023c73eb6b5b8`
> 结论类型：当前代码、schema、fixture 和测试所支持的边界盘点，不是硬件准确性或性能声明。

## 摘要

本项目的主要有损语义投影发生在 `operator-ub-sim`，而不是 CLT 的全部提取阶段。
CLT 可以保留比 NS-3 网络请求更多的设备 action、同步、内存访问、队列证据和
依赖关系；项目只选择能够由当前 case 合同消费的部分，归一化为项目输入，再生成
NS-3-UB/STARS 能接受的 typed replay。

当前边界可以表示为：

```text
C220 CLT
  collective-trace.json + request-flow.json + core-executions.json
    -> normalize_extraction_directory()
    -> operator-ub-sim/projection-input/v1
    -> project_replay()
    -> collective-llvm-trace/ns3-stars-replay/v2
    -> ns-3-ub runner/resource setup

C310 CTP CLT
  authoritative-extraction/v2
    -> normalize_c310_ctp_extraction()
    -> operator-ub-sim/c310-ctp-projection-input/v2
    -> explicit CTP resource setup
    -> project_c310_ctp_replay()
    -> collective-llvm-trace/ns3-stars-replay/v2
    -> ns-3-ub runner/resource setup
```

因此，“项目支持某种 LLVM 映射”必须拆成两个问题：

1. CLT 是否从绑定的 device-side LLVM 中提取了足够的源语义和证据；
2. operator-ub-sim 是否把这些证据转换为当前 NS-3 输入契约中的动作、资源和完成条件。

第二个问题不通过默认值、数组位置、历史计数或高层算子名称猜测来补全第一步缺失的
事实。不能进入项目输入或 replay 的语义应保留为未投影，而不是伪装成零流量或已支持。

### 1.4 HCOMM 来源、CLT 提取与项目投影的三方边界

用户指定的 `~/workspace/hcomm` 在本次环境中不存在。实际可见的 HCOMM checkout 是
相对于 `~/workspace` 的 `cann_gitcode/hcomm`，基线为 `master` /
`19541b172be3f2c76692bcb9309a66d8f70365a3`，worktree clean。C310 device-side
模板来自相对于 `~/workspace` 的已安装 CANN `cann/cann-9.2.0/x86_64-linux/asc/`，而不是
HCOMM checkout；安装目录中的 stripped
`libhcomm.so`/`libhccl_v2.so` 只证明二进制存在，不提供 LLVM provenance。
HCOMM `build/` 文件中残留的 `~/workspace/hcomm` 仅是历史构建路径，不能作为当前源码
位置或 artifact provenance。

投影时应按下面的归属判断字段是否可以落入 NS-3 输入：

| 字段/语义 | HCOMM 源码能说明什么 | CLT extraction 必须提供什么 | operator-ub-sim 可以做的投影 | 明确丢失或禁止推导 |
| --- | --- | --- | --- | --- |
| `src`/`dst`/`len` 与 remote buffer | `include/hcomm_primitives.h` 和 `HcommWriteNbi.md` 定义本地源、远端目标及字节长度 | 绑定 artifact 中可解析的地址、region/owner、bytes 和 witness | C220 `URMA_WRITE` 或 C310 CTP transaction 保留 bytes/remote address | 不从 API 原型或 buffer 名称猜地址和长度 |
| CTP 协议与 endpoint | `include/hcomm_res_defs.h` 的 `COMM_PROTOCOL_UBC_CTP=4`；`endpoint.cc` 将 CTP device/host 映射到 URMA endpoint | channel、peer、endpoint/resource ABI 关联 | C310 resource setup 使用显式 CTP binding | 不把 CTP 枚举自动当作某个 LLVM 调用已经出现 |
| SQE/SGE 与 queue 资源 | `aiv_urma_channel.cc` 准备 entity slab、SQ/CQ context、queue index；C310 `hcomm_aiv_urma.h` 填充 SQE/SGE | WQE/SQE/SGE 字段、SQ publication、queue identity 和 witness | C220 保留可消费的 queue/request/evidence；C310 保留 transaction lineage | 不承诺 raw SQE/SGE bytes 的 bit-exact replay |
| doorbell/commit | C310 `PostSend` 更新 SQ head，并按 `commit` 写 SQ doorbell；`Commit` 单独提交 head | publication/doorbell action 及显式 program order | 生成 typed `UBDMA_DOORBELL`，绑定 case-owned Jetty | 不从 queue index 或 transaction 序号推导 Jetty/entity |
| completion/drain | `Drain` 读取 WQE count 后调用 `PollCq`；`PollCq` 校验 CQE owner/status 并更新 CQ/SQ tail | Drain、CQ poll、completion status 和 action lineage | C310 生成 `DRAIN`；C220 按 polling relation 生成 `NOTIFY_WAIT`/dependency | C220 contract 禁止补造 `DRAIN` |
| `ORDER_NO`、notify type、entity/priority | 不是 HCOMM LLVM 源语义的直接字段，或由运行时资源决定 | source evidence 若存在则可作为输入事实 | C220 `ORDER_NO`/`notify_type=0` 为项目默认；C310 entity/priority 来自 resource plan | 默认值不得反向证明上游源码或 CLT 映射成功 |

因此，HCOMM 源码是“源语义和实现路径”证据，CLT extraction 是“某个 LLVM artifact
实际出现并被识别”证据，projection input/replay 是“项目有意保留的有损结果”。三者
任意一层缺失，都不能把最终 NS-3 action 反推回完整 HCOMM 或 LLVM 语义。

## 1. 边界和职责

### 1.1 上游 CLT 负责什么

CLT 负责 LLVM 分析、绑定和执行证据的形成。对通用 C220 路径，输入是完整的
`collective-trace-ir/v1`、`request-flow/v1` 以及每个 core execution；对 C310 CTP
路径，输入是经过真实 artifact 校验的
`c310-ctp-authoritative-extraction/v2`。CLT 负责建立：

- action、通信请求、同步对象、显式 program-order/data/sync/completion edges；
- rank、core、launch、channel、地址、长度、队列和 completion 身份；
- LLVM 行号、调用、ABI、descriptor/SQE/SGE、doorbell、Drain、CQ 证据；
- extraction、artifact、profile 和资源绑定的 provenance。

CLT 也可能产生普通 local action、barrier、cache maintenance、queue evidence、
unknown action 和诊断。这些信息即使没有进入 NS-3 网络请求图，也不代表它们未被
提取。CLT 能提取什么的完整盘点见
[`clt-llvm-mapping-capabilities.md`](clt-llvm-mapping-capabilities.md)。

### 1.2 operator-ub-sim 负责什么

项目边界从“完整提取已存在且可验证”开始，负责四件事：

1. 校验 schema、身份、引用、证据和计数，拒绝不完整输入；
2. 生成稳定、项目所有的 projection input，固定归一化排序和来源 hash；
3. 根据 case 合同选择 replay 可消费的通信、通知、资源和 completion 形状；
4. 在交给 NS-3 前验证 replay/resource setup，并把 provenance 和 lineage 留在报告中。

项目不重新解释任意 LLVM，也不把 replay 当作原始 SQE、原始设备时间线或完整
`CollectiveTraceIR` 的替代品。

### 1.3 NS-3 边界

本报告追踪到以下 simulator-facing 输入：

- `collective-llvm-trace/ns3-stars-replay/v2`；
- `collective-llvm-trace/ns3-stars-resource-setup/v1`；
- C310 phase runner 使用的 lifecycle sidecar、runner result 和 final-gate counters。

NS-3 内部的 packet scheduling、链路时延、拥塞、队列实现和性能算法不在本报告范围。
项目可以声称 functional replay 的 accepted/completed/drained，但不能仅凭 projection
声称硬件周期精确、bit-exact SQE、通信性能或 FFN/fusion 行为。

## 2. C220 通用投影链路

### 2.1 归一化输入

`src/operator_ub_sim/projection_input.py` 的
`normalize_extraction_directory()` 固定从一个 extraction directory 读取：

| 文件 | 作用 |
| --- | --- |
| `collective-trace.json` | CLT `CollectiveTraceIR`、actions、sync、edges、通信请求和 invocation |
| `request-flow.json` | CLT 派生请求及 request dependencies |
| `core-executions.json` | 每个绑定 core 的 completed execution 覆盖 |

`normalize_extraction()` 不改变源 action 的语义，而是做跨文件 join 和 fail-closed
校验：

- trace/request-flow schema、`case_id`、`case_sha256` 必须一致；
- trace error diagnostics 会拒绝完整提取；
- core executions 必须全部存在且为 `completed`；
- action、core、edge、sync、request 和 dependency 引用必须闭合且唯一；
- 每个 `doorbell_write` 必须沿显式 program-order edge 可达一个 `urma_write`；
- trace communication request 与 request-flow request 必须逐字段一致；
- request 必须是由 `urma_write` action 支撑的 URMA write，并有 channel、peer、bytes；
- `gm_polling_flag` 的 producer/consumer 必须由显式 sync 或 remote-completion edge
  连接；
- launch tag 只能来自 extraction 中的 launch parameter/argument evidence；
- rank 集合必须覆盖 `0..rank_count-1`。

这条项目投影链路的当前入口边界是带 URMA doorbell/request 的 C220 extraction。CLT
可以独立提取 C220 LDST/data-move 并形成 `RequestFlowIR`，但没有对应 URMA request、
doorbell group 和 resource contract 的 LDST-only extraction 不会被本 projector 自动
转成 NS-3 replay；它应记录为“CLT 提取存在、仿真链路未投影”。

归一化结果使用 `operator-ub-sim/projection-input/v1`，保留以下项目消费所需的
结构：`source`、`collective_invocation`、`cores`、`channels`、`launch_tags`、
`actions`、`communication_requests`、`request_flow_requests`、依赖、同步、edges 和
稳定计数。数组按稳定 identity 排序，数组顺序本身不被当作执行语义；执行顺序只能
来自显式 extraction edges。

`source` 同时记录 trace/request-flow schema、case hash、文件 hash、artifact/profile
manifest，使 projection input 可以重建并审计其来源。它是项目边界文件，不是 CLT
原生 artifact。

### 2.2 doorbell group 与 WQE 选择

`src/operator_ub_sim/projection.py::project_replay()` 只沿显式 program-order reachability
建立一个 doorbell group。每组要求：

- source rank、core instance 和 queue index 唯一；
- group 中的每个 request action 只属于一个 doorbell；
- 每个 communication request 都必须归入且只归入一个 group；
- 请求之间必须能由显式 edges 完成确定性排序，存在并列或环会失败；
- 每个 replay action 都继承至少一条 source evidence。

projector 将 CLT 的请求关系投影为两种 STARS WQE：

| CLT 关系 | STARS 结果 | 投影含义 |
| --- | --- | --- |
| `urma_write`，没有跨 rank polling relation | `URMA_WRITE` | 保留 bytes、remote address、channel/Jetty 归属 |
| `urma_write -> notify_wait`，由 `gm_polling_flag` 和显式 edge 支撑 | `POST`，以及接收端 `NOTIFY_WAIT` | 将设备完成通知投影为 typed notification |

每个 doorbell 的输出是 `UBDMA_DOORBELL`，其中包含其 WQEs 和 `jetty_binding_id`。
接收端的通知 action 放在目标 rank 的 SQ 中，并保留 source rank、tag、sync object
和 evidence。项目不会把普通 local action、barrier、descriptor/cache action 或
queue-head action 直接变成 NS-3 网络 action；它们的作用只能通过被保留的 request、
sync 或 evidence 间接体现。

### 2.3 项目固定的有损政策

C220 replay 的 schema 与 validator 规定了以下项目政策：

- WQE `placement_order` 固定为 `ORDER_NO`，来源标为 `case-default`；
- `POST` 和 `NOTIFY_WAIT` 的 `notify_type` 固定为 `0`；
- notification tag 必须来自 producer 和 consumer 同一 launch tag evidence，冲突即拒绝；
- `URMA_WRITE` 必须有正 bytes、`remote_address` 和 evidence；目的 node/entity ID
  只有成对出现时才允许保留；
- endpoint rank 必须连续，SQE ID 在每个 SQ 内连续；
- C220 replay 不生成 `DRAIN`。`validate_replay_v2()` 对任何 DRAIN 明确失败；
- report 会记录 `drain_count: 0`、doorbell/WQE/wait 计数、defaults、rejected evidence
  和 claims。

这不是说 CLT 没有 completion 或 queue 语义，而是 C220 这条项目 replay 契约使用
polling wait 和 request dependency，不用一个额外的 DRAIN action 表示它们。典型
fixture 的形状是 `NOTIFY_WAIT`、`UBDMA_DOORBELL`、`URMA_WRITE`/`POST`，例如
`tests/test_projection.py` 和 `tests/test_c220_alltoall_urma_r4.py` 的计数与负向测试。

### 2.4 C220 资源绑定

`src/operator_ub_sim/resource_setup.py::build_resource_setup()` 根据归一化 extraction
的 authoritative channels 和 case-owned `jetty_numbers` 生成资源输入。Jetty number
必须由调用方显式提供，函数不会从 queue index、rank、数组位置或 channel suffix 推导。
每个 binding 需要 endpoint/channel/peer 闭合，且当前 C220 contract 固定：

```text
transport_mode = RTP
ctp_jetty_binding = BOUND
priority = 7
src_entity_id = 0
dest_entity_id = 0
```

`validate_resource_setup()` 会把 replay 中每个 doorbell 的
`jetty_binding_id` 与资源 binding 做 exact coverage 检查，并在提供 projection input
时再次校验 channel 的 peer。资源输入是独立于 replay 的 simulator setup，不是一个
隐藏在 runner 中的全局默认值。

## 3. C310 CTP 专用投影链路

### 3.1 authoritative extraction 到 project input

C310 CTP 不复用 C220 的 `CollectiveTraceIR` 投影函数。CLT 的
`c310-ctp-authoritative-extraction/v2` 记录的是绑定 CTP ABI/dataflow 的专用事实，
包括：

- rank/core execution 和 transaction program order；
- `COMM_PROTOCOL_UBC_CTP` channel、resource、SQ/CQ 身份和 peer；
- source/destination buffer 的 base、offset、size、实际地址和 bytes；
- WriteNbi 调用与参数关联；
- SQE/SGE 填充、SQ publication、doorbell 和 Drain evidence；
- CQ poll/completion、completion status；
- witness-scoped LLVM/ABI evidence。

`normalize_c310_ctp_extraction()` 只接受：

- 正确的 authoritative extraction schema；
- `simulation_ready: true` 且无 diagnostics；
- 合法的 artifact sha256；
- `fixture_mode: false`；
- 每个 execution 已完成、transaction count/doorbell/drain/completion counts 与实际
  executions 一致；
- buffer、channel、ABI association、request evidence 的身份、范围和 witness 前缀
  完整。

输出 `operator-ub-sim/c310-ctp-projection-input/v2`，其 source 记录 case、phase、
artifact hash 和 authoritative extraction hash。它保留每个 rank 的完整 transaction
列表，但不会把 CTP 事实改名为 C220 RTP 事实，也不会补造缺失的 CQ、Drain 或 WQE
证据。

### 3.2 C310 resource setup

`build_c310_ctp_resource_setup()` 要求一个 case-owned 的
`c310-ctp-resource-plan/v1`。resource plan 必须按 `(source_rank, channel_id)` 覆盖
所有 authoritative transactions，并精确匹配 resource ID、peer 和 phase identity。
随后物化为 `ns3-stars-resource-setup/v1`，当前 CTP binding 固定为：

```text
transport_mode = CTP
ctp_jetty_binding = BOUND
priority <= 7
1 <= src_entity_id, dest_entity_id <= 0xFFFFF
```

Jetty number、entity ID 和 priority 是显式资源计划事实；projector 不从 LLVM 数组
位置或 transaction 序号推导协议身份。重复 Jetty、缺少 channel、错误 peer、额外或
缺失 binding 都会在 materialization/validation 阶段失败。

### 3.3 typed replay

`project_c310_ctp_replay()` 对每个 authoritative transaction 生成固定的两个 typed
动作：

```text
UBDMA_DOORBELL
  -> exactly one URMA_WRITE WQE
  -> DRAIN
```

其中：

- `URMA_WRITE` 保留 transaction bytes 和 destination address，`placement_order` 固定
  为 `ORDER_NO`；
- doorbell 的 `jetty_binding_id` 使用 extraction channel identity；
- `DRAIN` 通过 `through_action_id` 锚定到同一 transaction 的 doorbell；
- `source_sequence` 由 extraction transaction order 形成 doorbell/Drain 的局部顺序；
- doorbell、WQE、Drain 的 evidence 是从 invocation、WriteNbi、channel、SQE/SGE、
  publication、doorbell、Drain、buffer、CQ completion 等证据集合并而来；
- replay 的 `case_sha256` 指向 authoritative extraction hash，而不是另一个匿名 fixture。

C310 的 report 明确记载 doorbell、Drain、endpoint、SQ 和 URMA write 计数，并声明
“semantic projected; STARS does not replay raw SQE bytes”。validator 会反向检查每个
transaction 的 action IDs、bytes、remote address、channel、SQE 顺序和 evidence 子集，
防止投影阶段删除 ABI 或 invocation lineage。

### 3.4 C310 phase workflow 和 NS-3 消费

`src/operator_ub_sim/c310_phase.py` 将一次 C310 Dispatch 或 Combine phase 固定为一条
完整链路：layout/binding/resource plan -> CLT extraction -> normalized projection input
-> resource setup -> typed replay -> NS-3 runner -> lifecycle/final gate。runner 还会
捕获 CLT 与 NS-3 consumer 的 commit/module hash，要求被消费的 checkout 没有 tracked
修改。

phase final gate 检查：

- normalized extraction 与 stored projection input 完全相等；
- replay/resource setup 与 phase layout、rank、transaction、channel 和 buffer facts
  一致；
- runner 的 accepted/completed/failed/post/doorbell/WQE/URMA write/Drain counters 与
  phase contract 一致；
- lifecycle sidecar 对每个 doorbell 和 Drain 都有唯一成功的 terminal event，且 Drain
  terminal 不早于其锚定 doorbell；
- functional replay 成功，但 FFN、fusion、overlap、performance、hardware accuracy、
  bit-exact SQE 和 MC2 provenance 仍为明确的 claim boundary。

## 4. 两条路径的差异

| 项目 | C220 通用路径 | C310 CTP 路径 |
| --- | --- | --- |
| 输入 schema | trace/request-flow/core-executions | authoritative CTP extraction |
| 项目 input | `projection-input/v1` | `c310-ctp-projection-input/v2` |
| 主要 join | action、request-flow、program-order、polling sync | transaction、channel、ABI witness、CQ completion |
| replay | `UBDMA_DOORBELL`、`NOTIFY_WAIT`；WQE 为 `URMA_WRITE` 或 `POST` | 每个 transaction 的 `UBDMA_DOORBELL` + 一个 `URMA_WRITE` + `DRAIN` |
| 默认值 | `ORDER_NO`、`notify_type=0` | `ORDER_NO`；无 C220 POST/notify 默认 |
| 资源 transport | `RTP`，entity `0/0` | `CTP`，显式非零 entity，priority 受限 |
| completion 表达 | polling relation 和 request dependency；不生成 DRAIN | CTP Drain 和 CQ completion 均是 authoritative/typed lineage |
| 主要验证 | C220 projection/validator、resource coverage、fixture counts | CTP schema/ABI/buffer validation、resource plan、replay lineage、phase final gate |

不能把两列合并为“统一的 URMA 映射”：C220 recognizer 的证据和 C310 CTP 的
WriteNbi/SQE/SGE/CQ 证据属于不同 ABI/protocol path；它们的 replay policy 也不同。

## 5. 有损语义清单

以下信息可能在项目投影后不可见，或只以较粗粒度形式存在：

| 上游信息 | 投影后的状态 | 说明 |
| --- | --- | --- |
| LLVM CFG、SSA、每条指令和具体执行路径 | 不进入 replay；部分 identity/evidence 被保留 | replay 是动作队列，不是 LLVM interpreter trace |
| local load/store/reduce、barrier、cache maintenance、queue-head 更新 | 通常不生成 NS-3 action | 只有它们支撑的 request/sync/order/evidence 会间接保留 |
| 多个 descriptor/SQE/SGE 写入的字段级布局 | C220 只保留可消费的 bytes/address/peer；C310 保留语义事实和 evidence，不保留 raw bytes | 项目不声称 bit-exact SQE replay |
| request-flow 的完整依赖图 | C220 作为 normalized audit input 保留；当前 projector 主要用 source program-order edges 和 polling sync 做 group/order/notification | 不等于设备逐周期时间线 |
| C220 completion queue 或协议内部细节 | 用 `POST`/`NOTIFY_WAIT` 或 request dependency 表示 | 不生成 C220 DRAIN |
| C310 CTP 的 CQ completion | 作为 Drain/action lineage 和 phase gate 证据保留 | NS-3 仍执行 typed action，而非原始 CQE |
| 高层 AllToAll、MoE、token routing、专家计算 | 只有 case/source binding 明确声明时才进入 phase contract | LLVM mapping 和 operator semantics 不自动等价 |
| 未解析 peer、地址、tag、channel、ABI 或 witness | 拒绝投影 | 不用 rank、数组位置、默认地址或名称猜测 |

所以“有损”表示目标输入有意减少信息，不表示可以无证据补齐信息。成功的语义投影
必须同时能回答：保留了哪一个源事实、丢弃了哪些细节、丢弃是否被当前 simulator
contract 允许。

## 6. 负向空间和 fail-closed 边界

### C220

- trace/request-flow schema、case hash 或 profile identity 不一致：拒绝；
- extraction 有 error diagnostic、core execution 未完成或覆盖不全：拒绝；
- action/request/sync/edge 引用悬空、重复或无法闭合：拒绝；
- doorbell 没有显式 program-order 路径到 URMA request：拒绝；
- request-flow 与 trace 在 request ID、bytes、peer、channel、address 等字段冲突：拒绝；
- polling sync 不是唯一的跨 rank `urma_write -> notify_wait`：拒绝；
- 缺少 launch tag、remote address、queue identity 或 channel：拒绝；
- request 不能唯一归属 doorbell，或请求之间存在 ordering ambiguity：拒绝；
- replay 含 `DRAIN`、未知 action/WQE、缺失 evidence、非 `ORDER_NO` 或非零 notify type：拒绝。

### C310 CTP

- fixture extraction (`fixture_mode=true`) 或非 simulation-ready extraction：拒绝；
- 缺少 WriteNbi、channel、SQE/SGE、SQ publication、doorbell、Drain、CQ completion、
  buffer 或 ABI witness evidence：在 normalization 前拒绝；
- transaction count、rank coverage、completion status、buffer range 或 order 不一致：拒绝；
- resource plan 与 extraction 的 phase/channel/resource/peer 不一致：拒绝；
- resource setup 缺少 active channel、重复 Jetty 或非法 entity/priority：拒绝；
- replay 删除 ABI/invocation evidence，或改变 bytes/address/channel/action identity：拒绝；
- lifecycle 没有每个 doorbell/Drain 的唯一成功 terminal event：final gate 拒绝。

这些失败不是“映射成 unknown request”。原因在于项目输出一旦交给 NS-3，就会成为
仿真输入；在来源证据不足时生成近似请求会破坏 provenance 和统计口径。

## 7. 完整度和验证口径

本项目不输出脱离 case、schema 和阶段合同的单一“总映射数”。应分别记录：

- `CLT 提取完整度`：源语义是否进入 CLT 目标 IR/authoritative extraction；
- `仿真链路完整度`：这些语义是否经过项目 input、resource setup 和 replay validator，
  到达 NS-3 输入；
- 实现状态：`完整映射`、`部分映射`、`仅声明/不可达`、`未发现`；
- 验证等级：`实际运行`、`测试/fixture`、`静态代码追踪`、`无法验证`。

例如：

| 语义 | CLT 提取完整度 | 仿真链路完整度 | 当前验证 |
| --- | --- | --- | --- |
| C220 HCOMM URMA request + polling relation | 在绑定 ABI/证据完整时完整 | C220 replay/resource setup 可完整消费 | fixture/unit；真实 artifact 依赖外部环境 |
| C220 local/barrier/cache/queue action | CLT 可完整保留 | 通常不进入 NS-3 replay，仅作为 evidence/dependency | fixture/unit |
| C310 CTP WriteNbi + CQ-backed Drain | authoritative extraction 完整时完整 | C310 typed replay、resource setup、phase gate 可消费 | fixture/unit；生产 artifact 需真实 `.bc` |
| OPS-specific LLVM mapping | 当前未发现可定位 CLT catalog/artifact/provenance | 无项目投影链路 | 无法验证 |
| 高层 MoE routing/专家计算 | 不是 LLVM mapping 自动结果 | 只由 case semantic contract/oracle 处理 | 静态 case/source evidence |

## 8. 证据索引

项目投影边界的主要实现证据：

- C220 normalization：`src/operator_ub_sim/projection_input.py` 的
  `normalize_extraction()`、`normalize_extraction_directory()`；
- C220 projection：`src/operator_ub_sim/projection.py` 的
  `project_replay()`、`validate_replay_v2()`；
- C220 resources：`src/operator_ub_sim/resource_setup.py` 的
  `build_resource_setup()`、`validate_resource_setup()`；
- C310 normalization/resource/replay：`src/operator_ub_sim/c310_ctp.py` 的
  `normalize_c310_ctp_extraction()`、`build_c310_ctp_resource_setup()`、
  `project_c310_ctp_replay()`、`validate_c310_ctp_replay()`；
- C310 phase lineage：`src/operator_ub_sim/c310_phase.py` 的 phase projection input、
  lifecycle 和 final-gate 校验；
- C220 projection contract：`tests/test_projection.py`、
  `tests/test_c220_alltoall_urma_r4.py`；
- C310 CTP contract：`tests/test_c310_ctp_gate0.py`、`tests/test_c310_moe.py`；
- C310 acceptance/runner contract：`tests/test_c310_acceptance.py` 及对应
  `c310_acceptance.py`/`c310_roundtrip.py`。
- HCOMM API/协议来源（相对于 HCOMM checkout）：`include/hcomm_primitives.h`、
  `include/hcomm_res_defs.h`、`docs/zh/api_ref/comm_opdev/datatype_definition/CommProtocol.md`、
  `docs/zh/api_ref/comm_opdev/data_plane_api/cpu-cpu_ts-aicpu_ts/communication_operations/HcommWriteNbi.md`、
  `docs/zh/api_ref/comm_opdev/data_plane_api/cpu-cpu_ts-aicpu_ts/communication_operations/HcommChannelDrainOnThread.md`；
- HCOMM CTP/device resource 来源（相对于 HCOMM checkout）：
  `src/base_comm/resources/endpoints/endpoint.cc`、
  `src/base_comm/resources/endpoint_pairs/channels/aiv/aiv_urma_channel.cc`、
  `src/legacy/ascend950/unified_platform/resource/connection/dev_ub_connection.cc`、
  `src/legacy/ascend950/unified_platform/external_system/orion_adapter_hccp.cc`、
  `src/legacy/ascend950/unified_platform/resource/transport/aicpu/ub_transport_lite_impl.cc`；
- HCOMM C310 device-side 模板（相对于已安装 CANN `asc/` 根目录）：
  `include/adv_api/hcomm/hcomm.h`、
  `impl/adv_api/detail/hcomm/impl/platform_v310/hcomm_aiv_urma_def.h`、
  `impl/adv_api/detail/hcomm/impl/platform_v310/hcomm_aiv_urma.h`。

这些测试覆盖的是 schema、join、lineage、计数和 fail-closed contract。它们不替代真实
C220/C310 device artifact 的重新提取，也不替代 NS-3 内部算法或硬件一致性验证。

## 9. 结论

在当前基线下，合理的系统描述是：

> CLT 从绑定的 device-side LLVM 中收集和提取较丰富的执行、通信和证据语义；
> operator-ub-sim 对这些证据做项目归一化和有损语义投影，只把 case 合同允许的
> request、notification、resource、completion 和 lineage 转成 NS-3 typed replay。

因此，`operator-ub-sim` 的投影边界是语义保真与仿真可消费性之间的明确接口，而不是
把所有 LLVM 语义压缩成一个无来源的网络流量文件。任何新增 HCOMM/HCCL/OPS 映射都
应分别补齐 CLT 提取证据、项目 projection policy、resource/replay schema、lineage
校验和对应验证等级，不能只增加一个高层算子名称或一条历史计数。