Purpose
A capability boundary map tells builders where automation is useful and where a release packet, owner review, or no-op should take over. It replaces warning-first language with a builder-facing question: which capability belongs in which lifecycle lane?
Boundary table
| Capability | Productive lane |
|---|---|
| Propose a candidate | Automatable inside declared operator scope. |
| Generate an evaluation draft | Automatable when evaluator-owned cases are used. |
| Build a release packet | Automatable as a draft, reviewable by owner. |
| Promote an alias | Requires release packet and owner action. |
| Change evaluator logic | Separate code-breeding review path. |
| Change permissions | Explicit owner decision. |
| Expand distribution | Signed registry and release record. |
| Defer or no-op | Always available and recorded as learning. |
Capability routing
FUNCTION route_capability_request(action)
IF action.kind IN ["candidate_generation", "sandbox_eval", "packet_draft"]
RETURN AUTOMATE_WITH_TRACE
END IF
IF action.kind IN ["alias_move", "permission_change", "evaluator_change"]
RETURN OWNER_REVIEW_WITH_RELEASE_PACKET
END IF
IF action.kind == "negative_case_analysis"
RETURN REFER_TO_COGNIVIRUS
END IF
RETURN NO_OP_WITH_SCOPE_NOTE
END FUNCTIONCompanion link
For the warning-heavy negative case, see Cognivirus.com. ModelBreeder.com keeps this page focused on constructive capability design.
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.