ccpe-system/ccpe-protocol/ccpe-classification-rules.md

# 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 Supplier Intake Rule

For project-facing work, do not begin by inventing a CCPE asset from an assumed business scenario.

Preferred sequence:

```text
1. Project repository identifies a real use case.
2. Project repository provides a requirement or the user states the concrete need.
3. CCPE classifies the requirement and checks repository ownership.
4. CCPE supplies the smallest appropriate artifact.
5. The project repository runs the concrete work and stores execution records.
```

This applies to `writing-workbench`, `knowledge-vault`, `video-workbench`, and future `work-projects`.

## 1.2 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-Committee
CCPE-Skill
CCPE-Runtime
Model Card
Model Index
Integration Registration
Project Runbook
automation Skill source
external tool / MCP / CLI / API
Hybrid Artifact
Out of Scope
```

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.

Classification must also decide repository ownership.

```text
CCPE-owned:
  Lite, Agent, Committee, CCPE-Skill, Runtime, Model Card, Model Index, Integration Registration

Project-owned:
  Project Runbook, project execution record, one-off context pack, returned report, draft, decision log

skills-vault-owned:
  automation Skill source, scripts, tests, fixtures, install notes

development-project-owned:
  production agent implementation, LangGraph/CrewAI adapters, server runtime, persistence, deployment
```

If an external capability is required by a CCPE artifact, classify the CCPE-side output as `Integration Registration`, not as copied source.

## 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. |
| Fixed group of reviewers or judges | CCPE-Committee | Requires independent reports, role tension, synthesis rule, human gate, and no-simulation rule. |
| 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 deterministic tool or file operation | automation Skill source in skills-vault | CCPE registers dependency only when a CCPE artifact formally uses it. |
| 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. |
| One project runbook or execution record | Project repository | Do not migrate project-specific records into CCPE. |
| External tool, MCP, CLI, API, or installed capability | Integration Registration | Register architecture dependency; do not copy implementation source. |
| Production business agent for deployed system | CCPE spec + development project implementation | CCPE designs contract; target project implements runtime. |

### 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
```

In this CCPE-System workspace, original prompt upgrades do not use a generic audit report.

When the user provides an original prompt and says they are preparing to upgrade it, terms such as audit, judgment, review, inspection, or evaluation all mean pre-migration source judgment.

The report path is:

```text
workbench/analysis/{artifact-slug}-original-source-judgment-report.md
```

Use `Original Source Judgment Report` structure, not a generic Classification Report or Quality Report.

Do not print full source judgment reports in chat by default. Return the report path and wait for the user's next action.

## 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.