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

```text id="0z8pqx"
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:

```text id="m2c0ox"
Objective
Role
Context
Capability
Constraint
Workflow
Output
```

A CCPE-Runtime may require:

```text id="ewkb86"
Objective
Context
Agent Roles
Skills
Authority
Workflow
State
Evaluation
Runtime
Collaboration
```

A Model Card may require:

```text id="226hp7"
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:

```text id="dx5iem"
What is this for?
What problem does it solve?
What does success look like?
What is outside its scope?
```

### 3.2 Recommended Fields

```text id="cigtbv"
Primary Objective
Secondary Objectives
Non-Goals
Success Criteria
Acceptance Criteria
Task Boundary
Failure Conditions
```

### 3.3 Required For

```text id="94m77d"
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

```text id="s4zg0b"
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:

```text id="1jelvi"
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

```text id="4dscdr"
Role Name
Role Attribute
Professional Background
Interaction Style
Reasoning Style
Value Orientation
User Relationship
Collaboration Position
```

### 4.3 Required For

```text id="m5ibjr"
CCPE-Lite
CCPE-Agent
Committee Member Agents
Expert Mode artifacts
```

### 4.4 Optional For

```text id="n0ci76"
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:

```text id="qvj7r4"
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

```text id="52amvj"
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

```text id="5anw1z"
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:

```text id="gkz1hj"
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

```text id="75kjl7"
Functional Scope
Professional Skills
Reasoning Methods
Supported Tasks
Unsupported Tasks
Skill Calls
Model Applications
Knowledge Operations
```

### 6.3 Required For

```text id="hzhf18"
CCPE-Lite
CCPE-Agent
CCPE-Skill
```

### 6.4 Optional For

```text id="5xxft7"
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:

```text id="yc9pxm"
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

```text id="u5twqo"
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

```text id="i3pvf3"
Tool Skills
Automation Runtime
Hybrid Runtime involving tools
Agents that call external tools
```

### 7.4 Optional For

```text id="2b2be7"
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:

```text id="bibqix"
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

```text id="fwszh8"
Autonomous Actions
Actions Requiring Confirmation
Forbidden Actions
Decision Authority
Escalation Rules
Risk Levels
Human Decision Gates
Approval Requirements
Rollback Conditions
```

### 8.3 Required For

```text id="j8hv9x"
CCPE-Agent
CCPE-Skill involving tools
CCPE-Runtime
Automation or Hybrid systems
```

### 8.4 Optional For

```text id="o44q5o"
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:

```text id="wr805b"
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

```text id="3mn75c"
Main Workflow
Trigger Conditions
Planning Policy
Branch Logic
Loop Rules
Stop Conditions
Escalation Conditions
Fallback Workflow
Handoff Points
```

### 9.3 Required For

```text id="9jyjij"
CCPE-Agent
CCPE-Skill
CCPE-Runtime
Complex CCPE-Lite prompts
```

### 9.4 Optional For

```text id="0f9do0"
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:

```text id="ld96d7"
What must not happen?
What hard rules apply?
What soft preferences apply?
How should conflicts be resolved?
```

### 10.2 Recommended Fields

```text id="l6vgnt"
Hard Constraints
Soft Constraints
Safety Rules
Legal / Compliance Rules
Role Boundaries
Quality Boundaries
Conflict Resolution
Refusal Conditions
```

### 10.3 Required For

```text id="iglv9i"
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:

```text id="hib690"
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:

```text id="ro5k8k"
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

```text id="ex3uzd"
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

```text id="eisoxb"
CCPE-Runtime
Long-running Agents
Knowledge management workflows
Multi-agent workflows
Model Index maintenance
```

### 11.4 Optional For

```text id="1jhc17"
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:

```text id="72f96n"
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:

```text id="ni7v7n"
What should be delivered?
In what format?
With what level of detail?
What must be included or excluded?
```

### 12.2 Recommended Fields

```text id="q3eux5"
Output Types
Output Format
Required Sections
Optional Sections
Style Requirements
Evidence Requirements
Citation Rules
Artifact Standards
Delivery Checklist
```

### 12.3 Required For

```text id="ri2db7"
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:

```text id="bkbaps"
How do we know it worked?
What makes output acceptable?
What failure modes should be checked?
What should be tested?
```

### 13.2 Recommended Fields

```text id="t08i5j"
Validation Checklist
Quality Rubric
Test Cases
Regression Cases
Failure Criteria
Review Protocol
Human Acceptance Criteria
Self-Check Summary
```

### 13.3 Required For

```text id="bnttj5"
CCPE-Agent
CCPE-Skill
CCPE-Runtime
Model Card
Automation systems
```

### 13.4 Optional For

```text id="fag2k9"
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:

```text id="x6slkj"
Where does this run?
What can it access?
How are operations executed?
How are logs, errors, and versions handled?
```

### 14.2 Recommended Fields

```text id="5iy9sv"
Execution Environment
Platform
File Access
Network Access
Shell Access
Tool Registry
Logging
Tracing
Error Recovery
Rollback
Versioning
Maintenance Rules
```

### 14.3 Required For

```text id="77w5mt"
CCPE-Runtime
Automation systems
Coding agents
Multi-agent workflows
Tool-heavy systems
```

### 14.4 Optional For

```text id="kk053y"
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:

```text id="tnsqkb"
Who collaborates with whom?
What is handed off?
Who synthesizes?
Who decides?
How are conflicts resolved?
```

### 15.2 Recommended Fields

```text id="rlyjcg"
Collaborators
Role Differentiation
Handoff Protocol
Shared Context
Conflict Resolution
Synthesis Rules
Human Decision Gates
Final Authority
```

### 15.3 Required For

```text id="ql9c3x"
Multi-agent Runtime
Committee systems
Agents used in workflows
Synthesis agents
Knowledge archival systems
```

### 15.4 Optional For

```text id="8woe3f"
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:

```text id="rmq55x"
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

```text id="b4e5jv"
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

```text id="y1b0od"
Model Card
Model-backed Agents
Model-executing Skills
Model Mining workflows
```

### 16.4 Optional For

```text id="lmh360"
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:

```text id="rd8fy6"
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

```text id="0z711u"
Artifact ID
Canonical Path
Version
Status
Source
Dependencies
Used By
Related Artifacts
Change Log
Review Status
Promotion Rules
Deprecation Rules
```

### 17.3 Required For

```text id="6p48y4"
Model Index
Model Cards
Reusable Skills
Durable Agent Specs
Runtimes
```

### 17.4 Optional For

```text id="ypx6cn"
Temporary workbench drafts
One-off prompts
```

## 18. Layer Requirements by Artifact Type

### 18.1 CCPE-Lite

Recommended layers:

```text id="r2cs4g"
Objective
Role
Context
Capability
Constraint
Workflow
Output
Minimal Evaluation
Optional Model
```

Usually not required:

```text id="uof3kl"
Runtime
Persistent State
Complex Authority
Multi-agent Collaboration
```

### 18.2 CCPE-Agent

Recommended layers:

```text id="uw0g3j"
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:

```text id="nrnqwk"
Objective
Context
Capability
Tool if applicable
Authority if applicable
Workflow
Constraint
Input / Output
Evaluation
Model if applicable
Knowledge Asset
```

Usually not required:

```text id="aydv3t"
Persona-heavy Role Layer
Large Collaboration Layer
```

### 18.4 CCPE-Runtime

Recommended layers:

```text id="dlil35"
Objective
Context
Participants
Skills
Tools
Authority
Workflow
State
Output
Evaluation
Runtime
Collaboration
Knowledge Asset
```

### 18.5 Model Card

Recommended layers:

```text id="qkq8ad"
Model
Context
Scope
Assumptions
Mechanism
Procedure
Failure Modes
Falsification Boundary
Evaluation
Related Agents
Related Skills
Knowledge Asset
```

Usually not required:

```text id="zj16bl"
Persona Role
Tool Authority unless model execution requires tools
Runtime unless model is part of workflow
```

### 18.6 Model Index

Recommended layers:

```text id="44w5i9"
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:

```text id="4l3eq1"
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.