6.1 KiB
CCPE Boundaries
1. Purpose
This document defines what CCPE System owns, what it only registers, and what it must leave in other repositories.
The goal is to prevent CCPE from becoming:
a project execution repository
an automation script source repository
a deployed agentic application framework
a copy of upstream methodology documents
CCPE is an architecture forge and supplier layer for AI artifacts. More specifically, it is the forge for expert agents, cognitive models, reusable methods, and invocation contracts.
2. System Position
CCPE sits between high-level methodology and concrete project execution.
HiFi Agent Studio
= top-level principles and architecture philosophy
Agentic Engineering Handbook
= operating governance and field rules
CCPE System
= prompt / agent / skill / runtime / model / integration architecture forge
Project workbenches and vaults
= concrete project execution, records, materials, drafts, and runbooks
skills-vault / MCP / CLI / API services
= implementation and external capability layer
CCPE may reference higher-level methodology and external capability sources. It should not copy their full content or become their implementation source.
3. What CCPE Owns
CCPE owns reusable AI architecture assets:
CCPE-Lite prompt cards
CCPE-Agent specs
CCPE-Committee specs
CCPE-Skill specs for cognitive, method, workflow, and evaluation capabilities
CCPE-Runtime specs
Model Cards
Model Index entries
Integration Registrations
quality rubrics
invocation protocols
migration policies
artifact templates
CCPE should accept a requested artifact only when it has CCPE value. A request has CCPE value when it requires expert hidden experience, a stable cognitive model, a reusable method, a durable role, a cross-project invocation contract, or high-risk cognitive boundary management. If a request is merely project-local prompt glue, one-off formatting, immature model experimentation, a sample run, or a project decision about when to invoke an existing artifact, CCPE should return it to the owning project repository.
CCPE may design both:
development agents
= agents for the user's own local work, such as creation, review, planning, sales support, project planning, system design, or output production
production / business agents
= agents intended for deployed intelligent systems
For production / business agents, CCPE owns the specification and governance layer. The concrete development project owns framework implementation, deployment, state, monitoring, and application behavior.
4. What Project Repositories Own
Project repositories own concrete execution.
Examples:
writing-workbench
video-workbench
knowledge-vault
work-projects/*
These repositories should own:
requirements submitted to CCPE
project runbooks
project-specific context packs
source digests for one project
returned participant outputs
drafts and revisions
decision records
process logs
publication metadata
project handoffs
application code and deployment configuration
project-local prompt adapters and glue prompts
sample runs and trial outputs
model exploration before stable CCPE-worthy versions exist
decisions about when to invoke existing CCPE agents, Skills, runtimes, or external reviewers
CCPE may supply the agents, protocols, and rules used by those projects, but it should not store the project-specific run history.
5. What skills-vault Owns
skills-vault owns automation-oriented Skill source.
This includes:
SKILL.md
scripts
tests
fixtures
examples
installation notes
migration records
deterministic tool logic
Examples:
fix-title
markdown-normalizer
citation-checker
report-exporter
source-splitter
tts-batch-generator
image-prompt-exporter
These are not CCPE source assets unless they become method or governance specs. If a CCPE Runtime or Agent formally depends on one, CCPE should register the dependency rather than copying the source.
6. What Integration Registration Covers
Integration Registration is used when CCPE depends on a capability it does not own.
Possible integrations:
skills-vault automation skills
MCP servers
CLI tools
API services
installed local skills
platform-specific capabilities
agentic development frameworks
Registration records architecture metadata:
canonical implementation
installed path or endpoint
used_by
authority
allowed operations
forbidden operations
side effects
security notes
validation
failure behavior
status
version
Registration does not copy implementation source.
7. Requirement-First Supplier Rule
CCPE should not invent project workflows before a project needs them.
Preferred flow:
project repository identifies a real use case
project writes or states a requirement
CCPE classifies the requirement
CCPE supplies the smallest appropriate artifact
project repository runs the concrete workflow
project returns feedback or new requirements
This reverses the older pattern where CCPE first discussed a business scenario internally, built assets, and then expected project repositories to adapt around them.
8. No-Simulation Boundary
Formal participant output must come from real invocation.
The following are not execution:
dispatch packet only
prompt-to-send only
controller summary
main-session role-played reviewer output
If a participant cannot be truly invoked, the state must remain:
blocked_waiting_for_participant_output
Simulation may be used for planning only when labeled:
simulation_only: true
formal_output: false
excluded_from_synthesis: true
9. Boundary Decision Checklist
Before creating or moving an artifact, answer:
Does this artifact define a reusable AI role, method, model, runtime, or governance contract?
Does it belong to one project execution history?
Is it deterministic automation source?
Is it implementation code for a deployed system?
Is CCPE the owner, or only the architecture registrar?
Who will consume the artifact next?
What must not be copied into CCPE?
If ownership is unclear, write an analysis note in workbench/analysis/ before changing canonical directories.