Kun

技术洞察 ·

平时不盯表，扯皮时拿证据：Dummy 如何留下可核验的联调记录

这套记录不是每天都要打开的监控表。平时让接入团队专注生产；只有生产表现与供应商说法冲突时，才按需查询服务端记录，把争议缩小到具体会话、操作和小时。

01 · 不是日常看板

证据平时保持安静，出现矛盾时再用

供应商完成 Guide → Playground → Dummy 后，双方通常应该继续推进生产接入，不必安排人员逐条审阅 Dummy 记录，也不把它做成每日汇报。服务端证据的价值在于留下一条独立于截图和回忆的线索，在真实结果相互矛盾时可按供应商、会话、操作和完整 UTC 小时查询。

这让负责人先问一个具体问题：“生产现场声称执行的那次操作，服务端在什么时间、以什么结果收到？”问题足够具体，后续才知道该向哪一方要下一份材料。

02 · 一次生产争议

演练走完了，生产命令却复现不了

设想一家获准供应商已经依次完成 Guide、Playground 和 Dummy，并声称同样的文档命令已接入生产。上线后，IMS/MES 一直拿不到预期结果；供应商说请求已经成功发出，工厂团队却无法用其生产配置复现。

此时不先争论截图真假，也不要求供应商每天提交记录。负责人先锁定供应商、所用会话、Store / Predict / Remove 操作和争议发生的完整 UTC 小时，再查询服务端活动：同一会话是否出现相关操作，生命周期先后是否一致，结果是成功、拒绝还是根本没有可归因事件。

03 · 收件与归因

服务端收到了什么，凭据属于哪个会话

服务端 receipt time 是服务端接收时间，不是客户端按下发送的时间。每条记录带有内部请求标识、供应商与会话标识、操作、结果，以及诊断所需的有界运行元数据。凭据摘要能把到达应用的请求映射到已知的有效、过期或已撤销供应商会话；随机凭据和到达应用前就被拦截的请求不属于可归因事件。

这种归因只说明分配给某个 supplier session 的凭据参与了服务端活动，不识别实际使用凭据的人员、进程或主机。它也不把服务端接收时间冒充客户端发送时间，更不能用零事件小时证明客户端没有尝试或网络中没有流量。

记录遵循隐私最小化：仅为争议处理，不保留 raw body、原始 credentials、barcode、feature、IP 地址或 User-Agent。Dummy 仍只适合脱敏、可丢弃的测试数据。

04 · 从请求到锚定

一条记录怎样变成各方都能核验的小时文件

证据链：从 Dummy 收件到第三方锁定与独立副本
  1. Dummy receipt以服务端接收时间和内部请求标识记录到达应用的操作与结果。
  2. 可归因事件凭据摘要映射到已知供应商会话，形成可按会话查询的服务端活动。
  3. 小时 canonical JSON完整且非空的 UTC 小时被序列化为字段顺序确定的一组精确字节。
  4. Sigstore / Rekorbundle 与透明日志 inclusion 公开锚定这组字节的摘要和存在时间。
  5. B2 锁定与独立副本锁定已上传版本；供应商和利益相关方分别验证并保存同一组文件。

每一层都保留上一层的讨论对象：事件先归到会话，完整小时再固定成 canonical JSON，Sigstore 与 Rekor 锚定精确字节，B2 锁定已上传版本，各方的独立副本则避免把后续复核押在单一公开入口上。

05 · 小时证据

锚定完成后，改写一定会留下矛盾

对已经完成小时锚定的记录，任何人都不能在不留下可核验不一致的情况下删除或改写。

这项结论只覆盖已经完成且非空的 UTC 小时和对已知供应商会话的归因；它不承诺锚定前的普遍完整性，也不识别使用凭据的人员、进程或主机。

原因很直接：canonical JSON 的摘要已经进入 Sigstore bundle 与 Rekor 透明日志；B2 Compliance Object Lock 把已上传文件版本锁定 365 天；各方还能保存自己验证过的副本。后来少一条、多一条或改一个结果，字节和摘要都会变化，无法同时与公开锚定、锁定版本和独立副本保持一致。B2 的锁定由第三方平台执行，但平台不是独立保管方，因此参与方仍要留存副本。验证机制可参考官方 Sigstore blob verification 文档与 Backblaze Object Lock 文档。

06 · 争议处理

先核对服务端事实，再分配下一步举证

争议流程：从生产矛盾到下一份证据
  1. 发现生产矛盾生产结果与供应商声称完成的文档命令不一致。
  2. 查询供应商 / 会话 / 小时限定身份、操作和完整 UTC 小时，不做无边界搜索。
  3. 比较生命周期核对 Store → Predict → Remove 的先后、结果与凭据状态。
  4. 验证已锚定小时下载同一小时的 JSON 和 bundle，核对签名、透明日志与独立副本。
  5. 分配下一步举证按服务端结果要求责任方补充客户端、网络或服务端处理材料，直到差异可解释。

例如，同一供应商会话出现 Store 和 Remove，却没有可归因的 Predict，服务端只能确认未观察到匹配事件，不能反推客户端从未尝试。下一份证据应由供应商提供精确客户端时间、所用会话、CLI 输出和请求离开其控制边界的网络材料；若服务端记录显示已接收但处理结果异常，则由 KUN 团队沿内部请求标识解释服务端结果。

07 · 精确验证

下载同一小时的两个文件，验证后各自保存

技术人员先选择一个已经完成且非空的 UTC 小时。下面两个地址的年月日和小时必须完全一致，分别下载 canonical JSON 与对应的 Sigstore bundle：

https://evidence.kun-dummy.bigdick.live/v1/hour/YYYY/MM/DD/HH/evidence.json
https://evidence.kun-dummy.bigdick.live/v1/hour/YYYY/MM/DD/HH/evidence.sigstore.json

凭据持有者在自己的环境中计算 digest；printf 不添加换行。只比较摘要，不共享原始 token：

printf '%s' "$KUN_BEARER_TOKEN" | sha256sum

使用固定 GitHub OIDC workflow identity 和 issuer 验证同一小时的精确 JSON：

cosign verify-blob evidence.json \
  --bundle evidence.sigstore.json \
  --certificate-identity \
  'https://github.com/sctmes/kun/.github/workflows/anchor-dummy-evidence.yml@refs/heads/main' \
  --certificate-oidc-issuer \
  'https://token.actions.githubusercontent.com'

命令通过后，核对 JSON 中的供应商、会话摘要、操作、结果、服务端接收时间与争议范围，并确认 bundle 含 Rekor inclusion。供应商和利益相关方分别下载、验证并保存 JSON、bundle、文件摘要和命令结论；公开入口是分发渠道，不是唯一保管方。