能跑通的演示不等于完成的客户流程：保留三层验收记录

问题：一个绿勾，三个结论

演示可以是绿色的，而客户流程却从未运行过。根据 GridZen 公开的状态，托管身份路由上的真实会话创建、签名回调和权威读取已有证据，但新用户完整通过托管流程以及客户业务动作仍未验证。运营方测试不是客户需求。如果你的验收记录只有一行“身份开户”，你就无法分辨自己证明了哪一项。你需要做的决定是：你真正可以签收哪一层，又是什么阻碍了下一层？

拟议设计：三层验收记录

这是拟议的应用设计，不是 GridZen 已实现的行为。每个试点保留一条记录，分三层。第一层，本地 fixture：证明你的处理程序用合成数据正确处理批准、重复、更正和过期。第二层，已批准路由：证明已验证的商户账户提交了试点申请，负责人审查了用途、下游协议、供应商权利、能力、免费额度和到期，并且路由已确认可用。申请永远不会自动开启生产。第三层，真实下游动作：证明真实用户在允许的用途下完成会话，你的服务重新读取权威决定，应用自己的策略，并执行一个有边界的业务动作。每层都有负责人、日期和证据引用，且任何一层都不能用下层的证据标记为完成。

假设示例：填写第一层

假设：一个小型市场团队运行可下载示例的 identity 任务。创建返回 mode synthetic_fixture、state simulated、session fixture-session、指向 example.invalid 地址的 hosted_link、link_executable false，以及 next send_real_provider_link_only_after_authorization。带显式策略的合成 Approved 事件得到 status approved、deadline 60、permission_granted true、grant_count 1、live_permission_changed false、policy_version 1、allow_action true。重放同一事件返回完全相同的记录，grant_count 仍为 1。随后的 Declined 更正得到 status declined、permission_granted false、grant_count 1。对于超过截止时间仍处于待定的会话，recover 返回 status expired、permission_granted false、grant_count 0、next review_or_authorized_provider_refresh 和 provider_polled false。团队将这些值原样记入第一层。注意每一行的 live_permission_changed 都是 false：这个字段说明第三层尚未发生。

记录必须覆盖的失败处理

失败也属于第一层。未知会话的事件会抛出 BINDING_MISMATCH；读取未知会话会抛出 SESSION_NOT_FOUND。事件必须使用以 fixture- 开头的合成标识；声称其他模式或来源的事件会抛出 PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED，因为 fixture 没有真实的签名验证器。用错误的预期版本修改策略会抛出 STALE_POLICY_VERSION；没有当前已批准证据的显式决定会抛出 CURRENT_EVIDENCE_AND_EXPLICIT_APPROVAL_REQUIRED。recover 只在本地使状态过期，从不轮询服务商。你的记录应写明由哪段调用方自有逻辑处理每个错误，例如转入人工审核而不是盲目重试。

fixture 不能证明什么

fixture 中的权限是 SQLite 里的本地记录，不是真实的卖家或用户权限。第一层全部通过，并不说明第二层的资格、服务商额度或下游权利，这些必须在启用前核实。还要把这个示例与无需注册的匿名 HTTP 试用区分开：该试用在三个场景中返回合成响应，与包含四个电话分支和身份状态机的可下载示例是不同的产物。请注明你运行的是哪一个。

实用验收清单

第一层：上述每个 fixture 输出均按字段值记录；重复事件不改变 grant_count；更正清除 permission_granted；过期报告 provider_polled false；两个错误码均已处理。第二层：从已验证商户账户提交试点申请；记录审查结果；单独确认路由可用；每个请求使用一个幂等 UUID，中断后读取已有记录。第三层：允许的真实用户完成真实会话；重新获取权威决定；记录策略版本和显式决定；执行一个可撤销的下游动作。在这些全部具备之前，第三层保持未完成。

下一步

在 customer-pilot 指南中运行对应的合成教程，把每个输出字段填入第一层，并逐一检查你的代码如何处理每种失败，包括绑定不匹配、会话不存在和过期策略版本。只有在需要保存记录时才创建沙盒账户；沙盒记录同样不代表真实业务权限。然后在申请真实试点路由之前，判断沙盒集成是否适合你的任务，并让第二层和第三层保持未完成，直到出现各自独立的证据。

运行已检查的模拟示例

下载并解压 https://gridzen.ai/downloads/verification-delivery.zip，进入 verification_delivery，用 Python 3.10+ 运行。此本地示例不联网；独立身份实验请使用新的数据库。

python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqlite

来源与范围

https://gridzen.ai/guides/customer-pilot/ https://gridzen.ai/guides/current-capabilities/ 依据已检查的来源快照与本地模拟；建议的业务规则属于设计建议，不代表已证明的生产行为。内容使用 AI 辅助写作，并经过独立审稿。