A.15:4.3 - Bounded specialization scouting and CheckpointReturn
When one human-plus-AI pair faces a new task or solution family, identify each participating human or AI service as an admitted System before using this alignment. The pair may use four local system-role kinds for this bounded work: OutcomeCriterionHolderSystemRole, AIScoutSystemRole, AISpecialistProbeSystemRole, and CommitAuthoritySystemRole. Claim an assignment only by naming its occurrence and declared species under U.SystemRoleAssignment. The CommitAuthoritySystemRole name does not supply decision authority; any authority relation must obtain independently.
First distinguish the probe’s question. If another probe could change which option survives the OptionSet, return to C.11. If changed live facts or domain-Method limits could change the next action during ongoing Work, return to A.15.7. Use the enactment checkpoint below only when the action or option is fixed, tool or service calls must be planned, and route shape or rollout order is uncertain.
The pair declares one outcome criterion, explores several candidate routes for that fixed action or option, spends a bounded scouting or probing budget before commitment, and returns one CheckpointReturn comparing the tested routes. Keep scouting budget, probing budget, and commit checkpoint distinct. Use A.15 only for this dyadic assignment, Method, plan, and Work alignment; use C.24 for checkpoint-record semantics and E.16 for budget and guard enforcement.
Every CheckpointReturn carries:
- the declared outcome criterion and current
TaskFamily; - the candidate approaches actually tested;
- evidence observed for each tested approach, including progress toward the work-measure threshold and important failure signals;
- burned and residual budget;
- the recommended next use: continue probing, commit to planned Work, narrow the Method or claim, use the direct pattern for another claim, or stop; and
- the commit trigger that would justify leaving the bounded probe.
The return is evidence about candidate approaches, observed results, budget, and the commit trigger. It is not the selected Method, U.WorkPlan, or actual Work. Execution-evidence, provenance, and rollout-decision claims need their own admitted values and relations before committed rollout.
Low-human-overlap approaches remain admissible here only while they stay tied to the outcome criterion, budget limits, and the exact evidence or provenance relation used by the receiving claim.