{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"load_balancing__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"load_balancing__computer_science__P1","proposal_index":1,"version":0,"title":"Capability-Constrained Code-Review Routing for Monorepositories","problem":"In a monorepository, static ownership rules and habitual reviewer selection can concentrate incoming change reviews on a few authorized maintainers even when other authorized, sufficiently knowledgeable reviewers have usable capacity. The concentration is an assignment problem only where reviewers are genuinely substitutable for the change and all approval, independence, and security constraints can be preserved.","actors":["Change authors requesting review","Authorized code reviewers and component maintainers","Repository or engineering-platform owner","Security and compliance owners defining protected-change constraints","Release engineers affected by pending approvals"],"observable_state":"For the same eligibility class of changes, some reviewers have growing counts and ages of active review requests while other authorized, available reviewers have no or materially fewer active requests. The state is observable from request timestamps, reviewer assignments, completion timestamps, declared availability, component authorization, conflict rules, and current review work in progress.","consequence":"Concentrated review queues can delay merges and releases, increase interruption burden on hot-spot maintainers, and leave already-authorized review capacity unused. Reassigning work incorrectly could instead weaken review quality, violate separation of duties, or disclose protected code.","affected_objective":"Maintain timely, policy-compliant review of software changes while avoiding preventable assignment skew among interchangeable authorized reviewers.","intervention":"Insert an auditable advisory router between determination of a change's required reviewer class and issuance of review invitations. For each new request, first filter the reviewer pool by component authorization, required expertise, separation-of-duty rules, conflicts, protected-code access, and declared availability. Among the remaining viable reviewers, use capacity-aware weighted routing based on active review work, estimated change effort, and recent assignment burden. Downweight unavailable or repeatedly nonresponsive reviewers, preserve required owner approval and existing review continuity, impose a cooldown to prevent reassignment flapping, and expose the routing reason to authors and repository owners. Initially run the router only in shadow mode without changing assignments.","structural_mapping":[{"archetype_element":"Incoming work or flow","domain_realization":"New pull-request or change-set review requests entering the repository's approval process."},{"archetype_element":"Multiple viable receivers","domain_realization":"Reviewers who are independently authorized and sufficiently knowledgeable for the particular component and change class."},{"archetype_element":"Localized overload with idle equivalent capacity","domain_realization":"A maintainer accumulates eligible pending reviews while another interchangeable, available reviewer has unused review capacity."},{"archetype_element":"Capacity signal","domain_realization":"Active review count, estimated remaining review effort, recent assignment burden, and declared availability for each eligible reviewer."},{"archetype_element":"Health check","domain_realization":"Checks for leave, account suspension, revoked repository access, persistent nonresponse, or inability to review the protected change class."},{"archetype_element":"Distribution policy","domain_realization":"A compatibility-first weighted least-load rule with fairness bounds and cooldowns."},{"archetype_element":"Affinity and consistency invariant","domain_realization":"An in-progress review remains with its reviewer unless explicitly declined or reassigned; changes requiring designated owners or independent approvers retain those requirements."},{"archetype_element":"Feedback and monitoring","domain_realization":"Assignment outcomes update availability and effort estimates while dashboards expose request-age, load-skew, reassignment, and policy-violation measures."}],"mechanism_mapping":[{"mechanism_slug":"capacity_aware_routing","role":"Selects among policy-equivalent reviewers using current review work and estimated effort rather than a static owner order.","counterfactual_removal":"Without the capacity signal, the intervention collapses into static rotation or blind distribution and cannot specifically redirect work away from a review hot spot."},{"mechanism_slug":"health_checked_distribution","role":"Excludes or downweights reviewers who are unavailable, unauthorized, or operationally unable to respond.","counterfactual_removal":"Without viability checks, requests can be routed to absent or ineligible reviewers, creating delay or governance violations."},{"mechanism_slug":"weighted_routing","role":"Accounts for differences in reviewer capacity, expertise breadth, and recent burden instead of treating every eligible reviewer as identical.","counterfactual_removal":"Without weights, equal splitting can overload part-time or narrowly qualified reviewers and underuse reviewers able to absorb more work."}],"causal_chain":["Static ownership and habitual selection repeatedly send eligible changes to the same visible maintainers.","Their active-review queues grow while some interchangeable authorized reviewers retain capacity.","The router reconstructs the viable receiver set for each incoming change before considering load.","Live capacity and health signals downweight busy or unavailable reviewers within that viable set.","Weighted routing directs the new request to an eligible reviewer with usable capacity while preserving protected-change and independence constraints.","Cooldowns and continuity rules prevent rapid reassignment and loss of review context.","Observed assignments and outcomes reveal whether concentration changes without introducing policy violations, silent drops, or a new routing bottleneck."],"baseline":"Static component-owner lists plus author-selected familiar reviewers, with manual reassignment after delay or explicit decline. The baseline may identify who is authorized but does not systematically use live capacity when choosing among authorized reviewers.","nearest_rivals":["A priority queue orders which changes should be reviewed first but does not change which eligible reviewer receives each change.","Reviewer reminders or response-time escalation pressure the currently assigned reviewer without using idle equivalent capacity elsewhere.","Adding maintainers or training reviewers changes the eligible capacity pool but does not govern distribution across capacity already present.","Round-robin assignment changes destinations but ignores live workload, change effort, authorization differences, and reviewer availability.","Work-in-progress caps or backpressure slow admission of new review requests rather than assigning admitted requests to another viable reviewer."],"remaining_contrastive_claim":"The candidate's distinctive intervention is compatibility-first destination selection among already-authorized reviewers using live capacity and health signals. Queue prioritization changes order, staffing changes total capacity, reminders act on the current receiver, and backpressure changes admission. Whether this routing improves review outcomes remains an empirical hypothesis.","authority_safety":{"decision_authority":"The repository or engineering-platform owner may define and approve routing policy, but existing branch-protection, component-owner, security, and separation-of-duty authorities continue to determine who may approve each change.","authorized_first_step":"Perform a read-only shadow replay on historical review metadata for one repository; generate hypothetical recommendations without inviting reviewers, changing access, reassigning requests, or satisfying approval requirements.","excluded_actions":["Automatically granting review or repository permissions","Bypassing required owners, independent approval, or protected-branch controls","Sending protected change details to reviewers lacking access","Reassigning an active review without an explicit decline or authorized human decision","Using personal performance evaluations or sensitive attributes as routing weights","Automatically merging or approving changes","Changing production review assignments during the first evidence step"],"halt_rollback":"Stop the shadow evaluation if eligibility reconstruction cannot reliably reproduce existing authorization constraints, if protected metadata is exposed, or if recommendations include an ineligible reviewer. Because the first step is read-only, rollback consists of deleting derived recommendations and disabling the shadow job; existing review assignments and controls remain unchanged."},"negative_tests":{"strongest_counterevidence":"Apparent idle reviewers may not be true substitutes because of undocumented expertise, access, independence, language, or ownership constraints; alternatively, review delay may be dominated by change complexity, author revisions, or a shared validation bottleneck rather than assignment concentration.","problem_falsifier":"After reconstructing reviewer eligibility and availability, there are no intervals in which one reviewer has an accumulating eligible queue while another genuinely interchangeable authorized reviewer has usable capacity, or review waiting time does not vary with assignment concentration.","intervention_falsifier":"In shadow replay, the router either makes no different destination choices during verified hot spots, yields equal or worse simulated queue-age and capacity-normalized skew, or can change assignments only by violating authorization, continuity, independence, or protected-code constraints.","risks":["Incorrect eligibility modeling could recommend unauthorized reviewers.","Review quality could decline if nominal authorization masks tacit expertise differences.","Capacity estimates could become stale or invite gaming.","Routing could shift overload rather than remove it.","Frequent changes could destroy reviewer context despite cooldowns.","Fairness and throughput weights could concentrate undesirable work on particular reviewers.","The router could become a central workflow dependency or expose sensitive activity data.","Balanced reviewer assignments could leave a shared test, author-response, or release bottleneck untouched."]},"next_evidence_step":"For one repository and a fixed 14-day historical window, reconstruct each review request's viable reviewer set using recorded authorization, ownership, availability, and independence constraints. Replay arrivals in timestamp order through the shadow router and compare its recommendations with the baseline on eligibility violations, unassigned requests, assignment skew, active-review queue depth, request-age distribution, reassignment frequency, and sensitivity to stale capacity data. Manually audit every recommended reviewer change for a bounded sample of 30 requests. Do not alter live assignments; terminate the test if any recommendation violates an invariant.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"This isolated one-shot candidate applies receiver-aware balancing to governed human code-review assignment rather than runtime request traffic; no other experiment proposals were inspected or used.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial one-shot construction of a complete, falsifiable reverse-innovation candidate."],"conceptual_changes":["Initial version; no prior candidate was revised."],"operational_changes":["Initial version defines a read-only shadow replay with explicit authority boundaries and rollback."],"evidence_changes":["No prior-art evidence was searched; the first evidence step is limited to repository-local historical metadata."],"claim_changes":["Initial contrastive claim is structural and explicitly leaves outcome improvement as an empirical hypothesis."]}}