Data Horizon / 数据视界 战略白皮书

0. 文档定位与当前阶段

本文是 Data Horizon 的项目级战略事实源，回答：

1. Data Horizon 在 FinTec AI Ecosystem 中是什么；
2. 为什么在 AI 与金融信息结构变化下需要独立的金融信息感知系统；
3. 它长期生产什么价值、形成什么壁垒；
4. 第一阶段如何证明独立信息产品闭环；
5. 内部人类、内部机器、外部 B 和外部 C 如何依次进入；
6. 产品对象、Interface、Adapter 和工程实现如何受治理约束。

当前阶段需要区分四个层次，不得互相推断：

1. 项目级治理已收束：L2 canonical rebaseline、output/interface/architecture/collaboration inventories、reference evaluation 与 D-01 至 D-13 Owner direction 均已完成并被接受（D-14 为 Deferred；见 Reference Evaluation 与 Owner Decisions）。
2. 第一阶段收束完成（2026-08-31）：第一阶段按 Phase 1 Closure 口径收束完成，收束判定为 PASS——指收束目标达成、第一阶段作为执行阶段关闭；四轴历史状态（Governance Partial / Implementation Substantial / Production Partial / Acceptance Not accepted）与未达标的严格验收指标保留为历史事实，不改写、不倒推为 Phase 1 Accepted。
3. 第二阶段已提议、未启动：方向为四项成果（看得更广 / 看得更清楚 / 看得更快 / 更容易使用），载体为 2026-08-31 已接受的 L3 提议与 第二阶段知识包；接受仅覆盖知识治理方向，启动与逐阶段授权待 Owner 决定。
4. 生态登记已按 L3 更新：生态对象注册表 对 Data Horizon 的登记阶段已更新为"第一阶段收束完成（Phase 1 Closure 判定 PASS）/ 第二阶段已提议未启动"；该登记不冻结产品定义或工程契约，后续任何生态阶段变化仍须独立 L3。

本文是战略基线，不是正式 object schema、API contract、MVP、数据库设计、目标架构或工程路线图。

治理状态： 本版已通过 L2 canonical rebaseline review，作为当前项目级战略基线生效；它仍不冻结 object schema、API contract、MVP、数据库设计、目标架构或工程路线图。

当前工程已经存在大量实践资产，但不能因为代码、表、页面或消费者 wire 已经运行，就直接升级为 Data Horizon 正式产品对象。正式下推顺序是：

事实地图 → output/interface/architecture/collaboration inventories → reference evaluation → Owner decisions → 系统 / 产品定义 → Gap/Roadmap → 工程设计。

1. 一句话定义

Data Horizon 是 FinTec AI Ecosystem 感知环节中的独立金融信息感知系统和金融信息产品生产系统。

它面向公开与受授权的私域信息、实时与历史信息、结构化与非结构化信息，把复杂金融信息流转化为可追溯、可质量标记、可检索、可复核、可订阅或可导出的金融信息产品，供人和系统持续消费。

“金融感知资产”是本文对这些可复用信息成果的战略总称，不代表已经冻结一个同名数据库对象或统一 schema。

Data Horizon 不是：

• 更大的新闻爬虫；
• 某个消费者的专属后台；
• 最终金融认知、研究结论或投资建议系统；
• 交易策略、风控授权或真实执行系统；
• 仅靠接入源数量定义的数据平台；
• 把所有信息都送入最昂贵模型的 AI pipeline。

2. 为什么现在需要 Data Horizon

结构化行情、财务和宏观数据仍然重要，但越来越商品化、API 化和易于接入。与此同时，真正消耗人和机器判断带宽的信息在快速扩张：新闻、公告、政策、研报、社交、私域观点、图片、音视频、直播、链上材料、另类数据以及 AI 生成和改写内容。

这些信息具有共同困难：

• 来源多且质量不一；
• 同一事件被转载、改写、翻译和重复传播；
• 原始发布时间、系统取得时间、修订时间和消费者可见时间不同；
• 事实、推断、观点、宣传和交易主张容易混在一起；
• 访问权、处理权和再分发权不是同一件事；
• 信息会被纠正、撤回、补充或重新解释；
• 单一消费者的短期需求容易反向污染上游对象。

AI 降低了阅读和初步处理的成本，却同时提高了信息生产速度、噪声密度和伪确定性。新的长期优势不再只是“先看到”，而是：

能否持续把复杂、多源、快速变化的金融信息，组织成身份稳定、来源清楚、权利明确、生命周期可追踪、质量可判断并能被多个消费者复用的信息产品。

需要明确两类信息的角色：结构化信息是必要基础和上下文，不是被排除对象——行情、财务、宏观等结构化数据为身份、时间对齐和质量判断提供锚点；当前的差异化重点在非标准化与半结构化信息——它们来源分散、结构不稳、质量不一，正是消耗人和机器判断带宽、也最缺乏稳定感知产品的地方。

3. 系统使命与职责边界

Data Horizon 的使命是把金融世界的信息输入转化为稳定、可消费、可复核、可治理的信息成果。

核心动作包括：

1. 接入：连接来源、provider、文件、流和授权渠道；
2. 取得：保留 source record、原始 artifact 和取得上下文；
3. 处理：清洗、解析、翻译、去重、关联、结构化和质量标记；
4. 组织：按时间、实体、资产、主题、事件、来源和关系组织；
5. 溯源：记录来源、处理活动、参与者、版本、修订和证据；
6. 治理：记录权利、限制、复核、纠错、撤回和适用范围；
7. 输出：通过人类产品面和机器 Interface 形成不同消费投影；
8. 改进：使用运行、质量和消费证据改进来源与处理路径。

3.1 与金融认知的边界

Data Horizon 可以组合、去重和关联事实，也可以保留外部观点、情绪或交易主张，但不负责输出最终研究结论、投资判断、看多看空结论或反证推理。

这些认知任务由 FinBayes 等认知产品承接。

3.2 与交易执行的边界

Data Horizon 可以忠实采集他人的策略观点和交易信号，也可以输出值得下游进一步判断的信息变化，但不决定交易动作，不形成账户授权，不触发真实订单。

策略、回测、风控、授权、审计和执行由 AI Trading Matrix 等执行支持产品承接。

3.3 与模型能力建设的边界

Data Horizon 可以生产语料、样本、质量标签和评估材料，但不因此成为模型训练平台。FEFM 或其他模型能力系统负责训练、评估和模型治理。

4. Data Horizon 的战略资产与长期壁垒

Data Horizon 的壁垒不是单一来源、单一模型、单一 API 或某个消费者关系，而是以下能力共同形成的复利资产。

4.1 稳定身份与生命周期

同一信息可能有来源记录、DH 内部对象、publication 和 transport event 等不同身份。系统需要追踪 correction、withdrawal、revision、supersession 和 replay，而不是只保存 active snapshot。

4.2 Provenance 与 evidence

系统需要知道：原始 artifact 是什么，何时取得，通过什么 parser/rule/model/human activity 产生派生结果，由谁负责，与前一版本和其他来源有什么关系。

4.3 Rights 与适用范围

“从来源取得”不等于“可以向任何人再分发”。访问、处理、派生、再分发、训练、数据包交付和展示需要按 source、asset、output、purpose/consumer 分别判断。

技术 authorization 是执行机制，不是法律权利证明。

4.4 Quality 与不确定性

质量不确定的信息应显式表达来源级别、完整度、处理方式、置信限制和人工复核状态，而不是包装成确定事实。来源质量不能用 PnL 或交易收益直接定义。

这不意味着隔离交易反馈。准确性应区分事实/抽取准确性与特定交易条件下的方向命中；及时性应区分 DH 取得、处理、发布、送达延迟与消费者决策窗口适配；有效性必须绑定消费者任务和市场 context。来自 TM 的消费、验证和交易结果是 DH 改进来源运营、处理优先级、路由、质量提示、信号提取和时效策略的重要 evidence，但不得静默改写 raw fact、覆盖 rights 或抹去相反证据。

4.5 多产品输出与可移植性

同一 reusable information object 可以形成内部控制台视图、机器 feed、检索结果、B 端 API、bulk/dataset 或未来 C 产品投影，但每个输出必须独立判断权利、语义、时效、质量、成本和 SLA。

真正的 consumer neutrality 需要多个结构不同的消费者验证，而不是在代码中把 endpoint 改成通用名字。

4.6 成本—质量路径

规则、解析器、小模型、通用大模型、专业模型和人工复核应按信息价值、复杂度、风险和时效分层。成本控制不是事后优化，而是持续感知和商业化的必要条件。

5. 信息范围与成熟态感知版图

Data Horizon 的长期能力边界面向全球金融市场，而不是只面向加密、新闻或当前消费者。

成熟态可能覆盖：

• 宏观、央行、财政、监管和地缘；
• 公司公告、财报、监管披露、行业和供应链事件；
• 新闻、快讯、研究、访谈和媒体材料；
• 社交、社区、KOL、职业分析师和受授权私域材料；
• 加密、股票、商品、外汇、债券、利率、衍生品和链上数据；
• 价格、成交、盘口、波动率、资金费率、持仓和市场状态；
• 图片、音视频、直播、卫星、航运、供应链和其他另类数据；
• AI 生成、修改和传播的金融内容。

这是一张成熟态能力版图，不是第一阶段范围承诺。

覆盖优先级由以下因素共同决定：

1. 对内部人类和机器任务的真实价值；
2. 时效、风险和市场影响；
3. 来源权利、稳定性和可追溯性；
4. 当前实践复用程度；
5. 与第三方商品化数据相比的差异化；
6. 质量、处理和长期运行成本；
7. 是否能形成可复用信息产品，而不是一次性交付。

任何具体来源、市场或消费者需求都只是优先级证据之一，不能单独定义全局路线。

6. 产品与协同层次

Data Horizon 的核心、产品面和消费者产品必须分层。

6.1 Perception Core

负责身份、来源、时间、处理、权利、质量和生命周期。它不包含消费者的编辑排序、个性化、交易评分或产品 placement。

6.2 Information Products

把 core 中的信息组织成人或机器可消费的产品对象。Perception Record、Financial Information Feed、Evidence Package、Dataset Package 当前仍是候选，不在本文冻结结构。

6.3 Interfaces

Console、query、cursor feed、bulk、event/push 是不同交付方式。Interface 需要版本、时间语义、错误、兼容、弃用、权利和计量，但不是事实本体。

6.4 Consumer Adapters

Adapter 把 reusable product 投影为某个消费者需要的 shape。Trading Matrix、FinBayes、匿名外部 B cases 和 delivery channels 等现有 seam 应在这一层接受挑战。

6.5 Independent Consumer Products

外部 B 服务和未来可能的 C 产品拥有自己的品牌、用户、编辑、体验、个性化和商业闭环。它们不能反向定义 Perception Core。

7. 五大能力域

五大能力域是战略能力地图，不是团队、微服务或数据库边界。

7.1 信息接入

负责来源发现、注册、授权、provider 接入、采集、取得、健康度和失败恢复。

7.2 信息处理

负责清洗、解析、翻译、去重、关联、标准化、多源对齐、质量判断和分层成本路径。

7.3 信息资产

负责 raw artifact、reusable information object、版本、关系、provenance、rights、质量和生命周期沉淀。

7.4 资产输出

负责内部人类产品面、机器查询、feed、bulk、event/push、Adapter、版本、计量和兼容。

7.5 运营管理

负责 source、provider、job、review、authorization、configuration、migration、cost 和 evidence 的观察、控制、审计与恢复。

8. 第一阶段：独立信息产品闭环

第一阶段的主验收不是成功向某个下游推送，而是：

Data Horizon 在不依赖单一认知、执行或外部消费者的前提下，能持续把一个受控信息域转化为可追溯、可质量标记、可检索、可复核、可订阅或可导出的信息产品，并由内部人类和内部机器证明其独立价值。

8.1 Exit / Closure 原则

• Implementation substantial 不等于 Accepted。 代码存在、本地测试通过或生产有流量，只分别升级 Implementation 与 Production evidence；第一阶段验收需要独立的、有边界的 acceptance 证据。
• 第一阶段不要求先完成全市场覆盖、正式 Perception Record schema、统一 scheduler、完整 migration platform 或外部 C 接入；这些是成熟态或后续阶段方向，不是第一阶段 exit gate。
• Closure 的目标是收束范围并关闭已冻结的验收差距，而不是把第一阶段无限扩大成过度设计。

8.2 消费顺序

1. 内部人类：操作员、研究员、质检和管理员完成 source、processing、review、retrieval、quality、cost、recovery 和 export 工作流；
2. 内部机器：使用 consumer-neutral candidate Interface 验证结构化消费、回放和稳定语义；
3. 外部 B：用多个结构不同的 workload 验证 rights、SLA、metering、compatibility 和 portability；具体数量、样本和时间盒由产品验收 Gate 决定；
4. 外部 C：当前未批准；只有 Owner go/no-go 后才进入。

8.3 第一阶段感知切片

第一阶段优先复用当前实践资产，选择一个或多个可控信息域形成闭环。News、macro、KOL/私域、source operations 和 current market-data Interfaces 都是实践输入，不在白皮书中预定哪个消费者或哪组对象为唯一主线。

8.4 收束之后的方向承接

第一阶段收束完成后，战略下一步方向由第二阶段承接：以"看得更广、看得更清楚、看得更快、更容易使用"四项成果组织，覆盖优先级为全球官方披露 / 监管 / 交易所公告、更深的全球宏观与政策、全球事件与外生冲击三类；聚合渠道默认只作发现，重要信息追溯原始发布主体或一手材料；个人向探索仅原型 / 封闭验证。Owner 于同日补充第六项决定：DH 是金融信息感知与情报平台，不是事实核查、真伪裁决或辟谣平台——出处 / 溯源、事实支撑、市场相关性是三个独立维度，追溯提供上下文而非真伪认证，不得作为首次感知与快速交付的前置闸门；对可能实质影响市场的匿名、不确定、有争议或非官方信息按"先感知、后丰富、持续更新"处理，后续的证实、否认、修订与反转作为新的情报进展追加表达。DH 的输出边界不变：发现、组织、关联、标注与交付属于 DH，最终研究结论、Alpha 判断、投资建议、仓位与交易执行属于下游。该方向与本文的独立定位、消费顺序、边界和壁垒完全兼容，详见 第二阶段知识包；第二阶段未启动，本节不构成启动或任何对象 / Interface / 架构冻结。

8.5 最低验收问题

第一阶段至少回答：

• 输入范围、来源和权利是否明确；
• 原始 artifact、来源、时间和处理活动是否可追溯；
• 质量、不确定性、revision 和限制是否可观察；
• 内部人类能否复核、纠错、阻断、恢复和审计；
• 内部机器能否按稳定语义消费、分页/回放且不丢失；
• 输出是否与具体消费者投影分离；
• 运行、成本、失败和迁移证据是否可复核；
• 该价值在移除 Trading Matrix、FinBayes 或任何单一外部消费者之后是否仍然成立。

9. 生态内协同

9.1 与 FinBayes

FinBayes 是内部机器和认知产品候选消费者。Data Horizon 可以提供事件、宏观、市场状态、来源和证据材料；FinBayes 负责解释、研究、条件化判断和反证组织。

当前 macro/crypto 等接口是工程实践和需求证据，不代表 FinBayes 已经定义 DH 产品模型。

9.2 与 AI Trading Matrix

Trading Matrix 是内部机器 validation scene 和 compatibility Adapter。DH 向其提供事件、外部职业信号、市场状态和 evidence；TM 在交易场景中回传消费、验证与执行结果证据；DH 再依据带 context 和 attribution 的反馈改进信息与信号的准确性、及时性和有效性。这是原设计中需要保留并强化的正反馈闭环，不是一次性交付后的附属统计。

跟单、策略蒸馏、回测、PnL、风控和执行属于 Trading Matrix。它们可以成为 DH derived source/signal profile、路由、优先级、标签和产品设计的 contextual improvement evidence，但不能单独定义事实准确性、通用 source quality、information lifecycle 或 core object，也不能使 DH Core 只为单一消费者或 PnL 优化。

TM 回流至少需要关联 consumer/purpose、source/information/signal identifier 与 version、market/asset、strategy/candidate、observation window、适用时间戳、outcome metric、样本/置信限制和 attribution caveat；具体 schema 待 L3 协同评审，不在本文冻结。

同时，战略边界纠偏不得成为破坏既有协同的理由。DH 对 core object、Interface 或内部架构的升级必须通过 versioned contract、compatibility Adapter、双轨迁移、deprecation window 和 consumer regression evidence，确保现有 TM 数据、API、协同链路和流程不降级、不退化、不失效。

9.3 与独立外部 B benchmark cases

独立外部 B 客户只作为匿名 benchmark cases 进入 DH 治理。DH 记录其 workload、时效、rights、SLA、成本、退出和 acceptance evidence，不在 canonical、对象、接口、路线图或 core implementation 中登记客户品牌。

现有 News v1 wire 必须兼容；历史消费者命名的 contract token 只作为隔离的 legacy compatibility debt 保留，不是未来 neutral Interface 的命名先例。DH 可以复用协议、模型、验收和 defect evidence，不复制任何外部客户的品牌、用户、编辑、排序、placement、个性化或商业闭环。

9.4 与 RLE 和 FEFM

当前只保留 readiness-gated 边界。只有真实产品闭环产生稳定反馈、质量样本和授权语料后，才触发进一步协同。

10. To B 与 To C 战略

10.1 To B

To B 是独立闭环之后优先验证的商业方向，因为 DH 的 reusable information products、rights、SLA、metering 和 compatibility 能力天然适合机构或机器消费者。

但 To B readiness 需要：

• 正式对象和 Interface 版本；
• 来源与再分发权利；
• correction/withdrawal/replay；
• 多消费者 portability；
• 质量、延迟、成本、支持和退出机制；
• 不依赖单一客户的 contract evolution。

10.2 To C

DH 自营 To C 当前为 Not approved。未来只有在以下条件满足后才进入 Owner go/no-go：

• 有清晰且独立的用户任务；
• 不克隆现有独立消费者产品；
• 品牌、账户、编辑、个性化和责任边界明确；
• rights、成本、分发和 channel conflict 可治理；
• 不削弱 Perception Core 和 To B 中立性。

在此之前不冻结 Consumer Platform 架构。

11. 当前工程实践的正确位置

截至 2026-08，DH 已有 source health、review gate、source authorization、Provider Config、Cron、KOL、macro、crypto、Open News、Open API、Ops Console 等大量实现。

这些实践的正确处理方式是：

• 符合战略且可验证的能力保留；
• consumer-specific seam 留在 Adapter；
• 对象和状态过深冻结的部分降级为参考候选；
• 生产未验证的能力不写成完成；
• 有真实 drift 的 migration/configuration 问题进入治理；
• 任何新增正式对象、Interface 或架构先走 reference evaluation 和决策。

当前事实以 现有系统与战略映射图 为准；当前与候选清单以 Inventory 为准。

12. 下推治理

12.1 正确下推

战略白皮书只固定 identity、mission、boundaries、value、route 和 governance gates。

系统 / 产品定义承接：

• 第一阶段消费者和任务；
• 独立产品闭环；
• accepted/candidate/not-approved 对象；
• 产品层、Interface 和 Adapter 边界；
• 语义级 identity/lifecycle/rights/quality 要求；
• 验收和非目标。

工程设计再承接 schema、API、状态机、存储、任务、页面和迁移。

12.2 停止线

以下情况必须停止并重新对齐：

• 用一个消费者的 payload 直接定义 core object；
• 用 implementation green 代替 production/acceptance/governance；
• 用 technical authz 代替 rights evidence；
• 用 current table 或 API response 直接命名正式产品对象；
• 绕过已接受的 reference evaluation、Owner direction 或后续 gate 冻结 Interface、schema 或架构；
• 把 To C 设想写成当前产品承诺；
• 把下游 PnL 或交易表现写成 DH 来源质量。

13. 如何判断战略正在成立

Data Horizon 战略成立，不以采集器、模型、页面或 endpoint 数量衡量，而以以下证据衡量：

• 信息身份、来源、版本和权利越来越清楚；
• correction、withdrawal、revision 和 replay 可被表达；
• 内部人类能完成真实运营和复核任务；
• 内部机器能稳定消费且不依赖专属分支；
• 多个消费者共享同一 core 而保持不同产品体验；
• 运行、质量、成本、迁移和交付证据可复核；
• 新市场和新来源可以通过既有能力扩展，而不是复制一套系统；
• 移除任一单一消费者后，DH 的独立产品价值仍然成立。

Changelog / 演化记录

2026-08-31（第二次更新）：§8.4 补记 Owner 第六项决定（信息不确定性与市场影响边界）：DH 不做事实核查 / 真伪裁决；出处、事实支撑、市场相关性三维分离；追溯不作为交付前置；先感知、后丰富、持续更新。战略定位、消费顺序、边界与壁垒不变，本次不改动系统事实地图。

2026-08-31：登记第一阶段收束完成（Phase 1 Closure 判定 PASS；四轴历史与未达标严格指标保留为历史事实，不改写）；§0 阶段读法改为四层（治理收束 / 第一阶段收束完成 / 第二阶段已提议未启动 / 生态登记已按同日接受的 L3 更新）；新增 §8.4 收束之后的方向承接，指向第二阶段知识包（四项成果 + 三类覆盖优先级 + 原始出处追溯 + 个人向原型边界）；原最低验收问题移为 §8.5。战略定位、边界、壁垒与消费顺序不变。

2026-08-27：阶段表述校正与 closure 原则补强。区分项目级 L2 收束（rebaseline、inventories、reference evaluation、D-01..D-13 已完成/接受）与生态登记仍为“参考评估前置”（升级需独立 L3）；当前执行读法明确为 Phase 1 Closure，不等于 Phase 1 Accepted，也不是重启第一阶段；第一阶段章节新增 exit/closure 原则（Implementation substantial ≠ Accepted；第一阶段不要求全市场覆盖、正式 Perception Record schema、统一 scheduler、完整 migration platform 或外部 C）；强化非标准化/半结构化信息为当前差异化重点，结构化信息为必要基础与上下文。战略主线不变，动态工程与生产事实仍以 现有系统与战略映射图 为准。

2026-08-21：起草 canonical rebaseline 候选。保留独立金融信息感知定位、金融感知资产、五大能力域、认知/执行/模型边界、全市场成熟态愿景和成本质量路径；移除 Trading Matrix 单一消费者主线；新增稳定身份、provenance、rights、lifecycle、multi-product portability 作为战略壁垒；明确 Perception Core → Information Products → Interfaces → Adapters → Independent Consumer Products 分层；第一阶段改为独立信息产品闭环并采用 IH → IM → B → C 顺序；外部 B 只以匿名 benchmark case 登记；To B 后置于 readiness，To C 保持 Not approved；既有 TM 兼容性成为演进不变量。

2026-06-01：上一版补充全市场感知版图，并把私域职业信号、突发事件和 Trading Matrix 两类策略牵引写为第一阶段主线。该版本保留在 Git 历史中；其中成熟态视野和职责边界继续保留，单一消费者优先级和过早下推已由本版替代。

2026-05-19 至 2026-05-26：建立项目级战略白皮书，定义金融信息感知、金融感知资产、五大能力域和生态边界。