853 lines
18 KiB
Markdown
853 lines
18 KiB
Markdown
# CCPE Classification Rules
|
|
|
|
## 1. Purpose
|
|
|
|
This document defines how to classify AI artifacts inside the CCPE System.
|
|
|
|
Classification must happen before creation, auditing, refactoring, or migration.
|
|
|
|
Classification must be preceded by scenario probing. Do not decide artifact layers from the artifact's importance alone.
|
|
|
|
The goal is to avoid two common errors:
|
|
|
|
```text
|
|
Under-classification:
|
|
Treating every artifact as a prompt.
|
|
|
|
Over-classification:
|
|
Turning every artifact into a complex Agent / Skill / Runtime system.
|
|
```
|
|
|
|
Use the lightest structure that preserves clarity, function, reusability, maintainability, and safety.
|
|
|
|
## 1.1 Scenario Probe First
|
|
|
|
Before choosing Lite, Agent, Skill, Runtime, Model Card, or Hybrid, determine the real usage scenario.
|
|
|
|
For an existing artifact, ask or infer:
|
|
|
|
```text
|
|
How is it currently used?
|
|
Where does it run?
|
|
Is it used as a Web / GPT / Gemini / Claude single-agent prompt?
|
|
Is the user manually passing outputs between agents?
|
|
Does it already participate in a committee or workflow?
|
|
Does it need to be callable inside Codex?
|
|
Does it use files, tools, code, APIs, or external systems?
|
|
What output is considered successful in practice?
|
|
```
|
|
|
|
For a new artifact, ask or infer:
|
|
|
|
```text
|
|
Where will it run?
|
|
Will it be used alone or with other agents?
|
|
Will the user manually orchestrate it, or should the system automate routing?
|
|
Does the user need a copy-paste prompt, a Codex Skill, a durable Agent Spec, or a Runtime?
|
|
Is the work depth-oriented, automation-oriented, or hybrid?
|
|
```
|
|
|
|
Scenario answers determine the artifact layers to produce.
|
|
|
|
## 2. Classification Targets
|
|
|
|
Every artifact should be classified as one or more of the following:
|
|
|
|
```text
|
|
CCPE-Lite
|
|
CCPE-Agent
|
|
CCPE-Skill
|
|
CCPE-Runtime
|
|
Model Card
|
|
Model Index
|
|
Hybrid Artifact
|
|
```
|
|
|
|
Many real artifacts will be Hybrid.
|
|
|
|
The job of classification is not to force one label.
|
|
The job is to identify the dominant form and embedded components.
|
|
|
|
## 3. Quick Decision Tree
|
|
|
|
Start with these questions.
|
|
|
|
### 3.0 What is the usage scenario?
|
|
|
|
Use this matrix before the artifact-type questions.
|
|
|
|
| Scenario | Recommended Form | Notes |
|
|
| --- | --- | --- |
|
|
| One-off expert Q&A | CCPE-Lite | Do not over-engineer. |
|
|
| Long-term expert role in GPT / Gem / Claude | CCPE-Lite or Agent-Lite | Preserve single-context prompt strength. |
|
|
| Web-like single-agent use inside Codex | CCPE-Lite + optional Codex Skill | Skill is needed only if Codex should invoke it automatically. |
|
|
| Stable role with collaboration responsibilities | CCPE-Agent | Use when the role needs contracts, handoff, authority, or evaluation. |
|
|
| Multiple roles manually coordinated by the user | CCPE-Lite / CCPE-Agent + Interactive Runtime Lite | The human may remain the orchestrator. |
|
|
| Reusable method across roles | CCPE-Skill | Extract only when reuse or invocation is real. |
|
|
| Repeated tool or file operation | CCPE-Skill or Runtime | Add permission, validation, and recovery rules. |
|
|
| Multi-agent automated or semi-automated workflow | CCPE-Runtime | Requires state, handoff, routing, and human gates. |
|
|
| Deep creation / modeling / critique | Interactive Runtime or Lite/Agent set | Human judgment must remain central. |
|
|
| Low-risk repetitive execution | Automation Runtime | Use only when stable and verifiable. |
|
|
|
|
### 3.1 Is it mainly a portable expert prompt?
|
|
|
|
If yes, classify as:
|
|
|
|
```text
|
|
CCPE-Lite
|
|
```
|
|
|
|
Typical signs:
|
|
|
|
* Designed for GPT / Gemini / Claude custom assistant
|
|
* Single role
|
|
* Human-facing interaction
|
|
* Mostly language reasoning
|
|
* No major tool dependency
|
|
* No long-running state
|
|
* No multi-agent handoff
|
|
* No external file operations
|
|
* Can be copied into a chat product and used directly
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Red-team critic
|
|
Socratic questioner
|
|
Article reviewer
|
|
Cognitive sparring partner
|
|
Strategic advisor
|
|
```
|
|
|
|
### 3.2 Is it a durable working role?
|
|
|
|
If yes, classify as:
|
|
|
|
```text
|
|
CCPE-Agent
|
|
```
|
|
|
|
Typical signs:
|
|
|
|
* Stable responsibility
|
|
* Reused over time
|
|
* May participate in a workflow
|
|
* Has input/output contract
|
|
* May call Skills
|
|
* May use tools
|
|
* Has authority boundaries
|
|
* Has collaboration or handoff rules
|
|
* Needs evaluation criteria
|
|
* Needs versioning
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Modeling Committee Director
|
|
Knowledge Archivist
|
|
Review Committee Member
|
|
Cognitive Imaging Specialist as a committee node
|
|
Coding Project Planner
|
|
```
|
|
|
|
### 3.3 Is it a reusable capability?
|
|
|
|
If yes, classify as:
|
|
|
|
```text
|
|
CCPE-Skill
|
|
```
|
|
|
|
Typical signs:
|
|
|
|
* Can be used by more than one Agent
|
|
* Encodes a method, tool procedure, evaluation process, or transformation
|
|
* Has trigger conditions
|
|
* Has input/output expectations
|
|
* Can be invoked when needed
|
|
* Should not be duplicated inside many agents
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Cognitive Imaging execution method
|
|
Assumption stress-test
|
|
Argument chain inspection
|
|
Voice transcription preprocessing
|
|
Report synthesis
|
|
Model extraction
|
|
Knowledge archival
|
|
```
|
|
|
|
### 3.4 Is it a multi-step execution system?
|
|
|
|
If yes, classify as:
|
|
|
|
```text
|
|
CCPE-Runtime
|
|
```
|
|
|
|
Typical signs:
|
|
|
|
* Multiple stages
|
|
* Multiple agents
|
|
* Human decision gates
|
|
* State tracking
|
|
* Tool execution
|
|
* File operations
|
|
* Handoff
|
|
* Recovery
|
|
* Long-running process
|
|
* Evaluation and archival
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Modeling Committee workflow
|
|
Multi-agent article review workflow
|
|
Coding planning-to-implementation workflow
|
|
Knowledge extraction pipeline
|
|
Model mining pipeline
|
|
```
|
|
|
|
### 3.5 Is it a cognitive model?
|
|
|
|
If yes, classify as:
|
|
|
|
```text
|
|
Model Card
|
|
```
|
|
|
|
Typical signs:
|
|
|
|
* Defines a way of seeing, explaining, compressing, or evaluating reality
|
|
* Has assumptions
|
|
* Has mechanisms
|
|
* Has scope
|
|
* Has failure modes
|
|
* Can be applied by more than one Agent
|
|
* Can become a Skill
|
|
* Is not itself a persona
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Cognitive Imaging
|
|
Giant Cognition
|
|
Cognitive Prism
|
|
Concept Boundary Model
|
|
Argument Compression Model
|
|
```
|
|
|
|
### 3.6 Is it a catalog of models?
|
|
|
|
If yes, classify as:
|
|
|
|
```text
|
|
Model Index
|
|
```
|
|
|
|
Typical signs:
|
|
|
|
* Lists multiple models
|
|
* Tracks model hierarchy
|
|
* Tracks source articles
|
|
* Tracks dependencies
|
|
* Tracks related agents and skills
|
|
* Tracks status and versioning
|
|
* Organizes a model library
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Model taxonomy
|
|
Model dependency map
|
|
Model usage map
|
|
Extraction log
|
|
```
|
|
|
|
## 4. Hybrid Classification
|
|
|
|
Many artifacts combine several forms.
|
|
|
|
Use Hybrid classification when the artifact contains more than one structurally important component.
|
|
|
|
Example:
|
|
|
|
```text
|
|
Cognitive Imaging Specialist
|
|
```
|
|
|
|
Possible decomposition:
|
|
|
|
```text
|
|
Primary:
|
|
- CCPE-Agent or CCPE-Lite
|
|
|
|
Embedded:
|
|
- Cognitive Imaging Model
|
|
- Cognitive Imaging Skill
|
|
- Report template
|
|
- Retrieval policy
|
|
- Runtime node potential
|
|
```
|
|
|
|
Do not decide too early whether to split.
|
|
First identify embedded components.
|
|
|
|
## 5. Primary vs Secondary Classification
|
|
|
|
Every Hybrid artifact should receive:
|
|
|
|
```text
|
|
Primary Classification
|
|
Secondary Components
|
|
Recommended Target Form
|
|
```
|
|
|
|
Example:
|
|
|
|
```text
|
|
Primary Classification:
|
|
CCPE-Agent
|
|
|
|
Secondary Components:
|
|
- Embedded Cognitive Model
|
|
- Executable Method Skill
|
|
- Output Template
|
|
- Optional Retrieval Tool Policy
|
|
|
|
Recommended Target Form:
|
|
- Keep portable Lite version
|
|
- Extract Model Card
|
|
- Extract Skill
|
|
- Create Agent Spec for workflow use
|
|
```
|
|
|
|
## 6. Single-Agent Decision Rules
|
|
|
|
A single agent does not automatically mean CCPE-Lite.
|
|
|
|
A mature single-agent expert prompt also does not automatically require Agent, Skill, and Runtime layers.
|
|
|
|
### 6.1 Mature Agent Minimal Expansion Rule
|
|
|
|
For an existing mature agent that has been used successfully many times, default to the smallest expansion that preserves its working behavior.
|
|
|
|
Default target:
|
|
|
|
```text
|
|
CCPE-Lite
|
|
+ Model Card if it contains a stable user-authored cognitive model
|
|
```
|
|
|
|
Add other layers only when scenario evidence requires them:
|
|
|
|
```text
|
|
Add Skill when:
|
|
- Codex or another system should invoke the method automatically.
|
|
- The method is reused by multiple agents.
|
|
- The procedure must be validated independently.
|
|
|
|
Add Agent Spec when:
|
|
- The role joins a committee or durable workflow.
|
|
- It needs explicit handoff, collaboration, authority, or evaluation contracts.
|
|
|
|
Add Runtime when:
|
|
- Multiple agents, stages, state, routing, synthesis, archival, tools, or automation are involved.
|
|
```
|
|
|
|
Do not split mature prompts merely because CCPE System supports multiple artifact types.
|
|
|
|
Use CCPE-Agent when a single agent:
|
|
|
|
* Is used repeatedly in important work
|
|
* Has complex responsibilities
|
|
* Calls reusable Skills
|
|
* Uses tools
|
|
* Needs input/output contracts
|
|
* Requires evaluation criteria
|
|
* May join a workflow later
|
|
* Has embedded cognitive models
|
|
* Needs version control
|
|
|
|
Use CCPE-Lite when a single agent:
|
|
|
|
* Is mainly a portable expert assistant
|
|
* Does not need external orchestration
|
|
* Does not need separate model assets
|
|
* Does not use complex tools
|
|
* Is easy to maintain as one prompt
|
|
* Benefits from being self-contained
|
|
|
|
For Web-style expert prompts, Lite is a complete deployment form, not a downgraded Agent Spec.
|
|
|
|
## 7. Multi-Agent Decision Rules
|
|
|
|
A multi-agent system does not automatically require heavy automation.
|
|
|
|
Classify the overall system as CCPE-Runtime when it has:
|
|
|
|
* Defined stages
|
|
* Defined roles
|
|
* Handoff rules
|
|
* State tracking
|
|
* Human decision gates
|
|
* Shared Skills
|
|
* Shared outputs
|
|
* Synthesis or archival steps
|
|
|
|
Classify each member separately.
|
|
|
|
Some members may be:
|
|
|
|
```text
|
|
CCPE-Lite
|
|
```
|
|
|
|
Others may be:
|
|
|
|
```text
|
|
CCPE-Agent
|
|
```
|
|
|
|
The committee itself is usually:
|
|
|
|
```text
|
|
CCPE-Runtime
|
|
```
|
|
|
|
Example:
|
|
|
|
```text
|
|
Modeling Committee
|
|
= Interactive Runtime
|
|
+ Agent Specs for stable members
|
|
+ Shared Cognitive Skills
|
|
+ Human decision gates
|
|
+ Knowledge archival protocol
|
|
```
|
|
|
|
## 8. Self-Contained Model Agent Rules
|
|
|
|
When an agent includes its own model, classify each internal component.
|
|
|
|
Look for:
|
|
|
|
```text
|
|
Role
|
|
Model
|
|
Method
|
|
Workflow
|
|
Tool policy
|
|
Output template
|
|
Runtime role
|
|
```
|
|
|
|
Then decide whether to keep or split.
|
|
|
|
### 8.1 Keep as CCPE-Lite when:
|
|
|
|
* The agent is mostly used as a portable custom GPT / Gemini / Claude assistant
|
|
* The embedded model is not reused elsewhere
|
|
* The model is short enough to remain maintainable
|
|
* Splitting would reduce usability
|
|
* The user needs one-piece deployment
|
|
|
|
### 8.2 Extract Model Card when:
|
|
|
|
* The model is a durable intellectual asset
|
|
* The model appears in multiple articles or agents
|
|
* The model has its own assumptions, mechanisms, and boundaries
|
|
* The model can be reused by other agents
|
|
* The model should be indexed in a model library
|
|
|
|
### 8.3 Extract Skill when:
|
|
|
|
* The model has a repeatable procedure
|
|
* The procedure can be executed by multiple agents
|
|
* The model can become a callable method
|
|
* There are trigger conditions and output standards
|
|
* The same method is duplicated across agents
|
|
|
|
### 8.4 Create Agent Spec when:
|
|
|
|
* The role is durable
|
|
* It participates in a workflow
|
|
* It calls Skills
|
|
* It requires collaboration rules
|
|
* It requires evaluation rules
|
|
* It needs human decision gates or authority boundaries
|
|
|
|
### 8.5 Create Runtime when:
|
|
|
|
* The agent is part of a committee
|
|
* Multiple agents will be invoked
|
|
* Reports will be collected and synthesized
|
|
* State must be tracked
|
|
* Human decisions must be marked
|
|
* Automation is introduced around the process
|
|
|
|
## 9. Depth vs Automation Classification
|
|
|
|
Every artifact should be labeled by orientation:
|
|
|
|
```text
|
|
Depth-Oriented
|
|
Automation-Oriented
|
|
Hybrid
|
|
```
|
|
|
|
### 9.1 Depth-Oriented
|
|
|
|
Use this label when:
|
|
|
|
* Work is high uncertainty
|
|
* Human judgment is central
|
|
* Model fidelity matters
|
|
* The task involves interpretation, critique, theory, writing, or strategy
|
|
* Output quality depends on conceptual insight
|
|
* Full automation would be harmful
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Cognitive Imaging Specialist
|
|
Socratic Questioner
|
|
Modeling Committee
|
|
Strategic Architect
|
|
Red-team analysis of original theory
|
|
```
|
|
|
|
### 9.2 Automation-Oriented
|
|
|
|
Use this label when:
|
|
|
|
* Steps are stable
|
|
* Output is verifiable
|
|
* Risk is low or manageable
|
|
* Tool execution is central
|
|
* Human judgment is less central
|
|
* The task is repetitive
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Format conversion
|
|
Voice-to-text preprocessing
|
|
Batch file classification
|
|
Report collection
|
|
Archive update
|
|
Template generation
|
|
```
|
|
|
|
### 9.3 Hybrid
|
|
|
|
Use this label when:
|
|
|
|
* Core reasoning is human-led
|
|
* Peripheral operations can be automated
|
|
* Agents assist analysis
|
|
* Automation handles collection, routing, deduplication, or formatting
|
|
* Human decides final direction
|
|
|
|
Examples:
|
|
|
|
```text
|
|
Review Committee
|
|
Knowledge extraction pipeline
|
|
Writing workflow
|
|
Coding project workflow after planning is accepted
|
|
```
|
|
|
|
## 10. Runtime Necessity Rules
|
|
|
|
Do not create Runtime unless needed.
|
|
|
|
Runtime is likely needed if any of the following are true:
|
|
|
|
```text
|
|
The task has multiple phases.
|
|
Multiple agents are involved.
|
|
Files will be read or written.
|
|
Tools will be invoked.
|
|
Outputs from one step feed another step.
|
|
Human approval gates are required.
|
|
There is state to preserve.
|
|
There is a possibility of interruption and resumption.
|
|
There is a need for logging or archival.
|
|
There is automation beyond simple chat.
|
|
```
|
|
|
|
Runtime is likely not needed if:
|
|
|
|
```text
|
|
The artifact is a single expert prompt.
|
|
The user manually controls all input and output.
|
|
There is no tool use.
|
|
There is no state.
|
|
The work is short-lived.
|
|
The artifact is mainly for thinking or critique.
|
|
```
|
|
|
|
## 11. Skill Extraction Rules
|
|
|
|
Consider extracting a Skill when:
|
|
|
|
* A method appears in multiple agents
|
|
* A procedure has stable steps
|
|
* A tool needs consistent handling
|
|
* A report format is reused
|
|
* A reasoning checklist is reused
|
|
* A model can be executed procedurally
|
|
* An evaluation method needs standardization
|
|
|
|
Do not extract a Skill when:
|
|
|
|
* The procedure is too vague
|
|
* It is unique to one agent
|
|
* It depends entirely on the agent's persona
|
|
* It is too small to justify separation
|
|
* Separation would make usage harder
|
|
|
|
## 12. Model Card Extraction Rules
|
|
|
|
Consider creating a Model Card when:
|
|
|
|
* The artifact contains a theory or cognitive model
|
|
* The model has explanatory power beyond one agent
|
|
* The model has assumptions and boundaries
|
|
* The model can be reused
|
|
* The model came from long-form writing
|
|
* The model should be indexed
|
|
* The model may become a Skill later
|
|
|
|
Do not create a Model Card when:
|
|
|
|
* The idea is only a claim
|
|
* The idea is only a metaphor with no mechanism
|
|
* The idea is only an output style
|
|
* The idea has no clear scope
|
|
* The idea cannot yet be distinguished from the surrounding essay
|
|
|
|
Mark uncertain cases as:
|
|
|
|
```text
|
|
Candidate Model
|
|
```
|
|
|
|
## 13. Model Index Rules
|
|
|
|
Use Model Index when there are multiple Model Cards or candidate models.
|
|
|
|
Model Index should classify models by:
|
|
|
|
```text
|
|
Foundational
|
|
Intermediate
|
|
Applied
|
|
Workflow Model
|
|
Implicit Extracted
|
|
Deprecated
|
|
Candidate
|
|
```
|
|
|
|
Model Index should also track:
|
|
|
|
```text
|
|
Source article
|
|
Related models
|
|
Parent models
|
|
Child models
|
|
Overlapping models
|
|
Conflicting models
|
|
Related agents
|
|
Related skills
|
|
Runtime usage
|
|
Status
|
|
```
|
|
|
|
## 14. Creation Classification
|
|
|
|
When creating a new artifact, first produce a Creation Brief.
|
|
|
|
The Creation Brief should answer:
|
|
|
|
```text
|
|
What is the intended use?
|
|
Who will use it?
|
|
Where will it run?
|
|
Is it a prompt, agent, skill, runtime, model, or hybrid?
|
|
Is it depth-oriented, automation-oriented, or hybrid?
|
|
Does it involve tools?
|
|
Does it involve state?
|
|
Does it involve human decision gates?
|
|
Does it rely on a cognitive model?
|
|
Should that model become a Model Card?
|
|
Should any method become a Skill?
|
|
What files should be generated?
|
|
```
|
|
|
|
## 15. Audit Classification
|
|
|
|
When auditing an existing artifact, produce:
|
|
|
|
```text
|
|
Classification
|
|
Embedded components
|
|
Usage mode
|
|
Depth vs automation orientation
|
|
Over-engineering risks
|
|
Under-specification risks
|
|
Recommended target form
|
|
Proposed file split
|
|
```
|
|
|
|
## 16. Refactor Classification
|
|
|
|
When refactoring, produce:
|
|
|
|
```text
|
|
Original classification
|
|
Target classification
|
|
Preserved elements
|
|
Extracted elements
|
|
Deprecated elements
|
|
Generated files
|
|
Migration notes
|
|
Open questions
|
|
```
|
|
|
|
## 17. Classification Output Format
|
|
|
|
Use this format when reporting classification:
|
|
|
|
```text
|
|
# Classification Report
|
|
|
|
## 1. Primary Classification
|
|
...
|
|
|
|
## 2. Secondary Components
|
|
...
|
|
|
|
## 3. Usage Mode
|
|
Expert / Workshop / Automation / Hybrid
|
|
|
|
## 4. Depth vs Automation Orientation
|
|
Depth-Oriented / Automation-Oriented / Hybrid
|
|
|
|
## 5. Embedded Cognitive Models
|
|
...
|
|
|
|
## 6. Extractable Skills
|
|
...
|
|
|
|
## 7. Runtime Need
|
|
None / Optional / Recommended / Required
|
|
|
|
## 8. Recommended Target Form
|
|
...
|
|
|
|
## 9. Proposed Files
|
|
...
|
|
|
|
## 10. Human Decision Points
|
|
...
|
|
```
|
|
|
|
## 18. Classification Examples
|
|
|
|
### 18.1 Zhangliao Red-Team Critic
|
|
|
|
Likely classification:
|
|
|
|
```text
|
|
Primary:
|
|
CCPE-Lite
|
|
|
|
Possible upgrade:
|
|
CCPE-Agent if used as a durable review committee member
|
|
|
|
Extractable Skills:
|
|
- Argument attack
|
|
- Assumption stress-test
|
|
- Strategic vulnerability analysis
|
|
|
|
Runtime:
|
|
Optional only if used in a review committee
|
|
```
|
|
|
|
### 18.2 Cognitive Imaging Specialist
|
|
|
|
Likely classification:
|
|
|
|
```text
|
|
Primary:
|
|
CCPE-Agent or CCPE-Lite depending on deployment
|
|
|
|
Embedded:
|
|
- Cognitive Imaging Model
|
|
- Five-step imaging method
|
|
- Report template
|
|
- Retrieval policy
|
|
|
|
Recommended:
|
|
- Preserve Lite version for portable use
|
|
- Extract Model Card
|
|
- Extract Cognitive Imaging Skill
|
|
- Create Agent Spec if used in committee
|
|
- Runtime only if orchestrated with other reviewers
|
|
```
|
|
|
|
### 18.3 Modeling Committee
|
|
|
|
Likely classification:
|
|
|
|
```text
|
|
Primary:
|
|
CCPE-Runtime
|
|
|
|
Runtime type:
|
|
Interactive Runtime or Hybrid Runtime
|
|
|
|
Components:
|
|
- Director Agent
|
|
- Strategic Architect Agent
|
|
- Red-team Agent
|
|
- Socratic Questioner Agent
|
|
- Narrative Architect Agent
|
|
- Knowledge Archivist Agent
|
|
- Shared Skills
|
|
- Human decision gates
|
|
```
|
|
|
|
### 18.4 Long Essay Containing Several Models
|
|
|
|
Likely classification:
|
|
|
|
```text
|
|
Primary:
|
|
Model Mining Source
|
|
|
|
Outputs:
|
|
- Candidate Model Cards
|
|
- Model Index entries
|
|
- Possible Skills
|
|
- Possible Agents
|
|
|
|
Runtime:
|
|
Optional if extraction is part of a large knowledge pipeline
|
|
```
|
|
|
|
## 19. Final Rule
|
|
|
|
Classification is a tool, not a cage.
|
|
|
|
If classification makes the artifact clearer, use it.
|
|
|
|
If classification fragments the artifact without improving reuse, maintainability, or execution quality, keep the artifact simpler.
|
|
|
|
The correct CCPE form is the lightest form that preserves the artifact's cognitive power and practical usability.
|
|
|