Data Horizon 参考层入口
状态：Draft / reference hub
最后更新：2026-05-15
项目：Data Horizon / 数据视界
触发：R4 项目文档 IA audit（packets/sync/data-horizon-doc-ia-audit-2026-05-15.md §5.1）
1. 定位
本目录是 Data Horizon 第三方参考项目筛选、体验、评估和交叉对比的入口与索引。
本目录不是：
- 产品定义或 MVP 定义；
- 工程实施计划或 backlog；
- 当前实践正确性或最优性的证明；
- 竞品报告或市场分析。
本目录用于回答：
Data Horizon 应参考哪些外部产品、项目、架构、协议或实现，来回答自身的感知能力、信息覆盖、标准化、存储检索、接口形态、产品交互、成本控制和治理合规问题？
2. 参考评估问题域
从 data-horizon-alignment-packet-2026-05-12.md §5 和 output-object-inventory.md §6 汇总，参考评估应覆盖以下上位问题域：
| 优先级 | 维度 | 上位问题 |
|---|---|---|
| P0 | 感知能力 | 同类产品/系统如何完成金融信息监听、采集、清洗、标准化？ |
| P0 | 信息覆盖 | 同类产品/系统覆盖哪些市场、资产、信息源、数据类型？ |
| P0 | 质量 / Provenance | 同类产品/系统如何标记来源、时效、质量、授权和适用限制？ |
| P1 | 标准化方式 | 规则 / NLP / 小模型 / 云端 LLM / 人工复核如何分层？ |
| P1 | 存储检索 | 原始 / 规范化 / 搜索 / 语义 / 对象 / 数据集如何分层？ |
| P1 | 接口形态 | API / feed / MCP / CLI / export 等形态的实际案例？ |
| P1 | 成本控制 | 高频持久采集链路的成本结构和控制手段？ |
| P2 | 产品交互 | 内部控制台、B 端、C 端产品面的实际案例？ |
| P2 | 生态协同 | 感知层与认知/执行系统的协同模式？ |
| P2 | 治理合规 | 来源授权、非公开信息、用户误导风险的处理方式？ |
3. 参考项目筛选原则
筛选方式遵循 alignment-packet §6：
- 不从固定竞品分类出发；
- 不先假定 Bloomberg、金融新闻 API、另类数据商或开源 Agent 项目就是参考池；
- 先从 Data Horizon 的第一性角色、职责、场景和能力问题出发；
- 再为每个问题选择最合适的参考产品、项目、架构、协议、服务或实现；
- 每个参考对象必须明确回答上方问题域中的哪些维度。
4. 候选参考对象 Shortlist
当前状态：空白 / Blocked
待补。首批候选应至少覆盖：
- 金融信息 API 服务（感知能力、信息覆盖、接口形态）
- 金融数据标准化平台或协议（标准化方式、质量/Provenance）
- 开源金融信息采集框架（架构、成本控制、存储检索）
- 内部运营控制台参考（产品交互、工作流能力）
每个候选对象应按以下格式登记：
### X.X <参考对象名>
- 类型：<API 服务 / 开源项目 / 商业平台 / 协议 / 架构参考>
- 覆盖维度：<P0/P1/P2 维度列表>
- 回答的上位问题：<具体问题>
- 评估方式：<desk research / 注册体验 / API 测试 / 代码阅读 / 部署复现>
- 评估状态：<待筛选 / 待体验 / 待评估 / 已完成>
- 评估产出位置：<references/data-horizon/xxx-reference-analysis.md 或 xxx-reference-evaluation.md>
5. 已完成评估
无。
6. 评估方法
参考 references/external-reference-evaluation-method.md 的通用方法。Data Horizon 专属补充：
- Desk research 产出命名：
<对象名>-reference-analysis.md - 复现/体验证据产出命名：
<对象名>-reference-evaluation.md - 交叉对比产出命名：
data-horizon-reference-cross-analysis.md - 评估必须显式标注该参考对象对 Data Horizon 当前实践画像的挑战点和吸收建议
7. 输出对象参考评估优先级
基于 data-horizon-doc-ia-audit-2026-05-15.md §5.5：
Tier 1：参考评估必须覆盖
| 候选对象 | 参考评估需回答 |
|---|---|
| Perception Record | 单条金融信息感知记录应包含什么？质量、provenance、生命周期如何表达？ |
| Financial Information Feed | 面向不同消费者的 feed 形态如何区分？ |
| Data Quality / Provenance Metadata | 来源、时效、授权、质量的最小底线字段？ |
Tier 2：参考评估应覆盖
| 候选对象 | 参考评估需回答 |
|---|---|
| Evidence Package | 证据保留、原文快照、多源印证的最小可行方式？ |
| Dataset Package | 训练/评估/B端交付的数据包 manifest？ |
| Source Reliability Profile | 非交易化的来源质量观测维度？ |
Tier 3：接口与工作流
| 候选对象 | 参考评估需回答 |
|---|---|
| Machine Feed Contract | REST / webhook / streaming / MCP / bulk export 选型依据？ |
| Human Review / Quality Label | 内部复核工作流最小能力集？ |
| Retrieval Result | 检索结果对象如何表达匹配原因、时间、来源、质量？ |
8. 与 projects/data-horizon/ 的回流关系
参考评估的稳定结论应回写到：
| 结论类型 | 写回位置 |
|---|---|
| 参考对象分析 | references/data-horizon/<对象名>-reference-analysis.md |
| 复现/体验证据 | references/data-horizon/<对象名>-reference-evaluation.md |
| 交叉对比结论 | references/data-horizon/data-horizon-reference-cross-analysis.md |
| 对 current-state 的回流 | projects/data-horizon/current-state.md（由 Controller 判断） |
| 对 output-object-inventory 的回流 | projects/data-horizon/output-object-inventory.md（由 Controller 判断） |
| 对产品定义时机的回流 | projects/data-horizon/README.md §3（由 Controller 判断） |
参考评估结果不能直接成为产品定义、MVP、接口契约或工程实施计划。