# 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: ```text 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. ## 2. System Position CCPE sits between high-level methodology and concrete project execution. ```text 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: ```text 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 may design both: ```text 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: ```text writing-workbench video-workbench knowledge-vault work-projects/* ``` These repositories should own: ```text 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 ``` 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: ```text SKILL.md scripts tests fixtures examples installation notes migration records deterministic tool logic ``` Examples: ```text 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: ```text skills-vault automation skills MCP servers CLI tools API services installed local skills platform-specific capabilities agentic development frameworks ``` Registration records architecture metadata: ```text 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: ```text 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: ```text 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: ```text blocked_waiting_for_participant_output ``` Simulation may be used for planning only when labeled: ```yaml simulation_only: true formal_output: false excluded_from_synthesis: true ``` ## 9. Boundary Decision Checklist Before creating or moving an artifact, answer: ```text 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.