{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"deadweight_loss_reduction__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"deadweight_loss_reduction__computer_science__P1","proposal_index":1,"version":0,"title":"Risk-Tiered Approval Path for Routine Dependency Updates","problem":"A software organization requires the same two senior human approvals for every production dependency update, including narrowly scoped, machine-generated patch releases with unchanged permissions and passing tests. The uniform gate protects supply-chain security and service reliability, but its coarse scope can block routine maintenance beyond what those protections require.","actors":["Application developers submitting dependency updates","Senior maintainers serving as mandatory reviewers","Security and software-supply-chain owners","Service owners accountable for production reliability","Users affected by vulnerabilities or regressions"],"observable_state":"Repository records show routine dependency-update pull requests waiting for the same senior-review path as high-risk changes; some repeatedly require rebasing, expire, or are superseded while eligible reviewers are occupied. At the same time, the review queue contains patches that already have verified provenance, a bounded version change, unchanged requested privileges, and passing automated checks.","consequence":"Safe maintenance work can remain unrealized despite available engineering capacity: developers repeat merge preparation, scarce reviewers spend attention on low-variance cases, and services remain on older dependencies longer. Removing review indiscriminately could instead admit compromised packages or regressions.","affected_objective":"Timely adoption of safe dependency fixes while preserving software-supply-chain integrity, production reliability, accountability, and equitable access to reviewer capacity.","intervention":"Run a Distortion-Reduction Review of the universal approval rule, then authorize a reversible Regulatory Simplification Pilot for a narrowly defined low-risk class. Eligible updates would still require immutable package provenance, allowlisted registries, lockfile integrity, tests, vulnerability and license checks, unchanged privileges, a patch-level scope limit, and named service-owner accountability, but would need one maintainer approval instead of two senior approvals. Updates involving new dependencies, major versions, install scripts, permission changes, failed checks, critical services, or ambiguous provenance retain the existing path. Compare queue, rework, safety, and incidence outcomes and automatically end or narrow the pilot if safeguards fail.","structural_mapping":[{"archetype_element":"Beneficial activity blocked","domain_realization":"Routine, evidence-backed dependency maintenance that developers and service owners are prepared to merge."},{"archetype_element":"Distortion Map","domain_realization":"The universal two-senior-review rule applies a high-risk approval cost to low-risk and high-risk dependency changes alike."},{"archetype_element":"Protected Constraint Safeguard","domain_realization":"Provenance, integrity, privilege, test, vulnerability, license, accountability, and critical-service controls remain mandatory; only redundant approval is conditionally reduced."},{"archetype_element":"Surplus Estimate","domain_realization":"Estimate potentially recovered reviewer attention, developer rework, and time-to-safe-update from repository events, with assumptions and uncertainty reported separately rather than monetized as a certain gain."},{"archetype_element":"Affected-Party Incidence Map","domain_realization":"Developers may gain faster handling, senior maintainers may regain attention, security and service owners may inherit monitoring duties, and users could bear regression or compromise risk if classification is wrong."},{"archetype_element":"Redesign Lever","domain_realization":"Replace a uniform approval count with a bounded, evidence-based risk tier while retaining substantive checks."},{"archetype_element":"Implementation Boundary","domain_realization":"Only pre-specified repositories and patch-level updates satisfying every eligibility predicate enter the pilot."},{"archetype_element":"Monitoring and Rebound Check","domain_realization":"Track queueing, rebases, reviewer concentration, bypass attempts, post-merge reversions, incidents, and growth in nominally low-risk submissions."},{"archetype_element":"Rollback or Adjustment Rule","domain_realization":"Restore two senior approvals for the affected class if integrity checks are bypassed, classification errors cross the pre-registered threshold, or a qualifying update causes a defined security or reliability event."}],"mechanism_mapping":[{"mechanism_slug":"distortion-reduction-review","role":"Separates avoidable duplicate approval from the substantive security and reliability purpose of review, while documenting blocked work, incidence, and uncertainty.","counterfactual_removal":"Without this review, the organization could mistake all review effort for waste and weaken necessary controls, or retain the universal rule without testing whether its coarse scope causes avoidable loss."},{"mechanism_slug":"regulatory-simplification-pilot","role":"Tests the narrower approval path on reversible, bounded cases with a sunset, monitoring criteria, and automatic rollback.","counterfactual_removal":"Without the pilot boundary, the redesign would become an organization-wide policy claim without evidence about behavioral response, gaming, or safety."},{"mechanism_slug":"permit-or-approval-streamlining","role":"Reduces duplicated permission delay for cases where machine-verifiable safeguards already satisfy much of the protected purpose.","counterfactual_removal":"Without changing the approval path, better diagnostics alone would not release blocked maintenance or scarce reviewer attention."}],"causal_chain":["A universal two-senior-review rule assigns the same approval burden to dependency changes with materially different observable risk attributes.","Routine qualifying updates join the same scarce-reviewer queue as changes requiring expert judgment.","Waiting triggers rebasing, resubmission, abandonment, reviewer context switching, and delayed adoption of fixes.","A pre-specified risk tier separates machine-verifiable low-risk cases from changes with new or ambiguous exposure.","For qualifying cases, one redundant senior approval is removed while provenance, integrity, automated checks, accountability, and escalation remain.","If the removed approval was an avoidable wedge, qualifying maintenance should proceed with less queueing and rework without deterioration in protected outcomes.","Pilot monitoring detects classification gaming, regressions, security events, burden shifts, or queue displacement and triggers adjustment or rollback."],"baseline":"Every production dependency update requires two senior human approvals regardless of version scope, provenance, privileges, automated-check results, or service criticality; exceptions are informal or absent.","nearest_rivals":["Transaction Cost Reduction: reviewer coordination and waiting are costs, but the focal intervention changes a rule-mediated allocation of scarce approval authority and must preserve its protective purpose.","Asymmetric Screening: a cheap automated screen can support the tier, but screening alone does not decide whether the universal approval requirement destroys value beyond what its protection justifies.","Access Control: approval rules authorize changes, but the candidate does not primarily redesign who may access a resource; it redesigns when an additional authorization is required.","Generic CI automation: more tests may provide evidence for eligibility, but automation alone does not map incidence, narrow the governance wedge, or define rollback authority."],"remaining_contrastive_claim":"The candidate is specifically a deadweight-loss repair if low-risk updates are demonstrably blocked by a coarse approval rule, an additional senior approval contributes little marginal protection within the bounded class, and the same security and reliability constraints can be preserved through targeted checks, escalation, and monitoring. If reviewer search or verification effort remains the main obstacle after the rule is changed, a transaction-cost account is closer.","authority_safety":{"decision_authority":"Repository maintainers jointly with the software-supply-chain security owner and accountable service owners; no individual developer may self-declare an update eligible.","authorized_first_step":"Conduct a read-only retrospective classification and incidence review, define proposed eligibility predicates and stop conditions, and seek the named authorities' approval before any workflow change.","excluded_actions":["Removing all human review from dependency updates","Allowing new dependencies, major versions, install scripts, permission changes, failed checks, ambiguous provenance, or critical-service changes into the low-risk path","Weakening provenance, integrity, vulnerability, license, testing, audit-log, or service-owner requirements","Changing production repositories before pilot authorization","Using aggregate time savings to override a security, reliability, rights, or accountability objection"],"halt_rollback":"Pause admission immediately on evidence of safeguard bypass, systematic misclassification, unauthorized scope expansion, or a qualifying security or reliability event. Restore the baseline approval rule for open and future cases, retain audit evidence, and require joint security-maintainer review before resumption."},"negative_tests":{"strongest_counterevidence":"A matched retrospective review finds that the second senior approval frequently catches consequential defects or compromised-package indicators in cases that would satisfy the proposed low-risk predicates, or that apparent waiting is caused by failed tests, unresolved ownership, or real reviewer work rather than the approval-count rule.","problem_falsifier":"After controlling for failed checks, change scope, service criticality, and author response time, qualifying updates do not wait, rebase, expire, or consume scarce-review capacity differently from comparable work, so no material rule-mediated wedge is observable.","intervention_falsifier":"In a pre-authorized bounded pilot, the narrower path does not reduce rule-attributable queueing or rework, or it increases classification errors, bypass attempts, reversions, security findings, reliability events, or concentrated burdens beyond pre-registered stop thresholds.","risks":["Attackers or maintainers may shape changes to satisfy low-risk predicates while hiding meaningful risk.","Automated evidence may miss malicious package behavior, ecosystem compromise, or environment-specific regressions.","Reduced approval could normalize weaker scrutiny and expand beyond the authorized scope.","Faster merging could increase aggregate update volume and create testing or deployment congestion elsewhere.","Security and service owners may receive new monitoring burdens while developers capture most of the benefit.","Teams with mature test suites may gain access to the fast path while less-resourced teams remain queued, worsening internal inequity.","Sparse incidents may make safety comparisons inconclusive and invite false confidence."]},"next_evidence_step":"Using only historical records, sample at most 100 production dependency-update pull requests from a single repository group over the most recent completed 90-day period. Blindly apply the proposed eligibility predicates; record approval timestamps, failed checks, rebases, abandonment, defects caught by each approval, post-merge reversions, security findings, service criticality, and actor incidence. Produce a sensitivity table for alternative eligibility boundaries and a go/no-go recommendation for a time-limited pilot; make no approval-policy change during this step.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"No comparison with other experiment proposals was performed under runtime isolation; this candidate is distinguished internally by its concrete focus on a coarse dependency-update approval rule, preserved supply-chain safeguards, and a reversible repository-bounded risk-tier pilot.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial one-shot candidate only"],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}