跳到主要内容

ADR-0005 生态级多市场数据边界口径

§0 决议简述​

确立一个跨项目的数据边界口径：生态内多市场数据（crypto / 股 / 期 / 汇 / 宏观）由谁取、DH 承接什么、消费方自持什么。本 ADR 不是新的数据架构，是把 ADR-030（DH↔FinBayes 数据接口分工） 的双边结论，向生态范围（Trading Matrix / 未来项目）推广，并明确它与 DH 既有红线（ADR-004 差异化价值原则、架构边界不变量 #4）的关系。

级别判定：本 ADR 不修改任何治理协议正文，只在 ecosystem/ 对象层面立跨项目接口口径——按 变更协议 §1 属 L3（对齐同目录 ADR-0002 / ADR-0004 触及生态对象、走 L3 无公示窗口的先例），不需要 L4 七天公示。

§1 背景与根因（简）​

2026-06-22 FinBayes 团队问 BTC 多交易所盘口、全交易所取不到数。根因是取数容错 + venue 感知这一层从未建立（详见 DataAcquisition 子系统设计）。FinBayes 侧整改（弹性取数 + venue 模型 + crypto 接口）已落地。整改中浮现一个超出单项目的问题：crypto 只是第一个市场，未来多市场 + 多 vendor 的数据该由谁取、DH 承接到哪——owner 定调「整体架构、多市场，聚合源优先考虑生态内 DH」。本 ADR 即把这条口径立清，且不与 DH 红线冲突。

§2 相对 ADR-030 的新增判断​

ADR-030 已在 FinBayes↔DH 双边定了「商品化 FinBayes 直连 / DH 管配置 + 产高价值资产」。本 ADR 相对它的增量按强度诚实分级（不虚增条数）：

  1. 范围显式扩绑到生态全体消费方多市场（薄但真）：ADR-030 §1 已称这是「一个跨生态的边界问题」，本 ADR 的真增量仅在于显式把同一边界绑定到 Trading Matrix 与未来项目（TM 的数据需求本就落在差异化一侧、平凡成立），避免每个新项目重新议。
  2. DH 配置面定性为 registry 非运行事实源（沿用并收紧 ADR-030 §2.1）：ADR-030 §2.1 已把 DH 定为「配置中台 / 配置事实源、FinBayes 自持可达性、本地默认兜底」。本 ADR 把措辞收紧为 registry，并补一句「取数可用性责任不外包给 DH」（见 §3 共享注册表）——是再叙述 + 边际收紧，非全新判断。
  3. 「商品化 → 差异化资产」可裁决判据（唯一实质新增，但是 DH ADR-004 的操作化、非首创）：DH ADR-004 已立「差异化 vs 商品化、他处难自助、高杠杆、可信可回测」原则；本 ADR §3 边界二把它收敛成可执行的硬规则（仅转发原始字段=商品化 / 加校验+出处+质量+可回测=差异化），解决 ADR-030 只给例子未给规则的缺口。它是上位红线 ADR-004 的跨项目操作化，不另立新红线。

自检结论（按本 ADR 自设的「若三条都不成立应并入 ADR-030」纪律）：第 3 条成立（ADR-030 + ADR-004 均无可裁决硬规则），故本 ADR 保留为独立的生态级 WHAT 锚；第 1、2 条为薄增量 / 再叙述，不单独支撑存在必要性。

§3 决议：两条边界 + 一个共享注册表​

不用「三层」叙述（中间层易被误读为又一个控制面）。口径是两条数据边界 + 一个不承担运行责任的注册表：

边界一 · 数据面：消费方直连商品化行情，DH 不路由​

OHLCV / K 线、未平仓合约、资金费率、订单簿、报价等标准行情，第三方 API 可自助获取，由消费方直连第三方并自持取数容错 + 缓存 + 出处信封 + venue 感知。DH 不路由这类数据（守 DH 边界不变量 #4 与 ADR-004）。

边界二 · 资产生产面：DH 只产出「差异化资产」，且有判据​

DH 承接的不是「免费源做不了就归 DH」，而是对数据做了增值的那一层。判据（硬规则）：

  • 仅转发 vendor 原始字段 = 商品化，不进 DH 主线（哪怕是清算图 / 多空比 / 链上指标——若只是把 Coinglass / CryptoQuant 的字段转包，仍是重复路由、仍碰红线）。
  • 加了跨源校验 / 质量标签 / 双时间戳 / 授权与适用限制 / 可回测资产快照 / 生态复用消费契约 = 可进入 DH（命中 ADR-004「他处难自助、高杠杆、可信可回测」）。

即：DH 在衍生品 / 链上数据上的价值是校验 + 出处 + 资产化，不是当 vendor 的代理。这条同时框住了 §6 里 Coinglass/CryptoQuant 这类 self-serve vendor 的归属——它们的原始数据接入可由消费方直连，DH 承接的是其上的资产化层。

灰带的最小门槛（防「裹层信封就算资产化」）：出处信封 / 双时间戳是 DH 所有输出的基线要求（架构七维度），本身不构成增值。单源 vendor 透传只有在叠加了「跨源印证」或「实质性质量 / 许可裁定」时才跨过差异化线；仅加出处元数据的单源透传仍是商品化代理，不因经过 DH 就变差异化资产。

共享注册表 · DH 维护 provider registry，但不承担运行可用性​

DH 的 Provider 配置中心 作为生态内 provider 注册表 / 推荐配置源：维护 provider 元数据、凭据引用规范（非明文凭据）、能力标签、被墙源代理出口建议、可达性证据。消费方读取该 registry 后在本地合成自己的 fallback / runtime policy，并自持最终取数可用性——不把可用性责任转嫁给 DH。该注册表对消费方是低优先、非 P0/P1 运行依赖：DH 未暴露前，消费方用本地静态默认（venue 模型 + 本地配置）兜底，不阻塞。

§3.5 已失效的候选判断：DH 是过渡桥​

Superseded in part by ADR-0007（2026-08-25）：本节“DH 是过渡桥”的生态级判断从未完成本 ADR 所需会签，现已被获批的 DH↔TM 信息质量与反馈边界决策明确覆盖。Data Horizon 保持独立金融信息感知系统定位；消费方可以自主决定商品化行情的 sourcing architecture，但不能据此降级 DH 的生态身份。以下文字仅作为 proposal audit trail 保留，不再作为候选继承口径。

原候选记录称 owner 2026-06-24 直接拍定本方向（当时注明“不走 DH 会签”）：

  • 现阶段：维持走 DH（CoinAnk 清算等经 DH 透传 pilot 继续用，不动）。
  • 数据能力终局 = FinBayes 自主内化：① 近期——必要的基础数据 + 高频使用的数据能力，由 FinBayes 在后续内测中按真实使用（什么必要、什么高频）驱动逐步内化、自己取；② 以后——FinBayes 内化独立的基础 + 高阶数据能力（不再依赖 DH 取这些）。
  • 含义：DH 是过渡桥、不是永久依赖，用量随 FinBayes 内化推进而下降；内化按内测需求分批、不预先全建。故 §3 边界二「DH 产差异化资产、FinBayes 消费」是现阶段安排、非长期终态；本节内化方向优先于边界二的永久性表述。

§4 不变 / 变​

不变：出处信封（FetchResult / SourceRef）契约不动；诚实降级仍是地板；DH 红线（不路由商品化数据 / 不做认知结论 / 不做执行）不动。

变：取数从「单源单次」升级为「弹性多源 + venue 感知」（FinBayes 侧已落地）；确立「商品化数据面消费方直连 + DH 维护注册表 + DH 只产差异化资产」的边界口径，并给出商品化↔差异化判据。

§5 落地状态（诚实）​

  • 已落地（FinBayes 代码本地部署）：边界一的弹性取数 + venue 模型；crypto 接口完整；FX（frankfurter ECB 免费 + OANDA keyed）/ A 股（Tushare）/ 美股 的商品化直连取数代码亦已落地（均 FinBayes 直连第三方、不经 DH、不破边界一；部分待 live 验证，已知 FX 仅可信 rate 无可信 bid/ask）。期 / 港 / 日韩股 尚无代码，只有 配套任务书 §6 的 vendor 候选与口径。
  • 未落地（待 DH）：共享注册表（DH 配置中心 R2/R3 候选、排序由 DH 项目层裁定）、边界二的差异化资产生产（待 DH 立新 work package）。
  • 首个落地目标（owner 2026-06-23 拍）：CoinAnk 初级套餐由 DH 集成、经统一 Open API（并入现有宏观 API 同一表面 + asset-family 命名空间、共用 X-API-Key 与出处信封）供 FinBayes 消费，先补清算缺口；后续升套餐 + 加 provider（详见 配套任务书 §7.3 / §8）。
  • DH 进度（2026-06-23 回复）：DH 已接入 CoinAnk Plan1 清算（aggregate-only：汇总窗口 + 历史桶 + 支持对；逐笔爆仓属 Plan3），实施前 4 项确认全答（套餐字段 / DH 托管 key / 30 请求/分钟无缓存 / licenseScope = 生态内部用许可、对外分发待 CoinAnk 书面确认）。首刀诚实定性 = 出处信封 + license + 双时间戳封装的「单源透传 pilot」；跨源校验 / 可回测快照尚无——按本 ADR §3 灰带门槛尚未跨过差异化资产线，故不宜称「资产化闭环」，记为「透传通路已通、资产化为 S2 后续」。DH 已交付 handoff 契约 + 放行 key 的 crypto scope；FinBayes 侧 dh_crypto.py 消费端已实现、接进 crypto 工具并经 live 验证打通（清算由 no_source → 真实跨所聚合数据带出处）。工程执行证据（commit / 测试条数 / 部署进程态）留工程仓与 配套任务书 §11，不入本 ADR 正文。
  • 待回写：本 ADR accept 后，ecosystem/object-registry.md 中「信息感知→认知 DH→FinBayes 接口」一行应从「待项目层定义」更新为指向本 ADR + ADR-030。

§6 备选方案​

A. 每个消费方各自集成所有 vendor，无 DH 注册表。 否决：重复集成、凭据分散、与 DH 配置中心方向相悖。代价：消费方各自维护弹性链有重复实现风险——这是被选方案的已知成本，由 §3 共享注册表 + 消费契约缓解。

B. DH 路由全部数据（含商品化行情），或当所有金融数据的控制中台。 否决：违反 DH 边界不变量 #4 与 ADR-004；把 FinBayes 的运行可用性责任转嫁给 DH；给最常用路径塞 DH 依赖增加脆性。

C. 维持现状（消费方单源单次直连、无注册表、无判据）。 否决：正是 2026-06-22 取数失败的根因，无法扩展到多市场多 vendor。

§7 关联​