{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"backpressure__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["repository bot dynamic backpressure CI queue pull request creation capacity credits","automated pull request bot throttle based on CI status queue backlog","continuous integration build queue overload dependency update bots study"],"source_ids":["SRC1","SRC4"],"no_result_note":"The search exposed the stated CI-load problem but no retained source described a repository-wide protocol in which downstream validation headroom issues credits required before multiple automated producers can open or refresh changes."},"synonyms_and_historical_terms":{"queries":["CI pipeline admission control dynamic queue length repository pull requests","build queue backpressure continuous integration producer admission control","producer consumer credit based flow control bounded buffer standard","CI build queue load shedding cancel superseded runs priority jobs"],"source_ids":["SRC1","SRC3"],"no_result_note":"General admission-control, bounded-buffer, demand-signaling, concurrency, and superseding terminology produced conceptual analogues, but not the complete repository-specific protocol among the retained sources."},"products_practices_and_standards":{"queries":["Renovate bot CI pending status limit pull request creation prConcurrentLimit documentation","Dependabot open pull requests limit CI workload cooldown documentation","GitHub Actions workflow concurrency pending queue cancellation documentation","CI pipeline admission control dynamic queue length repository pull requests"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"component_combination":{"queries":["token bucket admission control bounded queue priority reserve hysteresis overload recovery","automated pull request bot throttle based on CI status queue backlog","CI build queue load shedding cancel superseded runs priority jobs","dependency update bots CI workload empirical study pull requests build cost"],"source_ids":["SRC1","SRC2","SRC3","SRC4"],"no_result_note":"Static PR caps, security-class separation, status-dependent PR creation, bounded CI queues, cancellation, and bot-induced CI waste were found separately; the retained sources did not combine them into downstream-sized, expiring producer credits with reserved classes and hysteretic restoration."}},"sources":[{"source_id":"SRC1","title":"Configuration Options - Renovate Docs","publisher":"Renovate","url":"https://docs.renovatebot.com/configuration-options/","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["Renovate documents that creating many update PRs can overwhelm CI and that repeated rebases can cause many test runs.","Renovate supplies per-repository static PR and branch concurrency limits and an hourly PR-creation limit.","Renovate can delay PR creation until status checks finish or succeed, but this gates an individual update branch rather than allocating shared credits from repository-wide CI and review headroom.","Renovate notes that base-branch movement can repeatedly defer automerge and cause rebasing of otherwise green branches."]},{"source_id":"SRC2","title":"Dependabot errors","publisher":"GitHub","url":"https://docs.github.com/en/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-errors","source_type":"OFFICIAL_GUIDANCE","claims_supported":["Dependabot stops opening version-update pull requests when its configurable open-PR limit is reached.","GitHub documents separate limits for security and version-update PRs so routine version updates cannot block security-update PR creation.","The documented limits are fixed class-specific caps, not credits dynamically sized from current CI or reviewer pressure."]},{"source_id":"SRC3","title":"Control the concurrency of workflows and jobs","publisher":"GitHub","url":"https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency","source_type":"OFFICIAL_GUIDANCE","claims_supported":["GitHub Actions concurrency groups bound simultaneous execution and, by default, retain at most one pending run in a group.","A larger bounded queue can retain up to 100 pending runs, after which additional runs are canceled.","Concurrency controls can cancel superseded in-progress or pending work and expose monitoring for concurrency and queuing constraints, but operate after workflow production rather than issuing pre-creation permission to repository bots."]},{"source_id":"SRC4","title":"Dependency-Induced Waste in Continuous Integration: An Empirical Study of Unused Dependencies in the npm Ecosystem","publisher":"University of Waterloo REBELs Laboratory","url":"https://rebels.cs.uwaterloo.ca/confpaper/2024/07/16/dependency-induced-waste-in-continuous-integration.html","source_type":"PRIMARY_RESEARCH","claims_supported":["The study analyzed 20,743 dependency-update commits across 1,487 npm projects.","It found that 55.88% of CI build time associated with dependency updates was triggered by unused dependencies.","Automated bots produced 92.93% of the CI time spent on unused-dependency updates, with Dependabot accounting for 74.52% of that waste.","The evidence establishes material bot-induced CI work, although it does not by itself establish queue overload in every repository."]}],"problem_evidence":{"status":"PARTLY_SUPPORTED","finding":"The problem is visible: Renovate explicitly warns that update PR bursts and rebases can overwhelm CI, GitHub provides caps and bounded/canceling queues for related accumulation, and primary research measures substantial bot-induced CI waste. The retained evidence does not quantify whether automated offered work exceeds contemporaneous runner-plus-reviewer service capacity, queue-age thresholds, or stale-validation debt in a particular repository, so the full repository-specific overload hypothesis remains to be measured.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"closest_prior_art":[{"name":"Renovate PR/branch concurrency limits, hourly throttling, and status-dependent PR creation","source_ids":["SRC1"],"overlap":"Limits update-branch and PR accumulation, slows emission to avoid CI overload, and can wait for validation status before publishing a PR.","remaining_difference":"Limits are primarily static and producer-local; status gating concerns the candidate branch's checks. The documentation does not describe repository-wide downstream headroom issuing finite shared credits across producers, reserved critical credits, explicit deferred-candidate accounting, or hysteretic recovery probes."},{"name":"Dependabot class-separated open-pull-request limits","source_ids":["SRC2"],"overlap":"Stops routine update PR creation at a hard bound and separates security capacity from version-update capacity, closely matching the cap and critical-flow components.","remaining_difference":"The quotas are fixed rather than dynamically contracted or expanded from CI queue cost, validation latency, stale runs, or reviewer backlog; no cross-producer credit lifecycle or gradual recovery is described."},{"name":"GitHub Actions concurrency groups and bounded or superseding queues","source_ids":["SRC3"],"overlap":"Bounds downstream running and pending work and can cancel superseded work to limit redundant resource consumption.","remaining_difference":"It governs jobs after repository events have created workflow work. It does not signal available demand upstream to bots before they create or materially refresh PRs, preserve producer-side deferred candidates, or reserve admission credits for critical change classes."}],"prior_art_disposition":"ADJACENT_PRIOR_ART","contrastive_claim_remaining":"For the same repository trace, hard active-work cap, and critical classification, a controller that converts current aggregate CI-and-review headroom into expiring producer admission credits will reduce automated PR openings or material refreshes before the cap is crossed, while keeping critical admission available and every admitted or deferred candidate visible, compared with static PR limits, time-based throttles, or downstream workflow concurrency alone.","contrastive_claim_falsifier":"The claim is falsified if a predeclared replay shows that timely pressure-derived credits do not reduce pre-cap automated admissions or validation accumulation relative to matched static controls, fail to preserve the critical reserve, cause excessive throttle reversals, or merely transfer unbounded accumulation into an unobserved producer-side backlog. Discovery of an earlier system implementing the same aggregate-headroom, pre-creation, expiring-credit protocol would also erase the claimed prior-art distinction.","gates":{"adequate_source_search":{"status":"PASS","rationale":"Four required lanes were searched using direct language, older systems terminology, named repository products and practices, and component combinations. Exactly four opened sources were retained from three publishers, including first-party, official, and primary-research evidence.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"Product documentation explicitly identifies CI overload and repeated tests from automated update activity, while primary research measures substantial bot-produced CI waste. Evidence is partial for the proposal's exact capacity-exceedance formulation but sufficient to make the problem observable and researchable.","source_ids":["SRC1","SRC3","SRC4"]},"distinct_testable_claim":{"status":"PASS","rationale":"The remaining claim contrasts downstream-pressure-sized, pre-creation credits against documented static producer limits and post-creation CI concurrency controls, with measurable admission, cap, reserve, oscillation, and deferred-backlog outcomes.","source_ids":["SRC1","SRC2","SRC3"]},"bounded_next_test":{"status":"PASS","rationale":"A fourteen-day, single-repository, read-only trace replay is bounded and predeclares the controller, comparison outcomes, critical reserve, explicit states, and failure conditions. It can test trace-level feasibility without enabling enforcement or claiming live effect size.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"The first step is read-only, requires a consenting repository and existing maintainer authority, changes no PR, CI, review, merge, branch-protection, or runner-allocation state, and includes data-access and classification halt conditions.","source_ids":[]}},"screen_survival":true,"world_novelty_boundary":"This bounded four-source screen establishes only that no substantial collision appeared in the retained public sources. It cannot establish world novelty, patentability, market size, expert acceptance, or realized value; unindexed implementations, private tooling, patents, and differently described systems may exist."}