5.1 KiB
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:
QPI class
task nature
reuse level
run mode
depth vs automation orientation
consumer repository
QPI class:
Q = information gap
P = path / production / transformation problem
I = order / judgment / responsibility problem
Task nature:
one-off output
reusable capability
governed system building
model calibration
exploratory rehearsal
Reuse level:
one-off
reusable
governed
Run mode:
Lite
Standard
Full
Default to Lite unless evidence requires escalation.
3. Cost Ledger
For substantial work, distinguish:
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:
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:
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:
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:
target output
brief input record
human confirmation
optional sample check
5.2 Standard
Use for:
future reuse
clear downstream consumer
context package needed
small number of real participant invocations
key human gate required
Typical outputs:
source or context pack
confirmed structure
reusable artifacts
decision record
targeted audit
minimal invocation record
5.3 Full
Use for:
many roles
many sources
high risk
accountability requirement
long cycle
external delivery
process authenticity required downstream
Typical outputs:
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:
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:
responsibility
inputs
outputs
authority_level
allowed_tools
forbidden_actions
required_skills
related_models
handoff_rules
evaluation
invocation_requirements
failure_modes
Integration registrations should include:
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:
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:
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:
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:
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.