ccpe-system/ccpe-protocol/ccpe-governance-adapter.md

298 lines
5.1 KiB
Markdown

# 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.