{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"agentic_control_loop_design__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"agentic_control_loop_design__computer_science__P1","proposal_index":1,"version":0,"title":"Bounded Control Loop for CI Build-Failure Recovery","problem":"In a large shared codebase, a service-owning team is held responsible for restoring its continuous-integration build after an ambiguous failure, but the evidence, permitted recovery actions, execution tools, and action-effect feedback are disconnected. Developers see a failed check yet cannot reliably distinguish an infrastructure transient, flaky test, dependency change, or defect; they repeatedly rerun jobs or escalate to central CI maintainers without learning which action changes the outcome.","actors":["Service-owning development team responsible for the failing build","CI recovery agent that assembles evidence and executes bounded actions","Central CI platform maintainers who govern permitted actions and receive escalations","Repository maintainers who approve changes to tests, dependencies, and source code"],"observable_state":"A CI run has failed; machine-readable logs, test histories, dependency changes, and runner-health signals exist, but they are scattered across tools. The responsible team can observe the red status but lacks a unified causal hypothesis, an explicit menu of authorized recovery actions, and feedback linking each attempted action to the subsequent build result. Observable symptoms include repeated identical reruns, premature escalation, and unresolved failures cycling between service and platform teams.","consequence":"Build restoration becomes ritual trial-and-error: compute and developer attention are consumed, delivery remains blocked, central maintainers receive avoidable escalations, and the service team may be blamed for an outcome it could not adequately observe or control.","affected_objective":"Restore a trustworthy passing CI state while preserving test validity, repository integrity, and proportional accountability for causes within each actor's control.","intervention":"Install a bounded CI recovery loop around each eligible failed run. The loop represents the goal as restoring a trustworthy build rather than merely producing a green status; constructs a current failure model from logs, history, recent changes, and infrastructure signals; records competing causal assumptions; selects only from a governed Safe Action Menu; executes one reversible action; observes the resulting run and diagnostics; and updates the failure model before choosing again. Low-risk actions such as rerunning on a fresh runner or reproducing a failed test in an isolated environment may execute automatically. Quarantining a test, changing dependencies, modifying source, weakening assertions, or bypassing required checks remains outside the autonomous boundary and requires human approval or escalation.","structural_mapping":[{"archetype_element":"Represented Goal","domain_realization":"A trustworthy passing build in which required checks retain their intended evidentiary meaning, not a pass obtained by suppressing failures."},{"archetype_element":"World Model","domain_realization":"A ranked, inspectable set of hypotheses about whether the failure originates in infrastructure, nondeterministic tests, dependency resolution, configuration, or the submitted code."},{"archetype_element":"Observation Channel","domain_realization":"CI logs, exit codes, test-level history, runner-health telemetry, dependency diffs, changed files, and outcomes of prior recovery attempts."},{"archetype_element":"Action Repertoire","domain_realization":"A bounded set of reversible diagnostic and recovery moves, including isolated reproduction, fresh-runner rerun, cache-free rebuild, and collection of additional diagnostics."},{"archetype_element":"Selection Policy","domain_realization":"Choose the lowest-risk permitted action expected to discriminate among current hypotheses; do not repeat an action unless new evidence changes its expected information value."},{"archetype_element":"Legitimate Action Boundary","domain_realization":"The agent may manipulate disposable CI executions and diagnostics but may not merge code, edit protected branches, suppress required checks, quarantine tests, rotate secrets, or alter production systems."},{"archetype_element":"Execution Capability","domain_realization":"Scoped CI credentials, ephemeral runners, reproducible test commands, and a limited retry and compute budget."},{"archetype_element":"Effect Feedback Loop","domain_realization":"Each action is linked to the next run's status, changed diagnostics, and hypothesis discrimination rather than recorded only as an unstructured rerun."},{"archetype_element":"Model Update Rule","domain_realization":"Increase or decrease support for each causal hypothesis based on action outcomes; escalate when evidence conflicts, the safe menu is exhausted, or confidence remains insufficient."},{"archetype_element":"Proportional Accountability Frame","domain_realization":"The service team is accountable for code-controlled causes, the platform team for runner-controlled causes, and neither is assigned responsibility where the available evidence and authority do not provide meaningful control."},{"archetype_element":"Override and Escalation Path","domain_realization":"A repository maintainer can stop the loop at any time; the agent escalates with its evidence, attempted actions, remaining hypotheses, and the specific authority or expertise required."}],"mechanism_mapping":[{"mechanism_slug":"agency_loop_map","role":"For each failure, expose the connection among restoration goal, observed evidence, current hypotheses, available actions, permissions, execution results, and the next model update.","counterfactual_removal":"Without the map, teams can receive more diagnostics or authority while the broken coupling remains hidden, allowing repeated actions that do not update understanding."},{"mechanism_slug":"model_assumption_register","role":"Record competing failure-cause hypotheses, their supporting observations, uncertainty, and which bounded action could distinguish them.","counterfactual_removal":"Without the register, the recovery process can collapse into an unexplained classifier verdict or repeat a favored diagnosis despite contradictory results."},{"mechanism_slug":"safe_action_menu","role":"Provide executable diagnostic and recovery actions with preconditions, resource limits, reversibility requirements, and explicit prohibited effects.","counterfactual_removal":"Without the menu, the agent either has no practical agency and only recommends actions, or receives broad tool access that permits unsafe changes to make the build appear healthy."},{"mechanism_slug":"action_effect_feedback_review","role":"After every attempted recovery, compare predicted and observed effects and use the discrepancy to select the next action or escalation.","counterfactual_removal":"Without this review, automated retries remain open-loop motion and cannot improve diagnosis or detect a mistaken world model."}],"causal_chain":["A failed CI run is converted from a generic red status into an explicit trustworthy-restoration goal and an inspectable set of causal hypotheses.","The loop combines scattered evidence with the permissions and resources actually available to the responsible actors.","The Safe Action Menu restricts selection to reversible actions that either recover the run or distinguish among hypotheses without weakening required checks.","Scoped execution makes the selected action operational rather than merely advisory.","The resulting run and diagnostics are attributed to the action just taken.","The action-effect comparison updates the failure model, preventing unsupported repetition and directing the next bounded action.","When controllability, confidence, budget, or authority is insufficient, structured escalation transfers the evidence and unmet decision need to the appropriate human owner.","Responsibility is assigned in proportion to the observation, authority, and control exposed by the completed loop."],"baseline":"The current baseline is a failed-check notification plus logs, manual rerun buttons, repository documentation, and informal escalation to service or CI maintainers. Actions are available in separate interfaces, but no per-failure structure joins the restoration goal, causal model, permitted action set, execution result, and model update.","nearest_rivals":["Automatic retry policies that rerun failed jobs according to fixed rules without maintaining or revising a causal model","Flaky-test detection systems that classify unstable tests but do not couple diagnosis to bounded recovery authority and effect feedback","Runbook automation that executes a predefined sequence but does not select actions from a changing failure model","CI failure summarizers or diagnostic assistants that explain logs but lack scoped execution rights and action-linked learning"],"remaining_contrastive_claim":"The candidate's distinguishing structural claim is that ambiguous CI recovery should be treated as a governed agentic loop: an explicit trustworthy-build goal, inspectable failure model, discriminating action selection, scoped execution authority, and action-linked model update must operate together. A system that only retries, classifies, summarizes, grants permissions, or runs a fixed playbook omits at least one of those couplings.","authority_safety":{"decision_authority":"Central CI platform maintainers define the globally permissible action classes and resource ceilings; repository maintainers may narrow them for their repository. The recovery agent selects and executes only preauthorized actions on disposable CI resources. Humans retain authority over persistent repository changes, policy exceptions, and test-validity decisions.","authorized_first_step":"Run the recovery logic in read-only shadow mode on archived failed-run artifacts, producing a proposed hypothesis register, selected safe action, and escalation decision without triggering jobs or modifying repositories.","excluded_actions":["Merging, reverting, or editing repository content","Disabling, skipping, quarantining, or weakening required tests or checks","Changing protected-branch rules or approval requirements","Accessing production systems or customer data","Reading, exposing, or rotating secrets","Executing arbitrary commands outside approved ephemeral test environments","Exceeding the per-failure retry, time, or compute budget","Representing an unverified pass as trustworthy"],"halt_rollback":"Halt on contradictory evidence, unrecognized commands, permission denial, budget exhaustion, repeated non-informative results, evidence of a security-sensitive failure, or human stop. Cancel queued disposable runs and revoke the per-incident token; because autonomous actions are confined to ephemeral executions, rollback consists of terminating those executions and preserving the complete evidence and action log for review."},"negative_tests":{"strongest_counterevidence":"Historical review shows that nearly all ambiguous failures are already resolved correctly by a single deterministic retry or existing runbook, and that an explicit hypothesis-and-feedback loop adds decisions without changing recovery paths or escalation quality.","problem_falsifier":"The nominated teams already possess timely integrated evidence, a shared causal model, adequate execution authority, explicit boundaries, and action-linked feedback; their delays instead arise from compute scarcity, mandatory approval latency, or defects that require ordinary code repair.","intervention_falsifier":"In blinded replay, the loop's permitted actions fail to discriminate among causes more reliably than the existing baseline, repeatedly recommend redundant actions, or require excluded persistent changes before producing useful evidence.","risks":["The agent may infer the wrong cause from correlated logs and consume time on misleading diagnostics.","Optimizing for a passing build may incentivize actions that conceal genuine defects unless trustworthiness remains part of the represented goal.","Additional automated runs may waste compute or amplify load during platform incidents.","Failure artifacts may contain credentials, personal data, or proprietary code that the model should not ingest or reproduce.","Maintainers may over-trust a ranked hypothesis or treat an escalation package as proof of responsibility.","A broad safe-action definition may become de facto permission for arbitrary code execution.","Teams may be blamed for rejecting agent advice even when the agent lacks sufficient observability or control."]},"next_evidence_step":"Using only archived artifacts from 30 previously resolved ambiguous CI failures in one consenting repository, have the loop operate in read-only shadow mode. Before revealing the recorded resolution, capture its failure hypotheses, chosen safe action, predicted observation, and escalation point; then compare these with the archived action sequence and known cause. Record unsupported repetitions, prohibited recommendations, cases lacking sufficient evidence, and whether each proposed action would have distinguished hypotheses. Stop after the fixed sample and make no live CI or repository changes.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed against other proposals because this isolated one-shot breadth probe generated exactly one candidate and did not inspect prior experiment candidates.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}