Failure Card · 6 类失败分类

任何判断在 30/90/365 attribution 阶段被证伪或部分证伪, 自动生成一张 Failure Card, 分类如下:

类型	触发条件	修复方向
fact_failure	输入事实有误	上游事实核查 · Wiki entities 更新
framework_failure	Reasoning 框架错位	修改 SKILL.md 中的 Step 列表
process_failure	流程执行不对	修订 Orchestrator Phase 步骤
scope_failure	议题被错误归类	路由器规则修订
validation_failure	Attribution metric 设计有问题	修订 attribution.checkpoints
handover_failure	决策落地的 owner/deadline 失效	决策模板修订

为什么是 6 类?

6 类对应判断流水线的 6 个可能出错的层:

输入 → [事实]      ← fact_failure
       ↓
       [框架]      ← framework_failure
       ↓
       [流程]      ← process_failure
       ↓
       [归类]      ← scope_failure
       ↓
       [验证]      ← validation_failure
       ↓
输出 → [落地]      ← handover_failure

少一类 → 失败归因被压缩到错的层, 修错地方; 多一类 → 分类决策疲劳, 反而不写。

6 类的判别问题树

问题	答 yes	答 no
输入数据本身就错了吗?	fact_failure	↓
用了不对的 mental model / doctrine?	framework_failure	↓
Phase 0-5 哪一步执行漏了/做错了?	process_failure	↓
议题被路由到错的 panel / mode?	scope_failure	↓
attribution metric 太软, 无法证伪?	validation_failure	↓
决策落地的 owner / deadline 失效?	handover_failure	(没归到任一类, 重新看)

按顺序问, 第一个 yes 就是它。不要一张 Failure Card 同时归 2 类 — 必有一个主因。

自动分类

skills/meta/failure-card-classifier/SKILL.md 由 Haiku 跑分类, attribution_check 检测到 falsified 时自动:

fc = classifier.classify(
  case=case,
  falsified_checkpoint=checkpoint,
  ground_truth=actual_signal,
)
# fc.type ∈ {fact, framework, process, scope, validation, handover}
write_failure_card(fc, path="failure_cards/FC-2026-NNNN.md")

每张 Failure Card 含:

---
fc_id: FC-2026-0001
type: validation_failure         # 6 类之一
case_ref: C-2026-0142
checkpoint_ref: 30d
created_at: 2026-06-29
classifier_version: v0.3
classifier_confidence: 0.82
status: open                      # open | in_review | closed
---

# FC-2026-0001 · 30d verify parser bug
...

怎么从 Failure Card 反推方法论

FC 类型	反推目标
fact_failure ≥ 3 张/月	Wiki entities 数据流断了 → 检查 sage-wiki ingest 与原料采集
framework_failure ≥ 2 张/月	某 SKILL 的 doctrine 该升级 → SKILL.md PR
process_failure ≥ 2 张/月	Orchestrator 流水线某 Phase 缺纪律 → Orchestrator SKILL PR
scope_failure ≥ 3 张/月	议题路由规则需细化 → panels/default.yaml auto-select rules
validation_failure ≥ 2 张/月	attribution 模板太软 → 收紧 falsification_metric SOP
handover_failure ≥ 2 张/月	决策书模板缺 owner 字段 → case-schema 改

scripts/monthly_review.py 每月统计这 6 类分布, 高位类型自动入下月 dev plan。

Failure Card 不是惩罚

Failure Card 是给方法论的反馈信号, 不是给某次判断/某位评委的扣分。

• ✅ "framework_failure: 这次用的 doctrine 不适合 B2B 议题" → SKILL 修订
• ❌ "这个判断错了, 锚点扣 1 分" — 没有这种东西

文化层的设计: 每张 FC 写完后归到 failure_cards/ 公开存档, 在月度复盘里正面提及而非掩盖。30d milestone 通过的同时也会暴露出 framework v0.1 的 parser bug → 写 FC-2026-0001 → skill_lint 5 类质量门加固 → 这是闭环的正向例子。

延伸阅读: 30/90/365 attribution · 5 镜头 · 架构决策记录