4.1 KiB
Proposal ADR-0022 — Governed Self-Development V1
Status: Proposed Task: DEV-000106
Problem and evidence
The audit found ReflectionCandidates and capability evidence, but no safe pipeline for turning repeated evidence into a reviewed change. Direct self-editing would let model output alter source, skills, authority or production without provenance, evaluation or rollback.
Decision proposed
- Introduce a governed development control plane.
ExtensionProposalis an evidence-bearing request that moves through review, implementation and promotion stages. - A proposal must reference repeated or corroborated evidence, desired outcome, smallest change layer, affected owners/contracts, assumptions, alternatives, risk tier, evaluation plan, rollback and emergency-stop conditions. One accidental failure is insufficient; duplicate evidence is deduplicated without deleting its history.
- Candidate artifacts are immutable, content-addressed and lineage-linked to the proposal, task packet, source revision, generator/author identity, tests, evaluations and environment. Candidate code, skill, adapter or configuration is created only in an isolated branch/worktree/sandbox with no protected-main, production or ambient-secret access.
- A human-authorized governance boundary approves task scope and promotion. Cognitive components may propose and summarize evidence; promotion remains an explicit governance decision.
- Evaluation is layered: contract/architecture/security checks, deterministic unit/integration tests, adversarial and regression corpus, migration/ recovery checks, and independent verifier review. Failed, conflicting or incomplete evidence blocks promotion and remains attributable.
- Candidate lifecycle is explicit:
PROPOSED,REJECTED,SANDBOXED,EVALUATING,CANARY,PROMOTED,ROLLED_BACK,RETIREDandBLOCKED. Promotion is bounded by capability registration, traffic, budget and telemetry policy. A candidate never receives authority merely by passing model evaluation. - Canary state keeps the previous implementation addressable. Rollback is a durable, reversible selection change with an emergency stop that disables candidate traffic without deleting evidence, artifacts or lineage.
- Generated skills, modules, adapters and configuration follow the same ordinary development path: typed owners, task scope, architecture checks, tests, security review, migration/recovery plan and independent verification.
Ownership and boundaries
Epistemics owns evidence and ReflectionCandidates; Capability owns implementation/skill registration and lifecycle; Work owns task/delegation execution; Artifact owns candidate and evaluation metadata; Authority owns human promotion permission; Commit/Executor owns external mutation. No new universal LearningManager or self-development owner is introduced.
Three boundaries are essential: candidate work uses the declared task scope, secret access follows existing CredentialRef policy, and candidate promotion does not itself grant new authority. Original intent, truth assessments and historical evidence retain their existing owners and provenance.
Rationale
Evidence, scoped implementation, independent evaluation and reversible promotion provide a practical improvement loop while keeping authority and provenance explicit. The design uses existing Epistemics, Capability, Work, Artifact and Authority boundaries instead of adding a new universal manager.
Consequences, migration and rollback
The proposal creates an auditable path for improvement while adding review, evaluation and artifact-retention cost. There is no implementation, schema or production change here. Implementation starts with a deterministic proposal fixture and fake candidate, then uses opt-in canary traffic. Rollback disables candidate selection and restores the previous implementation reference; evidence and failed candidates remain available for analysis.
Revisit if a candidate requires new authority, cross-owner direct storage, unreviewed external mutation, or if rollback cannot restore the previous implementation deterministically.