用例：面向消费者行为的隐私保护模型训练

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

场景

某个模型运营方希望利用分布在多个 Vault 中、受保护的小票与消费历史数据，训练一个面向消费者行为的模型。

模型目标可能包括：

1. 购买倾向预测
2. 品类或品牌偏好估计
3. 优惠券响应建模
4. 隐私保护用户分群

本文档是说明性用例，用来展示修订后的 SCP 与 SCS 规范如何映射到一个在不暴露原始消费明文的前提下进行模型训练的工作流。

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

为什么这个用例重要

这个场景很有代表性，因为它同时体现了新版 Symphony 体系中的几条关键性质：

1. model training intent 与 protocol-recognized training work 不是同一件事
2. 受保护的源记录可以持续保留在授权 Vault 或 TEE 边界内
3. 训练过程可以依赖派生 feature、query projection 或受保护计算，而不是任意导出原始记录
4. model artifact 与 evaluation result 必须关联到可 replay 的 evidence 与版本上下文
5. 最终模型是受治理训练结果的下游产物，而不是协议真相的替代物

入口区分

这个场景也有两层：

1. 业务侧或研究侧想训练一个模型
2. 带有明确 policy、semantic 与 privacy 约束的协议认可训练任务

“利用消费数据训练一个行为模型”本身还不是协议事件；只有当系统把它接纳为一项带有明确 feature scope、版本上下文和隐私执行规则的授权训练任务时，它才进入 SCP 生命周期。

协议视角

从协议角度看，这个场景的核心，是把训练意图转化为一个可验证、可治理的模型训练结果。

1. 训练意图与范围定义

请求方先定义训练目标和约束，例如：

1. 目标预测或分群任务
2. 适用的用户或市场范围
3. 允许使用的 feature family
4. 模型输出类型
5. evaluation threshold 或 acceptance criterion

在这一步，它仍然只是业务或研究意图，而不是协议事实。

2. 任务接纳与约束绑定

系统把这个请求转化为授权的协议工作。

从高层看，admission 需要明确：

1. 谁被授权提交该训练任务
2. 哪些 record domain、feature family 或 query projection 可以参与
3. 适用哪些 privacy、policy 与版本约束
4. 什么样的输出才算协议要评估的训练结果

只有经过这一步，训练流程才成为协议认可的工作。

3. 训练语义的解析

在训练开始之前，协议必须先在当前上下文中解析这项任务的语义含义。

这通常包括确定：

1. 哪些 domain 定义了受保护的源记录
2. 哪些 canonical attribute 或查询属性可用于 feature construction
3. 哪些 local-only signal 必须继续保持私有
4. 该次运行受哪个 semantic_version 与 policy_version 约束

这一步之所以重要，是因为修订后的 SCP 要求在受保护计算开始之前，先建立共享且可治理的语义解释。

4. 受保护的特征构造与训练执行

当语义被确定之后，系统才可以开始执行被授权的特征构造与训练。

在这个场景里，受保护工作通常包括：

1. 在 Vault 或 TEE 边界内导出获准的 feature aggregate
2. 组装 training-safe dataset 或 federated training input
3. 运行 model optimization、aggregation 或 update 步骤
4. 产出 model artifact、metric 与可 replay 的 training transcript

在整个阶段中：

1. 原始消费历史默认始终留在授权 Vault 或 TEE 边界内，除非 policy 明确允许更窄的导出路径
2. 协议依赖的是 commitment、evidence、lineage 与可 replay 工件，而不是任意移动明文
3. 训练始终绑定于 admission 时确定的 feature、policy 与版本约束

5. 验证与被接受的训练结果

协议不会把某个产出的 model artifact 立即视为最终事实。

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

1. accepted
2. rejected
3. challenged

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

6. 结算、记账与模型使用基础

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

在这个场景里：

1. settlement 的作用是把已接受的训练运行转化为协议认可的训练事实
2. finalized accounting 会成为后续 model registry 更新、部署或受控使用的依据
3. 已部署模型仍然只是下游系统后果，而不是协议真相本身

系统视角

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

1. 准入接口面

面向客户端的 admission 服务接收训练请求，校验提交方身份与授权，并把这些任务约束绑定为系统可执行的训练任务。

2. 协调与生命周期控制

协调服务负责把训练流程从 admission 推进到 semantic resolution、受保护 feature construction、execution、verification 与 settlement，同时保持整个过程有序且可审计。

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

语义服务负责在 commerce、behavior、identity 与 model governance 等相关 domain 下解释这项训练工作，并保持与当前 semantic_version 的兼容性。

4. Vault 与受保护数据服务

Vault 侧的存储和带授权的数据访问机制，负责在保持消费历史私密性的同时，只向训练计算暴露被允许的 feature material。

5. 执行运行时

执行 worker 在受保护运行时内完成 feature construction、training、aggregation 与 model artifact generation，并产出可 replay 的 result bundle。

6. 验证与质疑服务

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

7. 结算与下游模型使用

settlement 服务负责组装 finalized accounting context。下游模型系统随后可以在不改写协议 finality 的前提下，把这份最终结果作为 model registry 更新、部署或激活的可信依据。

语义与特征处理

这个场景也是受治理语义解释的一个典型例子。

如果某个模型依赖的概念无法被当前 canonical set 或 query set 直接解释，可能会出现几种情况：

1. 该任务保持阻塞，直到语义被澄清
2. 某些 feature logic 继续在策略允许下保持为本地处理
3. 新出现的行为语义或 query 概念之后进入受治理的语义演化流程

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

1. domain
2. CanonicalAttribute
3. QueryAttribute
4. local attribute handling
5. governed candidate evolution

关键在于，训练逻辑不能私下或悄悄改写协议含义。

关键边界提醒

单纯想基于消费者行为训练模型，还不自动等于一个完整的协议事件。

只有当系统把这项训练意图转化成一项带有明确 feature、privacy 与 evaluation 约束的授权协议任务时，完整的 SCP 生命周期才会开始。

同样地，训练出的模型也不会自动等于协议真相；协议真相是那个被接受并完成结算的训练结果，而下游系统再据此决定是否部署或激活该模型。