用途：为账户关联的 KYC 场景设计一套以 Persona 为验证提供方的控制平面架构，把 Persona 放在服务端身份编排边界之后。应用端负责主体身份、操作幂等、策略与决策；Persona 负责问询与验证资源；通过已认证事件加对账机制把两者连接起来。
前置条件：需要系统上下文、数据分级与威胁模型，业务与监管决策策略，以及可用性、延迟、留存、驻留和恢复要求。
主要步骤：一、划分信任边界，将客户端、应用 API、编排服务、密钥存储、Persona REST API、嵌入式问询流程、Webhook 边缘、持久队列、决策引擎和评审台分开。二、定义权威标识，把内部主体映射到 Persona 的 account 与 inquiry ID，操作 ID 与事件 ID 需有唯一性约束，不要用 PII 作为连接键。三、设计命令与会话，创建 inquiry 时使用持久幂等与支持的 account-auto-create 元数据，仅通过已认证的主体所有权签发或恢复会话。四、设计事件接入，终止 HTTPS、保留原始字节、校验带时间戳的 HMAC、在确认前先持久化、去重、按提供方创建时间排序、容忍未知事件类型。五、把证据与决策分离，保守地归一化验证资源，再应用带版本的内部策略，并有明确的复核与申诉路径。六、做恢复与隐私工程，使用持久队列、GET 对账、有界重试、环境与配额控制、数据最小化、留存、不可逆脱敏治理及经验证的回滚。
认证：服务端 REST 边界持有环境 bearer 密钥，Webhook 边缘持有签名密钥，客户端只拿到自己的 inquiry 会话令牌，凭据不得跨角色传递。
使用限制：未经操作员明确批准，不要创建、恢复、批准、拒绝、脱敏、轮换、吊销、部署或以其他方式变更生产 Persona 资源。输出需包含环境、资源与事件标识、API 版本、模板上下文、来源契约指纹、证据、未决风险、回滚状态与最终决策，且不得暴露 bearer 密钥、Webhook 密钥、inquiry 会话令牌、原始身份文件或不必要的 PII。一次请求成功并不等于身份决策成功。