用例：面向近期瑞幸消费者的定向优惠券活动

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

场景

瑞幸咖啡希望在新加坡发起一场营销活动，面向过去 30 天内有过瑞幸消费的用户发放优惠券。

这场活动的目标，是从合资格用户中选出最多 5000 人，并通过下游业务系统向他们发券。

本文档是说明性用例，用来展示新修订后的 SCP 与 SCS 规范如何映射到一个由广告客户发起的定向人群筛选与发券场景。

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

为什么这个用例重要

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

1. 发起方是广告客户，而不是普通终端用户
2. 资格判断依赖的是处于 Vault 边界内的受保护消费记录
3. 任务本身带有 geography、时间窗口与人数上限约束
4. 目标人群结果必须经过验证后，才能成为可被活动使用的可信事实
5. 发券动作位于 finalized protocol accounting 之后的下游

因此，这个用例很适合说明：协议可以支持隐私保护下的营销激活，但不会把原始消费者记录直接暴露成协议可见明文。

入口区分

这个场景有两层：

1. 业务侧的 campaign intent
2. 协议认可的人群资格判断与筛选任务

“瑞幸希望向新加坡过去 30 天内消费过的用户发券”本身还不是一个完整的协议事件。只有当系统把它转化为一项带有明确约束的授权任务时，它才真正进入 SCP 生命周期。

协议视角

从协议角度看，这个场景的核心，是把一项 campaign intent 转化为一个可验证、可结算的人群筛选结果。

1. Campaign 意图与本地业务输入

瑞幸先定义一场活动，其业务条件包括：

1. advertiser identity：瑞幸咖啡
2. geography：新加坡
3. eligibility window：过去 30 天
4. audience rule：过去 30 天内有过瑞幸消费的用户
5. audience cap：5000
6. downstream outcome：发放优惠券

在这个时点上，它仍然只是业务请求，还不是协议事实。

2. 任务接纳与约束绑定

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

从高层看，admission 需要明确：

1. 广告客户是否有权提交这场活动
2. 活动是否绑定了明确的 policy 与 budget 上下文
3. geography 和时间窗口是否被固定为本次任务的一部分
4. audience cap 是否被纳入协议需要评估的任务约束

只有经过这一步，这项 campaign 才成为协议认可的工作。

3. 资格语义的解析

在执行任何筛选之前，协议必须先解释这项任务在当前语义上下文中的含义。

这意味着协议需要先确定以下概念在当前 domain 与 semantic_version 下分别代表什么：

1. 瑞幸消费
2. 消费时间是否属于过去 30 天
3. 新加坡地域资格
4. campaign audience membership
5. 可以用于发券的目标身份或联系方式

这一步之所以重要，是因为修订后的 SCP 要求共享语义必须先于受保护计算成立。

4. 受保护的资格评估

当语义被解析清楚后，授权计算才可以开始在受保护记录上进行资格判断。

在这个场景里，这一步通常包括：

1. 检查用户是否有瑞幸消费记录
2. 判断消费时间是否落在过去 30 天内
3. 确认是否满足新加坡地域条件
4. 组装合资格的人群候选集合
5. 按 policy 定义的选择逻辑应用最多 5000 人的上限

在整个阶段中：

1. 原始消费记录始终留在授权 Vault 或 TEE 边界内
2. 协议依赖的是 evidence、commitment 与可 replay 的工件，而不是任意暴露明文
3. 所有筛选逻辑都必须绑定于已接纳的 campaign 约束

5. 验证与被接受的人群结果

协议不会把一份候选受众名单自动视为最终事实。

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

1. accepted
2. rejected
3. challenged

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

6. 结算、记账与发券依据

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

在这个场景里：

1. settlement 的作用是把已接受的人群筛选结果转化为协议认可的活动事实
2. finalized accounting 会成为下游发券的可信依据
3. 实际发券动作仍然是下游业务效果，而不是协议事实本身

也就是说，协议负责确定哪份人群结果是可信的；下游业务系统负责把这份可信结果转化为真正发出的优惠券。

系统视角

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

1. 准入接口面

面向客户端的 admission 服务接收 campaign 请求，校验广告客户身份与授权，并把活动约束绑定为系统可执行的任务。

2. 协调与生命周期控制

协调服务负责把 campaign 从 admission 推进到 semantic resolution、受保护资格评估、verification 与 settlement，同时保持整个过程有序且可审计。

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

语义服务负责在 commerce、transaction、identity、geography 与 audience 等相关 domain 下解释这项活动，并保持与当前 semantic_version 的兼容性。

4. Vault 与受保护数据服务

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

5. 执行运行时

执行 worker 在受保护运行时内完成 recent purchase、geography filter 与 audience cap 逻辑，并产出可 replay 的结果工件。

6. 验证与质疑服务

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

7. 结算与下游发券

settlement 服务负责组装 finalized accounting context。下游 campaign 系统随后可以在不改写协议 finality 的前提下，用这份最终结果作为发券依据。

语义与资格处理

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

如果活动依赖的某些概念无法被当前 canonical set 直接解释，可能会出现几种情况：

1. 任务会先被阻塞，直到语义被澄清
2. 某些概念会在策略允许的范围内保持本地处理
3. 一些新的 campaign 或 audience 概念之后可能进入受治理的语义演化流程

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

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

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

结算与发券后果

这个用例并不意味着瑞幸一定会直接获得协议奖励。

在协议层面，更核心的后果是：

1. 形成一份可信、被接受、并已结算的人群筛选结果
2. 形成下游发券可依赖的 finalized accounting basis

如果这条活动流程属于一个带激励的网络路径，那么也可能对某些 production roles 产生 reward 后果，例如：

1. Vault operator
2. executor
3. verifier

这些后果都必须建立在协议认可的状态迁移之上。

关键边界提醒

广告活动 brief 本身并不自动等于一个完整的协议事件。

只有当系统把这项业务意图转化成一项带有明确 audience、location 和 recency 约束的授权任务时，完整的 SCP 生命周期才会开始。

同样地，真正发出的优惠券也不是协议事实本身；协议事实是那份被接受并完成 settlement 的目标受众结果，而下游系统只是基于这份结果采取业务动作。