跳到主要内容

Data Horizon 2026-08 参考评估与 Owner direction

0. 文档定位​

本文承接：

本文在已接受的 L2 canonical rebaseline 中完成两件事：

  1. 用官方规范、官方数据源和项目官方文档挑战当前实践；
  2. 记录本轮项目级 Owner direction，作为后续战略白皮书和系统 / 产品定义重写的候选边界。

治理状态： 本文已随 L2 canonical rebaseline 获批。D-01 至 D-12 为 Accepted / Owner direction，D-13 为 Accepted operational direction，D-14 继续为 Deferred by Owner。需要改变生态对象注册表、生态阶段或跨项目 Interface 的部分仍须独立 L3。

本文不选择具体技术栈，不冻结 schema/API，不修改生态层 stage 或接口登记。涉及生态对象注册的决定仍需单独 L3 变更。

1. 参考评估方法​

本轮只使用标准组织、官方数据源、商业服务官方文档或开源项目官方文档。每个参考对象只回答特定问题，不把“竞品形态”整体复制给 Data Horizon。

评估维度：

  • identity、version、correction、withdrawal、replay；
  • provenance、rights、quality、review；
  • query、cursor、bulk、event/push 等 delivery modes；
  • internal human operations；
  • provider abstraction 与 consumer-neutral Interface；
  • configuration concurrency；
  • scheduling 与 migration evidence。

2. 信息身份、版本和生命周期​

2.1 参考证据​

  • SEC EDGAR APIs 同时使用 CIK、filing accession、form、filing history、source archive，并提供实时 JSON 与 nightly bulk；说明稳定来源身份、低延迟查询和历史恢复可以并存。
  • CloudEvents v1.0.2 使用 (source, id) 标识一个 transport event occurrence，并把 subject 与 event type 分开；它不替代业务对象身份。
  • Benzinga News API 同时提供 News、Removed News 等面，说明商业新闻交付需要 correction/removal，而不是只有 active snapshot。

2.2 对 DH 的挑战​

当前 News Stream 把 ingest row ID、publication sequence 和 cursor 紧密绑定；active-only 只能隐藏行，不能表达 correction、withdrawal、supersession 或 consumer-visible revision。

2.3 吸收原则​

  1. source record identity、DH canonical identity、publication identity、transport event identity 分离；
  2. replay 的重复 transport event 保留同一 event identity，consumer effect 仍需幂等；
  3. correction、withdrawal、supersession 是一等 lifecycle，不通过静默覆盖或删除表达；
  4. query、cursor、bulk 和 event/push 交付同一 versioned semantic object，而不是各自定义事实。

本文不决定字段或新表。

3. Macro observation 与 vintage​

3.1 参考证据​

ALFRED 保存一个经济数据值在什么 real-time period 内是当时已知值；FRED series observations API 支持按 vintage_dates 或 real-time start/end 查询历史时点所见数据。

3.2 对 DH 的挑战​

当前 dn_macro_calendar 同行承载 release schedule、reference period、actual/previous/revision 和 provider timing。它可以继续作为 current practice，但不能证明 release occurrence、indicator observation 和 vintage 已经建模完成。

3.3 吸收原则​

  1. observation/reference date 与 known-at/vintage time 分开；
  2. retrieval time 是运营证据，不能替代 provider-issued vintage；
  3. provider 不提供 vintage 时必须显式标记 unavailable/unknown，不推断历史时点真值；
  4. 产品定义先写语义和 fallback，不先决定拆表。

4. Provenance、rights 与 evidence tier​

4.1 参考证据​

  • W3C PROV-O 以 Entity、Activity、Agent 表达来源、生成、派生、归属和 revision。
  • W3C ODRL 2.2 将 permission、prohibition、duty、party、asset 和 constraint 建模为独立 policy concerns。
  • SEC original filing、Benzinga editorial/licensed news、GDELT media aggregation 分别代表不同 evidence tier，不能混写成同一种“事实”。

4.2 吸收原则​

最小 provenance trace 应能回答：

  • 原始 artifact 与 source record 是什么；
  • 系统何时、通过什么 acquisition activity 得到；
  • 哪个 parser/rule/model/human activity 产生派生结果；
  • 谁或哪个系统承担该 activity；
  • 该对象与前一版本、来源、修订或撤回的关系。

rights 与 provenance 分离：从某来源取得数据，不代表可以向所有消费者再分发。技术 source authz 也不是 rights/licensing evidence。

5. Delivery modes 与 consumer-neutral Interface​

5.1 参考证据​

  • SEC 同时提供 API、daily index/archive 和 nightly bulk；
  • Benzinga 同时提供 REST、TCP push、incremental query 和 removed news；
  • GDELT DOC 2.0 提供搜索和有限时间窗口，GDELT 2.0 使用约 15 分钟更新的 file lists；
  • OpenAPI 3.1.1 适合描述 HTTP Interface，但不是事实本体；
  • OpenBB architecture 分离 provider connectors、standard models 和 consumer response surface。

5.2 吸收原则​

  1. retrieval、cursor feed、bulk rebuild 和 optional event/push 是 delivery modes；
  2. Interface 必须声明版本、时间语义、pagination/cursor、error/retry、deprecation、entitlement 和 compatibility policy；
  3. provider raw shape、DH reusable object 和 consumer projection 分层；
  4. Trading Matrix、FinBayes 与匿名外部 B cases 只作为 Adapter/consumer，不决定 canonical shape；
  5. 至少使用两个结构不同的 B consumers 或一个内部机器加两个 B workloads 验证 portability。

6. 内部人类运营与 review​

6.1 参考证据​

  • Label Studio review/quality workflow 区分角色、review、quality 和 operation analytics；accept、reject、requeue、remove 等是不同动作。
  • Dagster asset checks 和 observations 将 materialization、observation、quality/freshness check 分开。
  • Airflow assets 使用 logical asset 表达 producer/consumer dependency，但不把 DAG success 当作业务 truth。

6.2 吸收原则​

  1. review decision、reason、evidence、reviewer、time、requeue/escalation 可审计；
  2. ingestion success、quality/review、governance acceptance、delivery success 使用不同状态轴；
  3. orchestrator/job/asset green 只证明运行，不证明信息有效或产品已验收；
  4. 控制台从用户任务设计，不从菜单、表或 API 数量设计。

7. Configuration concurrency​

7.1 参考证据​

7.2 吸收原则​

  1. 对可并发修改的控制面资源使用显式 resource revision 与 conditional write；
  2. patch、replace、command 三类语义不能混用；
  3. nullable business value 与 delete 必须可区分；
  4. arrays 和 nested provider config 的 ownership 要显式；
  5. 条件写只避免 lost update，不替代业务校验、审批和 rollback。

本文不决定采用 JSON Merge Patch 还是 command-specific API。

8. Migration history 与 activation​

8.1 参考证据​

8.2 吸收原则​

DH 的工具中立 migration contract 至少需要：

  • immutable change identity；
  • ordered apply；
  • checksum / drift detection；
  • success/failure history；
  • serialized single writer；
  • preflight、post-readback、rollback/roll-forward 与 exceptional repair 审计。

这不表示已经决定采用 Flyway 或 Liquibase。

9. Scheduling​

RFC 5545 recurrence rules 描述 intended occurrences，也揭示 timezone、DST、invalid dates 等边界；它不描述 job execution、retry 或 idempotency。

DH 应把以下概念分开：schedule definition、scheduled occurrence、execution attempt、result/evidence。后续决策需覆盖 timezone/DST、missed run、overlap、retry、deduplication 和 restart consistency。

10. 明确不吸收的内容​

  • 不把 SEC/GDELT/Benzinga 的对象直接作为 DH schema；
  • 不把 GDELT theme/tone、媒体覆盖量或机器翻译当作已验证金融事实；
  • 不把 OpenBB provider ABI 当作 DH domain model；
  • 不把 Dagster/Airflow asset 或 DAG success 当作信息有效性；
  • 不把 Label Studio UI/权限模型整体复制为 DH control plane；
  • 不因 CloudEvents 支持 envelope identity 就宣称具备 exactly-once；
  • 不因 ODRL policy 可表达就宣称法律权利已验证；
  • 不因 migration tool 有 history table 就忽略 non-transactional DDL 和生产窗口风险。

11. Owner direction register​

以下条目记录本轮 Data Horizon 项目级重基线中已接受的 Owner direction；需要改变生态对象注册表、生态阶段或跨项目 Interface 登记的部分，仍须另走 L3。

ID决策状态边界
D-01第一阶段消费顺序采用 IH → IM → B → C。Accepted / Owner direction是产品验证顺序，不冻结具体对象或 Interface。
D-02第一阶段主验收是 DH 独立信息产品闭环，不依赖单一认知/执行/外部消费者。Accepted / Owner direction现有下游消费只能作为附加证据。
D-03Trading Matrix 在项目层作为内部机器 validation scene 和 compatibility Adapter，不作为 DH 产品主轴。Accepted / Owner direction若写入生态 Interface registry，需单独 L3。
D-04外部 B benchmark customer 只以匿名 case、workload、rights、SLA 和 acceptance evidence 进入 DH canonical；不登记客户品牌或把其产品语义写入 core。Accepted / Owner direction既有 wire compatibility 保留；正式生态 Interface 登记仍需 L3。
D-05Perception Record、Financial Information Feed、Evidence Package、Dataset Package 等继续保持 Candidate。Accepted / Owner directionreference evaluation 前不冻结 schema 或最小字段。
D-06internal reusable information object、external Interface 和 consumer Adapter 必须分层。Accepted / Owner directioncurrent response/table/contract package 不自动提升为 core。
D-07identity、revision、correction、withdrawal、vintage 和 replay 进入下一版产品定义语义要求。Accepted / Owner direction不授权新表、新 endpoint 或 migration。
D-08rights/licensing 按 source、asset、output、purpose/consumer 分层治理；技术 authz 不等于法律权利。Accepted / Owner direction具体 policy/enforcement 仍需后续设计和 legal evidence。
D-09To B 在独立闭环和 consumer-neutral portability 之后作为优先商业验证方向。Accepted / Owner direction不是发布、定价、SLA 或销售承诺。
D-10DH 自营 To C 当前为 Not approved；只有 Owner go/no-go、独立用户任务和 rights/cost gate 满足后才进入。Accepted / Owner direction不建立 Consumer Platform 正式架构，不克隆任何独立外部产品。
D-11DH Core、对象和 Interface 可以演进，但不得使现有 Trading Matrix 数据、API、协同链路或流程降级、退化或失效。Accepted / Owner direction使用 versioned contract、compatibility Adapter、双轨迁移、deprecation window 和 consumer regression tests；破坏性切换需单独批准。
D-12外部消费者需求必须先还原为 DH 平台问题，再从全球金融信息感知、标准化/非标准化信息组织、rights、quality、lifecycle 与多消费者 portability 设计。Accepted / Owner direction禁止 consumer-specific core branch 和单客户补丁成为默认方案。
D-13建议将本轮已完成 DB 变更缺少可恢复历史执行回执的问题保留为 audit residual。Accepted operational direction不重跑已达终态的 DDL/DML；以后以 migration ledger/receipt 补强，而不是倒推或伪造历史证据。
D-14旧凭据轮换与撤销延期，由具备相应权限的责任团队后续处理。Deferred by Owner不把延期写成已完成；当前不阻塞既有 release acceptance，但保留安全风险与责任归属。

11.1 后续 Owner 决定的登记位置（2026-08-31）​

2026-08-31 Owner 就第二阶段方向作出五项决定（四项大白话成果、三类覆盖优先级、聚合渠道仅作发现与原始出处追溯、个人向探索仅原型 / 封闭验证、管理端按用户工作空间重构概念）。这五项决定不修改本文 D-01..D-14 的任何状态；其正文登记在 第二阶段知识包入口，治理载体为 2026-08-31 已接受的 L3 提议《Data Horizon 第二阶段知识治理重基线》；接受仅覆盖知识治理方向，第二阶段启动与实施授权未给出。

11.2 2026-08-31 补充 Owner 决定：信息不确定性与市场影响边界​

Owner 于 2026-08-31 在上述五项之外补充第六项第二阶段决定，同样登记于此，不修改 D-01..D-14 的任何编号、状态或措辞：

Data Horizon 是金融信息感知与情报平台，不是事实核查、真伪裁决、辟谣或谣言治理平台。金融市场中的信息可能匿名、不确定、有争议、带策略意图、事后被修订、被否认或被证实，但在其被表达与传播的当时仍可能实质影响市场。因此：

  • 不得以"找到原始出处"或"完成核实"作为首次感知与快速交付的前置闸门；source/provenance、事实支撑、市场相关性是三个独立维度，不合并为单一 credibility/truth score，也不以任何分数作为发布闸门；
  • 追溯（承接决定 3）提供的是出处与上下文，不是真伪认证；追溯、上下文补充与关系建立在交付之后异步进行；
  • 工作方式为先感知、后丰富、持续更新：证实、否认、修订、反转均为新的情报进展，追加表达，不抹除早先记录及其当时的市场意义；
  • 硬性阻断在概念上限于法律 / 权利限制、涉密与隐私安全暴露、恶意技术内容、滥用与垃圾信息、交付形态不安全；匿名、未经证实、有争议、非官方本身不构成阻断理由；
  • 感知范围显式包含调查性与深度报道、研究与分析观点、另类数据异常、叙事与预期变化、跨市场异常与潜在 Alpha 线索；DH 边界不变：发现、组织、关联、标注与交付属于 DH，最终研究结论、Alpha 判定、投资建议、仓位与交易执行属于下游；
  • 相关审计与核对按比例控制，仅覆盖运营、权利、安全与问责所必需的证据；不设立事实核查专线、真伪评审组织、信息核验工作包、新审计系统或统一记录设计。

本项决定的正文展开位于 第二阶段目标、范围与非目标第 5 节，治理载体与前五项一致（同一份已接受的 L3 提议）；该登记不构成任何对象、schema、评分模型或接口的冻结。

12. 进入战略白皮书重构的输入​

白皮书应继承：

  • DH 独立感知与信息产品定位；
  • IH → IM → B → C 的验证顺序；
  • reusable information object → Interface → Adapter → independent consumer product 的层次；
  • 事实、provenance、rights、quality、lifecycle、cost 的长期壁垒；
  • 多市场成熟态愿景，但不把单一消费者或单一市场需求写成第一阶段主线；
  • reference evaluation、portability proof 和 governance gates 先于正式 object/Interface freeze。

Changelog / 演化记录​

2026-08-31（第二次更新）：新增 §11.2，登记 2026-08-31 补充的第六项 Owner 决定（信息不确定性与市场影响边界：不做事实核查 / 真伪裁决、三维分离、不设单一可信度闸门、先感知后丰富持续更新、硬阻断范围、感知范围与 DH 输出边界、审计按比例）；D-01..D-14 与 §11.1 五项决定的编号、状态与措辞不变。

2026-08-31：新增 §11.1，登记 2026-08-31 五项第二阶段 Owner 决定的正文位置与治理载体；D-01..D-14 状态不变。

2026-08-25：统一治理措辞：D-01 至 D-13 是开放 L2 中的 proposed Owner direction，D-14 为 deferred；在 review approval 前不称为已生效 Owner 决策。

2026-08-21：完成首轮 Data Horizon reference evaluation，覆盖金融披露/新闻/API、身份与事件、macro vintage、provenance/rights、delivery modes、human review、configuration concurrency、migration 与 scheduling；记录 D-01 至 D-14 项目级 Owner direction，并保留所有 L3 生态登记边界。