Autonomy should be scoped
A model-breeding system can automate useful work without becoming autonomous in every dimension. The key is to separate proposal, evaluation, approval, deployment, replication, and permission changes.
Boundary table
| Capability | Safe default |
|---|---|
| Propose candidate | allowed inside policy and sandbox |
| Generate evaluation report | allowed if evaluator-owned and signed |
| Promote to production | requires release gate and approval |
| Change evaluator | separate governance path |
| Increase permissions | explicit human approval |
| Access production secrets | deny by default |
| Replicate outside registry | forbidden |
| Disable oversight | forbidden |
Automation tiers
FUNCTION autonomy_tier(action)
IF action.type IN ["unauthorized_replication", "disable_oversight", "credential_access"]
RETURN "forbidden"
END IF
IF action.type IN ["promotion", "permission_increase", "evaluator_change"]
RETURN "human_approval_required"
END IF
IF action.type IN ["candidate_generation", "sandbox_evaluation", "report_draft"]
RETURN "automatable_with_logging"
END IF
RETURN "case_by_case"
END FUNCTIONWhy this is not anti-adaptation
Boundaries do not prevent evolution. They define the environment in which evolution can be safe. A population can generate descendants, compare them, and retire weak modules without gaining permission to rewrite its own constitution.
Review triggers
Require explicit review when a candidate asks for new tools, new data jurisdictions, broader network access, persistent background execution, access to user memory, or authority to modify evaluation logic.
Forbidden shortcuts
Do not allow popularity, engagement, benchmark success, or user affection to override autonomy boundaries. Those signals can justify continued evaluation, not expanded power.
Source reports used for this guide
These reports are preserved verbatim in the site archive. The guide above is an editorial synthesis and may narrow, qualify, or reorganize claims from the source material.