“会达到 30 度吗？”可以对应几种不同的交易。 天气应用四舍五入后的预报、观测站实测气温和稍后公布的官方报告，可能并不一致。在任何人买入 YES 或 NO 前，市场就需要说明哪一个决定支付。
《Polymarket 与 Kuest 运作原理》第六篇，先把这个问题变成可测试规则，再沿着系统的不同层次追踪证据。可读页面、已承诺的结果判定字节和可访问的元数据文档，分别证明不同事情。
重写问题，直到两位读者得到相同答案
沿用虚构的 A 观测站、B 城和日期 C。“12:00”必须说明指观测时间还是发布截止时间，两者是不同事件。可以将标题重写为：“A 观测站在日期 C 的 12:00 UTC 对 B 城的观测气温，是否至少为 30.0°C？”然后明确证据：
使用 A 观测站日期 C 的官方每日观测 CSV，站点 B-01。读取时间戳为 12:00:00 UTC 的记录中，以摄氏度表示的空气温度字段。采用日期 C 的 13:00:00 UTC 之前可获得的最新官方修订，包括恰好在该截止时刻发布的修订。将公布的数值直接与 30.0 比较，不再次舍入。有效值达到或超过 30.0 为 YES，低于该值为 NO。忽略预报、其他站点和更晚的修订。如果截止时记录已撤回、冲突记录没有权威的修订顺序，或没有有效记录，则使用指定的数据不可用结果。
在真实市场中，应将每个虚构名称和日期替换为准确的来源 URL、站点标识、日历日期与字段定义。只写“官方网站”，仍会让读者自行选择页面、镜像和修订。备用来源也需要明确优先级，否则只是在结果已知后增加另一个选择。
在此规则下，即使应用显示 30.0，29.96 也意味着 NO。截止前从 29.9 修正为 30.1，意味着 YES；同样的修正在截止后发布，则不改变选定观测。规则明确将相等归为 YES，因此阈值处没有未解决的平局。
观测时间选定记录，截止时间选定修订，支付政策处理证据缺失。
数据不可用结果必须匹配所选合约路径。在这个教学例子中，假定使用支持 UNKNOWN 的标准二元适配器：YES 结果下 YES 支付一单位抵押品、NO 支付零；NO 结果下相反；UNKNOWN 下两者各付一半。这是明确的模型假设，不是通用取消规则，也不是 NegRisk 支付政策。
每个代币支付半单位，不等于退还购买价格。以 0.80 买入 YES 的参与者，在该假设结果下收到 0.50。拆分与赎回机制决定支付方式；规则决定应报告哪种受支持结果。
来源截止、交易截止和结果判定时间承担不同作用。前者选择证据，第二个控制订单接受，第三个记录结果。例如，订单可以在 11:55 UTC 停止接受，而合格修订仍可到 13:00，之后再判定结果。运营方必须单独配置交易，交易延迟不会延长证据截止时间。
追踪两类证据
市场既需要定义明确的结果判定问题，也需要可读的支持信息。辅助数据（ancillary data）指某个预言机集成所用的额外问题字节；描述性元数据还可能包含图片、标签和链接。它们用途不同，不能当作可互换的承诺。
公开的 Polymarket CTF 适配器提供了一个按定义好的编码记录问题数据的例子。重新计算承诺需要完全相同的编码，而不是视觉上相似的段落。应检查所选部署的公开接口，不要把一个例子泛化到所有适配器系列。
问题承诺与外部文档支持不同检查；一个引用本身不能证明 完整性或可用性。
Kuest 的公开且已验证的 Conditional Tokens 合约记录创建者和外部元数据引用。引用用于定位信息，本身不能证明文档可用、不可变或与原始结果判定承诺相同。应取得文档，并与记录的问题证据比较。
Kuest 的公开市场创建文档描述支持的产品界面。上传文档、准备条件和出现可交易条目，是不同的观察结果。应确认相应记录，而不是从一个成功页面推断三者全部成立。
看起来相似的标识符，承担不同工作
slug定位页面。问题 ID按适配器方案标识问题。条件 ID在公开 CTF 构造中组合预言机、问题 ID 与结果数量。准确输入很重要，页面文字相似不能证明条件相同。
仓位 ID标识所持有和交易的资产。在 CTF 中，它的派生还取决于抵押品和代表结果集合的 collection。标题或 slug 相同不能证明资产相同。创建者地址记录归属和某些权限，外部元数据标识符定位描述内容；两者都不能替代条件或仓位 ID。
即使“问题 ID”也没有通用编码。在 Polymarket 特定的 NegRiskIdLib中，问题与其市场 ID 共享前 31 字节，最后一个字节用于问题索引。这条规则只适用于该适配器系列，不适用于所有预言机问题。
签名交易订单中的 metadata 字段是另一个对象。例如，公开的 CTF Exchange V2 定义包含订单层面的 bytes32 metadata。它的存在不能证明签名承诺了市场当前显示的文档。
可追踪的更新，仍然是更新
Kuest 的 Conditional Tokens 扩展记录条件创建者与当前外部元数据引用。创建者或 CTF 管理员可以替换引用。每次成功调用都会递增计数器，并发出条件 ID、旧引用、新引用和更新者地址。
所检查的函数不会在结果确定时冻结更新，也不会检查替换字符串是否指向可用且非空的内容。因此，条件 ID 不变，不代表当前显示的描述从未改变。更新也可能只是增加支持引用或修正图片；判断命题是否变化前，应比较实际文档。
引用更新可以补充文档，也可以改变描述。事件揭示谁修改了指向， 内容仍需比较。
改变指向不会重写原始问题字节，也不会赋予新的支付报告权。CTF 的报告函数将调用者作为预言机来派生条件。适配器及其配置的结果判定路径，决定答案如何到达该函数；编辑元数据是另一种权限。
假设版本 A 写 30.0°C，版本 B 写 31.0°C。历史事件让替换可见，却不能证明 31.0 已成为合法阈值。解释变更前，应将两者与原始辅助字节及适用澄清政策对照。
澄清需要作者与政策
Polymarket 本来就有链上问题承诺。其固定版本的 UMA CTF 适配器对扩充后的辅助数据做哈希并保存，公告板则记录带作者身份的更新。这些是特定 CTF 适配器机制，并不是对所有当前 Polymarket 路径的 ABI 主张。
澄清也需要可识别的作者和适用政策。在公开的 Polymarket 例子中，带作者身份的帖子不会重写原始辅助数据。不要把任意提及问题的声明当成官方修订。
Polymarket 的当前结果判定文档指出，澄清上下文应保留基本意图。指出 CSV 列名已更改，可以澄清证据；把 30.0 阈值换成 31.0，则改变了命题。时间戳证明声明何时被记录，不证明它具有合法权限。
验证从引用到屏幕的路径
实际检查应按顺序追踪证据：
- 识别部署。 记录网络、合约地址、适配器系列和区块引用。取得创建回执、原始问题字节、预言机身份、创建者和条件 ID。
- 重新计算对应标识符。使用该实现的编码、初始化处理和结果数量。按实际抵押品和结果映射检查仓位 ID。
- 追踪元数据历史。 读取准备时引用、当前引用、计数器和更新日志。取得原始与替换文档，比较变更和更新者地址。
- 分别检查完整性与可用性。 按照存储系统实际的交易或承诺方案验证内容。保存取得的准确字节和来源；如果无人能取得文档，记录一个引用也无法提供内容。
- 比较参与者看到的内容。 将显示的来源、日期、规则和结果标签，与原始结果判定数据和获授权的上下文对照。可读界面不是独立的完整性检查。
文档可访问、来源有效、显示一致，是不同检查。任何一项单独成立，都不足以证明正确的 结果判定。
对品牌运营方来说，Kuest 的具体补充是：与创建者关联的元数据引用、可见更新历史，以及原始结果判定数据。它支持可审查的目录和可归属的发布流程，但不会把所有市场信息都放上链，也不保证文档可用，更不会裁决语义分歧。
通过 Kuest 上线自己的预测市场时，请准备明确的受众和司法辖区、经过演练的规则表、来源与修正政策、支持的结果判定路径，以及保留可访问证据的计划。接受交易前，先用模糊案例测试这些输入。