# CCPE Governance Adapter ## 1. Purpose This document adapts broader agentic engineering governance into CCPE artifact design without copying an entire external handbook into this repository. CCPE should reference higher-level methodology when needed, but local CCPE artifacts must still carry the governance fields needed for safe use. ## 2. Intake Before Artifact Design Before designing or refactoring an artifact, classify the request by: ```text QPI class task nature reuse level run mode depth vs automation orientation consumer repository ``` QPI class: ```text Q = information gap P = path / production / transformation problem I = order / judgment / responsibility problem ``` Task nature: ```text one-off output reusable capability governed system building model calibration exploratory rehearsal ``` Reuse level: ```text one-off reusable governed ``` Run mode: ```text Lite Standard Full ``` Default to Lite unless evidence requires escalation. ## 3. Cost Ledger For substantial work, distinguish: ```text Content Cost System-Building Cost Calibration Cost Exploration Cost ``` Do not present system-building cost as if it were normal content production cost. If a small source task expands into protocol design, runtime building, worker orchestration, audit logs, or no-simulation validation, reclassify the work and ask for human confirmation before continuing. ## 4. Scope Drift Detector Pause and reclassify when a task starts showing these signals: ```text one-off task begins creating reusable protocol new agents, skills, runtimes, or directories are introduced original output is delayed while governance artifacts multiply Lite task dispatches multiple workers P-domain work drifts into I-domain governance budget is exceeded invocation, authority, state, or audit becomes central ``` Required response: ```text pause name the drift ask whether this is still the original task if not, reclassify as system-building or governed work separate the cost ledger continue only after human confirmation ``` ## 5. Runtime Maturity Modes ### 5.1 Lite Use for: ```text one-off task low risk single model can handle it no true multi-agent requirement no full trace requirement downstream does not depend on process evidence ``` Typical outputs: ```text target output brief input record human confirmation optional sample check ``` ### 5.2 Standard Use for: ```text future reuse clear downstream consumer context package needed small number of real participant invocations key human gate required ``` Typical outputs: ```text source or context pack confirmed structure reusable artifacts decision record targeted audit minimal invocation record ``` ### 5.3 Full Use for: ```text many roles many sources high risk accountability requirement long cycle external delivery process authenticity required downstream ``` Typical outputs: ```text full runtime invocation records authority map state machine coverage audit distortion risk log recovery protocol downstream handoff ``` ## 6. Required Governance Fields Runtime specs should include: ```text runtime_orientation mode qpi_class participants human_gates state_protocol invocation_authenticity simulation_labeling authority_matrix tool_permissions source_fidelity evaluation_level stop_rule handoff_rules related_models related_skills related_integrations ``` Agent specs should include: ```text responsibility inputs outputs authority_level allowed_tools forbidden_actions required_skills related_models handoff_rules evaluation invocation_requirements failure_modes ``` Integration registrations should include: ```text canonical_implementation installed_path_or_endpoint used_by authority allowed_operations forbidden_operations side_effects security_notes validation failure_behavior status ``` ## 7. Human Gate Contract Human gates must be explicit. Each gate should record: ```text gate_id decision_owner input_artifacts decision_options default_action downstream_effect reversibility escalation_condition record_path ``` Do not use vague "wait for user confirmation" text when the decision changes downstream authority or artifact status. ## 8. Execution Authenticity Formal participant output requires real invocation evidence. Minimum invocation record: ```text participant id canonical artifact path invocation carrier thread / session / platform id when available input context returned output path timestamp whether output enters synthesis ``` Packet-only and prompt-to-send-only are not execution. ## 9. Evaluation Stack Use the lightest evaluation level that fits the risk: ```text E0 Smoke Test E1 Format Test E2 Factual Test E3 Reasoning Test E4 Expert Similarity E5 Decision Utility E6 Calibration Test E7 Governance Test ``` Suggested defaults: ```text Lite: E0-E2 Standard: E0-E5 Full: E0-E7 ``` ## 10. Platform and Framework Boundary Codex, Claude Code, OpenClaw, Superpowers, LangGraph, CrewAI, and similar systems may execute or host CCPE-designed artifacts. They do not override CCPE's classification, no-simulation, authority, and boundary rules. For deployed systems, CCPE should stop at specification, evaluation, and governance contracts unless the user explicitly asks to work in the concrete application repository.