用例：上传购物小票到个人 Vault

版本：v1.0（草案） 状态：草案 权威性：说明性

场景

用户将一张购物小票图片上传到自己的个人 Vault，并请求系统将其解析为结构化消费数据。

本文档是说明性用例，用来展示新修订后的 SCP 与 SCS 规范如何映射到一个具体的终端用户流程。

本文档中使用的 canonical protocol term 以 SCP 协议概览 和 SCP 核心规范 为准。

为什么这个用例重要

这个场景虽然简单，但几乎覆盖了新版 Symphony 体系里最关键的几条边界：

1. 数据首先进入本地 Vault 边界
2. 只有在任务被授权接纳后，协议流程才真正开始
3. 执行之前必须先完成语义解析
4. 小票明文必须始终留在授权数据边界内
5. 只有被接受并完成结算的结果，才会成为协议可见事实

因此，这个小票上传用例很适合用来区分“本地存储事件”、“协议认可的工作流程”以及“下游 accounting 后果”三者之间的关系。

入口区分

这个场景有两层：

1. 纯粹把文件上传到 Vault 存储
2. 上传后同时触发协议任务去解析小票

这里描述的是第二种，也就是上传动作同时触发一个解释小票的任务。

这一区分非常重要。把文件上传到个人 Vault，本质上首先是一个本地系统事件；只有当系统把它转化成一个被授权接纳的协议任务时，它才进入 SCP 生命周期。

协议视角

从协议角度看，这个场景的核心，是把一份私有小票逐步转化为协议认可的工作，并在结果被接受后，进一步转化为可结算的协议事实。

1. Vault 接入与本地托管

用户把小票图片上传到自己的个人 Vault。

在这一步：

1. 原始图片仍然是本地私有数据
2. 小票内容仍然处于 Vault 隐私边界内
3. 此时还没有 reward、settlement 或协议事实可言

这一步体现的是“个人数据托管”，还不是完整的协议工作。

2. 任务接纳与授权

如果用户请求系统解析这张小票，那么这个请求必须先被接纳为授权的协议工作。

从高层看，这一步要明确的是：

1. 谁发起了这项工作
2. 该调用者是否有权使用这张小票内容
3. 想要执行的工作是什么
4. 任务应在什么语义与策略上下文中执行

只有在这一步之后，小票解析请求才会变成协议认可的工作。

3. 在 domain 与版本上下文中完成语义解析

在执行之前，协议必须先确定这些字段在当前语义上下文里到底代表什么。

在这个场景里，通常需要先确定合适的 expense 或 personal finance domain，并把小票字段解析到当前有效的 canonical attribute 上，例如：

1. merchant
2. transaction date
3. total amount
4. currency
5. tax
6. payment method
7. line items

这一步之所以重要，是因为修订后的 SCP 不允许执行阶段悄悄“发明含义”。所有工作都必须在当前 semantic_version 和对应 domain 规则下被解释。

4. 受保护数据访问与执行

当语义被确定之后，系统才可以开始执行被授权的计算。

在这个例子里，执行过程通常包括：

1. 对小票图片做 OCR
2. 提取商户名和日期
3. 归一化金额
4. 结构化字段
5. 将字段映射成面向 expense 的记录

在整个阶段中：

1. 小票明文必须始终留在授权 Vault 或 TEE 边界内
2. 协议依赖的是记录关联、commitment、evidence 和执行工件，而不是任意移动明文
3. 执行始终绑定于已接纳的授权上下文和语义上下文

5. 验证与被接受结果的形成

协议不会把执行输出自动视为最终事实。

相反，执行结果还必须经过正确性与完整性验证。高层上看，结果可能是：

1. accepted
2. rejected
3. challenged

只有被接受的工作，才可能继续进入 settlement。

6. 结算、记账与可选的下游后果

如果结果被接受，它就可以进入 settlement，并进一步沉淀为 finalized protocol accounting 的一部分。

在这个用例里：

1. settlement 的作用是把已接受的工作转化为协议认可的事实
2. reward accounting 是否发生，取决于这条流程是否属于带激励的网络路径
3. 任何 payout 后果都位于 finalized accounting 之后的下游，而不是由它来定义协议事实

对于个人小票解析请求来说，最常见的结果是用户拿到可信的结构化消费记录，而不是直接获得协议奖励。

系统视角

从 SCS 角度看，同一个场景是由一组协作的运行时模块共同实现的。

1. 准入接口面

面向客户端的 admission 服务接收这个由上传触发的请求，校验身份与授权，并把可接纳的工作封装成系统可处理的任务。

2. 协调与生命周期控制

协调服务负责把请求从 admission 推进到 semantic resolution、execution、verification 与 settlement，同时保持整个过程可审计、可追踪。

3. 语义命名空间与注册表服务

语义服务负责判断适用的 domain，把小票字段解析到当前 active canonical attribute 上，并保持与 semantic_version 的兼容性。

4. Vault 与受保护数据服务

Vault 侧的存储和带授权的数据访问机制，负责在保持原始小票私密性的同时，只向计算过程暴露被允许的记录材料。

5. 执行运行时

执行 worker 在受保护运行时内完成小票解析工作，并产出可 replay 的 transcript 或结果工件。

6. 验证与质疑服务

验证服务检查结果、保留可 replay 的 evidence，并发布 accepted、rejected 或 challenged 的系统结论。

7. 结算与下游记账

settlement 服务负责组装 finalized accounting context。如果这个流程属于带奖励或支付的路径，下游系统会在不改写协议 finality 的前提下，继续准备 reward 或 payout 后果。

这个场景中的语义演化

小票解析也是一个很好的例子，可以说明修订后协议中的语义增长是如何发生的。

如果小票里出现的字段或标签，无法被当前 canonical set 直接解释：

1. 它可能保持 unresolved，并要求更严格的处理
2. 它也可能在策略允许的前提下，继续作为 Vault 内部的本地语义存在
3. 它之后还可能演化为一个隐私安全的 LocalAttributeCandidate

因此，这个用例会自然触及：

1. domain
2. CanonicalAttribute
3. Vault 内部的 local attribute handling
4. 在治理规则下进行的 candidate 演化

关键在于，语义上的新内容可以先存在，但不会自动变成共享的协议事实。

关键边界提醒

单纯把小票图片上传到 Vault，并不自动等于一个完整的协议事件。

只有当系统把这个上传对象转化成一项被授权接纳的协议工作，并要求它经历语义解析、执行、验证和结算时，完整的 SCP 生命周期才会真正开始。

同样地，最终得到的结构化消费记录，也不是因为系统跑过一次 OCR 或解析流程就自动成为协议事实；只有在结果被接受并完成结算后，它才具有协议认可的地位。