跳到主要内容

Escalation Packet

状态：基线收束草案 最后更新：2026-05-08 用途：定义项目实践如何向生态层提交需要正式判断、裁决、边界更新或基线更新的问题

1. 本目录定位​

packets/escalation/ 是项目向生态层请求正式判断的入口。

它用于处理项目层已经无法自行消化、不能只靠本地例外解决、并且可能改变生态级事实、项目边界、跨项目接口、风险治理或正式文档口径的问题。

一句话：escalation 是“请求生态层判断应该如何改口径、改边界或改约束”的事项。

2. 什么时候用 escalation​

以下情况应使用 escalation：

  • 现有生态基线无法解释当前项目实践；
  • 项目实践反证了当前顶层判断；
  • 项目实践改变 3 + 2 结构、五层能力链条或某个核心对象的职责边界；
  • 跨项目边界出现正式冲突；
  • 新增能力、输入、输出、接口或协同关系将影响多个项目；
  • 项目实践暴露金融风险、合规风险、用户误导风险或执行治理缺口；
  • 某个 sync 的证据变强、影响扩大或冲突明确，需要升级为正式判断；
  • 某项本地事实应被正式写入 baseline/、registry/、contexts/、projects/*、产品定义、MVP 定义或治理文档；
  • 项目 owner 认为继续局部推进会制造事实漂移、边界漂移或风险责任不清。

3. escalation 不是什么​

escalation 不是：

  • 普通项目状态更新；
  • 个人进度、会议纪要或 backlog 排序；
  • 纯项目内部实现选择；
  • 没有证据、来源或影响范围的模糊抱怨；
  • 用来绕过项目 owner、生态 owner、产品 owner 或正式文档评审的快捷通道；
  • 替代正式文档更新本身的最终产物。

如果事项只是值得生态层知道、登记或观察，但还不需要正式裁决，应先使用 ../sync/README.md。

4. 与 sync 的区别​

类型目的典型问题处理结果
sync让生态层知晓、登记、观察、预备吸收“这件事值得其他项目知道吗？”观察、补证、登记、待吸收
escalation请求生态层正式判断、裁决或更新正式口径“当前事实、边界或约束应该怎么改？”更新正式文档、记录决策、设置临时约束、退回澄清

判断规则：

  • 如果项目仍能按当前基线安全推进，优先 sync；
  • 如果继续推进会改变生态事实或风险责任，使用 escalation；
  • 如果事项已经触及真实执行、授权、资金、账户、链上动作、模型训练或跨项目边界，应优先 escalation；
  • 如果 escalation 被判断证据不足，可以退回 sync 继续观察。

5. 最小结构​

一份最小 escalation 应至少包含：

  • 标题；
  • 日期；
  • 来源项目或来源材料；
  • 提交人 / 责任人；
  • 当前背景；
  • 需要升级的问题；
  • 为什么项目层无法自行解决；
  • 证据或来源链接；
  • 影响的项目、接口、对象和文档；
  • 已尝试的项目层处理；
  • 建议的生态层处理动作；
  • 裁决前的临时下游约束；
  • 期望的决策产物；
  • 需要参与评审的 owner 或相关项目。

6. 建议模板​

# Escalation: <简短标题>

日期：
来源项目 / 材料：
提交人 / 责任人：
当前状态：Draft / Submitted / Accepted / Returned / Resolved

## 1. 当前背景

## 2. 需要升级的问题

## 3. 为什么项目层无法自行解决

## 4. 证据或来源

## 5. 影响范围

受影响项目：
受影响接口 / 对象：
受影响文档：
受影响风险边界：

## 6. 已尝试的项目层处理

## 7. 建议的生态层处理动作

## 8. 裁决前的临时下游约束

## 9. 期望产物

## 10. 需要参与评审的 owner / 项目

该模板是最小协作协议。真实 escalation 可以补充更具体的证据、备选方案、风险等级、决策期限和后续回写清单。

7. 当前典型场景​

7.1 FinClaw 认知边界冲击执行边界​

如果 FinClaw 的产品实践开始要求真实账户、订单、资金、合约、链上动作、自动执行或执行系统调用，应发起 escalation。

当前口径是：

  • FinClaw 可以输出评级、target price、portfolio analysis / optimization、backtesting、strategy suggestions、价格 / 事件 / 风险提醒等认知型决策支持；
  • FinClaw 不应直接触发真实交易执行；
  • 执行链路应由 AI Trading Matrix 或明确授权的执行系统承接。

因此，问题不应被描述成“FinClaw 能不能做投资研究建议”，而应被描述成“某项能力是否已经越过认知边界，进入真实执行或授权执行治理范围”。

7.2 Data Horizon / 数据视界 -> FinClaw 接口需要正式定稿​

如果 Data Horizon / 数据视界 的输出契约已经影响 FinClaw 的核心认知对象、输入 schema、来源质量标准或产品验收边界，应发起 escalation。

典型问题包括：

  • 感知输出是否成为 FinClaw 的正式上游输入对象；
  • 来源可信度、时效、授权和可追溯性如何表达；
  • Data Horizon / 数据视界 输出是否会被误用为确定性金融结论；
  • 双来源输入或第三方输入是否需要进入正式产品定义。

7.3 FinClaw -> AI Trading Matrix 接口需要正式定稿​

如果 FinClaw 输出的策略假设、风险约束、执行前检查点或行动候选已经影响 AI Trading Matrix 的职责边界，应发起 escalation。

典型问题包括：

  • 哪些认知输出可以被下游消费；
  • 哪些输出必须保留为解释、假设或检查点；
  • 何时必须进入用户授权、审计、风控和可回滚治理；
  • 如何防止认知输出被误解为直接交易指令。

7.4 AI Trading Matrix -> Reinforcement Learning Engine 反馈对象改变学习边界​

如果 AI Trading Matrix 产生的执行结果、风控拦截、用户授权 / 拒绝 / 撤销、回测或仿真结果将进入 RLE 学习链路，应发起 escalation。

典型问题包括：

  • 什么算真实反馈对象；
  • 什么只能作为观察记录；
  • 是否允许进入 Learning Asset；
  • 学习结果能否回流影响未来执行支持；
  • 如何避免反馈学习强化高风险或误导性金融行为。

7.5 Reinforcement Learning Engine -> Financial Expert Foundation Model 触发模型能力建设​

如果 RLE 的学习资产、失败案例、评估样本或结果标签被用于触发 FEFM 的训练、微调、评测平台或模型路线决策，应发起 escalation。

典型问题包括：

  • 当前是否真的满足 FEFM readiness；
  • 哪些样本可用于模型能力建设；
  • 样本来源、授权、风险等级、审核状态和可学习范围是否明确；
  • 模型能力反哺 FinClaw、Data Horizon / 数据视界 或 AI Trading Matrix 时如何保留原有职责边界。

8. 生态层收到 escalation 后的可能动作​

生态层收到 escalation 后，可以采取以下动作：

  • 接受 escalation，并更新对应正式文档；
  • 记录新的 decision、change 或 context-scoped ADR；
  • 更新 baseline/、registry/、contexts/ 或受影响的 projects/* 文档；
  • 要求相关项目 owner 共同评审；
  • 要求补充证据、用例、风险分析或接口样例；
  • 设置裁决前的临时下游约束；
  • 将问题拆分为 sync、PRD、issue、协同边界记录或材料吸收任务；
  • 判断其不影响生态层，退回项目层处理；
  • 判断该问题当前不可裁决，并登记为待观察事项。

9. 裁决产物与回写规则​

escalation 不应停留在讨论本身。

被接受后，应明确至少一个回写位置：

  • baseline/03-current-baseline.md；
  • registry/project-registry.md；
  • contexts/ecosystem/CONTEXT.md；
  • 受影响项目的 project-anchor.md、inherited-context.md、current-state.md 或 CONTEXT.md；
  • 产品定义、MVP 定义、协同边界记录、PRD 或 issue；
  • governance/ 下的正式治理文档；
  • 必要时，新的 decision、change 或 ADR。

原 escalation 文档应保留处理结果、裁决日期、回写链接和后续约束。

10. 裁决前的临时约束​

在 escalation 被正式处理前，默认应采用保守约束：

  • 不扩大项目职责边界；
  • 不把本地例外写成生态事实；
  • 不让认知输出直接触发执行；
  • 不让未经治理的反馈进入学习资产或模型训练链路；
  • 不把外部材料、参考仓库或个人判断直接写成正式事实；
  • 不让用户误以为系统已经承担收益保证、专业责任、真实执行或模型能力责任。

如果必须继续推进，应在相关项目文档中标明“待 escalation 裁决”。

11. 当前阶段建议​

当前阶段可先手工维护 escalation 文档，不急于抽象完整 schema。

更重要的是形成纪律：

  • 项目实践一旦证明当前正式口径不够用，就不要在项目内部静默改边界；
  • 先用 escalation 明确问题、证据、影响范围和临时约束；
  • 生态层裁决后，再回写正式文档；
  • 未裁决前，不把本地例外当成生态共识。