Data Horizon 系统 / 产品定义
0. 当前定义状态
本文定义 Data Horizon 当前阶段的产品主体、消费者顺序、独立闭环、产品层次、候选输出、语义要求、协同边界和验收。
治理状态： 本文已通过 L2 canonical rebaseline review，作为当前项目级系统 / 产品定义基线生效。生态登记已于 2026-08-31 经 L3 更新为“第一阶段收束完成 / 第二阶段已提议未启动”；本文不冻结具体对象 schema、API、数据库、页面、目标架构或工程合同，相关下推仍需后续 gate。第一阶段已于 2026-08-31 按 Phase 1 Closure 口径收束完成（收束判定 PASS；四轴历史状态 Governance Partial / Implementation Substantial / Production Partial / Acceptance Not accepted 保留为历史事实，不改写、不倒推为 Accepted）。第二阶段方向已提议、未启动，见 第二阶段知识包；本文的产品语义、层次与非目标在第二阶段作为约束继承，启动前不因方向登记发生变化。
本文承接：
本文不定义数据库字段、API payload、表、状态码、页面清单、微服务、技术栈或排期。旧版对象基数、状态轮廓、存储 ADR 和“一主四辅”结构已归档，不再作为工程合同。
1. 产品定位
Data Horizon 是独立金融信息感知系统和金融信息产品生产系统。
它把公开与受授权的私域信息、实时与历史信息、结构化与非结构化信息，转化为可被内部人类、内部机器和后续外部消费者持续使用的信息产品。
产品价值不依赖 Trading Matrix、FinBayes 或任何单一外部消费者。下游消费可以证明 Interface 和 portability，但不能替代独立产品闭环。
2. 当前阶段产品主体
2.1 第一产品主体
第一阶段直接产品主体是面向 Data Horizon 内部操作员、研究员、质检和管理员的金融信息运营工作空间。
当前 Ops Console、Source Health、Review、Provider Config、Cron、KOL 和其他页面只是实现素材。最终工作空间应按用户任务组织，不按历史菜单组织。
2.2 第一阶段后台能力
支撑第一产品主体的能力包括：
- 来源注册、权利、配置与健康；
- 信息取得、标准化、去重和关联；
- 身份、时间、provenance、质量和生命周期；
- 人工复核、纠错、阻断、恢复和审计；
- 检索、订阅、导出和机器消费；
- 运行、成本、任务、迁移和交付证据。
这些是能力问题，不预先等同模块或系统数量。
3. 消费者顺序
| 顺序 | 消费者类别 | 当前定义 |
|---|---|---|
| 1 | Internal human | 第一阶段主产品用户，完成信息运营、复核、检索、质量和恢复任务。 |
| 2 | Internal machine | 使用候选 consumer-neutral Interface 验证结构化消费、pagination/replay 和稳定语义。 |
| 3 | External B | 在独立闭环后验证 rights、SLA、metering、compatibility 和 portability。 |
| 4 | External C | 当前 Not approved；等待独立 go/no-go。 |
这个顺序是验证和资源约束，不表示先完成全部 IH 才能进行任何 IM/B 实验。已有接口继续兼容，但新增正式定义必须服从该顺序。
4. 第一阶段独立产品闭环
4.1 闭环定义
选择一个或多个受控信息域，持续完成：
闭环成立要求价值在移除任何单一消费者后仍然存在。
4.2 第一阶段信息切片
当前 News、macro、KOL/私域、source operations、Open API 和 market-data pass-through 都是实践候选。第一阶段切片由以下条件共同选择：
- 内部人类任务真实；
- 来源与权利可控；
- 当前实践可复用；
- 质量、时间和生命周期可验证；
- 成本和运行风险可界定；
- 能形成 reusable information product；
- 不被单一消费者 payload 锁定。
本文不把 Trading Matrix 的两类策略、某个外部 B realtime case 或 FinBayes blockers 指定为唯一切片。
5. 产品层次
| 层次 | 负责什么 | 不负责什么 |
|---|---|---|
| Perception Core | identity、time、provenance、rights、quality、lifecycle | 编辑排序、个性化、PnL、消费者专属字段 |
| Reusable Information Products | 把 core 组织成人或机器可消费的信息成果 | 直接等同当前表或 response |
| Interfaces | console、query、feed、bulk、event/push 等交付方式 | 定义事实本体 |
| Consumer Adapters | 把 reusable product 投影为消费者 shape | 反向定义 core |
| Independent Consumer Products | B/C 产品的品牌、用户、编辑、体验和商业闭环 | 把自身产品职责转嫁给 DH |
6. 当前与候选输出
6.1 Current implementation / compatibility assets
| 输出 | 当前状态 | 产品读法 |
|---|---|---|
| Ops、Source Health、Review 等内部视图 | Current implementation | 内部工作流素材，不代表最终 IA。 |
| Open News item/detail | Current implementation | Retrieval/Feed 候选材料，不是正式 To B/C 对象。 |
| News Stream v1 | Compatibility asset | 保持 wire compatibility，不作为未来 Feed 命名或模型先例。 |
| Macro calendar/catalog/latest/release-contract | Current implementation | 宏观实践对象，release/vintage 语义仍未收束。 |
| Crypto read models | Current implementation | request-time pass-through，不是 durable market-data asset。 |
| KOL/profile/signal/TM outputs | Current implementation / compatibility assets | 需拆 generic perception 与 consumer Adapter。 |
| Push/delivery logs | Current implementation | 运行和交付证据，不是核心信息对象。 |
internal/contract seven shapes | Engineering contract | 接受 reference evaluation，不自动成为正式七对象模型。 |
6.2 Candidate outputs
| 候选 | 当前角色 | 冻结状态 |
|---|---|---|
| Perception Record | 单条可追溯金融信息记录候选 | 未冻结 |
| Financial Information Feed | 按多轴组织信息的候选消费面 | 未冻结 |
| Evidence Package | 按需提供完整证据的支撑候选 | 未冻结 |
| Quality/Provenance metadata | 必备问题域和支撑层候选 | 未冻结 |
| Retrieval Result | 检索投影候选 | 未冻结 |
| Dataset Package | 二阶 B/训练/评估候选 | 未冻结，非第一阶段核心 |
候选进入正式定义前必须通过 reference evaluation、current-practice mapping、rights review 和至少两个不同消费任务的适配测试。
7. 核心用户任务
7.1 来源运营
操作员需要知道来源是什么、为何接入、当前权利和限制、健康状态、最近数据、失败原因、处理成本和影响范围，并能安全暂停、恢复、隔离或升级。
7.2 信息复核与纠错
操作员和质检需要查看原始 artifact、处理活动、来源关系、质量限制和输出影响，执行 accept、reject、hold、requeue、correct、withdraw 或 escalate，并留下 reason/evidence/audit。
这些动作是语义候选，不在本文定义状态码。
7.3 检索、追踪与订阅
研究员和内部机器需要按时间、实体、资产、主题、来源、质量、revision 和订阅条件发现信息，并能从结果回到来源和版本。
7.4 Publication 与生命周期
内部机器需要区分新 publication、重复 delivery、correction、withdrawal、supersession 和 replay；不能依赖数据库 row ID 推断全部语义。
7.5 运行与恢复
管理员需要观察 job、source、provider、review、migration、cost 和 delivery evidence；能够判断失败范围、执行有审计的恢复，并验证状态重新稳定。
8. 最低语义要求
以下是产品语义问题，不是字段清单。
8.1 Identity
必须能区分：source record、raw artifact、DH reusable object、publication/version 和 transport event。
8.2 Time
必须按适用场景区分：source-published/observed period、provider vintage/known-at、DH acquired、processed、reviewed、published 和 delivered time。
不是每个对象都必须有所有时间，但缺失和 unavailable 必须可表达。
8.3 Provenance
必须能连接 source entity、acquisition/transform/review activities、responsible agent 和 derived/revision relations。
8.4 Rights
必须知道信息能否被采集、处理、派生、内部使用、外部再分发、训练、导出或展示。技术 authorization 不能替代 rights evidence。
8.5 Quality
必须表达来源级别、完整度、不确定性、处理方式、review status 和适用限制。不得用下游交易收益直接定义事实/抽取准确性或通用信息质量；但应保留带 consumer、purpose、market/asset、strategy、window 和 attribution 的交易场景反馈，用于改进 derived profile、处理优先级、路由、标签、信号方法和时效策略。
8.6 Lifecycle
必须能表达 correction、withdrawal、revision、supersession、expiry 和 replay，并避免通过静默覆盖丢失历史。
9. Interface 定义边界
9.1 Interface 的共同要求
任何正式机器 Interface 至少说明：
- 消费对象和版本；
- 时间和顺序语义；
- pagination/cursor/snapshot/replay；
- error、retry、idempotency 和 deprecation；
- entitlement、rights 和 consumer scope；
- 质量与限制如何随对象传递；
- 计量、成本和支持边界。
- 对既有消费者的 compatibility guarantee、迁移窗口和 regression evidence。
9.2 当前 Interface 的位置
/v1/open/news/stream：现有 compatibility Interface；- generic Open API query：current implementation；
- TM event/KOL/direct push：consumer Adapter；
- webhook/Telegram：delivery adapters；
- MCP、SDK、CLI、bulk/dataset：Candidates；
- 新 availability、SSE、queue：Not approved。
本文不改变已有 v1 wire，也不新增端点。
10. 协同定义
10.1 Trading Matrix
项目层定位为内部机器 validation scene 和 Adapter。DH 向 TM 提供信息、信号和 evidence；TM 在交易场景中回传消费、验证和执行结果 evidence；DH 据此持续提升信息与信号的准确性、及时性和有效性，形成正反馈闭环。TM 可以提出场景、时效、语义、rights、SLA 和验收需求，但不设计 DH 内部对象、表或架构。
反馈至少应能关联 consumer/purpose、source/information/signal identifier 与 version、market/asset、strategy/candidate、observation window、received/consumed/executed/evaluated 等适用时间、outcome metric、样本/置信限制、成本/延迟和 attribution caveat。它可以影响 derived profile、路由、优先级、标签和产品设计，不得静默修改 raw fact、抹去相反 evidence、覆盖 rights/entitlement，或把 DH Core 单目标优化为 TM/PnL。字段级 contract 待跨项目评审，不在本文冻结。
DH 的内部升级不得使现有 TM 数据、API、协同链路或流程降级、退化或失效。任何替换必须提供 versioned contract、compatibility Adapter、双轨迁移、明确 deprecation window 和 TM regression acceptance。
10.2 FinBayes
项目层定位为内部机器和认知产品候选消费者。DH 提供可追溯信息和证据；FinBayes 负责认知组织。
10.3 独立外部 B benchmark cases
项目层只登记匿名 benchmark case：workload、rights、SLA、cost、exit 和 acceptance evidence。现有 News v1 保持兼容；外部客户的品牌、用户、编辑和产品体验不进入 DH canonical 或 core。
10.4 其他外部 B
需要选择至少两个 workload 结构不同的 consumer，验证 Interface portability、rights、SLA 和 exit。
10.5 External C
当前 Not approved。不创建 direct-C contract、账户、编辑、个性化或 Consumer Platform。
11. 横向产品约束
11.1 Cost-quality routing
按规则/解析器、轻量模型、强模型和人工复核分层；每条路径应有适用任务、成本、失败和降级证据。
11.2 Configuration concurrency
控制面资源需要明确 patch、replace、command、resource revision、conditional write、audit 和 rollback。本文不选择 JSON Merge Patch 或具体协议。
11.3 Scheduling
schedule definition、scheduled occurrence、execution attempt 和 result/evidence 分离；timezone、DST、missed run、overlap、retry 和 restart consistency 需要后续定义。
11.4 Migration
目标语义包括 immutable change identity、order、checksum、success/failure history、single writer、preflight、readback 和 exceptional repair audit；本文不选 Flyway/Liquibase。
12. 第一阶段验收
12.1 独立闭环验收
| 维度 | 通过条件 |
|---|---|
| Scope | 受控信息域、来源、权利、时间盒和非目标明确。 |
| Traceability | 抽样对象可回到 source、raw artifact、处理活动和版本。 |
| Human workflow | 内部人类能完成来源运营、复核、纠错、恢复和审计。 |
| Machine consumption | 内部机器能按稳定语义分页/回放，无静默丢失或顺序倒退。 |
| Lifecycle | correction/withdrawal/revision 的语义和最小实践可验证。 |
| Quality | 不确定性、限制和 review state 可见。 |
| Operations | 延迟、失败、成本、migration 和 delivery evidence 可复核。 |
| Independence | 移除任一单一消费者，产品价值仍成立。 |
12.2 外部 B readiness
只有在独立闭环成立后，才以两个异构 workloads 验证：rights、SLA、metering、compatibility、deprecation、support 和 exit。
13. 非目标
当前不做：
- 冻结 Perception Record、Feed、Evidence 或 Dataset schema；
- 新 publication/revision/release-event 表；
- 新 availability、SSE、webhook 或 queue；
- 把所有 job 纳入一个 DB scheduler；
- 选择 migration/configuration/orchestration 工具；
- 把
internal/contract直接宣布为产品模型； - 用 TM、FinBayes 或任一外部客户的 payload 定义 core；
- 以 core 重构或战略纠偏为由破坏既有 TM 数据、API 或协同链路；
- DH 自营 C 产品或 Consumer Platform；
- 最终金融认知、投资建议、交易策略或执行。
14. 后续承接
- Gap Map 按独立闭环、IH/IM/B/C 和语义要求重建；
- Roadmap 每项分开记录 Governance、Implementation、Production、Acceptance 和 next gate；
- Work Package 按 reusable capability 或明确 Adapter 定位；
- 工程设计只能承接已批准对象和语义，未批准项继续作为 experiment；
- plain-language 版本最后从本文和白皮书重新生成。
Changelog / 演化记录
2026-08-31：治理状态更新：第一阶段收束完成（Phase 1 Closure 判定 PASS，历史四轴保留）；登记第二阶段方向已提议未启动，本文语义要求与非目标作为第二阶段约束继承，不作其他改动。
2026-08-27：登记第一阶段四轴（Governance Partial / Implementation Substantial / Production Partial / Acceptance Not accepted）与 Phase 1 Closure 执行读法：收束第一阶段范围、关闭冻结的验收差距清单，不重启 Phase 1、不宣告 Accepted、不启动 Phase 2。
2026-08-21：重写系统 / 产品定义。第一阶段改为独立金融信息产品闭环；产品主体改为内部金融信息运营工作空间；采用 IH → IM → B → C 验证顺序；建立 Perception Core、Reusable Information Products、Interfaces、Consumer Adapters、Independent Consumer Products 分层；current outputs 与 candidates 分离；identity/time/provenance/rights/quality/lifecycle 作为语义要求；TM、FinBayes 与匿名外部 B cases 重新定位为消费者/Adapter；新增既有 TM 兼容性不变量；删除一主四辅、六资产强制分类、对象基数、状态终态、存储切分和 ADR 冻结。