Data Horizon / 数据视界
Data Horizon 是 FinTec AI Ecosystem 感知环节中的独立金融信息感知系统和金融信息产品生产系统。它把多源金融信息组织成身份稳定、来源清楚、权利可判断、质量可说明、生命周期可追踪，并能被人和机器复用的信息产品。
关键边界：DH 不拥有金融认知、最终研究结论、交易决策或执行；消费者的编辑、排序、策略、个性化、品牌和商业逻辑不进入 DH Core。
当前阶段
| 项 | 当前状态 |
|---|---|
| 生态登记 | 第一阶段收束完成（Phase 1 Closure 判定 PASS）/ 第二阶段已提议未启动；依据 2026-08-31 已接受 L3 提议，后续生态阶段变化仍须 L3 治理。 |
| 项目级 canonical baseline | 2026-08 已按事实地图 → inventories → 参考评估 / Owner direction → 战略 → 产品定义 → Gap / Roadmap 顺序完成 L2 重基线并获批。 |
| 第一阶段目标 | 证明不依赖单一消费者的独立金融信息产品闭环。 |
| 消费顺序（Accepted direction） | 内部人类 → 内部机器 → 外部 B → 外部 C；是项目级验证顺序，不冻结具体对象或 Interface。 |
| 外部 B（Accepted direction） | 只登记匿名 benchmark case 与 workload evidence；需至少两个异构消费者证明可移植性。 |
| 第一阶段收束（2026-08-31） | 第一阶段按 Phase 1 Closure 口径收束完成，收束判定 PASS（收束目标达成、第一阶段作为执行阶段关闭）。四轴历史状态（Governance Partial / Implementation Substantial / Production Partial / Acceptance Not accepted）与未达标的严格验收指标保留为历史事实，不改写、不倒推为 Phase 1 Accepted。 |
| 第二阶段（2026-08-31） | 已提议、未启动。 方向为四项大白话成果（看得更广 / 看得更清楚 / 看得更快 / 更容易使用），并以 Owner 补充决定确立信息不确定性与市场影响边界（DH 是感知与情报平台，不做事实核查 / 真伪裁决；先感知、后丰富、持续更新）；知识治理方向已经 2026-08-31 L3 评审接受（提议 + 评审纪要），方案见 第二阶段知识包；接受仅覆盖知识治理方向，启动与逐阶段授权待 Owner 决定。 |
| 外部 C | Not approved；个人向使用探索仅允许原型 / 封闭验证，公开上线、商业运营、投资建议与生产 SLA 均未批准。 |
| 当前工程 | 能力已较广，但 Implementation、Production、Acceptance、Governance 必须分别判断。 |
建议阅读顺序
| 顺序 | 文档 | 回答的问题 |
|---|---|---|
| 1 | 现有系统与战略映射图 | 截至 2026-08，工程真实有什么、生产证据到哪里、哪些仍未验收或未治理批准？ |
| 2 | 当前与候选 Inventory | 当前/兼容/候选/未批准的 output、interface、architecture、collaboration 分别是什么？ |
| 3 | 参考评估与 Owner direction | 外部参考怎样挑战 DH，哪些项目级方向已接受、哪些仍 deferred？ |
| 4 | 战略白皮书 | DH 的长期定位、边界、壁垒、路线和协同原则是什么？ |
| 5 | 战略白皮书（大白话版） | 怎样用不依赖工程术语的方式快速解释当前战略？ |
| 6 | 系统 / 产品定义 | 第一阶段产品主体、用户任务、最低语义、Interface 与验收是什么？ |
| 7 | 第一阶段 Gap 与需求映射 | 治理、实现、生产和验收分别还缺什么？ |
| 8 | 实施承接区 | 当前 gates、路线图、Work Package 与 deliverables 如何承接？ |
| 9 | 第二阶段知识包 | 第二阶段为什么存在、先做什么、故意不做什么、怎么判断做完？（已提议、未启动） |
文档状态原则
Implemented只说明当前代码存在，不代表生产验证。Production verified不代表产品验收或治理冻结。Compatibility asset必须维护既有依赖，但不能反推未来 Core。Candidate必须先经过参考评估和 Owner 决策。Not approved不得被工程实现或对外承诺。- 工程仓的表、API response、UI 页面和 job 只是实践证据，不能互相替代正式 output、Interface、Architecture 或 Collaboration 定义。
第一阶段产品主体
第一阶段项目级产品主体是供内部运营、研究、复核和管理人员使用的金融信息运营工作区及其背后的信息产品生产闭环。该方向已经 L2 接受；具体对象、Interface、页面和工程合同仍须后续 gate。现有 Ops Console、Source Health、Review、Provider Config、Cron、KOL Workbench 等是组成材料，不应由菜单结构反向定义产品。
内部机器和外部消费者用来验证可复用性与交付能力：
- FinBayes：认知消费候选，需以具体任务定义最小信息对象；
- Trading Matrix：内部机器验证与兼容 Adapter，不定义 DH Core；现有数据、API 与协同链路不得因 Core 演进而退化；
- 独立外部 B benchmark cases：只以匿名 workload、rights、SLA、acceptance evidence 进入治理；现有 News Stream v1 是兼容资产；
- 其他外部 B：用于证明中立产品和 Interface 的可移植性；
- 外部 C：当前未批准。
治理与工程边界
项目级事实和决策在本目录维护；生态对象、阶段或正式跨项目 Interface 的变化进入 ecosystem / L3 治理。
Data Horizon 工程仓承载实现、测试、迁移与运行手册。工程事实进入本库时，必须标明 commit、生产证据和验收边界；本库不复制代码，不把生产只读观察写成已完成 acceptance。
改 canonical Markdown 后运行 npm run derive，由工具更新 for-agents/**；禁止直接修改派生物。
历史定义
2026-06-01 的旧系统 / 产品定义已归档至仓库内 _archive/projects/data-horizon/2026-08-21-canonical-rebaseline/system-product-definition-2026-06-01.md。旧版保留用于追溯，不再作为当前实施指令。
相关入口
| 类型 | 入口 |
|---|---|
| 生态边界与阶段 | 生态对象注册表 |
| 第三方参考 | Data Horizon 参考层入口 |
| 已接受 L2 重基线 | 2026-08-21 Data Horizon canonical rebaseline |
| DH ↔ TM 跨项目边界矫正 | 已接受的信息质量与市场反馈边界 L3 提议 |
| 治理变更规则 | Change Protocol |
| 接入规则 | ACCESS |
Changelog / 演化记录
2026-08-31（第三次更新）：第二阶段 L3 提议经 Owner（生态发起人）评审接受，第一阶段 Closure 发布提议同步关闭；生态登记行更新为已接受阶段表述，第二阶段仍未启动。同时把两份 2026-05-22 历史 DH 提议（Step 1 定义工作区、白皮书评审反馈汇总）移入 superseded 归档。
2026-08-31（第二次更新）：第二阶段方向行补记 Owner 第六项决定（信息不确定性与市场影响边界），其余登记不变。
2026-08-31：登记第一阶段收束完成（Phase 1 Closure 判定 PASS，四轴历史与未达标严格指标保留为历史事实）；新增第二阶段知识包入口与四项大白话成果方向（已提议、未启动）；外部个人向探索边界更新为"仅原型 / 封闭验证"。
2026-08-27：刷新第一阶段四轴（Governance Partial / Implementation Substantial / Production Partial / Acceptance Not accepted）并登记 Phase 1 Closure 执行读法；按 2026-08-25 L2 正式 receipt 将消费顺序与外部 B 匿名化方向统一为 Accepted direction，具体对象和 Interface 仍未冻结。
2026-08-25：L2 正式 receipt 接受 D-01 至 D-13；消费顺序与外部 B 匿名化成为项目级 Accepted direction，external C 保持 Not approved。
2026-08-21：按 2026-08 canonical rebaseline 重写项目入口；增加事实、inventory、参考评估和决策阅读顺序，明确独立闭环、消费者顺序、四状态轴与 To B / To C 边界。