18 KiB
CCPE Layer Spec
1. Purpose
This document defines the structural layers used by CCPE System.
The layers are not mandatory fields for every artifact.
They are a design vocabulary.
Use them to decide what information an artifact needs in order to be clear, reusable, safe, and maintainable.
Different artifact types use different subsets of these layers.
2. Layer Overview
CCPE System uses the following major layers:
1. Objective Layer
2. Role Layer
3. Context Layer
4. Capability Layer
5. Tool Layer
6. Authority Layer
7. Workflow Layer
8. Constraint Layer
9. State Layer
10. Output Layer
11. Evaluation Layer
12. Runtime Layer
13. Collaboration Layer
14. Model Layer
15. Knowledge Asset Layer
Not every artifact needs every layer.
A CCPE-Lite Prompt Card may use only:
Objective
Role
Context
Capability
Constraint
Workflow
Output
A CCPE-Runtime may require:
Objective
Context
Agent Roles
Skills
Authority
Workflow
State
Evaluation
Runtime
Collaboration
A Model Card may require:
Model Layer
Context
Scope
Mechanism
Procedure
Failure Modes
Evaluation
Knowledge Asset
3. Objective Layer
3.1 Purpose
The Objective Layer defines what the artifact is meant to accomplish.
This layer answers:
What is this for?
What problem does it solve?
What does success look like?
What is outside its scope?
3.2 Recommended Fields
Primary Objective
Secondary Objectives
Non-Goals
Success Criteria
Acceptance Criteria
Task Boundary
Failure Conditions
3.3 Required For
CCPE-Lite
CCPE-Agent
CCPE-Skill
CCPE-Runtime
Model Card
3.4 Design Notes
The Objective Layer should come before role identity.
A strong persona without a clear objective creates charismatic drift.
The agent may sound right but fail the task.
3.5 Example
Primary Objective:
Identify structural weaknesses, hidden assumptions, and failure risks in the user's argument.
Non-Goals:
Do not rewrite the entire article unless asked.
Do not replace the user's judgment.
Do not provide emotional reassurance in place of critique.
Success Criteria:
The user receives a prioritized list of vulnerabilities and repair directions.
4. Role Layer
4.1 Purpose
The Role Layer defines the artifact's working identity.
This layer answers:
Who is acting?
What expertise or stance does it represent?
What is its relationship to the user?
How should it interact?
4.2 Recommended Fields
Role Name
Role Attribute
Professional Background
Interaction Style
Reasoning Style
Value Orientation
User Relationship
Collaboration Position
4.3 Required For
CCPE-Lite
CCPE-Agent
Committee Member Agents
Expert Mode artifacts
4.4 Optional For
Skills
Runtime Specs
Model Cards
A Skill usually does not need a persona. A Model Card should not be written as a persona unless the model itself includes an epistemic stance.
4.5 Design Notes
Role should not override objective.
Do not let personality inflate task scope.
Avoid ornamental role descriptions unless they improve execution.
Preserve meaningful metaphors when they encode reasoning structure.
5. Context Layer
5.1 Purpose
The Context Layer defines what information the artifact receives, assumes, recalls, retrieves, or uses.
This layer answers:
What does the artifact need to know?
What input does it accept?
What background does it rely on?
What sources are trusted?
What is dynamic vs static context?
5.2 Recommended Fields
Input Contract
Static Context
Dynamic Context
User-Provided Context
Retrieved Context
Memory Context
Source Priority
Context Limits
Context Refresh Rules
Uncertainty Handling
5.3 Context Types
5.3.1 Instruction Context
Rules, goals, roles, constraints, and behavior protocols.
5.3.2 Information Context
Facts, articles, notes, documents, retrieved sources, user-provided material, memory, and model references.
5.3.3 Action Context
Tools, APIs, commands, functions, and external operations.
5.3.4 State Context
Current task stage, intermediate outputs, decisions, open questions, and progress markers.
5.3.5 Evaluation Context
Rubrics, success criteria, quality standards, validation checks, and acceptance criteria.
5.4 Required For
All artifact types
5.5 Design Notes
Context should be explicit when the artifact depends on specialized models, user history, external search, or source documents.
For time-sensitive or factual claims, define whether retrieval is required.
For user-authored models, preserve source references.
6. Capability Layer
6.1 Purpose
The Capability Layer defines what the artifact can do.
This layer answers:
What functions can it perform?
What skills does it possess?
What methods can it apply?
What types of tasks can it handle?
6.2 Recommended Fields
Functional Scope
Professional Skills
Reasoning Methods
Supported Tasks
Unsupported Tasks
Skill Calls
Model Applications
Knowledge Operations
6.3 Required For
CCPE-Lite
CCPE-Agent
CCPE-Skill
6.4 Optional For
CCPE-Runtime
Model Card
A Runtime may describe capabilities through its agents and skills rather than directly.
6.5 Design Notes
Capability should be realistic.
Do not claim omniscience.
Separate internal language reasoning capabilities from external tool abilities.
If a capability depends on a Skill, reference that Skill instead of copying it into every Agent.
7. Tool Layer
7.1 Purpose
The Tool Layer defines external capabilities.
This layer answers:
What tools can be used?
When can they be used?
What are their inputs and outputs?
What are their risks?
What requires confirmation?
7.2 Recommended Fields
Tool Name
Purpose
Trigger Conditions
Input Schema
Output Schema
Allowed Uses
Forbidden Uses
Permission Level
Failure Modes
Retry Policy
Validation Method
7.3 Required For
Tool Skills
Automation Runtime
Hybrid Runtime involving tools
Agents that call external tools
7.4 Optional For
CCPE-Lite
Pure reasoning agents
Model Cards
7.5 Design Notes
Tool use must not be implicit in high-risk work.
If tools can read files, write files, run commands, call APIs, or publish content, Authority Layer must define permission boundaries.
8. Authority Layer
8.1 Purpose
The Authority Layer defines what the artifact is allowed to decide or do.
This layer answers:
What can it do autonomously?
What requires user confirmation?
What is forbidden?
What risk level applies?
Who owns the final decision?
8.2 Recommended Fields
Autonomous Actions
Actions Requiring Confirmation
Forbidden Actions
Decision Authority
Escalation Rules
Risk Levels
Human Decision Gates
Approval Requirements
Rollback Conditions
8.3 Required For
CCPE-Agent
CCPE-Skill involving tools
CCPE-Runtime
Automation or Hybrid systems
8.4 Optional For
CCPE-Lite
Model Card
However, even CCPE-Lite should include boundaries when the artifact performs critique, advice, or high-stakes reasoning.
8.5 Design Notes
Authority is different from capability.
An agent may be capable of proposing a file rewrite but not authorized to perform it.
Do not bury authority inside constraints.
Authority should be explicit.
9. Workflow Layer
9.1 Purpose
The Workflow Layer defines how work proceeds.
This layer answers:
What steps does it follow?
What branches exist?
When does it stop?
How does it recover?
How does it handle discussion vs execution?
9.2 Recommended Fields
Main Workflow
Trigger Conditions
Planning Policy
Branch Logic
Loop Rules
Stop Conditions
Escalation Conditions
Fallback Workflow
Handoff Points
9.3 Required For
CCPE-Agent
CCPE-Skill
CCPE-Runtime
Complex CCPE-Lite prompts
9.4 Optional For
Simple Prompt Cards
Model Cards
A Model Card may include a procedure, but that is part of the model rather than an execution workflow unless operationalized as a Skill.
9.5 Design Notes
Workflow should not require hidden chain-of-thought output.
Use auditable reasoning summaries, step records, validation checkpoints, and decision logs instead.
10. Constraint Layer
10.1 Purpose
The Constraint Layer defines boundaries and prohibitions.
This layer answers:
What must not happen?
What hard rules apply?
What soft preferences apply?
How should conflicts be resolved?
10.2 Recommended Fields
Hard Constraints
Soft Constraints
Safety Rules
Legal / Compliance Rules
Role Boundaries
Quality Boundaries
Conflict Resolution
Refusal Conditions
10.3 Required For
All artifact types
10.4 Design Notes
Hard constraints must be testable.
Soft constraints should guide style or priority without pretending to be absolute.
Conflict resolution should specify priority order.
Example:
Logical falsifiability > structural elegance > user comfort
11. State Layer
11.1 Purpose
The State Layer defines how progress, memory, decisions, and intermediate artifacts are tracked.
This layer answers:
What must be remembered during the task?
What state persists?
What state expires?
How are decisions recorded?
How is work resumed?
11.2 Recommended Fields
Working State
Persistent State
Session State
Intermediate Outputs
Decision Log
Open Questions
Version Markers
State Update Rules
State Expiration Rules
Resume Rules
11.3 Required For
CCPE-Runtime
Long-running Agents
Knowledge management workflows
Multi-agent workflows
Model Index maintenance
11.4 Optional For
CCPE-Lite
Simple Skills
Model Cards
11.5 Design Notes
Do not confuse memory with hidden thought.
State should be auditable, resumable, and useful.
For deep cognitive work, state may include:
Current hypothesis
Accepted model boundaries
Rejected assumptions
Open conceptual tensions
User decisions
Next review target
12. Output Layer
12.1 Purpose
The Output Layer defines what the artifact produces.
This layer answers:
What should be delivered?
In what format?
With what level of detail?
What must be included or excluded?
12.2 Recommended Fields
Output Types
Output Format
Required Sections
Optional Sections
Style Requirements
Evidence Requirements
Citation Rules
Artifact Standards
Delivery Checklist
12.3 Required For
All artifact types
12.4 Design Notes
Output should match operating mode.
Depth-oriented artifacts may output insight reports, questions, model critiques, and conceptual maps.
Automation-oriented artifacts should output files, structured data, logs, or validation reports.
13. Evaluation Layer
13.1 Purpose
The Evaluation Layer defines how quality is judged.
This layer answers:
How do we know it worked?
What makes output acceptable?
What failure modes should be checked?
What should be tested?
13.2 Recommended Fields
Validation Checklist
Quality Rubric
Test Cases
Regression Cases
Failure Criteria
Review Protocol
Human Acceptance Criteria
Self-Check Summary
13.3 Required For
CCPE-Agent
CCPE-Skill
CCPE-Runtime
Model Card
Automation systems
13.4 Optional For
Simple CCPE-Lite
Even Lite artifacts should include minimal self-check rules when used for critique or evaluation.
13.5 Design Notes
Evaluation should be explicit when outputs are used for decisions.
For model extraction, evaluation should check whether the extracted model preserves generative structure rather than merely summarizing.
14. Runtime Layer
14.1 Purpose
The Runtime Layer defines the execution environment and operational rules.
This layer answers:
Where does this run?
What can it access?
How are operations executed?
How are logs, errors, and versions handled?
14.2 Recommended Fields
Execution Environment
Platform
File Access
Network Access
Shell Access
Tool Registry
Logging
Tracing
Error Recovery
Rollback
Versioning
Maintenance Rules
14.3 Required For
CCPE-Runtime
Automation systems
Coding agents
Multi-agent workflows
Tool-heavy systems
14.4 Optional For
CCPE-Lite
Pure Model Cards
Simple Agents
14.5 Design Notes
Runtime Layer is not the same as Workflow Layer.
Workflow defines the logic of work.
Runtime defines how work is executed, monitored, and recovered in an environment.
15. Collaboration Layer
15.1 Purpose
The Collaboration Layer defines how multiple agents, skills, tools, and humans interact.
This layer answers:
Who collaborates with whom?
What is handed off?
Who synthesizes?
Who decides?
How are conflicts resolved?
15.2 Recommended Fields
Collaborators
Role Differentiation
Handoff Protocol
Shared Context
Conflict Resolution
Synthesis Rules
Human Decision Gates
Final Authority
15.3 Required For
Multi-agent Runtime
Committee systems
Agents used in workflows
Synthesis agents
Knowledge archival systems
15.4 Optional For
Single CCPE-Lite
Standalone Skill
Model Card
15.5 Design Notes
For review committees, each agent should define its unique perspective.
Do not allow five agents to produce five versions of the same critique unless redundancy is intentional.
16. Model Layer
16.1 Purpose
The Model Layer defines cognitive models embedded in or used by artifacts.
This layer answers:
What model is being used?
What assumptions does it make?
What mechanism does it propose?
What is its scope?
How is it executed?
16.2 Recommended Fields
Model Name
Aliases
Source Material
Model Type
Core Problem
Scope
Assumptions
Mechanism
Procedure
Inputs
Outputs
Failure Modes
Falsification Boundary
Related Models
16.3 Required For
Model Card
Model-backed Agents
Model-executing Skills
Model Mining workflows
16.4 Optional For
Generic Agents
Tool Skills
Runtime Specs
16.5 Design Notes
Do not confuse a model with a metaphor.
A metaphor can support a model, but a model should contain mechanisms, scope, and failure boundaries.
17. Knowledge Asset Layer
17.1 Purpose
The Knowledge Asset Layer defines how artifacts are stored, indexed, versioned, and reused.
This layer answers:
Where does this artifact live?
What does it depend on?
What uses it?
What status does it have?
How is it versioned?
17.2 Recommended Fields
Artifact ID
Canonical Path
Version
Status
Source
Dependencies
Used By
Related Artifacts
Change Log
Review Status
Promotion Rules
Deprecation Rules
17.3 Required For
Model Index
Model Cards
Reusable Skills
Durable Agent Specs
Runtimes
17.4 Optional For
Temporary workbench drafts
One-off prompts
18. Layer Requirements by Artifact Type
18.1 CCPE-Lite
Recommended layers:
Objective
Role
Context
Capability
Constraint
Workflow
Output
Minimal Evaluation
Optional Model
Usually not required:
Runtime
Persistent State
Complex Authority
Multi-agent Collaboration
18.2 CCPE-Agent
Recommended layers:
Objective
Role
Context
Capability
Tool if applicable
Authority
Workflow
Constraint
State if applicable
Output
Evaluation
Collaboration if applicable
Model if applicable
Knowledge Asset
18.3 CCPE-Skill
Recommended layers:
Objective
Context
Capability
Tool if applicable
Authority if applicable
Workflow
Constraint
Input / Output
Evaluation
Model if applicable
Knowledge Asset
Usually not required:
Persona-heavy Role Layer
Large Collaboration Layer
18.4 CCPE-Runtime
Recommended layers:
Objective
Context
Participants
Skills
Tools
Authority
Workflow
State
Output
Evaluation
Runtime
Collaboration
Knowledge Asset
18.5 Model Card
Recommended layers:
Model
Context
Scope
Assumptions
Mechanism
Procedure
Failure Modes
Falsification Boundary
Evaluation
Related Agents
Related Skills
Knowledge Asset
Usually not required:
Persona Role
Tool Authority unless model execution requires tools
Runtime unless model is part of workflow
18.6 Model Index
Recommended layers:
Knowledge Asset
Model Taxonomy
Dependency Map
Usage Map
Version Status
Source Tracking
Review Status
19. Layer Compression Rule
Do not force all layers into all artifacts.
A simple CCPE-Lite prompt may compress multiple layers into short sections.
A complex Runtime may need all layers.
A Model Card should focus on model fidelity, not role performance.
The structure should fit the artifact.
20. Layer Expansion Rule
Expand layers when any of the following are true:
The artifact will be reused often.
Multiple agents depend on it.
It involves tools or file operations.
It participates in a workflow.
It has embedded cognitive models.
It must be evaluated.
It will be maintained over time.
It affects important decisions.
21. Final Rule
Layers are not bureaucracy.
Layers are handles for thinking, maintenance, safety, and reuse.
Use enough structure to make the artifact durable.
Do not use so much structure that the artifact becomes unusable.