{"schema_version":1,"assessment_id":"eoa_inverse_innovation_exp03_opportunity320_20260801","source_experiment_id":"eoa_inverse_innovation_exp03_full320_20260801","cell_id":"deadweight_loss_reduction__computer_science","archetype_slug":"deadweight_loss_reduction","domain_slug":"computer_science","title":"Revocable Borrowing of Idle CI-Runner Quotas","opportunity_summary":"Permit eligible non-production CI jobs to borrow verified idle runner reservations within a security-equivalent pool while preserving tenant floors, compatibility constraints, immediate reclaim rights, and existing deployment controls. The opportunity depends on an unresolved empirical premise: a material amount of queue delay must arise from stranded compatible reservations rather than genuine pool saturation, required headroom, or short unusable idle intervals.","adopter_authorizer":"The CI platform owner, jointly with SRE and security owners, can authorize evaluation and a bounded pilot; participating repository owners must consent, and existing security and deployment authorities retain their gates.","scores":{"meaningful_impact":{"score":3,"rationale":"Reducing CI queue latency without adding physical capacity could improve development feedback and avoid idle compute, but the packet provides no evidence that recoverable quota-induced delay is prevalent or material."},"stakeholder_pull":{"score":3,"rationale":"Developers and platform operators have a plausible interest in shorter queues and better capacity use, while reservation-holding teams may resist interference; no observed demand, complaints, or adoption commitments are supplied."},"incremental_advantage":{"score":4,"rationale":"When compatible capacity is genuinely stranded, borrowing directly addresses the allocation wedge and can act faster and with less added capacity than autoscaling or purchasing runners. Its advantage disappears under broad pool saturation or harmful reclaim overhead."},"distinctiveness_plausibility":{"score":2,"rationale":"The combination of revocability, protected floors, compatibility checks, and incidence guardrails is coherent, but quota borrowing is an intuitive scheduling mechanism and prior art is explicitly unsearched, so distinctiveness has weak support."},"technical_implementability":{"score":4,"rationale":"A capped implementation within one security-equivalent runner pool appears technically bounded and reversible, with observable scheduling states and explicit controls. Reclaim semantics, partial-work loss, cache isolation, gaming, and scheduler reliability still require validation."},"adoption_authority_feasibility":{"score":4,"rationale":"The packet identifies the platform, SRE, security, and repository authorities, assigns consent, preserves existing gates, and defines exclusions and rollback. Joint approval and lending-tenant acceptance add coordination burden."},"evidence_readiness":{"score":4,"rationale":"The central premise and intervention have explicit falsifiers, measurable queue and idleness states, a baseline comparison, and identifiable guardrails. Synchronized trace quality and dispatchability classification are not yet demonstrated."},"safety_net_benefit":{"score":4,"rationale":"Tenant floors, security-boundary exclusions, immediate disablement, automatic pilot expiry, retained approval gates, and explicit halt thresholds substantially bound downside, although reclaim and shared-infrastructure risks remain."},"scalability":{"score":3,"rationale":"A scheduler-level mechanism could extend across repositories sharing compatible pools, but runner heterogeneity, security and residency boundaries, tenant-specific guarantees, gaming controls, and operational complexity may limit generalization."}},"score_confidence":"MODERATE","costs":{"first_evidence":{"band_2026_usd":"10K_TO_50K","scope":"A bounded offline audit of synchronized scheduler, quota, compatibility, headroom, and queue traces, including preregistered classifications, tenant-level analysis, and counterfactual scheduler replay.","confidence":"MODERATE","assumptions":["Existing logs can be accessed without building a new telemetry platform.","One security-equivalent runner pool and a limited repository cohort are analyzed.","Cost includes engineering, data analysis, SRE review, and security input.","No live scheduler behavior is changed."]},"initial_deployment_startup":{"band_2026_usd":"50K_TO_250K","scope":"Design, implement, test, and review a capped borrowing mode for one runner pool, including floors, compatibility enforcement, reclaim controls, instrumentation, feature flags, guardrails, and rollback procedures.","confidence":"LOW","assumptions":["The existing scheduler supports extensible quota and dispatch logic.","No runner-platform replacement or cross-boundary data sharing is required.","Security review and repository-owner coordination are included.","The estimate covers a pilot-capable implementation rather than a hardened organization-wide service."]},"operational_launch":{"band_2026_usd":"250K_TO_1M","scope":"Harden and launch the mechanism across multiple eligible tenant groups, including reliability testing, policy configuration, dashboards, incident procedures, fairness review, documentation, training, and phased evaluation.","confidence":"LOW","assumptions":["Launch remains within already compatible security and residency pools.","Material scheduler redesign, new hardware, and production deployment jobs remain out of scope.","Multiple teams require coordinated rollout and tenant-specific guardrails.","Cost varies substantially with scheduler architecture and compliance requirements."]},"annual_recurring":{"band_2026_usd":"50K_TO_250K","scope":"Ongoing monitoring, scheduler maintenance, guardrail review, incident response, policy tuning, tenant support, security reassessment, and outcome evaluation.","confidence":"LOW","assumptions":["The mechanism becomes a maintained feature of an existing CI platform.","No dedicated large operations team or added runner fleet is required.","Recurring work includes periodic analysis of fairness, gaming, reclaim waste, and latency effects.","Costs could rise if heterogeneous pools require separate policies or intensive support."]}},"research_burden":"MODERATE","earliest_credible_horizon":"0_TO_3_MONTHS","pipeline_gates":{"recognizable_externally_supportable_problem":{"status":"UNCERTAIN","reason":"The packet defines a recognizable and observable coexistence of quota-blocked jobs with idle compatible runners, but supplies no external or measured evidence that this state occurs materially after excluding saturation, incompatibility, and required headroom."},"identifiable_adopter_or_authorizer":{"status":"YES","reason":"The CI platform owner is identified as the primary authorizer, with joint SRE and security approval and consent from participating repository owners."},"distinct_testable_incremental_claim":{"status":"YES","reason":"The proposal claims that revocable borrowing, compared with static quotas under otherwise compatible conditions, will reduce quota-attributable waiting without violating isolation, reliability, tenant-floor, or distributional guardrails."},"bounded_next_evidence_step":{"status":"YES","reason":"A limited offline trace audit and counterfactual replay can compare static quotas with capped borrowing and falsify the opportunity if material dispatchable coexistence intervals or modeled latency gains are absent."},"no_unresolved_safety_or_authority_stop":{"status":"UNCERTAIN","reason":"Authority, consent, exclusions, and rollback are specified, but cache leakage, interference, reclaim instability, and protected headroom require security and reliability validation before any live pilot."},"implementation_cost_scope_and_range":{"status":"YES","reason":"The mechanism has a bounded single-pool pilot scope, and broad resource-equivalent ranges can include scheduler engineering, telemetry, security review, coordination, evaluation, and ongoing operations despite architecture-dependent uncertainty."}},"blocking_evidence":["Whether quota-blocked ready jobs materially coexist with idle, security-compatible, dispatchable runners after required failure headroom and minimum useful idle duration are excluded.","Whether counterfactual borrowing would reduce quota-attributable queue time enough to exceed reclaim, cache-loss, interference, and scheduler-complexity costs.","Whether lending tenants' latency floors and distributional outcomes remain protected under realistic overlapping demand.","Whether cache, infrastructure, and workload isolation controls are sufficient within the proposed security-equivalent pool."],"next_evidence_step":"Conduct a preregistered offline audit and scheduler replay on synchronized traces from one security-equivalent runner pool. Compare observed static-quota queue time with simulated capped borrowing that preserves floors, compatibility, headroom, and reclaim rules. Stop if recoverable coexistence intervals are immaterial, modeled quota-attributable waiting does not decline by a predeclared minimum, or any tenant-floor, reliability, isolation, or distributional guardrail is violated; do not enable live borrowing during this step.","research_questions":["What share of queue time contains quota-blocked ready jobs alongside idle runners that are security-compatible, workload-compatible, dispatchable, and not required as headroom?","How sensitive is recoverable capacity to minimum idle-duration, startup-time, cache-affinity, and headroom definitions?","Under trace replay, how much queue-time reduction remains after accounting for reclaim waste, lost partial work, cache penalties, and interference?","Which tenants gain or lose, and do protected queue-latency floors hold during overlapping demand spikes?","Can strategic priority inflation or job splitting defeat the proposed caps and fairness rules?","What scheduler and quota-borrowing mechanisms already exist, and is the proposed combination meaningfully distinct?","What security evidence is required to establish that borrowing within a nominally equivalent pool does not create cross-tenant leakage?","When does autoscaling or added capacity outperform borrowing because compatible pools are broadly saturated?"] ,"recommendation":"VALIDATE_PROBLEM_FIRST","uncertainty_constraints":["Closed-book assessment with no external validation of prevalence, stakeholder demand, prior art, market size, realized impact, or exact cost.","The candidate is a hypothesis, and its central allocation-loss premise may be falsified by synchronized traces.","Cost bands are architecture-sensitive resource equivalents, not vendor quotes or point estimates.","Technical feasibility is inferred from the bounded mechanism description, not demonstrated implementation.","Safety controls are specified conceptually but have not been validated against actual runner isolation, cache behavior, or reclaim semantics."],"closed_book_prior_art_boundary":"Prior art is explicitly unsearched. This assessment makes no claim that revocable CI-runner quota borrowing, protected tenant floors, compatibility constraints, reclaim controls, or their combination is novel, uncommon, or commercially differentiated."}