80 lines
4.1 KiB
Markdown
80 lines
4.1 KiB
Markdown
# 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
|
|
|
|
1. Introduce a governed development control plane. `ExtensionProposal` is an
|
|
evidence-bearing request that moves through review, implementation and
|
|
promotion stages.
|
|
2. 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.
|
|
3. 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.
|
|
4. A human-authorized governance boundary approves task scope and promotion.
|
|
Cognitive components may propose and summarize evidence; promotion remains
|
|
an explicit governance decision.
|
|
5. 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.
|
|
6. Candidate lifecycle is explicit: `PROPOSED`, `REJECTED`, `SANDBOXED`,
|
|
`EVALUATING`, `CANARY`, `PROMOTED`, `ROLLED_BACK`, `RETIRED` and `BLOCKED`.
|
|
Promotion is bounded by capability registration, traffic, budget and
|
|
telemetry policy. A candidate never receives authority merely by passing
|
|
model evaluation.
|
|
7. 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.
|
|
8. 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.
|