{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"pareto_frontier_navigation__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"pareto_frontier_navigation__computer_science__P1","proposal_index":1,"version":0,"title":"Frontier-Governed Static-Analysis Bundles for Monorepo CI","problem":"A monorepo team must choose which static-analysis rules and execution settings to run on every pull request. Candidate bundles differ simultaneously in high-severity defect detection, false-positive review burden, and CI latency. Teams comparing bundles through one aggregate score or inherited defaults may retain a bundle that is no better than another feasible bundle on any measured objective and worse on at least one.","actors":["Repository maintainers who define candidate analysis bundles","Developers who receive and investigate findings","Security and reliability engineers who define protected defect categories","CI platform operators who enforce compute and latency constraints","Engineering governance owner who approves the deployed bundle"],"observable_state":"For a fixed replay corpus of historical code changes, each candidate bundle has recorded high-severity defect detection, false-positive findings requiring review, p95 CI latency, and compute consumption. At least one feasible bundle is weakly worse than another on every recorded objective and strictly worse on one or more, while several remaining bundles exchange additional detection for additional latency or review burden.","consequence":"Decision attention can be spent defending inefficient bundles, developers can incur avoidable alert and waiting burden, and the selected CI configuration can embody an undocumented tradeoff between defect detection and delivery friction.","affected_objective":"Select an admissible pull-request analysis bundle that avoids dominated combinations of defect detection, false-positive burden, CI latency, and compute consumption while making the remaining value tradeoff explicit and reviewable.","intervention":"Construct a versioned decision table of feasible static-analysis bundles, apply security and operational guardrails before comparison, run Dominance Screening across defect detection, false-positive burden, p95 latency, and compute use, and use Pareto Frontier Analysis to expose the non-dominated bundles. The authorized governance owner then selects one frontier bundle under an explicit priority rule: satisfy protected-category detection floors first, then prefer the lowest review burden unless accepting additional burden yields a documented detection gain. Record the accepted sacrifice profile and re-run a Scenario Sensitivity Sweep when the codebase, analyzer versions, protected categories, or CI budget changes.","structural_mapping":[{"archetype_element":"Option Set","domain_realization":"Version-pinned bundles of static-analysis rules, severities, scopes, and execution settings that could run on each pull request."},{"archetype_element":"Objective Dimensions","domain_realization":"Protected-category defect detection, false-positive findings per change, p95 CI latency, and compute consumption, with direction and measurement procedure declared for each."},{"archetype_element":"Feasibility Constraints","domain_realization":"Every bundle must preserve required repository checks, meet protected-category detection floors, remain within the CI compute ceiling, and produce reproducible findings on the replay environment."},{"archetype_element":"Dominance Criterion","domain_realization":"Bundle A dominates bundle B only when A is at least as good on every declared objective and clearly better on at least one after applying prespecified uncertainty tolerances."},{"archetype_element":"Frontier Map","domain_realization":"A versioned table and tradeoff visualization containing only non-dominated bundles, with confidence intervals and qualitative limitations attached."},{"archetype_element":"Preference or Priority Rule","domain_realization":"After guardrails, prefer lower false-positive burden; accept a higher-burden frontier bundle only for an explicitly documented gain in protected-category detection, subject to the latency ceiling."},{"archetype_element":"Tradeoff Rationale","domain_realization":"The approval record states the detection gained, review burden and latency accepted, rejected frontier alternatives, and the actor accountable for the choice."},{"archetype_element":"Recheck Trigger","domain_realization":"Recompute the frontier after analyzer upgrades, material code-language changes, a changed CI budget, revised protected categories, or replay evidence that crosses a declared tolerance."},{"archetype_element":"Implementation Commitment Record","domain_realization":"A reviewed configuration commit pins the chosen bundle, measurements, guardrails, decision rule, owner, expiry date, and rollback configuration."}],"mechanism_mapping":[{"mechanism_slug":"dominance_screening","role":"Removes feasible bundles that provide no compensating advantage on any declared objective.","counterfactual_removal":"Without screening, inherited or politically favored bundles can remain under deliberation even when another feasible bundle is no worse on every measured dimension."},{"mechanism_slug":"pareto_frontier_analysis","role":"Separates technically inferior bundles from the genuine tradeoff set without collapsing objectives into one hidden score.","counterfactual_removal":"Without a frontier, an aggregate ranking can obscure whether the selected bundle represents efficiency or merely encoded weights."},{"mechanism_slug":"scenario_sensitivity_sweep","role":"Tests whether dominance relationships and the chosen bundle persist across codebase segments, workload mixes, and measurement uncertainty.","counterfactual_removal":"Without sensitivity analysis, sampling noise or one unrepresentative workload can create false dominance and a fragile selection."}],"causal_chain":["Define candidate analysis bundles, objective directions, uncertainty tolerances, and non-negotiable security and operational guardrails.","Replay each feasible bundle on the same versioned corpus and execution environment.","Exclude bundles that violate guardrails before permitting tradeoffs.","Apply Dominance Screening so clearly inferior bundles leave the deliberation set.","Map the remaining bundles as a Pareto frontier, preserving uncertainty and unmeasured considerations.","Apply the explicit protected-detection-first and review-burden-second priority rule to select one frontier bundle.","Commit the chosen configuration with its accepted opportunity costs, owner, rollback reference, and recheck triggers.","Recompute rather than silently retain the choice when a trigger changes the option space or measurements."],"baseline":"The team retains its current static-analysis defaults or compares proposed bundles using a single weighted score. Required checks may be enforced, but dominated bundles are not explicitly removed, weights need not be reviewable, and no frontier-specific rationale or recheck trigger is recorded.","nearest_rivals":["A weighted scorecard that ranks every bundle before dominance screening","Independent pass/fail thresholds followed by selection of the cheapest surviving bundle","Single-objective autotuning for maximum defect detection under a fixed latency budget","Maintainer judgment based on a small demonstration pull request","Rule-by-rule enablement without evaluating bundle-level interactions"],"remaining_contrastive_claim":"The candidate's distinguishing operational claim is that guardrails, objective measurement, dominance elimination, frontier exposure, and an explicit human-owned preference rule must occur as separate ordered stages; neither a weighted rank nor threshold compliance alone distinguishes inefficient bundles from legitimate tradeoff choices.","authority_safety":{"decision_authority":"The designated engineering governance owner may approve a bundle only after security or reliability owners attest that protected-category floors and repository invariants are satisfied; CI operators may enforce resource ceilings but do not choose the value tradeoff.","authorized_first_step":"Run an offline, read-only replay of a small prespecified set of candidate bundles against one version-pinned historical change corpus and produce a draft frontier report; do not alter pull-request enforcement.","excluded_actions":["Disabling required security, licensing, correctness, or compliance checks","Deploying a candidate bundle to blocking production CI during the first evidence step","Treating a frontier point or knee point as automatic approval","Eliminating a bundle when an asserted compensating dimension has not been investigated","Using developer identities or productivity rankings as objective dimensions","Expanding the replay beyond repository data already authorized for analysis"],"halt_rollback":"Halt the evaluation if replayed findings expose secrets, candidate runs are not reproducible, protected-category labels are disputed, or uncertainty reverses a claimed dominance relation. Because the first step is offline, rollback is deletion of derived reports containing sensitive findings and restoration of the untouched baseline configuration; any later pilot must retain a one-commit reversion to the prior pinned bundle."},"negative_tests":{"strongest_counterevidence":"After applying guardrails and uncertainty tolerances, no candidate bundle dominates another, or stakeholder review identifies an omitted dimension such as remediation clarity or language coverage that reverses the apparent dominance relations.","problem_falsifier":"The choice has only one legitimate objective after fixed requirements are applied, or the operational issue is analyzer correctness rather than selection among multi-objective bundles.","intervention_falsifier":"A blinded comparison shows that the frontier process selects no more reviewable or defensible bundle than the baseline, or repeated corpus samples produce materially different frontier membership and selection under the same declared rule.","risks":["Historical replay labels may be incomplete or biased toward defects already known to the organization.","A missing objective can falsely eliminate a bundle with a real compensating advantage.","False-positive counts may conceal large differences in investigation effort or finding severity.","Too many dimensions may leave nearly every bundle non-dominated and fail to reduce deliberation.","The explicit priority rule may still distribute burdens unevenly across languages or teams.","Analyzer updates or codebase drift may make the recorded frontier obsolete.","A technical visualization may launder the governance owner's value judgment as an objective result."]},"next_evidence_step":"On one version-pinned historical corpus, evaluate the current bundle and no more than five feasible alternative bundles using prespecified objectives, guardrails, and uncertainty tolerances. Produce—but do not deploy—a dominance table, frontier map, sensitivity results across at least two codebase strata, and a mock selection record. The step ends with a review that checks missing dimensions, reproducibility, disputed labels, and whether any claimed dominance survives the sensitivity sweep.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed because runtime isolation prohibits inspection of other proposals; this candidate was derived solely from the supplied archetype record and computer-science domain card.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}