13 KiB
Model Card Rules
1. Purpose
This file defines how CCPE Forge should create, audit, and maintain Model Cards.
A Model Card is the canonical description of a single cognitive model.
It should preserve the model as an independent intellectual asset, separate from any one Agent, Skill, or Runtime.
2. What a Model Card Is
A Model Card describes a reusable cognitive structure.
It captures:
What problem the model addresses
What assumptions it makes
What mechanism it proposes
Where it applies
Where it fails
How it can be used
How it can be tested
Which Agents, Skills, or Runtimes use it
A Model Card is not a persona.
A Model Card is not just a summary.
A Model Card is not merely a metaphor.
A Model Card is not automatically a Skill.
A Model Card is the model's source of truth.
3. When to Create a Model Card
Create or recommend a Model Card when an artifact contains a model that:
Has independent explanatory or generative value
Can be reused across multiple agents or skills
Comes from long-form writing
Has identifiable assumptions
Has a mechanism
Has a scope
Has failure modes
Can define a falsification boundary
May become part of a model library
4. When Not to Create a Model Card
Do not create a Model Card for:
A single claim
A slogan
A mood
A style preference
A loose metaphor without mechanism
A list of advice
A generic checklist
A temporary task procedure
An isolated example
A personal opinion without reusable structure
If uncertain, mark it as:
Candidate Model
rather than promoting it to a canonical Model Card.
5. Model Card vs Other CCPE Artifacts
5.1 Model Card vs Agent
A Model Card defines the model.
An Agent uses the model.
Example:
Cognitive Imaging Model Card:
Defines Capture, Darkroom, Enlarger, Exposure, Development as a model.
Cognitive Imaging Specialist Agent:
Uses the model in interaction with the user.
5.2 Model Card vs Skill
A Model Card explains the structure.
A Skill executes a procedure.
Example:
Cognitive Imaging Model:
The theory and generative mechanism.
Cognitive Imaging Skill:
A callable procedure that applies the model to user input and produces a report.
5.3 Model Card vs Runtime
A Model Card defines a model.
A Runtime orchestrates work.
Example:
Modeling Committee Runtime may orchestrate several agents and skills,
some of which use Cognitive Imaging, Giant Cognition, or Cognitive Prism models.
5.4 Model Card vs Model Index
A Model Card is one model.
A Model Index organizes many models.
The Model Card is the detailed record.
The Model Index is the map.
6. Canonical Model Card Structure
Use this structure for full Model Cards:
---
artifact_type: model-card
model_name:
aliases:
author:
version:
created:
updated:
status: candidate
source_material:
model_type:
related_models:
related_agents:
related_skills:
related_runtimes:
---
# {Model Name}
## 1. Model Overview
## 2. Source Material
## 3. Core Problem
## 4. Scope
## 5. Non-Scope
## 6. Core Assumptions
## 7. Core Mechanism
## 8. Procedure / Operating Logic
## 9. Inputs
## 10. Outputs
## 11. Failure Modes
## 12. Falsification Boundary
## 13. Distinctions
## 14. Related Models
## 15. Related Agents
## 16. Related Skills
## 17. Runtime Usage
## 18. Examples
## 19. Evaluation Criteria
## 20. Version Notes
## 21. Open Questions
7. Required Fields
Every Model Card should include at minimum:
Model Name
Source Material
Model Type
Core Problem
Scope
Core Assumptions
Core Mechanism
Failure Modes
Falsification Boundary
Status
A Model Card without mechanism is weak.
A Model Card without scope is dangerous.
A Model Card without failure mode tends to become ideology.
A Model Card without falsification boundary tends to become unfalsifiable explanatory fog.
8. Model Name
The model name should be stable, memorable, and specific.
If the user already has a name, preserve it unless there is a strong reason not to.
Use bilingual names when helpful:
认知显影术 / Cognitive Imaging
巨人认知 / Giant Cognition
认知棱镜 / Cognitive Prism
For implicit extracted models, mark the name as provisional:
Provisional Name:
9. Aliases
Aliases may include:
Chinese name
English name
Short name
Former name
Working title
Related phrase used in source material
Aliases help link old articles, prompts, and discussions.
10. Source Material
Record the source of the model.
Possible sources:
Article
Essay
Prompt appendix
Agent description
Conversation
Note
Lecture
Research draft
Knowledge base document
Include:
Title
Path
Date
Author
Relevant sections
Extraction notes
If source is unknown, mark:
source_material: unknown
Do not invent source metadata.
11. Model Type
Use one or more:
foundational
intermediate
applied
workflow-model
implicit-extracted
candidate
deprecated
Definitions:
foundational:
A deep model that supports many others.
intermediate:
A mid-level model that structures a domain or reasoning pattern.
applied:
A model designed for a specific practical use.
workflow-model:
A model that naturally becomes a repeatable process.
implicit-extracted:
A model inferred from writing rather than explicitly named.
candidate:
A possible model requiring review.
deprecated:
A model no longer recommended as canonical.
12. Status
Use:
candidate
draft
active
rejected
merged
deprecated
archived
Default status for extracted models should be:
candidate
or:
draft
Only use active after user confirmation.
13. Core Problem
The Core Problem defines what the model is trying to solve.
Good Core Problem examples:
How to identify generative structure inside complex adaptive systems.
How to distinguish real causal generators from surface correlations.
How to compress a long conceptual field into a usable explanatory algorithm.
Bad Core Problem examples:
Think better.
Analyze things.
Understand cognition.
Improve writing.
The Core Problem should be specific enough to shape the model.
14. Scope
Scope defines where the model applies.
Include:
Domain
Task type
Input type
Environmental assumptions
User goal
Level of uncertainty
Example:
Applies to complex adaptive systems, unfamiliar domains, low-feedback environments,
and cases where linear intuition is likely to fail.
15. Non-Scope
Non-Scope defines where the model should not be used.
This prevents overgeneralization.
Example:
Not intended for high-repetition, high-feedback expert tasks where trained intuition is more reliable,
such as routine surgical procedures or standard mechanical troubleshooting.
16. Core Assumptions
Core Assumptions define the model's foundation.
Good assumptions are:
Explicit
Limited
Mechanism-related
Testable or at least challengeable
Avoid vague universal statements.
Example:
Insight begins when prediction error is not immediately normalized by existing theory.
17. Core Mechanism
The Core Mechanism is the heart of the Model Card.
It should explain how the model generates insight or explanation.
Ask:
What moves?
What transforms?
What causes what?
What filters what?
What compresses what?
What predicts what?
What breaks if the mechanism is wrong?
A model without mechanism is usually just a theme.
18. Procedure / Operating Logic
If the model has steps, define them.
Example:
1. Capture prediction error.
2. Suspend premature interpretation.
3. Apply multiple disciplinary filters.
4. Test causal generators through intervention.
5. Compress the surviving structure into a falsifiable algorithm.
If the model has no fixed procedure, define operating logic instead.
19. Inputs
Define what the model can receive.
Examples:
Article
Argument
Phenomenon
Strategic situation
System behavior
Draft model
User question
Research notes
20. Outputs
Define what the model produces.
Examples:
Insight report
Core mechanism
Causal generator
Failure boundary
Question list
Model compression
Risk diagnosis
Reframed hypothesis
21. Failure Modes
Failure Modes define how the model goes wrong.
Examples:
Overgeneralization
Pseudo-profundity
Forced hard-science analogy
Mistaking correlation for causation
Turning every anomaly into meaningful signal
Ignoring domain-specific evidence
Unfalsifiable explanation
Failure Modes are essential for preserving model discipline.
22. Falsification Boundary
The Falsification Boundary defines what the model says should not happen, or what would weaken it.
Ask:
What observation would challenge the model?
What input is outside scope?
What prediction would the model make?
What result would make the model less useful?
Where does the model become unfalsifiable?
What would turn it into a conspiracy-like explanation?
Good models have edges.
If the model explains everything, it explains nothing.
23. Distinctions
Use this section to distinguish the model from nearby concepts.
Examples:
Cognitive Imaging vs ordinary critique
Cognitive Imaging vs brainstorming
Cognitive Imaging vs confirmation bias hunting
Cognitive Imaging vs generic systems thinking
This helps prevent conceptual drift.
24. Related Models
List models that are:
Parent models
Child models
Sibling models
Overlapping models
Conflicting models
Prerequisite models
Derived models
If unsure, mark:
TBD
25. Related Agents
List agents that use or may use the model.
Example:
Cognitive Imaging Specialist
Review Committee Chair
Strategic Architect
26. Related Skills
List Skills that execute or support the model.
Example:
cognitive-imaging.skill.md
prediction-error-capture.skill.md
do-operator-test.skill.md
27. Runtime Usage
List Runtimes where the model participates.
Example:
review-committee.runtime.md
modeling-committee.runtime.md
article-to-model-extraction.runtime.md
28. Examples
Include examples only when they clarify the model.
Avoid dumping long source excerpts.
Use short examples that show:
Input
Model application
Output
Failure boundary
29. Evaluation Criteria
Define how to judge whether the model was applied well.
Examples:
Did it identify a real mechanism rather than a surface pattern?
Did it define scope?
Did it avoid unfalsifiable explanation?
Did it preserve prediction-error discipline?
Did it produce a usable output?
30. Version Notes
Record:
What changed
Why it changed
What remains unstable
What requires user review
31. Open Questions
Use this for:
Naming uncertainty
Scope uncertainty
Overlaps with other models
Missing examples
Weak falsification boundary
Possible merge with another model
32. Model Card Quality Checklist
Before finalizing a Model Card, check:
Does it preserve the model's original conceptual force?
Is the core problem clear?
Is the scope defined?
Is the mechanism explicit?
Are assumptions listed?
Are failure modes included?
Is the falsification boundary meaningful?
Are related agents and skills identified?
Is status marked correctly?
Is source material recorded?
33. Promotion Rules
A Model Card may move from candidate to draft when:
The model is structurally clear.
Source material is known.
Scope and mechanism are present.
Failure modes are at least partly defined.
A Model Card may move from draft to active only when:
The user confirms it.
The model name is accepted.
The scope is accepted.
The mechanism is accepted.
It has a meaningful falsification boundary.
It is properly indexed.
34. Merge Rules
Merge models when:
Two models have the same mechanism.
One is clearly a renamed version of another.
The distinction is terminological rather than structural.
Do not merge when:
They share vocabulary but solve different problems.
They share metaphor but have different mechanisms.
One is foundational and the other is applied.
35. Deprecation Rules
Deprecate a Model Card when:
It is superseded by a better model.
It was extracted incorrectly.
It overlaps too much with a stronger model.
The user rejects it.
It no longer represents the user's thinking.
Do not delete deprecated models immediately.
Mark them as deprecated and explain why.
36. Final Rule
A Model Card is not a tombstone for an idea.
It is a living interface between thought, agents, skills, workflows, and future knowledge work.
It should make the model easier to use without making it shallower.