feat: build model library mvp foundation

AGENTS.md

@@ -100,6 +100,7 @@ Every model must eventually have:
 - `one_sentence_definition`
 - `core_question`
 - `core_mechanism`
+- `status`
 - `source_articles`
 - `source_evidence`
 - `input_types`
@@ -184,6 +185,22 @@ Validation should eventually check:
 - Valid regression test model references
 - Required fields
 - Enum values
+- Model/card index drift
+
+Index maintenance should follow:
+
+```text
+incremental update on every model/card/source/test change
++
+full rebuild or full reconciliation at release, handoff, schema migration, batch expansion, or validation drift
+```
+
+Use:
+
+```text
+python scripts\rebuild_indexes.py --write
+python scripts\rebuild_indexes.py --check
+```
 
 Validation output should be written to:
 

README.md

@@ -78,6 +78,8 @@ tests/     Regression cases for model use, misuse, and boundary checks.
 selector/  Rule-based selector configuration and examples.
 scripts/   Local validation and selector demo scripts.
 reports/   Validation reports, extraction notes, and concrete session handoffs.
+knowledge_assets/  Stable long-term reusable knowledge distilled from local project artifacts.
+ccra_review_bundle/  Per-round CCRA review packages; each round must live in its own dated subdirectory.
 ```
 
 ## 7. Data Format
@@ -88,7 +90,7 @@ Markdown files are used for human-readable model cards and documentation.
 
 ## 8. Validation
 
-All model JSON files should eventually pass schema validation.
+All model JSON files should pass the local schema before they are treated as stable.
 
 Validation should check:
 
@@ -98,6 +100,9 @@ Validation should check:
 - Source article references
 - Source evidence references
 - Regression test references
+- Model/card indexes
+- Markdown card required sections
+- Regression case coverage
 
 ## 9. Minimal Selector
 
@@ -135,16 +140,38 @@ See `PROJECTS.md` for the operative cross-repository boundary map, including req
 
 ## 12. Current Status
 
-Initial project setup.
+Foundation repair in progress for:
+
+- QPI
+- Intellectual Archaeology / 思想考古学
+
+Current foundation assets include:
+
+- GPT plan localization protocol.
+- Model extraction rules.
+- Model card contract.
+- Model extraction workflow.
+- JSON schemas for model cards, source articles, source excerpts, regression cases, and indexes.
+- Machine-readable model index.
+- Human-readable card index.
+- Validation scripts for model library contracts and card headings.
+- Source article and source excerpt indexes.
+- Regression cases for model use, boundary behavior, and misuse.
+- Rule-based selector configuration and examples.
+- A standard-library validation script that writes `reports/validation_report.md`.
+- A standard-library index rebuild/check script that writes `reports/index_rebuild_report.md`.
+- ChatGPT handoff rules.
+- Long-term knowledge asset rules and initial `knowledge_assets/` documents.
+
+Current QPI and Intellectual Archaeology model contents pass the local contract and remain `draft` pending product review.
+
+Indexes follow `docs/INDEX_MAINTENANCE_PROTOCOL.md`: every asset change must synchronize `models/model_index.json` and `cards/card_index.md`, and handoff/release points must run a full rebuild or check.
+
+CCRA review packages are archived by round under `ccra_review_bundle/round-NN_YYYY-MM-DD_topic/`. Do not place new review bundle files directly in `ccra_review_bundle/`; create or update the current round directory instead.
 
 ## 13. Next Steps
 
-1. Confirm directory structure.
+1. Review QPI and Intellectual Archaeology content for product correctness.
-2. Confirm schema files.
+2. Review whether the new `knowledge_assets/` package is sufficient for ChatGPT / CCRA reuse.
-3. Add QPI model JSON.
+3. Decide whether to expand to a third core model.
-4. Add Intellectual Archaeology model JSON.
+4. Decide whether extraction, inspection, and stability scoring should become CCPE or skills-vault requests.
-5. Add human-readable model cards.
-6. Add source records and evidence excerpts.
-7. Add regression cases.
-8. Add validation scripts.
-9. Add minimal selector demo.

cards/README.md

@@ -1,10 +1,14 @@
 # Cards
 
-This folder will contain human-readable Markdown model cards.
+This folder contains human-readable Markdown model cards.
 
-The first expected cards are:
+Current draft cards are:
 
-- `qpi.card.md`
+- `qpi.md`
-- `intellectual_archaeology.card.md`
+- `intellectual_archaeology.md`
 
 Model cards should explain model purpose, mechanism, usage boundaries, misuse risks, source traceability, and productization notes.
+
+`card_index.md` is the human-readable model card registry.
+
+Current cards are `draft_pre_contract` until they are repaired against `docs/MODEL_CARD_CONTRACT.md`.

cards/card_index.md

@@ -0,0 +1,6 @@
+# Card Index
+
+| Model ID | 模型名称 | 类型 | 流程位置 | Card | Model JSON | 稳固性 | 回归状态 | 状态 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| intellectual_archaeology | 思想考古学 | deep_modeling_model | deep_analysis | `cards/intellectual_archaeology.md` | `models/intellectual_archaeology.model.json` | B | pending | draft |
+| qpi | QPI 三元定性模型 | routing_model | pre_analysis | `cards/qpi.md` | `models/qpi.model.json` | B | pending | draft |

cards/intellectual_archaeology.md

@@ -0,0 +1,246 @@
+# 思想考古学
+
+## 模型名称
+
+思想考古学
+
+## 模型 ID
+
+`intellectual_archaeology`
+
+## 一句话定义
+
+思想考古学是一种从表层应用逐层下钻到哲学基岩的建模方法，用于发现支撑一个模型或判断的深层假设、核心机理和动态韧性来源。
+
+## 模型类型
+
+`deep_modeling_model`
+
+思想考古学是深度建模模型，不是前置路由模型，也不是轻量执行流程。
+
+## 所在流程位置
+
+`deep_analysis`
+
+通常应在 QPI 或问题价值评估之后调用。
+
+## 来源文章
+
+- `article_intellectual_archaeology_primary_001`: 《建模者的工坊》
+- `article_cognitive_os_synthesis_001`: 《Wantsong认知操作系统》
+
+## 来源证据片段
+
+- `excerpt_ia_primary_definition_001`: 支撑思想考古学的定义。
+- `excerpt_ia_primary_layers_001`: 支撑七层下钻机制。
+- `excerpt_ia_primary_resilience_001`: 支撑动态韧性价值。
+- `excerpt_ia_cognitive_os_minimum_depth_001`: 支撑最小充分下潜原则。
+- `excerpt_ia_primary_validation_001`: 支撑内部自洽不等于现实有效的验证要求。
+
+## 核心问题
+
+当前问题、方案或模型背后，隐藏了哪些更深层的结构性假设？
+
+## 核心机制
+
+思想考古学把待建模对象放入七层深度框架：
+
+1. 应用层
+2. 领域层
+3. 过程层
+4. 目的层
+5. 核心机理层
+6. 人类能力层
+7. 哲学基岩层
+
+每一层都追问上一层的支撑假设。下钻必须遵守最小充分下潜原则：如果继续下潜不再改变判断、路径、验证方式或行动边界，就应该停止。
+
+## 输入类型
+
+- 复杂问题
+- 系统性议题
+- 反复失败的问题
+- 专家隐性知识
+- 认知模型草稿
+- 产品底层逻辑
+- 需要抽取底层假设的业务方案
+
+## 输出类型
+
+- 层级化问题地图
+- 是否应该调用
+- 进入思想考古的理由
+- 建议最大下潜层级
+- 实际分析层级
+- 停止理由
+- 不继续下潜理由
+- 深层假设清单
+- 最小充分下潜层级
+- 模型稳固性判断
+- 需要验证的薄弱环节
+- 后续建模建议
+
+## 适用场景
+
+- QPI 判断问题偏课题或中重型难题。
+- 问题具有高复用价值。
+- 用户希望从文章中抽取模型。
+- 当前解释停留在表层工具或症状。
+- 需要把专家隐性知识显性化。
+- 需要为一个模型寻找更稳固的底层结构。
+- 一个问题反复解决但反复失败。
+
+## 不适用场景
+
+- 当前只是缺少一个事实或材料位置，直接检索即可。
+- 问题属于低风险轻量表达，不值得进入深层建模。
+- 继续下钻不再改变判断、路径、验证方式或行动边界。
+- 用户明确只需要短平快执行，不需要模型化解释。
+- 缺少足够领域材料，无法区分真实底层假设和空泛哲学化表达。
+
+## 调用关键词
+
+- 深层结构
+- 底层逻辑
+- 模型稳不稳
+- 为什么反复失败
+- 问题的根在哪里
+- 沉淀成模型
+- 从文章抽取模型
+- 方法论的基岩
+- 隐性知识
+- 哲学基岩
+
+## 负向触发条件
+
+- 快速回答
+- 不要展开
+- 只查事实
+- 只要执行步骤
+- 不要深入分析
+- 只改文案
+
+## 相关模型
+
+- `qpi`: 通常作为前置路由模型，先判断问题是否值得进入深度建模。
+
+## 冲突模型
+
+- `fast_execution_flow`: 当用户只需要轻量执行或快速产出时，思想考古学不应默认介入。
+
+## 学科底座关联
+
+- 哲学
+- 认识论
+- 系统论
+- 复杂系统
+- 认知心理学
+- 专家知识显性化
+- 因果推理
+- 设计理论
+
+## 常见误用
+
+- 把思想考古学误用为文章摘要或概念堆叠。
+- 为了显得深刻而无限下钻。
+- 把所有轻量问题都拖入七层分析。
+- 只做纵向下潜而缺少横向模型竞争。
+- 用哲学基岩替代现实验证。
+- 下潜后没有回到可行动结论。
+
+## 失败信号
+
+- 分析很深但不能改变判断或行动。
+- 层级之间没有清楚递进关系。
+- 把所有问题都下钻到哲学层。
+- 输出只有抽象概念而没有模型结构。
+- 没有说明应该在哪一层停止。
+- 没有指出需要证据验证的地方。
+
+## 可信度等级
+
+`medium`
+
+思想考古学的定义、七层结构、动态韧性和验证要求都有来源支撑，但七层结构的停止条件仍需要更多跨场景案例校准。
+
+## 稳固性状态
+
+`B`
+
+需要继续稳定化。
+
+## 稳定性评估
+
+- 概念清晰度：中高，模型名称和下钻方向明确。
+- 机制稳定性：中等，七层结构清晰，但层级之间的真实递进关系需要更多案例验证。
+- 边界清晰度：中等，最小充分下潜原则已明确，但执行时容易过度下钻。
+- 来源证据质量：较高，核心定义和七层结构来自原文，停止条件来自综合应用材料。
+- 回归测试表现：pending，已有五条样板用例，尚未扩展到更多领域。
+
+评级理由：纵向下潜机制清晰，适合深度建模，但七层结构和停止条件需要进一步稳定。
+
+下一步稳定化动作：补充不同复杂度问题的下潜深度测试，明确最小充分下潜原则。
+
+## 回归测试状态
+
+`pending`
+
+当前已有五条回归用例：
+
+- `case_ia_positive_deep_modeling_001`
+- `case_ia_positive_resilience_001`
+- `case_ia_boundary_minimum_depth_001`
+- `case_ia_misuse_philosophizing_001`
+- `case_ia_misuse_no_validation_001`
+
+## 示例输入
+
+- “我想把过去文章中的认知模型抽取出来，但不知道这些模型到底稳不稳，应该怎么判断？”
+- “现代人为什么一边渴望连接，一边又渴望逃离连接？”
+
+## 示例输出
+
+- “第一个输入适合下潜到核心机理层，判断文章、模型卡、系统调用、回归测试之间的关系。”
+- “第二个输入可从应用层、评价层、过程层、目的层和人类能力层分析连接与逃离连接的双重机制。”
+
+## 输出契约
+
+输出必须包含：
+
+- `should_call`: `true | false`。
+- `entry_reason`: 为什么值得进入思想考古；不应调用时说明 no-call 原因。
+- `recommended_max_depth`: `application | domain | process | purpose | core_mechanism | human_capability | philosophical_bedrock`。
+- `layers_to_analyze`: 实际需要分析的层级数组。
+- `stop_reason`: 为什么停在这一层。
+- `no_deeper_reason`: 继续下潜不会改变什么。
+- `assumptions_by_layer`: 按七层列出关键假设；未分析层级保留空数组。
+- `validation_needed`: 哪些判断需要现实反馈、数据、专家盲审或红队。
+- `action_implication`: 下潜结果如何改变下一步行动。
+
+## 深度控制
+
+原则：最小充分下潜。
+
+停止条件：
+
+- 已经足以改变决策。
+- 继续下潜不会增加解释力。
+- 缺少证据支撑更深推断。
+- 问题不值得重型建模。
+- 用户当前只需要执行层结果。
+- QPI 未放行中重型难题或课题时，不进入完整思想考古。
+- 如果建议最大下潜层级低于哲学基岩，不得自动展开到哲学基岩。
+
+过度调用警告：思想考古不是所有问题的默认流程，必须先经过问题价值评估和 QPI 定性。
+
+## 产品化建议
+
+思想考古适合作为中重度问题的深层建模模块，不应默认全量调用。
+
+它应该由 QPI、问题复杂度和复用价值共同触发。输出必须回到可验证、可行动的模型结构。
+
+## 版本信息
+
+- version: `0.1`
+- last_updated: `2026-06-16`
+- status: `draft`

cards/qpi.md

@@ -0,0 +1,287 @@
+# QPI 三元定性模型
+
+## 模型名称
+
+QPI 三元定性模型
+
+## 模型 ID
+
+`qpi`
+
+## 一句话定义
+
+QPI 用于判断某个认知主体在特定上下文中，如何将期望—现实落差框定为 Question、Problem、Issue、mixed 或 no-call，并识别其中的上下文缺口、动态演化和误框定风险。
+
+## 模型类型
+
+`routing_model`
+
+QPI 是前置路由模型，不是最终分析模型。
+
+## 所在流程位置
+
+`pre_analysis`
+
+它应在深度分析、系统建模或执行拆解之前调用。
+
+## 来源文章
+
+- `article_qpi_primary_001`: 《问题之锚：从混沌现实到认知秩序的重构》
+- `article_qpi_contextual_2025_001`: 《解构“问题”：认知主体与现实映射的动态框架》
+- `article_cognitive_os_synthesis_001`: 《Wantsong认知操作系统》
+
+## 来源证据片段
+
+- `excerpt_qpi_primary_spectrum_001`: 支撑 QPI 的三元分类和核心匮乏物定义。
+- `excerpt_qpi_primary_question_001`: 支撑提问对应数据匮乏。
+- `excerpt_qpi_primary_problem_001`: 支撑难题对应路径、方法和资源匮乏。
+- `excerpt_qpi_primary_issue_001`: 支撑课题对应动态平衡和演化。
+- `excerpt_qpi_primary_pathology_reduction_001`: 支撑暴力降维误用识别。
+- `excerpt_qpi_primary_pathology_inflation_001`: 支撑恶意升维误用识别。
+- `excerpt_qpi_contextual_subjectivity_001`: 支撑 QPI 必须基于主体和上下文场景判断。
+- `excerpt_qpi_contextual_gap_001`: 支撑问题作为期望—现实落差的定义。
+- `excerpt_qpi_contextual_dynamic_001`: 支撑问题框架会随时间和新信息演化。
+- `excerpt_qpi_cognitive_os_application_001`: 支撑 QPI 在问题定义阶段的应用位置。
+
+## 核心问题
+
+谁在什么场景下，把什么期望—现实落差框定成了哪类问题；这个框定是否缺上下文、正在演化或存在误框定风险？
+
+## 核心机制
+
+QPI 先执行 no-call gate，再确认主体位置、场景上下文、责任范围、经验水平、问题拥有者、来源和时间尺度。
+
+如果缺少主体或场景，QPI 只能输出 provisional classification，不能高置信定性。此时必须给出 `missing_context`、`evidence_gap` 和澄清问题。
+
+- 缺数据，归为提问，适合搜索、检索、自动化。
+- 缺路径、方法或资源，归为难题，适合工程求解和资源调配。
+- 缺共识、确定性或动态秩序，归为课题，适合对话、博弈、干预和演化。
+
+完成分类后，还要检查是否存在暴力降维、恶意升维、手段错配、工具解法主义或过早定性。
+
+QPI 必须区分：
+
+- `intra_frame_mixed`: 同一主体、同一场景、同一阶段内，多类匮乏物同时存在。
+- `inter_viewpoint_divergence`: 同一句输入在不同主体、责任位置或时间尺度下会被框定成不同 QPI 类型。
+
+## 输入类型
+
+- 模糊问题
+- 复杂问题
+- 业务问题描述
+- 组织冲突叙述
+- 需求或故障初始表述
+- 需要进入深度分析前的问题定义
+
+## 输出类型
+
+- 问题类型判断
+- 分类作用域
+- 是否临时判断
+- 主体位置
+- 场景上下文
+- 责任范围
+- 经验水平
+- 问题拥有者
+- 问题来源
+- 时间尺度
+- 期望现实落差
+- 上下文充足度
+- 缺失上下文
+- 三类匮乏物强度
+- 主导匮乏物
+- 分类理由
+- 分类置信度
+- 多视角分类
+- 动态阶段
+- 可能演化轨迹
+- 成功标准稳定性
+- 硬反馈可用性
+- 治理负荷
+- 澄清问题
+- 证据缺口
+- 核心匮乏物判断
+- 误判风险
+- 推荐处理路径
+- 后续模型调用建议
+
+## 适用场景
+
+- 用户输入的问题定义不清。
+- 同一问题被不同主体以不同方式理解。
+- 用户急于求解但尚未判断问题性质。
+- 问题中混杂事实、路径、利益、共识和系统结构。
+- 需要决定后续调用哪些认知模型。
+- 怀疑存在暴力降维、恶意升维或手段与目标错配。
+
+## 不适用场景
+
+- 用户只是查询明确事实。
+- 用户已经给出明确执行任务。
+- 输入是纯创意写作且不需要问题定性。
+- 问题已经被清楚分类且只需要执行后续步骤。
+- 输入不是问题定义，而是纯粹的润色或格式转换请求。
+
+## 调用关键词
+
+- 问题到底是什么
+- 为什么解决不了
+- 卡在哪里
+- 技术问题还是组织问题
+- 方向是不是错了
+- 为什么反复出现
+- 该怎么定义这个问题
+- 这个问题怎么拆
+- 缺数据
+- 缺路径
+- 缺共识
+
+## 负向触发条件
+
+- 请直接查询
+- 请直接改写
+- 只要清单
+- 不要分析原因
+- 不要展开
+- 只改错别字
+
+## 相关模型
+
+- `intellectual_archaeology`: 当 QPI 判断问题偏中重型难题或课题时，可进入思想考古做深度建模。
+
+## 冲突模型
+
+无明确冲突模型。
+
+## 学科底座关联
+
+- 问题定义理论
+- 决策科学
+- 系统论
+- 复杂系统
+- 组织行为
+- 工程问题分解
+
+## 常见误用
+
+- 把 QPI 当作完整解决方案，而不是问题定义和路由模型。
+- 把所有复杂叙事都归为课题，逃避可执行的难题拆解。
+- 把系统性课题暴力压缩成个人执行难题。
+- 把具体可解决的难题恶意升维成不可处理的课题。
+- 在事实缺口上过度建模，拖慢本应直接检索的提问。
+- 忽略问题拥有者，直接给出单一视角的分类。
+- 把缺少主体和场景的复杂短句直接判成高置信 Q/P/I。
+- 把跨主体视角分歧误写成同一主体内的 mixed。
+
+## 失败信号
+
+- 核心匮乏物识别错误，导致后续资源配置错位。
+- 未识别权力叙事，接受了伪问题或甩锅框架。
+- 把动态平衡型课题误判为可终结的难题。
+- 把明确工程障碍误判为需要无限讨论的课题。
+- 分类没有给出理由。
+- 分类之后没有给出后续处理路径。
+- 缺少 `subject_position` 或 `scenario_context` 时仍输出 high confidence。
+- 只按表层关键词定性，忽略责任范围、成功标准、硬反馈和治理负荷。
+
+## 可信度等级
+
+`medium`
+
+QPI 的三分结构、核心匮乏物、主体性和动态性有清晰来源支撑，但真实输入中经常出现上下文不足、多视角分歧和同一主体内的 Q/P/I 混合状态，仍需要更多边界案例稳定判断。
+
+## 稳固性状态
+
+`B`
+
+需要继续稳定化。
+
+## 稳定性评估
+
+- 概念清晰度：较高，提问、难题、课题的核心匮乏物清楚。
+- 机制稳定性：中高，扫描匮乏物和匹配处理范式的机制明确。
+- 边界清晰度：中等，混合型问题、多视角分歧和上下文不足场景仍需更多测试。
+- 来源证据质量：较高，主体性和动态性来自 2025 原文，核心匮乏物和误框定规则来自 2026 原文，应用规则来自综合文档。
+- 回归测试表现：pending，已有五条样板用例，尚未经过真实案例扩展。
+
+评级理由：三分结构清晰，适合作为入口路由模型，但需要补充大量边界案例，防止过度升维或降维。
+
+下一步稳定化动作：补充主体-上下文-动态案例、混合问题、误用问题和轻量问题测试，并记录主导匮乏物与多视角分歧判断标准。
+
+## 回归测试状态
+
+`pending`
+
+当前已有五条回归用例：
+
+- `case_qpi_positive_question_001`
+- `case_qpi_positive_problem_001`
+- `case_qpi_positive_issue_001`
+- `case_qpi_boundary_mixed_001`
+- `case_qpi_misuse_inflation_001`
+
+## 示例输入
+
+- “我们团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？”
+- “我知道要做模型库，但不知道先用数据库还是文件系统，这属于什么问题？”
+
+## 示例输出
+
+- “第一个输入更接近课题，因为它涉及激励结构、时间尺度冲突和组织共识。”
+- “第二个输入更接近难题，因为目标明确，主要缺的是实现路径和技术取舍。”
+
+## 输出契约
+
+输出必须包含：
+
+- `problem_owner`: 谁的问题；未知时写 `unknown`。
+- `classification_scope`: `subject_contextual | multi_perspective | insufficient_context | no_call`。
+- `is_provisional`: 缺少主体或场景时必须为 `true`。
+- `subject_position`: 当前认知主体的位置；未知时写 `unknown`。
+- `scenario_context`: 问题发生的场景；未知时写 `unknown`。
+- `responsibility_scope`: 个体学习、团队执行、跨职能治理、owner 治理或 `unknown`。
+- `context_sufficiency`: `high | medium | low`。
+- `missing_context`: 缺少哪些主体、场景、目标、资源、责任或时间信息。
+- `problem_source`: 问题从哪里被提出，是否可能带有立场、恐惧或甩锅框架。
+- `time_scale`: `short_term | mid_term | long_term | mixed | unknown`。
+- `expectation_reality_gap`: expected、reality、gap_summary；未知时写 `unknown`。
+- `scarcity_profile`: 分别标出 `data_scarcity`、`path_or_resource_scarcity`、`consensus_or_order_scarcity` 的强度。
+- `dominant_scarcity`: `data | path_resource | consensus_order | mixed | unknown`。
+- `classification`: `question | problem | issue | mixed | no_call`。
+- `classification_confidence`: `high | medium | low`。
+- `classification_by_viewpoint`: 多视角分歧时列出不同主体下的分类和理由。
+- `dynamic_stage`: `initial | evolving | recurring | stabilized | unknown`。
+- `possible_trajectory`: 问题可能从 Q 到 P、从 P 到 I，或反向收敛。
+- `success_criteria_stability`: `stable | unstable | contested | unknown`。
+- `hard_feedback_availability`: `high | medium | low | unknown`。
+- `governance_load`: `high | medium | low | unknown`。
+- `evidence_gap`: 还缺哪些信息才能稳定判断；mixed 或 low confidence 时必须填写。
+- `misclassification_risk`: 暴力降维、恶意升维或手段错配风险。
+- `recommended_clarifying_questions`: 上下文不足时必须给出需要补问的问题。
+- `recommended_next_step`: 检索、工程拆解、共识协调、补充上下文或不调用。
+- `next_model_candidates`: 后续可调用模型 ID。
+
+## 深度控制
+
+原则：先定性，再决定是否进入深层模型。
+
+停止条件：
+
+- 如果只是明确事实查询，停止在提问层并建议检索。
+- 如果已明确是执行任务，停止继续路由。
+- 如果分类证据不足，先输出 `evidence_gap` 并要求补充上下文。
+- 如果负向触发命中且没有复杂问题信号，输出 `classification=no_call`。
+
+过度调用警告：QPI 是前置路由模型，不应替代后续具体分析模型。
+
+## 产品化建议
+
+QPI 应作为问题回答系统的前置路由模型，用于防止系统在问题类型错误的情况下直接给答案。
+
+selector 应优先使用 `trigger_keywords`、`negative_triggers`、`pipeline_position` 和 `selection_priority` 做规则推荐。
+
+## 版本信息
+
+- version: `0.1`
+- last_updated: `2026-06-16`
+- status: `draft`

ccra_review_bundle/round-02_2026-06-16_second-audit/00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md

@@ -0,0 +1,67 @@
+# CCRA Review Brief
+
+## 1. 本轮目标
+
+把 QPI 和思想考古从“工程可运行”推进到“内容可审查、证据可追溯、误用可测试、selector 可防误召回”。
+
+## 2. 本轮依据文件
+
+- `2026-06-16-核心模型抽取样板 v0.1.md`
+- `CCRA_Codex指导意见_Index更新策略与下一轮执行_v0.2_2026-06-16.md`
+- `CCRA_Codex指导意见_模型库MVP第二轮内容稳定化_v0.3_2026-06-16.md`
+- `CCRA_下一轮审核包压缩上传协议_v0.1_2026-06-16.md`
+
+## 3. 本轮禁止事项
+
+- 不扩展第三模型
+- 不接完整问题回答系统
+- 不引入 LLM selector
+- 不升级 stable，除非 CCRA 明确批准
+
+## 4. 当前状态摘要
+
+| Model ID | Status | Stability | Regression Status | Regression Count | Evidence Count |
+| --- | --- | --- | --- | ---: | ---: |
+| `qpi` | draft | B | pending | 17 | 7 |
+| `intellectual_archaeology` | draft | B | pending | 17 | 5 |
+
+## 5. 本轮完成事项
+
+- 新增内容稳定化协议。
+- 建立字段级 evidence coverage matrix。
+- 修复 source excerpt 的 quote_status / source_location。
+- 强化 QPI 输出契约。
+- 强化思想考古停止门。
+- 每模型 regression cases 扩展到 17 条。
+- selector 升级到 v0.2 规则版，增加 no-call、negative trigger、QPI-before-IA gate、rejected reasons。
+- 新增 selector regression 与 JSON/Markdown sync checks。
+- 生成压缩审核包 `ccra_review_bundle/`。
+
+## 6. 本轮未完成事项
+
+- 未升级 stable：按用户和 CCRA 明确约束保持 draft。
+- 未扩展第三模型：按用户和 CCRA 明确约束继续阻塞。
+- 未引入 LLM selector：selector v0.2 仍为规则系统。
+- 未接完整问题回答系统：属于本轮非目标。
+
+## 7. Codex 自我判断
+
+工程验证已通过；内容已经从“能跑通”推进到“可审查”。但内容质量、模型边界、回归用例真实性、selector 阈值仍需要 CCRA / Owner 审核。当前建议保持 `draft / B / pending`。
+
+## 8. 请求 CCRA 审核的问题
+
+1. QPI mixed case 的主导匮乏物仲裁是否足够。
+2. QPI 输出契约中的 `problem_owner`、`time_scale`、`dominant_scarcity`、`evidence_gap` 是否应进入 schema required。
+3. 思想考古 `recommended_max_depth`、`stop_reason`、`no_deeper_reason` 是否应进入 schema required。
+4. selector v0.2 是否仍有误召回风险。
+5. 是否允许进入下一阶段；默认仍不建议扩第三模型。
+
+## 9. 文件清单
+
+| Bundle File | Contains | Why Needed |
+| --- | --- | --- |
+| `00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md` | 审核入口、当前状态、请求审核问题 | 新会话第一屏读取 |
+| `01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md` | 三份指导合并、优先级、compliance matrix | 替代分散上传指导文件 |
+| `02_CURRENT_ASSET_PACK.md` | 当前关键资产内容和 SHA256 | 替代 10-15 个分散资产文件 |
+| `03_REPORTS_DIFF_AND_COMMAND_LOG.md` | 报告、diff、命令日志、open questions | 替代临时报告文件 |
+| `optional_raw_changed_files.zip` | changed/new 原始文件备份 | CCRA 指定原文时再用 |

ccra_review_bundle/round-02_2026-06-16_second-audit/BUNDLE_FILE_MANIFEST.md

@@ -0,0 +1,9 @@
+# CCRA Review Bundle Manifest
+
+| File | Size Bytes | SHA256 |
+| --- | ---: | --- |
+| `00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md` | 3079 | `b9ad46ac23fe93e466ef55b4631daa4593a2158b1aaf30f432a962e4b4600c63` |
+| `01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md` | 103648 | `a667f70aa7652ede151cfacbb907f67c7853647c0f846615e766e6e6e3e6223a` |
+| `02_CURRENT_ASSET_PACK.md` | 113495 | `228f1fbd143c8f592e74d7ba9a60ec622a5d08487a43bb051f82ed517425a0a6` |
+| `03_REPORTS_DIFF_AND_COMMAND_LOG.md` | 31018 | `ecccc2fa106c4e2e5db7a83448a334369e009a34f20b79d7a125c959251143df` |
+| `optional_raw_changed_files.zip` | 116961 | `84ad50d10e47eeba65aa73078d4bdfbc013c3ec0b4ea52d866833842eb2ff8d7` |

ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md

@@ -0,0 +1,93 @@
+# CCRA Review Brief: Round 03 Contract Hardening and Selector Calibration
+
+Date: 2026-06-17
+
+Repository: `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong`
+
+Phase: `model_library_mvp`
+
+## 1. Default Conclusion
+
+This round does not upgrade model lifecycle state.
+
+Current model states remain:
+
+| Model ID | Status | Stability | Regression Status |
+| --- | --- | --- | --- |
+| `qpi` | draft | B | pending |
+| `intellectual_archaeology` | draft | B | pending |
+
+Allowed review conclusion: `draft-callable` as report-level language only.
+
+Not allowed:
+
+- stable upgrade;
+- third model expansion;
+- full question-answering system;
+- LLM selector;
+- database, vector database, full RAG, frontend, backend service, or user account system.
+
+## 2. What Changed
+
+Round 03 hardened second-round risks:
+
+- `ccra_review_bundle/` is now a per-round archive root.
+- QPI source structure now includes the 2025 contextual article as a live source, not an obsolete predecessor.
+- QPI definition and runtime output contract now reflect subject, context, expectation-reality gap, dynamic stage, multi-perspective divergence, and governance load.
+- `schemas/model_card.schema.json` now allows `structured_output_contract` without making model-specific fields globally required.
+- `scripts/validate_model_library.py` now enforces model-specific structured output contract fields for QPI and Intellectual Archaeology.
+- `selector/selector_rules.json` is now the runtime source for selector scoring, no-call gates, signal lists, and weights.
+- `scripts/run_selector_demo.py` no longer owns hard-coded primary selector rules.
+- hard no-call signals now block fact lookup, rewrite, translation, and direct execution unless the user explicitly asks for deeper analysis.
+- `selector/selector_calibration_inputs.json` adds 20 draft calibration inputs.
+- QPI and IA rule docs were added.
+
+## 3. QPI Scope Boundary
+
+QPI is now treated as a subject-context-dynamic routing model:
+
+```text
+某个认知主体
+在某个场景
+基于知识结构、责任位置、目标、资源和时间压力
+把期望—现实落差
+框定成 Q / P / I / mixed / no-call
+```
+
+Owner raw QPI cases have not yet been processed. The calibration file is a draft selector calibration set, not a replacement for owner-provided raw case materials.
+
+## 4. Verification Summary
+
+Fresh checks run in this round:
+
+```powershell
+python scripts\rebuild_indexes.py --check
+python -m unittest discover -s tests -p "test*.py" -v
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+python scripts\run_selector_demo.py
+python scripts\run_selector_regression.py
+python scripts\check_model_card_sync.py
+```
+
+Results:
+
+- Index check: PASS
+- Unit tests: PASS, 15 tests
+- Card contract: PASS
+- Model library validation: PASS
+- Selector demo: PASS; selected `qpi`, rejected `intellectual_archaeology`
+- Selector regression: PASS
+- Model/card sync: PASS
+
+## 5. Review Focus
+
+CCRA / Owner should review:
+
+- Whether QPI v0.3 contextual routing fields are the right required runtime output layer.
+- Whether `classification_scope`, `is_provisional`, `context_sufficiency`, and `missing_context` sufficiently prevent false high-confidence QPI classification.
+- Whether `intra_frame_mixed` and `inter_viewpoint_divergence` are correctly separated.
+- Whether the Issue-as-governance-load rule is accepted.
+- Whether selector hard no-call signals are too broad or too narrow.
+- Whether owner raw case preprocessing should later be routed to `skills-vault` as a reusable Skill.
+

ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md

@@ -0,0 +1,96 @@
+# Guidance Pack and Compliance Matrix
+
+## 1. Input Guidance
+
+Round 03 implements the Owner/GPT instruction:
+
+- do not add a third model;
+- do not upgrade stable;
+- do not build a full answer system;
+- do not introduce an LLM selector;
+- harden model-specific output contracts;
+- make selector rules executable, not documentary;
+- upgrade QPI from text classification to subject-context-dynamic routing;
+- defer owner raw case preprocessing until materials are available.
+
+## 2. Compliance Matrix
+
+| Requirement | Status | Evidence |
+| --- | --- | --- |
+| Per-round CCRA bundle directory | Done | `ccra_review_bundle/round-02_...`, `round-03_...` |
+| Preserve second-round bundle | Done | Existing flat files moved under `round-02_2026-06-16_second-audit/` |
+| Add `structured_output_contract` to schema properties | Done | `schemas/model_card.schema.json` |
+| Do not make QPI/IA fields global top-level required | Done | schema allows object; validator does model-specific checks |
+| QPI required runtime fields | Done | `models/qpi.model.json`, `scripts/validate_model_library.py` |
+| IA required runtime fields | Done | `models/intellectual_archaeology.model.json`, `scripts/validate_model_library.py` |
+| Fix QPI report missing `classification` | Done | `reports/content_review_report_v0.2.md` |
+| Add QPI contextual routing rules | Done | `docs/QPI_CONTEXTUAL_ROUTING_RULES.md` |
+| Add IA depth gate rules | Done | `docs/INTELLECTUAL_ARCHAEOLOGY_DEPTH_GATE.md` |
+| Make selector rules executable source | Done | `selector/selector_rules.json`, `scripts/run_selector_demo.py` |
+| Hard no-call gate | Done | `selector/selector_rules.json`, `scripts/run_selector_demo.py` |
+| Add selector calibration inputs | Done | `selector/selector_calibration_inputs.json` |
+| Keep models `draft / B / pending` | Done | `models/model_index.json` |
+| Defer owner raw sample processing | Done | documented in QPI rules and calibration notes |
+
+## 3. QPI Contract Delta
+
+New or hardened QPI output fields include:
+
+- `classification_scope`
+- `is_provisional`
+- `subject_position`
+- `scenario_context`
+- `responsibility_scope`
+- `context_sufficiency`
+- `missing_context`
+- `expectation_reality_gap`
+- `success_criteria_stability`
+- `hard_feedback_availability`
+- `governance_load`
+- `dynamic_stage`
+- `possible_trajectory`
+- `classification_by_viewpoint`
+- `frame_shift_risk` as a documented risk concept through `misclassification_risk`
+
+Required runtime fields enforced by validator:
+
+- `classification_scope`
+- `is_provisional`
+- `subject_position`
+- `scenario_context`
+- `responsibility_scope`
+- `context_sufficiency`
+- `missing_context`
+- `problem_owner`
+- `problem_source`
+- `time_scale`
+- `scarcity_profile`
+- `dominant_scarcity`
+- `classification`
+- `classification_confidence`
+- `evidence_gap`
+- `misclassification_risk`
+- `recommended_next_step`
+- `next_model_candidates`
+
+## 4. Selector Delta
+
+`selector/selector_rules.json` now contains:
+
+- hard no-call signals;
+- explicit analysis override phrases;
+- complexity signals;
+- QPI gate signals;
+- IA heavy-depth signals;
+- scoring weights;
+- per-model base score and trigger lists.
+
+`scripts/run_selector_demo.py` reads that file at runtime.
+
+## 5. Known Limits
+
+- Calibration inputs are draft and not owner-supplied real cases.
+- QPI raw case preprocessing is deferred until owner materials arrive.
+- `frame_shift_risk` is represented through `misclassification_risk`; it can become a separate required field later if Owner/CCRA wants a stricter contract.
+- Selector calibration is still rule-based and local; it is not evidence of stable selector behavior in the wild.
+

ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/02_CURRENT_ASSET_PACK.md

@@ -0,0 +1,60 @@
+# Current Asset Pack
+
+## 1. Core Model Assets
+
+- `models/qpi.model.json`
+- `models/intellectual_archaeology.model.json`
+- `cards/qpi.md`
+- `cards/intellectual_archaeology.md`
+- `models/model_index.json`
+- `cards/card_index.md`
+
+## 2. Contract and Rule Assets
+
+- `schemas/model_card.schema.json`
+- `docs/DATA_CONTRACT.md`
+- `docs/QPI_CONTEXTUAL_ROUTING_RULES.md`
+- `docs/INTELLECTUAL_ARCHAEOLOGY_DEPTH_GATE.md`
+- `docs/DECISIONS.md`
+- `knowledge_assets/08_CCRA模型库MVP质量门与交接协议.md`
+
+## 3. Source and Evidence Assets
+
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+- `sources/evidence_coverage.matrix.json`
+
+New QPI source:
+
+- `article_qpi_contextual_2025_001`
+
+New QPI evidence excerpts:
+
+- `excerpt_qpi_contextual_subjectivity_001`
+- `excerpt_qpi_contextual_gap_001`
+- `excerpt_qpi_contextual_dynamic_001`
+
+## 4. Selector Assets
+
+- `selector/selector_rules.json`
+- `selector/selector_examples.json`
+- `selector/selector_calibration_inputs.json`
+- `scripts/run_selector_demo.py`
+- `scripts/run_selector_regression.py`
+
+## 5. Validation Assets
+
+- `scripts/validate_model_library.py`
+- `scripts/check_card_contract.py`
+- `scripts/check_model_card_sync.py`
+- `scripts/rebuild_indexes.py`
+- `tests/test_validate_model_library.py`
+- `reports/validation_report.md`
+- `reports/index_rebuild_report.md`
+- `reports/model_card_sync_report_v0.2.md`
+- `reports/selector_regression_report_v0.2.md`
+
+## 6. Deferred Owner Input
+
+Owner raw QPI case materials are not yet included. The expected future raw-case format is documented in `docs/QPI_CONTEXTUAL_ROUTING_RULES.md`.
+

ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/03_REPORTS_DIFF_AND_COMMAND_LOG.md

@@ -0,0 +1,85 @@
+# Reports Diff and Command Log
+
+## 1. Fresh Verification Commands
+
+```powershell
+python scripts\rebuild_indexes.py --check
+python -m unittest discover -s tests -p "test*.py" -v
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+python scripts\run_selector_demo.py
+python scripts\run_selector_regression.py
+python scripts\check_model_card_sync.py
+```
+
+## 2. Results
+
+- `python scripts\rebuild_indexes.py --check`: PASS
+- `python -m unittest discover -s tests -p "test*.py" -v`: PASS, 15 tests
+- `python scripts\check_card_contract.py`: PASS
+- `python scripts\validate_model_library.py`: PASS
+- `python scripts\run_selector_demo.py`: PASS; selected `qpi`, rejected `intellectual_archaeology`
+- `python scripts\run_selector_regression.py`: PASS
+- `python scripts\check_model_card_sync.py`: PASS
+
+## 3. Important Implementation Notes
+
+During selector verification, the first `run_selector_demo.py` run selected `intellectual_archaeology` for a general complex QPI example. This exposed that IA could still cross the threshold without a heavy-depth signal. The selector config was adjusted:
+
+- `selector_rules.json` IA `base_score` reduced from 35 to 30.
+- `ia_no_heavy_gate_penalty` increased from 0.2 to 0.35.
+
+During selector regression, `case_ia_no_call_fact_001` initially selected `qpi` for a fact lookup phrase. The hard no-call signal list was updated with:
+
+- `只是想知道`
+- `有没有提到`
+
+After these changes, selector regression passed.
+
+## 4. Changed File Groups
+
+Review bundle structure:
+
+- `ccra_review_bundle/round-02_2026-06-16_second-audit/`
+- `ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/`
+
+QPI contextual hardening:
+
+- `models/qpi.model.json`
+- `cards/qpi.md`
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+- `docs/QPI_CONTEXTUAL_ROUTING_RULES.md`
+
+IA depth gate:
+
+- `docs/INTELLECTUAL_ARCHAEOLOGY_DEPTH_GATE.md`
+
+Contracts and validation:
+
+- `schemas/model_card.schema.json`
+- `scripts/validate_model_library.py`
+- `tests/test_validate_model_library.py`
+- `docs/DATA_CONTRACT.md`
+
+Selector:
+
+- `selector/selector_rules.json`
+- `selector/selector_calibration_inputs.json`
+- `scripts/run_selector_demo.py`
+
+Reports and docs:
+
+- `reports/content_review_report_v0.2.md`
+- `reports/validation_report.md`
+- `reports/index_rebuild_report.md`
+- `reports/model_card_sync_report_v0.2.md`
+- `reports/selector_regression_report_v0.2.md`
+- `README.md`
+- `docs/DECISIONS.md`
+- `knowledge_assets/08_CCRA模型库MVP质量门与交接协议.md`
+
+## 5. Git Status Caveat
+
+This workspace already contains many untracked second-round files. `git diff --name-only` only reports tracked file diffs, so it is not a complete changed-file list for this MVP worktree. Use `BUNDLE_FILE_MANIFEST.md` and `optional_raw_changed_files.zip` for the round-03 review set.
+

ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/BUNDLE_FILE_MANIFEST.md

@@ -0,0 +1,38 @@
+# Bundle File Manifest
+
+## Required Review Files
+
+- `00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md`
+- `01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md`
+- `02_CURRENT_ASSET_PACK.md`
+- `03_REPORTS_DIFF_AND_COMMAND_LOG.md`
+- `BUNDLE_FILE_MANIFEST.md`
+- `optional_raw_changed_files.zip`
+
+## Raw Changed Files Included In Zip
+
+- `README.md`
+- `docs/DATA_CONTRACT.md`
+- `docs/DECISIONS.md`
+- `docs/QPI_CONTEXTUAL_ROUTING_RULES.md`
+- `docs/INTELLECTUAL_ARCHAEOLOGY_DEPTH_GATE.md`
+- `knowledge_assets/08_CCRA模型库MVP质量门与交接协议.md`
+- `schemas/model_card.schema.json`
+- `models/qpi.model.json`
+- `models/model_index.json`
+- `cards/qpi.md`
+- `cards/card_index.md`
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+- `selector/selector_rules.json`
+- `selector/selector_calibration_inputs.json`
+- `scripts/run_selector_demo.py`
+- `scripts/validate_model_library.py`
+- `tests/test_validate_model_library.py`
+- `reports/content_review_report_v0.2.md`
+- `reports/validation_report.md`
+- `reports/index_rebuild_report.md`
+- `reports/model_card_sync_report_v0.2.md`
+- `reports/selector_regression_report_v0.2.md`
+- `docs/superpowers/plans/2026-06-17-contract-hardening-selector-calibration.md`
+

docs/CHATGPT_HANDOFF_RULES.md

@@ -0,0 +1,83 @@
+# ChatGPT Handoff Rules
+
+## Purpose
+
+When the project owner moves from Codex back to ChatGPT or CCRA for discussion, Codex must provide a compact handoff document.
+
+The handoff prevents ChatGPT from reconstructing project state from scattered history and prevents the owner from manually explaining the latest local implementation.
+
+## When To Create A Handoff
+
+Create a ChatGPT handoff when:
+
+- The owner says they are going back to ChatGPT.
+- A model extraction or repair session completes.
+- Rules, schemas, workflow, indexes, or validation tools materially change.
+- The next step requires product, CCRA, or architecture judgment outside Codex.
+
+Do not replace validation reports with a handoff. The handoff summarizes and points to validated artifacts.
+
+## Location And Naming
+
+Store handoffs in `reports/`.
+
+Use this naming pattern:
+
+```text
+ChatGPT交接文档_<topic>_<YYYY-MM-DD>.md
+```
+
+Example:
+
+```text
+reports/ChatGPT交接文档_模型库MVP_2026-06-16.md
+```
+
+## Required Sections
+
+Each handoff must include:
+
+1. 当前阶段
+2. 本轮目标
+3. 已完成内容
+4. 关键文件路径
+5. Codex 实现和原计划的差异
+6. 当前问题
+7. 需要 ChatGPT / CCRA 判断的事项
+8. 下一步候选方向
+9. 验证结果
+
+## Required Distinctions
+
+The handoff must distinguish:
+
+- 已验证事实
+- 当前草稿
+- 待产品判断
+- 待 CCRA / ChatGPT 判断
+- 已知限制
+
+Do not write only "已完成". Include the verification commands and results.
+
+## Required File References
+
+The handoff should point to local files rather than copying everything.
+
+For model library MVP handoffs, include links to:
+
+- `reports/validation_report.md`
+- `models/model_index.json`
+- `cards/card_index.md`
+- `schemas/model_card.schema.json`
+- current model JSON files
+- current Markdown cards
+- source and regression indexes
+- relevant rules or workflow docs
+
+## Relationship To Knowledge Assets
+
+Handoffs are session-level reports.
+
+Long-term reusable knowledge belongs in `knowledge_assets/`.
+
+If a handoff repeats stable rules, model maps, or project context that should be reused across sessions, create or update a knowledge asset instead of leaving it only in `reports/`.

docs/CONTENT_STABILIZATION_PROTOCOL.md

@@ -0,0 +1,84 @@
+# Content Stabilization Protocol
+
+## Principle
+
+Engineering contract PASS is not content stability.
+
+The validation scripts prove that the model library can be parsed, indexed, and checked. They do not prove that a model is semantically correct, sufficiently evidenced, regression-stable, or safe for broad product use.
+
+## Stabilization Gates
+
+A model cannot move beyond `draft` without these review gates:
+
+1. Evidence review.
+2. Content review.
+3. Regression review.
+4. Selector review.
+5. Owner / CCRA review.
+
+Each gate must leave a file-backed result under `reports/` or a structured status entry.
+
+## Current Model Rule
+
+For this round:
+
+| Model ID | Status | Stability | Regression Status |
+| --- | --- | --- | --- |
+| `qpi` | draft | B | pending |
+| `intellectual_archaeology` | draft | B | pending |
+
+Do not upgrade either model to stable.
+
+## Current Non-Goals
+
+This round must not:
+
+- Add a third model.
+- Connect a full question-answering system.
+- Introduce an LLM selector.
+- Introduce a vector database.
+- Build frontend or backend product surfaces.
+- Change `stability_level` from B to A.
+- Change `regression_status` from pending to passed.
+- Change `status` from draft to stable.
+
+## Draft-Callable Meaning
+
+`draft-callable` is a review conclusion, not a model JSON status value in v0.2.
+
+It means:
+
+- The model remains `status: draft`.
+- The model has enough structure for controlled review calls.
+- Evidence coverage, regression coverage, selector false-positive protection, and content risks are visible.
+- The model still requires Owner / CCRA judgment before any stronger state.
+
+## Required v0.2 Evidence Types
+
+Field support must be classified as:
+
+- `direct_source`: directly supported by source text.
+- `derived_from_source`: reasonably inferred from source text.
+- `product_decision`: product or selector rule.
+- `red_team_inference`: misuse, boundary, or failure inference.
+- `owner_decision`: Owner / CCRA judgment.
+
+## Required v0.2 Coverage Status
+
+Each required model field must be marked as:
+
+- `supported`
+- `partially_supported`
+- `derived`
+- `unsupported`
+- `needs_owner_review`
+
+## Required Review Status Fields
+
+Content review reports should track:
+
+- `engineering_contract_status`
+- `content_review_status`
+- `evidence_review_status`
+- `regression_review_status`
+- `selector_review_status`

docs/DATA_CONTRACT.md

@@ -4,6 +4,8 @@
 
 Use JSON for machine-readable data.
 
+Model JSON files own the model asset state, including `status`, `regression_status`, and `stability_profile.stability_level`.
+
 Main JSON objects:
 
 - Model spec
@@ -11,6 +13,7 @@ Main JSON objects:
 - Source excerpt
 - Regression case
 - Selector example
+- Model index
 
 ## 2. Human-Readable Format
 
@@ -33,6 +36,7 @@ Every model JSON should include:
 - `one_sentence_definition`
 - `core_question`
 - `core_mechanism`
+- `status`
 - `source_articles`
 - `source_evidence`
 - `input_types`
@@ -45,8 +49,14 @@ Every model JSON should include:
 - `confidence_level`
 - `stability_profile`
 - `regression_status`
+- `output_contract`
+- `structured_output_contract`
 - `productization_notes`
 
+`structured_output_contract` is model-specific. It must not turn QPI-only or Intellectual-Archaeology-only runtime fields into global top-level required fields for every model.
+
+Model-specific required runtime output fields are checked by `scripts/validate_model_library.py`.
+
 ## 4. Source Article Contract
 
 Every source article should include:
@@ -95,6 +105,15 @@ Every regression case should include:
 Optional:
 
 - `expected_output_elements`
+- `should_call_model`
+- `expected_primary_model`
+- `negative_expected_models`
+- `expected_classification`
+- `expected_dominant_scarcity`
+- `expected_max_depth`
+- `minimum_required_elements`
+- `forbidden_elements`
+- `evaluation_mode`
 - `notes`
 
 ## 7. Reference Integrity
@@ -106,3 +125,19 @@ The following references must be valid:
 - `regression_case.model_id` -> `models/*.model.json`
 - `source_excerpt.source_id` -> `sources/source_articles.json`
 - `source_excerpt.related_model_id` -> `models/*.model.json`
+
+## 8. Index Integrity
+
+`models/model_index.json` is generated or checked from model JSON, card files, source references, and regression cases.
+
+`cards/card_index.md` is the human-readable projection of `models/model_index.json`.
+
+Indexes must not drift from model state, source/evidence counts, regression case counts, or card file existence.
+
+## 9. Content Stabilization Integrity
+
+Engineering validation does not imply content stability.
+
+Before content stabilization review, every core model should have at least 15 regression cases and field-level evidence coverage.
+
+Source excerpts must distinguish exact quotes from condensed or paraphrased excerpts with `quote_status`.

docs/DECISIONS.md

@@ -83,3 +83,73 @@ Frameworks such as CrewAI and LangGraph may be useful later for implementing pro
 CCPE may define the agent contract, runtime governance, authority, evaluation, and integration registration.
 
 skills-vault may provide reusable deterministic helper Skills discovered during implementation.
+
+## Decision 009: Use `intellectual_archaeology` as the machine model ID
+
+Status: Accepted
+
+Reason:
+
+The source article names the model **“思想考古学”（Intellectual Archaeology）**.
+
+The machine-readable ID should use the stable English snake_case form `intellectual_archaeology`, while the human-facing model name remains Chinese.
+
+## Decision 010: Keep field names English and field content Chinese
+
+Status: Accepted
+
+Reason:
+
+English field names make JSON easier to validate and integrate.
+
+Chinese field values preserve source-language meaning and avoid translation drift during model extraction.
+
+## Decision 011: GPT plans must be localized before implementation
+
+Status: Accepted
+
+Reason:
+
+GPT planning documents may not know the current local repository state, existing constraints, missing contracts, or prior owner decisions.
+
+Codex must first convert each GPT plan into local rules, schemas, indexes, workflow, tooling expectations, and validation gates before implementing content.
+
+Content extraction or content repair must not begin from a GPT plan until the local foundation has been reviewed, unless the project owner explicitly overrides the gate.
+
+## Decision 012: Maintain indexes by script-backed synchronization
+
+Status: Accepted
+
+Reason:
+
+`models/model_index.json` is the machine discovery entrypoint, and `cards/card_index.md` is the human review entrypoint.
+
+They should follow source assets instead of becoming separate hand-maintained content sources.
+
+Every asset change must incrementally synchronize the indexes, and handoff or release points must run a full rebuild or consistency check.
+
+The current rule is:
+
+```text
+incremental update on every model/card/source/test change
++
+full rebuild or full reconciliation at release, handoff, schema migration, batch expansion, or validation drift
+```
+
+Model status remains an owner / ChatGPT / CCRA decision; validation and index rebuilds must not upgrade `draft` to a stronger state automatically.
+
+## Decision 013: Archive CCRA review bundles by round
+
+Status: Accepted
+
+Reason:
+
+The first compressed CCRA review bundle was generated as flat files under `ccra_review_bundle/`. That works for a single handoff, but it becomes ambiguous once later rounds produce new `00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md`, command logs, diffs, and raw changed files.
+
+`ccra_review_bundle/` is now the archive root. Each review round must live in a dated subdirectory:
+
+```text
+ccra_review_bundle/round-NN_YYYY-MM-DD_topic/
+```
+
+This keeps second-round and third-round materials comparable without overwriting prior evidence. Temporary review bundles remain session evidence and should not be copied into `knowledge_assets/`.

docs/GPT_PLAN_LOCALIZATION_PROTOCOL.md

@@ -0,0 +1,65 @@
+# GPT Plan Localization Protocol
+
+## Purpose
+
+GPT planning documents are upstream planning inputs. They are not directly executable repository rules.
+
+Before Codex implements content from a GPT plan, Codex must convert the plan into local rules, schemas, workflow steps, tools, indexes, and validation criteria.
+
+## Required Intake Steps
+
+1. Read the GPT planning document completely enough to extract fields, tasks, non-goals, workflow requirements, tooling expectations, index expectations, and acceptance criteria.
+2. Compare the GPT plan against local repository rules in `AGENTS.md`, `README.md`, `docs/DATA_CONTRACT.md`, `docs/WORKFLOW.md`, `docs/DECISIONS.md`, and `PROJECTS.md`.
+3. Identify conflicts, missing local contracts, missing schemas, missing validators, missing indexes, missing workflow gates, and missing owner-confirmation points.
+4. Write a local execution plan before changing content.
+5. Ask the project owner to review the local execution plan.
+6. Only after owner approval, implement local rules, schemas, indexes, workflow, and tooling.
+7. Validate the foundation.
+8. Ask the project owner to review the foundation before content extraction or content repair begins.
+
+## Required Local Plan
+
+Each local plan must state:
+
+- Which parts of the GPT plan become repository rules.
+- Which parts become schemas.
+- Which parts become workflow gates.
+- Which parts become validation or selector tools.
+- Which parts are deferred.
+- Which parts conflict with existing local rules.
+- What the project owner must confirm before implementation.
+
+## Prohibited Shortcut
+
+Do not directly create or repair model content from a GPT planning document before local rules, schemas, indexes, workflow, and validation expectations are confirmed.
+
+Do not treat a GPT plan as a substitute for local schema, local workflow, local index definitions, or local validation tools.
+
+Do not silently narrow a GPT plan to the current repository minimum field set. If the GPT plan has a richer contract, record the difference and ask for confirmation or implement the richer local contract first.
+
+## Dual-Track Rule
+
+Model extraction must keep two tracks separate:
+
+1. Workflow/tooling track: rules, schemas, indexes, validators, selector demo, audit reports, and supplier requests.
+2. Content extraction track: source records, evidence excerpts, model JSON, Markdown cards, regression cases, and selector examples.
+
+The content extraction track must not absorb missing workflow or tooling work. If a missing capability blocks reliable extraction, create a local plan item or a supplier request before continuing.
+
+## Required Report
+
+Each localization pass must produce a report under `reports/` that lists:
+
+- GPT plan source path.
+- Local files created or modified.
+- Fields adopted.
+- Fields rejected or deferred.
+- Workflow gates added.
+- Indexes required.
+- Tooling needs identified.
+- Differences from current repository state.
+- Open owner questions.
+
+## Owner Review Gate
+
+After local rules, schemas, indexes, workflow, and validation expectations are implemented, Codex must stop for project owner review unless the owner explicitly authorizes continuing into content extraction.

docs/INDEX_MAINTENANCE_PROTOCOL.md

@@ -0,0 +1,115 @@
+# Index Maintenance Protocol
+
+## Purpose
+
+`models/model_index.json` is the machine-readable registry for model discovery.
+
+`cards/card_index.md` is the human-readable projection for review and handoff.
+
+Neither file is the full source of model content. Full content remains in:
+
+- `models/*.model.json`
+- `cards/*.md`
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+- `tests/regression_cases.json`
+
+## Maintenance Rule
+
+Every asset change must keep indexes synchronized.
+
+Key handoff and release points must run a full rebuild or full consistency check.
+
+The operating rule is:
+
+```text
+incremental update on every model/card/source/test change
++
+full rebuild or full reconciliation at release, handoff, schema migration, batch expansion, or validation drift
+```
+
+## Incremental Update Triggers
+
+Update indexes in the same work session whenever any of these changes:
+
+- Model added, deleted, renamed, or archived.
+- `model_id`, `model_name`, `model_type`, or `pipeline_position`.
+- `model_file` or `card_file` path.
+- Source article or source evidence references.
+- Regression cases for a model.
+- `stability_profile.stability_level`.
+- `regression_status`.
+- `status`.
+- Card file added, deleted, or renamed.
+
+## Full Rebuild Or Full Check Triggers
+
+Run `python scripts\rebuild_indexes.py --check` or `python scripts\rebuild_indexes.py --write` before:
+
+- ChatGPT / CCRA / owner handoff.
+- Writing `reports/validation_report.md`.
+- Schema changes.
+- Batch model expansion.
+- Directory or naming-rule changes.
+- Larger merges.
+- Selector rules depending on model registry state.
+- Any model status upgrade review.
+- Any detected index drift or orphan file.
+
+## Field Sources
+
+| Index field | Source |
+| --- | --- |
+| `model_id` | `models/*.model.json.model_id` |
+| `model_name` | `models/*.model.json.model_name` |
+| `model_type` | `models/*.model.json.model_type` |
+| `pipeline_position` | `models/*.model.json.pipeline_position` |
+| `model_file` | Model JSON file path |
+| `card_file` | `cards/{model_id}.md` in v0.2 |
+| `source_article_count` | Length of `source_articles` |
+| `source_evidence_count` | Length of `source_evidence` |
+| `regression_case_count` | Cases in `tests/regression_cases.json` with the same `model_id` |
+| `stability_level` | `stability_profile.stability_level` |
+| `regression_status` | `regression_status` |
+| `status` | `status` |
+| `last_updated` | `last_updated` |
+
+## Card Index Generation
+
+`cards/card_index.md` is rendered from `models/model_index.json`.
+
+Current v0.2 table columns:
+
+- Model ID
+- 模型名称
+- 类型
+- 流程位置
+- Card
+- Model JSON
+- 稳固性
+- 回归状态
+- 状态
+
+Do not treat `cards/card_index.md` as an independent content source.
+
+## Drift Checks
+
+Validation must detect:
+
+- Missing `model_file` or `card_file`.
+- Model JSON files missing from `model_index.json`.
+- Card files missing from `card_index.md`.
+- `card_index.md` entries missing from `model_index.json`.
+- Count drift for source articles, source evidence, and regression cases.
+- State drift for `stability_level`, `regression_status`, and `status`.
+
+## Codex Checklist
+
+When modifying model assets:
+
+1. Update the source asset first.
+2. Run `python scripts\rebuild_indexes.py --write`.
+3. Run `python scripts\rebuild_indexes.py --check`.
+4. Run `python scripts\validate_model_library.py`.
+5. Confirm `reports/index_rebuild_report.md` and `reports/validation_report.md`.
+6. Do not upgrade `status`, `stability_level`, or `regression_status` unless owner / ChatGPT / CCRA explicitly decided it.

docs/INTELLECTUAL_ARCHAEOLOGY_DEPTH_GATE.md

@@ -0,0 +1,103 @@
+# Intellectual Archaeology Depth Gate
+
+Date: 2026-06-17
+
+Status: draft rule hardening for `model_library_mvp`
+
+## 1. Purpose
+
+Intellectual Archaeology is a deep modeling model. It is not a default analysis mode, article summary mode, or ornament for ordinary questions.
+
+The depth gate exists to prevent over-analysis and to force explicit stopping reasons.
+
+## 2. When `should_call=false`
+
+Set `should_call=false` when:
+
+- the user only needs a fact lookup;
+- the user asks for rewrite, translation, typo correction, or direct execution;
+- QPI has not completed problem definition for an ambiguous problem;
+- the input has deep words such as "底层", "模型", or "哲学" but the user intent is light;
+- there is not enough material to separate real assumptions from generic abstraction;
+- the analysis would not change judgment, route, verification, or action.
+
+## 3. Depth Levels
+
+Allowed `recommended_max_depth` values:
+
+- `application`
+- `domain`
+- `process`
+- `purpose`
+- `core_mechanism`
+- `human_capability`
+- `philosophical_bedrock`
+
+## 4. Depth Derivation
+
+Use the shallowest level that can change the next action.
+
+Stop at `application` when the request is about usage, examples, or immediate application.
+
+Stop at `domain` when domain assumptions or contextual constraints explain the behavior.
+
+Stop at `process` when the missing value is workflow, sequence, role boundary, or operating mechanism.
+
+Stop at `purpose` when the problem is about what the system is trying to optimize or preserve.
+
+Stop at `core_mechanism` when the request is to extract a reusable model or explain repeated failure.
+
+Use `human_capability` only when the question depends on human cognition, judgment, agency, fatigue, attention, or embodied limitation.
+
+Use `philosophical_bedrock` only when the problem explicitly involves value premises, epistemic assumptions, ontology of the problem, or the model's deepest ground.
+
+## 5. Philosophical Bedrock Is Not Default
+
+`philosophical_bedrock` must not be selected only because the input contains:
+
+- "底层";
+- "模型";
+- "哲学";
+- "第一性原理";
+- "深层".
+
+It is allowed only when deeper analysis changes the framing, validity, or action boundary.
+
+## 6. Required Runtime Fields
+
+The model-specific runtime contract requires:
+
+- `should_call`
+- `entry_reason`
+- `recommended_max_depth`
+- `layers_to_analyze`
+- `stop_reason`
+- `no_deeper_reason`
+- `assumptions_by_layer`
+- `validation_needed`
+- `action_implication`
+
+`value_of_deeper_analysis` may be added later as an optional field, but `no_deeper_reason` is required because it prevents depth inflation.
+
+## 7. Stop Reason Templates
+
+Use concrete stopping reasons:
+
+- "Stop at purpose because the decision depends on what the system optimizes; deeper ontology would not change the next action."
+- "Stop at core_mechanism because the reusable pattern is now explicit and validation can begin."
+- "Stop before philosophical_bedrock because the input lacks evidence for value-premise or epistemic claims."
+- "No call because QPI has not completed the problem frame."
+- "No call because the user requested direct execution."
+
+## 8. Status Boundary
+
+This gate does not upgrade the model. Intellectual Archaeology remains:
+
+```json
+{
+  "status": "draft",
+  "stability_level": "B",
+  "regression_status": "pending"
+}
+```
+

docs/KNOWLEDGE_ASSET_RULES.md

@@ -0,0 +1,90 @@
+# Knowledge Asset Rules
+
+## Purpose
+
+`knowledge_assets/` stores stable, long-term, reusable knowledge documents for this repository.
+
+These documents are not raw source archives, not temporary handoffs, and not implementation-only files. They are the durable explanation layer that helps the project owner, ChatGPT, Codex, and future CCRA work understand the model library without reconstructing context from scattered files.
+
+## What Belongs In `knowledge_assets/`
+
+Use `knowledge_assets/` for:
+
+- product context summaries
+- model maps
+- model card structure rules
+- model extraction templates
+- stability rating rules
+- durable process records
+- reusable architecture summaries
+
+Do not use `knowledge_assets/` for:
+
+- raw original articles
+- temporary validation reports
+- full copies of every model card
+- generated cache files
+- implementation scripts
+- source-of-truth JSON model assets
+
+## Relationship To Other Directories
+
+`docs/` contains operative local rules, contracts, workflow docs, and decisions.
+
+`models/` contains machine-readable model JSON source of truth.
+
+`cards/` contains human-readable model cards.
+
+`reports/` contains session-level validation, audit, and handoff documents.
+
+`knowledge_assets/` contains stable explanatory knowledge distilled from those sources.
+
+## Naming Rule
+
+Use numeric prefixes for reading order.
+
+Do not put version numbers in filenames. Put version, status, and last updated date inside the document.
+
+Examples:
+
+```text
+00_用户背景与产品上下文.md
+01_核心模型地图.md
+02_模型卡结构规范.md
+03_核心模型抽取样板.md
+06_模型稳固性评级规则.md
+07_产品规划过程记录.md
+```
+
+## Model Card Sample Rule
+
+Do not duplicate every concrete model card into `knowledge_assets/`.
+
+Concrete model card source of truth remains in `cards/` and `models/`.
+
+If a sample is needed for ChatGPT or CCRA reasoning, create a clearly marked sample or summary document, not a second source of truth.
+
+For now, QPI and 思想考古 are referenced through:
+
+- `cards/qpi.md`
+- `cards/intellectual_archaeology.md`
+- `models/qpi.model.json`
+- `models/intellectual_archaeology.model.json`
+
+## Update Rule
+
+Update or create a knowledge asset when:
+
+- a rule becomes stable enough to reuse across sessions
+- project context changes in a durable way
+- a model map changes
+- a workflow or schema decision should be remembered outside a single report
+- ChatGPT handoff material repeats across sessions
+
+Do not update knowledge assets for every small implementation change. Use reports for session-level details.
+
+## Review Rule
+
+Knowledge assets should be concise and source-linked.
+
+When a knowledge asset summarizes a file-backed artifact, link to the artifact and state whether the source of truth remains elsewhere.

docs/MODEL_CARD_CONTRACT.md

@@ -0,0 +1,133 @@
+# Model Card Contract
+
+Each human-readable model card in `cards/` must include the sections below.
+
+Section contents should be Chinese when the source material is Chinese. English may appear in IDs, aliases, source terms, and field labels.
+
+## Required Sections
+
+## 模型名称
+
+The human-readable model name.
+
+## 模型 ID
+
+The stable machine ID used by model JSON, source excerpts, regression cases, selector rules, and indexes.
+
+## 一句话定义
+
+One concise sentence explaining what the model does.
+
+## 模型类型
+
+The model type, aligned with `schemas/model_card.schema.json`.
+
+## 所在流程位置
+
+Where the model belongs in the processing pipeline.
+
+## 来源文章
+
+Source article IDs and titles.
+
+## 来源证据片段
+
+Evidence excerpt IDs and what each excerpt supports.
+
+## 核心问题
+
+The core question this model answers.
+
+## 核心机制
+
+The reusable mechanism or operating logic of the model.
+
+## 输入类型
+
+Inputs the model can accept.
+
+## 输出类型
+
+Outputs the model should produce.
+
+## 适用场景
+
+When the model should be called.
+
+## 不适用场景
+
+When the model should not be called.
+
+## 调用关键词
+
+Trigger keywords or expressions that suggest the model may apply.
+
+## 负向触发条件
+
+Expressions, task types, or contexts that should suppress the model.
+
+## 相关模型
+
+Models that can be called before, after, or alongside this model.
+
+## 冲突模型
+
+Models or flows that should not be used together without arbitration.
+
+## 学科底座关联
+
+Disciplines, theories, or knowledge bases that anchor the model.
+
+## 常见误用
+
+Common misuse patterns.
+
+## 失败信号
+
+Signals that the model was called incorrectly or produced unstable output.
+
+## 可信度等级
+
+The current confidence level and why.
+
+## 稳固性状态
+
+The current stability level and whether stabilization is still required.
+
+## 稳定性评估
+
+Assessment across concept clarity, mechanism stability, boundary clarity, source evidence quality, and regression performance.
+
+## 回归测试状态
+
+Regression status and current coverage.
+
+## 示例输入
+
+Representative inputs.
+
+## 示例输出
+
+Representative outputs.
+
+## 输出契约
+
+The expected structure or elements of model output.
+
+## 深度控制
+
+Depth limits, stop conditions, or overuse warnings.
+
+## 产品化建议
+
+Notes for selector, workflow, product integration, or future stabilization.
+
+## 版本信息
+
+Version, last updated date, and draft/stability status.
+
+## Additional Sections
+
+Cards may include additional explanatory sections after the required sections.
+
+Required sections may contain `无` only when the model genuinely has no value for that field, and the reason must be clear.

docs/MODEL_EXTRACTION_RULES.md

@@ -0,0 +1,174 @@
+# Model Extraction Rules
+
+## Language Rule
+
+JSON field names use English.
+
+JSON field values and Markdown card contents should remain Chinese when the source material is Chinese. English terms may be preserved as aliases, IDs, or source terms.
+
+This rule exists to avoid translation drift while keeping machine-readable files easy to validate and integrate.
+
+## Source Traceability Rule
+
+Every model must reference source article IDs.
+
+Every model must reference source evidence excerpt IDs.
+
+Do not invent source IDs without matching records in `sources/source_articles.json`.
+
+Do not invent evidence excerpt IDs without matching records in `sources/source_excerpts.json`.
+
+Placeholder excerpts must be marked clearly and must not be treated as verified evidence.
+
+If a field is a productization inference rather than a direct source claim, record that status in the relevant note, evidence summary, or audit report.
+
+Evidence coverage must distinguish:
+
+- `direct_source`
+- `derived_from_source`
+- `product_decision`
+- `red_team_inference`
+- `owner_decision`
+
+Source excerpts must include `quote_status` and `source_location`.
+
+`quote_status=exact` must not contain unmarked ellipses. If a snippet is compressed, use `quote_status=condensed` and explain the compression in `notes`.
+
+## Model Extraction Is Not Article Summary
+
+Article summary answers:
+
+- What does this article say?
+
+Model extraction answers:
+
+- What reusable cognitive mechanism exists?
+- What input does it handle?
+- What output does it produce?
+- When should it be called?
+- When should it not be called?
+- What are its misuse patterns?
+- What are its failure signals?
+- How can its stability be tested?
+- How can it be routed by a selector?
+
+Do not stop at viewpoint summary. A model asset must become callable, bounded, traceable, and testable.
+
+## Required Model Asset Chain
+
+For each core model, the complete asset chain is:
+
+1. Source article record.
+2. Source evidence excerpts.
+3. Human-readable Markdown card.
+4. Machine-readable JSON model card.
+5. Regression cases.
+6. Selector examples or routing rules.
+7. Model index entry.
+8. Card index entry.
+9. Validation report.
+
+## Required Model JSON Fields
+
+Model JSON must include the required fields from `schemas/model_card.schema.json` after that schema is implemented.
+
+Recommended fields from the GPT plan should be included for v0.1 unless a field is explicitly deferred in the localization report.
+
+The current minimum field list from `docs/DATA_CONTRACT.md` is not enough for the full GPT sample contract. Until `schemas/model_card.schema.json` is implemented, extraction work must treat the GPT sample field list as the stronger target contract.
+
+## Required Human Card Sections
+
+Human-readable Markdown cards must follow `docs/MODEL_CARD_CONTRACT.md` after that contract is implemented.
+
+Before the card contract exists, Codex must not assume a short readable summary is a valid model card.
+
+## Stability Assessment
+
+Each model must include stability assessment across:
+
+- 概念清晰度
+- 机制稳定性
+- 边界清晰度
+- 来源证据质量
+- 回归测试表现
+
+Each model must record:
+
+- `stability_level`
+- `reason`
+- `next_stabilization_action`
+
+Stability level meanings:
+
+- `A`: 五个维度都较稳定，可进入核心调用。
+- `B`: 基本可用，但需要边界案例测试。
+- `C`: 有启发，但系统调用风险较高。
+- `D`: 不适合进入模型库，需要重构。
+
+## Regression Rule
+
+Every core model must have at least fifteen regression cases before content stabilization review.
+
+Each core model must include:
+
+- positive cases
+- boundary cases
+- misuse cases
+- no-call cases
+- selector gate cases
+- pipeline cases
+
+Regression tests are product stability tests for model use, not only software unit tests.
+
+## Selector Rule
+
+The v0.2 selector must not call an LLM.
+
+Selector output should include:
+
+- selected model IDs
+- rejected model IDs
+- scores
+- reasons
+- penalties
+- routing notes
+- no-call status
+
+Selector scoring should consider:
+
+- trigger keyword hits
+- input type match
+- negative trigger hits
+- `do_not_call_when` hits
+- pipeline position
+- selection priority
+- QPI-before-IA gate
+
+## Index Rule
+
+Machine-readable model assets are indexed in `models/model_index.json`.
+
+Human-readable cards are indexed in `cards/card_index.md`.
+
+Both indexes must be updated whenever a model or card is added, renamed, deprecated, or materially reclassified.
+
+For v0.1, manual incremental index updates are acceptable. When the model count grows beyond roughly 8-10 core models, a full rebuild script can be added if manual maintenance becomes costly or error-prone.
+
+## Workflow Gate Rule
+
+When a GPT plan is provided, Codex must not begin content extraction immediately.
+
+The required order is:
+
+1. Localize the GPT plan into repository rules, schemas, indexes, workflow, and tooling plan.
+2. Produce a localization difference report.
+3. Ask the project owner to review the local foundation.
+4. Only after confirmation, perform model content extraction or repair.
+
+## Supplier Request Rule
+
+If reliable extraction requires reusable automation, deterministic validators, batch processors, or installable Skills, classify it as a `skills-vault` need and create a request under `requirements/skills-vault/`.
+
+If reliable extraction requires expert-agent specifications, model-governance rules, invocation protocols, evaluation rubrics, or runtime contracts, classify it as a `ccpe-system` need and create a request under `requirements/ccpe/`.
+
+Do not copy canonical CCPE artifacts or reusable Skill source into this repository.

docs/MODEL_EXTRACTION_WORKFLOW.md

@@ -0,0 +1,133 @@
+# Model Extraction Workflow
+
+This workflow is the required gate sequence for extracting or repairing cognitive model assets.
+
+## Stage 0: GPT Plan Intake
+
+Input from user:
+
+- GPT planning document path
+- Source article paths
+- Existing model or application material paths
+- Target model IDs
+- Whether placeholder evidence is allowed
+- Whether the goal is rules only, content extraction, or full chain
+
+Codex output:
+
+- Local execution plan
+- Open questions
+- Owner review gate
+
+## Stage 1: Rules, Schema, Index, And Workflow Foundation
+
+Codex actions:
+
+- Convert GPT planning document into local rules.
+- Define or update schemas.
+- Define or update indexes.
+- Define workflow gates.
+- Define validation expectations.
+
+Output:
+
+- Rules docs
+- Schema files
+- Index contracts
+- Workflow docs
+- Difference report
+
+Owner confirmation:
+
+- The project owner reviews rules, schemas, indexes, and workflow before content extraction.
+
+## Stage 2: Source And Evidence Preparation
+
+Codex actions:
+
+- Register source articles.
+- Extract source evidence excerpts.
+- Mark placeholder evidence explicitly if source text is unavailable or insufficient.
+
+Output:
+
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+
+Checks:
+
+- Every excerpt references a known source article.
+- Every source ID is unique.
+- Placeholder evidence is not treated as verified evidence.
+
+## Stage 3: Model Asset Extraction
+
+Codex actions:
+
+- Write machine-readable model JSON.
+- Write human-readable Markdown card.
+- Update model and card indexes.
+
+Output:
+
+- `models/<model_id>.model.json`
+- `cards/<model_id>.md`
+- `models/model_index.json`
+- `cards/card_index.md`
+
+Checks:
+
+- JSON passes schema.
+- Markdown card contains required sections.
+- Source references resolve.
+- Index entries match model and card files.
+
+## Stage 4: Regression And Selector Preparation
+
+Codex actions:
+
+- Write at least five regression cases per core model.
+- Include positive, boundary, and misuse cases.
+- Add selector rules and selector examples.
+
+Output:
+
+- Regression case files or consolidated regression case JSON.
+- Selector rules.
+- Selector examples.
+
+Checks:
+
+- Every core model has at least five cases.
+- Each model has positive, boundary, and misuse cases.
+- Selector examples return model IDs and reasons.
+
+## Stage 5: Validation And Audit
+
+Codex actions:
+
+- Run local validation scripts.
+- Generate validation report.
+- Generate extraction audit report.
+
+Output:
+
+- `reports/validation_report.md`
+- `reports/<model_id>_extraction_audit.md` or session-level audit report.
+
+## Stage 6: Owner Review
+
+Owner reviews:
+
+- Model definition
+- Field completeness
+- Evidence quality
+- Boundary and misuse cases
+- Selector behavior
+- Open questions
+
+Content is not considered stable until owner review completes.
+
+## Workflow Rule
+
+Do not repair or expand model content before Stage 1 foundation is implemented and reviewed, unless the project owner explicitly overrides the gate.

docs/PROJECT_BRIEF.md

@@ -24,6 +24,7 @@ The project solves a model asset management problem:
 - Model cards need stronger source traceability.
 - Some early models require regression testing and stabilization.
 - The future question-answering system needs callable model specifications.
+- Model and card indexes need script-backed synchronization so the library does not drift into scattered files.
 
 ## 4. MVP Focus
 
@@ -34,6 +35,8 @@ The MVP focuses on two models:
 
 These two models are used to validate the model extraction protocol.
 
+The current index maintenance rule is documented in `docs/INDEX_MAINTENANCE_PROTOCOL.md`: every asset change synchronizes `models/model_index.json` and `cards/card_index.md`, while handoff and release points require a full rebuild or check.
+
 ## 5. Long-Term Direction
 
 Future versions may support:

docs/QPI_CONTEXTUAL_ROUTING_RULES.md

@@ -0,0 +1,178 @@
+# QPI Contextual Routing Rules
+
+Date: 2026-06-17
+
+Status: draft rule hardening for `model_library_mvp`
+
+## 1. Updated Definition
+
+QPI is not a text classifier.
+
+QPI judges how a cognitive subject, in a concrete context, frames an expectation-reality gap as `question`, `problem`, `issue`, `mixed`, or `no_call`.
+
+The model must therefore inspect:
+
+- who the subject is;
+- what responsibility position they occupy;
+- what scenario the gap appears in;
+- what the expected outcome and current reality are;
+- what resources, authority, time scale, and feedback loops are available;
+- whether the frame is stable, provisional, mixed, or changing.
+
+## 2. Source Structure
+
+QPI currently draws from two non-substitutable source layers:
+
+- `article_qpi_contextual_2025_001`: subjectivity, context, expectation-reality gap, dynamic lifecycle, and semantic foundation.
+- `article_qpi_primary_001`: core scarcity, cognitive optics, power-framed misclassification, violent reduction, and malicious inflation.
+
+The 2025 article is not obsolete. It supplies the subject-context-dynamic foundation that prevents QPI from becoming a shallow text classifier.
+
+## 3. No-Call Gate
+
+Return `classification_scope=no_call` when the input is only:
+
+- fact lookup;
+- rewrite, polish, or typo correction;
+- translation;
+- direct file or formatting execution;
+- a low-risk instruction where the user explicitly says not to analyze.
+
+Exception: if the user explicitly says not to execute literally and asks for analysis of the underlying problem, the no-call gate may be bypassed.
+
+## 4. Subject-Context Gate
+
+QPI must not produce high-confidence classification without enough context.
+
+Rules:
+
+- If `subject_position` is missing, `classification_confidence` must not be `high`.
+- If `scenario_context` is missing, `dominant_scarcity` must not be high-confidence.
+- If both subject and scenario are missing, set `is_provisional=true`.
+- If context is insufficient, fill `missing_context` and `recommended_clarifying_questions`.
+
+Example:
+
+```text
+Input: 如何提高流量？
+```
+
+This is not automatically `problem` or `mixed`. It is `insufficient_context` until the subject, responsibility scope, goal, resources, and time scale are known.
+
+## 5. Expectation-Reality Gap
+
+Every non-no-call QPI output should extract:
+
+- expected state;
+- current reality;
+- gap summary.
+
+If any part is unknown, write `unknown` instead of inventing context.
+
+## 6. Mixed Versus Multi-Perspective
+
+QPI must distinguish two different kinds of complexity.
+
+`intra_frame_mixed`:
+
+Same subject, same scenario, same stage. Multiple scarcities coexist inside one problem frame.
+
+Example:
+
+```text
+我是集团营销负责人，既缺流量增长方法，也担心销售、库存、客服和激励机制跟不上。
+```
+
+`inter_viewpoint_divergence`:
+
+The same surface input would be framed differently by different subjects or responsibility positions.
+
+Example:
+
+```text
+如何提高流量？
+```
+
+For a student this may be `question`; for a marketing manager this may be `problem`; for a group marketing director this may be `issue`.
+
+Do not collapse `inter_viewpoint_divergence` into `mixed`.
+
+## 7. Scarcity Profile
+
+Use three scarcity channels:
+
+- `data_scarcity`: facts, concepts, examples, source location, or basic knowledge are missing.
+- `path_or_resource_scarcity`: goal is clear, but method, resource, decomposition, or implementation path is missing.
+- `consensus_or_order_scarcity`: success depends on alignment, incentives, governance, stability, authority, or system order.
+
+Dominant scarcity rules:
+
+- If exactly one channel is `high`, use its corresponding dominant scarcity.
+- If two or three channels are `high` for the same subject and scenario, use `mixed`.
+- If evidence is insufficient, use `unknown`.
+- For `mixed` or `low` confidence, `evidence_gap` must be non-empty.
+
+## 8. Issue As Governance Load
+
+`issue` does not require a multi-person organization.
+
+Raise issue weight when any of these are present:
+
+- success criteria are not unique, and multiple standards are reasonable;
+- the task cannot be solved once and closed;
+- the action will change the future problem structure;
+- multiple valid goals require ongoing tradeoff;
+- state continuity, role boundaries, invocation authenticity, audit trail, or downstream reuse matters;
+- the validator is part of the system being designed;
+- local truth can masquerade as global structure;
+- the next step depends on human confirmation, authority, or boundary protocol.
+
+This covers personal workflow redesign cases where the owner, future owner, agents, source materials, token budget, audit boundary, and downstream projects behave like proxy stakeholders.
+
+## 9. Misframing Risks
+
+QPI must identify these risks when present:
+
+- `violent_reduction`: compressing an issue into a personal execution problem.
+- `malicious_inflation`: inflating a concrete problem into an untouchable issue.
+- `tool_solutionism`: treating subject-context-governance work as mere tool unfamiliarity.
+- `premature_classification`: assigning Q/P/I before subject and scenario are known.
+
+## 10. Routing Output
+
+The required QPI runtime output fields are declared in `models/qpi.model.json` under `structured_output_contract` and enforced by `scripts/validate_model_library.py`.
+
+Do not write `draft-callable` into model `status`. QPI remains:
+
+```json
+{
+  "status": "draft",
+  "stability_level": "B",
+  "regression_status": "pending"
+}
+```
+
+## 11. Raw Case Preprocessing
+
+Owner-provided raw cases should not be compressed into short classification prompts.
+
+Each case digest should preserve:
+
+- `subject_position`;
+- `responsibility_scope`;
+- `scenario_context`;
+- `experience_level`;
+- `goal`;
+- `expected_outcome`;
+- `current_reality`;
+- `hard_feedback_availability`;
+- `success_criteria`;
+- `proxy_stakeholders`;
+- `dynamic_shift`;
+- `possible_qpi_by_viewpoint`;
+- `owner_expected_judgment`;
+- `codex_candidate_judgment`;
+- `owner_review_needed`.
+
+Raw case processing is intentionally deferred until owner materials are available.
+

docs/WORKFLOW.md

@@ -2,6 +2,8 @@
 
 ## 1. Model Extraction Workflow
 
+For detailed model extraction gates, see `docs/MODEL_EXTRACTION_WORKFLOW.md`.
+
 The project follows this flow:
 
 ```text
@@ -37,8 +39,9 @@ When adding a new model:
 4. Add source evidence excerpts.
 5. Add regression cases.
 6. Add selector examples if relevant.
-7. Run validation.
+7. Run `python scripts\rebuild_indexes.py --write`.
-8. Update documentation.
+8. Run validation.
+9. Update documentation.
 
 ## 4. Stabilization Workflow
 
@@ -51,6 +54,8 @@ If a model is unstable:
 
 ## 5. Handoff Workflow
 
+For ChatGPT-specific handoff rules, see `docs/CHATGPT_HANDOFF_RULES.md`.
+
 At the end of each work session:
 
 1. Summarize what changed.
@@ -60,6 +65,15 @@ At the end of each work session:
 5. List questions that require product or CCRA judgment.
 6. Suggest the smallest useful next tasks.
 
+If the owner is going from Codex to ChatGPT, create a `reports/ChatGPT交接文档_<topic>_<YYYY-MM-DD>.md` file before ending the work session.
+
+Before handoff, run:
+
+```powershell
+python scripts\rebuild_indexes.py --check
+python scripts\validate_model_library.py
+```
+
 ## 6. Supplier Request Workflow
 
 When this repository needs a capability owned by a neighboring repository:
@@ -95,3 +109,11 @@ Before adoption:
 3. Identify whether skills-vault needs to supply reusable deterministic helpers.
 4. Keep framework adapters, state, deployment, and product-specific behavior in this repository.
 5. Record the boundary decision in `docs/DECISIONS.md`.
+
+## 9. Knowledge Asset Workflow
+
+For long-term reusable knowledge rules, see `docs/KNOWLEDGE_ASSET_RULES.md`.
+
+When a rule, model map, schema explanation, workflow summary, or product context becomes stable enough to reuse across sessions, create or update a file under `knowledge_assets/`.
+
+Do not leave durable knowledge only in temporary reports.

docs/model_case_preprocessing/README.md

@@ -0,0 +1,23 @@
+# Model Case Preprocessing
+
+This folder stores reusable rules for turning owner-provided raw materials into reviewable model case drafts.
+
+Use one subfolder per model:
+
+```text
+docs/model_case_preprocessing/
+  qpi/
+  intellectual_archaeology/
+  future_model_id/
+```
+
+Rules here define preprocessing workflow only. They are not model cards, regression cases, selector calibration files, or stable content-review conclusions.
+
+Draft outputs should be written under:
+
+```text
+reports/model_case_preprocessing/<model_id>/<round-id>/
+```
+
+Machine-readable digests or calibration JSON should be created only after owner review of the Markdown case drafts.
+

docs/model_case_preprocessing/qpi/CASE_PREPROCESSING_WORKFLOW.md

@@ -0,0 +1,175 @@
+# QPI Case Preprocessing Workflow
+
+Date: 2026-06-17
+
+Status: reusable draft workflow for owner review
+
+## 1. Purpose
+
+Convert owner-provided raw materials into Markdown QPI case drafts that the owner can confirm or correct.
+
+This workflow exists because the owner should not need to write JSON or fill a heavy form before case extraction begins.
+
+## 2. Inputs
+
+Input is a raw Markdown or text source supplied by the owner.
+
+Examples:
+
+- long reflective analysis;
+- process redesign notes;
+- GPT discussion records;
+- QPI case analysis documents;
+- model extraction or workflow failure records.
+
+Do not copy the full source into this repository unless the owner explicitly asks. Record the source path and extract only concise evidence snippets or summaries needed for case review.
+
+## 3. Output Location
+
+Write draft cases under:
+
+```text
+reports/model_case_preprocessing/qpi/<round-id>/
+```
+
+Use one output file per raw source:
+
+```text
+<short-source-slug>.cases.md
+```
+
+Each file must be marked:
+
+```text
+status: draft_owner_review_needed
+```
+
+## 4. Case Draft Format
+
+Each source file may produce multiple cases.
+
+Use this structure for every case:
+
+```markdown
+## Case qpi-draft-XXX: <short title>
+
+status: draft_owner_review_needed
+
+source_path: `<absolute source path>`
+
+### 1. Surface Problem
+
+What the problem appears to be at first glance.
+
+### 2. Subject Position
+
+Who is framing the problem, including role, experience level, responsibility scope, and whether the subject is the present owner, future owner, an agent, a team, or another proxy stakeholder.
+
+### 3. Scenario Context
+
+Where the problem appears, including workflow, repo, article, relationship, tool, organization, or life context.
+
+### 4. Expectation-Reality Gap
+
+- Expected:
+- Reality:
+- Gap summary:
+
+### 5. Attempted Paths
+
+What has already been tried or assumed.
+
+### 6. Dynamic Shift
+
+How the problem frame changes over time, such as Q -> P, P -> I, Q/P -> P/I mixed, or insufficient context -> multi-perspective.
+
+### 7. Scarcity Profile
+
+- data_scarcity:
+- path_or_resource_scarcity:
+- consensus_or_order_scarcity:
+
+Use `high | medium | low | unknown`.
+
+### 8. Mixed Or Multi-Perspective
+
+Choose one:
+
+- `intra_frame_mixed`
+- `inter_viewpoint_divergence`
+- `not_mixed`
+- `unknown`
+
+Explain why.
+
+### 9. Governance Load
+
+Does the case require ongoing tradeoff, role boundary management, audit authenticity, downstream reuse, state continuity, or human confirmation?
+
+### 10. Misframing Risks
+
+Check any that apply:
+
+- violent_reduction
+- malicious_inflation
+- tool_solutionism
+- premature_classification
+- single-cause_reduction
+- over_pathologizing
+- other
+
+### 11. Candidate QPI Judgment
+
+- classification_scope:
+- is_provisional:
+- classification:
+- dominant_scarcity:
+- classification_confidence:
+- recommended_next_step:
+
+### 12. Owner Review Questions
+
+List concrete questions the owner should confirm or correct.
+```
+
+## 5. Extraction Rules
+
+Preserve subject-context before classification.
+
+Do not classify a sentence in isolation if the source provides broader context.
+
+Separate:
+
+- `intra_frame_mixed`: same subject, same scene, same stage, multiple scarcities.
+- `inter_viewpoint_divergence`: different subjects or responsibility positions would classify the same surface issue differently.
+
+Do not equate `issue` with "many people". A one-person workflow can be an Issue if it has ongoing governance load, proxy stakeholders, state continuity, audit boundaries, or unstable success criteria.
+
+Do not turn psychological, relational, or workflow material into clinical claims. Use QPI terms: subject, context, gap, scarcity, frame shift, misframing risk.
+
+## 6. What Not To Do
+
+Do not:
+
+- write selector JSON directly;
+- update regression cases directly;
+- upgrade model status;
+- create a third model;
+- summarize the whole source instead of extracting cases;
+- quote long source passages;
+- pretend draft cases are owner-approved.
+
+## 7. Promotion Path
+
+The promotion path is:
+
+```text
+raw source
+-> Markdown case drafts
+-> owner review and correction
+-> case digest JSON
+-> selector calibration inputs or regression cases
+```
+
+Only owner-reviewed cases may become machine-readable calibration or regression assets.
+

docs/model_case_preprocessing/qpi/README.md

@@ -0,0 +1,10 @@
+# QPI Case Preprocessing
+
+This folder defines how to preprocess raw owner materials into QPI case drafts.
+
+QPI is a subject-context-dynamic routing model. Preprocessing must preserve the subject, scenario, expectation-reality gap, dynamic shift, and possible misframing risks. Do not compress raw materials into short classification prompts.
+
+Primary workflow:
+
+- `CASE_PREPROCESSING_WORKFLOW.md`
+

docs/superpowers/plans/2026-06-16-model-extraction-contract-and-workflow.md

@@ -0,0 +1,844 @@
+# Model Extraction Contract and Workflow Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Turn the GPT planning document into local executable rules, schemas, indexes, workflow gates, and validation tools before revising QPI or Intellectual Archaeology content.
+
+**Architecture:** Treat GPT planning documents as upstream planning inputs, not direct implementation instructions. The repository must first convert them into local contracts, indexes, validators, and workflow gates; only after owner review should content extraction or model asset repair continue.
+
+**Tech Stack:** Markdown documentation, JSON Schema draft 2020-12, Python standard library validation scripts, file-first JSON indexes.
+
+---
+
+## Scope
+
+This plan covers the process and tooling foundation for future model extraction.
+
+It does not repair the current QPI or Intellectual Archaeology model contents yet. Those repairs happen only after the rules, schemas, indexes, workflow, and validators are written and reviewed.
+
+## Source Planning Document
+
+Read this first:
+
+```text
+C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\GPT成果\2026-06-16-核心模型抽取样板 v0.1.md
+```
+
+Use it as an upstream plan. Do not treat it as already-local repository law until the relevant parts are converted into this repository.
+
+## Required Local Outputs
+
+Create or update these files:
+
+- Create: `docs/MODEL_EXTRACTION_RULES.md`
+- Create: `docs/MODEL_CARD_CONTRACT.md`
+- Create: `docs/MODEL_EXTRACTION_WORKFLOW.md`
+- Create: `docs/GPT_PLAN_LOCALIZATION_PROTOCOL.md`
+- Create: `schemas/model_card.schema.json`
+- Modify: `schemas/source_article.schema.json`
+- Modify: `schemas/source_excerpt.schema.json`
+- Modify: `schemas/regression_case.schema.json`
+- Create: `models/model_index.json`
+- Create: `cards/card_index.md`
+- Create: `schemas/model_index.schema.json`
+- Create: `schemas/card_index.schema.json`
+- Modify: `scripts/validate_model_library.py`
+- Create: `scripts/check_card_contract.py`
+- Create: `scripts/run_selector_demo.py`
+- Create: `reports/GPT规划落地差异检查_v0.1.md`
+- Modify: `docs/DECISIONS.md`
+- Modify: `README.md`
+- Modify: `docs/WORKFLOW.md`
+- Modify: relevant folder README files
+
+## Index Decision
+
+Two indexes are required because model JSON and Markdown cards serve different consumers.
+
+`models/model_index.json` is the machine-readable model index. It supports validation, selector routing, model lookup, model status tracking, and future application integration.
+
+`cards/card_index.md` is the human-readable card index. It supports owner review, editorial navigation, extraction status review, and handoff.
+
+Index maintenance policy for v0.1:
+
+- During early MVP with two models, update indexes manually and validate references.
+- When model count grows beyond roughly 8-10 core models, add an optional full rebuild script.
+- Do not require full rebuild on every small edit in v0.1.
+- Full extraction from files is acceptable on demand because the repository is file-first and small, but it should become a tool only when manual maintenance becomes costly or error-prone.
+
+## Workflow Gates
+
+This repository must use these gates for every future GPT-provided planning document:
+
+1. GPT plan intake.
+2. Local plan creation.
+3. Owner review of local plan.
+4. Rules/schema/index/workflow implementation.
+5. Validation of rules/schema/index/workflow.
+6. Owner review of the foundation.
+7. Content extraction or content repair.
+8. Validation and audit report.
+9. Owner content review.
+
+No model content extraction should happen before gate 6 unless the owner explicitly overrides the gate.
+
+---
+
+### Task 1: Localize GPT Plan Into Repository Rules
+
+**Files:**
+- Create: `docs/GPT_PLAN_LOCALIZATION_PROTOCOL.md`
+- Create: `docs/MODEL_EXTRACTION_RULES.md`
+- Create: `reports/GPT规划落地差异检查_v0.1.md`
+- Modify: `docs/DECISIONS.md`
+
+- [ ] **Step 1: Write GPT plan localization protocol**
+
+Create `docs/GPT_PLAN_LOCALIZATION_PROTOCOL.md` with these sections:
+
+```markdown
+# GPT Plan Localization Protocol
+
+## Purpose
+
+GPT planning documents are upstream planning inputs. They are not directly executable repository rules.
+
+Before Codex implements content from a GPT plan, Codex must convert the plan into local rules, schemas, workflow steps, tools, and validation criteria.
+
+## Required Intake Steps
+
+1. Read the GPT planning document completely enough to extract fields, tasks, non-goals, workflow requirements, tooling expectations, and acceptance criteria.
+2. Compare the GPT plan against local repository rules in `AGENTS.md`, `README.md`, `docs/DATA_CONTRACT.md`, `docs/WORKFLOW.md`, and `PROJECTS.md`.
+3. Identify conflicts, missing local contracts, missing schemas, missing validators, missing indexes, and missing workflow gates.
+4. Write a local execution plan.
+5. Ask the project owner to review the local execution plan.
+6. Only after owner approval, implement local rules/schema/workflow/tooling.
+7. Ask the project owner to review the foundation before content extraction begins.
+
+## Prohibited Shortcut
+
+Do not directly create or repair model content from a GPT planning document before local rules, schemas, workflow, and validation expectations are confirmed.
+
+## Required Report
+
+Each localization pass must produce a report under `reports/` that lists:
+
+- GPT plan source path
+- Local files created or modified
+- Fields adopted
+- Fields rejected or deferred
+- Workflow gates added
+- Tooling needs identified
+- Open owner questions
+```
+
+- [ ] **Step 2: Write model extraction rules**
+
+Create `docs/MODEL_EXTRACTION_RULES.md` with these sections:
+
+```markdown
+# Model Extraction Rules
+
+## Language Rule
+
+JSON field names use English.
+
+JSON field values and Markdown card contents should remain Chinese when the source material is Chinese. English terms may be preserved as aliases, IDs, or source terms.
+
+## Source Traceability Rule
+
+Every model must reference source article IDs and source evidence excerpt IDs.
+
+Do not invent source IDs without matching records in `sources/source_articles.json`.
+
+Do not invent evidence excerpt IDs without matching records in `sources/source_excerpts.json`.
+
+Placeholder excerpts must be marked clearly and must not be treated as verified evidence.
+
+## Model Extraction Is Not Article Summary
+
+Article summary answers what the article says.
+
+Model extraction answers:
+
+- What reusable cognitive mechanism exists?
+- What input does it handle?
+- What output does it produce?
+- When should it be called?
+- When should it not be called?
+- How can misuse be detected?
+- How can stability be tested?
+
+## Required Model Asset Chain
+
+For each core model:
+
+1. Source article record
+2. Source evidence excerpts
+3. Human-readable Markdown card
+4. Machine-readable JSON model card
+5. Regression cases
+6. Selector examples or routing rules
+7. Validation report
+
+## Required Model JSON Fields
+
+Model JSON must include the required fields from `schemas/model_card.schema.json`.
+
+Recommended fields from the GPT plan should be included for v0.1 unless a field is explicitly deferred in the localization report.
+
+## Stability Assessment
+
+Each model must include stability assessment across:
+
+- 概念清晰度
+- 机制稳定性
+- 边界清晰度
+- 来源证据质量
+- 回归测试表现
+
+Each model must record:
+
+- `stability_level`
+- `reason`
+- `next_stabilization_action`
+
+## Index Rule
+
+Machine-readable model assets are indexed in `models/model_index.json`.
+
+Human-readable cards are indexed in `cards/card_index.md`.
+
+Both indexes must be updated whenever a model or card is added, renamed, deprecated, or materially reclassified.
+```
+
+- [ ] **Step 3: Write localization diff report**
+
+Create `reports/GPT规划落地差异检查_v0.1.md` with these sections and fill it from the GPT planning document:
+
+```markdown
+# GPT 规划落地差异检查 v0.1
+
+## Source Plan
+
+`C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\GPT成果\2026-06-16-核心模型抽取样板 v0.1.md`
+
+## Adopted Into Local Rules
+
+## Adopted Into Local Schema
+
+## Adopted Into Local Workflow
+
+## Adopted Into Tooling Plan
+
+## Differences From Current Repository
+
+## Deferred Items
+
+## Owner Review Questions
+```
+
+- [ ] **Step 4: Record decision**
+
+Append to `docs/DECISIONS.md`:
+
+```markdown
+## Decision 011: GPT plans must be localized before implementation
+
+Status: Accepted
+
+Reason:
+
+GPT planning documents may not know the current local repository state, existing constraints, missing contracts, or prior owner decisions.
+
+Codex must first convert each GPT plan into local rules, schemas, workflow, tooling expectations, and validation gates before implementing content.
+```
+
+---
+
+### Task 2: Define Model Card Contract And Schema
+
+**Files:**
+- Create: `docs/MODEL_CARD_CONTRACT.md`
+- Create: `schemas/model_card.schema.json`
+- Modify: `schemas/README.md`
+
+- [ ] **Step 1: Write Markdown card contract**
+
+Create `docs/MODEL_CARD_CONTRACT.md` with exactly these required card sections:
+
+```markdown
+# Model Card Contract
+
+Each human-readable model card in `cards/` must include these sections in Chinese content:
+
+## 模型名称
+## 模型 ID
+## 一句话定义
+## 模型类型
+## 所在流程位置
+## 来源文章
+## 来源证据片段
+## 核心问题
+## 核心机制
+## 输入类型
+## 输出类型
+## 适用场景
+## 不适用场景
+## 调用关键词
+## 负向触发条件
+## 相关模型
+## 冲突模型
+## 学科底座关联
+## 常见误用
+## 失败信号
+## 可信度等级
+## 稳固性状态
+## 稳定性评估
+## 回归测试状态
+## 示例输入
+## 示例输出
+## 输出契约
+## 深度控制
+## 产品化建议
+## 版本信息
+
+Cards may include additional explanatory sections after the required sections.
+
+Required sections may contain `无` only when the model genuinely has no value for that field, and the reason must be clear.
+```
+
+- [ ] **Step 2: Create full model card JSON schema**
+
+Create `schemas/model_card.schema.json` based on the GPT plan's schema, with these additions:
+
+- Add Chinese `description` to every property.
+- Include recommended fields: `trigger_keywords`, `negative_triggers`, `related_models`, `conflicting_models`, `disciplinary_anchors`, `example_inputs`, `example_outputs`, `output_contract`, `depth_control`, `stabilization_path`, `version`, `last_updated`.
+- Use enum values from the GPT plan:
+  - `model_type`: `routing_model`, `deep_modeling_model`, `lens_model`, `diagnostic_model`, `evaluation_model`, `generation_model`, `conflict_resolution_model`, `stabilization_model`
+  - `pipeline_position`: `pre_analysis`, `analysis`, `deep_analysis`, `synthesis`, `red_team`, `evaluation`, `post_processing`
+  - `confidence_level`: `high`, `medium`, `low`
+  - `regression_status`: `not_started`, `pending`, `in_progress`, `passed`, `failed`, `needs_rebuild`
+- Set `selection_priority` minimum 1 and maximum 10.
+- Require `stability_profile.stability_level`, `stability_profile.needs_stabilization`, `stability_profile.main_risks`, `stability_profile.reason`, and `stability_profile.next_stabilization_action`.
+
+- [ ] **Step 3: Update schema README**
+
+Update `schemas/README.md` so it lists `model_card.schema.json` as the authoritative schema for machine-readable model cards.
+
+---
+
+### Task 3: Define Source, Regression, And Index Schemas
+
+**Files:**
+- Modify: `schemas/source_article.schema.json`
+- Modify: `schemas/source_excerpt.schema.json`
+- Modify: `schemas/regression_case.schema.json`
+- Create: `schemas/model_index.schema.json`
+- Create: `schemas/card_index.schema.json`
+
+- [ ] **Step 1: Add descriptions to existing schemas**
+
+For `source_article.schema.json`, `source_excerpt.schema.json`, and `regression_case.schema.json`, add Chinese `description` fields for every property.
+
+- [ ] **Step 2: Strengthen regression schema**
+
+Update `schemas/regression_case.schema.json` so `case_type` uses enum:
+
+```json
+["positive", "boundary", "misuse"]
+```
+
+- [ ] **Step 3: Create model index schema**
+
+Create `schemas/model_index.schema.json` with this structure:
+
+```json
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Model Index",
+  "type": "object",
+  "required": ["index_version", "last_updated", "models"],
+  "properties": {
+    "index_version": {
+      "type": "string",
+      "description": "索引版本。"
+    },
+    "last_updated": {
+      "type": "string",
+      "description": "索引最后更新时间。"
+    },
+    "models": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "required": [
+          "model_id",
+          "model_name",
+          "model_type",
+          "pipeline_position",
+          "model_file",
+          "card_file",
+          "source_article_count",
+          "source_evidence_count",
+          "regression_case_count",
+          "stability_level",
+          "regression_status",
+          "status"
+        ],
+        "properties": {
+          "model_id": {"type": "string", "description": "模型 ID。"},
+          "model_name": {"type": "string", "description": "模型中文名称。"},
+          "model_type": {"type": "string", "description": "模型类型。"},
+          "pipeline_position": {"type": "string", "description": "模型所在流程位置。"},
+          "model_file": {"type": "string", "description": "模型 JSON 文件路径。"},
+          "card_file": {"type": "string", "description": "Markdown 模型卡文件路径。"},
+          "source_article_count": {"type": "integer", "description": "引用来源文章数量。"},
+          "source_evidence_count": {"type": "integer", "description": "引用证据片段数量。"},
+          "regression_case_count": {"type": "integer", "description": "回归测试用例数量。"},
+          "stability_level": {"type": "string", "description": "稳固性等级。"},
+          "regression_status": {"type": "string", "description": "回归测试状态。"},
+          "status": {"type": "string", "description": "索引条目状态，例如 draft、active、deprecated。"}
+        }
+      }
+    }
+  }
+}
+```
+
+- [ ] **Step 4: Create card index schema**
+
+Create `schemas/card_index.schema.json` with this structure:
+
+```json
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Card Index Metadata",
+  "type": "object",
+  "required": ["index_version", "last_updated", "required_columns"],
+  "properties": {
+    "index_version": {"type": "string", "description": "卡片索引版本。"},
+    "last_updated": {"type": "string", "description": "最后更新时间。"},
+    "required_columns": {
+      "type": "array",
+      "description": "card_index.md 表格必须包含的列名。",
+      "items": {"type": "string"}
+    }
+  }
+}
+```
+
+---
+
+### Task 4: Define Model Extraction Workflow
+
+**Files:**
+- Create: `docs/MODEL_EXTRACTION_WORKFLOW.md`
+- Modify: `docs/WORKFLOW.md`
+
+- [ ] **Step 1: Write model extraction workflow**
+
+Create `docs/MODEL_EXTRACTION_WORKFLOW.md` with these stages:
+
+```markdown
+# Model Extraction Workflow
+
+## Stage 0: GPT Plan Intake
+
+Input from user:
+
+- GPT planning document path
+- Source article paths
+- Existing model/application material paths
+- Target model IDs
+- Whether placeholder evidence is allowed
+- Whether the goal is rules only, content extraction, or full chain
+
+Output:
+
+- Local execution plan
+- Open questions
+- Owner review gate
+
+## Stage 1: Rules, Schema, Index, And Workflow Foundation
+
+Codex actions:
+
+- Convert GPT planning document into local rules.
+- Define or update schemas.
+- Define or update indexes.
+- Define workflow gates.
+- Define validation expectations.
+
+Output:
+
+- Rules docs
+- Schema files
+- Index contracts
+- Workflow docs
+- Difference report
+
+Owner confirmation:
+
+- Owner reviews rules/schema/workflow before content extraction.
+
+## Stage 2: Source And Evidence Preparation
+
+Codex actions:
+
+- Register source articles.
+- Extract source evidence excerpts.
+- Mark placeholder evidence explicitly if source text is unavailable or insufficient.
+
+Output:
+
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+
+Checks:
+
+- Every excerpt references a known source article.
+- Every source ID is unique.
+
+## Stage 3: Model Asset Extraction
+
+Codex actions:
+
+- Write machine-readable model JSON.
+- Write human-readable Markdown card.
+- Update model and card indexes.
+
+Output:
+
+- `models/<model_id>.model.json`
+- `cards/<model_id>.md`
+- `models/model_index.json`
+- `cards/card_index.md`
+
+Checks:
+
+- JSON passes schema.
+- Markdown card contains required sections.
+- Source references resolve.
+
+## Stage 4: Regression And Selector Preparation
+
+Codex actions:
+
+- Write at least five regression cases per core model.
+- Include positive, boundary, and misuse cases.
+- Add selector rules and selector examples.
+
+Output:
+
+- Regression case files or consolidated regression case JSON.
+- Selector rules.
+- Selector examples.
+
+Checks:
+
+- Every core model has at least five cases.
+- Each model has positive, boundary, and misuse cases.
+- Selector examples return model IDs and reasons.
+
+## Stage 5: Validation And Audit
+
+Codex actions:
+
+- Run local validation scripts.
+- Generate validation report.
+- Generate extraction audit report.
+
+Output:
+
+- `reports/validation_report.md`
+- `reports/<model_id>_extraction_audit.md` or session-level audit report.
+
+## Stage 6: Owner Review
+
+Owner reviews:
+
+- Model definition
+- Field completeness
+- Evidence quality
+- Boundary and misuse cases
+- Selector behavior
+- Open questions
+
+Content is not considered stable until owner review completes.
+```
+
+- [ ] **Step 2: Link workflow from existing workflow doc**
+
+Add a short reference in `docs/WORKFLOW.md`:
+
+```markdown
+For detailed model extraction gates, see `docs/MODEL_EXTRACTION_WORKFLOW.md`.
+```
+
+---
+
+### Task 5: Add Index Files
+
+**Files:**
+- Create: `models/model_index.json`
+- Create: `cards/card_index.md`
+- Modify: `models/README.md`
+- Modify: `cards/README.md`
+
+- [ ] **Step 1: Create machine-readable model index**
+
+Create `models/model_index.json` with current two models:
+
+```json
+{
+  "index_version": "0.1",
+  "last_updated": "2026-06-16",
+  "models": [
+    {
+      "model_id": "qpi",
+      "model_name": "QPI 三元定性模型",
+      "model_type": "routing_model",
+      "pipeline_position": "pre_analysis",
+      "model_file": "models/qpi.model.json",
+      "card_file": "cards/qpi.md",
+      "source_article_count": 2,
+      "source_evidence_count": 5,
+      "regression_case_count": 5,
+      "stability_level": "B",
+      "regression_status": "pending",
+      "status": "draft"
+    },
+    {
+      "model_id": "intellectual_archaeology",
+      "model_name": "思想考古学",
+      "model_type": "deep_modeling_model",
+      "pipeline_position": "deep_analysis",
+      "model_file": "models/intellectual_archaeology.model.json",
+      "card_file": "cards/intellectual_archaeology.md",
+      "source_article_count": 2,
+      "source_evidence_count": 5,
+      "regression_case_count": 5,
+      "stability_level": "B",
+      "regression_status": "pending",
+      "status": "draft"
+    }
+  ]
+}
+```
+
+- [ ] **Step 2: Create human-readable card index**
+
+Create `cards/card_index.md`:
+
+```markdown
+# Card Index
+
+| Model ID | 模型名称 | 类型 | 流程位置 | Card | Model JSON | 稳固性 | 回归状态 | 状态 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| qpi | QPI 三元定性模型 | routing_model | pre_analysis | `cards/qpi.md` | `models/qpi.model.json` | B | pending | draft |
+| intellectual_archaeology | 思想考古学 | deep_modeling_model | deep_analysis | `cards/intellectual_archaeology.md` | `models/intellectual_archaeology.model.json` | B | pending | draft |
+```
+
+- [ ] **Step 3: Update README files**
+
+Update `models/README.md` to state:
+
+```markdown
+`model_index.json` is the machine-readable model registry.
+```
+
+Update `cards/README.md` to state:
+
+```markdown
+`card_index.md` is the human-readable model card registry.
+```
+
+---
+
+### Task 6: Upgrade Validation Tools
+
+**Files:**
+- Modify: `scripts/validate_model_library.py`
+- Create: `scripts/check_card_contract.py`
+- Test: `tests/test_validate_model_library.py`
+- Create or modify: `tests/test_card_contract.py`
+
+- [ ] **Step 1: Add failing tests for schema expectations**
+
+Add tests that expect validation to fail when:
+
+- Model JSON omits `trigger_keywords`.
+- Model JSON has `selection_priority` outside 1-10.
+- Model JSON uses `model_type` outside the enum.
+- `stability_profile` omits `reason`.
+- `models/model_index.json` references a missing model file.
+- `cards/card_index.md` omits a known model.
+
+- [ ] **Step 2: Add failing tests for card sections**
+
+Create tests that expect `check_card_contract.py` to report a missing required heading when a card lacks `## 调用关键词`.
+
+- [ ] **Step 3: Implement schema validation**
+
+Update `scripts/validate_model_library.py` to:
+
+- Load JSON schemas from `schemas/`.
+- Validate model JSON against `schemas/model_card.schema.json`.
+- Validate source articles, source excerpts, regression cases, and model index.
+- Check model index file paths exist.
+- Check every model appears in `models/model_index.json`.
+- Check every card appears in `cards/card_index.md`.
+- Keep existing reference checks.
+
+If the standard library is insufficient for full JSON Schema validation, implement the local subset required by current schemas and record that limitation in `reports/validation_report.md`.
+
+- [ ] **Step 4: Implement card contract checker**
+
+Create `scripts/check_card_contract.py` to:
+
+- Read `docs/MODEL_CARD_CONTRACT.md`.
+- Extract required `##` headings.
+- Check each `cards/*.md` file except `card_index.md`.
+- Print missing headings.
+- Return non-zero on missing headings.
+
+- [ ] **Step 5: Verify tests**
+
+Run:
+
+```powershell
+python -m unittest discover -s tests -p "test*.py" -v
+```
+
+Expected:
+
+```text
+OK
+```
+
+---
+
+### Task 7: Add Selector Demo Plan And Minimal Script
+
+**Files:**
+- Create: `scripts/run_selector_demo.py`
+- Modify: `selector/selector_rules.json`
+- Modify: `selector/selector_examples.json`
+- Test: add selector tests if practical
+
+- [ ] **Step 1: Align selector output shape**
+
+Ensure selector demo outputs:
+
+```json
+{
+  "recommended_models": [
+    {
+      "model_id": "qpi",
+      "score": 0.92,
+      "reason": "输入包含问题定性需求。"
+    }
+  ],
+  "not_recommended_models": [],
+  "routing_notes": "先用 QPI 判断问题类型。"
+}
+```
+
+- [ ] **Step 2: Implement no-LLM selector demo**
+
+Create `scripts/run_selector_demo.py` using only Python standard library.
+
+Scoring rules:
+
+- trigger keyword hit: `+0.2`
+- input type match: `+0.2`
+- pipeline stage match: `+0.2`
+- complexity signals: `+0.2`
+- selection priority contribution: `selection_priority / 100`
+- negative trigger hit: `-0.3`
+- do_not_call_when hit: `-0.5`
+
+The script must read model JSON and selector examples from local files.
+
+- [ ] **Step 3: Add README command**
+
+Document:
+
+```powershell
+python scripts\run_selector_demo.py
+```
+
+---
+
+### Task 8: Owner Review Gate
+
+**Files:**
+- Modify: `reports/GPT规划落地差异检查_v0.1.md`
+- Create: `reports/规则Schema工作流检查摘要_v0.1.md`
+
+- [ ] **Step 1: Write foundation check summary**
+
+Create `reports/规则Schema工作流检查摘要_v0.1.md` with:
+
+```markdown
+# 规则 Schema 工作流检查摘要 v0.1
+
+## Completed
+
+## Files Changed
+
+## Checks Run
+
+## Known Limits
+
+## Owner Review Checklist
+
+- GPT 规划是否已正确本地化？
+- card contract 是否覆盖模型卡样例？
+- model schema 是否覆盖机器 JSON 样例？
+- index 设计是否满足当前和未来扩展？
+- 工作流 gate 是否足以防止直接跳内容？
+- 工具需求是否足够但不过度？
+
+## Do Not Proceed Before Owner Confirms
+
+Do not repair QPI or Intellectual Archaeology content until this foundation is reviewed.
+```
+
+- [ ] **Step 2: Stop for owner review**
+
+After validation passes, stop and ask the owner to review the foundation. Do not continue to model content repair in the same step unless the owner explicitly says to continue.
+
+---
+
+## Verification Commands
+
+Run these before claiming the foundation is ready:
+
+```powershell
+python -m unittest discover -s tests -p "test*.py" -v
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+python scripts\run_selector_demo.py
+```
+
+Expected:
+
+- Unit tests pass.
+- Card contract check passes after cards are brought into contract, or reports known current failures before content repair.
+- Model library validation reports schema/index status clearly.
+- Selector demo returns recommended models with score, reason, and routing notes.
+
+## Self-Review Checklist
+
+- The plan blocks content repair until rules/schema/workflow/index foundation is reviewed.
+- GPT planning document is treated as upstream input, not direct implementation law.
+- Both machine and human indexes are defined.
+- Index maintenance policy is explicit.
+- The dual-track model is represented:
+  - workflow/tooling track
+  - content extraction track
+- Every new tool has a clear reason.
+- No database, backend, frontend, RAG, or platform scope is introduced.
+

docs/superpowers/plans/2026-06-17-contract-hardening-selector-calibration.md

@@ -0,0 +1,80 @@
+# Contract Hardening Selector Calibration Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Harden the third-round model-library contract and selector behavior without adding a third model, upgrading stable status, or processing owner-supplied raw QPI samples before they are available.
+
+**Architecture:** Keep the MVP file-first. Model-specific output contracts live in model JSON and are validated by `scripts/validate_model_library.py`; selector runtime behavior is driven by `selector/selector_rules.json`; per-round CCRA review bundles are stored under dated subdirectories. QPI contextual routing rules are documented now, while real owner case preprocessing remains a later input-dependent step.
+
+**Tech Stack:** JSON, Markdown, Python standard library, PowerShell file operations.
+
+---
+
+### Task 1: Review Bundle Round Structure
+
+**Files:**
+- Move existing files under `ccra_review_bundle/round-02_2026-06-16_second-audit/`
+- Create `ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/`
+- Modify `knowledge_assets/08_CCRA模型库MVP质量门与交接协议.md`
+- Modify `docs/DECISIONS.md`
+- Modify `README.md`
+
+- [ ] Move the second-round flat bundle files into the round-02 directory.
+- [ ] Create an empty round-03 directory for the new audit package.
+- [ ] Document that `ccra_review_bundle/` is now a per-round archive root.
+- [ ] Keep per-round command logs and temporary review materials out of `knowledge_assets/`.
+
+### Task 2: Model-Specific Output Contract Validation
+
+**Files:**
+- Modify `schemas/model_card.schema.json`
+- Modify `models/qpi.model.json`
+- Modify `models/intellectual_archaeology.model.json`
+- Modify `scripts/validate_model_library.py`
+- Modify `tests/test_validate_model_library.py`
+
+- [ ] Add `structured_output_contract` to the schema properties without adding it to global top-level required.
+- [ ] Update QPI definition and output contract for subject-context-dynamic routing.
+- [ ] Keep IA contract model-specific and include the required depth-gate fields.
+- [ ] Add model-specific required contract checks for `qpi` and `intellectual_archaeology`.
+- [ ] Add unit coverage proving missing QPI/IA model-specific output contract fields are reported.
+
+### Task 3: QPI and IA Rules Documentation
+
+**Files:**
+- Create `docs/QPI_CONTEXTUAL_ROUTING_RULES.md`
+- Create `docs/INTELLECTUAL_ARCHAEOLOGY_DEPTH_GATE.md`
+- Modify `reports/content_review_report_v0.2.md`
+
+- [ ] Document QPI as a subject-context expectation-reality gap routing model.
+- [ ] Distinguish `intra_frame_mixed` from `inter_viewpoint_divergence`.
+- [ ] Document context sufficiency, provisional classification, governance-load issue rules, and misframing risks.
+- [ ] Document IA should-call false cases, max-depth derivation, and non-default `philosophical_bedrock`.
+- [ ] Fix the QPI report field list to include `classification`.
+
+### Task 4: Selector Runtime Config Source
+
+**Files:**
+- Modify `selector/selector_rules.json`
+- Modify `scripts/run_selector_demo.py`
+- Modify `scripts/run_selector_regression.py`
+- Create `selector/selector_calibration_inputs.json`
+
+- [ ] Move scoring signals and hard no-call signals into `selector_rules.json`.
+- [ ] Make `run_selector_demo.py` load runtime rules from `selector_rules.json`.
+- [ ] Apply hard no-call gating before positive scoring unless an explicit override phrase is present.
+- [ ] Add calibration inputs covering fact lookup, rewrite, translation, direct execution, QPI-only, IA-after-QPI, model extraction, false positive traps, and mixed QPI cases.
+- [ ] Keep calibration inputs marked as draft and owner-reviewable.
+
+### Task 5: Verification and Third-Round Handoff
+
+**Files:**
+- Modify or create reports under `reports/`
+- Later create files under `ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/`
+
+- [ ] Run `python scripts/rebuild_indexes.py --write` if model/index-relevant fields changed.
+- [ ] Run the required full check commands.
+- [ ] Record command outcomes in reports.
+- [ ] Generate the round-03 CCRA review bundle after validation.
+- [ ] Keep `qpi` and `intellectual_archaeology` at `draft / B / pending`.
+

knowledge_assets/00_用户背景与产品上下文.md

@@ -0,0 +1,70 @@
+# 用户背景与产品上下文
+
+version: 0.1
+
+last_updated: 2026-06-16
+
+status: draft
+
+## 项目定位
+
+`the-mindscape-of-bro-tsong` 是 The Mindscape of Bro Tsong 的产品和应用边界。
+
+当前阶段是 `model_library_mvp`，目标是建立一个 file-first 的认知模型库 MVP。
+
+## 当前 MVP 目标
+
+验证少量核心认知模型能否被整理为：
+
+- 人读 Markdown 模型卡
+- 机器可读 JSON 模型卡
+- 来源文章记录
+- 来源证据片段
+- 回归测试用例
+- 最小规则选择器
+- 本地校验对象
+
+## 第一批样板模型
+
+- QPI
+- 思想考古学
+
+QPI 用于前置问题定性和路由。
+
+思想考古学用于中重型问题的深度建模。
+
+## 边界
+
+本仓库不做：
+
+- 完整前端
+- 后端服务
+- 数据库
+- 向量数据库
+- 完整 RAG 系统
+- 用户账户
+- 认证
+- 支付
+- 公共平台
+- 多用户协作
+
+## 周边仓库关系
+
+- `knowledge-vault`: 原始文章、上游讨论和源材料。
+- `ccpe-system`: 专家智能体、运行时、协议、评估和治理规格。
+- `skills-vault`: 可复用自动化工具和安装型 Skill 的源头。
+- `writing-workbench`: 深度写作生产工作台。
+- `video-workbench`: 视频和呈现型输出工作台。
+
+本仓库消费这些仓库的产物，但不复制它们的 canonical 内容。
+
+## 本地 source of truth
+
+- 项目规则：`docs/`
+- 模型 JSON：`models/`
+- 人读模型卡：`cards/`
+- 来源索引：`sources/`
+- 回归测试：`tests/`
+- selector：`selector/`
+- 校验脚本：`scripts/`
+- 过程报告和交接：`reports/`

knowledge_assets/01_核心模型地图.md

@@ -0,0 +1,62 @@
+# 核心模型地图
+
+version: 0.1
+
+last_updated: 2026-06-16
+
+status: draft
+
+## 当前模型
+
+当前模型地图以 `models/model_index.json` 为机器索引源，以 `cards/card_index.md` 为人读索引源。
+
+Index 维护采用“每次资产变化增量同步 + 关键节点全量重建 / 全量校验”的混合策略。
+
+## QPI
+
+- model_id: `qpi`
+- model_type: `routing_model`
+- pipeline_position: `pre_analysis`
+- stability_level: `B`
+- regression_status: `pending`
+- source of truth:
+  - `models/qpi.model.json`
+  - `cards/qpi.md`
+
+QPI 用于判断当前输入更接近提问、难题、课题或混合型。
+
+## 思想考古学
+
+- model_id: `intellectual_archaeology`
+- model_type: `deep_modeling_model`
+- pipeline_position: `deep_analysis`
+- stability_level: `B`
+- regression_status: `pending`
+- source of truth:
+  - `models/intellectual_archaeology.model.json`
+  - `cards/intellectual_archaeology.md`
+
+思想考古学用于从表层应用逐层下钻到哲学基岩，识别模型或判断背后的深层假设、核心机理和动态韧性来源。
+
+## 调用关系
+
+QPI 通常在前。
+
+如果 QPI 判断输入属于中重型难题、课题或高复用模型抽取任务，可以进入思想考古学。
+
+如果输入只是明确事实查询、轻量改写或直接执行任务，不应默认调用思想考古学。
+
+## 当前扩展原则
+
+不要在 QPI 和思想考古学稳定前快速扩展大量模型。
+
+新增模型前必须先满足：
+
+- source article record
+- source evidence excerpts
+- model JSON
+- Markdown card
+- regression cases
+- selector examples or routing rules
+- model/card index entries
+- validation report

knowledge_assets/02_模型卡结构规范.md

@@ -0,0 +1,86 @@
+# 模型卡结构规范
+
+version: 0.1
+
+last_updated: 2026-06-16
+
+status: draft
+
+## Source Of Truth
+
+本文件是长期知识资产摘要。
+
+操作性 source of truth 位于：
+
+- `docs/MODEL_CARD_CONTRACT.md`
+- `schemas/model_card.schema.json`
+
+## 基本原则
+
+Markdown card 用于人读审查。
+
+JSON model card 用于系统调用、selector、校验和未来应用集成。
+
+字段名使用英文。
+
+中文来源的字段值和 Markdown 内容保持中文，避免翻译漂移。
+
+## Markdown Card 必需章节
+
+模型卡必须覆盖：
+
+- 模型名称
+- 模型 ID
+- 一句话定义
+- 模型类型
+- 所在流程位置
+- 来源文章
+- 来源证据片段
+- 核心问题
+- 核心机制
+- 输入类型
+- 输出类型
+- 适用场景
+- 不适用场景
+- 调用关键词
+- 负向触发条件
+- 相关模型
+- 冲突模型
+- 学科底座关联
+- 常见误用
+- 失败信号
+- 可信度等级
+- 稳固性状态
+- 稳定性评估
+- 回归测试状态
+- 示例输入
+- 示例输出
+- 输出契约
+- 深度控制
+- 产品化建议
+- 版本信息
+
+## JSON Model Card 必需方向
+
+JSON model card 必须回答：
+
+- 什么时候调用？
+- 什么时候不调用？
+- 输入是什么？
+- 输出是什么？
+- 调用优先级是多少？
+- 位于流程哪里？
+- 前后相关模型是什么？
+- 冲突模型是什么？
+- 如何判断调用失败？
+- 稳固性如何？
+- 如何继续稳定化？
+
+## 校验
+
+使用：
+
+```powershell
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+```

knowledge_assets/03_核心模型抽取样板.md

@@ -0,0 +1,106 @@
+# 核心模型抽取样板
+
+version: 0.2
+
+last_updated: 2026-06-16
+
+status: draft
+
+## Source Documents
+
+原始 GPT 规划位于：
+
+`C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\GPT成果\2026-06-16-核心模型抽取样板 v0.1.md`
+
+本仓库本地化规则位于：
+
+- `docs/GPT_PLAN_LOCALIZATION_PROTOCOL.md`
+- `docs/MODEL_EXTRACTION_RULES.md`
+- `docs/MODEL_EXTRACTION_WORKFLOW.md`
+
+## 核心判断
+
+GPT 规划不是本地可直接执行规则。
+
+Codex 必须先把 GPT 规划转成：
+
+- local rules
+- schemas
+- workflow gates
+- indexes
+- validation tools
+- owner review points
+
+再进入内容抽取。
+
+## 模型抽取链路
+
+```text
+原始文章 / 代表文本
+-> source article record
+-> source evidence excerpts
+-> human-readable Markdown card
+-> machine-readable JSON model card
+-> regression cases
+-> selector examples or routing rules
+-> model/card indexes
+-> validation report
+```
+
+## 双工模式
+
+模型抽取必须分为两条线：
+
+1. workflow/tooling track
+2. content extraction track
+
+内容抽取不能吸收缺失的规则、schema、validator、index 或 workflow 工作。
+
+## 当前本地样板
+
+当前本地样板模型：
+
+- QPI
+- 思想考古学
+
+当前验证命令：
+
+```powershell
+python scripts\rebuild_indexes.py --check
+python -m unittest discover -s tests -p "test*.py" -v
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+python scripts\run_selector_demo.py
+python scripts\run_selector_regression.py
+python scripts\check_model_card_sync.py
+```
+
+## v0.2 内容稳定化补充
+
+工程 contract 通过不等于内容稳定。
+
+字段级 evidence coverage 必须区分：
+
+- `direct_source`
+- `derived_from_source`
+- `product_decision`
+- `red_team_inference`
+- `owner_decision`
+
+source excerpt 必须标记：
+
+- `quote_status`
+- `source_location`
+
+`quote_status=exact` 表示准确摘录；压缩摘录必须使用 `quote_status=condensed` 并在 notes 中说明。
+
+回归测试在内容稳定化阶段每个核心模型至少 15 条，并覆盖：
+
+- positive
+- boundary
+- misuse
+- no_call
+- selector_gate
+- pipeline
+
+selector v0.2 仍然是规则 selector，不引入 LLM。它必须输出 selected/rejected models、score breakdown、penalties 和 no-call 状态。

knowledge_assets/06_模型稳固性评级规则.md

@@ -0,0 +1,64 @@
+# 模型稳固性评级规则
+
+version: 0.1
+
+last_updated: 2026-06-16
+
+status: draft
+
+## 评级维度
+
+每个模型必须从五个维度评估：
+
+- 概念清晰度
+- 机制稳定性
+- 边界清晰度
+- 来源证据质量
+- 回归测试表现
+
+## 等级
+
+`A`: 五个维度都较稳定，可进入核心调用。
+
+`B`: 基本可用，但需要边界案例测试。
+
+`C`: 有启发，但系统调用风险较高。
+
+`D`: 不适合进入模型库，需要重构。
+
+## 必填稳定性字段
+
+每个 JSON model card 的 `stability_profile` 必须包含：
+
+- `stability_level`
+- `needs_stabilization`
+- `main_risks`
+- `reason`
+- `next_stabilization_action`
+
+## 当前样板评级
+
+QPI:
+
+- stability_level: `B`
+- reason: 三分结构清晰，适合作为入口路由模型，但需要补充大量边界案例，防止过度升维或降维。
+
+思想考古学:
+
+- stability_level: `B`
+- reason: 纵向下潜机制清晰，适合深度建模，但七层结构和停止条件需要进一步稳定。
+
+QPI 和思想考古在第二轮内容稳定化完成并通过 CCRA / Owner 审查前，保持 B 级，不因 schema、contract、index check 或 selector demo 通过而升级。
+
+## 升级条件
+
+模型不能仅因为字段完整就升级。
+
+升级必须同时满足：
+
+- 来源证据充分
+- 边界清楚
+- misuse case 能暴露误用
+- regression cases 覆盖 positive、boundary、misuse
+- selector 不会在明显负向触发时误调用
+- owner 或 CCRA 完成内容审查

knowledge_assets/07_产品规划过程记录.md

@@ -0,0 +1,58 @@
+# 产品规划过程记录
+
+version: 0.1
+
+last_updated: 2026-06-16
+
+status: draft
+
+## 起点
+
+本仓库初始化为 The Mindscape of Bro Tsong 的 `model_library_mvp` 产品边界。
+
+初始目标是验证 QPI 和思想考古学两个模型能否被整理成可读、可调用、可追溯、可测试的模型资产。
+
+## 关键过程
+
+1. 初始化 file-first 目录结构。
+2. 根据 GPT 规划尝试抽取 QPI 和思想考古学。
+3. 发现直接按 GPT 规划现改会导致字段缺失、schema 不完整、workflow 缺位。
+4. 决定 GPT 规划必须先本地化为规则、schema、workflow、index 和工具。
+5. 建立 ChatGPT 交接机制和长期知识资产机制。
+6. 修复 QPI 和思想考古学的 JSON 与 Markdown card，使其通过本地 contract。
+7. 为避免新会话上传文件过多，后续 Codex 交接采用 CCRA review bundle 压缩审核协议；长期协议进知识库，本轮执行证据通过新会话上传。
+
+## 当前关键决策
+
+详见 `docs/DECISIONS.md`。
+
+当前最重要的决策包括：
+
+- file-first architecture
+- JSON for machine-readable model data
+- Markdown for human-readable model cards
+- rule-based selector in v0.1
+- GPT plans must be localized before implementation
+- field names English and field content Chinese
+
+## 当前验证状态
+
+截至 2026-06-16：
+
+- Unit tests: PASS
+- Card contract: PASS
+- Model library validation: PASS
+- Selector demo: PASS
+
+详见：
+
+- `reports/validation_report.md`
+- `reports/内容修复检查摘要_v0.1.md`
+
+## 下一步讨论方向
+
+- 是否扩展第三个核心模型
+- 是否强化 selector scoring
+- 是否将抽取智能体、检验智能体、评分模型作为 CCPE 或 skills-vault 需求
+- 是否将 regression cases 拆分为按模型文件
+- 是否为知识资产建立自动摘要或索引工具

knowledge_assets/08_CCRA模型库MVP质量门与交接协议.md

@@ -0,0 +1,383 @@
+# CCRA 模型库 MVP 质量门与交接协议
+
+version: 0.1
+
+last_updated: 2026-06-16
+
+status: active
+
+## 1. 协议来源
+
+本文件综合以下 CCRA 指导文件：
+
+- `2026-06-16-核心模型抽取样板 v0.1.md`
+- `CCRA_Codex指导意见_Index更新策略与下一轮执行_v0.2_2026-06-16.md`
+- `CCRA_Codex指导意见_模型库MVP第二轮内容稳定化_v0.3_2026-06-16.md`
+- `CCRA_下一轮审核包压缩上传协议_v0.1_2026-06-16.md`
+
+如果模型质量规则之间发生冲突，优先级为：
+
+```text
+v0.3 内容稳定化
+> v0.2 Index 策略
+> v0.1 核心模型抽取样板
+```
+
+审核包压缩上传协议只约束交接与上传方式，不覆盖模型质量规则。
+
+## 2. 当前阶段边界
+
+当前阶段是 `model_library_mvp`。
+
+本阶段目标是建立 file-first 认知模型库 MVP，让 QPI 和思想考古学两个样板模型具备：
+
+- 可读：Markdown card 可供人审查。
+- 可追溯：source article 和 source excerpt 能支撑字段来源。
+- 可调用：JSON model card 有稳定输出契约。
+- 可测试：regression cases 能覆盖正例、边界和误用。
+- 可路由：rule-based selector 能推荐和拒绝模型。
+
+本阶段不做：
+
+- 完整前端
+- 后端服务
+- 数据库
+- RAG
+- 知识图谱
+- 用户系统
+- 认证 / 支付
+- 商业平台
+- 多人协作系统
+- 完整问题回答系统
+- LLM selector
+
+## 3. 模型抽取链路
+
+核心模型进入模型库时，应按以下链路组织：
+
+```text
+原始文章 / 代表文本
+-> source article record
+-> source evidence excerpts
+-> Markdown card
+-> JSON model card
+-> regression cases
+-> selector rules / examples
+-> model/card indexes
+-> validation report
+-> CCRA review
+```
+
+模型抽取不是文章摘要。抽取目标是得到可复用、可边界化、可验证、可被 selector 调用的认知模型资产。
+
+GPT / CCRA 规划文件不能直接当作本地执行规则。Codex 必须先将规划本地化为：
+
+- local rules
+- schemas
+- workflow gates
+- indexes
+- validation tools
+- owner / CCRA review points
+
+## 4. Index 维护规则
+
+`models/model_index.json` 是机器可读模型注册表。
+
+`cards/card_index.md` 是人读模型卡索引。
+
+二者是导航层和注册表，不是模型内容本体。
+
+完整模型内容仍以以下文件为 source of truth：
+
+- `models/*.model.json`
+- `cards/*.md`
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+- `tests/*.regression.json`
+
+Index 维护采用混合策略：
+
+```text
+每次资产变化后增量同步
++
+关键节点全量重建或全量校验
+```
+
+关键节点包括：
+
+- ChatGPT / CCRA / owner 交接前
+- release 前
+- schema 变化后
+- 批量扩展模型后
+- 模型状态升级前
+- selector 依赖模型注册表前
+- 发现 index drift 后
+
+## 5. 内容稳定化质量门
+
+工程 contract 通过不等于内容稳定。
+
+模型不能仅因为以下事项通过就升级：
+
+- JSON 可解析
+- schema pass
+- Markdown required headings 存在
+- selector demo 能运行
+- index drift check pass
+
+核心模型升级必须经过：
+
+- evidence review
+- content review
+- regression review
+- selector review
+- owner / CCRA review
+
+QPI 和思想考古在通过内容审查前保持：
+
+- `status: draft`
+- `stability_level: B`
+- `regression_status: pending` 或 `in_progress`
+
+不得仅因 schema、contract、selector demo 或本地 validation 通过而升级为 stable。
+
+## 6. Evidence Coverage 规则
+
+source excerpt 必须区分证据状态。
+
+字段级 evidence coverage 至少区分：
+
+- `direct_source`: 原文直接支撑。
+- `derived_from_source`: 从原文合理推导。
+- `product_decision`: 产品化调用或 selector 规则。
+- `red_team_inference`: 边界、误用、防误召回推导。
+- `owner_decision`: Owner / CCRA 人工判断。
+
+source excerpt 应包含：
+
+- `quote_status`
+- `source_location`
+
+`quote_status` 取值：
+
+- `exact`: 准确原文摘录。
+- `condensed`: 压缩摘录。
+- `paraphrased`: 转述。
+
+如果 `quote_status=exact`，`raw_excerpt` 不应包含未说明的省略号。
+
+如果摘录为了节省篇幅而压缩，必须使用 `quote_status=condensed`，并在 notes 中说明。
+
+## 7. QPI 强化要求
+
+QPI 是前置路由模型，不是完整解决方案。
+
+QPI 输出契约必须能支持稳定路由，至少包含：
+
+- `problem_owner`
+- `problem_source`
+- `time_scale`
+- `scarcity_profile`
+- `dominant_scarcity`
+- `classification`
+- `classification_confidence`
+- `evidence_gap`
+- `misclassification_risk`
+- `recommended_next_step`
+- `next_model_candidates`
+
+QPI 必须能处理：
+
+- Question: 数据匮乏。
+- Problem: 路径、方法或资源匮乏。
+- Issue: 共识、确定性或动态秩序匮乏。
+- mixed state: 多类匮乏物同时存在。
+- no-call: 明确事实查询、纯改写、直接执行等不需要问题定性场景。
+
+QPI 必须识别误用风险：
+
+- 暴力降维
+- 恶意升维
+- 手段错配
+
+## 8. 思想考古强化要求
+
+思想考古学是深度建模模型，不是默认分析流程。
+
+它必须保留七层结构：
+
+1. application
+2. domain
+3. process
+4. purpose
+5. core_mechanism
+6. human_capability
+7. philosophical_bedrock
+
+但不得默认七层全量展开。
+
+输出契约必须包含：
+
+- `should_call`
+- `entry_reason`
+- `recommended_max_depth`
+- `layers_to_analyze`
+- `stop_reason`
+- `no_deeper_reason`
+- `assumptions_by_layer`
+- `validation_needed`
+- `action_implication`
+
+思想考古必须遵守最小充分下潜原则：
+
+```text
+如果继续下潜不再改变判断、路径、验证方式或行动边界，就应停止。
+```
+
+不应调用思想考古的场景包括：
+
+- 明确事实查询。
+- 低风险轻量改写。
+- 用户只需要直接执行。
+- 缺少足够材料，无法区分真实假设和空泛哲学化表达。
+
+## 9. Regression 扩展要求
+
+样板阶段每个核心模型至少 5 条 regression cases。
+
+进入内容稳定化阶段后，每个核心模型至少 15 条 regression cases。
+
+Regression cases 应覆盖：
+
+- positive
+- boundary
+- misuse
+- no_call
+- selector_gate
+- pipeline
+
+Regression tests 不只是代码测试，也用于检验：
+
+- 模型是否被正确调用。
+- 不该调用时是否能拒绝。
+- 混合型输入是否能暴露证据缺口。
+- selector 是否误召回。
+- 模型是否过度下潜或过度升维。
+
+按模型拆分的 regression 文件可以作为人审 source of truth；聚合文件可以供 validator 使用。
+
+## 10. Selector v0.2 原则
+
+selector 继续 rule-based。
+
+暂不引入 LLM selector。
+
+selector v0.2 应优先补强：
+
+- negative trigger first
+- no-call threshold
+- negative trigger penalty
+- score breakdown
+- rejected model reasons
+- QPI-before-IA gate
+- selector regression tests
+
+selector 输出应包含：
+
+- selected models
+- rejected models
+- scores
+- reasons
+- penalties
+- no-call status
+- routing notes
+
+思想考古不应仅因为出现“底层”“模型”“哲学”等词就被召回。问题定义未完成时，应先通过 QPI。
+
+## 11. CCRA 审核包规则
+
+新会话不要上传 30 个分散文件。
+
+由 Codex 本地生成。`ccra_review_bundle/` 是审核包归档根目录，不直接平铺放置单轮文件。每一轮应创建独立目录：
+
+```text
+ccra_review_bundle/
+  round-02_2026-06-16_second-audit/
+  round-03_2026-06-17_contract-hardening-selector-calibration/
+```
+
+单轮目录内部保持压缩上传协议的标准文件名：
+
+```text
+ccra_review_bundle/round-NN_YYYY-MM-DD_topic/
+  00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md
+  01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md
+  02_CURRENT_ASSET_PACK.md
+  03_REPORTS_DIFF_AND_COMMAND_LOG.md
+  BUNDLE_FILE_MANIFEST.md
+  optional_raw_changed_files.zip
+```
+
+推荐上传顺序：
+
+第一批：
+
+- `00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md`
+- `01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md`
+- `03_REPORTS_DIFF_AND_COMMAND_LOG.md`
+
+如果仍然过大，先上传：
+
+- `00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md`
+- `03_REPORTS_DIFF_AND_COMMAND_LOG.md`
+
+第二批按 CCRA 要求补：
+
+- `02_CURRENT_ASSET_PACK.md`
+- `optional_raw_changed_files.zip`
+- 或 CCRA 指定的原始文件
+
+## 12. 知识库边界规则
+
+适合放入知识库：
+
+- 稳定长期背景文件。
+- 核心模型地图。
+- 模型卡结构规范。
+- 稳固性评级规则。
+- 产品规划过程记录。
+- 已定稿的 CCRA 长期指导协议。
+
+不适合放入知识库：
+
+- 本轮 validation report。
+- command log。
+- 临时 changed files manifest。
+- 临时 selector regression report。
+- 临时 content review report。
+- 未审定的中间状态文件。
+- 下一轮审核包合并文档整体。
+
+判断标准：
+
+```text
+回答“以后一直怎么做”的文档，可以进知识库。
+回答“这轮做了什么、改了什么、哪些 PASS/FAIL”的文档，不进知识库。
+```
+
+## 13. 推荐分工
+
+Codex:
+
+- 本地执行者。
+- 校验脚本运行者。
+- 审核包生成器。
+- 预审疑点整理者。
+
+CCRA:
+
+- 产品质量门槛判断者。
+- 模型产品化审查者。
+- 是否进入下一阶段的判断者。
+
+Codex 不应替代 CCRA 做最终内容质量审查。

knowledge_assets/README.md

@@ -0,0 +1,16 @@
+# Knowledge Assets
+
+This folder contains stable, long-term reusable knowledge documents for the model library MVP.
+
+It is the durable explanation layer for ChatGPT, Codex, CCRA, and the project owner.
+
+Rules:
+
+- Store reusable knowledge here.
+- Keep raw source archives outside this repository.
+- Keep model source of truth in `models/` and `cards/`.
+- Keep session-level validation and handoff documents in `reports/`.
+- Do not put version numbers in filenames; record version information inside the document.
+- Store long-term CCRA quality gates and handoff protocols here, but do not store per-round review bundles or command logs here.
+
+See `docs/KNOWLEDGE_ASSET_RULES.md`.

models/README.md

@@ -1,10 +1,12 @@
 # Models
 
-This folder will contain machine-readable JSON model specifications.
+This folder contains machine-readable JSON model specifications.
 
-The first expected sample models are:
+Current sample models:
 
 - `qpi.model.json`
 - `intellectual_archaeology.model.json`
 
 Each model file must follow `docs/DATA_CONTRACT.md` and reference valid source and evidence records.
+
+`model_index.json` is the machine-readable model registry.

models/intellectual_archaeology.model.json

@@ -0,0 +1,187 @@
+{
+  "model_id": "intellectual_archaeology",
+  "model_name": "思想考古学",
+  "model_type": "deep_modeling_model",
+  "pipeline_position": "deep_analysis",
+  "one_sentence_definition": "思想考古学是一种从表层应用逐层下钻到哲学基岩的建模方法，用于发现支撑一个模型或判断的深层假设、核心机理和动态韧性来源。",
+  "core_question": "当前问题、方案或模型背后，隐藏了哪些更深层的结构性假设？",
+  "core_mechanism": "把待建模对象放入七层深度框架：应用层、领域层、过程层、目的层、核心机理层、人类能力层、哲学基岩层；逐层追问支撑上一层的假设，并以最小充分下潜原则停止，避免为了深刻而深刻。",
+  "status": "draft",
+  "source_articles": [
+    "article_intellectual_archaeology_primary_001",
+    "article_cognitive_os_synthesis_001"
+  ],
+  "source_evidence": [
+    "excerpt_ia_primary_definition_001",
+    "excerpt_ia_primary_layers_001",
+    "excerpt_ia_primary_resilience_001",
+    "excerpt_ia_cognitive_os_minimum_depth_001",
+    "excerpt_ia_primary_validation_001"
+  ],
+  "input_types": [
+    "复杂问题",
+    "系统性议题",
+    "反复失败的问题",
+    "专家隐性知识",
+    "认知模型草稿",
+    "产品底层逻辑",
+    "需要抽取底层假设的业务方案"
+  ],
+  "output_types": [
+    "层级化问题地图",
+    "是否应该调用",
+    "进入思想考古的理由",
+    "建议最大下潜层级",
+    "实际分析层级",
+    "停止理由",
+    "不继续下潜理由",
+    "深层假设清单",
+    "最小充分下潜层级",
+    "模型稳固性判断",
+    "需要验证的薄弱环节",
+    "后续建模建议"
+  ],
+  "call_when": [
+    "QPI 判断问题偏课题或中重型难题。",
+    "问题具有高复用价值。",
+    "用户希望从文章中抽取模型。",
+    "当前解释停留在表层工具或症状。",
+    "需要把专家隐性知识显性化。",
+    "需要为一个模型寻找更稳固的底层结构。",
+    "一个问题反复解决但反复失败。"
+  ],
+  "do_not_call_when": [
+    "当前只是缺少一个事实或材料位置，直接检索即可。",
+    "问题属于低风险轻量表达，不值得进入深层建模。",
+    "继续下钻不再改变判断、路径、验证方式或行动边界。",
+    "用户明确只需要短平快执行，不需要模型化解释。",
+    "缺少足够领域材料，无法区分真实底层假设和空泛哲学化表达。"
+  ],
+  "trigger_keywords": [
+    "深层结构",
+    "底层逻辑",
+    "模型稳不稳",
+    "为什么反复失败",
+    "问题的根在哪里",
+    "沉淀成模型",
+    "从文章抽取模型",
+    "方法论的基岩",
+    "隐性知识",
+    "哲学基岩"
+  ],
+  "negative_triggers": [
+    "快速回答",
+    "不要展开",
+    "只查事实",
+    "只要执行步骤",
+    "不要深入分析",
+    "只改文案"
+  ],
+  "related_models": [
+    "qpi"
+  ],
+  "conflicting_models": [
+    "fast_execution_flow"
+  ],
+  "disciplinary_anchors": [
+    "哲学",
+    "认识论",
+    "系统论",
+    "复杂系统",
+    "认知心理学",
+    "专家知识显性化",
+    "因果推理",
+    "设计理论"
+  ],
+  "common_misuses": [
+    "把思想考古学误用为文章摘要或概念堆叠。",
+    "为了显得深刻而无限下钻。",
+    "把所有轻量问题都拖入七层分析。",
+    "只做纵向下潜而缺少横向模型竞争。",
+    "用哲学基岩替代现实验证。",
+    "下潜后没有回到可行动结论。"
+  ],
+  "failure_modes": [
+    "分析很深但不能改变判断或行动。",
+    "层级之间没有清楚递进关系。",
+    "把所有问题都下钻到哲学层。",
+    "输出只有抽象概念而没有模型结构。",
+    "没有说明应该在哪一层停止。",
+    "没有指出需要证据验证的地方。"
+  ],
+  "selection_priority": 7,
+  "confidence_level": "medium",
+  "stability_profile": {
+    "stability_level": "B",
+    "needs_stabilization": true,
+    "main_risks": [
+      "七层结构需要进一步稳定。",
+      "容易过度下潜。",
+      "容易输出抽象概念而缺少行动回路。",
+      "需要更多真实案例验证。"
+    ],
+    "reason": "纵向下潜机制清晰，适合深度建模，但七层结构和停止条件需要进一步稳定。",
+    "next_stabilization_action": "补充不同复杂度问题的下潜深度测试，明确最小充分下潜原则。",
+    "stabilization_notes": "当前适合作为中重型问题的 draft 深度建模模块。"
+  },
+  "regression_status": "pending",
+  "example_inputs": [
+    "我想把过去文章中的认知模型抽取出来，但不知道这些模型到底稳不稳，应该怎么判断？",
+    "现代人为什么一边渴望连接，一边又渴望逃离连接？"
+  ],
+  "example_outputs": [
+    "第一个输入适合下潜到核心机理层，判断文章、模型卡、系统调用、回归测试之间的关系。",
+    "第二个输入可从应用层、评价层、过程层、目的层和人类能力层分析连接与逃离连接的双重机制。"
+  ],
+  "output_contract": [
+    "should_call: true | false。",
+    "entry_reason: 为什么值得进入思想考古；不应调用时说明 no-call 原因。",
+    "recommended_max_depth: application | domain | process | purpose | core_mechanism | human_capability | philosophical_bedrock。",
+    "layers_to_analyze: 实际需要分析的层级数组。",
+    "stop_reason: 为什么停在这一层。",
+    "no_deeper_reason: 继续下潜不会改变什么。",
+    "assumptions_by_layer: 按七层列出关键假设；未分析层级保留空数组。",
+    "validation_needed: 哪些判断需要现实反馈、数据、专家盲审或红队。",
+    "action_implication: 下潜结果如何改变下一步行动。"
+  ],
+  "structured_output_contract": {
+    "should_call": "boolean",
+    "entry_reason": "string",
+    "recommended_max_depth": ["application", "domain", "process", "purpose", "core_mechanism", "human_capability", "philosophical_bedrock"],
+    "layers_to_analyze": "array<layer_id>",
+    "stop_reason": "string",
+    "no_deeper_reason": "string",
+    "assumptions_by_layer": {
+      "application": "array<string>",
+      "domain": "array<string>",
+      "process": "array<string>",
+      "purpose": "array<string>",
+      "core_mechanism": "array<string>",
+      "human_capability": "array<string>",
+      "philosophical_bedrock": "array<string>"
+    },
+    "validation_needed": "array<string>",
+    "action_implication": "string"
+  },
+  "depth_control": {
+    "principle": "最小充分下潜",
+    "stop_conditions": [
+      "已经足以改变决策。",
+      "继续下潜不会增加解释力。",
+      "缺少证据支撑更深推断。",
+      "问题不值得重型建模。",
+      "用户当前只需要执行层结果。",
+      "QPI 未放行中重型难题或课题时，不进入完整思想考古。",
+      "如果 recommended_max_depth 低于 philosophical_bedrock，不得自动展开到哲学基岩。"
+    ],
+    "overuse_warning": "思想考古不是所有问题的默认流程，必须先经过问题价值评估和 QPI 定性。"
+  },
+  "stabilization_path": [
+    "补充轻量、中量、重量问题的边界测试。",
+    "补充不同领域的七层下钻案例。",
+    "建立停止条件和现实验证的示例库。"
+  ],
+  "productization_notes": "思想考古适合作为中重度问题的深层建模模块，不应默认全量调用。它应该由 QPI、问题复杂度和复用价值共同触发。",
+  "version": "0.1",
+  "last_updated": "2026-06-16"
+}

models/model_index.json

@@ -0,0 +1,36 @@
+{
+  "index_version": "0.1",
+  "last_updated": "2026-06-17",
+  "models": [
+    {
+      "model_id": "intellectual_archaeology",
+      "model_name": "思想考古学",
+      "model_type": "deep_modeling_model",
+      "pipeline_position": "deep_analysis",
+      "model_file": "models/intellectual_archaeology.model.json",
+      "card_file": "cards/intellectual_archaeology.md",
+      "source_article_count": 2,
+      "source_evidence_count": 5,
+      "regression_case_count": 17,
+      "stability_level": "B",
+      "regression_status": "pending",
+      "status": "draft",
+      "last_updated": "2026-06-16"
+    },
+    {
+      "model_id": "qpi",
+      "model_name": "QPI 三元定性模型",
+      "model_type": "routing_model",
+      "pipeline_position": "pre_analysis",
+      "model_file": "models/qpi.model.json",
+      "card_file": "cards/qpi.md",
+      "source_article_count": 3,
+      "source_evidence_count": 10,
+      "regression_case_count": 17,
+      "stability_level": "B",
+      "regression_status": "pending",
+      "status": "draft",
+      "last_updated": "2026-06-16"
+    }
+  ]
+}

models/qpi.model.json

@@ -0,0 +1,243 @@
+{
+  "model_id": "qpi",
+  "model_name": "QPI 三元定性模型",
+  "model_type": "routing_model",
+  "pipeline_position": "pre_analysis",
+  "one_sentence_definition": "QPI 用于判断某个认知主体在特定上下文中，如何将期望—现实落差框定为 Question、Problem、Issue、mixed 或 no-call，并识别其中的上下文缺口、动态演化和误框定风险。",
+  "core_question": "谁在什么场景下，把什么期望—现实落差框定成了哪类问题；这个框定是否缺上下文、正在演化或存在误框定风险？",
+  "core_mechanism": "先执行 no-call gate，再检查主体位置、场景上下文、责任范围、经验水平、时间尺度、成功标准和硬反馈可用性；在上下文不足时输出 provisional classification 和 missing_context，不做高置信定性；随后抽取期望—现实落差、三类匮乏物、动态阶段、治理负荷和误框定风险，区分同一框架内的 mixed 与跨主体视角分歧。",
+  "status": "draft",
+  "source_articles": [
+    "article_qpi_primary_001",
+    "article_qpi_contextual_2025_001",
+    "article_cognitive_os_synthesis_001"
+  ],
+  "source_evidence": [
+    "excerpt_qpi_primary_spectrum_001",
+    "excerpt_qpi_primary_question_001",
+    "excerpt_qpi_primary_problem_001",
+    "excerpt_qpi_primary_issue_001",
+    "excerpt_qpi_primary_pathology_reduction_001",
+    "excerpt_qpi_primary_pathology_inflation_001",
+    "excerpt_qpi_contextual_subjectivity_001",
+    "excerpt_qpi_contextual_gap_001",
+    "excerpt_qpi_contextual_dynamic_001",
+    "excerpt_qpi_cognitive_os_application_001"
+  ],
+  "input_types": [
+    "模糊问题",
+    "复杂问题",
+    "业务问题描述",
+    "组织冲突叙述",
+    "需求或故障初始表述",
+    "需要进入深度分析前的问题定义"
+  ],
+  "output_types": [
+    "问题类型判断",
+    "分类作用域",
+    "是否临时判断",
+    "主体位置",
+    "场景上下文",
+    "责任范围",
+    "经验水平",
+    "问题拥有者",
+    "问题来源",
+    "时间尺度",
+    "期望现实落差",
+    "上下文充足度",
+    "缺失上下文",
+    "三类匮乏物强度",
+    "主导匮乏物",
+    "分类理由",
+    "分类置信度",
+    "多视角分类",
+    "动态阶段",
+    "可能演化轨迹",
+    "成功标准稳定性",
+    "硬反馈可用性",
+    "治理负荷",
+    "澄清问题",
+    "证据缺口",
+    "核心匮乏物判断",
+    "误判风险",
+    "推荐处理路径",
+    "后续模型调用建议"
+  ],
+  "call_when": [
+    "用户输入的问题定义不清。",
+    "同一问题被不同主体以不同方式理解。",
+    "用户急于求解但尚未判断问题性质。",
+    "问题中混杂事实、路径、利益、共识和系统结构。",
+    "需要决定后续调用哪些认知模型。",
+    "怀疑存在暴力降维、恶意升维或手段与目标错配。"
+  ],
+  "do_not_call_when": [
+    "用户只是查询明确事实。",
+    "用户已经给出明确执行任务。",
+    "输入是纯创意写作且不需要问题定性。",
+    "问题已经被清楚分类且只需要执行后续步骤。",
+    "输入不是问题定义，而是纯粹的润色或格式转换请求。"
+  ],
+  "trigger_keywords": [
+    "问题到底是什么",
+    "为什么解决不了",
+    "卡在哪里",
+    "技术问题还是组织问题",
+    "方向是不是错了",
+    "为什么反复出现",
+    "该怎么定义这个问题",
+    "这个问题怎么拆",
+    "缺数据",
+    "缺路径",
+    "缺共识"
+  ],
+  "negative_triggers": [
+    "请直接查询",
+    "请直接改写",
+    "只要清单",
+    "不要分析原因",
+    "不要展开",
+    "只改错别字"
+  ],
+  "related_models": [
+    "intellectual_archaeology"
+  ],
+  "conflicting_models": [],
+  "disciplinary_anchors": [
+    "问题定义理论",
+    "决策科学",
+    "系统论",
+    "复杂系统",
+    "组织行为",
+    "工程问题分解"
+  ],
+  "common_misuses": [
+    "把 QPI 当作完整解决方案，而不是问题定义和路由模型。",
+    "把所有复杂叙事都归为课题，逃避可执行的难题拆解。",
+    "把系统性课题暴力压缩成个人执行难题。",
+    "把具体可解决的难题恶意升维成不可处理的课题。",
+    "在事实缺口上过度建模，拖慢本应直接检索的提问。",
+    "忽略问题拥有者，直接给出单一视角的分类。"
+    ,
+    "把缺少主体和场景的复杂短句直接判成高置信 Q/P/I。",
+    "把跨主体视角分歧误写成同一主体内的 mixed。"
+  ],
+  "failure_modes": [
+    "核心匮乏物识别错误，导致后续资源配置错位。",
+    "未识别权力叙事，接受了伪问题或甩锅框架。",
+    "把动态平衡型课题误判为可终结的难题。",
+    "把明确工程障碍误判为需要无限讨论的课题。",
+    "分类没有给出理由。",
+    "分类之后没有给出后续处理路径。"
+    ,
+    "缺少 subject_position 或 scenario_context 时仍输出 high confidence。",
+    "只按表层关键词定性，忽略责任范围、成功标准、硬反馈和治理负荷。"
+  ],
+  "selection_priority": 9,
+  "confidence_level": "medium",
+  "stability_profile": {
+    "stability_level": "B",
+    "needs_stabilization": true,
+    "main_risks": [
+    "Q/P/I 在真实复杂案例中可能同时存在，需要先区分同一主体场景内的 mixed 与不同主体视角导致的 inter_viewpoint_divergence。",
+    "权力博弈判断依赖上下文，证据不足时不能断言动机。",
+      "边界案例仍需用真实业务输入扩展。",
+      "主体性、上下文充足度、动态演化和治理负荷需要继续通过 owner 原始案例校准。"
+    ],
+    "reason": "三分结构清晰，适合作为入口路由模型，但需要补充大量边界案例，防止过度升维或降维。",
+    "next_stabilization_action": "补充主体-上下文-动态案例、混合问题、误用问题和轻量问题测试，并记录主导匮乏物与多视角分歧判断标准。",
+    "stabilization_notes": "当前已具备 v0.1 调用基础，但仍保持 draft 状态。"
+  },
+  "regression_status": "pending",
+  "example_inputs": [
+    "我们团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？",
+    "我知道要做模型库，但不知道先用数据库还是文件系统，这属于什么问题？"
+  ],
+  "example_outputs": [
+    "第一个输入更接近课题，因为它涉及激励结构、时间尺度冲突和组织共识。",
+    "第二个输入更接近难题，因为目标明确，主要缺的是实现路径和技术取舍。"
+  ],
+  "output_contract": [
+    "classification_scope: subject_contextual | multi_perspective | insufficient_context | no_call。",
+    "is_provisional: true | false；缺少主体或场景时必须为 true。",
+    "subject_position: 当前认知主体的位置；未知时写 unknown。",
+    "scenario_context: 问题发生的场景；未知时写 unknown。",
+    "responsibility_scope: individual_learning | team_execution | cross_function_governance | owner_governance | unknown。",
+    "context_sufficiency: high | medium | low。",
+    "missing_context: 缺少哪些主体、场景、目标、资源、责任或时间信息。",
+    "problem_owner: 谁的问题；未知时写 unknown。",
+    "problem_source: 问题从哪里被提出，是否可能带有立场、恐惧或甩锅框架。",
+    "time_scale: short_term | mid_term | long_term | mixed | unknown。",
+    "expectation_reality_gap: expected、reality、gap_summary；未知时写 unknown。",
+    "scarcity_profile: 分别标出 data_scarcity、path_or_resource_scarcity、consensus_or_order_scarcity 的 high | medium | low | unknown。",
+    "dominant_scarcity: data | path_resource | consensus_order | mixed | unknown。",
+    "classification: question | problem | issue | mixed | no_call。",
+    "classification_confidence: high | medium | low。",
+    "classification_by_viewpoint: 多视角分歧时列出不同主体下的分类和理由。",
+    "dynamic_stage: initial | evolving | recurring | stabilized | unknown。",
+    "possible_trajectory: question_to_problem | problem_to_issue | issue_to_problem | stabilized | unknown。",
+    "success_criteria_stability: stable | unstable | contested | unknown。",
+    "hard_feedback_availability: high | medium | low | unknown。",
+    "governance_load: high | medium | low | unknown。",
+    "evidence_gap: 列出还缺哪些信息才能稳定判断；mixed 或 low confidence 时必须填写。",
+    "misclassification_risk: 标出暴力降维、恶意升维或手段错配风险。",
+    "recommended_clarifying_questions: 上下文不足时必须给出需要补问的问题。",
+    "recommended_next_step: 检索 | 工程拆解 | 共识协调 | 补充上下文 | 不调用。",
+    "next_model_candidates: 后续可调用模型 ID；无则为空数组。"
+  ],
+  "structured_output_contract": {
+    "classification_scope": ["subject_contextual", "multi_perspective", "insufficient_context", "no_call"],
+    "is_provisional": "boolean",
+    "subject_position": "string | unknown",
+    "scenario_context": "string | unknown",
+    "responsibility_scope": ["individual_learning", "team_execution", "cross_function_governance", "owner_governance", "unknown"],
+    "context_sufficiency": ["high", "medium", "low"],
+    "missing_context": "array<string>",
+    "problem_owner": "string | unknown",
+    "problem_source": "string | unknown",
+    "time_scale": ["short_term", "mid_term", "long_term", "mixed", "unknown"],
+    "experience_level": ["novice", "experienced", "expert", "cross_domain", "unknown"],
+    "expectation_reality_gap": {
+      "expected": "string | unknown",
+      "reality": "string | unknown",
+      "gap_summary": "string | unknown"
+    },
+    "scarcity_profile": {
+      "data_scarcity": ["high", "medium", "low", "unknown"],
+      "path_or_resource_scarcity": ["high", "medium", "low", "unknown"],
+      "consensus_or_order_scarcity": ["high", "medium", "low", "unknown"]
+    },
+    "dominant_scarcity": ["data", "path_resource", "consensus_order", "mixed", "unknown"],
+    "classification": ["question", "problem", "issue", "mixed", "no_call"],
+    "classification_confidence": ["high", "medium", "low"],
+    "classification_by_viewpoint": "array<object>",
+    "dynamic_stage": ["initial", "evolving", "recurring", "stabilized", "unknown"],
+    "possible_trajectory": "array<string>",
+    "success_criteria_stability": ["stable", "unstable", "contested", "unknown"],
+    "hard_feedback_availability": ["high", "medium", "low", "unknown"],
+    "governance_load": ["high", "medium", "low", "unknown"],
+    "evidence_gap": "array<string>",
+    "misclassification_risk": "array<string>",
+    "recommended_clarifying_questions": "array<string>",
+    "recommended_next_step": ["检索", "工程拆解", "共识协调", "补充上下文", "不调用"],
+    "next_model_candidates": "array<model_id>"
+  },
+  "depth_control": {
+    "principle": "先定性，再决定是否进入深层模型。",
+    "stop_conditions": [
+      "如果只是明确事实查询，停止在提问层并建议检索。",
+      "如果已明确是执行任务，停止继续路由。",
+      "如果分类证据不足，先输出 evidence_gap 并要求补充上下文。",
+      "如果 negative_triggers 命中且没有复杂问题信号，输出 classification=no_call。"
+    ],
+    "overuse_warning": "QPI 是前置路由模型，不应替代后续具体分析模型。"
+  },
+  "stabilization_path": [
+    "补充真实业务混合案例。",
+    "补充暴力降维和恶意升维案例。",
+    "形成主导匮乏物判定示例库。"
+  ],
+  "productization_notes": "QPI 应作为问题回答系统的前置路由模型，用于防止系统在问题类型错误的情况下直接给答案。",
+  "version": "0.1",
+  "last_updated": "2026-06-16"
+}

repo_tree.txt

@@ -0,0 +1,82 @@
+.
+|-- AGENTS.md
+|-- PROJECTS.md
+|-- README.md
+|-- cards/
+|   |-- README.md
+|   |-- card_index.md
+|   |-- intellectual_archaeology.md
+|   `-- qpi.md
+|-- docs/
+|   |-- CHATGPT_HANDOFF_RULES.md
+|   |-- CONTENT_STABILIZATION_PROTOCOL.md
+|   |-- DATA_CONTRACT.md
+|   |-- DECISIONS.md
+|   |-- GPT_PLAN_LOCALIZATION_PROTOCOL.md
+|   |-- INDEX_MAINTENANCE_PROTOCOL.md
+|   |-- KNOWLEDGE_ASSET_RULES.md
+|   |-- MODEL_CARD_CONTRACT.md
+|   |-- MODEL_EXTRACTION_RULES.md
+|   |-- MODEL_EXTRACTION_WORKFLOW.md
+|   |-- PROJECT_BRIEF.md
+|   |-- WORKFLOW.md
+|   `-- superpowers/
+|-- knowledge_assets/
+|   |-- 00_用户背景与产品上下文.md
+|   |-- 01_核心模型地图.md
+|   |-- 02_模型卡结构规范.md
+|   |-- 03_核心模型抽取样板.md
+|   |-- 06_模型稳固性评级规则.md
+|   `-- 07_产品规划过程记录.md
+|-- models/
+|   |-- README.md
+|   |-- intellectual_archaeology.model.json
+|   |-- model_index.json
+|   `-- qpi.model.json
+|-- reports/
+|   |-- ChatGPT交接文档_模型库MVP_第二轮内容稳定化_2026-06-16.md
+|   |-- changed_files_manifest.md
+|   |-- command_log.md
+|   |-- content_review_report_v0.2.md
+|   |-- evidence_coverage_report_v0.2.md
+|   |-- index_check_report.md
+|   |-- index_rebuild_report.md
+|   |-- model_card_sync_report_v0.2.md
+|   |-- model_review_status.json
+|   |-- open_questions_for_CCRA.md
+|   |-- schema_change_notes.md
+|   |-- selector_regression_report_v0.2.md
+|   `-- validation_report.md
+|-- requirements/
+|   |-- ccpe/
+|   `-- skills-vault/
+|-- schemas/
+|   |-- card_index.schema.json
+|   |-- model_card.schema.json
+|   |-- model_index.schema.json
+|   |-- regression_case.schema.json
+|   |-- source_article.schema.json
+|   `-- source_excerpt.schema.json
+|-- scripts/
+|   |-- check_card_contract.py
+|   |-- check_model_card_sync.py
+|   |-- rebuild_indexes.py
+|   |-- run_selector_demo.py
+|   |-- run_selector_regression.py
+|   `-- validate_model_library.py
+|-- selector/
+|   |-- README.md
+|   |-- selector_examples.json
+|   `-- selector_rules.json
+|-- sources/
+|   |-- evidence_coverage.matrix.json
+|   |-- source_articles.json
+|   `-- source_excerpts.json
+`-- tests/
+    |-- intellectual_archaeology.regression.json
+    |-- qpi.regression.json
+    |-- regression_cases.json
+    |-- regression_index.json
+    |-- test_card_contract.py
+    |-- test_rebuild_indexes.py
+    `-- test_validate_model_library.py

reports/ChatGPT交接文档_模型库MVP_2026-06-16.md

@@ -0,0 +1,138 @@
+# 项目交接文档：模型库 / 模型管理子系统 MVP
+
+## 1. 当前阶段
+
+已完成 QPI 和思想考古学两个样板模型的本地工程化打样。
+
+当前状态：模型内容通过本地 contract，但仍是 `draft`，等待产品 / ChatGPT / CCRA 内容审查。
+
+## 2. 本轮目标
+
+验证 QPI 和思想考古学两个核心模型，能否被整理为：
+
+- 人读模型卡
+- 机器可读 JSON
+- 来源文章索引
+- 来源证据片段
+- 回归测试用例
+- schema 校验对象
+- 最小规则选择器对象
+- model/card index 条目
+
+## 3. 已完成内容
+
+- 建立 GPT 规划本地化协议。
+- 建立模型抽取规则。
+- 建立模型卡结构规范。
+- 建立模型抽取工作流。
+- 建立知识资产规则。
+- 建立 ChatGPT 交接规则。
+- 建立 `knowledge_assets/` 长期知识资产目录。
+- 创建 model/card/source/excerpt/regression/index schemas。
+- 创建 QPI 和思想考古学的 JSON model card。
+- 创建 QPI 和思想考古学的 Markdown card。
+- 创建 source article 和 source excerpt 索引。
+- 创建 regression cases。
+- 创建 selector rules 和 selector examples。
+- 创建 model index 和 card index。
+- 创建 validator、card contract checker、selector demo。
+
+## 4. 关键文件路径
+
+规则和流程：
+
+- `docs/GPT_PLAN_LOCALIZATION_PROTOCOL.md`
+- `docs/MODEL_EXTRACTION_RULES.md`
+- `docs/MODEL_CARD_CONTRACT.md`
+- `docs/MODEL_EXTRACTION_WORKFLOW.md`
+- `docs/CHATGPT_HANDOFF_RULES.md`
+- `docs/KNOWLEDGE_ASSET_RULES.md`
+
+长期知识资产：
+
+- `knowledge_assets/00_用户背景与产品上下文.md`
+- `knowledge_assets/01_核心模型地图.md`
+- `knowledge_assets/02_模型卡结构规范.md`
+- `knowledge_assets/03_核心模型抽取样板.md`
+- `knowledge_assets/06_模型稳固性评级规则.md`
+- `knowledge_assets/07_产品规划过程记录.md`
+
+模型资产：
+
+- `models/qpi.model.json`
+- `models/intellectual_archaeology.model.json`
+- `cards/qpi.md`
+- `cards/intellectual_archaeology.md`
+- `models/model_index.json`
+- `cards/card_index.md`
+
+数据与测试：
+
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+- `tests/regression_cases.json`
+- `selector/selector_rules.json`
+- `selector/selector_examples.json`
+
+校验：
+
+- `scripts/validate_model_library.py`
+- `scripts/check_card_contract.py`
+- `scripts/run_selector_demo.py`
+- `reports/validation_report.md`
+- `reports/内容修复检查摘要_v0.1.md`
+
+## 5. Codex 实现和原计划的差异
+
+- 原 GPT 规划是外部计划；Codex 已将其转为本地规则、schema、workflow、index 和工具。
+- 原 GPT 规划建议长期知识库文件名带版本号；本地决定文件名不带版本号，版本写入文档内部。
+- 原 GPT 规划建议可包含具体模型卡长期资产；本地决定不复制具体模型卡，具体模型卡 source of truth 保持在 `cards/` 和 `models/`。
+- 原 GPT 规划中的 `source_index.json` 被拆分为 `sources/source_articles.json` 和 `sources/source_excerpts.json`。
+- regression cases 当前使用合并文件 `tests/regression_cases.json`，未按模型拆分。
+
+## 6. 当前问题
+
+- QPI 和思想考古学内容通过 contract，但仍需产品语义审查。
+- source evidence 是否足够支撑所有字段，仍需进一步判断。
+- regression cases 是样板级，真实业务案例仍不足。
+- selector demo 可运行，但评分逻辑仍是 v0.1 简单规则。
+- 长期知识资产刚建立，需要确认是否还缺 `04/05` sample 类文件。
+
+## 7. 需要 ChatGPT / CCRA 判断的事项
+
+- QPI 当前字段和边界是否准确。
+- 思想考古学是否应保持七层结构，还是需要更强的停止条件表达。
+- 是否应引入第三个核心模型。
+- 从产品角度看，后续模型抽取是否需要拆成抽取、检验、评分三个环节。
+- 如果需要多环节审查，这三个环节的质量标准分别是什么。
+- 当前 QPI / 思想考古样板是否已经暴露出需要多角色审查的质量问题。
+- regression cases 是否应按模型拆分。
+- selector 应继续规则化，还是加入 LLM 判断层。
+
+## 8. 下一步候选方向
+
+- 继续完善模型管理子系统。
+- 接入最小问题回答流程。
+- 扩展到第三个核心模型。
+- 做模型稳固性评级审查。
+- 扩展 regression cases。
+- 评估是否需要抽取、检验、评分三段式审查流程。
+
+## 9. 验证结果
+
+已运行：
+
+```powershell
+python -m unittest discover -s tests -p "test*.py" -v
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+python scripts\run_selector_demo.py
+```
+
+结果：
+
+- Unit tests: PASS, 9 tests.
+- Card contract: PASS.
+- Model library validation: PASS.
+- Selector demo: PASS.
+- `reports/validation_report.md`: `Status: PASS`.

reports/ChatGPT交接文档_模型库MVP_第二轮内容稳定化_2026-06-16.md

@@ -0,0 +1,153 @@
+# ChatGPT 交接文档：模型库 MVP 第二轮内容稳定化
+
+## 审核摘要
+
+本轮依据：
+
+- `2026-06-16-核心模型抽取样板 v0.1.md`
+- `CCRA_Codex指导意见_Index更新策略与下一轮执行_v0.2_2026-06-16.md`
+- `CCRA_Codex指导意见_模型库MVP第二轮内容稳定化_v0.3_2026-06-16.md`
+
+本轮目标：
+
+- 不扩展第三模型。
+- 不接入完整问题回答系统。
+- 不引入 LLM selector。
+- 不升级 stable。
+- 优先完成 QPI / 思想考古内容稳定化、证据矩阵、回归扩展、selector 防误召回和 index drift 检查。
+
+当前状态：
+
+- QPI: `draft / B / pending`
+- 思想考古: `draft / B / pending`
+
+请求 CCRA 审核：
+
+1. 内容稳定化是否达标。
+2. evidence coverage 是否足够。
+3. regression cases 是否足够。
+4. selector v0.2 是否避免误召回。
+5. 是否允许进入下一阶段。
+
+## 1. 本轮 Codex 接收的指导文件
+
+- `reports/Codex新会话交接文档_模型库MVP_2026-06-16.md`
+- `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\GPT成果\CCRA_Codex指导意见_Index更新策略与下一轮执行_v0.2_2026-06-16.md`
+- `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\GPT成果\CCRA_Codex指导意见_模型库MVP第二轮内容稳定化_v0.3_2026-06-16.md`
+- 用户明确约束：不扩展第三模型、不接完整问题回答系统、不引入 LLM selector、不升级 stable。
+
+## 2. 本轮实际完成任务
+
+- 建立 `docs/CONTENT_STABILIZATION_PROTOCOL.md`。
+- 建立字段级 `sources/evidence_coverage.matrix.json` 和 `reports/evidence_coverage_report_v0.2.md`。
+- 修复 `sources/source_excerpts.json` 的 `quote_status`、`source_location`，并补充 QPI 暴力降维 / 恶意升维 evidence。
+- 扩展 source article / source excerpt schema 枚举与 validator 检查。
+- 强化 QPI JSON 和 Markdown card 输出契约。
+- 强化思想考古 JSON 和 Markdown card 停止门。
+- 扩展 regression schema 的可评估字段。
+- 拆分 regression cases 为每模型文件，并保持 aggregate 文件。
+- 每模型扩展到 17 条 regression cases。
+- selector 升级到 v0.2 规则版，保留 no LLM。
+- 新增 `scripts/run_selector_regression.py`。
+- 新增 `scripts/check_model_card_sync.py`。
+- 生成 content review、model review status、next action、command log、schema notes、changed files manifest、repo tree 等审核材料。
+
+## 3. 未完成任务及原因
+
+- 未升级 `stable`：用户和 CCRA 明确禁止，本轮只允许 draft-callable 审查结论。
+- 未扩展第三模型：用户和 CCRA 明确要求先稳定 QPI / 思想考古。
+- 未接入完整问题回答系统：属于非目标。
+- 未引入 LLM selector：selector v0.2 仍为规则 selector。
+- 未建立 `selector_score_breakdown` 的运行时数据仓库：当前以静态报告和 selector demo 输出说明 score breakdown。
+
+## 4. 关键新增 / 修改文件
+
+详见：
+
+- `reports/changed_files_manifest.md`
+
+核心新增文件：
+
+- `docs/CONTENT_STABILIZATION_PROTOCOL.md`
+- `sources/evidence_coverage.matrix.json`
+- `tests/qpi.regression.json`
+- `tests/intellectual_archaeology.regression.json`
+- `scripts/run_selector_regression.py`
+- `scripts/check_model_card_sync.py`
+- `reports/content_review_report_v0.2.md`
+- `reports/model_review_status.json`
+- `reports/next_action_register_v0.2.md`
+- `reports/changed_files_manifest.md`
+- `reports/command_log.md`
+- `reports/open_questions_for_CCRA.md`
+- `reports/schema_change_notes.md`
+
+## 5. 执行命令与结果
+
+详见：
+
+- `reports/command_log.md`
+
+摘要：
+
+| Command | Result |
+| --- | --- |
+| `python scripts\rebuild_indexes.py --check` | PASS |
+| `python scripts\check_card_contract.py` | PASS |
+| `python scripts\validate_model_library.py` | PASS |
+| `python scripts\run_selector_demo.py` | PASS |
+| `python scripts\run_selector_regression.py` | PASS |
+| `python scripts\check_model_card_sync.py` | PASS |
+| `python -m unittest discover -s tests -p "test*.py" -v` | PASS, 14 tests |
+
+## 6. 实现取舍
+
+- `draft-callable` 没有写入模型 JSON，仅作为 review report 结论，避免过早扩展状态 schema。
+- `reports/index_check_report.md` 作为审核友好摘要补充；实际脚本仍写 `reports/index_rebuild_report.md`。
+- `reports/content_review_report.md`、`reports/evidence_coverage_matrix.md`、`reports/selector_regression_report.md` 作为无版本审核入口，指向 v0.2 正本。
+- regression per-model 文件作为人审 source of truth，`tests/regression_cases.json` 保持 aggregate 供 validator 使用。
+- selector v0.2 只做规则评分和拒绝理由，不做回答生成。
+
+## 7. 需要 CCRA / 用户确认的问题
+
+详见：
+
+- `reports/open_questions_for_CCRA.md`
+
+核心问题：
+
+1. QPI mixed case 的 `dominant_scarcity` 仲裁是否足够。
+2. QPI 输出契约中的 `problem_owner`、`time_scale`、`dominant_scarcity`、`evidence_gap` 是否应进入 schema required。
+3. 思想考古 `recommended_max_depth` / `stop_reason` / `no_deeper_reason` 是否应进入 schema required。
+4. selector v0.2 阈值是否需要基于真实输入校准。
+5. 是否继续保持 `draft / B / pending`。
+6. 是否允许之后讨论第三模型，默认答案仍为否。
+
+## 8. 当前模型状态判断
+
+| Model | Status | Stability | Regression Status | Draft-callable | Stable Allowed |
+| --- | --- | --- | --- | --- | --- |
+| `qpi` | draft | B | pending | yes | no |
+| `intellectual_archaeology` | draft | B | pending | yes | no |
+
+## 9. 审核包入口
+
+- `models/model_index.json`
+- `cards/card_index.md`
+- `models/qpi.model.json`
+- `models/intellectual_archaeology.model.json`
+- `cards/qpi.md`
+- `cards/intellectual_archaeology.md`
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+- `sources/evidence_coverage.matrix.json`
+- `tests/qpi.regression.json`
+- `tests/intellectual_archaeology.regression.json`
+- `tests/regression_cases.json`
+- `selector/selector_rules.json`
+- `selector/selector_examples.json`
+- `reports/content_review_report_v0.2.md`
+- `reports/validation_report.md`
+- `reports/index_check_report.md`
+- `reports/selector_regression_report_v0.2.md`
+- `reports/model_card_sync_report_v0.2.md`

reports/Codex_模型资产链路摘要_v0.1.md

@@ -0,0 +1,98 @@
+# Codex 模型资产链路摘要 v0.1
+
+## 1. Current Work Session
+
+Date: 2026-06-16
+
+Task: 根据 GPT 抽取样板和三份中文来源材料，建立 QPI 与思想考古学的第一版模型资产链路。
+
+## 2. Completed Work
+
+- 确认 `intellectual_archaeology` 作为思想考古学的机器 ID。
+- 按“字段名英文、字段内容中文”的规则产出 JSON 与 Markdown。
+- 新增四类 JSON Schema：model spec、source article、source excerpt、regression case。
+- 新增三份来源文章记录。
+- 新增十条 source evidence excerpt。
+- 新增 QPI 与思想考古学的模型卡。
+- 新增 QPI 与思想考古学的机器可读 model JSON。
+- 新增十条回归用例，每个模型五条，覆盖正例、边界和误用。
+- 新增 data-only selector 规则与示例。
+- 新增标准库 Python 校验脚本，并以单元测试覆盖核心校验行为。
+- 运行校验并生成 `reports/validation_report.md`。
+
+## 3. Files Created
+
+- `schemas/model_spec.schema.json`
+- `schemas/source_article.schema.json`
+- `schemas/source_excerpt.schema.json`
+- `schemas/regression_case.schema.json`
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+- `models/qpi.model.json`
+- `models/intellectual_archaeology.model.json`
+- `cards/qpi.md`
+- `cards/intellectual_archaeology.md`
+- `tests/regression_cases.json`
+- `tests/test_validate_model_library.py`
+- `selector/selector_rules.json`
+- `selector/selector_examples.json`
+- `scripts/validate_model_library.py`
+- `reports/validation_report.md`
+- `reports/Codex_模型资产链路摘要_v0.1.md`
+
+## 4. Files Modified
+
+- `README.md`
+- `schemas/README.md`
+- `models/README.md`
+- `sources/README.md`
+- `tests/README.md`
+- `selector/README.md`
+- `scripts/README.md`
+- `docs/DECISIONS.md`
+
+## 5. Validation Status
+
+Commands run:
+
+```powershell
+python -m unittest tests.test_validate_model_library -v
+python scripts\validate_model_library.py
+```
+
+Result:
+
+- Unit tests: 2 tests passed.
+- Model library validation: passed.
+- Validation report written to `reports/validation_report.md`.
+
+## 6. Assumptions Made
+
+- QPI 的主要来源为 `2026-01-07-anchoring-the-void.md`，综合应用说明作为补充来源。
+- 思想考古学的主要来源为 `2025-10-26-the-workshop-of-Modelers.md` 的 1.3 节，综合应用说明作为边界规则补充来源。
+- 证据片段可以引用原文短段或压缩摘录，但不能替代完整原文；完整来源路径保留在 `sources/source_articles.json`。
+- v0.1 schema 保持宽松，仅锁定必填字段和基础类型，不提前引入复杂 enum。
+- selector 当前只做规则数据，不做可执行 demo，以避免在模型资产尚未审阅前过早扩展脚本。
+
+## 7. What Does Not Yet Work
+
+- `scripts/validate_model_library.py` 还没有执行 JSON Schema draft 的完整校验，只做当前 MVP 需要的必填字段和引用完整性校验。
+- selector 还没有可执行评分脚本。
+- 回归用例还没有自动执行器，它们目前是产品稳定性测试数据。
+- 模型内容尚未经过项目 owner 的逐字段审阅。
+- source excerpts 仍是第一轮人工抽取，后续可以追加更细证据片段。
+
+## 8. Questions for Product / CCRA
+
+- QPI 的 `confidence_level` 是否应从 `medium` 升到 `high`，还是等真实案例回归后再升级？
+- 思想考古学是否需要把“七层框架”作为独立结构化字段加入 model JSON，还是暂时保留在 `core_mechanism` 与 card 中？
+- selector demo 是否进入下一步，还是先审模型卡和回归用例？
+- 是否需要为“源文证据摘录格式”向 `skills-vault` 提出可复用抽取工具需求？
+
+## 9. Suggested Next Tasks
+
+1. 项目 owner 审阅两张模型卡的定义、适用边界和常见误用。
+2. 根据审阅意见修订 model JSON 与 cards。
+3. 为 selector 增加最小可执行 demo，输入文本后输出推荐模型、分数、理由和 routing notes。
+4. 将回归用例接入一个简单检查器，验证每个核心模型至少有五条 case，且覆盖 positive、boundary、misuse。
+5. 如果后续需要批量从中文文章抽 evidence excerpt，再向 `requirements/skills-vault/` 写工具需求。

reports/Codex新会话交接文档_CCRA评审后处理_2026-06-16.md

@@ -0,0 +1,258 @@
+# Codex 新会话交接文档：CCRA 评审后处理
+
+date: 2026-06-16
+
+repo: `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong`
+
+phase: `model_library_mvp`
+
+next_context: 用户将在新会话中带回 GPT / CCRA 对压缩审核包的评审意见。
+
+## 1. 当前状态摘要
+
+本仓库当前仍只处理两个样板模型：
+
+- `qpi`
+- `intellectual_archaeology`
+
+当前状态保持：
+
+| Model ID | Status | Stability | Regression Status |
+| --- | --- | --- | --- |
+| `qpi` | draft | B | pending |
+| `intellectual_archaeology` | draft | B | pending |
+
+本轮没有：
+
+- 扩展第三模型
+- 接完整问题回答系统
+- 引入 LLM selector
+- 升级 stable
+
+## 2. 本轮已完成事项
+
+### 2.1 Index 维护机制
+
+已完成：
+
+- `scripts/rebuild_indexes.py`
+- `docs/INDEX_MAINTENANCE_PROTOCOL.md`
+- `reports/index_rebuild_report.md`
+- `reports/index_check_report.md`
+
+索引策略：
+
+```text
+每次资产变化增量同步
++
+关键节点全量重建 / 全量校验
+```
+
+### 2.2 第二轮内容稳定化
+
+已完成：
+
+- 字段级 evidence coverage matrix
+- source excerpt quote 精确性修复
+- QPI 输出契约强化
+- 思想考古停止门强化
+- regression cases 扩展到每模型 17 条
+- selector v0.2 防误召回
+- JSON / Markdown sync check
+- content review report
+
+核心文件：
+
+- `docs/CONTENT_STABILIZATION_PROTOCOL.md`
+- `sources/evidence_coverage.matrix.json`
+- `reports/evidence_coverage_report_v0.2.md`
+- `models/qpi.model.json`
+- `models/intellectual_archaeology.model.json`
+- `cards/qpi.md`
+- `cards/intellectual_archaeology.md`
+- `tests/qpi.regression.json`
+- `tests/intellectual_archaeology.regression.json`
+- `tests/regression_cases.json`
+- `tests/regression_index.json`
+- `selector/selector_rules.json`
+- `selector/selector_examples.json`
+- `scripts/run_selector_regression.py`
+- `scripts/check_model_card_sync.py`
+- `reports/content_review_report_v0.2.md`
+- `reports/model_review_status.json`
+- `reports/next_action_register_v0.2.md`
+
+### 2.3 CCRA 压缩审核包
+
+已按 CCRA 压缩上传协议生成：
+
+```text
+ccra_review_bundle/
+```
+
+目录内核心文件：
+
+- `ccra_review_bundle/00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md`
+- `ccra_review_bundle/01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md`
+- `ccra_review_bundle/02_CURRENT_ASSET_PACK.md`
+- `ccra_review_bundle/03_REPORTS_DIFF_AND_COMMAND_LOG.md`
+- `ccra_review_bundle/BUNDLE_FILE_MANIFEST.md`
+- `ccra_review_bundle/optional_raw_changed_files.zip`
+
+上传建议：
+
+第一批：
+
+1. `00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md`
+2. `01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md`
+3. `03_REPORTS_DIFF_AND_COMMAND_LOG.md`
+
+如果仍过大：
+
+1. `00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md`
+2. `03_REPORTS_DIFF_AND_COMMAND_LOG.md`
+
+第二批按 CCRA 要求补：
+
+- `02_CURRENT_ASSET_PACK.md`
+- `optional_raw_changed_files.zip`
+- 或 CCRA 指定的原始文件
+
+### 2.4 长期知识资产更新
+
+新增：
+
+- `knowledge_assets/08_CCRA模型库MVP质量门与交接协议.md`
+
+同步更新：
+
+- `knowledge_assets/01_核心模型地图.md`
+- `knowledge_assets/06_模型稳固性评级规则.md`
+- `knowledge_assets/07_产品规划过程记录.md`
+- `knowledge_assets/README.md`
+
+原则：
+
+长期协议、质量门、交接规则进入 `knowledge_assets/`。
+
+本轮审核包、command log、validation report、diff、selector regression report 等临时证据不进入知识资产，只作为新会话审核材料。
+
+## 3. 当前验证命令与结果
+
+最近一轮完整验证通过：
+
+```powershell
+python scripts\rebuild_indexes.py --check
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+python scripts\run_selector_demo.py
+python scripts\run_selector_regression.py
+python scripts\check_model_card_sync.py
+python -m unittest discover -s tests -p "test*.py" -v
+```
+
+结果：
+
+- Index check: PASS
+- Card contract: PASS
+- Model library validation: PASS
+- Selector demo: PASS
+- Selector regression: PASS
+- Model/card sync: PASS
+- Unit tests: PASS, 14 tests
+
+## 4. 新会话开始时建议先读
+
+按顺序读：
+
+1. `AGENTS.md`
+2. `README.md`
+3. `reports/Codex新会话交接文档_CCRA评审后处理_2026-06-16.md`
+4. 用户带回的 GPT / CCRA 评审意见
+5. `knowledge_assets/08_CCRA模型库MVP质量门与交接协议.md`
+6. `ccra_review_bundle/00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md`
+7. `ccra_review_bundle/03_REPORTS_DIFF_AND_COMMAND_LOG.md`
+8. 评审意见指定的具体资产文件
+
+不要一上来全量重读所有模型资产，除非评审意见要求。
+
+## 5. 下一轮处理原则
+
+用户会带回 GPT / CCRA 评审后的要求。
+
+处理时先分类：
+
+- 内容修复
+- evidence 修复
+- regression 修复
+- selector 修复
+- schema 修复
+- index / handoff 修复
+- supplier request
+- owner / CCRA 决策问题
+
+如果评审意见是明确修改要求：
+
+1. 修改最小必要文件。
+2. 如涉及模型 / evidence / regression，运行 `python scripts\rebuild_indexes.py --write`。
+3. 再运行完整验证。
+4. 更新必要报告和交接文件。
+
+如果评审意见是产品判断或质量门意见：
+
+1. 记录在相应报告或 docs。
+2. 不要自行扩大到第三模型。
+3. 不要自行升级 stable。
+
+## 6. 当前仍需 CCRA / Owner 判断的问题
+
+这些问题已记录在 `reports/open_questions_for_CCRA.md`：
+
+- QPI mixed case 的 `dominant_scarcity` 仲裁是否足够。
+- QPI 输出契约中的 `problem_owner`、`time_scale`、`dominant_scarcity`、`evidence_gap` 是否应进入 schema required。
+- 思想考古 `recommended_max_depth`、`stop_reason`、`no_deeper_reason` 是否应进入 schema required。
+- selector v0.2 阈值是否需要基于真实输入校准。
+- `draft-callable` 是否继续作为 report-only 状态，还是进入 schema。
+- 是否继续保持两个模型 `draft / B / pending`。
+- 是否允许之后讨论第三模型，默认答案仍为否。
+
+## 7. 禁止事项
+
+除非用户 / CCRA 明确改变边界，不要：
+
+- 扩展第三模型
+- 引入完整问题回答系统
+- 引入 LLM selector
+- 引入数据库、RAG、知识图谱、前端或后台管理页面
+- 将 `status` 改为 stable
+- 将 `stability_level` 改为 A
+- 将 `regression_status` 改为 passed
+- 把本轮临时审核材料写入 `knowledge_assets/`
+
+## 8. 工作区提醒
+
+当前工作区有大量 untracked 文件，这是模型库 MVP 工程化和内容稳定化产物，不是临时垃圾。
+
+不要误删：
+
+- `cards/*.md`
+- `models/*.json`
+- `sources/*.json`
+- `tests/*.json`
+- `reports/*.md`
+- `ccra_review_bundle/*`
+
+测试运行可能生成：
+
+- `scripts/__pycache__/`
+- `tests/__pycache__/`
+
+验证后可清理这两个缓存目录。
+
+## 9. 新会话建议第一句话
+
+用户可在新会话中说：
+
+```text
+请先阅读 reports/Codex新会话交接文档_CCRA评审后处理_2026-06-16.md，然后阅读我带回的 GPT / CCRA 评审意见。不要扩第三模型、不要升级 stable。先判断评审意见属于内容修复、schema 修复、selector 修复、evidence 修复、regression 修复还是需要 owner 决策。
+```

reports/Codex新会话交接文档_QPI案例草稿审阅与第三轮后续_2026-06-17.md

@@ -0,0 +1,274 @@
+# Codex 新会话交接文档：QPI 案例草稿审阅与第三轮后续
+
+date: 2026-06-17
+
+repo: `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong`
+
+phase: `model_library_mvp`
+
+current_focus: QPI 主体-上下文-动态框定规则优化、案例草稿 owner 审阅、后续 CCRA 审核资料补强
+
+## 1. 当前状态
+
+本会话已完成第三轮第一阶段工程硬化：
+
+- 未扩展第三模型。
+- 未升级 stable。
+- 未接完整问题回答系统。
+- 未引入 LLM selector。
+- `qpi` 与 `intellectual_archaeology` 保持 `draft / B / pending`。
+
+已完成：
+
+- CCRA 审核包按轮次归档。
+- QPI 从“文本分类器”升级为“主体-上下文-动态框定前置路由模型”。
+- `structured_output_contract` 进入 schema properties，但 QPI / IA 专属字段不进入全局 required。
+- validator 已做模型专属 output contract 检查。
+- selector 已改为读取 `selector/selector_rules.json`，并加入 hard no-call gate。
+- 新增 QPI 案例预处理流程，支持后续多模型扩展。
+- 通过子代理从 8 份原始材料抽出 62 个 QPI draft cases，均为 `draft_owner_review_needed`。
+
+## 2. 新会话优先阅读顺序
+
+新会话不要一上来全量读所有模型资产。建议按下列顺序：
+
+1. `AGENTS.md`
+2. `README.md`
+3. 本文件：`reports/Codex新会话交接文档_QPI案例草稿审阅与第三轮后续_2026-06-17.md`
+4. QPI 规则：`docs/QPI_CONTEXTUAL_ROUTING_RULES.md`
+5. QPI 案例预处理流程：`docs/model_case_preprocessing/qpi/CASE_PREPROCESSING_WORKFLOW.md`
+6. round-01 草稿目录说明：`reports/model_case_preprocessing/qpi/round-01/README.md`
+7. 用户正在审阅或指定的具体 `.cases.md` 文件
+8. 第三轮审核包入口：`ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md`
+9. 第三轮 compliance matrix：`ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md`
+
+## 3. QPI 案例草稿位置
+
+QPI 案例预处理规则：
+
+- `docs/model_case_preprocessing/README.md`
+- `docs/model_case_preprocessing/qpi/README.md`
+- `docs/model_case_preprocessing/qpi/CASE_PREPROCESSING_WORKFLOW.md`
+
+草稿目录：
+
+```text
+reports/model_case_preprocessing/qpi/round-01/
+```
+
+草稿文件：
+
+- `reports/model_case_preprocessing/qpi/round-01/flow-redesign.cases.md`
+- `reports/model_case_preprocessing/qpi/round-01/disappointment-emotional-isolation.cases.md`
+- `reports/model_case_preprocessing/qpi/round-01/year-end-review-development-office.cases.md`
+- `reports/model_case_preprocessing/qpi/round-01/year-end-review-engineering-center.cases.md`
+- `reports/model_case_preprocessing/qpi/round-01/year-end-review-international-college.cases.md`
+- `reports/model_case_preprocessing/qpi/round-01/year-end-review-academic-affairs.cases.md`
+- `reports/model_case_preprocessing/qpi/round-01/year-end-review-employment-entrepreneurship.cases.md`
+- `reports/model_case_preprocessing/qpi/round-01/year-end-review-research-office.cases.md`
+
+总量：
+
+```text
+62 draft QPI cases
+```
+
+状态：
+
+```text
+draft_owner_review_needed
+```
+
+这些草稿还不是 selector calibration JSON，也不是 regression cases。
+
+## 4. 用户下一步怎么审
+
+用户不需要一次审完 62 个。
+
+建议先挑 10-15 个高质量案例确认。优先挑：
+
+- 能体现 QPI 主体性 / 上下文性的案例。
+- 能区分 `intra_frame_mixed` 与 `inter_viewpoint_divergence` 的案例。
+- 能体现组织级 I 域治理负荷的案例。
+- 能暴露暴力降维、恶意升维、工具解法主义、过早定性的案例。
+- 用户认为“这就是 QPI 真实应用”的案例。
+
+用户可以在 Markdown 草稿中直接改：
+
+- 删除不成立的 case。
+- 合并重复 case。
+- 修改 `classification_scope`。
+- 修改 `classification` / `dominant_scarcity`。
+- 修改 `classification_confidence`。
+- 补充 Owner Review Questions 的答案。
+- 标记 `owner_approved_for_digest: true`。
+
+如果用户只想低负担审阅，可以直接回复：
+
+```text
+保留：文件A case 1/3/5，文件B case 2/4
+删除：文件C case 6
+合并：文件D case 1 和 case 7
+改判：文件E case 3 从 problem 改为 issue
+```
+
+Codex 应据此更新 Markdown 草稿。
+
+## 5. Codex 后续处理规则
+
+在用户确认前，不要：
+
+- 写 `selector/qpi_case_digests.json`。
+- 把 draft cases 合并进 `selector/selector_calibration_inputs.json`。
+- 把 draft cases 写入 regression。
+- 把 draft case 当成 CCRA 已认可内容。
+- 升级 QPI status / stability / regression status。
+
+用户确认后，处理路径是：
+
+```text
+draft .cases.md
+-> owner-reviewed .cases.md
+-> case digest JSON
+-> selector calibration inputs
+-> selected regression cases
+-> validation
+-> CCRA review material update
+```
+
+建议输出位置：
+
+- owner-reviewed Markdown 仍留在 `reports/model_case_preprocessing/qpi/round-01/`
+- 结构化 digest 建议新增：`selector/qpi_case_digests.json`
+- selector 校准合并：`selector/selector_calibration_inputs.json`
+- 只有特别关键、可复用且边界明确的案例才进入 `tests/regression_cases.json`
+
+## 6. 脱敏规则
+
+组织级 CT 切片已经要求子代理脱敏加工。
+
+后续继续处理组织材料时必须：
+
+- 不保留真实人名。
+- 不保留古人名认知锚点。
+- 不保留机构名、部门名、地点名。
+- 不保留时间戳。
+- 不保留精确人数、金额、比例、面积等高识别数字。
+- 不保留可直接反推组织身份的细节。
+- 使用泛化角色：`decision_maker`、`execution_lead`、`functional_department`、`the organization`。
+- 使用泛化病理：`compliance workaround risk`、`metric pressure`、`incentive backlash`、`governance load`、`audit authenticity risk`。
+
+如果发现残留敏感信息，先修 Markdown 草稿，再进入 digest。
+
+## 7. 当前已完成的第三轮审核资料
+
+第三轮审核包目录：
+
+```text
+ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/
+```
+
+核心文件：
+
+- `ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/00_OPEN_THIS_FIRST_CCRA_REVIEW_BRIEF.md`
+- `ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/01_GUIDANCE_PACK_AND_COMPLIANCE_MATRIX.md`
+- `ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/02_CURRENT_ASSET_PACK.md`
+- `ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/03_REPORTS_DIFF_AND_COMMAND_LOG.md`
+- `ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/BUNDLE_FILE_MANIFEST.md`
+- `ccra_review_bundle/round-03_2026-06-17_contract-hardening-selector-calibration/optional_raw_changed_files.zip`
+
+注意：这些审核包是在 QPI draft cases 进入 digest / calibration 之前生成的。等用户完成案例确认并转成 digest/calibration 后，需要生成新的补充审核资料或 round-04。
+
+## 8. 已验证命令
+
+第三轮工程硬化完成时已通过：
+
+```powershell
+python scripts\rebuild_indexes.py --check
+python -m unittest discover -s tests -p "test*.py" -v
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+python scripts\run_selector_demo.py
+python scripts\run_selector_regression.py
+python scripts\check_model_card_sync.py
+```
+
+结果：
+
+- Index check: PASS
+- Unit tests: PASS, 15 tests
+- Card contract: PASS
+- Model library validation: PASS
+- Selector demo: PASS
+- Selector regression: PASS
+- Model/card sync: PASS
+
+案例草稿抽取后没有再改 selector / regression / model JSON，因此无需因为草稿本身重跑全量验证。等 digest/calibration/regression 被写入后，必须重跑完整验证链。
+
+## 9. 后续建议计划
+
+### Step 1: 用户审阅草稿
+
+用户先选 10-15 个案例，不必全审。
+
+### Step 2: Codex 整理 owner-reviewed cases
+
+Codex 根据用户修改，把草稿标记为：
+
+```text
+owner_reviewed
+owner_approved_for_digest: true
+```
+
+### Step 3: 生成 case digest
+
+新增或更新：
+
+```text
+selector/qpi_case_digests.json
+```
+
+### Step 4: 合并 selector calibration
+
+将确认后的案例转入：
+
+```text
+selector/selector_calibration_inputs.json
+```
+
+仍需标记来源和 owner-reviewed 状态。
+
+### Step 5: 选择少量 regression cases
+
+只挑关键边界案例进入：
+
+```text
+tests/regression_cases.json
+tests/qpi.regression.json
+```
+
+不要把 62 个草稿全部塞进 regression。
+
+### Step 6: 验证与审核包补充
+
+重跑完整验证链，更新报告，并生成给 CCRA 的补充审核资料。
+
+## 10. 边界提醒
+
+不要：
+
+- 扩展第三模型。
+- 升级 stable。
+- 把 `draft-callable` 写进 model status。
+- 引入 LLM selector。
+- 建完整问答系统。
+- 建数据库、RAG、前端或后台服务。
+- 把未确认草稿当作正式 regression。
+
+继续保持：
+
+```text
+qpi: draft / B / pending
+intellectual_archaeology: draft / B / pending
+```
+

reports/Codex新会话交接文档_模型库MVP_2026-06-16.md

@@ -0,0 +1,281 @@
+# Codex 新会话交接文档：模型库 / 模型管理子系统 MVP
+
+## 1. 当前状态
+
+仓库：`C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong`
+
+当前阶段：`model_library_mvp`
+
+当前已完成：
+
+- QPI 和思想考古学两个样板模型已工程化为模型资产。
+- 本地规则、schema、workflow、index、validator、selector demo 已建立。
+- ChatGPT 交接规则和长期知识资产规则已建立。
+- `knowledge_assets/` 已建立，放置长期复用的规则性文档，不复制具体模型卡 source of truth。
+- 索引维护已升级为脚本化规则：每次资产变更增量同步，关键节点全量重建或校验。
+- `status` 已加入模型 JSON，作为 `models/model_index.json.status` 的来源字段。
+- 第二轮内容稳定化已完成：字段级 evidence matrix、source excerpt quote 状态、QPI 输出契约、思想考古停止门、regression 扩展、selector v0.2、防误召回测试、JSON/Markdown 同步检查、content review report。
+
+当前模型资产状态：
+
+- `qpi`: `draft` / `B` / `pending`
+- `intellectual_archaeology`: `draft` / `B` / `pending`
+
+二者通过本地 contract，但仍等待产品 / ChatGPT / CCRA 内容审查。
+
+当前 review 结论：
+
+- draft-callable: allowed
+- stable: not allowed
+- third model expansion: not allowed
+
+## 2. 下个 Codex 会话先读文件
+
+按顺序读：
+
+1. `AGENTS.md`
+2. `README.md`
+3. `reports/Codex新会话交接文档_模型库MVP_2026-06-16.md`
+4. `reports/ChatGPT交接文档_模型库MVP_2026-06-16.md`
+5. `docs/MODEL_EXTRACTION_WORKFLOW.md`
+6. `docs/MODEL_EXTRACTION_RULES.md`
+7. `docs/MODEL_CARD_CONTRACT.md`
+8. `docs/CHATGPT_HANDOFF_RULES.md`
+9. `docs/KNOWLEDGE_ASSET_RULES.md`
+10. `docs/INDEX_MAINTENANCE_PROTOCOL.md`
+11. `models/model_index.json`
+12. `cards/card_index.md`
+
+如果用户带回 ChatGPT 新建议，先按 `docs/GPT_PLAN_LOCALIZATION_PROTOCOL.md` 做本地化计划，不要直接改内容。
+
+## 3. 已验证命令
+
+最近一轮验证通过：
+
+```powershell
+python scripts\rebuild_indexes.py --check
+python -m unittest discover -s tests -p "test*.py" -v
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+python scripts\run_selector_demo.py
+python scripts\run_selector_regression.py
+python scripts\check_model_card_sync.py
+```
+
+结果：
+
+- Index check: PASS.
+- Unit tests: PASS, 14 tests.
+- Card contract: PASS.
+- Model library validation: PASS.
+- Selector demo: PASS.
+- Selector regression: PASS.
+- Model/card sync: PASS.
+- `reports/index_rebuild_report.md`: `Status: PASS`.
+- `reports/validation_report.md`: `Status: PASS`.
+
+## 4. 关键规则
+
+### GPT 规划规则
+
+GPT 规划不是本地可直接执行规则。
+
+必须先转为：
+
+- local rules
+- schemas
+- workflow gates
+- indexes
+- validation tools
+- owner review points
+
+再进入内容修改。
+
+相关文件：
+
+- `docs/GPT_PLAN_LOCALIZATION_PROTOCOL.md`
+- `docs/MODEL_EXTRACTION_RULES.md`
+
+### ChatGPT 交接规则
+
+每次用户从 Codex 回 ChatGPT 时，生成：
+
+```text
+reports/ChatGPT交接文档_<topic>_<YYYY-MM-DD>.md
+```
+
+相关文件：
+
+- `docs/CHATGPT_HANDOFF_RULES.md`
+- `reports/ChatGPT交接文档_模型库MVP_2026-06-16.md`
+
+### 长期知识资产规则
+
+稳定复用知识进入 `knowledge_assets/`。
+
+不要把具体模型卡复制进 `knowledge_assets/` 作为第二 source of truth。
+
+具体模型卡 source of truth 仍在：
+
+- `cards/`
+- `models/`
+
+相关文件：
+
+- `docs/KNOWLEDGE_ASSET_RULES.md`
+- `knowledge_assets/`
+
+### 索引维护规则
+
+`models/model_index.json` 是机器发现入口。
+
+`cards/card_index.md` 是人读审查入口。
+
+二者不再作为独立手工内容源长期维护，而是从模型 JSON、card 文件和 regression cases 生成或校验。
+
+规则：
+
+```text
+每次资产变更必须增量同步索引
++
+关键节点必须全量重建或全量一致性校验
+```
+
+相关文件：
+
+- `docs/INDEX_MAINTENANCE_PROTOCOL.md`
+- `scripts/rebuild_indexes.py`
+- `reports/index_rebuild_report.md`
+
+### 内容稳定化规则
+
+工程 contract 通过不等于内容稳定。
+
+本轮新增：
+
+- `docs/CONTENT_STABILIZATION_PROTOCOL.md`
+- `sources/evidence_coverage.matrix.json`
+- `reports/evidence_coverage_report_v0.2.md`
+- `reports/content_review_report_v0.2.md`
+- `reports/model_review_status.json`
+- `reports/next_action_register_v0.2.md`
+
+当前结论：
+
+```text
+QPI: draft / B / pending
+Intellectual Archaeology: draft / B / pending
+draft-callable: allowed
+stable: not allowed
+third_model_expansion: not allowed
+```
+
+## 5. 当前关键文件
+
+模型资产：
+
+- `models/qpi.model.json`
+- `models/intellectual_archaeology.model.json`
+- `cards/qpi.md`
+- `cards/intellectual_archaeology.md`
+- `models/model_index.json`
+- `cards/card_index.md`
+
+schema：
+
+- `schemas/model_card.schema.json`
+- `schemas/source_article.schema.json`
+- `schemas/source_excerpt.schema.json`
+- `schemas/regression_case.schema.json`
+- `schemas/model_index.schema.json`
+- `schemas/card_index.schema.json`
+
+数据：
+
+- `sources/source_articles.json`
+- `sources/source_excerpts.json`
+- `tests/regression_cases.json`
+- `tests/qpi.regression.json`
+- `tests/intellectual_archaeology.regression.json`
+- `selector/selector_rules.json`
+- `selector/selector_examples.json`
+
+工具：
+
+- `scripts/validate_model_library.py`
+- `scripts/check_card_contract.py`
+- `scripts/rebuild_indexes.py`
+- `scripts/run_selector_demo.py`
+- `scripts/run_selector_regression.py`
+- `scripts/check_model_card_sync.py`
+
+知识资产：
+
+- `knowledge_assets/00_用户背景与产品上下文.md`
+- `knowledge_assets/01_核心模型地图.md`
+- `knowledge_assets/02_模型卡结构规范.md`
+- `knowledge_assets/03_核心模型抽取样板.md`
+- `knowledge_assets/06_模型稳固性评级规则.md`
+- `knowledge_assets/07_产品规划过程记录.md`
+
+## 6. 当前已知未决问题
+
+这些问题应由用户 / ChatGPT / CCRA 做产品或质量判断，不应由 Codex 直接拍板：
+
+- QPI 当前字段和边界是否准确。
+- 思想考古学是否应保持七层结构，还是需要更强的停止条件表达。
+- 是否应引入第三个核心模型。
+- 从产品角度看，后续模型抽取是否需要拆成抽取、检验、评分三个环节。
+- 如果需要多环节审查，这三个环节的质量标准分别是什么。
+- 当前 QPI / 思想考古样板是否已经暴露出需要多角色审查的质量问题。
+- regression cases 已按模型拆分，但用例真实性和遗漏边界仍需人工审查。
+- selector 已保持规则化并升级到 v0.2；是否未来加入 LLM 判断层仍不是本轮决策。
+- 当前索引策略已工程化，不再需要 owner 判断；但模型状态升级仍需要 owner / ChatGPT / CCRA 明确决定。
+- QPI 混合案例是否需要更细的主导匮乏物仲裁规则。
+- 思想考古 `recommended_max_depth` 是否应与 QPI 输出更强绑定。
+- `draft-callable` 是否应进入 schema，还是继续留在 review report。
+
+本地仓库归属判断不交给 ChatGPT：
+
+- agent spec / invocation / evaluation / governance -> `requirements/ccpe/`
+- reusable deterministic tools / batch scripts / format transformers -> `requirements/skills-vault/`
+- product-specific config, adapters, state, selector behavior -> 本仓库
+
+## 7. 下轮可能任务
+
+用户即将带回 ChatGPT 新一轮讨论结果。
+
+下轮开始时：
+
+1. 先读取用户带回的内容。
+2. 判断它是产品判断、内容修复、规则修复、schema 修复、workflow 修复、工具需求，还是 supplier request。
+3. 若是 GPT 规划或建议，先做本地化计划。
+4. 若是明确内容修改，按现有 contract 修模型卡和 JSON。
+5. 修改后运行 `python scripts\rebuild_indexes.py --write`。
+6. 再运行 `python scripts\rebuild_indexes.py --check`、`python scripts\run_selector_regression.py`、`python scripts\check_model_card_sync.py` 和验证命令。
+7. 若用户要再回 ChatGPT，生成新的 ChatGPT 交接文档。
+
+## 8. 工作区提醒
+
+当前 `git status --short` 显示大量新增文件和修改文件；这些是本轮模型库 MVP 工程化打样产物。
+
+不要把 untracked 文件误认为无关临时文件。
+
+测试运行会生成：
+
+- `scripts/__pycache__/`
+- `tests/__pycache__/`
+
+验证后应清理这些缓存目录。
+
+## 9. 不要重复做的事
+
+不要重新初始化目录。
+
+不要重新创建 QPI / 思想考古基础模型资产。
+
+不要把具体模型卡复制进 `knowledge_assets/`。
+
+不要把 GPT 对 agent / tool 归属的意见直接当成本地仓库归属决策。
+
+不要在没有 owner 明确要求时引入数据库、后端服务、前端应用、RAG、认证或平台化能力。

reports/GPT规划落地差异检查_v0.1.md

@@ -0,0 +1,162 @@
+# GPT 规划落地差异检查 v0.1
+
+## Source Plan
+
+`C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\GPT成果\2026-06-16-核心模型抽取样板 v0.1.md`
+
+## Scope Of This Pass
+
+本轮只修复规则层。
+
+已落地：
+
+- GPT 规划本地化协议。
+- 模型抽取规则。
+- GPT 规划与当前仓库差异检查。
+- 决策日志。
+
+未在本轮执行：
+
+- schema 修复。
+- card contract 修复。
+- workflow 文档修复。
+- index 文件创建。
+- validator 或 selector 工具修复。
+- QPI / 思想考古内容修复。
+
+## Adopted Into Local Rules
+
+已写入 `docs/GPT_PLAN_LOCALIZATION_PROTOCOL.md`：
+
+- GPT 规划是上游计划输入，不是本地可直接执行规则。
+- 每次 GPT 规划进入后，必须先做本地计划。
+- 本地计划必须识别规则、schema、workflow、tooling、index、owner gate。
+- 未完成本地化前，不允许直接进入内容抽取或内容修复。
+- 模型抽取必须保持双工模式：
+  - workflow/tooling track
+  - content extraction track
+
+已写入 `docs/MODEL_EXTRACTION_RULES.md`：
+
+- 字段名英文，中文来源的 JSON 值和 Markdown 内容保持中文。
+- 模型抽取不是文章摘要。
+- 每个模型必须有 source article 和 source evidence 引用。
+- placeholder evidence 必须明确标注，不能伪装成 verified evidence。
+- 完整模型资产链为 source article、source excerpt、Markdown card、JSON model card、regression cases、selector routing、model index、card index、validation report。
+- 每个核心模型至少五个 regression cases，覆盖 positive、boundary、misuse。
+- v0.1 selector 不调用 LLM，必须输出 model ID、score、reason、routing notes。
+- 机器模型索引使用 `models/model_index.json`。
+- 人读模型卡索引使用 `cards/card_index.md`。
+- 未来超过约 8-10 个核心模型后，再考虑 full rebuild index script。
+- 缺失可复用工具时走 `requirements/skills-vault/`。
+- 缺失 CCPE 规格、治理、调用协议或评估能力时走 `requirements/ccpe/`。
+
+## Adopted Into Local Schema
+
+本轮尚未修改 schema。
+
+GPT 规划中待落地到 schema 的关键点：
+
+- `schemas/model_card.schema.json` 应成为机器可读模型卡的权威 schema。
+- 当前 `schemas/model_spec.schema.json` 只覆盖最小字段，不覆盖 GPT 样例完整字段。
+- model JSON 需要补充推荐字段：
+  - `trigger_keywords`
+  - `negative_triggers`
+  - `related_models`
+  - `conflicting_models`
+  - `disciplinary_anchors`
+  - `example_inputs`
+  - `example_outputs`
+  - `output_contract`
+  - `depth_control`
+  - `stabilization_path`
+  - `version`
+  - `last_updated`
+- `selection_priority` 应使用 1-10 范围，而不是当前 95 / 80 这类百分制风格。
+- `model_type` 应使用 GPT 规划中的枚举，例如 `routing_model`、`deep_modeling_model`。
+- `pipeline_position` 应使用 GPT 规划中的枚举，例如 `pre_analysis`、`deep_analysis`。
+- `stability_profile` 需要包含：
+  - `stability_level`
+  - `needs_stabilization`
+  - `main_risks`
+  - `reason`
+  - `next_stabilization_action`
+- 每个 schema 属性需要中文 `description`，避免字段歧义。
+
+## Adopted Into Local Workflow
+
+本轮只在规则文件中记录 workflow gate，尚未创建 `docs/MODEL_EXTRACTION_WORKFLOW.md`。
+
+待落地 workflow：
+
+1. GPT plan intake。
+2. Local plan creation。
+3. Owner review of local plan。
+4. Rules/schema/index/workflow implementation。
+5. Validation of rules/schema/index/workflow。
+6. Owner review of the foundation。
+7. Content extraction or content repair。
+8. Validation and audit report。
+9. Owner content review。
+
+## Adopted Into Tooling Plan
+
+本轮尚未修改工具。
+
+GPT 规划中待落地的工具要求：
+
+- `scripts/validate_model_library.py` 需要升级为 schema、引用、index、card contract、regression coverage 的综合校验器。
+- 需要新增 `scripts/check_card_contract.py`，检查 Markdown card 必需章节。
+- 需要新增 `scripts/run_selector_demo.py`，按关键词、输入类型、负向触发、pipeline position、selection_priority 输出推荐模型、分数、理由和 routing notes。
+- 如果后续需要从 GPT 规划自动提取字段和验收标准，可新增 `scripts/extract_plan_requirements.py`，但 v0.1 暂不必做。
+
+## Differences From Current Repository
+
+当前仓库与 GPT 规划的主要差异：
+
+1. `cards/qpi.md` 和 `cards/intellectual_archaeology.md` 目前不是按完整 card contract 写成，缺少 GPT 规划中的多个章节。
+2. 当前没有 `docs/MODEL_CARD_CONTRACT.md`。
+3. 当前没有 `schemas/model_card.schema.json`。
+4. 当前 `schemas/model_spec.schema.json` 缺少字段描述、枚举、推荐字段和稳定性理由字段。
+5. 当前 model JSON 的 `model_type`、`pipeline_position`、`selection_priority` 与 GPT 规划枚举和范围不一致。
+6. 当前没有 `models/model_index.json`。
+7. 当前没有 `cards/card_index.md`。
+8. 当前没有 index schema。
+9. 当前 selector 只有 data-only rules 和 examples，没有可执行 demo。
+10. 当前 regression cases 是合并文件，不是 GPT 规划中建议的按模型拆分文件；这不一定错误，但需要在后续 schema/workflow 中明确采用合并还是拆分。
+11. 当前 validation 只检查基础必填字段和引用完整性，没有完整 schema、card contract、index、selector demo 或 regression coverage 检查。
+12. 当前 handoff 把第一版内容称为“资产链路”，但按新的规则判断，它只能算草稿内容，不能算已通过 GPT 样板契约。
+
+## Deferred Items
+
+以下内容留到后续任务执行：
+
+- 创建 `docs/MODEL_CARD_CONTRACT.md`。
+- 创建 `docs/MODEL_EXTRACTION_WORKFLOW.md`。
+- 创建 `schemas/model_card.schema.json`。
+- 为现有 schemas 添加中文 `description` 和枚举约束。
+- 创建 `schemas/model_index.schema.json` 和 `schemas/card_index.schema.json`。
+- 创建 `models/model_index.json` 和 `cards/card_index.md`。
+- 升级 validator。
+- 新增 card contract checker。
+- 新增 selector demo。
+- 重新修复 QPI 和思想考古模型内容。
+
+## Owner Review Questions
+
+1. `tests/regression_cases.json` 是否继续使用合并文件，还是改为 GPT 规划建议的 `tests/qpi.regression.json` 与 `tests/intellectual_archaeology.regression.json`？
+2. 当前两个已经生成的模型内容，后续是直接改写，还是先保留为 `draft_pre_contract` 状态并新建合规版本？
+3. `model_spec.schema.json` 是否保留为旧名兼容，还是迁移到 `model_card.schema.json` 并废弃旧名？
+4. selector demo 是否应在 schema/index 基础完成后立即实现，还是等模型内容修复后再实现？
+5. index 是否在 v0.1 手动维护即可，是否暂缓 full rebuild script？
+
+## Current Recommendation
+
+下一步应执行计划 Task 2 和 Task 3：
+
+1. 建立 `docs/MODEL_CARD_CONTRACT.md`。
+2. 建立 `schemas/model_card.schema.json`。
+3. 给 source、excerpt、regression schema 补中文说明与枚举。
+4. 定义 model/card index schema。
+
+在这些完成并经 owner 检查前，不继续修复 QPI 和思想考古内容。

reports/README.md

@@ -1,11 +1,18 @@
 # Reports
 
-This folder will contain generated or manually written project reports.
+This folder contains generated or manually written project reports.
 
-Expected future files:
+Current reports:
 
 - `validation_report.md`
-- `extraction_notes.md`
+- `Codex_工程产物摘要_v0.1.md`
-- Concrete Codex handoff reports
+- `Codex_模型资产链路摘要_v0.1.md`
+- `baseline_before_content_stabilization_v0.2.md`
+- `evidence_coverage_report_v0.2.md`
+- `selector_regression_report_v0.2.md`
+- `model_card_sync_report_v0.2.md`
+- `content_review_report_v0.2.md`
+- `model_review_status.json`
+- `next_action_register_v0.2.md`
 
 Reports should separate verified facts, assumptions, unresolved questions, and suggested next tasks.

reports/baseline_before_content_stabilization_v0.2.md

@@ -0,0 +1,67 @@
+# Baseline Before Content Stabilization v0.2
+
+Date: 2026-06-16
+
+## Scope
+
+This baseline was captured before the v0.2 content stabilization pass for:
+
+- `qpi`
+- `intellectual_archaeology`
+
+No third model is in scope.
+
+## Baseline Commands
+
+```powershell
+python -m unittest discover -s tests -p "test*.py" -v
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+python scripts\run_selector_demo.py
+python scripts\rebuild_indexes.py --check
+```
+
+## Results
+
+- Unit tests: PASS, 14 tests.
+- Card contract: PASS.
+- Model library validation: PASS.
+- Selector demo: PASS.
+- Model/card index check: PASS.
+
+## Current Asset Counts
+
+- Models: 2
+- Source articles: 3
+- Source evidence excerpts: 10
+- Regression cases: 10 total, 5 per model
+- Selector examples: 3
+
+## Current Model State
+
+| Model ID | Status | Stability | Regression Status |
+| --- | --- | --- | --- |
+| `qpi` | draft | B | pending |
+| `intellectual_archaeology` | draft | B | pending |
+
+## What PASS Means
+
+PASS means:
+
+- JSON files are parseable.
+- Required contract fields exist.
+- Source article and source excerpt references resolve.
+- Regression cases reference known models.
+- Model/card indexes are synchronized.
+- Markdown cards contain required headings.
+
+## What PASS Does Not Mean
+
+PASS does not mean:
+
+- Model content is stable.
+- Evidence is sufficient at field level.
+- Raw excerpts are all exact quotes.
+- Regression cases are strong enough for stable use.
+- Selector behavior is protected against false positive recall.
+- QPI or Intellectual Archaeology can be upgraded to stable.

reports/changed_files_manifest.md

@@ -0,0 +1,39 @@
+# Changed Files Manifest
+
+| File | Change Type | Why Changed | Related Guidance | Need Human Review |
+| --- | --- | --- | --- | --- |
+| `docs/CONTENT_STABILIZATION_PROTOCOL.md` | added | Define content stabilization gates | v0.3 Task 1 | yes |
+| `sources/evidence_coverage.matrix.json` | added | Field-level evidence coverage matrix | v0.3 Task 2 | yes |
+| `reports/evidence_coverage_report_v0.2.md` | added | Human-readable evidence coverage summary | v0.3 Task 2 | yes |
+| `sources/source_excerpts.json` | modified | Add quote_status/source_location and QPI pathology excerpts | v0.3 Task 3 | yes |
+| `schemas/source_excerpt.schema.json` | modified | Formalize quote_status/source_location and excerpt_type enum | v0.3 Task 3 | yes |
+| `schemas/source_article.schema.json` | modified | Formalize source_type/source_status enum | v0.3 Task 3 | yes |
+| `models/qpi.model.json` | modified | Strengthen QPI output contract and source evidence count | v0.3 Task 4 | yes |
+| `cards/qpi.md` | modified | Mirror QPI output contract and evidence references | v0.3 Task 4 | yes |
+| `models/intellectual_archaeology.model.json` | modified | Strengthen IA stop gate and structured output contract | v0.3 Task 5 | yes |
+| `cards/intellectual_archaeology.md` | modified | Mirror IA stop gate and output contract | v0.3 Task 5 | yes |
+| `schemas/regression_case.schema.json` | modified | Add v0.2 evaluable fields and new case types | v0.3 Task 7 | yes |
+| `tests/qpi.regression.json` | added | Per-model QPI regression source of truth, 17 cases | v0.3 Task 6 | yes |
+| `tests/intellectual_archaeology.regression.json` | added | Per-model IA regression source of truth, 17 cases | v0.3 Task 6 | yes |
+| `tests/regression_cases.json` | modified | Aggregate regression cases for validation | v0.3 Task 6 | yes |
+| `tests/regression_index.json` | added | Audit index for split regression files | GPT audit package | yes |
+| `selector/selector_rules.json` | modified | Selector v0.2 rule config | v0.3 Task 8 | yes |
+| `selector/selector_examples.json` | modified | Add no-call and QPI-before-IA examples | v0.3 Task 8 | yes |
+| `scripts/run_selector_demo.py` | modified | Emit selected/rejected models, reasons, penalties, no_call | v0.3 Task 8 | no |
+| `scripts/run_selector_regression.py` | added | Validate no-call/selector gate/pipeline cases | v0.3 Task 8 | no |
+| `scripts/check_model_card_sync.py` | added | Check hard-field JSON/Markdown sync | v0.3 Task 9 | no |
+| `scripts/validate_model_library.py` | modified | Validate quote status, enums, 15-case coverage, v0.2 fields | v0.3 Tasks 3/7 | no |
+| `models/model_index.json` | regenerated | Sync evidence and regression counts | v0.2 index strategy | yes |
+| `cards/card_index.md` | regenerated | Human-readable projection of model index | v0.2 index strategy | yes |
+| `reports/content_review_report_v0.2.md` | added | Content stabilization review summary | v0.3 Task 10 | yes |
+| `reports/model_review_status.json` | added | Structured review status | v0.3 Task 10 | yes |
+| `reports/next_action_register_v0.2.md` | added | Next review/action items | v0.3 Task 10 | yes |
+| `reports/selector_regression_report_v0.2.md` | added/generated | Selector regression PASS report | v0.3 Task 8 | yes |
+| `reports/model_card_sync_report_v0.2.md` | added/generated | JSON/Markdown sync PASS report | v0.3 Task 9 | yes |
+| `reports/validation_report.md` | generated | Validator result | Validation | no |
+| `reports/index_rebuild_report.md` | generated | Index check result | v0.2 index strategy | no |
+| `reports/ChatGPT交接文档_模型库MVP_第二轮内容稳定化_2026-06-16.md` | added | Audit handoff package | GPT audit request | yes |
+| `reports/command_log.md` | added | Command results for audit | GPT audit request | no |
+| `reports/open_questions_for_CCRA.md` | added | Concrete review questions | GPT audit request | yes |
+| `reports/schema_change_notes.md` | added | Schema diff explanation | GPT audit request | yes |
+| `repo_tree.txt` | added | 2-level repo structure for audit | GPT audit request | no |

reports/command_log.md

@@ -0,0 +1,88 @@
+# Command Log
+
+Date: 2026-06-16
+
+```powershell
+python scripts\rebuild_indexes.py --check
+```
+
+Result: PASS
+
+```text
+index check passed
+```
+
+```powershell
+python scripts\check_card_contract.py
+```
+
+Result: PASS
+
+```text
+card contract check passed
+```
+
+```powershell
+python scripts\validate_model_library.py
+```
+
+Result: PASS
+
+```text
+validation passed
+```
+
+```powershell
+python scripts\run_selector_demo.py
+```
+
+Result: PASS
+
+Notes:
+
+- Emits selector v0.2 selected/rejected model output.
+- Demo selects `qpi` and rejects `intellectual_archaeology` for the sample long-termism/KPI input.
+
+```powershell
+python scripts\run_selector_regression.py
+```
+
+Result: PASS
+
+```text
+selector regression passed
+```
+
+```powershell
+python scripts\check_model_card_sync.py
+```
+
+Result: PASS
+
+```text
+model/card sync passed
+```
+
+```powershell
+python -m unittest discover -s tests -p "test*.py" -v
+```
+
+Result: PASS
+
+```text
+Ran 14 tests
+OK
+```
+
+```powershell
+python -m json.tool reports\model_review_status.json
+python -m json.tool sources\evidence_coverage.matrix.json
+python -m json.tool tests\regression_cases.json
+python -m json.tool models\model_index.json
+```
+
+Result: PASS
+
+Notes:
+
+- Key audit JSON files are parseable.

reports/content_review_report.md

@@ -0,0 +1,15 @@
+# Content Review Report
+
+This file is an audit-friendly alias for:
+
+- `reports/content_review_report_v0.2.md`
+
+Current conclusions:
+
+- QPI: `draft / B / pending`
+- Intellectual Archaeology: `draft / B / pending`
+- draft-callable: allowed as report conclusion only
+- stable: not allowed
+- third model expansion: not allowed
+
+See `reports/content_review_report_v0.2.md` for the full report.

reports/content_review_report_v0.2.md

@@ -0,0 +1,177 @@
+# Content Review Report v0.2
+
+Date: 2026-06-16
+
+## 1. 本轮修改摘要
+
+本轮没有扩展第三模型，没有接完整问题回答系统，没有引入 LLM selector，也没有升级 stable。
+
+完成内容稳定化补强：
+
+- 新增 `docs/CONTENT_STABILIZATION_PROTOCOL.md`。
+- 新增字段级 evidence coverage matrix。
+- 修复 source excerpt 的 quote 精确性标记。
+- 强化 QPI 结构化输出契约。
+- 强化思想考古停止门。
+- regression cases 扩展到每模型 17 条。
+- selector 升级到 v0.2 规则防误召回。
+- 新增 JSON / Markdown 同步检查。
+- 新增 review status 和 next action register。
+
+## 2. QPI 内容审查结果
+
+当前状态：
+
+- `status`: draft
+- `stability_level`: B
+- `regression_status`: pending
+
+QPI 已强化输出契约，包含：
+
+- `problem_owner`
+- `problem_source`
+- `time_scale`
+- `scarcity_profile`
+- `dominant_scarcity`
+- `classification`
+- `classification_confidence`
+- `evidence_gap`
+- `misclassification_risk`
+- `recommended_next_step`
+- `next_model_candidates`
+
+审查结论：
+
+- 可进入 draft-callable 审查。
+- 不允许升级 stable。
+- mixed 案例和主导匮乏物判断仍需 Owner / CCRA 复核。
+
+## 3. 思想考古内容审查结果
+
+当前状态：
+
+- `status`: draft
+- `stability_level`: B
+- `regression_status`: pending
+
+思想考古已强化停止门，包含：
+
+- `should_call`
+- `entry_reason`
+- `recommended_max_depth`
+- `layers_to_analyze`
+- `stop_reason`
+- `no_deeper_reason`
+- `assumptions_by_layer`
+- `validation_needed`
+- `action_implication`
+
+审查结论：
+
+- 可进入 draft-callable 审查。
+- 不允许升级 stable。
+- 哲学基岩层调用边界仍需 Owner / CCRA 复核。
+
+## 4. Evidence Coverage 结论
+
+字段级矩阵位于 `sources/evidence_coverage.matrix.json`。
+
+报告位于 `reports/evidence_coverage_report_v0.2.md`。
+
+结论：
+
+- required 字段均已标注 support type 和 coverage status。
+- QPI 的 Q/P/I、核心匮乏物、暴力降维、恶意升维均有 source evidence 支撑。
+- 思想考古的定义、七层机制、动态韧性、最小充分下潜和验证要求均有 source evidence 支撑。
+- status、stability、confidence、selection priority 仍是 owner / product review 判断，不是 source-direct 事实。
+
+## 5. Regression Coverage 结论
+
+Regression source of truth:
+
+- `tests/qpi.regression.json`
+- `tests/intellectual_archaeology.regression.json`
+
+Aggregate file:
+
+- `tests/regression_cases.json`
+
+Coverage:
+
+| Model ID | Total | positive | boundary | misuse | no_call | selector_gate | pipeline |
+| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
+| `qpi` | 17 | 9 | 3 | 2 | 1 | 1 | 1 |
+| `intellectual_archaeology` | 17 | 5 | 3 | 3 | 3 | 2 | 1 |
+
+结论：
+
+- 每模型均超过 15 条。
+- 已覆盖误用、防误召回、no-call 和 pipeline gate。
+- 仍需人工审查用例真实性和遗漏边界。
+
+## 6. Selector Regression 结论
+
+Selector v0.2 仍为规则 selector。
+
+新增能力：
+
+- negative trigger 先行
+- no-call threshold
+- QPI-before-IA gate
+- score breakdown
+- rejected model reasons
+
+报告位于：
+
+- `reports/selector_regression_report_v0.2.md`
+
+结论：
+
+- selector regression 当前 PASS。
+- 明确事实查询、纯改写、轻量翻译不会召回思想考古。
+- 问题定义未完成时，思想考古受 QPI-before-IA gate 抑制。
+
+## 7. JSON / Markdown 同步结论
+
+检查脚本：
+
+- `scripts/check_model_card_sync.py`
+
+报告：
+
+- `reports/model_card_sync_report_v0.2.md`
+
+结论：
+
+- 硬字段同步 PASS。
+- 关键 output contract 和 depth control 术语已在 Markdown card 中出现。
+- 中文长文本语义一致性仍需人工审查。
+
+## 8. 仍未解决的问题
+
+- QPI 的混合案例是否需要更细的主导匮乏物仲裁规则。
+- 思想考古是否应把 `recommended_max_depth` 的默认值与 QPI 输出强绑定。
+- `draft-callable` 是否应进入模型 JSON schema，还是继续留在 review report。
+- selector v0.2 阈值是否需要基于真实输入校准。
+
+## 9. 是否允许进入 draft-callable
+
+允许。
+
+这里的 draft-callable 是 review report 结论，不改变模型 JSON 的 `status: draft`。
+
+## 10. 是否允许升级 stable
+
+不允许。
+
+当前两个模型仍保持：
+
+- `status: draft`
+- `stability_level: B`
+- `regression_status: pending`
+
+## 11. 是否允许扩展第三模型
+
+不允许。
+
+建议先完成 Owner / CCRA 对本轮 evidence、regression、selector 和 content review 的审查。

reports/evidence_coverage_matrix.md

@@ -0,0 +1,17 @@
+# Evidence Coverage Matrix
+
+Machine-readable matrix:
+
+- `sources/evidence_coverage.matrix.json`
+
+Human-readable report:
+
+- `reports/evidence_coverage_report_v0.2.md`
+
+Current conclusion:
+
+- Required fields are classified by support type and coverage status.
+- QPI source-direct fields include Q/P/I taxonomy and core scarcity.
+- QPI misuse coverage includes violent reduction and malicious inflation excerpts.
+- Intellectual Archaeology source-direct fields include definition and seven-layer mechanism.
+- Status, stability, confidence, and selection priority remain review decisions.

reports/evidence_coverage_report_v0.2.md

@@ -0,0 +1,98 @@
+# Evidence Coverage Report v0.2
+
+Date: 2026-06-16
+
+## Scope
+
+Models reviewed:
+
+- `qpi`
+- `intellectual_archaeology`
+
+The field-level machine matrix is stored in `sources/evidence_coverage.matrix.json`.
+
+## Coverage Method
+
+Each required model field is classified by:
+
+- `support_type`
+- `coverage_status`
+- supporting `excerpt_ids`
+
+Support type values:
+
+- `direct_source`
+- `derived_from_source`
+- `product_decision`
+- `red_team_inference`
+- `owner_decision`
+
+Coverage status values:
+
+- `supported`
+- `partially_supported`
+- `derived`
+- `unsupported`
+- `needs_owner_review`
+
+## QPI Summary
+
+Directly supported fields include:
+
+- `model_name`
+- `one_sentence_definition`
+- `core_mechanism`
+
+Derived or productized fields include:
+
+- `model_type`
+- `pipeline_position`
+- `input_types`
+- `output_types`
+- `trigger_keywords`
+- `negative_triggers`
+- `output_contract`
+
+Owner / CCRA review fields include:
+
+- `status`
+- `selection_priority`
+- `confidence_level`
+- `stability_profile`
+- `regression_status`
+
+No required field is currently marked `unsupported`.
+
+## Intellectual Archaeology Summary
+
+Directly supported fields include:
+
+- `model_name`
+- `one_sentence_definition`
+- `core_mechanism`
+
+Derived or productized fields include:
+
+- `model_type`
+- `pipeline_position`
+- `input_types`
+- `output_types`
+- `trigger_keywords`
+- `negative_triggers`
+- `output_contract`
+
+Owner / CCRA review fields include:
+
+- `status`
+- `selection_priority`
+- `confidence_level`
+- `stability_profile`
+- `regression_status`
+
+No required field is currently marked `unsupported`.
+
+## Review Conclusion
+
+Evidence coverage is now explicit enough for content review.
+
+This does not mean all fields are source-direct. It means source-backed, derived, productized, red-team, and owner-decision fields are separated for review.

reports/index_check_report.md

@@ -0,0 +1,22 @@
+# Index Check Report
+
+Date: 2026-06-16
+
+Status: `PASS`
+
+Command:
+
+```powershell
+python scripts\rebuild_indexes.py --check
+```
+
+Canonical generated report:
+
+- `reports/index_rebuild_report.md`
+
+Result:
+
+- `models/model_index.json` matches the generated registry.
+- `cards/card_index.md` matches the generated human-readable projection.
+- QPI index counts: source evidence 7, regression cases 17.
+- Intellectual Archaeology index counts: source evidence 5, regression cases 17.

reports/index_rebuild_report.md

@@ -0,0 +1,9 @@
+# Index Rebuild Report
+
+Mode: `check`
+Status: `PASS`
+
+## Result
+
+- models/model_index.json matches generated model registry.
+- cards/card_index.md matches generated card index.

reports/model_card_sync_report_v0.2.md

@@ -0,0 +1,13 @@
+# Model Card Sync Report v0.2
+
+Status: `PASS`
+
+## Hard-Field Result
+
+- Model IDs, names, types, pipeline positions, source IDs, evidence IDs, stability fields, regression status, version, and last_updated are present in Markdown cards.
+- Key output contract and depth-control terms are present.
+
+## Manual Review Items
+
+- intellectual_archaeology: long Chinese definitions, examples, and risk notes require human semantic review.
+- qpi: long Chinese definitions, examples, and risk notes require human semantic review.

reports/model_case_preprocessing/qpi/round-01/README.md

@@ -0,0 +1,13 @@
+# QPI Case Preprocessing Round 01
+
+status: draft_owner_review_needed
+
+This round preprocesses owner-provided raw QPI materials into Markdown case drafts.
+
+Raw source files currently assigned:
+
+- `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\流程改造.md`
+- `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\失望性情感隔离心理分析.md`
+
+Output files should remain Markdown drafts until owner review.
+

reports/model_case_preprocessing/qpi/round-01/disappointment-emotional-isolation.cases.md

@@ -0,0 +1,569 @@
+# QPI Case Drafts: Disappointment Emotional Isolation
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\失望性情感隔离心理分析.md`
+
+source_note: Owner-provided raw material. These drafts paraphrase and restructure the source into QPI review cases. They are not clinical assessments and should not be promoted to JSON until owner review.
+
+## Case qpi-draft-001: Same Surface Term, Different Mechanisms
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\失望性情感隔离心理分析.md`
+
+### 1. Surface Problem
+
+The surface phrase "disappointment emotional isolation" appears to name one phenomenon, but the source separates at least two frames: passive emotional numbness and active cognitive withdrawal.
+
+### 2. Subject Position
+
+The subject may be a person reflecting on their own relational withdrawal, a reader seeking conceptual clarity, or an analyst trying to distinguish mechanisms. The experience level is unknown unless the case specifies whether the subject is seeking vocabulary, self-regulation, or model building.
+
+### 3. Scenario Context
+
+The context is psychological-relational interpretation: repeated disappointment in important relationships may lead either to reduced felt response or to deliberate boundary-setting. The same surface description can therefore point to different underlying frames.
+
+### 4. Expectation-Reality Gap
+
+- Expected: A single label should clarify the state.
+- Reality: The label compresses distinct mechanisms with different intervention implications.
+- Gap summary: Naming the phenomenon is insufficient because the frame depends on whether the subject cannot feel, can feel but withdraws, or is using the label to organize a relationship boundary.
+
+### 5. Attempted Paths
+
+The source attempts to split the phrase into mechanism types before applying QPI. It also warns against treating the phrase as a standalone diagnosis or moral judgment.
+
+### 6. Dynamic Shift
+
+The frame can shift from Q to P/I. At first it looks like a Q: "What does this phrase mean?" Once the subject asks how the state is maintained, generalized, or governed in relationships, it becomes P/I mixed or Issue.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: medium
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+The same phrase can be classified differently depending on whether the subject is asking for conceptual definition, self-management steps, or long-term relational governance.
+
+### 9. Governance Load
+
+The governance load is medium to high when the label affects boundaries, help-seeking, self-interpretation, and relationship decisions. It is low only when the task is limited to vocabulary clarification.
+
+### 10. Misframing Risks
+
+- premature_classification
+- single-cause_reduction
+- over_pathologizing
+- violent_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: mixed
+- classification_confidence: medium
+- recommended_next_step: Clarify whether the subject needs definition, self-regulation, relational boundary design, or long-term governance before assigning a Q/P/I route.
+
+### 12. Owner Review Questions
+
+- Should this be treated primarily as a QPI multi-perspective sample rather than an intra-frame mixed sample?
+- Should the QPI output require a mechanism distinction before any route recommendation?
+- Is "passive numbness vs active withdrawal" a required preprocessing distinction for future psychological-relational cases?
+
+## Case qpi-draft-002: I Domain Misread As a Label Question
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\失望性情感隔离心理分析.md`
+
+### 1. Surface Problem
+
+A subject may ask whether their relational withdrawal has a named psychological label.
+
+### 2. Subject Position
+
+The subject is likely a self-reflective owner trying to understand a recurring relational pattern. The responsibility scope is not only learning a concept, but deciding how the concept should affect self-understanding, boundaries, and future action.
+
+### 3. Scenario Context
+
+The source treats the phenomenon as a psychological-relational system involving expectation, response history, self-explanation, defense, relationship patterns, and current life context.
+
+### 4. Expectation-Reality Gap
+
+- Expected: A correct label will settle the question.
+- Reality: A label can explain one layer while hiding the system dynamics that keep the pattern stable.
+- Gap summary: The subject may be seeking identity certainty through a Q-shaped question, while the actual work requires long-term framing and calibration.
+
+### 5. Attempted Paths
+
+The source names several explanatory models but rejects using any one of them as a final single-cause answer.
+
+### 6. Dynamic Shift
+
+The case starts as Q: "What is this?" It shifts to I when the label becomes part of the subject's identity, relational decisions, and self-governance system.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+Within the same subject frame, there is both knowledge scarcity and governance scarcity. The label may help, but routing only to Q risks missing the recurring system.
+
+### 9. Governance Load
+
+High. The subject must manage the cost and benefit of the explanatory label, prevent identity freezing, and decide what kinds of external support or self-regulation are appropriate.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- premature_classification
+- single-cause_reduction
+- over_pathologizing
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat the label as a provisional map, then ask what pattern is recurring, what it protects, what it costs, and what context is needed before choosing an intervention route.
+
+### 12. Owner Review Questions
+
+- Should the dominant route be Issue rather than mixed once the subject is using the label to organize identity and relationships?
+- What minimum context would distinguish a pure Q concept lookup from an I-domain self-framing case?
+- Should this become a selector false-positive trap for "what is X" questions that are actually identity/governance cases?
+
+## Case qpi-draft-003: Single-Cause Attribution Compresses a System
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\失望性情感隔离心理分析.md`
+
+### 1. Surface Problem
+
+The subject asks whether one source, such as childhood experience, family relationship, attachment style, or social pressure, explains the current isolation pattern.
+
+### 2. Subject Position
+
+The subject is a person or analyst trying to locate causality. The responsibility scope may range from understanding a pattern to choosing an intervention or assigning blame.
+
+### 3. Scenario Context
+
+The source argues that psychological-relational patterns are coupled systems. Multiple models may each explain part of the pattern, but no single factor should be treated as the complete cause.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Finding the main cause will make the problem tractable.
+- Reality: The pattern may be maintained by interacting histories, interpretations, learned predictions, boundaries, pressures, and current relationship conditions.
+- Gap summary: A single-cause explanation can make an Issue look like a solvable Problem or a finished Question.
+
+### 5. Attempted Paths
+
+The source reviews several attribution paths and criticizes single-point, moral, and intervention-as-cause explanations.
+
+### 6. Dynamic Shift
+
+The frame shifts from Q/P to I. It may begin as "What caused this?" or "How do I fix this?", but the source reframes the task as maintaining and recalibrating a dynamic system.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+Within one subject frame, the same case contains evidence gaps, intervention uncertainty, and governance load. It is not merely multiple observers disagreeing.
+
+### 9. Governance Load
+
+High. The subject must avoid blame compression, preserve explanatory plurality, and decide which factor is actionable at the current stage without claiming it is the only cause.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- over_pathologizing
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Require a multi-factor maintenance map and separate cause, trigger, maintaining condition, and current action lever before recommending a route.
+
+### 12. Owner Review Questions
+
+- Should QPI explicitly mark "single-cause reduction" as a subtype of violent reduction?
+- Should this case be used to test that QPI does not output a single definitive cause when the source provides coupled mechanisms?
+- What owner-approved language should be used to distinguish explanatory usefulness from causal finality?
+
+## Case qpi-draft-004: Intervention Framed as a One-Time Solution
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\失望性情感隔离心理分析.md`
+
+### 1. Surface Problem
+
+The subject asks how to reduce or fix emotional isolation.
+
+### 2. Subject Position
+
+The subject is likely the person experiencing the pattern or someone advising them. The responsibility scope includes selecting actions without pretending the issue can be permanently solved in one step.
+
+### 3. Scenario Context
+
+The source reframes intervention from finding a cure to managing isolation intensity, object, benefit, cost, and generalization over time.
+
+### 4. Expectation-Reality Gap
+
+- Expected: There should be a method or treatment plan that removes the isolation.
+- Reality: The phenomenon may require ongoing calibration of expectations, boundaries, investment, and relational experiments.
+- Gap summary: The problem is not "which solution works once" but "how to govern a protective pattern that can become overgeneralized."
+
+### 5. Attempted Paths
+
+The source considers external intervention, self-adjustment, and relational experience, while arguing that the goal is not a single answer but a self-governance system.
+
+### 6. Dynamic Shift
+
+The frame shifts from P to I. It begins as a path problem but becomes an Issue because the relevant actions change with relationship context, risk, feedback, and stage.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The subject needs both action paths and governance rules. A pure P route would overpromise a one-time fix.
+
+### 9. Governance Load
+
+High. The subject must continuously calibrate when isolation is protective, when it is costly, and when external support is useful.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- tool_solutionism
+- malicious_inflation
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Route as P/I mixed: identify one immediate boundary or experiment, while also defining ongoing governance variables and review conditions.
+
+### 12. Owner Review Questions
+
+- Should "cannot be solved once, can be governed over time" be a standard Issue signal?
+- Should this case become a regression sample for preventing QPI from over-routing psychological-relational questions to Problem?
+- What minimum actionability is required before recommending a P step inside an I-domain case?
+
+## Case qpi-draft-005: External Help as Method Teaching vs Calibration Environment
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\失望性情感隔离心理分析.md`
+
+### 1. Surface Problem
+
+The subject questions whether external psychological support is useful or merely treats symptoms.
+
+### 2. Subject Position
+
+The subject is evaluating the role of external intervention while preserving personal agency. The subject may distrust external authority, commercialized help, or over-generalized therapeutic scripts.
+
+### 3. Scenario Context
+
+The source distinguishes low-quality outside intervention from high-quality support that helps the subject build self-governance, feedback, boundary, and relational calibration capacities.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Either the subject must self-design the intervention model, or external help must solve it.
+- Reality: A better frame distributes roles: the subject retains final agency, while external support can provide feedback, mirror, method, and safe relational correction.
+- Gap summary: The question is not whether outside help solves the Issue, but what role it plays in the governance system.
+
+### 5. Attempted Paths
+
+The source first considers the claim that external intervention may be limited, then refines it by separating poor intervention from support that enables self-governance.
+
+### 6. Dynamic Shift
+
+The frame shifts from binary Q/P to Issue. The relevant judgment depends on role boundaries, quality conditions, and how the intervention changes the subject's self-regulation system.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same subject needs to decide both what to do and how to govern agency, trust, expertise, and external calibration boundaries.
+
+### 9. Governance Load
+
+High. The case requires role boundary management, risk control, authority calibration, and ongoing assessment of whether external help increases or weakens self-governance.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- single-cause_reduction
+- over_pathologizing
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Reframe from "external help works or does not work" to "what external role, under what boundaries, helps the subject build a stronger self-governance system."
+
+### 12. Owner Review Questions
+
+- Is this an Issue sample because it is primarily about role/order calibration rather than method selection?
+- Should QPI include "external authority boundary" as a governance-load signal?
+- Should selector calibration treat "does therapy work" style inputs as low-confidence until context is known?
+
+## Case qpi-draft-006: Time Scale Changes the QPI Classification
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\失望性情感隔离心理分析.md`
+
+### 1. Surface Problem
+
+The same relational phenomenon appears to have different QPI classifications depending on time scale and system boundary.
+
+### 2. Subject Position
+
+The subject is a model builder or self-reflective owner evaluating how one phenomenon changes across moments, situations, and life-history scale.
+
+### 3. Scenario Context
+
+The source explicitly frames Q/P/I as dynamic viewpoints rather than static properties. A question about one moment may differ from a question about a concrete decision or a life-system pattern.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The phenomenon should have one stable classification.
+- Reality: It may be Q at the concept level, P at the action-decision level, and I at the long-term life-pattern level.
+- Gap summary: Classification depends on observer position, time scale, goal scale, and system boundary.
+
+### 5. Attempted Paths
+
+The source proposes treating problem granularity as a modeling result rather than a fixed property of the issue.
+
+### 6. Dynamic Shift
+
+This is the core case: Q -> P -> I across time and scope. The dynamic shift is not a failure of classification; it is the phenomenon QPI must represent.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+The divergence comes from different time scales and responsibility scopes. It should not be collapsed into intra-frame mixed unless the same subject is operating at multiple scales simultaneously.
+
+### 9. Governance Load
+
+High when the subject must choose the right scale before acting. Mis-scaling can cause over-analysis, under-analysis, or wrong intervention choice.
+
+### 10. Misframing Risks
+
+- premature_classification
+- malicious_inflation
+- violent_reduction
+- tool_solutionism
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: mixed
+- classification_confidence: medium
+- recommended_next_step: Ask for the subject's active time scale and decision boundary before deciding whether to answer, solve, or govern.
+
+### 12. Owner Review Questions
+
+- Should QPI output include a required `time_scale` or `classification_scope` field for this exact reason?
+- Should "same phenomenon, different time scale" be treated as inter-viewpoint divergence or a separate dynamic-scope category?
+- Should selector calibration include short inputs that are no-call or Q at one scale but QPI/Issue at another?
+
+## Case qpi-draft-007: QPI Mismatch Table for Psychological-Relational Material
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\失望性情感隔离心理分析.md`
+
+### 1. Surface Problem
+
+The source identifies recurring mistakes where a psychological-relational Issue is treated as a label question, single-step solution, moral judgment, or over-expanded life theory.
+
+### 2. Subject Position
+
+The subject is a QPI model builder or reviewer designing guardrails for future classification. The responsibility scope is product/model stability rather than direct advice.
+
+### 3. Scenario Context
+
+The context is QPI model hardening. Psychological-relational inputs often contain ambiguous language that can trigger over-simplification or over-complication.
+
+### 4. Expectation-Reality Gap
+
+- Expected: A table of Q/P/I categories can classify the input.
+- Reality: The more important task is detecting frame mismatch before routing.
+- Gap summary: QPI needs misframing diagnostics, not only final labels.
+
+### 5. Attempted Paths
+
+The source lists mismatch patterns such as treating an Issue as a label lookup, treating an Issue as a one-step plan, or turning a simple concept question into a life problem.
+
+### 6. Dynamic Shift
+
+The frame shifts from model content to model validation. The case is about how QPI itself should resist failure modes.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`not_mixed`
+
+This is primarily a guardrail case for QPI itself, not a user-world case with multiple simultaneous scarcities.
+
+### 9. Governance Load
+
+High for the model library. The rule must prevent future selector and regression samples from rewarding shallow category assignment.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- tool_solutionism
+- premature_classification
+- single-cause_reduction
+- over_pathologizing
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: false
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Add QPI mismatch diagnostics to case preprocessing so each draft records both candidate classification and likely wrong classifications.
+
+### 12. Owner Review Questions
+
+- Should QPI case digest include an explicit `wrong_route_to_avoid` field?
+- Should mismatch detection become part of QPI regression rather than selector calibration only?
+- Which mismatch labels should be canonical in v0.3?
+
+## Case qpi-draft-008: Isolation as Protective Boundary or Overgeneralized Defense
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\失望性情感隔离心理分析.md`
+
+### 1. Surface Problem
+
+The subject asks whether emotional withdrawal is unhealthy avoidance or a valid boundary.
+
+### 2. Subject Position
+
+The subject is a person evaluating their own relational strategy. The subject has final authority over boundaries, but may not have enough feedback to tell whether the strategy remains adaptive.
+
+### 3. Scenario Context
+
+The source frames isolation as potentially protective in high-risk relationships, but costly when generalized to safe or potentially supportive relationships.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The strategy should be judged as either good boundary or bad avoidance.
+- Reality: The judgment depends on target, intensity, duration, benefit, cost, and current environment.
+- Gap summary: A binary moral or clinical judgment misses the governance variables that determine whether isolation is still serving the subject.
+
+### 5. Attempted Paths
+
+The source proposes evaluating object, strength, benefit, and cost rather than treating isolation as uniformly good or bad.
+
+### 6. Dynamic Shift
+
+The frame shifts from Q to I. It may start as "Is this normal?" but becomes an ongoing calibration problem across relationships and stages.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same subject must integrate evidence, action paths, and governance tradeoffs. A one-label answer is inadequate.
+
+### 9. Governance Load
+
+High. The subject must repeatedly judge when withdrawal is protective, when it is overgeneralized, and when a new relational experiment is worth the risk.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- over_pathologizing
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Replace binary judgment with a governance review: target, strength, duration, benefit, cost, and evidence for whether the strategy still fits the current context.
+
+### 12. Owner Review Questions
+
+- Should this be classified as Issue rather than P/I mixed because the core task is ongoing calibration?
+- What evidence would justify routing part of the case to Problem, such as a concrete boundary conversation?
+- Should this case become a canonical example of "Issue does not require many people; one-person self-governance can still be Issue"?

reports/model_case_preprocessing/qpi/round-01/flow-redesign.cases.md

@@ -0,0 +1,423 @@
+# QPI Case Drafts: Flow Redesign
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\流程改造.md`
+
+source_note: Raw source remains outside this repository. These are reviewable QPI case drafts only; they are not selector JSON, regression cases, or owner-approved calibration data.
+
+## Case qpi-draft-001: Outline Review Was Not The Real Entry Point
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\流程改造.md`
+
+### 1. Surface Problem
+
+The apparent problem was how to automate an existing article-outline review loop with multiple reviewers and a main writer.
+
+### 2. Subject Position
+
+The subject is the owner as an experienced writer, model builder, and workflow designer trying to externalize a mature personal writing process into a file-first, agentic workflow. The owner is not a beginner asking how to review an outline; the owner is responsible for preserving writing judgment, source fidelity, role boundaries, and downstream reuse.
+
+### 3. Scenario Context
+
+The case appears in the transition from a Web single-agent writing workflow to a Codex / CCPE / writing-workbench style workflow. The initial target was a small outline-review loop, but the workflow exposed a prior dependency on material preparation and context engineering before outline generation.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The owner expected the outline review stage to be the highest-value small loop to automate first.
+- Reality: The review stage depended on earlier material compression, premise context, main-writer framing, and user confirmation. If these were missing, review would only discover unstable foundations late.
+- Gap summary: The apparent P-domain task of automating outline review shifted into a broader workflow-framing issue about where context engineering must sit.
+
+### 5. Attempted Paths
+
+The initial path treated "existing draft outline enters review" as the entry point. After discussion, the entry was moved earlier: raw viewpoint material -> context engineering -> premise context pack -> main-writer framing -> owner confirmation -> outline v1 -> outline-aligned context -> review.
+
+### 6. Dynamic Shift
+
+P -> P/I mixed. The task began as a bounded process automation problem, then became a governance problem about sequencing, context sufficiency, and avoiding late-stage review over unstable inputs.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+For the same owner in the same workflow, there is both path scarcity (how to automate the loop) and order/governance scarcity (where the real entry point should be, and which stage has authority).
+
+### 9. Governance Load
+
+High. The case requires deciding stage boundaries, ownership of context engineering, when owner confirmation is required, and how to keep later review from compensating for earlier context failure.
+
+### 10. Misframing Risks
+
+- tool_solutionism
+- premature_classification
+- violent_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Confirm whether QPI should classify this as P/I mixed rather than a simple workflow automation problem, and identify which context gates are required before outline review.
+
+### 12. Owner Review Questions
+
+- Should the dominant scarcity be `consensus_order`, or is `path_resource` more accurate for this stage?
+- Is "outline review was the wrong entry point" the core case, or should it be folded into a larger context-engineering case?
+- Should this case become a selector calibration example for "workflow automation that looks like P but becomes P/I mixed"?
+
+## Case qpi-draft-002: Dispatch Pack Was Mistaken For Real Invocation
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\流程改造.md`
+
+### 1. Surface Problem
+
+The apparent problem was that a multi-agent review test produced files but failed when inspected for actual agent invocation boundaries.
+
+### 2. Subject Position
+
+The subject is the owner as workflow auditor and product boundary enforcer. The owner is checking whether review outputs are real independent agent outputs or main-session simulations.
+
+### 3. Scenario Context
+
+The failed Sanguo test used writing-workbench-style artifacts for Han Yu, Zhang Liao, Cognitive Imaging, Giant Cognition, and Outline Context Architect. The owner asked for the exact prompt, send instruction, and direct reply for Zhang Liao, exposing that the report had been simulated by the main session.
+
+### 4. Expectation-Reality Gap
+
+- Expected: A dispatch pack plus role-specific files would represent real participant invocation.
+- Reality: The dispatch pack was only a task description or index, not a complete prompt-to-send or invocation packet. Outputs that looked like reports were not generated by independent agent instances.
+- Gap summary: File completeness created a workflow illusion; the missing scarcity was execution authenticity and invocation traceability.
+
+### 5. Attempted Paths
+
+The workflow initially accepted generated role reports. After inspection, simulated outputs were marked unusable, the test was invalidated, and the requirement for Agent Invocation Packet / prompt-to-send / invocation record was introduced.
+
+### 6. Dynamic Shift
+
+P -> I. At first the issue looked like a missing file-format or dispatch-design problem. It shifted into a governance rule: formal reports must come from real independent participants or be blocked.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The owner is in one frame, but the problem includes both a path gap (how to package invocation) and an order gap (what counts as formal output).
+
+### 9. Governance Load
+
+High. This case depends on audit authenticity, role boundary management, formal-output eligibility, and a rule that the orchestrator must stop rather than simulate when true invocation is unavailable.
+
+### 10. Misframing Risks
+
+- tool_solutionism
+- premature_classification
+- violent_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: false
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: high
+- recommended_next_step: Treat this as a QPI Issue example where the key scarcity is not "how to generate files" but "what execution boundary makes an output legitimate."
+
+### 12. Owner Review Questions
+
+- Is `issue` too strong here, or should this be `mixed` because invocation packet implementation also has a clear P component?
+- Should "formal_output: false" and "simulation-only" be named as expected downstream routing notes in the case digest?
+- Should this case be used as a no-simulation calibration example across other models, not only QPI?
+
+## Case qpi-draft-003: Chunk-First Distillation Produced Local Truth But Global Misread
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\流程改造.md`
+
+### 1. Surface Problem
+
+The apparent problem was how to distill a long discussion into reusable topics and material routes.
+
+### 2. Subject Position
+
+The subject is the owner as knowledge-vault maintainer and topic-structure reviewer. The owner is not merely asking for a summary; the owner needs material structure that future writing, modeling, and engineering tasks can consume.
+
+### 3. Scenario Context
+
+The material-distillation workflow around `失望性情感隔离` ran multiple times. The first attempt split the source into chunks and asked workers to extract topics, then tried to reconstruct the whole. Later attempts introduced whole-source gestalt before worker extraction.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Chunked worker extraction would make long-source distillation scalable.
+- Reality: Local topic extraction produced locally true outputs but misread or flattened the whole discussion's structure, main axis, and model-evolution line.
+- Gap summary: The workflow lacked a whole-source gestalt gate before fragmentation.
+
+### 5. Attempted Paths
+
+The first path was R01-R07 chunk-first extraction, followed by topic hierarchy repair. The corrected path started with Step 0 whole-source gestalt, then language repair, structure revision, human confirmation, broad-fidelity workers, synthesis preparation, topic map, material routing, topic docs, and coverage audit.
+
+### 6. Dynamic Shift
+
+Q/P -> P/I mixed. At the surface, the question is how to split and summarize long material. In practice, the central issue is when local extraction has enough authority to shape global structure.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same owner and same source-processing workflow contain both path scarcity (how to process long material) and order scarcity (which layer has authority: whole-source gestalt, chunks, topic map, or human confirmation).
+
+### 9. Governance Load
+
+High. The case requires managing source fidelity, whole/part authority, human confirmation gates, and downstream risk if temporary topic structures become authoritative.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- premature_classification
+- single-cause_reduction
+- tool_solutionism
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: false
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: high
+- recommended_next_step: Use this as a QPI example where the correct first move is not more extraction, but a structure-authority gate that distinguishes local truth from global structure.
+
+### 12. Owner Review Questions
+
+- Should this case be split into two: one for chunk-first failure and one for whole-source gestalt as remedy?
+- Is `dominant_scarcity=consensus_order` correct, or should the dominant scarcity be `path_resource` because the workflow lacked the right processing path?
+- Should "local truth impersonating global structure" become a named misframing risk in QPI?
+
+## Case qpi-draft-004: Material Distillation Needed Stop Gates, Not More Automation
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\流程改造.md`
+
+### 1. Surface Problem
+
+The apparent problem was how far to continue processing distilled material after topic maps and topic documents were available.
+
+### 2. Subject Position
+
+The subject is the owner as knowledge process designer deciding what belongs in knowledge-vault, what should move to writing-workbench, what may become model-mining, and what should stop as a one-time record.
+
+### 3. Scenario Context
+
+The third distillation run produced a more mature chain with source map, topic map, material routing, topic documents, human confirmation, and coverage audit. The owner then explicitly skipped model-mining because formal modeling should not be produced by mechanically processing one discussion draft.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Once a mature distillation chain exists, it might naturally continue into topic docs, model-mining, writing project setup, or downstream handoff.
+- Reality: More automation could prematurely solidify provisional structures or create downstream work not yet authorized by owner judgment.
+- Gap summary: The scarcity is not output quantity; it is a stop rule that protects authority, scope, and downstream intent.
+
+### 5. Attempted Paths
+
+The workflow matured through multiple gates and audits, but retained explicit boundaries: knowledge-vault handles discussion distillation and knowledge processing; writing-workbench consumes only after the owner decides to write; model-mining is skipped unless separately authorized.
+
+### 6. Dynamic Shift
+
+P -> I. The processing pipeline can be engineered, but deciding when not to continue is a governance problem.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same source-processing frame combines a solvable pipeline problem with an authority and stop-boundary problem.
+
+### 9. Governance Load
+
+High. The case involves owner confirmation, downstream dependency control, preventing premature model extraction, and preventing automation from converting temporary structures into canonical outputs.
+
+### 10. Misframing Risks
+
+- tool_solutionism
+- malicious_inflation
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: false
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: high
+- recommended_next_step: Treat stop-gate placement as a first-class QPI Issue: define which downstream transitions require owner confirmation before any automated continuation.
+
+### 12. Owner Review Questions
+
+- Should this case be classified as `issue`, or as `mixed` because there are also concrete pipeline implementation tasks?
+- Should "do not automatically create writing project / model-mining" become an expected routing note?
+- Which owner confirmation gates should be represented in the eventual case digest?
+
+## Case qpi-draft-005: Personal Workflow Redesign Looked Like P But Became P/I
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\流程改造.md`
+
+### 1. Surface Problem
+
+The apparent problem was that the owner felt a personal workflow redesign should be a P-domain task because it involved only the owner and seemed close to software/process engineering.
+
+### 2. Subject Position
+
+The subject is the owner reflecting on their own workflow design. The owner has strong experience in writing, software development, abstraction, and model building, but is now externalizing personal judgment into an agentic, file-backed cognitive production system.
+
+### 3. Scenario Context
+
+The reflection compares Vibe Coding small systems with redesigning writing and material-distillation workflows in Codex-like agentic environments. Code often has hard feedback; cognitive workflows rely on judgment, audit, counterexamples, and calibration.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Because the affected audience was mainly the owner, the redesign should be a P-domain tool-familiarity or implementation issue.
+- Reality: The workflow involved multiple reasonable goals, quasi-stakeholders, state continuity, invocation authenticity, token cost, source fidelity, downstream reuse, and audit boundaries.
+- Gap summary: The owner initially treated difficulty as accidental complexity from unfamiliar tools, but the deeper difficulty was essential complexity from governance and judgment externalization.
+
+### 5. Attempted Paths
+
+The owner tried to reason from ordinary software development and personal process automation. The analysis reframed the case: small software development often remains P because tests and runtime feedback provide convergence, while cognitive workflow redesign becomes P/I when the validation mechanism itself is part of the system.
+
+### 6. Dynamic Shift
+
+P -> P/I mixed. The initial framing is a practical implementation problem; the later framing recognizes ongoing governance load and unstable success criteria.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same owner and same redesign effort include P-domain path questions and I-domain governance questions. This is not merely `inter_viewpoint_divergence`, because the case is not different subjects classifying the same sentence differently; it is one subject discovering deeper governance load in the same situation.
+
+### 9. Governance Load
+
+Very high. The workflow has proxy stakeholders: present owner, future owner, future writing projects, future knowledge-vault maintenance, agent roles, source material, topic docs, token budget, invocation authenticity, coverage fidelity, and future model-mining.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- tool_solutionism
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: false
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: high
+- recommended_next_step: Use this as a primary QPI calibration case for the rule that Issue does not require many human participants; ongoing governance load and proxy stakeholders can raise Issue weight.
+
+### 12. Owner Review Questions
+
+- Does this case capture your intended QPI update: "Issue is sustained governance load, not only multi-person conflict"?
+- Should this become the anchor case for `intra_frame_mixed` in QPI contextual routing rules?
+- Should the eventual digest preserve "code has a compiler; process has no compiler" as a concise rationale, or is that too interpretive?
+
+## Case qpi-draft-006: Complexity Placement Gate
+
+status: draft_owner_review_needed
+
+source_path: `C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\QPI案例分析\流程改造.md`
+
+### 1. Surface Problem
+
+The apparent problem was whether the redesigned workflow had become over-engineered.
+
+### 2. Subject Position
+
+The subject is the owner as process architect deciding which complexity is justified and which should be removed.
+
+### 3. Scenario Context
+
+The source reframes Anti-Overengineering Gate into Complexity Placement Gate. The question changes from "Is this too complex?" to "What does this complexity buy?"
+
+### 4. Expectation-Reality Gap
+
+- Expected: The system might be judged by whether it has too many folders, agents, protocols, audits, or handoff artifacts.
+- Reality: Some complexity is required when it purchases authenticity, independence, fidelity, structure, traceability, reviewability, reuse, or downstream dependency value. Other complexity should be cut if it buys none of these.
+- Gap summary: The core scarcity is a decision rule for placing complexity, not a blanket rule to simplify or expand.
+
+### 5. Attempted Paths
+
+The source lists examples: Agent Invocation Packet is justified because it buys authenticity; whole-source gestalt is justified because it buys structure; full coverage audit, thick topic docs, downstream handoff packets, or real worker invocation may or may not be justified depending on value purchased.
+
+### 6. Dynamic Shift
+
+Q/P -> I. The surface question "Is this too complex?" could invite a simple answer, but the useful frame is an ongoing governance rule for deciding where complexity is worth paying for.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`not_mixed`
+
+This case is primarily about governance criteria. It can generate implementation tasks, but the QPI classification itself is centered on Issue.
+
+### 9. Governance Load
+
+High. The decision must be re-applied across future workflows, source types, worker dispatches, audits, and downstream artifacts.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- tool_solutionism
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: false
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: high
+- recommended_next_step: Treat Complexity Placement Gate as a reusable routing principle: ask what complexity buys before adding or removing process layers.
+
+### 12. Owner Review Questions
+
+- Should Complexity Placement Gate be represented as a QPI case, a separate model candidate, or both?
+- Should this case remain under QPI calibration, or should it later become evidence for another model in the library?
+- Are the listed value categories complete enough for an owner-reviewed case digest?

reports/model_case_preprocessing/qpi/round-01/year-end-review-academic-affairs.cases.md

@@ -0,0 +1,563 @@
+# QPI Case Drafts: Year-End Review Academic Affairs Function
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+source_note: Owner-provided raw organizational material. These drafts are anonymized and generalized for QPI review. Real or potentially identifying people, departments, institutions, timestamps, locations, titles, exact numbers, and sensitive operational details have been removed or generalized. Ancient-style cognitive-anchor names from the source are intentionally omitted. These drafts are not selector JSON, regression cases, or owner-approved calibration data.
+
+anonymization_note: People are represented as generic roles such as `decision_maker`, `execution_lead`, `technical_staff`, `frontline_staff`, and `affected_learners`. The organization is represented as `the organization`; the department is represented as `academic_affairs_function`. Sensitive details are generalized as `external compliance review`, `credential metric`, `staffing ratio`, `assessment material`, `academic integrity risk`, `teaching operation risk`, `quality assurance gap`, and `public safety compliance gap`.
+
+## Case qpi-draft-001: Compliance Reporting Becomes Performative Evidence Construction
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization needs to prepare assessment materials for an external compliance review and wants the submission to present a strong, coherent story.
+
+### 2. Subject Position
+
+The subject is the organization under `decision_maker` pressure, with `academic_affairs_function` and `execution_lead` responsible for converting weak operational reality into acceptable review evidence. The subject is not a neutral writer asking how to improve a report; it is an accountable system tempted to use documentation as a substitute for actual capability.
+
+### 3. Scenario Context
+
+The case appears in a year-end review context where external compliance survival, assessment evidence, and digital tools are discussed together. The organization faces a high-stakes review and is considering tool-assisted reconstruction of materials.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Assessment materials should accurately reflect real teaching operations, quality assurance, and institutional capability.
+- Reality: The proposed path risks starting from desired conclusions and then generating supporting materials backward.
+- Gap summary: A compliance documentation task becomes a truthfulness and governance problem because evidence construction may replace evidence collection.
+
+### 5. Attempted Paths
+
+The apparent path is to use digital or AI tools to accelerate material preparation and make the review narrative more polished. The risky version of this path treats the tool as a way to reverse-engineer evidence after the desired rating is assumed.
+
+### 6. Dynamic Shift
+
+P -> I. It starts as a Problem about how to prepare materials efficiently. It shifts into an Issue because the method changes the organization's relationship to evidence, auditability, and institutional honesty.
+
+### 7. Scarcity Profile
+
+- data_scarcity: high
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+For the same organization in the same review scenario, there is both data scarcity and order scarcity. The organization lacks reliable evidence and is also tempted to change the rules of evidence by treating fabricated coherence as acceptable.
+
+### 9. Governance Load
+
+High. The case requires managing audit authenticity, review exposure, data lineage, tool boundaries, and the difference between legitimate material organization and performative evidence construction.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- tool_solutionism
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Separate legitimate evidence organization from fabricated evidence construction, then require a traceable evidence inventory before any tool-assisted material drafting.
+
+### 12. Owner Review Questions
+
+- Should this case emphasize `consensus_order` because it is about evidence legitimacy, or `data` because the triggering gap is missing reliable proof?
+- Should it become a selector calibration case for "AI or tool request that should not be treated as a simple execution task"?
+- Is the anonymization level sufficient, or should the external review context be generalized further?
+
+## Case qpi-draft-002: Credential Metric Repair Creates Staffing Ratio Deadlock
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization needs to improve a credential or staffing ratio metric for external compliance.
+
+### 2. Subject Position
+
+The subject is the organization as framed by `decision_maker` and implemented through `academic_affairs_function`. `frontline_staff`, newly recruited staff, and existing staff become affected system parts rather than equal framers of the problem.
+
+### 3. Scenario Context
+
+The case appears in a teaching operation and staffing discussion. The organization has recruited or reclassified people to satisfy metric pressure, but the available course structure and role design cannot absorb them productively.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Recruiting or counting higher-credential staff should strengthen compliance and teaching capability.
+- Reality: Credential-matched staff may have no suitable work, while existing staff may lose workload or security.
+- Gap summary: A compliance metric repair creates resource idle time, role mismatch, and internal conflict.
+
+### 5. Attempted Paths
+
+The apparent paths include adding credentialed people, reallocating workload from existing staff, and using organizational structure to make staffing numbers look compliant. These paths improve the table before they improve the operating system.
+
+### 6. Dynamic Shift
+
+P -> I. It begins as a Problem about how to meet a metric. It becomes an Issue because the chosen path creates sustained tradeoffs among compliance, cost, workload fairness, staff morale, and actual teaching value.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same subject in the same scenario faces both path/resource scarcity and order scarcity. The organization can add people, but cannot translate them into useful teaching capacity without triggering conflict.
+
+### 9. Governance Load
+
+High. This requires ongoing management of staffing legitimacy, workload distribution, incentive backlash, budget pressure, compliance exposure, and role boundaries.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat the staffing metric as a P/I mixed case, model real workload absorption before further recruitment or reclassification, and identify which compliance path is legitimate rather than merely cosmetic.
+
+### 12. Owner Review Questions
+
+- Should the dominant scarcity be `path_resource` because the immediate blocker is role absorption, or `consensus_order` because the deeper risk is zero-sum governance?
+- Should this case be merged with other staffing-ratio cases, or kept separate as an academic-affairs-specific example?
+- Does the phrase "credential metric" sufficiently anonymize the original compliance indicator?
+
+## Case qpi-draft-003: Academic Output Incentive Becomes Integrity Backlash
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that an academic output incentive policy produced weak or unreliable outputs and now needs correction.
+
+### 2. Subject Position
+
+The subject is the organization and `academic_affairs_function` dealing with the consequences of a prior incentive design. `frontline_staff` are both participants in the old incentive game and affected parties under the correction.
+
+### 3. Scenario Context
+
+The case appears in a review of teaching quality, promotion incentives, and academic output claims. The organization previously rewarded output quantity or formal compliance, then recognized that the reward system encouraged low-integrity behavior.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Output incentives should encourage real academic or teaching development.
+- Reality: The incentive design encouraged performative output and may have normalized low-integrity shortcuts.
+- Gap summary: A policy intended to strengthen capability created a trust and integrity liability.
+
+### 5. Attempted Paths
+
+The organization appears to have used quantifiable output incentives and then considered or initiated a reversal. The reversal may reduce future distortion, but it also risks backlash from people who already paid cost under the previous rule.
+
+### 6. Dynamic Shift
+
+P -> I. It starts as a Problem about correcting a bad incentive. It shifts into an Issue because the correction affects trust, fairness, past commitments, and organizational culture.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The case contains policy repair, incentive redesign, and trust repair within the same frame. The technical path is not enough because the previous policy has already reshaped behavior and expectations.
+
+### 9. Governance Load
+
+High. The organization must manage academic integrity, incentive transition, retroactive fairness, staff trust, and the long-term difference between real capability and formal output.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Frame this as incentive and trust repair, not only as policy cancellation. Separate future integrity rules from transitional handling of people affected by prior incentives.
+
+### 12. Owner Review Questions
+
+- Should this be classified as `issue` rather than `mixed`, given that the path to correction exists but legitimacy remains contested?
+- Should the draft explicitly include "policy memory" as a proxy stakeholder?
+- Is this case useful as a false-negative trap where a selector might under-call QPI because the surface request sounds like policy cleanup?
+
+## Case qpi-draft-004: Strategic Alignment Is Replaced By Easier Program Packaging
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is choosing which program, project, or specialization to prioritize for strategic development and external recognition.
+
+### 2. Subject Position
+
+The subject is the organization under `decision_maker` strategy pressure, with `academic_affairs_function` responsible for translating that strategy into program-level execution. The function also has its own local incentives to choose easier paths.
+
+### 3. Scenario Context
+
+The case appears in a strategic alignment discussion. The decision layer expects program choices to connect to a broader organizational industry or mission advantage, while the execution layer gravitates toward options that are easier to package, report, or complete.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Program selection should align with the organization's strategic advantage and long-term positioning.
+- Reality: Execution may select a more convenient or fashionable option that improves short-term reportability while weakening strategic coherence.
+- Gap summary: A strategic choice is reduced to a packaging convenience problem.
+
+### 5. Attempted Paths
+
+The attempted path is to choose a more workable or marketable label for application and reporting. This lowers immediate execution difficulty but may disconnect the project from the organization's real strategic base.
+
+### 6. Dynamic Shift
+
+P -> I. It begins as a Problem about selecting and executing a project path. It becomes an Issue because the selected path reveals conflict between strategic intent, departmental incentives, and evaluation convenience.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+From the execution function's viewpoint, this may look like a practical Problem: choose the feasible path. From the decision layer's viewpoint, it is an Issue about strategic discipline and local incentive drift.
+
+### 9. Governance Load
+
+High. The case requires aligning strategy, incentives, execution capacity, external review criteria, and the threshold for rejecting convenient but strategically hollow options.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Ask whose frame is being used. If the owner frame is strategic governance, treat as Issue; if the local execution frame is selected, first verify whether the easier path still satisfies strategic alignment.
+
+### 12. Owner Review Questions
+
+- Should this case be labeled `inter_viewpoint_divergence` because the same choice differs by role, or `intra_frame_mixed` because one organization contains both frames?
+- Should the owner-expected judgment emphasize "strategic evasion" or "resource-feasible compromise"?
+- Is this a good calibration case for distinguishing local feasibility from organizational strategy?
+
+## Case qpi-draft-005: Resource Reuse Proposal Collides With Operational Reality
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is how to reuse surplus teaching capacity across internal units to reduce cost and improve utilization.
+
+### 2. Subject Position
+
+The subject differs by viewpoint. `decision_maker` sees unused capacity and seeks cross-unit reuse. `execution_lead` and receiving units see timetable mismatch, capability mismatch, and operational disruption.
+
+### 3. Scenario Context
+
+The case appears after the organization has created surplus or underused staffing capacity. Cross-unit teaching reuse is proposed as a way to convert idle resources into value.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Surplus staff can be redeployed across units to solve underutilization.
+- Reality: Role fit, schedule structure, learner profile, and unit boundary constraints may make the proposed reuse impractical or damaging.
+- Gap summary: A cost-saving idea that looks simple from above becomes a cross-boundary operating problem below.
+
+### 5. Attempted Paths
+
+The attempted path is cross-unit reassignment or shared staffing. The resistance path is to reject the reassignment because the work is not equivalent across units and the schedules do not naturally align.
+
+### 6. Dynamic Shift
+
+P -> I. It starts as a Problem about resource allocation. It becomes an Issue because the reuse path triggers role boundary, unit autonomy, quality, and fairness disputes.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+From the decision layer, the case may look like a path/resource Problem. From the receiving or executing units, it becomes an Issue about role fit and imposed coordination burden.
+
+### 9. Governance Load
+
+High. Sustainable reuse requires role compatibility, scheduling authority, quality standards, workload agreements, and credible feedback from affected units.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: mixed
+- classification_confidence: medium
+- recommended_next_step: Build a role-fit and schedule-fit test before treating surplus capacity as redeployable. If fit fails, do not classify the resistance as mere execution unwillingness.
+
+### 12. Owner Review Questions
+
+- Should the classification be `mixed` or `issue`?
+- Should this be paired with the staffing ratio deadlock case, or does it represent a distinct resource reuse pattern?
+- What minimum evidence would make redeployment a legitimate Problem rather than an Issue?
+
+## Case qpi-draft-006: Student Outcome Decline Is Reframed As Input Quality Excuse
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that student outcome indicators and learner complaints have worsened, creating pressure on the academic affairs system.
+
+### 2. Subject Position
+
+The subject is `academic_affairs_function` under accountability pressure. `affected_learners` appear as downstream recipients of quality gaps, while `decision_maker` evaluates whether the function still has operational credibility.
+
+### 3. Scenario Context
+
+The case appears in a review of student progression, academic quality, complaints, and teaching operation. The function appears to explain poor outcomes partly through input conditions and learner quality.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The academic affairs system should improve learning outcomes, identify quality problems, and manage learner complaints before they become systemic distrust.
+- Reality: Outcome decline is explained through external or upstream factors, while internal management levers remain under-specified.
+- Gap summary: A quality assurance failure is at risk of being reframed as an unavoidable input problem.
+
+### 5. Attempted Paths
+
+The apparent path is explanatory defense: cite difficult input conditions, highlight isolated achievements, or use micro-successes to offset macro outcome decline. This may protect the function rhetorically but does not repair the quality system.
+
+### 6. Dynamic Shift
+
+Q/P -> I. It begins with Questions about what the data really shows and Problems about process repair. It becomes an Issue when responsibility attribution, trust, and accountability are contested.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+For the same accountability frame, the case contains uncertain causal data, missing improvement path, and order scarcity around responsibility attribution.
+
+### 9. Governance Load
+
+High. The organization must manage outcome evidence, learner voice, quality assurance, accountability boundaries, and whether local bright spots can legitimately offset systemic decline.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Separate input-condition analysis from management-lever analysis, then require a quality assurance map that links complaints, outcomes, process controls, and owner accountability.
+
+### 12. Owner Review Questions
+
+- Should this case be classified as `mixed` because data, path, and responsibility are all contested?
+- Should isolated achievements be treated as evidence of latent capability or as masking signals?
+- What owner-approved wording should be used to avoid over-claiming causal responsibility?
+
+## Case qpi-draft-007: Digital Platform And Local AI Choice Becomes Governance Boundary Problem
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is choosing a digital collaboration platform or AI deployment mode for the organization.
+
+### 2. Subject Position
+
+The subject is split between `decision_maker`, who prioritizes control and data safety, and `technical_staff`, who worries about iteration speed, obsolescence, and practical maintenance. `academic_affairs_function` appears as one affected business function.
+
+### 3. Scenario Context
+
+The case appears in a discussion of digital transformation, platform standardization, and AI deployment. Multiple tools or deployment modes are considered without a stable decision basis.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The organization should choose a digital base that supports coordination, security, and long-term use.
+- Reality: Platform choice is debated through partial priorities, with no shared weighting of data security, iteration speed, integration, maintainability, and user adoption.
+- Gap summary: A tool selection question hides an unresolved governance boundary.
+
+### 5. Attempted Paths
+
+The apparent paths include comparing platforms, testing tools, and choosing between local control and cloud-based iteration. These paths remain unstable because the evaluation criteria are not settled.
+
+### 6. Dynamic Shift
+
+Q/P -> I. It may begin as a Question about which tool is better or a Problem about how to deploy. It becomes an Issue because the real conflict is between governance priorities.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+The same platform decision can be framed as a technical Problem by implementers, a risk-control Issue by decision makers, and a user-adoption Problem by operating functions.
+
+### 9. Governance Load
+
+High. The organization must maintain platform standards, data boundaries, lifecycle decisions, adoption incentives, and responsibility for future migration or failure.
+
+### 10. Misframing Risks
+
+- tool_solutionism
+- malicious_inflation
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Define decision criteria and authority before selecting tools. Treat the deployment choice as governance-bound technical strategy, not a simple platform preference.
+
+### 12. Owner Review Questions
+
+- Should this case remain in QPI calibration, or does it overlap too much with generic technology strategy examples?
+- Should the dominant scarcity be `consensus_order` because criteria are contested, or `path_resource` because implementation cost is material?
+- Is the local-vs-cloud distinction too specific and should it be further generalized?
+
+## Case qpi-draft-008: Public Safety Compliance Gap Reveals Bottom-Line Control Failure
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that a large activity or event was not managed through proper safety and compliance procedures.
+
+### 2. Subject Position
+
+The subject is the organization and `academic_affairs_function` as part of the operating system responsible for basic procedural control. `affected_learners`, frontline organizers, and external regulators are proxy stakeholders.
+
+### 3. Scenario Context
+
+The case appears inside a broader teaching and compliance review. It is not only an event-management problem; it is evidence that basic operating controls may be weak during high-pressure or high-volume situations.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Activities involving large groups should have clear approval, reporting, safety planning, and accountability.
+- Reality: The event proceeded without adequate procedural control and created external enforcement or safety exposure.
+- Gap summary: A single event failure points to a deeper bottom-line control gap.
+
+### 5. Attempted Paths
+
+The source suggests reactive handling after the event rather than a reliable preventive process. The organization may treat it as an isolated incident, but the governance signal is broader.
+
+### 6. Dynamic Shift
+
+P -> I. It starts as a Problem about missing event process. It becomes an Issue because it reveals control culture, risk ownership, and whether compliance procedures are treated as optional.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same operational frame contains a missing process path and a governance failure. A checklist may fix the local process, but not the underlying tolerance for unmanaged risk.
+
+### 9. Governance Load
+
+High. The case requires defining approval authority, event risk classification, accountability, external reporting boundaries, learner safety, and hard stop rules.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat the event as a bottom-line control signal, not only a process mistake. Build a hard-gate event approval workflow and assign risk ownership before allowing similar activities.
+
+### 12. Owner Review Questions
+
+- Should this case be classified as `mixed` or direct `issue`?
+- Should it be included in QPI calibration even though it is less cognitively subtle and more operationally concrete?
+- What level of detail should remain after anonymization so the safety risk is still meaningful?

reports/model_case_preprocessing/qpi/round-01/year-end-review-development-office.cases.md

@@ -0,0 +1,564 @@
+# QPI Case Drafts: Year-End Review Planning Function
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+source_note: Owner-provided raw organizational material. These drafts are anonymized and generalized for QPI review. Real or potentially identifying people, departments, institutions, timestamps, locations, titles, and exact numeric details have been removed or generalized. Ancient-style cognitive anchors from the source are intentionally omitted. These drafts are not selector JSON, regression cases, or owner-approved calibration data.
+
+anonymization_note: People are represented as roles such as `decision_maker`, `execution_lead`, `strategy_staff`, `functional_department`, and `frontline_staff`. The organization is represented as `the organization`; the department is represented as `planning function`. Sensitive details are generalized as `facility metric gap`, `staffing credential metric gap`, `compliance workaround risk`, `incentive backlash`, and `operational continuity risk`.
+
+## Case qpi-draft-001: Compliance Goal Becomes Compliance Workaround Risk
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization faces a facility metric gap against an external compliance target and needs a way to make the submitted indicators appear adequate.
+
+### 2. Subject Position
+
+The subject is the organization as framed by `decision_maker` and translated by `execution_lead`. The subject is not a neutral analyst asking what the rule says; it is an accountable organization under external review pressure, with limited willingness to invest in physical resources and strong pressure to pass the gate.
+
+### 3. Scenario Context
+
+The case appears in a year-end review and planning discussion for a `planning function`. The function is responsible for turning external compliance requirements into internal plans and evidence packages. The broader context is a survival-level compliance milestone where the organization wants to preserve status while minimizing new resource commitments.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The organization expects to satisfy external facility-related requirements through planning, packaging, and administrative coordination.
+- Reality: The underlying physical resource base has a material gap that cannot be solved by renaming, relabeling, or paperwork alone.
+- Gap summary: A hard resource shortage is being reframed as a documentation problem, creating `compliance workaround risk`.
+
+### 5. Attempted Paths
+
+The apparent path is to reinterpret or reclassify existing facilities so that reported indicators look closer to the required threshold. This path avoids physical investment but increases audit and credibility risk.
+
+### 6. Dynamic Shift
+
+P -> I. It begins as a Problem about how to meet a facility metric under constraints. It shifts into an Issue because the proposed solution changes the organization's relationship to compliance, truthfulness, risk exposure, and long-term auditability.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+For the same organization in the same compliance scenario, there is both path/resource scarcity and order scarcity. The hard resource gap creates a path problem, while the workaround creates a governance and legitimacy problem.
+
+### 9. Governance Load
+
+High. The case requires managing audit authenticity, regulatory exposure, internal pressure, physical resource limits, and whether short-term indicator repair will damage long-term institutional legitimacy.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat the facility metric gap as a P/I mixed case, separate legitimate remediation paths from compliance workaround risk, and ask the owner whether the intended QPI label should emphasize resource scarcity or governance failure.
+
+### 12. Owner Review Questions
+
+- Should the dominant scarcity be `consensus_order` because of compliance workaround risk, or `path_resource` because the physical gap is the triggering constraint?
+- Should this case become a selector calibration input for "hard resource gap disguised as documentation problem"?
+- Is the draft sufficiently anonymized, or should the source relation to an external compliance milestone be further generalized?
+
+## Case qpi-draft-002: Credential Metric Repair Creates Operational Continuity Risk
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization needs to improve a staffing credential metric for external compliance.
+
+### 2. Subject Position
+
+The subject is the organization under `decision_maker` pressure, with `execution_lead` responsible for converting the target into staffing action. `frontline_staff` and `functional_department` appear as affected system parts rather than decision owners.
+
+### 3. Scenario Context
+
+The scenario is a planning and staffing adjustment discussion in which non-core service and administrative roles are evaluated primarily by whether they help the organization satisfy a credential metric. The planning function is pulled from strategic diagnosis into indicator assembly.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Replacing or reclassifying staff can improve a credential indicator and make the organization appear stronger.
+- Reality: Credential fit does not equal functional fit. Replacing experienced operational staff with credential-matched but role-mismatched staff may weaken daily operations and increase churn.
+- Gap summary: A staffing quality issue is violently reduced to a single credential indicator.
+
+### 5. Attempted Paths
+
+The source describes an aggressive replacement or reclassification logic: roles that require continuity, practical experience, or trust are forced into a credential-centered standard. The method may improve the table but damage the operating system.
+
+### 6. Dynamic Shift
+
+P -> I. It starts as a Problem about how to close a staffing credential metric gap. It becomes an Issue because the chosen method creates role mismatch, morale damage, labor conflict risk, and operational continuity risk.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same subject has simultaneous resource/path scarcity and governance scarcity: it lacks enough metric-qualified staff, but the repair path undermines role boundaries and operational stability.
+
+### 9. Governance Load
+
+High. This case requires balancing compliance metrics, role-function fit, morale, operational memory, turnover, and the legitimacy of using people as indicator carriers.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Frame the case as a staffing-governance Issue with a path/resource trigger, and ask whether the QPI output should explicitly mark `violent_reduction` when role-function fit is collapsed into credential count.
+
+### 12. Owner Review Questions
+
+- Should this be treated as the clearest example of `violent_reduction` in this source?
+- Should the QPI case emphasize role mismatch, morale damage, compliance optics, or operational continuity?
+- Is `classification: issue` more appropriate than `classification: mixed` once the staffing path is chosen?
+
+## Case qpi-draft-003: Incentive Backlash Misread As Lack of Effort
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that performance or output indicators are declining and `decision_maker` interprets the decline as insufficient effort or insufficient pressure.
+
+### 2. Subject Position
+
+The subject is the organization as seen by two different internal positions. `decision_maker` frames the problem as willpower and output discipline. `execution_lead` and `frontline_staff` experience it as an incentive mismatch where the required behavior imposes unrecovered costs or losses.
+
+### 3. Scenario Context
+
+The case appears in a performance discussion where the organization wants higher externally visible output while maintaining tight cost control. The planning function surfaces the contradiction between aspiration and incentive design.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Staff should increase output when the organization demands it or when ranking/status pressure rises.
+- Reality: Existing policy creates `incentive backlash`; rational staff reduce effort when the required behavior is economically or professionally unrewarding.
+- Gap summary: A systemic incentive design problem is misread as individual laziness or insufficient mobilization.
+
+### 5. Attempted Paths
+
+The apparent path is to restart pressure, exhortation, or low-cost incentive signals without fixing the underlying cost-reward mismatch. This may briefly increase compliance speech but is unlikely to restore real output.
+
+### 6. Dynamic Shift
+
+I misread as P. The decision frame treats the issue as a manageable execution problem: "make people work harder." The source frames it as an Issue: incentives, trust, cost allocation, and long-term response have already changed.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+Different roles classify the same decline differently. `decision_maker` sees a Problem of mobilization; `frontline_staff` experience an Issue of unfair incentive structure; `planning function` sees a system loop.
+
+### 9. Governance Load
+
+High. The case requires redesigning incentive credibility, cost coverage, trust, and future behavior rather than issuing a one-time execution command.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Separate output symptom from incentive mechanism, then ask which role's frame is being routed: mobilization problem, incentive redesign issue, or evidence question about actual causes.
+
+### 12. Owner Review Questions
+
+- Should this be classified as `inter_viewpoint_divergence` because roles see different problems, or `intra_frame_mixed` because the organization has simultaneous incentive and path gaps?
+- Is the main misframing `violent_reduction` from incentive structure to personal effort?
+- Should this be a strong selector calibration example for "performance decline with incentive backlash"?
+
+## Case qpi-draft-004: Strategic Planning Function Reduced To Indicator Packaging
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the `planning function` is criticized for not providing enough innovation, strategy, or concrete implementation value.
+
+### 2. Subject Position
+
+The subject can be framed from multiple positions. `decision_maker` sees a weak function that should deliver usable progress. `strategy_staff` sees a strategic function that requires resources, trust, and coordination authority. `execution_lead` sees a function that must translate strategy into compliance packages under cost pressure.
+
+### 3. Scenario Context
+
+The scenario is a year-end review where the planning function is expected to speak the language of strategy but is evaluated mainly by its usefulness in meeting immediate compliance and indicator goals.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The planning function should generate strategic growth, external collaboration, and innovation.
+- Reality: It lacks the authority, resources, and trust needed to implement those ambitions, and is instead pulled into packaging and target repair.
+- Gap summary: A strategic function is assigned strategic responsibility but denied strategic operating conditions.
+
+### 5. Attempted Paths
+
+`strategy_staff` attempts to propose external resource routes or larger strategic narratives. `decision_maker` rejects resource-intensive paths and reasserts the minimum-cost requirement. The function then risks becoming either ceremonial or defensive.
+
+### 6. Dynamic Shift
+
+P/I -> I. The surface problem might be a Problem of poor planning quality. With context, it becomes an Issue about role authority, trust, resource constraints, and whether the organization actually wants strategy or only compliant indicators.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+The same "planning function underperformance" surface problem is classified differently by role: competence problem for `decision_maker`, resource/path problem for `strategy_staff`, and governance issue for a system analyst.
+
+### 9. Governance Load
+
+High. The organization must decide whether the planning function has real strategic authority or only responsibility for compliance packaging. Without that decision, every proposed path will be judged by incompatible standards.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Ask the owner to confirm whether this should become a QPI sample for role-authority mismatch: the function is blamed for strategy while governed as a packaging unit.
+
+### 12. Owner Review Questions
+
+- Should this be classified as `issue` rather than `mixed` because the role contradiction dominates?
+- Does the case need a separate viewpoint table for `decision_maker`, `strategy_staff`, and `execution_lead`?
+- Should the anonymized role `planning function` be made even broader for future publication safety?
+
+## Case qpi-draft-005: Low-Cost Ambition Creates Physical-Law Contradictions
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is how to achieve ambitious organizational outcomes under tight budget and resource constraints.
+
+### 2. Subject Position
+
+The subject is `decision_maker` as the owner of targets and cost limits, with `planning function` and `execution_lead` expected to make the contradiction operationally feasible.
+
+### 3. Scenario Context
+
+The case occurs across several planning themes: external cooperation, facility readiness, staffing credentials, and performance indicators. The repeated pattern is "raise the standard while minimizing the investment."
+
+### 4. Expectation-Reality Gap
+
+- Expected: The organization can obtain high-level outcomes through administrative pressure, packaging, and internal compression.
+- Reality: Several desired outcomes require real exchanges, physical capacity, credible incentives, or role-compatible talent. These cannot be created by command alone.
+- Gap summary: The organization treats resource-dependent outcomes as if they were compliance wording or discipline problems.
+
+### 5. Attempted Paths
+
+The repeated attempted path is cost suppression plus command pressure: demand external cooperation without meaningful exchange, demand output without adequate incentive, demand capacity without physical expansion, and demand talent quality without role-market fit.
+
+### 6. Dynamic Shift
+
+P -> I. Each item can look like a separate Problem, but the repeated pattern reveals a deeper Issue: the decision logic itself generates contradictions that downstream actors must absorb.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+Within the same organizational frame, path/resource scarcity and order scarcity reinforce each other. The path gap is not accidental; it is produced by the governing cost doctrine.
+
+### 9. Governance Load
+
+High. This requires confronting target-resource consistency, investment boundaries, credibility of command, and whether downstream functions are being asked to absorb impossible contradictions.
+
+### 10. Misframing Risks
+
+- malicious_inflation
+- violent_reduction
+- tool_solutionism
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat the pattern as an Issue about target-resource governance, not as a list of independent execution blockers.
+
+### 12. Owner Review Questions
+
+- Is this case too broad, or is it useful as a meta-case for the whole organizational slice?
+- Should QPI allow a "pattern-level Issue" extracted from multiple surface Problems in one source?
+- Should this case be merged with the compliance workaround and staffing credential cases, or kept as a higher-level calibration sample?
+
+## Case qpi-draft-006: Data Completeness Masks Truthfulness Gap
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization needs complete and favorable records for external review, including facility, staffing, performance, and planning materials.
+
+### 2. Subject Position
+
+The subject is the `planning function` as a data assembler and risk translator. It sits between `decision_maker` pressure, `execution_lead` tactics, and external review expectations.
+
+### 3. Scenario Context
+
+The source contains multiple instances where indicators can be made to look complete while the underlying reality remains unstable or misleading. The planning function becomes the place where mismatch between reports and operations is either surfaced or hidden.
+
+### 4. Expectation-Reality Gap
+
+- Expected: If the data package is complete and internally consistent, the organization can pass the review.
+- Reality: The data package may be internally complete while externally fragile because the underlying facts are physically, operationally, or behaviorally weak.
+- Gap summary: Data completeness is mistaken for truthfulness and audit resilience.
+
+### 5. Attempted Paths
+
+The organization appears to build a coherent evidence package around renamed resources, reclassified staff, and performance narratives. This can reduce short-term data gaps but increase risk when auditors inspect the underlying reality.
+
+### 6. Dynamic Shift
+
+Q/P -> I. It begins as a data or documentation question: "What information is missing?" It becomes an Issue once the problem is whether the evidence corresponds to real, stable operations.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same planning frame contains a data scarcity problem and a governance problem. The missing data is not just unknown information; it reflects contested or unstable reality.
+
+### 9. Governance Load
+
+High. The organization needs audit authenticity, evidence discipline, internal truth reporting, and escalation rules when data packaging diverges from operational reality.
+
+### 10. Misframing Risks
+
+- tool_solutionism
+- violent_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Mark this as an Issue where evidence traceability and audit authenticity dominate; request owner confirmation before converting it into selector calibration.
+
+### 12. Owner Review Questions
+
+- Should this case be used to test QPI's ability to distinguish "missing data" from "untrusted data"?
+- Should the recommended next step be evidence audit rather than resource planning?
+- Is `data_scarcity: medium` correct, or should it be `low` because the facts are known but politically inconvenient?
+
+## Case qpi-draft-007: Execution Lead As Translator Of Impossible Commands
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is how middle execution converts high-pressure directives into operational action when the directives conflict with resource limits or compliance reality.
+
+### 2. Subject Position
+
+The subject is `execution_lead` as a translator between `decision_maker` demands and implementation reality. This role may possess the best data but limited authority to challenge the premise.
+
+### 3. Scenario Context
+
+In the organizational slice, `execution_lead` repeatedly appears as the person who knows operational constraints, signals some risk, and then turns the chosen direction into executable workaround or enforcement.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Middle execution should make leadership directives feasible and keep the organization moving.
+- Reality: When directives are internally contradictory, execution becomes a conversion layer that may normalize workaround risk, suppress professional resistance, and transfer damage downward.
+- Gap summary: Operational competence becomes complicit adaptation when the governance premise is broken.
+
+### 5. Attempted Paths
+
+The attempted path is pragmatic translation: identify gaps, propose packaging or enforcement moves, and execute once the top-level decision is fixed. This keeps the system moving but may deepen the underlying Issue.
+
+### 6. Dynamic Shift
+
+P -> I. It begins as a Problem of execution under constraints. It becomes an Issue about role ethics, authority boundaries, risk ownership, and the organization's inability to feed bad news upward.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+From `decision_maker`, the execution lead may look effective. From `frontline_staff`, the role may look coercive. From QPI, the same behavior reveals governance scarcity: the system lacks a legitimate channel for refusing impossible commands.
+
+### 9. Governance Load
+
+High. The case requires boundary rules for escalation, refusal, risk documentation, and whether implementation roles should be evaluated by compliance with command or by protection of system viability.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Use this case to test whether QPI can identify governance scarcity when a competent executor is converting impossible directives into risky action.
+
+### 12. Owner Review Questions
+
+- Should this role-level case be kept, or is it too interpretive without more owner confirmation?
+- Is the main risk "complicity in workaround" or "lack of escalation channel"?
+- Should this become a calibration sample for `inter_viewpoint_divergence`?
+
+## Case qpi-draft-008: External Review Pressure Turns Mission Into Indicator Survival
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is how the organization can pass a high-stakes external review while also maintaining its stated mission and internal operating health.
+
+### 2. Subject Position
+
+The subject is the whole organization under existential review pressure. `decision_maker`, `planning function`, `execution_lead`, and `frontline_staff` all participate in different roles, but the frame is organization-level survival.
+
+### 3. Scenario Context
+
+The slice shows the organization treating the external review milestone as an overriding mission. This pressure reorganizes priorities: indicator appearance, cost control, staffing numbers, and reporting coherence dominate over educational or operational substance.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Passing the external milestone should validate organizational development.
+- Reality: The effort to pass the milestone may be destroying the real capabilities the milestone is supposed to measure.
+- Gap summary: The metric becomes detached from the mission and begins to cannibalize the system it was meant to improve.
+
+### 5. Attempted Paths
+
+The organization attempts to optimize indicator packages, staffing optics, facility records, and performance narratives under severe cost constraints. These moves may produce short-term apparent progress while increasing long-term fragility.
+
+### 6. Dynamic Shift
+
+Multiple P cases -> system-level I. Individual gaps in facilities, staffing, incentives, and planning appear solvable one by one. Together they form an Issue: a negative reinforcing loop where short-term indicator repair worsens long-term capability.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same organization has simultaneous path scarcity and governance scarcity. The resource gaps are real, but the deeper issue is that the governing objective is forcing destructive short-term substitutions.
+
+### 9. Governance Load
+
+Very high. The case requires deciding how to balance survival pressure, truthful reporting, mission integrity, investment constraints, staff stability, and long-term capability.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat this as the umbrella organization-level Issue and use the narrower cases as subcases. Owner should confirm whether this should be a calibration input or only a source-level summary case.
+
+### 12. Owner Review Questions
+
+- Should this umbrella case be retained, or should only the narrower pathology cases be promoted later?
+- Is "indicator survival cannibalizes mission capability" the correct anonymized abstraction?
+- Should this case be linked to future CT diagnosis model work rather than only QPI?

reports/model_case_preprocessing/qpi/round-01/year-end-review-employment-entrepreneurship.cases.md

@@ -0,0 +1,566 @@
+# QPI Case Drafts: Year-End Review Employment Function
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+source_note: Owner-provided raw organizational material. These drafts are anonymized and generalized for QPI review. Real or potentially identifying people, departments, institutions, timestamps, places, titles, exact numbers, and sensitive operational details have been removed or generalized. Ancient-style cognitive anchors from the source are intentionally omitted. These drafts are not selector JSON, regression cases, or owner-approved calibration data.
+
+anonymization_note: People are represented as roles such as `decision_maker`, `execution_lead`, `employment_function`, `teaching_function`, `finance_function`, and `frontline_staff`. The organization is represented as `the organization`. Sensitive details are generalized as `outcome metric pressure`, `student pipeline`, `employer coordination risk`, `credential metric workaround`, `internal accounting mismatch`, `reverse accountability power`, and `compliance exposure`.
+
+## Case qpi-draft-001: Outcome Metric Pressure Becomes Reverse Accountability Power
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that student outcome metrics are under strategic pressure, so the organization wants the `employment_function` to force the `teaching_function` to align programs, courses, and student management with employability results.
+
+### 2. Subject Position
+
+The subject is the organization as framed by `decision_maker`. The `employment_function` is being promoted from a service role into a control role. The `teaching_function` and `frontline_staff` become affected parties whose professional authority may be overridden by outcome pressure.
+
+### 3. Scenario Context
+
+The case appears in an organizational year-end review under survival-level market pressure. The organization treats employment outcomes as proof that the education product is still viable. The `employment_function` is given stronger leverage over student pipeline design and internal accountability.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Giving the `employment_function` stronger authority will force teaching, student management, and employer coordination to converge around real outcomes.
+- Reality: A service function gaining veto-like power over teaching may trigger organizational rejection, metric gaming, and professional resistance.
+- Gap summary: A coordination problem is escalated into a governance redesign without a stable accountability protocol.
+
+### 5. Attempted Paths
+
+The apparent path is to let outcome pressure override existing departmental boundaries. Instead of negotiating a shared teaching-employment mechanism, the organization tries to install `reverse accountability power` from the employment side toward the teaching side.
+
+### 6. Dynamic Shift
+
+P -> I. It begins as a Problem about improving student outcomes and employer alignment. It becomes an Issue because the proposed path changes authority boundaries, professional legitimacy, incentive structures, and the meaning of educational quality.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+For the same organization in the same year-end review, there is both a path problem and an order problem. The organization lacks a reliable implementation path, and the proposed authority inversion changes the internal order.
+
+### 9. Governance Load
+
+High. The case requires ongoing tradeoff among student outcomes, teaching authority, employer promises, accountability design, professional boundaries, and resistance management.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat this as a P/I mixed case. Separate the operational question of how to improve outcomes from the governance question of who may legitimately evaluate and direct teaching work.
+
+### 12. Owner Review Questions
+
+- Should this case be treated primarily as `issue`, or as `mixed` because there remains a concrete process design problem?
+- Does `reverse accountability power` capture the source pathology without exposing sensitive organizational details?
+- Should this become a selector calibration trap for cases where a hard metric hides authority redesign?
+
+## Case qpi-draft-002: Credential Metric Repair Becomes Compliance Exposure
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization needs to improve a credential-related metric for external evaluation or institutional positioning.
+
+### 2. Subject Position
+
+The subject is the organization under `decision_maker` pressure. The `employment_function` and adjacent functions are treated as tools for closing a metric gap rather than as owners of educational substance.
+
+### 3. Scenario Context
+
+The case appears in a review where staffing credentials, external labels, and compliance indicators are discussed as survival assets. The organization considers shortcuts that may satisfy a formal count while bypassing the substantive purpose behind the metric.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Acquiring or associating with credentialed personnel can quickly repair a visible compliance gap.
+- Reality: If credentialed personnel are not substantively integrated into teaching, research, or student development, the metric becomes a fragile shell and may produce serious audit risk.
+- Gap summary: A hard compliance metric is being solved through an externalized workaround rather than real capability building.
+
+### 5. Attempted Paths
+
+The apparent path is to source credentialed people or labels cheaply and quickly, treating them as indicator products. This may improve a table in the short term but does not create real capacity.
+
+### 6. Dynamic Shift
+
+Q/P -> I. It can begin as a Question about what the credential requirement is, then a Problem about how to close the gap. It becomes an Issue when the chosen path normalizes `credential metric workaround` and creates institutional legitimacy risk.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same subject faces a real resource/path scarcity and a governance scarcity. The metric gap is concrete, but the shortcut path changes the organization's compliance posture.
+
+### 9. Governance Load
+
+High. The case requires managing external audit exposure, internal incentive distortion, authentic capability building, and the boundary between legitimate remediation and indicator fabrication.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- tool_solutionism
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Identify which credential gaps are substantive capability gaps and which proposed repairs are compliance exposure. Do not classify the case as a simple procurement or staffing problem.
+
+### 12. Owner Review Questions
+
+- Should this case be marked as a high-risk `issue` rather than `mixed`?
+- Are the generalized terms `credential metric workaround` and `compliance exposure` sufficiently anonymized?
+- Should future calibration require QPI to ask for evidence of substantive integration before accepting metric repair as a valid path?
+
+## Case qpi-draft-003: Internal Accounting Mismatch Inflates Functional Performance
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the `employment_function` reports strong non-core revenue or contribution results, but the underlying calculation standard may not match the organization's financial recognition standard.
+
+### 2. Subject Position
+
+The subject is the organization and its `finance_function`, with the `employment_function` trying to demonstrate value under survival pressure. The reviewer must distinguish reported functional achievement from actual cash or recognized organizational value.
+
+### 3. Scenario Context
+
+The case appears in a year-end performance narrative where functional units are encouraged to prove they are not only cost centers. Reported contribution is used to justify strategic importance and expanded authority.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The reported revenue-like figure proves the function has independent value and can become a strategic growth node.
+- Reality: The reported number may be based on internal conversion logic, incomplete collection, or non-standard recognition, so it may overstate the actual financial contribution.
+- Gap summary: Functional performance is inflated by an `internal accounting mismatch`.
+
+### 5. Attempted Paths
+
+The apparent path is to use a department-level calculation standard to claim organizational contribution. This can make the function look more productive while leaving `finance_function` recognition unresolved.
+
+### 6. Dynamic Shift
+
+Q -> P/I. It may start as a Question about which number is correct. It becomes a Problem if the organization needs a unified accounting standard. It becomes an Issue when inflated performance numbers are used to justify power expansion or strategic decisions.
+
+### 7. Scarcity Profile
+
+- data_scarcity: high
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same subject lacks reliable recognized data and also lacks a shared order for what counts as contribution. The data gap and governance gap reinforce each other.
+
+### 9. Governance Load
+
+High. The case requires financial standard alignment, credibility management, performance evaluation fairness, and prevention of strategic decisions based on inflated internal claims.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: data
+- classification_confidence: medium
+- recommended_next_step: First reconcile recognized financial data, then separately evaluate whether the function's claimed strategic importance is justified.
+
+### 12. Owner Review Questions
+
+- Should `dominant_scarcity` be `data` because the accounting basis is unclear, or `consensus_order` because the deeper risk is performance legitimacy?
+- Should this case be used to test QPI's ability to avoid accepting reported metrics at face value?
+- Does the anonymized phrasing remove enough source specificity?
+
+## Case qpi-draft-004: Outcome Promise Creates Student Pipeline Distortion
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization wants stronger student recruitment and retention by promising clearer employment outcomes.
+
+### 2. Subject Position
+
+The subject is the organization under market pressure. `decision_maker` frames student outcomes as a survival proof, while `employment_function`, `student_pipeline`, and `teaching_function` become instruments for making the promise credible.
+
+### 3. Scenario Context
+
+The case appears where education value, employment outcomes, pricing pressure, and recruitment narrative are tightly coupled. The organization may use outcome promises to compensate for weak perceived educational value.
+
+### 4. Expectation-Reality Gap
+
+- Expected: A stronger employment promise will make the education product easier to sell and will force internal functions to become more market-oriented.
+- Reality: If the organization lacks real capability to deliver the promise, the student pipeline may become distorted by overpromising, data pressure, and downstream trust loss.
+- Gap summary: A market-facing promise is used before the delivery system is stable.
+
+### 5. Attempted Paths
+
+The apparent path is to put employment outcomes into the center of recruitment and program design. This can be valid if backed by real capability, but dangerous if used as a substitute for capability.
+
+### 6. Dynamic Shift
+
+P -> I. It starts as a Problem about how to improve recruitment value and student outcomes. It becomes an Issue when the promise affects institutional identity, teaching incentives, student trust, and long-term brand legitimacy.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+Within the same organizational frame, there is a delivery path scarcity and a governance scarcity. The promise cannot be evaluated only as a marketing tactic.
+
+### 9. Governance Load
+
+High. The case requires balancing recruitment pressure, student expectations, employer coordination risk, teaching capability, outcome proof, and long-term trust.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- tool_solutionism
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Require evidence that the promised outcome can be delivered before treating the issue as a recruitment or messaging problem.
+
+### 12. Owner Review Questions
+
+- Should this be a separate case, or merged with the reverse accountability case?
+- Does the source imply a stronger `issue` judgment because the student promise changes institutional identity?
+- What context would be needed to distinguish legitimate outcome orientation from overpromising?
+
+## Case qpi-draft-005: High Outcome Data Masks Data Quality Risk
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization has strong student outcome data and wants to use it as proof of institutional health.
+
+### 2. Subject Position
+
+The subject is the organization as evaluated by `decision_maker` and external stakeholders. `employment_function` is the data-producing function, while students, employers, and teaching units become the systems from which the data is extracted.
+
+### 3. Scenario Context
+
+The case appears in a review where outcome metrics are used as regulatory, recruitment, and internal performance evidence. The same metric may carry multiple political meanings.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Strong outcome data demonstrates real education-market fit and functional performance.
+- Reality: If the data is produced under administrative pressure, it may contain hidden coercion, weak verification, or short-term compliance behavior.
+- Gap summary: A green dashboard may hide `data quality risk` and behavioral distortion.
+
+### 5. Attempted Paths
+
+The apparent path is to celebrate the outcome metric and expand the mechanisms that produced it. The source warns that high-pressure mechanisms can make the data less trustworthy over time.
+
+### 6. Dynamic Shift
+
+Q/P -> I. It begins as a Question about whether the data is accurate and a Problem about how to maintain outcomes. It becomes an Issue when incentives push actors toward data production rather than substantive student value.
+
+### 7. Scarcity Profile
+
+- data_scarcity: high
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same organization has both a data verification problem and an incentive-order problem. The metric cannot be trusted without understanding how it is produced.
+
+### 9. Governance Load
+
+High. The case requires audit design, anti-gaming controls, student trust protection, employer verification, and separation of real outcomes from administrative compliance.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: data
+- classification_confidence: medium
+- recommended_next_step: Verify the production mechanism behind the outcome data before using it as evidence of institutional health or as a basis for stronger internal pressure.
+
+### 12. Owner Review Questions
+
+- Should this case require QPI to output an explicit `evidence_gap` around data production?
+- Is this primarily a data scarcity case or an incentive governance case?
+- Should future calibration distinguish high metric value from high metric credibility?
+
+## Case qpi-draft-006: Employer Coordination Asset Remains Isolated From Teaching
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization has an employer-linked asset or project, but it is not clearly integrated into the student learning and program design pipeline.
+
+### 2. Subject Position
+
+The subject is the organization trying to convert external cooperation into educational capability. The `employment_function` owns or coordinates the external relation, while the `teaching_function` must make it meaningful for students.
+
+### 3. Scenario Context
+
+The case appears in a year-end review where external partnership, project funding, and practical training are presented as achievements. The concern is whether these assets are isolated showcases or connected to the core learning system.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Employer coordination will become a real capability asset and improve student outcomes.
+- Reality: Without integration into curriculum, teaching plans, student projects, and assessment, the asset remains a detached showcase.
+- Gap summary: A real external asset exists, but the integration path is incomplete.
+
+### 5. Attempted Paths
+
+The apparent path is to list the external asset as proof of employment-oriented education. The missing path is the operational bridge from asset to student capability development.
+
+### 6. Dynamic Shift
+
+P. It is mainly a Problem because the asset appears real and the key gap is an integration path. It may become an Issue if authority conflict between functions blocks integration.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: medium
+
+### 8. Mixed Or Multi-Perspective
+
+`not_mixed`
+
+The primary scarcity is path/resource scarcity: how to connect employer assets to teaching and student capability. Governance risk exists, but it is not necessarily dominant unless internal authority conflict blocks integration.
+
+### 9. Governance Load
+
+Medium. The case requires coordination between functions, but the source suggests the asset itself may be healthy if connected to the learning system.
+
+### 10. Misframing Risks
+
+- tool_solutionism
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: problem
+- dominant_scarcity: path_resource
+- classification_confidence: medium
+- recommended_next_step: Ask for the operational bridge from employer asset to curriculum, student project, assessment, and outcome verification.
+
+### 12. Owner Review Questions
+
+- Should this case remain `problem`, or should it become `mixed` because cross-function integration may trigger authority conflict?
+- Is it useful as a positive contrast case where QPI should not over-escalate to Issue?
+- What minimum evidence would prove that the employer asset is truly integrated?
+
+## Case qpi-draft-007: Functional Performance Gains Justify Power Expansion Too Quickly
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that a function shows strong visible performance and is therefore granted a larger strategic role.
+
+### 2. Subject Position
+
+The subject is the organization under `decision_maker` authority. The `employment_function` becomes the favored vehicle for survival reform, while adjacent functions may lose authority without a full institutional design.
+
+### 3. Scenario Context
+
+The case appears in a crisis-driven review. Because the organization distrusts slower legacy systems, a function that appears closer to market outcomes is elevated rapidly.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Elevating a high-performing function will break through inertia and force the system to become outcome-oriented.
+- Reality: Fast power expansion can exceed the function's professional mandate, create backlash, and turn functional achievement into organizational overreach.
+- Gap summary: Performance evidence is used to justify authority expansion before governance boundaries are settled.
+
+### 5. Attempted Paths
+
+The apparent path is crisis-driven centralization around the function that seems closest to survival metrics. This may solve inertia but can create a new internal imbalance.
+
+### 6. Dynamic Shift
+
+P -> I. It starts as a Problem about overcoming departmental walls and implementation paralysis. It becomes an Issue when the solution redistributes authority, changes evaluation rights, and creates legitimacy conflict.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same organization lacks an implementation path and a legitimate authority design. The visible performance gain does not resolve governance scarcity.
+
+### 9. Governance Load
+
+High. The case requires designing authority scope, checks and balances, conflict resolution, data credibility, and whether the favored function can bear the role assigned to it.
+
+### 10. Misframing Risks
+
+- malicious_inflation
+- violent_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Do not infer from functional performance that the function should own system-wide authority. Define scope, checks, and evidence standards before expanding control.
+
+### 12. Owner Review Questions
+
+- Should this case be merged with Case 001, or kept separate as a general power-expansion pattern?
+- Does `malicious_inflation` apply, or is this better described as crisis-driven overextension?
+- Should QPI distinguish "asset recognition" from "authority transfer" as a recurring pattern?
+
+## Case qpi-draft-008: Survival Strategy Reframes Education As Transactional Output
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization needs a survival strategy in a hostile market and therefore shifts education toward employment, pricing, and measurable output.
+
+### 2. Subject Position
+
+The subject is the organization at the strategic level. `decision_maker` frames survival as the primary objective, while students, teaching units, employers, and compliance systems become parts of a transactional survival machine.
+
+### 3. Scenario Context
+
+The case appears in a diagnostic slice where student outcome pressure, pricing pressure, compliance indicators, and internal authority redesign converge. The organization may be moving from an education identity toward a transactional output identity.
+
+### 4. Expectation-Reality Gap
+
+- Expected: A more transactional, outcome-centered model will help the organization survive market pressure.
+- Reality: If the model hollows out teaching substance and relies on metrics, shortcuts, and pressure transfer, it may destroy the very legitimacy needed for long-term survival.
+- Gap summary: A survival adaptation risks becoming a self-defeating identity shift.
+
+### 5. Attempted Paths
+
+The apparent path is to align the organization around measurable survival outputs: student outcomes, employer linkage, lower-cost delivery, compliance metrics, and function-led accountability. The path may solve short-term pressure while worsening long-term capability.
+
+### 6. Dynamic Shift
+
+I. This is not a simple Question or Problem. It concerns strategic identity, institutional legitimacy, value definition, incentive design, and long-term governance.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+There are concrete path/resource scarcities, but the dominant problem is order scarcity: what kind of organization it is becoming, what success means, and which tradeoffs are acceptable.
+
+### 9. Governance Load
+
+Very high. The case requires continuous governance of identity, incentives, compliance boundaries, stakeholder trust, student value, and whether short-term survival tactics poison long-term viability.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat this as an Issue-level strategic governance case. Identify which survival tactics are reversible experiments and which would permanently alter institutional identity and trust.
+
+### 12. Owner Review Questions
+
+- Is this case too broad for calibration, or useful as an Issue anchor?
+- Should it be decomposed into several narrower P/I mixed cases?
+- What owner-approved wording should be used for the anonymized identity-shift risk?

reports/model_case_preprocessing/qpi/round-01/year-end-review-engineering-center.cases.md

@@ -0,0 +1,552 @@
+# QPI Case Drafts: Year-End Review Technical Function
+
+status: draft_owner_review_needed
+
+source_path: `<owner-provided QPI raw source path; redacted for anonymization>`
+
+anonymization_note: Real names, ancient-style cognitive-anchor names, organization names, places, timestamps, titles, exact figures, and sensitive operational details have been generalized. This draft preserves only the QPI-relevant structure of the organizational pathology.
+
+## Case qpi-draft-eng-001: Strategic Target Exceeds Operating Reality
+
+status: draft_owner_review_needed
+
+source_path: `<owner-provided QPI raw source path; redacted for anonymization>`
+
+### 1. Surface Problem
+
+A technical_function is asked to move from routine support work into a major revenue-generating or industrialized role.
+
+### 2. Subject Position
+
+The framing subject is an organization observer diagnosing the gap between decision_maker ambition and execution_lead capacity. The execution_lead is responsible for delivery but does not control the target, resource allocation, or strategic definition.
+
+### 3. Scenario Context
+
+The case appears in a year-end organizational review where a support-oriented technical_function is being evaluated against an expansion mandate that greatly exceeds its current validated output.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The technical_function should rapidly become a meaningful industrialization or revenue unit.
+- Reality: Existing output, skills, channels, and validated market capacity remain close to a support-function baseline.
+- Gap summary: A strategic growth target is imposed without a believable bridge from current capability to target state.
+
+### 5. Attempted Paths
+
+The organization has pointed to existing small wins, available staff, possible equipment purchases, and leadership attention as proof that the target can be pursued.
+
+### 6. Dynamic Shift
+
+The surface frame starts as a Problem: how to grow output. It shifts into an Issue because the target itself may distort reporting, procurement, project creation, and compliance behavior.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same technical_function faces a path/resource gap and an order/governance gap at the same time. The issue is not only how to execute, but whether the imposed target creates unhealthy organizational incentives.
+
+### 9. Governance Load
+
+High. The case requires ongoing target governance, metric authenticity checks, procurement restraint, and role-boundary management between strategic ambition and operational reality.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- tool_solutionism
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Reframe the target as a staged capability-and-market validation problem before accepting it as an execution target.
+
+### 12. Owner Review Questions
+
+- Should this case be judged as `issue` rather than `mixed` because the dominant risk is target governance?
+- Should the target-authenticity problem become a reusable QPI calibration pattern?
+
+## Case qpi-draft-eng-002: Equipment-Led Solutionism Without Market Closure
+
+status: draft_owner_review_needed
+
+source_path: `<owner-provided QPI raw source path; redacted for anonymization>`
+
+### 1. Surface Problem
+
+The organization considers buying advanced equipment or creating a high-end production capability.
+
+### 2. Subject Position
+
+The decision_maker frames equipment as the enabling condition. The execution_lead frames orders, skills, and operating standards as prior conditions. The observer evaluates the mismatch.
+
+### 3. Scenario Context
+
+The technical_function is under pressure to move into higher-value activity while still lacking proven market demand, trained operators, and delivery quality controls.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Assets and credentials will create capability, credibility, and future work.
+- Reality: The organization lacks confirmed demand, operator competence, and a reliable execution path.
+- Gap summary: The proposed solution may add fixed assets before the organization has solved the market and operating model.
+
+### 5. Attempted Paths
+
+The decision_maker pushes for asset-first expansion. The execution_lead suggests smaller tests or waiting for confirmed demand before committing to equipment and staffing.
+
+### 6. Dynamic Shift
+
+The issue starts as a Problem of sequencing investment. It shifts into Issue when equipment purchase becomes a governance decision that can lock in sunk cost, safety exposure, and reporting pressure.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same scene combines missing demand evidence, missing execution capability, and a conflict over investment logic.
+
+### 9. Governance Load
+
+High. The case requires procurement gates, demand validation, safety boundaries, and a rule for when asset commitments are allowed.
+
+### 10. Misframing Risks
+
+- tool_solutionism
+- violent_reduction
+- malicious_inflation
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: false
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Require demand proof, operator readiness, and safety validation before asset purchase.
+
+### 12. Owner Review Questions
+
+- Is `tool_solutionism` the primary misframing risk here?
+- Should QPI recommend a hard no-go gate when demand and operator readiness are both absent?
+
+## Case qpi-draft-eng-003: Compliance Shortcut Becomes Structural Constraint
+
+status: draft_owner_review_needed
+
+source_path: `<owner-provided QPI raw source path; redacted for anonymization>`
+
+### 1. Surface Problem
+
+The technical_function needs enough qualified staff to satisfy operational and regulatory expectations.
+
+### 2. Subject Position
+
+The execution_lead must deliver staffing coverage. Compliance_authority constrains shortcuts. The decision_maker wants low-cost continuity and expansion.
+
+### 3. Scenario Context
+
+A previous low-cost staffing workaround is no longer viable after external or internal compliance pressure. The organization must now meet formal qualification requirements.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Staffing gaps can be patched through flexible internal substitution.
+- Reality: Compliance boundaries now block the shortcut and force higher-cost, more formal staffing.
+- Gap summary: A once-tolerated operating hack has become a structural constraint.
+
+### 5. Attempted Paths
+
+The organization previously relied on substitute staffing. Compliance pressure forced a correction, but the expansion target still assumes cheap and flexible labor.
+
+### 6. Dynamic Shift
+
+The surface Problem is filling roles. It shifts to Issue because the organization must reconcile cost control, regulatory legitimacy, and expansion demands.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same staffing problem contains a resource gap and an order gap: the old path is blocked not by logistics alone, but by legitimacy and compliance.
+
+### 9. Governance Load
+
+High. The organization needs stable staffing policy, compliance review, budget realism, and authority alignment.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: false
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat staffing as a compliance-governance constraint, not as a simple headcount patch.
+
+### 12. Owner Review Questions
+
+- Should this be a canonical example of `issue` caused by compliance boundary hardening?
+- Should QPI require a separate compliance-risk field for cases like this?
+
+## Case qpi-draft-eng-004: Credential Integrity Treated As Mere Usability
+
+status: draft_owner_review_needed
+
+source_path: `<owner-provided QPI raw source path; redacted for anonymization>`
+
+### 1. Surface Problem
+
+The organization discovers a credential or background-check inconsistency in a person it still wants to use.
+
+### 2. Subject Position
+
+The decision_maker prioritizes immediate usability. Risk_control or compliance logic is underweighted. The observer frames the event as a governance signal.
+
+### 3. Scenario Context
+
+The technical_function is under staffing pressure, making it tempting to treat credential anomalies as a tolerable exception rather than a system-level warning.
+
+### 4. Expectation-Reality Gap
+
+- Expected: If someone can perform a near-term task, they can remain useful.
+- Reality: Credential integrity problems can expose the organization to trust, compliance, and future audit failures.
+- Gap summary: A short-term staffing solution masks a control-system failure.
+
+### 5. Attempted Paths
+
+The organization appears inclined to keep using the person if operationally convenient, instead of treating the case as a control breach requiring remediation.
+
+### 6. Dynamic Shift
+
+The surface frame is a Question or Problem: can this person be used? It shifts to Issue because the answer affects organizational trust, screening policy, and risk tolerance.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same decision mixes evidence uncertainty, staffing pressure, and governance-order risk.
+
+### 9. Governance Load
+
+High. The case requires a durable rule for credential verification, exception handling, and risk ownership.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Convert the incident into a screening and exception-policy review before making a convenience-based staffing decision.
+
+### 12. Owner Review Questions
+
+- Should this case be linked to QPI's no-call boundary against making specific personnel judgments?
+- Is the key QPI lesson about evidence integrity, compliance order, or both?
+
+## Case qpi-draft-eng-005: Production Capability Without Acquisition Channel
+
+status: draft_owner_review_needed
+
+source_path: `<owner-provided QPI raw source path; redacted for anonymization>`
+
+### 1. Surface Problem
+
+The technical_function may be able to perform some work but does not know where demand or orders will come from.
+
+### 2. Subject Position
+
+The execution_lead recognizes a business-closure gap. The decision_maker may assume production capability is enough to create business.
+
+### 3. Scenario Context
+
+The organization is trying to convert a support unit into a business unit without an established market channel or customer-acquisition function.
+
+### 4. Expectation-Reality Gap
+
+- Expected: If production capability exists, business can be generated.
+- Reality: The unit lacks a reliable path from capability to paying demand.
+- Gap summary: The business loop is incomplete at the demand-source stage.
+
+### 5. Attempted Paths
+
+The organization has discussed possible work types and capabilities, but no validated customer acquisition mechanism appears to exist.
+
+### 6. Dynamic Shift
+
+This begins as a Question: where do orders come from? It becomes a Problem when a sales or partnership path must be designed. It may become Issue if decision_maker pressure ignores the missing channel.
+
+### 7. Scarcity Profile
+
+- data_scarcity: high
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: medium
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same surface problem contains both missing market information and missing operating path.
+
+### 9. Governance Load
+
+Medium. Governance load rises if the organization continues to impose revenue targets without validating demand sources.
+
+### 10. Misframing Risks
+
+- premature_classification
+- tool_solutionism
+- malicious_inflation
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: data
+- classification_confidence: medium
+- recommended_next_step: Validate demand source and acquisition channel before committing to revenue targets or equipment expansion.
+
+### 12. Owner Review Questions
+
+- Should this be classified as `question` first because the missing demand source blocks all later action?
+- What minimal evidence would move this from Q to P?
+
+## Case qpi-draft-eng-006: Micro-Intervention Creates Execution Fatigue
+
+status: draft_owner_review_needed
+
+source_path: `<owner-provided QPI raw source path; redacted for anonymization>`
+
+### 1. Surface Problem
+
+The execution_lead becomes fatigued when decision flow is slow, intrusive, or repeatedly overridden.
+
+### 2. Subject Position
+
+The execution_lead is responsible for delivery but lacks stable decision space. The decision_maker holds authority and frequently intervenes in operational detail.
+
+### 3. Scenario Context
+
+A technical_function is under expansion pressure while leadership attention alternates between strategic target-setting and tactical detail control.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Direct leadership attention should accelerate progress.
+- Reality: Micro-intervention can reduce ownership, create waiting behavior, and exhaust execution energy.
+- Gap summary: Authority intended as support becomes a bottleneck and demotivating force.
+
+### 5. Attempted Paths
+
+The execution_lead appears to defer to decision_maker instructions and minimize independent commitment when details are repeatedly overridden.
+
+### 6. Dynamic Shift
+
+The surface problem appears to be execution attitude or morale. It shifts into Issue because decision rights, trust, and role boundaries are unstable.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same situation contains a path problem and an authority-order problem. Execution cannot stabilize until decision rights are clarified.
+
+### 9. Governance Load
+
+High. The organization needs explicit decision lanes, escalation rules, and protection of execution ownership.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Diagnose decision-rights architecture before blaming execution motivation.
+
+### 12. Owner Review Questions
+
+- Should this case be used as a violent-reduction example: "people are unmotivated" masking authority-design failure?
+- What evidence would distinguish healthy hands-on leadership from destructive micro-control?
+
+## Case qpi-draft-eng-007: Inherited Project May Be Hidden Liability
+
+status: draft_owner_review_needed
+
+source_path: `<owner-provided QPI raw source path; redacted for anonymization>`
+
+### 1. Surface Problem
+
+A certification or platform project is transferred to a weaker receiving function after a stronger function declines or disengages.
+
+### 2. Subject Position
+
+The receiving technical_function may frame the project as an opportunity. The observer frames the transfer as a possible adverse-selection signal.
+
+### 3. Scenario Context
+
+The organization treats an inherited project as a strategic asset, but the transfer history suggests possible hidden maintenance cost, low yield, or execution burden.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The project provides scarce qualification, status, or future income.
+- Reality: The project may have been avoided by stronger actors because costs, workload, or risk exceed benefits.
+- Gap summary: The asset label may hide a liability profile.
+
+### 5. Attempted Paths
+
+The organization celebrates or absorbs the project without first validating why the previous owner declined it and whether the receiver has capacity.
+
+### 6. Dynamic Shift
+
+The case starts as a Question: why was this project transferred? It becomes a Problem if cost-benefit analysis is needed. It becomes Issue if internal incentives push weaker units to absorb discarded burdens.
+
+### 7. Scarcity Profile
+
+- data_scarcity: high
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: medium
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The receiver's opportunity frame and the observer's risk frame diverge inside the same organizational context.
+
+### 9. Governance Load
+
+Medium. The organization needs transfer due diligence, cost accounting, and responsibility boundaries.
+
+### 10. Misframing Risks
+
+- premature_classification
+- malicious_inflation
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: data
+- classification_confidence: medium
+- recommended_next_step: Investigate transfer history, operating cost, and realistic value before treating the project as a confirmed asset.
+
+### 12. Owner Review Questions
+
+- Should this be a QPI calibration sample for "asset or liability" ambiguity?
+- Is the main lesson adverse selection, missing data, or organizational dumping?
+
+## Case qpi-draft-eng-008: Personnel Redeployment Without Legitimate Path
+
+status: draft_owner_review_needed
+
+source_path: `<owner-provided QPI raw source path; redacted for anonymization>`
+
+### 1. Surface Problem
+
+Existing staff may not fit the new technical direction, and leadership wants to move them elsewhere.
+
+### 2. Subject Position
+
+The decision_maker frames redeployment as a management lever. The execution_lead and affected staff face operational and legal constraints. Compliance logic limits informal movement.
+
+### 3. Scenario Context
+
+The technical_function is under pressure to upgrade capability while carrying legacy staffing constraints.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Existing personnel can be moved aside and replaced with more suitable staff.
+- Reality: Redeployment requires lawful, budgeted, and institutionally accepted paths that may not exist.
+- Gap summary: A personnel optimization idea lacks a legitimate execution route.
+
+### 5. Attempted Paths
+
+The organization discusses moving existing staff out and bringing in higher-capability staff, but no clear legal, financial, or relational path is established.
+
+### 6. Dynamic Shift
+
+The surface frame is a Problem: how to upgrade the team. It shifts to Issue because human consequences, compliance boundaries, budget, and organizational trust are intertwined.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same staffing challenge contains path scarcity and order scarcity. There may be no acceptable route without redesigning policy and incentives.
+
+### 9. Governance Load
+
+High. The case requires legal review, budget planning, role transition design, and authority alignment.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Define lawful redeployment and hiring boundaries before treating staff mismatch as an execution-only problem.
+
+### 12. Owner Review Questions
+
+- Should this case be merged with the compliance staffing case or kept separate as a personnel-transition governance case?
+- What minimum context is needed to avoid overclaiming legal or labor-risk conclusions?

reports/model_case_preprocessing/qpi/round-01/year-end-review-international-college.cases.md

@@ -0,0 +1,561 @@
+# QPI Case Drafts: Year-End Review, Cross-Border Education Function
+
+status: draft_owner_review_needed
+
+source_path: `[redacted owner-provided raw source path: organization CT slice]`
+
+anonymization_note: Real names, ancient-style cognitive-anchor names, organization names, places, timestamps, titles, exact numbers, and sensitive operational details have been generalized. These drafts are for owner review only and must not be promoted to JSON, selector calibration, or regression assets before owner confirmation.
+
+## Case qpi-draft-intl-001: Compliance Risk Packaged As Enrollment Retention
+
+status: draft_owner_review_needed
+
+source_path: `[redacted owner-provided raw source path: organization CT slice]`
+
+### 1. Surface Problem
+
+The surface issue appears to be how an enrollment team can retain students who entered through less attractive programs and want a better path.
+
+### 2. Subject Position
+
+The framing subject is a department-level execution team under enrollment pressure. The team is responsible for hitting intake and retention targets, but it does not fully own institutional compliance, regulator exposure, or long-term credential trust.
+
+### 3. Scenario Context
+
+The case appears in a year-end organizational review. A conventional enrollment pipeline is under market pressure, while a separate cross-border program has stronger growth and cash-flow performance. The struggling side uses a pathway adjustment mechanism to prevent student loss.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Flexible pathway management can preserve enrollment and reduce attrition.
+- Reality: The same action may convert a retention tactic into a compliance and trust risk.
+- Gap summary: What looks like an execution workaround from the team viewpoint may be a governance-level red line from the institutional viewpoint.
+
+### 5. Attempted Paths
+
+The execution team reframes the pathway adjustment as practical retention. The decision layer questions whether the mechanism is still legitimate institutional flexibility or has become a prohibited workaround.
+
+### 6. Dynamic Shift
+
+The frame shifts from P to P/I mixed. It begins as a resource and process problem: how to keep students in the pipeline. It escalates into Issue because the workaround changes the institution's risk posture and creates a recurring governance burden.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+For the same execution subject in the same organizational scene, there is both a path scarcity and an order scarcity. The team lacks a viable compliant path, and the attempted substitute threatens the legitimacy of the system.
+
+### 9. Governance Load
+
+High. The case requires risk containment, role boundary clarification, audit authenticity, future complaint prevention, and a decision on whether short-term survival can override institutional legitimacy.
+
+### 10. Misframing Risks
+
+- malicious_inflation
+- violent_reduction
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Separate retention problem-solving from compliance judgment; confirm hard red lines before designing any replacement pathway.
+
+### 12. Owner Review Questions
+
+- Is the dominant scarcity here correctly placed on consensus/order rather than path/resource?
+- Should this be treated as Issue rather than mixed because the compliance boundary dominates?
+- Which details, if any, are safe enough to retain in a future owner-approved case digest?
+
+## Case qpi-draft-intl-002: Physical Capacity Treated As Negotiable Resource
+
+status: draft_owner_review_needed
+
+source_path: `[redacted owner-provided raw source path: organization CT slice]`
+
+### 1. Surface Problem
+
+The surface issue is whether the organization can support an expanded enrollment target despite limited housing and delivery capacity.
+
+### 2. Subject Position
+
+The framing subject is a fast-growing cross-border education function seeking resources from the broader organization. It owns growth commitments but depends on other functions for physical delivery.
+
+### 3. Scenario Context
+
+The function's growth plan depends on shared infrastructure controlled by other units. Internal claims of having secured capacity conflict with evidence that the available capacity is constrained and contested.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Growth targets can be met through internal resource coordination.
+- Reality: The target appears to exceed verified delivery capacity, and the solution depends on displacing other units.
+- Gap summary: The business promise is ahead of the organization's physical and coordination reality.
+
+### 5. Attempted Paths
+
+The function attempts to solve the shortage through internal resource reallocation and pressure on adjacent units rather than through a verified capacity gate.
+
+### 6. Dynamic Shift
+
+The case shifts from P to I. At first it looks like a logistics problem. It becomes Issue when resource reallocation creates cross-unit conflict, delivery risk, and potential reputational consequences.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same growth function faces resource scarcity and governance scarcity simultaneously. The missing capacity cannot be solved only by a schedule, because allocation rights and downstream harm are contested.
+
+### 9. Governance Load
+
+High. The case requires a hard capacity gate, cross-functional arbitration, commitment control, downstream service assurance, and a clear rule for who bears the cost of over-promising.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- tool_solutionism
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: path_resource
+- classification_confidence: medium
+- recommended_next_step: Establish a verified delivery-capacity gate before allowing further promises, then decide whether resource conflict requires governance escalation.
+
+### 12. Owner Review Questions
+
+- Should dominant_scarcity be `path_resource` or `consensus_order`?
+- Is the key failure over-promising, cross-unit conflict, or the absence of a hard capacity gate?
+- Should this case be paired with a no-call selector trap about simple logistics requests?
+
+## Case qpi-draft-intl-003: Performance-Backed Role Inflation
+
+status: draft_owner_review_needed
+
+source_path: `[redacted owner-provided raw source path: organization CT slice]`
+
+### 1. Surface Problem
+
+The surface issue is whether a high-performing team should receive higher internal status, stronger authority, or a more formal role.
+
+### 2. Subject Position
+
+The framing subject is a high-performing subfunction that has become strategically valuable through revenue, external channels, and market execution ability. It is negotiating its organizational status from a position of performance leverage.
+
+### 3. Scenario Context
+
+The organization has an uneven internal power structure. A growth subfunction is gaining influence faster than formal governance rules can absorb, creating tension between performance contribution and institutional order.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Strong performance should be recognized and converted into appropriate authority.
+- Reality: Authority claims may become personalized, destabilize role boundaries, and create a semi-independent internal power center.
+- Gap summary: The organization lacks a clean mechanism for converting business contribution into legitimate governance authority.
+
+### 5. Attempted Paths
+
+The subfunction requests upgraded status and symbolic authority. The broader organization informally acknowledges the team's value but lacks a stable rule for granting power without encouraging factional autonomy.
+
+### 6. Dynamic Shift
+
+The case is Issue from the start. It is not only a staffing or title allocation problem; it concerns how performance, authority, accountability, and organizational identity are linked.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same situation contains a real resource/authority need and a governance-order risk. It should not be reduced to either "reward the team" or "suppress ambition."
+
+### 9. Governance Load
+
+High. The organization must manage role boundaries, incentive legitimacy, succession risk, internal fairness, and whether a high-performing team becomes an internal exception to normal rules.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- malicious_inflation
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Define a rule-based authority and accountability package before granting status; avoid converting personal leverage directly into structural power.
+
+### 12. Owner Review Questions
+
+- Is "performance-backed role inflation" the right abstraction, or should this be framed as "authority without accountability"?
+- Should this case include proxy stakeholders such as future management, adjacent units, and external partners?
+- Is the classification too confidently Issue without more context from the organization owner?
+
+## Case qpi-draft-intl-004: Strategic Chain Collapsed Into Front-End Sales
+
+status: draft_owner_review_needed
+
+source_path: `[redacted owner-provided raw source path: organization CT slice]`
+
+### 1. Surface Problem
+
+The surface issue is a disagreement about whether the function should focus on front-end recruitment or build a full education-to-outcome chain.
+
+### 2. Subject Position
+
+There are at least two subject positions: a decision layer thinking in long-term chain design, and an execution layer optimizing for faster recruitment and easier short-term delivery.
+
+### 3. Scenario Context
+
+The organization wants a cross-stage pathway that links intake, education delivery, advancement, and outcomes. The execution layer narrows the work into lead generation and conversion.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The function should build a durable pathway with downstream outcomes.
+- Reality: Execution behavior treats the work as a lighter enrollment intermediary business.
+- Gap summary: The strategic object and the operational object are not the same.
+
+### 5. Attempted Paths
+
+The decision layer pushes for a broader chain. The execution layer continues to prioritize front-end recruitment because it is faster, measurable, and closer to immediate incentives.
+
+### 6. Dynamic Shift
+
+This case shows `inter_viewpoint_divergence`. From the execution layer it may look like a P: how to recruit more effectively. From the decision layer it is an I: how to align organizational mission, delivery responsibility, and outcome accountability.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+The same surface request is framed differently by different responsibility positions. The issue is not merely mixed scarcity inside one frame; it is a divergence between strategic and operational definitions of the work.
+
+### 9. Governance Load
+
+High. The organization must decide what business it is actually in, what outcomes are owned, and whether short-term enrollment can be allowed to define the whole function.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- premature_classification
+- malicious_inflation
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Explicitly separate the decision-layer strategic frame from the execution-layer sales frame, then define which frame governs resource allocation.
+
+### 12. Owner Review Questions
+
+- Is this the clearest example of `inter_viewpoint_divergence` in this source?
+- Should the execution-layer frame be classified as Problem while the decision-layer frame is Issue?
+- Does this case need a paired expected output showing `classification_by_viewpoint`?
+
+## Case qpi-draft-intl-005: Inflated Credential Metrics As Fact Scarcity
+
+status: draft_owner_review_needed
+
+source_path: `[redacted owner-provided raw source path: organization CT slice]`
+
+### 1. Surface Problem
+
+The surface issue is whether reported credential or staffing indicators are real enough to support institutional evaluation and delivery claims.
+
+### 2. Subject Position
+
+The framing subject is the decision layer reviewing whether the execution layer's reported indicators represent real capability or only formalistic compliance.
+
+### 3. Scenario Context
+
+The organization faces evaluation pressure. The execution layer reports credential-related assets, but the decision layer suspects that the data may be inflated, symbolic, or disconnected from real teaching capacity.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Credential indicators should reflect real institutional capacity.
+- Reality: Reported indicators may be assembled to satisfy evaluation appearance without improving actual delivery.
+- Gap summary: The organization lacks trusted facts about whether the metric corresponds to real capability.
+
+### 5. Attempted Paths
+
+The execution layer presents the metric as progress. The decision layer questions the nature, source, and operational usefulness of the metric.
+
+### 6. Dynamic Shift
+
+The case begins as Q because the first scarcity is factual: what is the reported indicator really measuring? It may escalate into I if metric inflation is systemic and tied to governance incentives.
+
+### 7. Scarcity Profile
+
+- data_scarcity: high
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: medium
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The first move is fact verification, but the case contains a governance shadow because the organization may reward metric appearance over substance.
+
+### 9. Governance Load
+
+Medium to high. If the metric is false or misleading, the organization must repair audit authenticity, incentive design, and future reporting standards.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: question
+- dominant_scarcity: data
+- classification_confidence: medium
+- recommended_next_step: Verify whether the indicator maps to real delivery capacity before treating it as an asset or a compliance risk.
+
+### 12. Owner Review Questions
+
+- Should this remain Question-first, or should it be Issue because the source already frames it as systemic metric distortion?
+- What level of evidence would let this case move from fact verification into governance remediation?
+- Should the future digest keep the credential category abstract to avoid compliance sensitivity?
+
+## Case qpi-draft-intl-006: Pricing Deadlock Misread As Simple Market Weakness
+
+status: draft_owner_review_needed
+
+source_path: `[redacted owner-provided raw source path: organization CT slice]`
+
+### 1. Surface Problem
+
+The surface issue is weak demand for an existing program due to a mismatch between price and perceived market value.
+
+### 2. Subject Position
+
+The framing subject is an execution team responsible for recruitment under inherited pricing and product-positioning constraints. It can observe market rejection but may not have authority to reset the pricing structure.
+
+### 3. Scenario Context
+
+The program uses a pricing logic borrowed from stronger or different categories. Lowering price creates fairness and refund risks for existing participants, while not lowering price makes new recruitment difficult.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The program should compete in its market and sustain intake.
+- Reality: Pricing and perceived value are misaligned, and every correction path creates a secondary risk.
+- Gap summary: This is not merely poor sales execution; it is a structural deadlock between market fit and legacy commitment.
+
+### 5. Attempted Paths
+
+The team continues recruitment under the existing price structure and explores workaround mechanisms to preserve intake, rather than solving the underlying price-value mismatch.
+
+### 6. Dynamic Shift
+
+The case begins as P: find a viable pricing and enrollment path. It can become I when legacy commitments, refund fairness, and institutional reputation become the central constraints.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: medium
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The core path problem is clear, but order scarcity emerges because every path affects existing participants and institutional fairness.
+
+### 9. Governance Load
+
+Medium. The organization needs a transition rule, risk budget, and communication strategy rather than only a new sales tactic.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- tool_solutionism
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: problem
+- dominant_scarcity: path_resource
+- classification_confidence: medium
+- recommended_next_step: Model the transition options and their fairness costs before using workaround enrollment tactics.
+
+### 12. Owner Review Questions
+
+- Should this be a Problem case, or a P/I mixed case because the fairness and legacy-risk layer is central?
+- Does the owner want this retained as a distinct case if similar pricing deadlocks appear in other department slices?
+- What anonymized wording best captures the inherited-pricing constraint?
+
+## Case qpi-draft-intl-007: High-Quality Asset At Risk Of Privatization
+
+status: draft_owner_review_needed
+
+source_path: `[redacted owner-provided raw source path: organization CT slice]`
+
+### 1. Surface Problem
+
+The surface issue is how to retain and scale a high-performing field execution team.
+
+### 2. Subject Position
+
+The framing subject is the organization owner or decision layer assessing whether a valuable team capability is an institutional asset or an individual-centered private asset.
+
+### 3. Scenario Context
+
+A small, highly capable team has proven it can execute across recruitment, operations, documentation, and external coordination. The capability is valuable, but it may be bound to one leader or subfunction rather than institutionalized.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Strong team capability can be reused as an organizational asset.
+- Reality: The capability may be personally controlled, hard to transfer, and linked to bargaining power against the organization.
+- Gap summary: The organization has an asset, but it may not yet own the asset structurally.
+
+### 5. Attempted Paths
+
+The organization celebrates the team's results and may reward the team informally. It has not yet created a governance mechanism that captures the capability without killing the team's effectiveness.
+
+### 6. Dynamic Shift
+
+The case shifts from P to I. Initially it asks how to retain or replicate a team. It becomes Issue because institutionalization, incentives, personal leverage, and continuity all need governance.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same team is both an asset and a governance risk. Reducing it to "reward them" or "control them" would miss the system tension.
+
+### 9. Governance Load
+
+High. The organization must balance retention, incentives, knowledge transfer, role boundaries, and protection from private capture.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Design an institutionalization path that preserves execution energy while separating team capability from personal bargaining monopoly.
+
+### 12. Owner Review Questions
+
+- Is "privatization of organizational capability" the right abstraction here?
+- Should this case be connected with the role-inflation case or kept separate?
+- What owner-approved signal distinguishes healthy recognition from dangerous private capture?
+
+## Case qpi-draft-intl-008: Strong External Channel Used To Justify Risky Internal Expansion
+
+status: draft_owner_review_needed
+
+source_path: `[redacted owner-provided raw source path: organization CT slice]`
+
+### 1. Surface Problem
+
+The surface issue is whether a valuable external partnership and market channel should justify aggressive internal expansion.
+
+### 2. Subject Position
+
+The framing subject is a decision layer evaluating a growth function's strategic assets and the risks of overextending them.
+
+### 3. Scenario Context
+
+The function holds valuable external access and brand leverage. These assets create real opportunity, but the organization may use them to justify expansion into areas where delivery, compliance, and internal coordination are not ready.
+
+### 4. Expectation-Reality Gap
+
+- Expected: A strong external channel should become a protected strategic asset and growth engine.
+- Reality: If attached to low-quality or risky internal practices, the same channel can become contaminated and lose credibility.
+- Gap summary: Real assets can be converted into future liabilities when the internal operating model cannot support them.
+
+### 5. Attempted Paths
+
+The organization highlights the channel as proof of growth potential. The source analysis warns that the asset should not be used as cover for lower-quality or riskier practices.
+
+### 6. Dynamic Shift
+
+The frame starts as P: how to exploit a valuable channel. It becomes I when the key question is how to protect the asset from organizational misuse and incentive-driven overreach.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+There is a real growth path, but using it without governance can degrade the very asset that enables growth.
+
+### 9. Governance Load
+
+High. The organization needs rules for asset protection, partner trust, quality control, and limits on using strategic channels to mask weak delivery.
+
+### 10. Misframing Risks
+
+- malicious_inflation
+- violent_reduction
+- tool_solutionism
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat the external channel as a protected strategic asset; define what internal uses are prohibited before scaling.
+
+### 12. Owner Review Questions
+
+- Should this case remain separate from capacity and compliance cases, or is it a higher-level synthesis case?
+- Is the key misframing "real asset implies safe expansion"?
+- What minimum evidence should be kept in a future digest without identifying the partner or program category?
+

reports/model_case_preprocessing/qpi/round-01/year-end-review-research-office.cases.md

@@ -0,0 +1,565 @@
+# QPI Case Drafts: Year-End Review Research Function
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+source_note: Owner-provided raw organizational material. These drafts are anonymized and generalized for QPI review. Real or potentially identifying people, departments, institutions, timestamps, locations, titles, ancient-style cognitive anchors, exact numeric details, and sensitive operational details have been removed or generalized. These drafts are not selector JSON, regression cases, or owner-approved calibration data.
+
+anonymization_note: People are represented as roles such as `decision_maker`, `execution_lead`, `research_staff`, `compliance_staff`, and `frontline_staff`. The organization is represented as `the organization`; the department is represented as `research_function`. Sensitive details are generalized as `tax-preference metric pressure`, `research identity simulation`, `paper-and-patent metric pressure`, `talent-role mismatch`, `resource allocation bottleneck`, `facility capacity risk`, and `compliance red-line risk`.
+
+## Case qpi-draft-001: Tax-Preference Goal Becomes Research Identity Simulation
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization wants to qualify for an external preferential status that requires a credible research identity.
+
+### 2. Subject Position
+
+The subject is the organization as framed by `decision_maker` and translated through `research_function` and related administrative functions. It is not a neutral learner asking how the policy works; it is an accountable organization under financial pressure, attempting to turn an external status requirement into an internal reporting strategy.
+
+### 3. Scenario Context
+
+The case appears in a year-end review of a `research_function`. The function is expected to support external certification, research metrics, and organizational reputation, while the actual operating base is more commercial and administrative than research-intensive.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The organization expects to obtain a preferential external status by assembling research-related indicators and evidence.
+- Reality: The underlying research capacity is not strong enough to naturally support the desired identity, so the organization considers simulating research attributes through administrative reclassification and transactional evidence.
+- Gap summary: A capability-building problem is reframed as an evidence-packaging and accounting problem.
+
+### 5. Attempted Paths
+
+The apparent path is to make existing people, expenses, and intangible assets appear research-related enough to satisfy the external gate. This avoids building real research capability but increases `compliance red-line risk` and audit fragility.
+
+### 6. Dynamic Shift
+
+P -> I. It begins as a Problem about how to meet an external qualification requirement. It shifts into an Issue because the chosen path changes the organization's relationship to truthfulness, legal exposure, research identity, and long-term legitimacy.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+For the same organizational subject, the case has both a resource/path gap and a governance gap. The organization lacks sufficient real research capacity, and the proposed workaround undermines the legitimacy of the reported identity.
+
+### 9. Governance Load
+
+Very high. The case requires managing audit authenticity, compliance boundaries, financial pressure, research identity, and whether short-term certification gain is worth long-term institutional risk.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- tool_solutionism
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat the case as a governance Issue with a path/resource trigger; separate legitimate capability-building paths from evidence simulation and compliance red-line risk.
+
+### 12. Owner Review Questions
+
+- Should this be the umbrella QPI case for the source, or should it remain a narrower certification-risk sample?
+- Should `classification` be `issue` or `mixed` given the strong path/resource shortage behind the governance failure?
+- Is the anonymized phrase `research identity simulation` acceptable, or should it be softened further?
+
+## Case qpi-draft-002: Research Staff Count Treated As Movable Accounting Data
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization lacks enough research-qualified personnel or research-related cost evidence to satisfy an external metric.
+
+### 2. Subject Position
+
+The subject is `decision_maker` using administrative authority to force metric completion, with `research_function`, finance, and personnel-related roles expected to make the numbers fit. A system analyst would see the same situation as a boundary and legitimacy problem rather than a simple data-filling task.
+
+### 3. Scenario Context
+
+The case occurs inside a certification and reporting context where staff identity, payroll category, and research contribution are treated as adjustable inputs to a metric package.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Staff and cost categories can be rearranged to make the organization appear research-intensive.
+- Reality: Research identity depends on actual work, role, capability, and evidence. Moving labels without changing reality creates a fragile and potentially noncompliant data package.
+- Gap summary: A real capability shortage is violently reduced to category manipulation.
+
+### 5. Attempted Paths
+
+The attempted path is to reassign or relabel non-research roles into research-related categories. This may reduce a reported data gap but creates a truthfulness gap and escalates audit risk.
+
+### 6. Dynamic Shift
+
+Q/P -> I. It may first appear as a Question about what the metric requires or a Problem about how to satisfy it. With context, it becomes an Issue because the organization is changing the meaning of "research personnel" to survive the metric.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+From `decision_maker`, the case may look like an execution Problem: adjust the table. From a compliance or research-quality viewpoint, it is an Issue about role truthfulness and institutional integrity.
+
+### 9. Governance Load
+
+High. The organization needs rules for role classification, evidence authenticity, refusal boundaries, and escalation when a metric request conflicts with real work identity.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- tool_solutionism
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Use this as a QPI sample for distinguishing missing data from falsified or untrusted data; ask the owner whether the case should explicitly mark "data completeness is not truthfulness."
+
+### 12. Owner Review Questions
+
+- Should this case be classified as `inter_viewpoint_divergence` because different roles see different frames, or `intra_frame_mixed` because both resource and governance scarcities exist?
+- Is the main misframing `violent_reduction` from research capability to spreadsheet category?
+- Should this sample later test QPI's ability to reject high-confidence classification when compliance details are not owner-verified?
+
+## Case qpi-draft-003: Transactional Research Assets Create Audit Fragility
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization needs enough research outputs or transferable assets to support its external status and metrics.
+
+### 2. Subject Position
+
+The subject is the `research_function` under `decision_maker` pressure. The function is expected to manufacture evidence for an identity it may not substantively possess. External auditors, regulators, and future organizational actors are proxy stakeholders.
+
+### 3. Scenario Context
+
+The case appears where research outputs are discussed less as knowledge production and more as objects that can be transacted, reported, or recycled to satisfy rules.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The organization can close the research-output gap by acquiring or circulating research-like assets.
+- Reality: If the transaction has weak substantive value, it may create formal evidence while increasing audit fragility and institutional risk.
+- Gap summary: The organization treats research evidence as a tradable token rather than as a trace of real capability.
+
+### 5. Attempted Paths
+
+The attempted path is to use asset transactions or paper evidence to create the appearance of research output. The method may satisfy a surface indicator while leaving the capability gap unresolved.
+
+### 6. Dynamic Shift
+
+P -> I. It starts as a Problem about acquiring enough evidence. It becomes an Issue because the evidence path itself changes the organization's risk profile and value system.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same subject has insufficient real output and a governance conflict over whether synthetic evidence should be accepted. The path scarcity and order scarcity reinforce each other.
+
+### 9. Governance Load
+
+Very high. The case requires deciding what counts as authentic evidence, what transaction patterns are prohibited, who can refuse risky actions, and how audit traces should be preserved.
+
+### 10. Misframing Risks
+
+- tool_solutionism
+- violent_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat the case as a P/I mixed sample where the immediate path gap is dominated by evidence authenticity and compliance governance.
+
+### 12. Owner Review Questions
+
+- Should this be merged with Case 001 as a subcase of research identity simulation?
+- Should the dominant scarcity be `path_resource` because the organization lacks real assets, or `consensus_order` because the chosen route is illegitimate?
+- Is this anonymized enough, or should all references to transactional research assets be further abstracted?
+
+## Case qpi-draft-004: Ranking Anxiety Converts Research Into Purchasable Metrics
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that external ranking or reputation indicators are declining or under pressure, and the organization wants quick visible improvement.
+
+### 2. Subject Position
+
+The subject is the organization under `metric pressure`. `decision_maker` cares about external visibility and market effects; `research_function` is asked to deliver measurable outputs; `research_staff` and external collaborators become instruments of metric production.
+
+### 3. Scenario Context
+
+The case occurs in a review of research performance where publications, projects, and recognitions are treated primarily as ranking inputs rather than as outcomes of genuine inquiry.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Increasing reported outputs should improve reputation, ranking, and market appeal.
+- Reality: If the output is produced mainly through transactional or low-authenticity mechanisms, the organization may improve the metric while degrading research culture and long-term credibility.
+- Gap summary: A reputation problem is reframed as a purchasable output problem, hiding the value-system failure.
+
+### 5. Attempted Paths
+
+The attempted path is to reward or purchase visible research outputs without resolving underlying capability, research culture, or quality-control constraints.
+
+### 6. Dynamic Shift
+
+P -> I. At first it looks like a Problem of improving ranking inputs. It becomes an Issue when the optimization logic corrupts the meaning of research and creates future trust risk.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+`decision_maker` may frame the case as a metric execution problem. `research_staff` may experience it as a value and incentive issue. A system analyst sees a governance problem where metrics replace mission.
+
+### 9. Governance Load
+
+High. The case requires ongoing tradeoffs among ranking pressure, research authenticity, incentive design, quality control, and reputational exposure.
+
+### 10. Misframing Risks
+
+- malicious_inflation
+- violent_reduction
+- tool_solutionism
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Use this as a QPI sample for "metric improvement is not the same as capability improvement"; ask the owner whether later calibration should route this to governance review rather than execution planning.
+
+### 12. Owner Review Questions
+
+- Should this be a strong sample for `malicious_inflation`, where an ordinary metric problem is inflated into a legitimacy narrative to justify risky action?
+- Or is the stronger risk `violent_reduction`, where research value is reduced to ranking inputs?
+- Should this case later connect to selector traps around "how to improve ranking quickly"?
+
+## Case qpi-draft-005: High-Level Talent Becomes Role-Mismatched Display Asset
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that the organization has recruited high-level talent but struggles to place that talent into suitable teaching, research, or operational roles.
+
+### 2. Subject Position
+
+The subject is the organization as employer and capability builder. `decision_maker` views talent as proof of quality and as a metric asset. The recruited expert is a proxy stakeholder whose professional identity, motivation, and retention risk matter.
+
+### 3. Scenario Context
+
+The case appears in a research and staffing review where expert credentials are valuable for external appearance, but internal course design, research platform, or task structure cannot absorb the expert's actual capability.
+
+### 4. Expectation-Reality Gap
+
+- Expected: High-level talent should strengthen research status, teaching quality, and external metrics.
+- Reality: The organization lacks appropriate work design, so the talent is assigned generic or mismatched tasks that waste capability and weaken long-term retention.
+- Gap summary: Talent acquisition solves a credential problem while creating a role-fit and capability-utilization problem.
+
+### 5. Attempted Paths
+
+The attempted path is to keep the talent by creating broad, low-specificity assignments that are easier to schedule but misaligned with the person's expertise. This preserves the visible asset while degrading its productive value.
+
+### 6. Dynamic Shift
+
+P -> I. It starts as a Problem of how to arrange work for a high-level hire. It becomes an Issue because the organization treats human capability as a display asset, creating retention, morale, and mission-integrity risks.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same organization lacks an execution path for using expert capability and also has a governance conflict over whether talent is valued as capability or as an indicator.
+
+### 9. Governance Load
+
+High. The case requires balancing credential needs, real capability use, task design, professional dignity, retention risk, and whether the organization is willing to build the platform needed for talent to matter.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Frame the case as a role-governance Issue with a work-design Problem inside it; ask whether the QPI output should explicitly mark talent-as-indicator reduction.
+
+### 12. Owner Review Questions
+
+- Should this case be promoted as a separate QPI calibration sample or kept as a subcase of metric-driven research identity?
+- Is `dominant_scarcity: consensus_order` correct, or should `path_resource` dominate because the immediate blocker is work design?
+- Should future case digest include proxy stakeholder `high_level_talent`?
+
+## Case qpi-draft-006: Facility Capacity Risk Misread As Expansion Logistics
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that a growing program or external-facing activity needs more physical capacity than the organization currently has.
+
+### 2. Subject Position
+
+The subject is the organization under growth pressure. `decision_maker` prioritizes expansion and revenue; `execution_lead` must find space; affected staff and users are proxy stakeholders who bear the consequences of compression.
+
+### 3. Scenario Context
+
+The case appears in a year-end review where growth has already been promised or pursued, while physical capacity and operational readiness lag behind.
+
+### 4. Expectation-Reality Gap
+
+- Expected: The organization can absorb expanded activity by reallocating existing space or forcing internal adjustments.
+- Reality: Physical capacity is a hard constraint. Improvised reallocation may damage teaching, work continuity, user experience, safety, and trust.
+- Gap summary: A capacity planning failure is treated as a short-term logistics task.
+
+### 5. Attempted Paths
+
+The attempted path is to squeeze or repurpose existing space rather than slow expansion or invest in capacity. This may solve the immediate placement problem but transfer cost to other functions and future stability.
+
+### 6. Dynamic Shift
+
+P -> I. It begins as a Problem of finding enough physical space. It becomes an Issue when growth promises, resource allocation, user rights, staff disruption, and reputational risk collide.
+
+### 7. Scarcity Profile
+
+- data_scarcity: low
+- path_or_resource_scarcity: high
+- consensus_or_order_scarcity: medium
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same organizational frame contains a hard resource shortage and a governance burden. The path scarcity is dominant, but the way the shortage is handled creates order and legitimacy risks.
+
+### 9. Governance Load
+
+High. The case requires capacity governance, expansion pacing, risk communication, user protection, and whether revenue growth can override physical readiness.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: mixed
+- dominant_scarcity: path_resource
+- classification_confidence: medium
+- recommended_next_step: Treat as a P/I mixed case; first verify physical capacity and committed obligations, then decide whether expansion should be capped, delayed, or redesigned.
+
+### 12. Owner Review Questions
+
+- Should this case be classified as `problem` because resource scarcity dominates, or `mixed` because downstream governance risk is already visible?
+- Should it be used as a calibration sample for "hard constraint cannot be solved by administrative command"?
+- Is the growth context anonymized enough, or should all references to external-facing activity be made more generic?
+
+## Case qpi-draft-007: Safety Responsibility Vacuum Covered By Emergency Command
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is that a safety-related task needs immediate ownership and completion.
+
+### 2. Subject Position
+
+The subject is the organization as an operating system. `decision_maker` can issue emergency commands, but the real subject includes the missing responsibility chain, affected users, and downstream risk owners.
+
+### 3. Scenario Context
+
+The case appears in a meeting where responsibility for a safety-related administrative action is unclear until a top-down directive assigns it under time pressure.
+
+### 4. Expectation-Reality Gap
+
+- Expected: Safety tasks should have a clear owner, process, evidence trail, and escalation route.
+- Reality: The responsibility chain is unclear, and the gap is patched through emergency personal assignment rather than through a stable process.
+- Gap summary: A process and accountability failure is temporarily hidden by command authority.
+
+### 5. Attempted Paths
+
+The attempted path is to assign a person under urgent deadline pressure. This may produce a short-term action but does not solve the underlying absence of stable responsibility architecture.
+
+### 6. Dynamic Shift
+
+Q/P -> I. It could look like a Question of "who handles this?" or a Problem of task completion. With context, it becomes an Issue about accountability design, safety governance, and command-dependent operations.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: medium
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`intra_frame_mixed`
+
+The same organizational subject has a data gap about responsibility, a path gap about execution, and a dominant governance gap about safety accountability.
+
+### 9. Governance Load
+
+High. The case requires responsibility mapping, documented ownership, escalation rules, safety evidence, and prevention of repeat emergency command substitution.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- premature_classification
+- single-cause_reduction
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: subject_contextual
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Route as an Issue: identify the missing responsibility chain before treating it as an isolated task execution problem.
+
+### 12. Owner Review Questions
+
+- Should this case be included despite being a smaller slice than the research and compliance cases?
+- Is this a useful QPI sample for "Q-like responsibility question that is actually an accountability Issue"?
+- Should safety details be further generalized for publication safety?
+
+## Case qpi-draft-008: Compliance Risk Defined Only By Immediate Penalty
+
+status: draft_owner_review_needed
+
+source_path: `[redacted external source path: owner-provided organizational CT slice]`
+
+### 1. Surface Problem
+
+The surface problem is whether a past or ongoing compliance-sensitive behavior creates meaningful risk for the organization.
+
+### 2. Subject Position
+
+The subject is the organization as interpreted by `compliance_staff`, `research_function`, and `decision_maker`. The viewpoint is not a legal conclusion; it is an internal risk frame that may underestimate non-financial, reputational, and ethical exposure.
+
+### 3. Scenario Context
+
+The case appears where internal actors assess external scrutiny through the narrow lens of whether immediate penalties, reimbursement issues, or formal interviews have occurred.
+
+### 4. Expectation-Reality Gap
+
+- Expected: If no immediate penalty or visible sanction occurs, the organization can treat the behavior as low-risk or resolved.
+- Reality: Compliance and academic integrity risks can persist even without immediate financial loss or official sanction. The absence of punishment is not the same as the presence of legitimacy.
+- Gap summary: The organization collapses substantive compliance into short-term penalty avoidance.
+
+### 5. Attempted Paths
+
+The attempted path is to benchmark against whether other institutions or actors were formally sanctioned and to use the lack of immediate punishment as proof of acceptability. This converts compliance into a minimum-punishment game.
+
+### 6. Dynamic Shift
+
+Q -> I. It starts as a Question about whether a behavior caused formal risk. It becomes an Issue because the organization's definition of risk is miscalibrated and may normalize future boundary crossing.
+
+### 7. Scarcity Profile
+
+- data_scarcity: medium
+- path_or_resource_scarcity: low
+- consensus_or_order_scarcity: high
+
+### 8. Mixed Or Multi-Perspective
+
+`inter_viewpoint_divergence`
+
+Internal actors may classify the situation as a Question about penalty status. A governance or integrity frame classifies it as an Issue about what counts as acceptable behavior.
+
+### 9. Governance Load
+
+High. The case requires redefining compliance beyond immediate punishment, creating review standards, and preventing "not caught yet" from becoming the organization's operating rule.
+
+### 10. Misframing Risks
+
+- violent_reduction
+- single-cause_reduction
+- premature_classification
+
+### 11. Candidate QPI Judgment
+
+- classification_scope: multi_perspective
+- is_provisional: true
+- classification: issue
+- dominant_scarcity: consensus_order
+- classification_confidence: medium
+- recommended_next_step: Treat as an Issue about compliance-risk framing; request owner confirmation before using it as a calibration sample because legal interpretation must remain generalized.
+
+### 12. Owner Review Questions
+
+- Should this be kept as a separate QPI sample or folded into the broader metric-and-compliance culture case?
+- Should the candidate judgment emphasize `inter_viewpoint_divergence` between penalty-status and integrity-status frames?
+- Is the legal-risk language sufficiently generalized?
+

reports/model_review_status.json

@@ -0,0 +1,34 @@
+{
+  "review_version": "0.2",
+  "last_updated": "2026-06-16",
+  "models": [
+    {
+      "model_id": "qpi",
+      "engineering_contract_status": "passed",
+      "content_review_status": "needs_owner_review",
+      "evidence_review_status": "field_level_matrix_created",
+      "regression_review_status": "expanded_pending_review",
+      "selector_review_status": "v0_2_no_call_tests_passed",
+      "draft_callable": true,
+      "stable_allowed": false,
+      "third_model_expansion_allowed": false,
+      "status": "draft",
+      "stability_level": "B",
+      "regression_status": "pending"
+    },
+    {
+      "model_id": "intellectual_archaeology",
+      "engineering_contract_status": "passed",
+      "content_review_status": "needs_owner_review",
+      "evidence_review_status": "field_level_matrix_created",
+      "regression_review_status": "expanded_pending_review",
+      "selector_review_status": "v0_2_no_call_tests_passed",
+      "draft_callable": true,
+      "stable_allowed": false,
+      "third_model_expansion_allowed": false,
+      "status": "draft",
+      "stability_level": "B",
+      "regression_status": "pending"
+    }
+  ]
+}

reports/next_action_register_v0.2.md

@@ -0,0 +1,25 @@
+# Next Action Register v0.2
+
+## Status
+
+QPI and Intellectual Archaeology are ready for content review as `draft-callable` assets.
+
+They are not stable.
+
+Do not expand to a third model yet.
+
+## Owner / CCRA Review Items
+
+1. Review whether QPI's structured output contract is sufficient for routing.
+2. Review whether QPI's mixed-case dominant scarcity rule is acceptable.
+3. Review whether Intellectual Archaeology's stop gate is strict enough.
+4. Review whether `draft-callable` should remain report-only or become a future schema field.
+5. Review selector v0.2 false-positive protections against real user inputs.
+
+## Suggested Next Tasks
+
+1. Run human review on `reports/evidence_coverage_report_v0.2.md`.
+2. Review all 34 regression cases for realism and missing edge cases.
+3. Add real failed-call examples if available.
+4. Decide whether `model_review_status.json` should become a first-class schema.
+5. Only after review, discuss whether a third model should enter the library.

reports/open_questions_for_CCRA.md

@@ -0,0 +1,31 @@
+# Open Questions For CCRA
+
+## QPI
+
+1. Should `problem_owner` be required in QPI output for all calls, with `unknown` allowed when unavailable?
+2. Should `time_scale` be required in QPI output, or remain a recommended routing field?
+3. Is the current `dominant_scarcity` enum sufficient: `data`, `path_resource`, `consensus_order`, `mixed`, `unknown`?
+4. For mixed cases, should QPI always output `classification=mixed`, or can it output a primary classification plus mixed evidence?
+5. Are the violent reduction / malicious inflation checks strong enough for review, or should they become separate required output fields?
+
+## Intellectual Archaeology
+
+1. Should `recommended_max_depth` become a required model-card schema field?
+2. Should `stop_reason` and `no_deeper_reason` become required output fields?
+3. Should `value_of_deeper_analysis` be added explicitly, or is `no_deeper_reason` plus `action_implication` enough?
+4. Should QPI approval be mandatory before Intellectual Archaeology can be selected, except for explicit model-extraction tasks?
+5. Is `philosophical_bedrock` allowed only when the input explicitly concerns problem ontology or model foundations?
+
+## Regression And Selector
+
+1. Are 17 cases per model sufficient for the next review phase?
+2. Should `regression_status` remain `pending`, or move to `in_progress` after this expansion?
+3. Is selector v0.2's no-call threshold of `0.35` acceptable for review, or should it be calibrated with real inputs?
+4. Is it acceptable for mixed QPI cases to recommend QPI first and leave IA as a later candidate only after QPI output?
+
+## Status
+
+1. Should `draft-callable` remain report-only for v0.2?
+2. Should `draft-callable` become a first-class schema/status field later?
+3. Should both models remain `draft / B / pending`? Current Codex recommendation: yes.
+4. Should third model expansion remain blocked until after this review? Current Codex recommendation: yes.

reports/schema_change_notes.md

@@ -0,0 +1,95 @@
+# Schema Change Notes
+
+## Scope
+
+This note covers schema changes made during the second content stabilization pass.
+
+## Changed Schemas
+
+### `schemas/source_article.schema.json`
+
+Change:
+
+- Formalized `source_type` enum:
+  - `original_article`
+  - `synthesis_note`
+  - `placeholder`
+- Formalized `source_status` enum:
+  - `representative`
+  - `derived_synthesis`
+  - `placeholder`
+
+Reason:
+
+- Current data already used `synthesis_note` and `derived_synthesis`.
+- The schema now matches implementation data instead of leaving enum drift implicit.
+
+### `schemas/source_excerpt.schema.json`
+
+Change:
+
+- Added required `quote_status`.
+- Added required `source_location`.
+- Formalized `quote_status` enum:
+  - `exact`
+  - `condensed`
+  - `paraphrased`
+- Formalized `excerpt_type` enum:
+  - `definition`
+  - `taxonomy`
+  - `mechanism`
+  - `application_rule`
+  - `value_claim`
+  - `boundary_rule`
+  - `validation_rule`
+
+Reason:
+
+- Distinguishes exact quotes from compressed or paraphrased evidence.
+- Prevents `raw_excerpt` from silently containing condensed text.
+
+### `schemas/regression_case.schema.json`
+
+Change:
+
+- Expanded `case_type` enum:
+  - `positive`
+  - `boundary`
+  - `misuse`
+  - `no_call`
+  - `selector_gate`
+  - `pipeline`
+- Added optional evaluable fields:
+  - `should_call_model`
+  - `expected_primary_model`
+  - `negative_expected_models`
+  - `expected_classification`
+  - `expected_dominant_scarcity`
+  - `expected_max_depth`
+  - `minimum_required_elements`
+  - `forbidden_elements`
+  - `evaluation_mode`
+
+Reason:
+
+- Supports no-call, false-positive, selector-gate, and structured review cases without adding LLM evaluation.
+
+## Not Changed
+
+### `schemas/model_card.schema.json`
+
+No new required model-card fields were added in this pass.
+
+Reason:
+
+- QPI and Intellectual Archaeology output contracts were strengthened in model JSON and cards.
+- Making those fields schema-required is left for CCRA / Owner review to avoid over-weighting v0.2.
+
+### `schemas/model_index.schema.json`
+
+No additional index semantics were added in this pass.
+
+Reason:
+
+- Index continues to mirror model/card state and counts.
+- Content review status remains in `reports/model_review_status.json`, not `model_index.json`.

reports/selector_regression_report.md

@@ -0,0 +1,15 @@
+# Selector Regression Report
+
+This file is an audit-friendly alias for:
+
+- `reports/selector_regression_report_v0.2.md`
+
+Current status: `PASS`
+
+Summary:
+
+- Cases checked: 9
+- Failures: 0
+- no-call cases pass.
+- QPI-before-IA gate cases pass.
+- Pipeline gate cases pass.

reports/selector_regression_report_v0.2.md

@@ -0,0 +1,18 @@
+# Selector Regression Report v0.2
+
+Status: `PASS`
+
+Cases checked: 9
+Failures: 0
+
+## Cases
+
+- `case_ia_no_call_fact_001`: PASS; selected=[]; no_call=True
+- `case_ia_no_call_edit_001`: PASS; selected=[]; no_call=True
+- `case_ia_no_call_light_execution_001`: PASS; selected=[]; no_call=True
+- `case_ia_selector_gate_qpi_first_001`: PASS; selected=['qpi']; no_call=False
+- `case_ia_selector_gate_no_heavy_signal_001`: PASS; selected=[]; no_call=True
+- `case_ia_pipeline_after_qpi_001`: PASS; selected=['intellectual_archaeology', 'qpi']; no_call=False
+- `case_qpi_no_call_direct_edit_001`: PASS; selected=[]; no_call=True
+- `case_qpi_selector_gate_fact_001`: PASS; selected=[]; no_call=True
+- `case_qpi_pipeline_before_ia_001`: PASS; selected=['qpi']; no_call=False

reports/selector_score_breakdown.md

@@ -0,0 +1,24 @@
+# Selector Score Breakdown
+
+Selector v0.2 emits per-model score details from `scripts/run_selector_demo.py`.
+
+Current demo input:
+
+```text
+团队每次都说要长期主义，但一到季度 KPI 就回到短期动作，这到底是什么问题？
+```
+
+Current output summary:
+
+| Model | Score | Decision | Reasons | Penalties |
+| --- | ---: | --- | --- | --- |
+| `qpi` | 0.44 | selected | pipeline_position matched; complexity signal: 长期; selection_priority=9 | none |
+| `intellectual_archaeology` | 0.02 | rejected | complexity signal: 长期; selection_priority=7 | no IA heavy-depth gate |
+
+Rules represented:
+
+- Negative trigger first.
+- No-call threshold.
+- QPI-before-IA gate.
+- Rejected model reasons.
+- No LLM selector.

reports/validation_report.md

@@ -0,0 +1,12 @@
+# Validation Report
+
+Status: `PASS`
+
+Command: `python scripts/validate_model_library.py`
+
+## Result
+
+- JSON 文件可解析。
+- 模型必填字段存在并符合本地 contract 子集。
+- source article、source excerpt、regression case 引用完整。
+- model/card index 引用完整，计数、状态和索引投影一致。

reports/内容修复检查摘要_v0.1.md

@@ -0,0 +1,41 @@
+# 内容修复检查摘要 v0.1
+
+## Scope
+
+本次检查对象：
+
+- `models/qpi.model.json`
+- `models/intellectual_archaeology.model.json`
+- `cards/qpi.md`
+- `cards/intellectual_archaeology.md`
+- `models/model_index.json`
+- `cards/card_index.md`
+
+## Verification Commands
+
+```powershell
+python -m unittest discover -s tests -p "test*.py" -v
+python scripts\check_card_contract.py
+python scripts\validate_model_library.py
+python scripts\run_selector_demo.py
+```
+
+## Results
+
+- Unit tests: PASS, 9 tests.
+- Card contract: PASS.
+- Model library validation: PASS.
+- Selector demo: PASS.
+- `reports/validation_report.md`: `Status: PASS`.
+
+## Current Status
+
+QPI and Intellectual Archaeology content now passes the current local contract.
+
+The model assets remain `draft`, not final product-approved content. The next gate is owner content review for definition wording, evidence adequacy, boundaries, and selector behavior.
+
+## Notes
+
+- `scripts/run_selector_demo.py` returns both models with scores and reasons.
+- Index entries are aligned with current model and card files.
+- Test-generated `__pycache__` directories were removed after verification.

reports/内容修复检查摘要_v0.2.md

@@ -0,0 +1,33 @@
+# 内容修复检查摘要 v0.2
+
+## 范围
+
+本摘要覆盖模型库 MVP 第二轮内容稳定化。
+
+## 完成项
+
+- 字段级 evidence coverage matrix 已建立。
+- source excerpt 已增加 `quote_status` 和 `source_location`。
+- QPI 输出契约已强化。
+- 思想考古停止门已强化。
+- regression cases 已扩展到每模型 17 条。
+- selector v0.2 已增加 no-call、negative trigger、QPI-before-IA gate 和 rejected reasons。
+- JSON / Markdown 硬字段同步检查已增加。
+
+## 验证状态
+
+| Check | Status |
+| --- | --- |
+| schema / model library validation | PASS |
+| card contract check | PASS |
+| index drift check | PASS |
+| selector regression | PASS |
+| JSON / Markdown sync | PASS |
+| unit tests | PASS |
+
+## 当前状态
+
+- QPI: `draft / B / pending`
+- 思想考古: `draft / B / pending`
+- stable: not allowed
+- third model expansion: not allowed

reports/规则Schema工作流检查摘要_v0.1.md

@@ -0,0 +1,116 @@
+# 规则 Schema 工作流检查摘要 v0.1
+
+## Completed
+
+- 新增 GPT 规划本地化协议。
+- 新增模型抽取规则。
+- 新增模型卡 Markdown contract。
+- 新增模型抽取 workflow。
+- 新增机器模型索引 `models/model_index.json`。
+- 新增人读模型卡索引 `cards/card_index.md`。
+- 新增权威机器模型卡 schema `schemas/model_card.schema.json`。
+- 新增 `schemas/model_index.schema.json`。
+- 新增 `schemas/card_index.schema.json`。
+- 为 source article、source excerpt、regression case schema 补充中文 `description`。
+- 为 regression case schema 增加 `case_type` 枚举：`positive`、`boundary`、`misuse`。
+- 升级 `scripts/validate_model_library.py`，增加本地 contract 子集、index、回归覆盖检查。
+- 新增 `scripts/check_card_contract.py`。
+- 新增 `scripts/run_selector_demo.py`。
+- 新增和更新单元测试。
+- 更新 README、workflow、schema/scripts/selector/cards/models 目录说明。
+
+## Files Changed
+
+Created:
+
+- `docs/MODEL_CARD_CONTRACT.md`
+- `docs/MODEL_EXTRACTION_WORKFLOW.md`
+- `schemas/model_card.schema.json`
+- `schemas/model_index.schema.json`
+- `schemas/card_index.schema.json`
+- `models/model_index.json`
+- `cards/card_index.md`
+- `scripts/check_card_contract.py`
+- `scripts/run_selector_demo.py`
+- `tests/test_card_contract.py`
+- `reports/规则Schema工作流检查摘要_v0.1.md`
+
+Modified:
+
+- `README.md`
+- `docs/WORKFLOW.md`
+- `schemas/README.md`
+- `schemas/source_article.schema.json`
+- `schemas/source_excerpt.schema.json`
+- `schemas/regression_case.schema.json`
+- `scripts/README.md`
+- `scripts/validate_model_library.py`
+- `selector/README.md`
+- `models/README.md`
+- `cards/README.md`
+- `tests/test_validate_model_library.py`
+- `reports/validation_report.md`
+
+## Checks Run
+
+```powershell
+python -m unittest discover -s tests -p "test*.py" -v
+```
+
+Result:
+
+- PASS
+- 9 tests run.
+
+```powershell
+python scripts\check_card_contract.py
+```
+
+Result:
+
+- FAIL as expected.
+- Current `cards/qpi.md` and `cards/intellectual_archaeology.md` are still `draft_pre_contract` and do not yet contain all required headings.
+- `cards/README.md` is now ignored by the checker.
+
+```powershell
+python scripts\validate_model_library.py
+```
+
+Result:
+
+- FAIL as expected.
+- Current `models/qpi.model.json` and `models/intellectual_archaeology.model.json` are still `draft_pre_contract`.
+- Main failures are missing recommended/required GPT-plan fields, invalid enum values, invalid `selection_priority` range, and incomplete `stability_profile`.
+
+```powershell
+python scripts\run_selector_demo.py
+```
+
+Result:
+
+- PASS.
+- Demo outputs recommended model IDs, scores, reasons, and routing notes.
+- Scores are low because current model JSON has not yet been repaired with trigger keywords and 1-10 priority values.
+
+## Known Limits
+
+- `scripts/validate_model_library.py` implements the local schema subset required by current contracts. It does not implement a complete JSON Schema draft 2020-12 engine.
+- Current model/card content is intentionally not repaired in this pass.
+- `models/model_index.json` and `cards/card_index.md` mark both sample models as `draft_pre_contract`.
+- Selector demo works, but its output quality depends on model JSON fields that are not yet repaired.
+- `card_index.schema.json` defines card index metadata, but `cards/card_index.md` itself is Markdown and is checked by local tooling rather than full JSON Schema.
+
+## Owner Review Checklist
+
+- GPT 规划是否已正确本地化？
+- card contract 是否覆盖模型卡样例？
+- model schema 是否覆盖机器 JSON 样例？
+- index 设计是否满足当前和未来扩展？
+- 工作流 gate 是否足以防止直接跳内容？
+- 工具需求是否足够但不过度？
+- 是否接受 `tests/regression_cases.json` 继续作为合并式 regression case 文件？
+- 是否接受 `model_spec.schema.json` 暂时保留为 pre-contract legacy schema？
+
+## Do Not Proceed Before Owner Confirms
+
+Do not repair QPI or Intellectual Archaeology content until this foundation is reviewed or the owner explicitly authorizes content repair.

schemas/README.md

@@ -1,12 +1,17 @@
 # Schemas
 
-This folder will contain JSON Schema files for machine-readable project data.
+This folder contains JSON Schema files for machine-readable project data.
 
-Expected future files:
+Current files:
 
 - `model_card.schema.json`
+- `model_spec.schema.json`
 - `source_article.schema.json`
 - `source_excerpt.schema.json`
 - `regression_case.schema.json`
+- `model_index.schema.json`
+- `card_index.schema.json`
 
-Do not add schema complexity before the first two sample models are stable enough to validate.
+`model_card.schema.json` is the authoritative schema for machine-readable model cards.
+
+`model_spec.schema.json` is retained as a pre-contract draft schema until existing model files are migrated.

schemas/card_index.schema.json

@@ -0,0 +1,16 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Card Index Metadata",
+  "description": "人读模型卡索引元数据 schema。",
+  "type": "object",
+  "required": ["index_version", "last_updated", "required_columns"],
+  "properties": {
+    "index_version": {"type": "string", "description": "卡片索引版本。"},
+    "last_updated": {"type": "string", "description": "最后更新时间。"},
+    "required_columns": {
+      "type": "array",
+      "description": "card_index.md 表格必须包含的列名。",
+      "items": {"type": "string"}
+    }
+  }
+}

schemas/model_card.schema.json

@@ -0,0 +1,260 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Cognitive Model Card",
+  "description": "机器可读认知模型卡 schema。字段名使用英文，中文来源的字段值应保持中文。",
+  "type": "object",
+  "required": [
+    "model_id",
+    "model_name",
+    "model_type",
+    "pipeline_position",
+    "one_sentence_definition",
+    "core_question",
+    "core_mechanism",
+    "status",
+    "source_articles",
+    "source_evidence",
+    "input_types",
+    "output_types",
+    "call_when",
+    "do_not_call_when",
+    "trigger_keywords",
+    "negative_triggers",
+    "related_models",
+    "conflicting_models",
+    "disciplinary_anchors",
+    "common_misuses",
+    "failure_modes",
+    "selection_priority",
+    "confidence_level",
+    "stability_profile",
+    "regression_status",
+    "example_inputs",
+    "example_outputs",
+    "output_contract",
+    "productization_notes",
+    "version",
+    "last_updated"
+  ],
+  "properties": {
+    "model_id": {
+      "type": "string",
+      "description": "稳定机器 ID，供 JSON、证据、回归测试、selector 和索引引用。"
+    },
+    "model_name": {
+      "type": "string",
+      "description": "模型中文名称。"
+    },
+    "model_type": {
+      "type": "string",
+      "description": "模型类型。",
+      "enum": [
+        "routing_model",
+        "deep_modeling_model",
+        "lens_model",
+        "diagnostic_model",
+        "evaluation_model",
+        "generation_model",
+        "conflict_resolution_model",
+        "stabilization_model"
+      ]
+    },
+    "pipeline_position": {
+      "type": "string",
+      "description": "模型在处理流程中的位置。",
+      "enum": [
+        "pre_analysis",
+        "analysis",
+        "deep_analysis",
+        "synthesis",
+        "red_team",
+        "evaluation",
+        "post_processing"
+      ]
+    },
+    "one_sentence_definition": {
+      "type": "string",
+      "description": "一句话定义模型的用途和边界。"
+    },
+    "core_question": {
+      "type": "string",
+      "description": "模型主要回答的核心问题。"
+    },
+    "core_mechanism": {
+      "type": "string",
+      "description": "模型的核心运作机制。"
+    },
+    "status": {
+      "type": "string",
+      "description": "模型资产状态。状态升级必须由 owner / ChatGPT / CCRA 明确决定，不能由验证脚本自动升级。",
+      "enum": ["draft", "review", "reviewed", "callable", "stable", "archived", "deprecated", "draft_pre_contract"]
+    },
+    "source_articles": {
+      "type": "array",
+      "description": "引用的 source article ID 列表。",
+      "items": {"type": "string"}
+    },
+    "source_evidence": {
+      "type": "array",
+      "description": "引用的 source excerpt ID 列表。",
+      "items": {"type": "string"}
+    },
+    "input_types": {
+      "type": "array",
+      "description": "模型可接受的输入类型。",
+      "items": {"type": "string"}
+    },
+    "output_types": {
+      "type": "array",
+      "description": "模型应产出的输出类型。",
+      "items": {"type": "string"}
+    },
+    "call_when": {
+      "type": "array",
+      "description": "应调用该模型的场景。",
+      "items": {"type": "string"}
+    },
+    "do_not_call_when": {
+      "type": "array",
+      "description": "不应调用该模型的场景。",
+      "items": {"type": "string"}
+    },
+    "trigger_keywords": {
+      "type": "array",
+      "description": "提示可能调用该模型的关键词或表达。",
+      "items": {"type": "string"}
+    },
+    "negative_triggers": {
+      "type": "array",
+      "description": "提示不应调用该模型的关键词或表达。",
+      "items": {"type": "string"}
+    },
+    "related_models": {
+      "type": "array",
+      "description": "可前置、后置或并行调用的相关模型 ID。",
+      "items": {"type": "string"}
+    },
+    "conflicting_models": {
+      "type": "array",
+      "description": "可能与该模型冲突或需要仲裁的模型 ID。",
+      "items": {"type": "string"}
+    },
+    "disciplinary_anchors": {
+      "type": "array",
+      "description": "模型关联的学科、理论或知识底座。",
+      "items": {"type": "string"}
+    },
+    "common_misuses": {
+      "type": "array",
+      "description": "常见误用方式。",
+      "items": {"type": "string"}
+    },
+    "failure_modes": {
+      "type": "array",
+      "description": "调用失败或输出失稳的信号。",
+      "items": {"type": "string"}
+    },
+    "selection_priority": {
+      "type": "integer",
+      "description": "selector 选择优先级，范围 1-10。",
+      "minimum": 1,
+      "maximum": 10
+    },
+    "confidence_level": {
+      "type": "string",
+      "description": "当前可信度等级。",
+      "enum": ["high", "medium", "low"]
+    },
+    "stability_profile": {
+      "type": "object",
+      "description": "稳固性评估。",
+      "required": [
+        "stability_level",
+        "needs_stabilization",
+        "main_risks",
+        "reason",
+        "next_stabilization_action"
+      ],
+      "properties": {
+        "stability_level": {
+          "type": "string",
+          "description": "稳固性等级。",
+          "enum": ["A", "B", "C", "D"]
+        },
+        "needs_stabilization": {
+          "type": "boolean",
+          "description": "是否仍需要稳定化。"
+        },
+        "main_risks": {
+          "type": "array",
+          "description": "主要风险。",
+          "items": {"type": "string"}
+        },
+        "reason": {
+          "type": "string",
+          "description": "当前稳固性评级理由。"
+        },
+        "next_stabilization_action": {
+          "type": "string",
+          "description": "下一步稳定化动作。"
+        },
+        "stabilization_notes": {
+          "type": "string",
+          "description": "其他稳定化说明。"
+        }
+      }
+    },
+    "regression_status": {
+      "type": "string",
+      "description": "回归测试状态。",
+      "enum": [
+        "not_started",
+        "pending",
+        "in_progress",
+        "passed",
+        "failed",
+        "needs_rebuild"
+      ]
+    },
+    "example_inputs": {
+      "type": "array",
+      "description": "示例输入。",
+      "items": {"type": "string"}
+    },
+    "example_outputs": {
+      "type": "array",
+      "description": "示例输出。",
+      "items": {"type": "string"}
+    },
+    "output_contract": {
+      "type": "array",
+      "description": "输出必须包含的结构或要素。",
+      "items": {"type": "string"}
+    },
+    "structured_output_contract": {
+      "type": "object",
+      "description": "模型专属运行输出契约。该字段允许每个模型声明自己的 required runtime output fields；字段是否完整由本地 validator 的模型专属检查负责，不进入全局顶层 required。"
+    },
+    "depth_control": {
+      "type": "object",
+      "description": "深度控制、停止条件或过度调用警告。"
+    },
+    "stabilization_path": {
+      "type": "array",
+      "description": "稳定化路径。",
+      "items": {"type": "string"}
+    },
+    "productization_notes": {
+      "type": "string",
+      "description": "产品化、selector、workflow 或集成说明。"
+    },
+    "version": {
+      "type": "string",
+      "description": "模型卡版本。"
+    },
+    "last_updated": {
+      "type": "string",
+      "description": "最后更新日期。"
+    }
+  }
+}

schemas/model_index.schema.json

@@ -0,0 +1,48 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Model Index",
+  "description": "机器可读模型索引 schema。",
+  "type": "object",
+  "required": ["index_version", "last_updated", "models"],
+  "properties": {
+    "index_version": {"type": "string", "description": "索引版本。"},
+    "last_updated": {"type": "string", "description": "索引最后更新时间。"},
+    "models": {
+      "type": "array",
+      "description": "模型索引条目。",
+      "items": {
+        "type": "object",
+        "required": [
+          "model_id",
+          "model_name",
+          "model_type",
+          "pipeline_position",
+          "model_file",
+          "card_file",
+          "source_article_count",
+          "source_evidence_count",
+          "regression_case_count",
+          "stability_level",
+          "regression_status",
+          "status",
+          "last_updated"
+        ],
+        "properties": {
+          "model_id": {"type": "string", "description": "模型 ID。"},
+          "model_name": {"type": "string", "description": "模型中文名称。"},
+          "model_type": {"type": "string", "description": "模型类型。"},
+          "pipeline_position": {"type": "string", "description": "模型所在流程位置。"},
+          "model_file": {"type": "string", "description": "模型 JSON 文件路径。"},
+          "card_file": {"type": "string", "description": "Markdown 模型卡文件路径。"},
+          "source_article_count": {"type": "integer", "description": "引用来源文章数量。"},
+          "source_evidence_count": {"type": "integer", "description": "引用证据片段数量。"},
+          "regression_case_count": {"type": "integer", "description": "回归测试用例数量。"},
+          "stability_level": {"type": "string", "description": "稳固性等级。"},
+          "regression_status": {"type": "string", "description": "回归测试状态。"},
+          "status": {"type": "string", "description": "索引条目状态，例如 draft、active、deprecated、draft_pre_contract。"},
+          "last_updated": {"type": "string", "description": "模型 JSON 最后更新日期。"}
+        }
+      }
+    }
+  }
+}

schemas/model_spec.schema.json

@@ -0,0 +1,49 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Model Spec",
+  "type": "object",
+  "required": [
+    "model_id",
+    "model_name",
+    "model_type",
+    "pipeline_position",
+    "one_sentence_definition",
+    "core_question",
+    "core_mechanism",
+    "source_articles",
+    "source_evidence",
+    "input_types",
+    "output_types",
+    "call_when",
+    "do_not_call_when",
+    "common_misuses",
+    "failure_modes",
+    "selection_priority",
+    "confidence_level",
+    "stability_profile",
+    "regression_status",
+    "productization_notes"
+  ],
+  "properties": {
+    "model_id": {"type": "string"},
+    "model_name": {"type": "string"},
+    "model_type": {"type": "string"},
+    "pipeline_position": {"type": "string"},
+    "one_sentence_definition": {"type": "string"},
+    "core_question": {"type": "string"},
+    "core_mechanism": {"type": "string"},
+    "source_articles": {"type": "array", "items": {"type": "string"}},
+    "source_evidence": {"type": "array", "items": {"type": "string"}},
+    "input_types": {"type": "array", "items": {"type": "string"}},
+    "output_types": {"type": "array", "items": {"type": "string"}},
+    "call_when": {"type": "array", "items": {"type": "string"}},
+    "do_not_call_when": {"type": "array", "items": {"type": "string"}},
+    "common_misuses": {"type": "array", "items": {"type": "string"}},
+    "failure_modes": {"type": "array", "items": {"type": "string"}},
+    "selection_priority": {"type": "integer"},
+    "confidence_level": {"type": "string"},
+    "stability_profile": {"type": "object"},
+    "regression_status": {"type": "string"},
+    "productization_notes": {"type": "array", "items": {"type": "string"}}
+  }
+}

schemas/regression_case.schema.json

@@ -0,0 +1,53 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Regression Case",
+  "description": "认知模型回归测试用例 schema。",
+  "type": "object",
+  "required": [
+    "case_id",
+    "model_id",
+    "case_type",
+    "input",
+    "expected_behavior",
+    "failure_signal"
+  ],
+  "properties": {
+    "case_id": {"type": "string", "description": "测试用例 ID。"},
+    "model_id": {"type": "string", "description": "被测试模型 ID。"},
+    "case_type": {
+      "type": "string",
+      "description": "用例类型。",
+      "enum": ["positive", "boundary", "misuse", "no_call", "selector_gate", "pipeline"]
+    },
+    "input": {"type": "string", "description": "测试输入。"},
+    "expected_behavior": {"type": "string", "description": "期望行为。"},
+    "failure_signal": {"type": "string", "description": "失败信号。"},
+    "expected_output_elements": {"type": "array", "description": "期望输出包含的要素。", "items": {"type": "string"}},
+    "should_call_model": {"type": "boolean", "description": "该模型是否应该被调用。"},
+    "expected_primary_model": {"type": "string", "description": "期望首选模型 ID。"},
+    "negative_expected_models": {"type": "array", "description": "不应被召回的模型 ID。", "items": {"type": "string"}},
+    "expected_classification": {
+      "type": "string",
+      "description": "QPI 分类期望。",
+      "enum": ["question", "problem", "issue", "mixed", "no_call", "not_applicable"]
+    },
+    "expected_dominant_scarcity": {
+      "type": "string",
+      "description": "期望主导匮乏物。",
+      "enum": ["data", "path_resource", "consensus_order", "mixed", "unknown", "not_applicable"]
+    },
+    "expected_max_depth": {
+      "type": "string",
+      "description": "思想考古期望最大下潜层级。",
+      "enum": ["application", "domain", "process", "purpose", "core_mechanism", "human_capability", "philosophical_bedrock", "no_call", "not_applicable"]
+    },
+    "minimum_required_elements": {"type": "array", "description": "必须出现的输出元素。", "items": {"type": "string"}},
+    "forbidden_elements": {"type": "array", "description": "不应出现的输出元素。", "items": {"type": "string"}},
+    "evaluation_mode": {
+      "type": "string",
+      "description": "评估模式。",
+      "enum": ["manual", "keyword", "structured", "semantic"]
+    },
+    "notes": {"type": "string", "description": "补充说明。"}
+  }
+}

schemas/source_article.schema.json

@@ -0,0 +1,32 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Source Article",
+  "description": "来源文章记录 schema。",
+  "type": "object",
+  "required": [
+    "source_id",
+    "title",
+    "source_type",
+    "related_models",
+    "source_status"
+  ],
+  "properties": {
+    "source_id": {"type": "string", "description": "来源文章 ID。"},
+    "title": {"type": "string", "description": "来源标题。"},
+    "source_type": {
+      "type": "string",
+      "description": "来源类型。",
+      "enum": ["original_article", "synthesis_note", "placeholder"]
+    },
+    "related_models": {"type": "array", "description": "关联模型 ID 列表。", "items": {"type": "string"}},
+    "source_status": {
+      "type": "string",
+      "description": "来源状态。",
+      "enum": ["representative", "derived_synthesis", "placeholder"]
+    },
+    "author": {"type": "string", "description": "作者。"},
+    "date": {"type": "string", "description": "来源日期。"},
+    "file_path": {"type": "string", "description": "本地来源路径。"},
+    "notes": {"type": "string", "description": "补充说明。"}
+  }
+}

schemas/source_excerpt.schema.json

@@ -0,0 +1,37 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Source Excerpt",
+  "description": "来源证据片段 schema。",
+  "type": "object",
+  "required": [
+    "excerpt_id",
+    "source_id",
+    "related_model_id",
+    "excerpt_type",
+    "summary",
+    "used_for",
+    "quote_status",
+    "source_location"
+  ],
+  "properties": {
+    "excerpt_id": {"type": "string", "description": "证据片段 ID。"},
+    "source_id": {"type": "string", "description": "所属来源文章 ID。"},
+    "related_model_id": {"type": "string", "description": "关联模型 ID。"},
+    "excerpt_type": {
+      "type": "string",
+      "description": "证据类型。",
+      "enum": ["definition", "taxonomy", "mechanism", "application_rule", "value_claim", "boundary_rule", "validation_rule"]
+    },
+    "summary": {"type": "string", "description": "证据片段摘要。"},
+    "used_for": {"type": "array", "description": "该证据支撑的模型字段或用途。", "items": {"type": "string"}},
+    "quote_status": {
+      "type": "string",
+      "description": "raw_excerpt 的摘录状态。exact 表示准确摘录；condensed 表示压缩摘录；paraphrased 表示转述。",
+      "enum": ["exact", "condensed", "paraphrased"]
+    },
+    "raw_excerpt": {"type": "string", "description": "原文摘录、压缩摘录、转述或明确标注的 placeholder。"},
+    "source_location": {"type": "string", "description": "章节、段落、标题或行号；未知则写 unknown。"},
+    "confidence": {"type": "string", "description": "证据可信度。", "enum": ["high", "medium", "low"]},
+    "notes": {"type": "string", "description": "补充说明。"}
+  }
+}

scripts/README.md

@@ -1,12 +1,50 @@
 # Scripts
 
-This folder will contain simple local scripts for validation and selector demos.
+This folder contains simple local scripts for validation and selector demos.
 
-Expected future scripts:
+Current script:
 
-- `validate_models.py`
+- `validate_model_library.py`
-- `validate_sources.py`
+- `check_card_contract.py`
-- `validate_tests.py`
+- `rebuild_indexes.py`
+- `check_model_card_sync.py`
+- `run_selector_regression.py`
 - `run_selector_demo.py`
 
+Run:
+
+```powershell
+python scripts\validate_model_library.py
+```
+
+The script checks JSON parsing, required model fields, unique IDs, source references, excerpt references, regression case model references, and model/card index drift. It writes `reports/validation_report.md`.
+
+Rebuild or check model/card indexes:
+
+```powershell
+python scripts\rebuild_indexes.py --write
+python scripts\rebuild_indexes.py --check
+```
+
+The index script regenerates `models/model_index.json` and `cards/card_index.md` from model JSON, card files, and regression cases. It writes `reports/index_rebuild_report.md`.
+
+Run the card contract checker:
+
+```powershell
+python scripts\check_card_contract.py
+```
+
+Run the selector demo:
+
+```powershell
+python scripts\run_selector_demo.py
+```
+
+Run selector regression and model/card sync checks:
+
+```powershell
+python scripts\run_selector_regression.py
+python scripts\check_model_card_sync.py
+```
+
 Prefer Python standard library before adding dependencies.

scripts/check_card_contract.py

@@ -0,0 +1,72 @@
+import re
+import sys
+from pathlib import Path
+
+
+def required_headings(root):
+    contract_path = Path(root) / "docs" / "MODEL_CARD_CONTRACT.md"
+    if not contract_path.exists():
+        return [], [f"missing file {contract_path.as_posix()}"]
+
+    headings = []
+    in_required_sections = False
+    for line in contract_path.read_text(encoding="utf-8").splitlines():
+        if line.strip() == "## Required Sections":
+            in_required_sections = True
+            continue
+        if in_required_sections and line.startswith("## "):
+            title = line[3:].strip()
+            if title and title not in {"Additional Sections"}:
+                headings.append(title)
+        if in_required_sections and line.strip() == "## Additional Sections":
+            break
+    return headings, []
+
+
+def card_headings(path):
+    headings = set()
+    for line in path.read_text(encoding="utf-8").splitlines():
+        match = re.match(r"^##\s+(.+?)\s*$", line)
+        if match:
+            headings.add(match.group(1).strip())
+    return headings
+
+
+def check_cards(root):
+    root = Path(root)
+    headings, errors = required_headings(root)
+    if errors:
+        return errors
+
+    cards_dir = root / "cards"
+    if not cards_dir.exists():
+        return ["missing directory cards"]
+
+    ignored_names = {"README.md", "card_index.md"}
+    card_paths = sorted(path for path in cards_dir.glob("*.md") if path.name not in ignored_names)
+    if not card_paths:
+        return ["cards/ contains no Markdown model cards"]
+
+    results = []
+    for path in card_paths:
+        present = card_headings(path)
+        relative_path = path.relative_to(root).as_posix()
+        for heading in headings:
+            if heading not in present:
+                results.append(f"{relative_path} missing required heading ## {heading}")
+    return results
+
+
+def main():
+    root = Path(__file__).resolve().parents[1]
+    errors = check_cards(root)
+    if errors:
+        for error in errors:
+            print(f"ERROR: {error}")
+        return 1
+    print("card contract check passed")
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())

scripts/check_model_card_sync.py

@@ -0,0 +1,131 @@
+import json
+import sys
+from pathlib import Path
+
+
+KEY_CONTRACT_TERMS = {
+    "qpi": [
+        "problem_owner",
+        "time_scale",
+        "dominant_scarcity",
+        "evidence_gap",
+        "classification",
+        "no_call"
+    ],
+    "intellectual_archaeology": [
+        "should_call",
+        "recommended_max_depth",
+        "stop_reason",
+        "no_deeper_reason",
+        "validation_needed",
+        "action_implication"
+    ]
+}
+
+
+def read_json(path):
+    return json.loads(path.read_text(encoding="utf-8"))
+
+
+def card_path_for_model(root, model_id):
+    return root / "cards" / f"{model_id}.md"
+
+
+def check_model_card(root, model_path):
+    model = read_json(model_path)
+    model_id = model["model_id"]
+    card_path = card_path_for_model(root, model_id)
+    errors = []
+    manual_review = []
+
+    if not card_path.exists():
+        return [f"missing card {card_path.relative_to(root).as_posix()}"], []
+
+    text = card_path.read_text(encoding="utf-8")
+    hard_values = [
+        model_id,
+        model["model_name"],
+        model["model_type"],
+        model["pipeline_position"],
+        model["regression_status"],
+        model["version"],
+        model["last_updated"],
+        model.get("status", "")
+    ]
+    stability_level = model.get("stability_profile", {}).get("stability_level")
+    if stability_level:
+        hard_values.append(stability_level)
+
+    for value in hard_values:
+        if value and value not in text:
+            errors.append(f"{model_id} card missing hard value {value}")
+
+    for source_id in model.get("source_articles", []):
+        if source_id not in text:
+            errors.append(f"{model_id} card missing source article {source_id}")
+
+    for excerpt_id in model.get("source_evidence", []):
+        if excerpt_id not in text:
+            errors.append(f"{model_id} card missing source evidence {excerpt_id}")
+
+    for term in KEY_CONTRACT_TERMS.get(model_id, []):
+        if term not in text:
+            errors.append(f"{model_id} card missing key contract term {term}")
+
+    manual_review.append(f"{model_id}: long Chinese definitions, examples, and risk notes require human semantic review.")
+    return errors, manual_review
+
+
+def write_report(root, errors, manual_review):
+    report_path = root / "reports" / "model_card_sync_report_v0.2.md"
+    lines = [
+        "# Model Card Sync Report v0.2",
+        "",
+        f"Status: `{'PASS' if not errors else 'FAIL'}`",
+        "",
+    ]
+    if errors:
+        lines.append("## Errors")
+        lines.append("")
+        lines.extend(f"- {error}" for error in errors)
+        lines.append("")
+    else:
+        lines.append("## Hard-Field Result")
+        lines.append("")
+        lines.append("- Model IDs, names, types, pipeline positions, source IDs, evidence IDs, stability fields, regression status, version, and last_updated are present in Markdown cards.")
+        lines.append("- Key output contract and depth-control terms are present.")
+        lines.append("")
+
+    lines.append("## Manual Review Items")
+    lines.append("")
+    lines.extend(f"- {item}" for item in manual_review)
+    report_path.write_text("\n".join(lines) + "\n", encoding="utf-8")
+    return report_path
+
+
+def check_sync(root):
+    root = Path(root)
+    errors = []
+    manual_review = []
+    for model_path in sorted((root / "models").glob("*.model.json")):
+        model_errors, model_manual_review = check_model_card(root, model_path)
+        errors.extend(model_errors)
+        manual_review.extend(model_manual_review)
+    report_path = write_report(root, errors, manual_review)
+    return errors, report_path
+
+
+def main():
+    root = Path(__file__).resolve().parents[1]
+    errors, report_path = check_sync(root)
+    print(f"model/card sync report written to {report_path}")
+    if errors:
+        for error in errors:
+            print(f"ERROR: {error}")
+        return 1
+    print("model/card sync passed")
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())

scripts/rebuild_indexes.py

@@ -0,0 +1,183 @@
+import argparse
+import json
+import sys
+from dataclasses import dataclass
+from datetime import date
+from pathlib import Path
+
+
+IGNORED_CARD_NAMES = {"README.md", "card_index.md"}
+
+
+@dataclass
+class RebuildResult:
+    drift_found: bool
+    differences: list
+    report_path: Path
+
+
+def read_json(path):
+    return json.loads(path.read_text(encoding="utf-8"))
+
+
+def write_text(path, text):
+    path.parent.mkdir(parents=True, exist_ok=True)
+    path.write_text(text, encoding="utf-8")
+
+
+def regression_case_counts(root):
+    path = root / "tests" / "regression_cases.json"
+    if not path.exists():
+        return {}
+    data = read_json(path)
+    counts = {}
+    for case in data.get("regression_cases", []):
+        model_id = case.get("model_id")
+        if model_id:
+            counts[model_id] = counts.get(model_id, 0) + 1
+    return counts
+
+
+def card_path_for_model(root, model_id):
+    path = root / "cards" / f"{model_id}.md"
+    if path.exists():
+        return path.relative_to(root).as_posix()
+    return f"cards/{model_id}.md"
+
+
+def existing_index_version(root):
+    path = root / "models" / "model_index.json"
+    if not path.exists():
+        return "0.1"
+    try:
+        data = read_json(path)
+    except json.JSONDecodeError:
+        return "0.1"
+    return data.get("index_version", "0.1")
+
+
+def build_model_index(root):
+    counts = regression_case_counts(root)
+    models = []
+    for model_path in sorted((root / "models").glob("*.model.json")):
+        model = read_json(model_path)
+        model_id = model["model_id"]
+        models.append({
+            "model_id": model_id,
+            "model_name": model["model_name"],
+            "model_type": model["model_type"],
+            "pipeline_position": model["pipeline_position"],
+            "model_file": model_path.relative_to(root).as_posix(),
+            "card_file": card_path_for_model(root, model_id),
+            "source_article_count": len(model.get("source_articles", [])),
+            "source_evidence_count": len(model.get("source_evidence", [])),
+            "regression_case_count": counts.get(model_id, 0),
+            "stability_level": model.get("stability_profile", {}).get("stability_level"),
+            "regression_status": model.get("regression_status"),
+            "status": model.get("status"),
+            "last_updated": model.get("last_updated")
+        })
+
+    return {
+        "index_version": existing_index_version(root),
+        "last_updated": date.today().isoformat(),
+        "models": sorted(models, key=lambda item: item["model_id"])
+    }
+
+
+def render_json(data):
+    return json.dumps(data, ensure_ascii=False, indent=2) + "\n"
+
+
+def render_card_index(model_index):
+    lines = [
+        "# Card Index",
+        "",
+        "| Model ID | 模型名称 | 类型 | 流程位置 | Card | Model JSON | 稳固性 | 回归状态 | 状态 |",
+        "| --- | --- | --- | --- | --- | --- | --- | --- | --- |",
+    ]
+    for entry in model_index["models"]:
+        lines.append(
+            "| {model_id} | {model_name} | {model_type} | {pipeline_position} | "
+            "`{card_file}` | `{model_file}` | {stability_level} | {regression_status} | {status} |".format(**entry)
+        )
+    return "\n".join(lines) + "\n"
+
+
+def collect_differences(root, expected_model_index_text, expected_card_index_text):
+    checks = [
+        (root / "models" / "model_index.json", expected_model_index_text, "models/model_index.json"),
+        (root / "cards" / "card_index.md", expected_card_index_text, "cards/card_index.md"),
+    ]
+    differences = []
+    for path, expected_text, label in checks:
+        if not path.exists():
+            differences.append(f"{label} is missing")
+            continue
+        actual_text = path.read_text(encoding="utf-8")
+        if actual_text != expected_text:
+            differences.append(f"{label} differs from generated index")
+    return differences
+
+
+def write_report(root, mode, differences):
+    report_path = root / "reports" / "index_rebuild_report.md"
+    lines = [
+        "# Index Rebuild Report",
+        "",
+        f"Mode: `{mode}`",
+        f"Status: `{'DRIFT' if differences else 'PASS'}`",
+        "",
+    ]
+    if differences:
+        lines.append("## Differences")
+        lines.append("")
+        lines.extend(f"- {difference}" for difference in differences)
+    else:
+        lines.append("## Result")
+        lines.append("")
+        lines.append("- models/model_index.json matches generated model registry.")
+        lines.append("- cards/card_index.md matches generated card index.")
+    write_text(report_path, "\n".join(lines) + "\n")
+    return report_path
+
+
+def rebuild_indexes(root, write=False):
+    root = Path(root)
+    model_index = build_model_index(root)
+    model_index_text = render_json(model_index)
+    card_index_text = render_card_index(model_index)
+
+    if write:
+        write_text(root / "models" / "model_index.json", model_index_text)
+        write_text(root / "cards" / "card_index.md", card_index_text)
+        differences = []
+        mode = "write"
+    else:
+        differences = collect_differences(root, model_index_text, card_index_text)
+        mode = "check"
+
+    report_path = write_report(root, mode, differences)
+    return RebuildResult(bool(differences), differences, report_path)
+
+
+def main():
+    parser = argparse.ArgumentParser(description="Rebuild or check model and card indexes.")
+    group = parser.add_mutually_exclusive_group(required=True)
+    group.add_argument("--check", action="store_true", help="Check generated indexes against files without writing them.")
+    group.add_argument("--write", action="store_true", help="Write generated indexes to disk.")
+    args = parser.parse_args()
+
+    root = Path(__file__).resolve().parents[1]
+    result = rebuild_indexes(root, write=args.write)
+    print(f"index rebuild report written to {result.report_path}")
+    if result.drift_found:
+        for difference in result.differences:
+            print(f"DRIFT: {difference}")
+        return 1
+    print("index check passed")
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())