{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"load_shedding__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"load_shedding__computer_science__P1","proposal_index":1,"version":0,"title":"Supersession-aware load shedding for monorepo code-intelligence servers","problem":"A shared code-intelligence service for a large monorepo receives bursts of interactive requests and background reindex tasks after branch switches, generated-code updates, or broad refactors. Each edit can enqueue analysis for files whose state is soon superseded by a newer edit. If the service admits and retains all such work, stale background analyses occupy workers and queues while current-document completion, navigation, and diagnostics wait or time out.","actors":["Developers using editor code-intelligence features","Repository and language-tooling maintainers","Operators of the shared analysis service","Automated processes that submit background indexing work"],"observable_state":"Queue age and worker utilization exceed an overload threshold while a measurable share of queued background tasks refers to file or dependency revisions older than the latest registered revision. Interactive request latency rises, and stale tasks continue consuming capacity despite their results no longer being publishable as current.","consequence":"Developers lose timely feedback on the code state they are actively editing, while the service spends scarce capacity producing results that must be discarded as obsolete; continued accumulation can remove recovery headroom and make the service unresponsive to all request classes.","affected_objective":"Keep current-revision interactive code-intelligence requests serviceable and restore a bounded analysis queue without publishing results for obsolete source states.","intervention":"Place an auditable admission-and-queue boundary before analysis workers. When queue age or utilization crosses an activation threshold, reserve worker capacity for authenticated current-document interactive requests and apply supersession-aware controlled drop to queued background tasks: for each repository, branch, analysis kind, and file or dependency region, retain only the newest still-relevant revision and explicitly terminate older tasks with a `SUPERSEDED_DURING_OVERLOAD` outcome. Also expire optional whole-repository refresh tasks that cannot begin before a declared usefulness deadline. Do not defer discarded tasks into another queue. Continue shedding until both utilization and oldest-task age remain below lower recovery thresholds for a fixed stabilization interval, then re-admit background work gradually.","structural_mapping":[{"archetype_element":"Capacity-constrained flow","domain_realization":"Interactive queries and background analysis tasks flow into a finite pool of parser, type-checker, index, memory, and storage capacity."},{"archetype_element":"Detectable overload threshold","domain_realization":"Worker utilization, runnable-queue age, and memory pressure jointly trigger overload mode; separate lower thresholds and a stabilization interval govern recovery."},{"archetype_element":"Distinguishable load classes","domain_realization":"Current-revision interactive requests are protected; superseded background analyses and deadline-missed optional refreshes are shed candidates."},{"archetype_element":"Selective sacrifice at a boundary","domain_realization":"The admission-and-queue controller removes obsolete or expired work before it can consume additional analysis capacity."},{"archetype_element":"Critical-capacity reserve","domain_realization":"A bounded share of workers and memory is unavailable to background tasks and remains available for current interactive work and recovery operations."},{"archetype_element":"Explicit handling and observability","domain_realization":"Every removed task receives a terminal reason code, and operators can inspect shed counts by repository, requester class, cause, and age."},{"archetype_element":"Bounded accumulation and recovery","domain_realization":"Dropped work is not moved to a hidden retry queue, and hysteretic, gradual re-admission prevents immediate queue reconstruction."}],"mechanism_mapping":[{"mechanism_slug":"controlled_drop","role":"Remove queued background analyses whose input revision has been superseded, converting obsolete accumulated work into explicit terminal outcomes.","counterfactual_removal":"Without controlled drop, obsolete tasks remain in the queue or merely receive lower scheduling priority, so backlog and resource commitments can remain unbounded."},{"mechanism_slug":"queue_discard_or_deadline_expiration","role":"Expire optional repository refresh work whose result would arrive after its declared usefulness deadline.","counterfactual_removal":"Without expiration, old optional refreshes can survive overload and later compete with newer work despite having lost operational value."},{"mechanism_slug":"critical_capacity_reserve","role":"Prevent background work from consuming all workers or memory needed by current interactive requests and recovery controls.","counterfactual_removal":"Without a reserve, shedding may occur too late because already-admitted background tasks can occupy every execution slot."},{"mechanism_slug":"hysteretic_controlled_reentry","role":"Require lower recovery thresholds and a stabilization interval before gradually restoring background admission.","counterfactual_removal":"Without hysteresis and staged re-entry, minor metric fluctuations can cause repeated shedding and re-admission or instantly recreate the overload."}],"causal_chain":["Broad source changes generate more analysis tasks than the shared service can safely execute.","Many queued background tasks become obsolete when newer revisions of the same analysis region arrive.","Retaining all tasks lets obsolete work consume queue slots, memory, and workers, delaying current interactive requests and eroding recovery headroom.","The overload controller detects unsafe utilization or queue age and classifies queued work by request class, revision currency, and usefulness deadline.","Superseded and expired background tasks are explicitly terminated, while reserved capacity remains available to current-revision interactive requests.","The runnable backlog contracts instead of relocating, reducing contention and allowing current work to reach workers.","Lower recovery thresholds plus gradual re-admission let the service return to normal operation without immediate oscillation."],"baseline":"The service admits every well-formed analysis task, uses ordinary priority scheduling to favor interactive work, and eventually discards stale results only when they attempt publication. This can delay obsolete tasks but does not remove their queued or execution cost.","nearest_rivals":["Priority scheduling: changes execution order but retains obsolete work and its backlog.","Rate limiting: caps submission frequency without necessarily distinguishing a current request from a superseded one or removing already-queued work.","Backpressure: asks editors or index producers to slow down but depends on upstream cooperation and does not clear obsolete work already admitted.","Buffering: absorbs bursts temporarily but preserves the work and can postpone overload.","Graceful degradation: could return less precise analysis for each request, whereas this intervention sacrifices selected requests while retaining the protected request contract.","Capacity expansion: adds workers or memory rather than converting excess demand into bounded, policy-governed loss."],"remaining_contrastive_claim":"The candidate's distinguishing claim is that overload is contained by explicitly terminating provably superseded or deadline-invalid analysis tasks at the queue boundary, not merely by slowing, reordering, buffering, or reducing the quality of all analysis; protected current-revision requests retain reserved capacity and their normal result contract.","authority_safety":{"decision_authority":"The code-intelligence platform team may configure and activate the policy for service-owned queues after repository owners define which analysis kinds are optional and which request classes are protected.","authorized_first_step":"Run the policy in shadow mode on recorded or synthetic queue metadata, computing hypothetical shed decisions without cancelling live tasks or changing developer-visible responses.","excluded_actions":["Dropping security, authorization, repository-integrity, or data-migration checks","Cancelling a task after it has committed externally visible index state unless the task supports an atomic rollback","Trusting a caller-supplied priority label without server-side authentication and policy validation","Moving shed tasks into an unbounded retry or dead-letter backlog","Publishing analysis produced from a superseded revision as current","Enabling live shedding from the first evidence step"],"halt_rollback":"In shadow mode, halt if the policy marks any protected task, cannot establish revision ordering, or exceeds the predefined wrong-shed tolerance of zero for the labelled test set. A later live pilot must support immediate disabling of admission decisions, preserve terminal audit records, and restore the previous admit-all priority scheduler for new work; already terminated tasks may be resubmitted only from the latest repository state."},"negative_tests":{"strongest_counterevidence":"During representative overload traces, superseded or expired tasks account for too little queued or executing cost to release meaningful headroom, or protected-request latency remains unsafe even if every eligible task is hypothetically removed.","problem_falsifier":"The inferred problem is falsified if interactive degradation is primarily caused by a correctness defect, lock contention, dependency-service failure, or per-request computational blowup rather than aggregate excess work and obsolete backlog.","intervention_falsifier":"The intervention is falsified if shadow evaluation cannot identify shed-eligible work before execution with zero protected-task classifications, or if replay shows that removing eligible tasks does not bound queue growth and restore capacity for protected requests.","risks":["Incorrect revision or dependency tracking could classify still-needed analysis as superseded.","Interactive clients could game priority labels and consume the protected reserve.","Repositories with frequent edits could have background analysis repeatedly shed and never obtain a complete index.","Shedding could disproportionately degrade developers working in large or generated-code-heavy repository regions.","Terminal notifications could trigger automatic client retries and recreate load elsewhere.","Thresholds without sufficient hysteresis could cause oscillatory shedding.","The policy could conceal chronic undercapacity or inefficient analysis algorithms.","Cancelling non-atomic tasks could leave partial index state or resource leaks.","Metrics aggregated across repositories could hide unfair sacrifice concentrated in one tenant."]},"next_evidence_step":"Construct a bounded offline replay using one previously retained overload trace, or a synthetic trace if none exists, containing task arrival time, authenticated class, repository and branch, analysis region, revision, deadline, estimated or measured resource cost, and completion outcome. Label protected and supersession relations independently of the policy. Compare the admit-all priority baseline with shadow shedding over the same trace, checking: zero protected tasks selected; explicit terminal classification for every selected task; no relocated retry backlog; peak and final runnable-queue size; protected-request waiting time; released worker-time estimate; shed distribution by repository; and stability under small threshold perturbations. Limit the exercise to one service, one workload window, and no production cancellations. Proceed to any live canary only if eligible obsolete work is identifiable before execution, the queue is bounded in replay, and protected-task selection remains zero.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed because runtime isolation forbids inspection of other proposals; this candidate is derived solely from the supplied load-shedding archetype and computer-science domain card.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}