运行状态

我们对什么负责，以及永远不对什么负责。

服务级目标、它们各自的度量口径，以及事故如何通报。这一页目前还没有实时数据源——与其画一块「因为什么都没接上所以全绿」的看板，我们把位置留空，并写清楚将来会由什么填满它。

当前状态

尚无实时数据

组件看板与滚动历史会在首个生产部署上线时出现在这里。它由下方目标所依据的同一批测量生成，不由人工维护。

计划中 · 随首个生产部署上线

五项目标，每一项都附上它被度量的口径。一个可以有两种读法的口径不算目标，所以口径与数字一起公布，而不是留在合同附件里。

目标项	目标值	度量口径
实时信号捕获延迟	P99 ≤ 15 s	从承载该执法动作的区块在源链上达到终局，到告警离开我方系统为止。按链分别度量，在我方一侧统计，覆盖每一条告警而非抽样。
筛查延迟	P99 < 100 ms	对我方自持的权威名单的一次查询，在 API 边界处度量。该层覆盖为全量，且不计费。
入金裁决延迟	P99 < 3 s	一次完整裁决，含过程中调用的任何外部来源。预算内超时解析为 HOLD。不存在任何一条分支会让它解析为贷记。
API 可用性	每月 99.9%	按自然月计，未返回服务端错误的合格请求占比。我方自己的 5xx 计入违约。客户端 SDK 默认把 5xx 读作 HOLD，因此我方故障只会让客户更严格，不会更宽松。
Webhook 投递	至少一次，24h 内	指数退避加死信队列。「至少一次」意味着按设计可能重复，消费端必须幂等。投递会重试，不会被静默丢弃。

提前量: 事前可见性是发行方选择的治理方式的副产品，发行方可以在无预告的情况下把它取消。对一个具体间隔作出保证，等于对一件我们并不控制的事作出保证。我们给出的是另一种：有信号时第一时间送达，并标出哪里是盲区。
覆盖的完整性: 有些机制在生效之前不留下任何可读痕迹。每一个响应都带覆盖健康度，让「安静」与「看不见」在使用现场就能被区分开——这比在这一页上放一个数字更有用。
判断的准确性: 我们报告观察到了什么，并保全它的证据。我们不给自己的结论打分，也不提供一个会诱使你把它们当作已被打分的分数。

在第一次事故之前写好，因为在事故当中写的政策叫谈判。