1085 lines
18 KiB
Markdown
1085 lines
18 KiB
Markdown
# 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.
|
|
|