11 KiB
Model Index Rules
1. Purpose
This file defines how CCPE Forge should create, audit, and maintain the Model Index.
The Model Index organizes the user's model library.
It is necessary when the user has many cognitive models extracted from articles, prompts, discussions, and agent designs.
2. What the Model Index Is
The Model Index is the map of the model library.
It tracks:
What models exist
Where they came from
What type they are
How they relate to each other
Which agents use them
Which skills execute them
Which runtimes orchestrate them
Which models are active, candidate, deprecated, or merged
The Model Index does not replace Model Cards.
It points to them.
3. Model Index Core Files
The model index should include:
model-index.md
model-taxonomy.md
model-dependency-map.md
model-usage-map.md
extraction-log.md
4. File Purposes
4.1 model-index.md
The main table of models.
It should include all known models and candidate models.
4.2 model-taxonomy.md
The classification system for models.
It defines categories such as foundational, intermediate, applied, workflow, and implicit extracted.
4.3 model-dependency-map.md
Tracks model relationships.
Examples:
Parent model
Child model
Prerequisite model
Derived model
Overlapping model
Conflicting model
Merged model
Deprecated successor
4.4 model-usage-map.md
Tracks where models are used.
Examples:
Agents
Skills
Runtimes
Prompt Cards
Committees
Knowledge workflows
4.5 extraction-log.md
Tracks model extraction events.
Examples:
Source article
Extraction date
Extracted models
Confidence
Review status
Open questions
Next action
5. Model Index Entry Fields
Each model index entry should include:
Model ID
Model Name
Aliases
Model Type
Layer
Status
Canonical Path
Source Material
Parent Models
Child Models
Related Models
Conflicting Models
Related Agents
Related Skills
Related Runtimes
Usage Notes
Review Status
Last Updated
6. Model ID
Use a stable kebab-case ID.
Example:
cognitive-imaging
giant-cognition
cognitive-prism
prediction-error-capture
argument-compression
Do not use vague IDs like:
model-1
thinking-model
good-model
7. Model Name
Use the canonical name.
Bilingual names are encouraged when useful.
Example:
认知显影术 / Cognitive Imaging
8. Aliases
Aliases help connect older documents.
Include:
Chinese name
English name
Former names
Working titles
Article-specific labels
Prompt-specific labels
9. Model Type
Use one or more:
foundational
intermediate
applied
workflow-model
implicit-extracted
candidate
deprecated
10. Layer
Layer describes the model's position in the model ecology.
Recommended values:
L0: Foundational Assumption
L1: Foundational Model
L2: Intermediate Model
L3: Applied Model
L4: Workflow / Procedure Model
L5: Output / Evaluation Lens
Example:
Cognitive Imaging = L2 Intermediate Model + L4 Workflow Model
11. Status
Use:
candidate
draft
active
rejected
merged
deprecated
archived
Default for newly extracted implicit models:
candidate
Default for structurally clear but unconfirmed models:
draft
Use active only after user confirmation.
12. Canonical Path
The canonical path points to the Model Card.
Example:
model-cards/intermediate/cognitive-imaging-model.md
For candidate models without full cards, use:
TBD
13. Source Material
Record source.
Examples:
Article title
File path
Prompt name
Conversation summary
Agent appendix
If multiple sources exist, list all important sources.
14. Parent Models
Parent models are models that provide assumptions or mechanisms.
Example:
Cognitive Imaging may depend on:
- Prediction Error
- Algorithmic Compression
- Complex Adaptive Systems
- Causal Intervention
15. Child Models
Child models are derived or applied from this model.
Example:
Cognitive Imaging may produce:
- Prediction Error Capture Skill
- Do-Operator Testing Skill
- Conspiracy Breaker Check
16. Related Models
Related models are nearby but not parent/child.
Examples:
Cognitive Prism
Giant Cognition
Systems Thinking
Argument Compression
17. Conflicting Models
Conflicting models are models with incompatible assumptions or opposite guidance.
Use this carefully.
A model is not conflicting just because it is different.
Conflict requires actual contradiction.
18. Related Agents
List agents that use the model.
Example:
cognitive-imaging-specialist.agent.md
review-committee-chair.agent.md
19. Related Skills
List skills that execute or support the model.
Example:
cognitive-imaging.skill.md
do-operator-test.skill.md
prediction-error-capture.skill.md
20. Related Runtimes
List workflows that use the model.
Example:
review-committee.runtime.md
modeling-committee.runtime.md
article-to-model-extraction.runtime.md
21. Usage Notes
Usage notes explain how the model should be used.
Examples:
Use for complex adaptive systems.
Avoid using for simple linear troubleshooting.
Best used in depth-oriented review workflows.
Can be called by multiple critique agents.
22. Review Status
Review Status may differ from Status.
Use it to indicate process state:
needs-source-check
needs-user-confirmation
needs-scope-review
needs-falsification-boundary
needs-merge-review
reviewed
23. Last Updated
Use ISO date format:
YYYY-MM-DD
Do not invent dates if unknown. Use:
unknown
or leave blank if the system convention allows.
24. Model Taxonomy Rules
The taxonomy should not be too flat.
Use at least:
Foundational Models
Intermediate Models
Applied Models
Workflow Models
Implicit Extracted Models
Deprecated / Archived Models
Optional additional categories:
Causal Models
Cognitive Models
Writing Models
Review Models
Strategy Models
Knowledge Management Models
Agent Design Models
Evaluation Models
25. Dependency Mapping Rules
Dependency mapping should answer:
Which models depend on which assumptions?
Which models are applications of deeper models?
Which models overlap?
Which models should not be used together?
Which models have been merged?
Use structured bullets first.
Do not require graphical diagrams in the first version.
26. Usage Mapping Rules
Usage mapping should answer:
Which Agents use this model?
Which Skills execute this model?
Which Runtimes orchestrate this model?
Which Prompt Cards embed this model?
Which committees use this model?
This makes model maintenance possible.
If a model changes, usage mapping shows what must be updated.
27. Extraction Log Rules
Each extraction log entry should include:
Date
Source
Extractor
Models extracted
Confidence
Status
Open questions
Next action
Example:
## 2026-05-31 - Source: article-title.md
- Extracted:
- cognitive-imaging - high confidence - draft
- prediction-error-capture - medium confidence - candidate
- Open questions:
- Should prediction-error-capture be a separate model or Skill?
- Next action:
- User review before Model Index promotion.
28. Candidate Model Handling
Candidate models should be visible but not treated as canonical.
Rules:
Put candidate models in Model Index.
Mark status as candidate.
Mark confidence.
Record extraction basis.
Ask for user review.
Do not build major Agents or Skills on weak candidates without warning.
29. Active Model Handling
Active models require:
User confirmation
Model Card
Scope
Core mechanism
Failure modes
Falsification boundary
Model Index entry
Usage map if used by Agents or Skills
30. Deprecated Model Handling
Deprecated models should remain traceable.
Rules:
Mark status as deprecated.
Explain why.
Point to successor if any.
Do not delete immediately.
Update usage map to show affected Agents or Skills.
31. Merged Model Handling
When models are merged:
Mark old model as merged.
Point to canonical successor.
Explain merge reason.
Update related Agents and Skills.
Update dependency map.
32. Model Index Table Format
Use this format in model-index.md:
| Model ID | Model Name | Type | Layer | Status | Canonical Path | Source | Related Agents | Related Skills | Review Status |
|---|---|---|---|---|---|---|---|---|---|
| cognitive-imaging | 认知显影术 / Cognitive Imaging | intermediate; workflow-model | L2; L4 | draft | model-cards/intermediate/cognitive-imaging-model.md | TBD | cognitive-imaging-specialist | cognitive-imaging | needs-user-confirmation |
33. Model Taxonomy Format
Use this format in model-taxonomy.md:
# Model Taxonomy
## Foundational Models
## Intermediate Models
## Applied Models
## Workflow Models
## Implicit Extracted Models
## Deprecated / Archived Models
34. Dependency Map Format
Use this format in model-dependency-map.md:
# Model Dependency Map
## cognitive-imaging
### Parent Models
- prediction-error
- algorithmic-compression
- causal-intervention
- complex-adaptive-systems
### Child Models / Derived Skills
- prediction-error-capture
- do-operator-test
- conspiracy-breaker-check
### Related Models
- cognitive-prism
- giant-cognition
### Conflicts / Tensions
- TBD
35. Usage Map Format
Use this format in model-usage-map.md:
# Model Usage Map
## cognitive-imaging
### Agents
- cognitive-imaging-specialist.agent.md
### Skills
- cognitive-imaging.skill.md
### Runtimes
- review-committee.runtime.md
### Prompt Cards
- cognitive-imaging-specialist.prompt.md
### Notes
- Best used in depth-oriented review and complex systems analysis.
36. Model Index Quality Checklist
Before updating Model Index, check:
Is the model ID stable?
Is the model type correct?
Is the status correct?
Is the canonical path known?
Is the source recorded?
Are related models identified?
Are related agents and skills identified?
Is review status clear?
Is user confirmation needed?
37. Promotion Rules
Candidate 鈫?Draft when:
Model structure is clear.
Source is identified.
Scope and mechanism are present.
Draft 鈫?Active when:
User confirms the model.
Model Card exists.
Falsification boundary exists.
Index entry exists.
Usage mapping is updated.
Active 鈫?Deprecated when:
User rejects it.
It is superseded.
It merges into another model.
It is no longer useful.
38. Final Rule
The Model Index is not just a list.
It is the control panel for the user's cognitive model library.
It should help answer:
What models do I have?
Which ones matter most?
Which ones depend on which?
Which ones are reusable?
Which agents use them?
Which skills execute them?
Which ones need review?