175 lines
5.5 KiB
Markdown
175 lines
5.5 KiB
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.
|
|
|
|
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.
|