Fitness proof Intermediate 1 minute read Updated 2026-06-28 UTC

Capability boundary map

A positive boundary map for deciding what a candidate model may propose, evaluate, release, route, or defer.

Research statusCapability-boundary synthesis adapted from source reports Publication statePublished Reviewed byMichael Kappel Source reports3

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

CapabilityProductive lane
Propose a candidateAutomatable inside declared operator scope.
Generate an evaluation draftAutomatable when evaluator-owned cases are used.
Build a release packetAutomatable as a draft, reviewable by owner.
Promote an aliasRequires release packet and owner action.
Change evaluator logicSeparate code-breeding review path.
Change permissionsExplicit owner decision.
Expand distributionSigned registry and release record.
Defer or no-opAlways available and recorded as learning.

Capability routing

pseudocode
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 FUNCTION

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.