ccpe-system/ccpe-protocol/ccpe-migration-policy.md

CCPE Migration Policy

1. Purpose

This document defines how to migrate older CCPE 2.0 artifacts into the new CCPE System.

The migration policy applies to:

Old CCPE 2.0 prompts
Custom GPT / Gem instructions
Single-agent expert prompts
Self-contained model-backed agents
Multi-agent committees
Old Skill-like procedures
Workflow descriptions
Prompt templates

The goal is not to rewrite everything into a heavier format.

The goal is to identify what each artifact really contains and move each component into its most useful form.

Migration must begin with scenario probing. The same source artifact may become only a Lite prompt, or may become Lite + Model Card + Skill + Agent + Runtime, depending on how the user actually uses it.

2. Migration Principle

The central migration principle is:

Preserve cognitive power while improving structure.

For mature single-agent expert prompts, preserve the working prompt kernel before extracting components.

Migration should improve:

Clarity
Reusability
Maintainability
Portability
Safety
Evaluation
Model fidelity

Migration should not destroy:

Original metaphor
Conceptual force
Distinctive terminology
User's intellectual intent
Useful personality
Domain-specific sharpness

Do not turn powerful cognitive tools into bland generic templates.

2.1 Scenario Probe

Before migrating an old CCPE 2.0 artifact, determine:

current_usage:
  - Web / GPT / Gemini / Claude single-agent prompt?
  - Codex local workspace artifact?
  - committee member manually invoked by the user?
  - automated workflow node?

planned_usage:
  - copy-paste prompt?
  - Codex-callable Skill?
  - durable Agent Spec?
  - multi-agent Runtime?

orchestration:
  - human manually passes context?
  - a lead agent routes work?
  - system automation routes and synthesizes outputs?

depth_orientation:
  - deep expert thinking?
  - workflow execution?
  - hybrid?

If scenario information is unavailable, produce a scenario assumption and mark it as a migration risk.

2.2 Mature Agent Minimal Expansion Rule

For a proven old agent that is mainly used as a single expert in chat:

default_migration: CCPE-Lite
recommended_addition: Model Card if the embedded model is stable and valuable
defer: Agent Spec, Skill, Runtime

Create additional layers only when the scenario requires them:

Skill:
  Needed when Codex should invoke the method automatically, or the method is reused across agents.

Agent Spec:
  Needed when the role participates in a durable workflow or committee and needs handoff, authority, and evaluation rules.

Runtime:
  Needed when multiple roles, stages, state, synthesis, archival, tools, or automation must be coordinated.

Do not treat four-layer expansion as a default migration outcome.

3. Old CCPE 2.0 Layer Mapping

Old CCPE 2.0 used four major layers:

Core Layer
Execution Layer
Constraint Layer
Operation Layer

The new CCPE System expands these into more precise structures.

For CCPE-Lite migration, these four layers remain the preferred prompt-construction kernel:

Core Layer
Execution Layer
Constraint Layer
Operation Layer

Do not collapse a Web-style Lite prompt into an Agent Spec outline if the target use is direct single-agent deployment.

3.1 Core Layer Migration

Old:

Core Layer
= identity, role, professional background, style, values, reasoning preference

New:

Objective Layer
Role Layer
Model Layer if cognitive model is embedded
Collaboration Layer if role participates in workflow

Migration action:

• Extract objective from role description.
• Preserve meaningful role identity.
• Move cognitive model content into Model Layer or Model Card.
• Move collaboration-related content into Collaboration Layer or Runtime.

3.2 Execution Layer Migration

Old:

Execution Layer
= functional range, skills, knowledge base, tools, decision authority

New:

Capability Layer
Context Layer
Tool Layer
Authority Layer
Skill references
Model references

Migration action:

• Separate capability from authority.
• Separate knowledge assumptions from source policy.
• Separate internal methods from reusable Skills.
• Separate tool abilities from general reasoning abilities.
• Replace omniscience with evidence and uncertainty rules.

3.3 Constraint Layer Migration

Old:

Constraint Layer
= hard constraints, soft constraints, safety boundaries, conflict resolution

New:

Constraint Layer
Authority Layer
Safety Rules
Refusal Conditions
Conflict Resolution
Evaluation Layer

Migration action:

• Keep hard constraints.
• Mark soft constraints as preferences.
• Move permission-related rules to Authority Layer.
• Add testable refusal conditions.
• Add evaluation rules where constraints imply quality standards.

3.4 Operation Layer Migration

Old:

Operation Layer
= input processing, context, memory, workflow, output, validation, feedback, exceptions

New:

Context Layer
Workflow Layer
State Layer
Output Layer
Evaluation Layer
Runtime Layer
Collaboration Layer if multi-agent

Migration action:

• Separate input handling from workflow.
• Separate state from memory.
• Replace chain-of-thought requirements with auditable reasoning summaries.
• Move output format to Output Layer.
• Move validation to Evaluation Layer.
• Move long-running process rules to Runtime Layer.

4. Migration Decision Tree

Before migrating, classify the artifact.

4.1 If it is a portable expert prompt

Target:

CCPE-Lite

Actions:

• Keep concise.
• Preserve persona.
• Preserve the four-layer CCPE 2.0 working kernel when the prompt is deep or expert-like.
• Keep necessary workflow, output, validation, and feedback rules.
• Add minimal objective, boundary, and evaluation rules without weakening the original effect.
• Do not extract components unless reuse, indexing, Codex invocation, or workflow participation is likely.

4.2 If it is a durable work role

Target:

CCPE-Agent

Actions:

• Add input/output contract.
• Add authority rules.
• Add collaboration rules if applicable.
• Add evaluation criteria.
• Reference Skills and Models instead of embedding everything.

4.3 If it contains a reusable procedure

Target:

CCPE-Skill

Actions:

• Extract trigger conditions.
• Define inputs and outputs.
• Define procedure.
• Add validation and failure handling.
• Reference the Skill from relevant Agents.

4.4 If it contains a cognitive model

Target:

Model Card

Actions:

• Extract model name, scope, assumptions, mechanism, procedure, failure modes, and falsification boundary.
• Keep source trace.
• Add related agents and skills.
• Register in Model Index if accepted.

4.5 If it coordinates multiple roles or stages

Target:

CCPE-Runtime

Actions:

• Define stages.
• Define participants.
• Define handoff.
• Define state.
• Define human decision gates.
• Define automation boundaries.
• Define outputs and archival rules.

5. Self-Contained Model Agent Migration

Many old agents combine:

Role
Model
Method
Workflow
Output format
Tool policy

This is common and acceptable in CCPE 2.0.

In the new system, inspect whether to split.

5.1 Migration Pattern

Preferred pattern:

Original self-contained agent
→ Portable Lite Prompt
→ Durable Agent Spec
→ Model Card
→ Executable Skill
→ Runtime node if needed

Not all outputs are always required.

For mature Web-style expert agents, the preferred initial pattern is:

Original self-contained agent
→ Portable Lite Prompt preserving the original working kernel
→ Model Card if the embedded model is stable
→ Regression test against the original agent
→ Additional Agent / Skill / Runtime only if the usage scenario requires it

The Lite version is not a byproduct. In single-agent scenarios it is the primary production artifact.

5.2 Example Pattern

Original:

Cognitive Imaging Specialist

Possible migration:

cognitive-imaging-specialist.prompt.md
cognitive-imaging-specialist.agent.md
cognitive-imaging-model.md
cognitive-imaging.skill.md
review-committee.runtime.md reference

5.3 Keep Lite Version When

• The user wants copy-paste deployment.
• The agent is used in GPT / Gemini / Claude.
• The model is short enough to embed.
• Platform cannot load external references.
• One-piece portability matters.

5.4 Extract Model Card When

• The model is an intellectual asset.
• The model appears in multiple agents.
• The model comes from long-form writing.
• The model deserves indexing.
• The model has independent value.

5.5 Extract Skill When

• The method is reusable.
• The method has stable steps.
• The method can be called by multiple agents.
• The method has clear inputs and outputs.
• The method can be validated.

5.6 Create Agent Spec When

• The role will be maintained over time.
• The role participates in workflows.
• The role needs authority and collaboration rules.
• The role calls Skills or tools.
• The role has evaluation criteria.

5.7 Create Runtime When

• Multiple agents are involved.
• Outputs are routed or synthesized.
• Human approval gates exist.
• State must be tracked.
• Automation is introduced.

6. CoT and Reasoning Migration

Old prompts may include instructions such as:

Must include internal thought
Must show chain of thought
Must reveal full reasoning process

Migrate these instructions.

6.1 Replace With

Reasoning Summary
Decision Criteria
Validation Checklist
Assumptions
Evidence Used
Uncertainty Notes
Intermediate Findings
Self-Check Results

6.2 Do Not Require

Full hidden chain-of-thought
Private internal reasoning
Raw scratchpad

6.3 Acceptable Pattern

Before final output, perform internal analysis.
In the response, provide:
- Key assumptions
- Reasoning summary
- Main checks performed
- Uncertainty or failure points
- Final conclusion

7. Retrieval and Source Policy Migration

Old prompts may say:

Can use online search
Can use latest facts
Can retrieve external data

Migrate to explicit Source Policy.

7.1 Required Fields

When retrieval is required
What sources are acceptable
How retrieved facts are treated
How source conflicts are handled
How uncertainty is marked
Whether retrieved material is evidence, raw material, or context

7.2 Example

Retrieved data is not self-evident truth.
It is treated as raw observational material.
The agent must distinguish:
- reported fact
- interpretation
- correlation
- causal claim
- noise

8. Tool Policy Migration

Old prompts may mention tools informally.

Migrate informal tool rules into Tool Layer and Authority Layer.

8.1 Required Fields

Tool Name
Purpose
Allowed Use
Trigger Conditions
Input
Output
Permission Level
Failure Handling
Validation

8.2 Authority Mapping

Separate:

Can propose tool use
Can invoke tool automatically
Requires confirmation
Forbidden tool use

9. Output Format Migration

Old prompts may contain long report formats.

Migrate output formats into Output Layer.

9.1 Keep

Distinctive report sections
Useful terminology
Required analysis fields
Downstream usability

9.2 Remove or Simplify

Duplicate sections
Ceremonial headings with no function
Excessive mandatory verbosity
Unclear formatting

9.3 Add

Concise mode if needed
Full report mode if needed
Follow-up discussion mode if needed
Delivery checklist
Output hierarchy rules

9.4 Output Structure Discipline

When migrating old prompts with report formats, preserve useful sections but repair hierarchy.

Keep:
  Distinctive section names, required fields, and downstream-useful report shape.

Repair:
  Flattened list levels, ambiguous heading hierarchy, repeated fields, and formatting that hides conclusions.

Require:
  Each major section should begin with a clear judgment, followed by supporting evidence or subpoints.

10. Constraint Migration

Old hard constraints should be preserved when still useful.

But separate:

Safety constraint
Quality constraint
Role boundary
Permission rule
Evaluation requirement

10.1 Example

Old:

Must always follow five-step workflow.

Possible migration:

For full report mode, execute five-step workflow.
For follow-up discussion mode, use the relevant step only.
For non-CAS input, refuse or switch to general analysis.

This preserves rigor while reducing unnecessary rigidity.

10A. Concept and Reconstruction Discipline

When migrating critique, review, modeling, or pressure-test agents, add rules that prevent false targets.

10A.1 Concept Function Discipline

Before testing or refactoring a concept, classify its function:

lens
claim
metaphor
mechanism
generator
procedure
constraint
output form

Do not force a lens, metaphor, or local heuristic to carry full causal-generator responsibility unless the source artifact explicitly or implicitly assigns that role.

10A.2 Reconstruction Discipline

When testing implicit claims:

1. Separate explicit source claims from reconstructed claims.
2. Mark reconstructed claims before testing them.
3. Use the strongest plausible reconstruction, not a straw version.
4. Note uncertainty when source intent is ambiguous.

11. Multi-Agent Migration

Old multi-agent systems may exist as separate prompts manually coordinated by the user.

Do not assume immediate automation. First determine whether the current system is:

Manual committee:
  The user manually invokes each agent and passes context.

Lead-agent committee:
  A director / project manager agent coordinates known members.

Automated Runtime:
  The system routes, stores, synthesizes, and resumes work.

Migrate into full Runtime only when state, handoff, synthesis, archival, or automation is actually needed:

Runtime Spec
+ Member Agent Specs
+ Shared Skills
+ Human Decision Gates
+ Output Synthesis Rules
+ Archival Rules

11.1 Pre-Composed Committee Pattern

Use this pattern for stable human-led committees.

Committee Runtime
├── Director Agent
├── Specialist Agents
├── Shared Skills
├── State Rules
├── Human Decision Gates
├── Synthesis Rules
└── Knowledge Archival Rules

11.2 Do Not Default to Dynamic Agent Creation

If roles are already known and valuable, preserve them.

Dynamic role generation is optional, not default.

12. Model Index Migration

When extracting models from old artifacts or articles, update Model Index.

12.1 Required Index Fields

Model Name
Model Type
Layer
Status
Source
Related Models
Related Agents
Related Skills
Runtime Usage
Canonical Path
Review Status

12.2 Candidate vs Canonical

Do not promote extracted models to canonical status automatically.

Use statuses:

candidate
draft
active
deprecated
archived

Human confirmation is required to promote important models.

13. Migration Output Format

Every migration should produce an Upgrade Report.

Use this format:

# CCPE Upgrade Report

## 1. Original Artifact
Name:
Path:
Version:
Original Format:

## 2. Original Classification
Primary:
Secondary Components:
Operating Mode:
Depth vs Automation:

## 3. Target Classification
Primary:
Secondary Outputs:
Runtime Need:

## 4. Preserved Elements
...

## 5. Extracted Elements
...

## 6. Modified Elements
...

## 7. Deprecated or Removed Elements
...

## 8. Generated Files
...

## 9. Model Index Updates
...

## 10. Human Decisions Required
...

## 11. Next Step
...

14. Migration Severity

Use severity labels for problems:

S = Must fix before reuse
A = Major issue
B = Should improve
C = Minor cleanup

14.1 S-Level Issues

Examples:

Unsafe tool authority
Contradictory instructions
No clear objective
High-risk automation without human approval
Model flattened into false universality

14.2 A-Level Issues

Examples:

Model and role too tightly coupled
No source policy for retrieval
No evaluation criteria
Workflow unclear
Scope boundary vague

14.3 B-Level Issues

Examples:

Output format too long
Duplicate sections
Skill extraction opportunity
Missing version metadata

14.4 C-Level Issues

Examples:

Naming inconsistency
Minor formatting issues
Section order could improve

15. Migration Safety Rules

Before modifying files:

1. Read the artifact.
2. Classify it.
3. Produce a migration plan.
4. List proposed output files.
5. Ask for confirmation before large changes.
6. Write upgraded drafts first.
7. Do not overwrite originals.
8. Preserve an archive copy if replacing canonical versions.

16. Migration Completion Criteria

A migration is complete when:

Scenario probe is documented.
The artifact has a clear target form.
Embedded models are handled.
Reusable Skills are identified or extracted.
Runtime needs are addressed or explicitly rejected.
Agent Spec and Skill extraction are justified by usage scenario.
Human decision gates are defined where needed.
Output format is usable.
Evaluation criteria exist.
Model Index is updated when relevant.
Original intent is preserved.
Original working prompt kernel is preserved when target is Lite.
Regression test or comparison is planned for mature agents.

17. Final Rule

Migration is not modernization theater.

Do not split an artifact just because the new system has more categories.

Split only when it improves reuse, clarity, safety, evaluation, or long-term maintenance.

Preserve the portable Lite form when it remains useful.

Upgrade the structure without sanding off the mind behind it.