{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"rate_limiting__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"rate_limiting__computer_science__P1","proposal_index":1,"version":0,"title":"Metered Admission for Speculative Compilation","problem":"A shared compiler service admits every speculative compile requested by developers' IDEs. During synchronized source-tree changes, repeated speculative compiles from a few workspaces can occupy the worker pool faster than jobs complete, even though each request is valid, leaving release-validation compiles waiting behind replaceable work.","actors":["Developers using IDEs that request speculative compilation","CI systems submitting release-validation compiles","Teams sharing compiler capacity","Compiler-platform operators"],"observable_state":"Per-workspace arrival rates and token consumption, request class, worker occupancy, in-flight compilations, queue age, delayed or denied requests, retry timing, and release-validation latency are observable. The target problem state is present when speculative requests arrive faster than sustainable completion and consume capacity needed by release-validation work.","consequence":"Worker saturation and queue growth make release-validation results late or unavailable, while obsolete speculative compiles may finish after newer edits have superseded them.","affected_objective":"Preserve predictable compiler availability for release validation while retaining bounded access to useful speculative feedback across workspaces.","intervention":"Place an admission boundary before compiler workers. Give each workspace a token bucket for speculative compiles, with a bounded burst allowance and steady refill rate; admit a speculative compile only when a token is available. Apply a global concurrency ceiling, reserve a separately governed allowance for release-validation jobs, and return delayed requests a retry-after interval with jitter rather than placing them in an unbounded queue. Expose token state, enforcement events, and impact by workspace and request class for audit and tuning.","structural_mapping":[{"archetype_element":"Flow","domain_realization":"Speculative and release-validation compilation jobs submitted to the shared compiler service."},{"archetype_element":"Finite shared capacity","domain_realization":"Compiler workers, memory, and scheduler attention shared across workspaces and CI."},{"archetype_element":"Measurable subject and unit","domain_realization":"One compilation admission attributed to an authenticated workspace and labeled by request class."},{"archetype_element":"Measurement window","domain_realization":"Token consumption and refill over time, supplemented by the count of concurrent admitted jobs."},{"archetype_element":"Threshold","domain_realization":"The workspace token balance, global concurrency ceiling, and protected release-validation allowance."},{"archetype_element":"Admission control","domain_realization":"A pre-worker gate that admits, delays, or rejects compilation jobs before they consume compiler capacity."},{"archetype_element":"Prioritization and fairness","domain_realization":"Separate treatment for release-validation and speculative work, with equivalent speculative workspaces governed by the same default allocation policy."},{"archetype_element":"Predictable excess handling","domain_realization":"Explicit retry-after responses with jitter and no silent accumulation in an unbounded queue."}],"mechanism_mapping":[{"mechanism_slug":"token_bucket","role":"Allows a bounded short burst of speculative compiles per workspace while capping sustained admission through a refill rate.","counterfactual_removal":"Without the token bucket, a workspace can continue admitting speculative jobs at its source-generated request rate until another control or worker exhaustion intervenes."},{"mechanism_slug":"concurrency_limit","role":"Caps total in-flight compiler work so admission remains bounded even when token allowances across workspaces coincide.","counterfactual_removal":"Per-workspace rates could individually comply while their combined in-flight work still exceeds the worker pool's safe operating envelope."},{"mechanism_slug":"priority_class_rules","role":"Protects a separately visible allowance for release-validation compiles instead of letting speculative work consume every admission opportunity.","counterfactual_removal":"Low-consequence speculative requests could spend available allowance while release-validation jobs remain blocked, creating priority inversion."}],"causal_chain":["IDE edit activity produces bursts of valid but replaceable speculative compilation requests.","Unmetered admission allows those bursts to consume workers and grow the shared queue faster than compilations complete.","A per-workspace token bucket makes sustained speculative admission explicitly bounded while retaining a limited burst allowance.","A global concurrency ceiling bounds aggregate in-flight work, and a protected release-validation allowance prevents speculative work from capturing all admission capacity.","Excess speculative requests receive explicit delayed handling rather than consuming workers or becoming a hidden backlog.","Bounded admission preserves compiler capacity for release validation and makes allocation decisions observable by workspace and class."],"baseline":"The compiler scheduler accepts all authenticated jobs into a shared FIFO queue and starts them whenever a worker becomes available. It records job timing but imposes no per-workspace rate envelope, burst allowance, protected class allowance, or finite admission queue.","nearest_rivals":["Autoscaling compiler workers increases capacity but does not bound how quickly one workspace can capture newly added capacity or define excess handling when scaling lags or stops.","A priority queue reorders already-admitted jobs but can retain an unbounded backlog of obsolete speculative work; the proposed gate governs entry before that work consumes queue and worker resources.","Backpressure would communicate current worker or queue pressure to producers and depend on their response; the proposed limit is an enforceable allocation rule at the compiler boundary.","Bulkhead isolation would dedicate fixed worker partitions to workspaces or classes; the proposed intervention retains a shared pool while bounding each source's admission rate and protecting a request class.","Cancellation of superseded compiles removes obsolete work after supersession is known but does not itself bound admission during a request burst."],"remaining_contrastive_claim":"The candidate's distinctive claim is that compiler instability and unfair capture arise partly from the temporal admission rate of otherwise authorized speculative jobs, so an enforceable, measured rate envelope before worker allocation is necessary. It is not merely authorization, job reprioritization, post-admission cancellation, downstream pressure signaling, or capacity expansion.","authority_safety":{"decision_authority":"The compiler-platform owner may define and operate admission policy, with affected engineering teams reviewing workspace attribution, class definitions, and exception criteria.","authorized_first_step":"Perform an offline trace replay that computes hypothetical token balances, admissions, delays, and class allocation without changing production scheduling.","excluded_actions":["Do not enable production rejection or delay during the first evidence step.","Do not reduce or reclassify release-validation capacity without CI-owner approval.","Do not create permanent workspace-specific quotas from team identity, status, or historical consumption without a documented allocation review.","Do not place delayed work into an unbounded hidden queue.","Do not treat rate limiting as a substitute for investigating compiler defects or justified capacity expansion."],"halt_rollback":"If later piloting causes release-validation starvation, blocks documented critical bursts, produces unexplained allocation differences between equivalent workspaces, or increases hidden backlog, disable enforcement through the admission-gate feature flag and restore the prior scheduler while retaining audit logs."},"negative_tests":{"strongest_counterevidence":"Trace replay shows that high release-validation latency occurs when speculative arrival rates remain below sustainable completion and worker occupancy is not associated with speculative admissions; instead, a small number of intrinsically long or deadlocked compiles dominate capacity.","problem_falsifier":"The rate-based problem is falsified if synchronized speculative bursts do not coincide with worker saturation, queue growth, or displacement of release-validation work after jobs are correctly attributed and obsolete requests are identified.","intervention_falsifier":"The intervention is falsified if a plausible token-bucket and concurrency policy cannot keep admitted work within the selected capacity envelope while preserving documented legitimate bursts and avoiding starvation across ordinary workspaces and release-validation jobs.","risks":["Limits may suppress legitimate high-intensity debugging or large refactor bursts.","Static refill rates may mismatch changing compiler capacity or job cost.","Workspace identities may be split or rotated to evade limits.","Protected tokens may be consumed by incorrectly labeled speculative work.","Simultaneous token refills or retries may create a thundering herd.","Equivalent workspaces may receive unequal treatment because attribution or defaults differ.","Delayed requests may migrate into an invisible client-side backlog.","Conservative limits may leave compiler workers underutilized.","The gate may conceal a need to fix pathological compiler jobs or expand capacity."]},"next_evidence_step":"Using a bounded sample of existing compiler admission and completion traces from one consenting service environment, replay the baseline and the proposed per-workspace token-bucket, global-concurrency, protected-class, and jittered-retry rules. Compare admitted flow, hypothetical delay or denial, worker-envelope violations, release-validation preservation, burst handling, and allocation across workspaces. Stop at offline analysis; do not infer production effect, and advance only if attribution and request-class labels are sufficiently reliable to evaluate the falsifiers.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed because runtime isolation forbids inspecting other proposals; this candidate was derived only from the supplied rate-limiting archetype and computer-science domain card.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}