{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"synchronized_release_dampening__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"synchronized_release_dampening__computer_science__P1","proposal_index":1,"version":0,"title":"Dependency-Ready Release Control for Blocked CI Workflows","problem":"In a large continuous-integration system, many pull-request workflows can be blocked on the same upstream dependency build. When that dependency becomes ready, the event releases all blocked workflows simultaneously. They then contend for a finite integration-test environment broker and often request duplicate base-environment construction for the same dependency and repository revision. The broker could process the work over a wider interval, but the correlated release produces a short-lived collision.","actors":["Developers awaiting pull-request validation","CI workflow orchestrator","Dependency-build service","Integration-test environment broker","CI platform operators"],"observable_state":"Immediately after one dependency-ready event, environment-lease requests, duplicate base-environment build requests, broker queue depth, and lease timeouts rise sharply relative to adjacent intervals, while average utilization over the surrounding day remains below the broker's service capacity.","consequence":"Environment allocation thrashes or times out, delaying otherwise-ready validations and producing infrastructure-related test failures that can be mistaken for defects in submitted code.","affected_objective":"Reliable and bounded-time validation of pull requests without requiring the integration-test broker to absorb an all-at-once dependency-release wave.","intervention":"Replace immediate fan-out from a dependency-ready event with a release controller keyed by dependency version and repository base revision. The controller performs one shared base-environment preparation per key, admits ready workflows through capacity-priced tokens, and reactivates them in bounded cohorts. Urgent security-fix validations receive a separately bounded escape lane; every ordinary workflow retains a maximum-wait deadline and then falls back to the existing scheduler.","structural_mapping":[{"archetype_element":"Shared Release Signal","domain_realization":"Publication of a successful upstream dependency artifact that changes blocked CI workflows from waiting to runnable."},{"archetype_element":"Waiting Population Boundary","domain_realization":"CI workflows registered as waiting for the same dependency version, partitioned further by repository base revision and required test-environment class."},{"archetype_element":"Finite Choke Point","domain_realization":"The broker and worker pool that construct and lease isolated integration-test environments."},{"archetype_element":"Release Correlation Metric","domain_realization":"Lease-request peak-to-average ratio and arrival-window width following each dependency-ready event, accompanied by the number of duplicate environment preparations per key."},{"archetype_element":"Coalescing Rule","domain_realization":"For each dependency-version and base-revision key, one preparation operation produces a reusable immutable environment snapshot while concurrent workflows await that result."},{"archetype_element":"Admission Gate","domain_realization":"A token budget limits new environment leases to broker-observed preparation and allocation capacity."},{"archetype_element":"Dispersion Policy","domain_realization":"Waiting workflows are released in cohorts with bounded jitter rather than all being marked runnable at the same instant."},{"archetype_element":"Fairness and Starvation Guard","domain_realization":"Per-repository round-robin selection, a maximum ordinary-workflow delay, and a separately capped security-fix lane prevent indefinite postponement or priority capture."},{"archetype_element":"Capacity Recovery Signal","domain_realization":"Broker queue depth, recent lease latency, and available environment slots determine whether the next cohort may be released."}],"mechanism_mapping":[{"mechanism_slug":"single_flight_request_coalescing","role":"Coalesces identical base-environment preparation requests so one immutable snapshot can serve all workflows sharing the key.","counterfactual_removal":"Without coalescing, cohort release would reduce simultaneous leases but each workflow could still duplicate the most expensive preparation work."},{"mechanism_slug":"token_bucket_admission_gate","role":"Converts the released population into an admitted stream sized to the environment broker's measured service envelope.","counterfactual_removal":"Without the gate, cohort timing alone could still oversubscribe the broker when cohort size or service time is misestimated."},{"mechanism_slug":"cohort_based_reactivation","role":"Stages workflows after the shared dependency-ready event instead of exposing the broker to an immediate fan-out.","counterfactual_removal":"Without cohort reactivation, all blocked workflows would compete for tokens and scheduler attention at the same event boundary, preserving a substantial correlated control-plane spike."}],"causal_chain":["Many CI workflows independently block on one missing upstream dependency artifact.","The dependency-build service publishes one readiness event observed by every blocked workflow.","The baseline orchestrator marks the entire waiting population runnable within the same short interval.","Runnable workflows simultaneously request scarce environment leases and duplicate preparation for common dependency/base-revision keys.","The resulting queue and preparation contention increase lease timeouts and infrastructure-related validation failures despite adequate average daily capacity.","Keyed single-flight preparation removes equivalent duplicate work.","Capacity-priced admission tokens and bounded cohorts widen the arrival window at the environment broker.","Fairness deadlines and a capped priority lane constrain the latency and starvation introduced by dampening."],"baseline":"The dependency-ready callback immediately marks every blocked workflow runnable. The existing CI scheduler applies a global runner concurrency limit only after workflows begin competing for environment allocation, and each workflow independently requests preparation of its required base environment.","nearest_rivals":["Autoscaling the environment worker pool: adds capacity but does not directly remove the dependency-ready synchronization or duplicate preparation work.","A fixed global CI concurrency cap: bounds execution but is not keyed to the release event, broker recovery state, or equivalence of environment preparation requests.","A conventional merge queue: serializes admission of code changes for branch correctness, whereas this intervention governs reactivation of already-admitted workflows released by a shared dependency event.","Priority scheduling: changes ordering among workflows but does not by itself spread the release wave or coalesce common preparation."],"remaining_contrastive_claim":"The candidate applies only if the dependency-ready boundary creates a transient, correlated broker collision and common environment preparations are shareable; its distinguishing control target is release correlation plus duplicate work, not sustained runner scarcity or branch-merge ordering.","authority_safety":{"decision_authority":"The CI platform team may modify the staging orchestrator's dependency-ready callback, environment-preparation cache, and admission policy; repository owners retain authority over required tests and merge decisions.","authorized_first_step":"Implement or simulate the controller only in a staging replay harness using recorded or synthetic workflow descriptors, with no authority to suppress tests, alter test results, merge code, or change production scheduling.","excluded_actions":["Delaying emergency or security-fix validation outside its declared maximum wait","Skipping, weakening, or reclassifying required tests","Reusing mutable environments across trust boundaries","Changing production CI release behavior during the first evidence step","Granting repositories unbounded priority bypass"],"halt_rollback":"Abort the staging run if any workflow exceeds the configured maximum wait, cross-repository environment reuse is observed, or the priority lane consumes more than its reserved cap. Disable the controller feature flag and return all simulated workflows to the baseline scheduler state."},"negative_tests":{"strongest_counterevidence":"Event-aligned traces show no narrow post-publication spike, little duplicate preparation, and a broker that remains continuously saturated before and after dependency readiness.","problem_falsifier":"The diagnosis is falsified if dependency-ready events do not materially align lease arrivals, or if comparable timeouts occur under steady uncorrelated arrivals at the same average rate.","intervention_falsifier":"The intervention is falsified for this problem if a staging replay with single-flight preparation and capacity-gated cohorts does not reduce event-window collision indicators without violating the preset maximum-wait, fairness, and priority-cap constraints.","risks":["Added validation latency for workflows that would have obtained an immediate lease","Starvation or repository-level unfairness from poorly chosen cohort selection","A faulty shared environment snapshot propagating one preparation error to many workflows","Backlog displacement from the broker into a less visible release queue","Stale or misleading capacity signals causing under-release or renewed overload","Priority-lane capture by misclassified workflows","Isolation failure if environment reuse crosses repository or credential boundaries"]},"next_evidence_step":"Select one bounded historical or synthetic dependency-ready scenario containing at most 500 workflow descriptors and replay it once through the baseline and once through a staging implementation of keyed single-flight preparation, a token-bucket gate, and bounded cohorts. Record the event-window lease-arrival peak, broker queue depth, duplicate preparations per key, completion latency distribution, maximum wait, per-repository service order, and priority-token use; make no production change.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"No prior proposals or experiment candidates were inspected. This one-shot candidate is derived solely from the supplied archetype and domain card and focuses on CI workflows released by a shared dependency-build event.","revision_record":{"parent_version":null,"progress_targets_addressed":["Produce one complete one-shot reverse-innovation candidate","Preserve the archetype's shared-release, finite-choke, correlation-control, coalescing, admission, and fairness structure","Ground the intervention in named mechanisms from the supplied archetype","Define bounded authority, safeguards, falsifiers, risks, and a first evidence step"],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}