{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"objective_weighting_governance__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"objective_weighting_governance__computer_science__P1","proposal_index":1,"version":0,"title":"Governed Objective Weights for Pre-Merge CI Test Scheduling","problem":"A software organization with limited continuous-integration compute ranks which test suites run first—or run at all—using a composite priority score combining estimated defect-detection value, runtime, flakiness, code-change relevance, security relevance, and developer waiting time. The coefficients and compensability assumptions are controlled as scheduler configuration, so affected service owners cannot determine why a slow security or integration suite lost priority to faster tests, whether small coefficient changes would reverse the schedule, or who may revise the tradeoffs.","actors":["CI platform engineers who implement and operate the scheduler","Repository and service owners whose changes enter the test queue","Developers waiting for pre-merge results","Security engineers responsible for security-relevant test obligations","Site-reliability engineers responsible for production-risk controls","Engineering governance owner authorized to approve organization-wide CI policy"],"observable_state":"For a fixed set of queued changes and test suites, the scheduler emits test priorities or omissions from a weighted score, yet its decision record does not expose the objectives, normalized scales, coefficients, protected minima, rationale, approving authority, or ranking sensitivity. Replaying the queue with modestly different defensible coefficients can change which suites receive scarce compute before a merge deadline.","consequence":"A nominally technical scheduler can silently trade regression-detection and security assurance against compute cost or developer latency, making merge evidence dependent on unreviewed value choices and leaving contested omissions difficult to explain, appeal, or revise.","affected_objective":"Legitimate allocation of constrained pre-merge CI compute while preserving non-compensable assurance requirements and making tradeoffs among feedback latency, compute use, and defect-detection priorities inspectable.","intervention":"Wrap the CI test-priority model in an objective-weight governance process. Define each objective and proxy; separate mandatory branch-protection, security, and release-assurance suites from compensatory preferences; publish candidate weights, scales, rationales, ownership, and effective dates; generate per-queue decision-impact traces; run a weight sensitivity sweep over predeclared plausible alternatives; require review by the CI policy owner with security and reliability sign-off for protected thresholds; approve weights only when fragile scheduling outcomes are disclosed and accepted; and record revision triggers such as changed compute capacity, proxy drift, repeated contested omissions, or altered assurance requirements.","structural_mapping":[{"archetype_element":"Objective Set","domain_realization":"Estimated defect-detection value, change relevance, security relevance, feedback latency, compute consumption, suite flakiness, and coverage of historically under-tested components."},{"archetype_element":"Objective Weight","domain_realization":"Explicit coefficients applied to normalized CI test-suite attributes when calculating scheduling priority."},{"archetype_element":"Weight-Setting Process","domain_realization":"A documented proposal in which the CI policy owner states coefficients, rationale, uncertainty, data period, and intended compensatory tradeoffs before approval."},{"archetype_element":"Stakeholder Review","domain_realization":"Service-owner representatives inspect impact traces, while security and reliability reviewers evaluate assurance consequences before the policy owner authorizes deployment."},{"archetype_element":"Legitimacy Rule","domain_realization":"Weights are acceptable only if their objectives, proxies, scales, consequences, reviewers, objections, and authorization are recorded and protected suites cannot be displaced by a high score elsewhere."},{"archetype_element":"Weight Sensitivity Analysis","domain_realization":"Offline replay varies coefficients within predeclared plausible ranges and records changes in test ordering, deadline completion, and suite omission."},{"archetype_element":"Decision Impact Trace","domain_realization":"Each replay links a weight set to the suites advanced, delayed, or omitted for each queued change, including the score contributions responsible."},{"archetype_element":"Protected Threshold","domain_realization":"Required security, branch-protection, and release-gating suites must complete successfully; weighted priority cannot compensate for their absence."},{"archetype_element":"Proxy Alignment Check","domain_realization":"Reviewers test whether historical failure yield, code-path similarity, and flakiness estimates still represent assurance value rather than merely favoring frequently executed or inexpensive suites."},{"archetype_element":"Revision Procedure","domain_realization":"Weights expire on a stated review date and reopen when compute capacity, assurance policy, proxy validity, or observed scheduling impacts materially change."},{"archetype_element":"Audit Trail","domain_realization":"A versioned policy record captures proposed and approved weights, objections, sensitivity results, sign-offs, effective dates, and subsequent changes."},{"archetype_element":"Score Interpretation Rule","domain_realization":"The score may order optional suites within available capacity but may neither waive protected suites nor independently authorize a merge."}],"mechanism_mapping":[{"mechanism_slug":"weighted_scoring_model","role":"Computes an inspectable priority for optional test suites from normalized objective values and approved weights.","counterfactual_removal":"Without it, there is no composite weighting rule to govern; the intervention would instead address a different scheduling policy."},{"mechanism_slug":"scorecard_disclosure_template","role":"Publishes objective definitions, proxies, scales, weights, rationales, compensability rules, authority, and effective date in a consistent artifact.","counterfactual_removal":"Reviewers would receive outcomes without a stable account of the value choices that produced them."},{"mechanism_slug":"weight_sensitivity_sweep","role":"Replays historical queues across plausible weight sets to reveal scheduling decisions that depend on reasonable disagreement about priorities.","counterfactual_removal":"The approval process could disclose coefficients while concealing that small changes reverse which suites run before the deadline."},{"mechanism_slug":"ranking_stability_report","role":"Summarizes stable and fragile test-ordering or omission decisions and links them to affected repositories and suites.","counterfactual_removal":"Raw replay results would not translate coefficient variation into reviewable consequences for actual CI decisions."},{"mechanism_slug":"audit_trail_for_weight_changes","role":"Records who changed the scheduler weights, under what authority, for what reason, and after which reviews.","counterfactual_removal":"Post-hoc manipulation and stale policies would be difficult to distinguish from authorized revision."}],"causal_chain":["Scarce pre-merge compute forces the CI scheduler to trade among multiple unlike objectives.","A composite priority score converts those tradeoffs into coefficients and proxy measurements.","When coefficients, compensability, and authority remain implicit, scheduler outputs appear technically determined even though they encode contestable assurance choices.","Explicit objective definitions and proxy checks expose what each score term is allowed to represent.","Protected thresholds remove mandatory assurance suites from compensatory scoring, preventing cheap or fast tests from offsetting their omission.","Decision-impact traces and a weight sensitivity sweep show which concrete suite schedules change under plausible alternative priorities.","Accountable stakeholder review uses those consequences—not coefficients alone—to approve, reject, or revise the proposed weights.","A versioned approval and revision record keeps the operative rule traceable as capacity, evidence, and assurance obligations change.","The resulting scheduler remains an optimization mechanism, but its value tradeoffs become bounded, inspectable, contestable, and revisable."],"baseline":"The CI platform team selects and tunes scheduler coefficients as an internal implementation detail, optionally responding to complaints through ad hoc exceptions. Mandatory and preferential suites may be mixed in one score, and neither ranking fragility nor the decision authority behind coefficient changes is routinely exposed.","nearest_rivals":["Shortest-job-first or runtime-minimizing CI scheduling, which pursues a comparatively narrow latency or throughput objective without governing tradeoffs among assurance values.","Coverage- or change-relevance-based test selection, which improves a proxy or prediction method but does not establish who may authorize competing objective weights.","Fixed per-repository compute quotas, which constrain allocation but do not explain tradeoffs among optional suites inside each quota.","Manual mandatory-test lists plus operator overrides, which can protect named suites but lack systematic impact tracing, sensitivity review, and a lifecycle for the remaining composite priorities.","Pareto-front presentation of latency, compute, and detection alternatives, which preserves tradeoffs for selection rather than authorizing a governed composite ranking."],"remaining_contrastive_claim":"The candidate is not a new test-selection predictor or scheduling heuristic. Its distinct claim is that coefficients governing consequential CI scheduling should be treated as authorized, reviewable value choices: mandatory assurance is separated from compensatory scoring, and weight fragility must affect approval and revision rather than remain a technical diagnostic.","authority_safety":{"decision_authority":"The engineering governance owner may approve the organization-wide weighting policy; CI platform engineers may implement only an approved version; security and site-reliability owners control the protected thresholds within their mandates; repository owners may review evidence and raise objections but may not unilaterally weaken organization-wide safeguards.","authorized_first_step":"A CI analyst may conduct a read-only offline replay on a bounded sample of previously completed queues using existing scheduler logs, documenting the current objective terms and comparing the current weights with predeclared alternative weight sets. The replay may produce a draft disclosure and stability report but may not alter live scheduling or merge eligibility.","excluded_actions":["Changing production scheduler coefficients or queue order","Adding, removing, or bypassing required tests or branch-protection rules","Using the draft score to approve or reject a live merge","Granting the review group access beyond existing authorization","Backfilling missing evidence with invented proxy values","Tuning alternative weights after seeing which repositories or teams benefit"],"halt_rollback":"Stop the replay if required logs cannot be accessed lawfully, if proxy definitions cannot be reconstructed, if the sample exposes secrets or individual performance data, or if protected suites cannot be distinguished reliably. Delete only newly generated derived reports under the applicable retention rule, preserve source logs unchanged, and make no production rollback because the authorized step changes no live state."},"negative_tests":{"strongest_counterevidence":"Current scheduler documentation and logs show a single uncontested objective, or show that all contested objectives, weights, scales, protected suites, rationale, authorization, impact traces, sensitivity results, and revision triggers are already explicit and operative.","problem_falsifier":"Across the bounded replay sample, the scheduler does not combine competing objectives into a consequential score, or its ordering has no effect on which test evidence becomes available before merge decisions.","intervention_falsifier":"After reconstructing valid proxies and testing the predeclared plausible weight sets, no scheduling decision changes and reviewers identify no contested compensability or authority issue; in that setting, the proposed governance layer addresses no demonstrated weighting fragility or legitimacy gap.","risks":["Review can become ceremonial if affected service owners can comment but cannot trigger reconsideration.","Publishing score details may encourage repositories to game change-relevance, duration, or failure-yield proxies.","Historical replay can reproduce gaps in test availability and thereby make biased coverage patterns appear legitimate.","Too many protected suites can exhaust capacity and make weighted scheduling irrelevant.","Broad sensitivity ranges can exaggerate instability, while narrow ranges can conceal reasonable disagreement.","Governance latency can delay necessary scheduler maintenance.","Security or reliability representatives may acquire de facto veto power beyond their defined threshold authority.","A composite score can create false commensurability even when its weights are transparent."]},"next_evidence_step":"Select one previously completed seven-day CI queue window for one bounded repository group; reconstruct the live score terms and coefficients from authorized configuration and logs; identify protected suites from existing policy; pre-register three alternative weight sets supplied independently by the CI policy owner, a service-owner representative, and an assurance representative; replay without changing production; and report objective definitions, score contributions, suites advanced or omitted before their original deadlines, ranking reversals, proxy-data gaps, and any threshold violations. The step ends with an evidence review and authorizes no deployment decision.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed against other proposals because runtime isolation prohibits inspecting them; this candidate was derived solely from the supplied archetype and computer-science domain card.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial one-shot breadth candidate","Concrete computer-science problem inference","Causal preservation of objective-weight governance","Bounded and non-deploying evidence step"],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}