# 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.json` - `cards/.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/_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.