{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","research_id":"eoa_inverse_innovation_exp09_light_prior_art_20260804","cell_id":"incentive_compatible_rule_design__computer_science","search_lanes":{"direct_problem_and_intervention":{"queries":["package registry compatibility bond fast propagation credits downstream canary builds","software package release compatibility stake bonded fast lane","\"package registry\" \"bond\" release compatibility","\"fast lane\" package release registry compatibility"],"source_ids":["SRC3","SRC4"],"no_result_note":"No retained source described the complete proposed combination of a compatibility claim, nonmonetary propagation-credit bond, concealed downstream canaries, and fast versus staged registry lanes."},"synonyms_and_historical_terms":{"queries":["dependency update ecosystem compatibility testing downstream projects semantic versioning breakage","reverse dependency testing package release canary ecosystem CI","software package maintainer reputation penalty breaking release registry"],"source_ids":["SRC1","SRC2","SRC3"],"no_result_note":null},"products_practices_and_standards":{"queries":["npm semantic versioning compatible updates official docs","package registry reverse dependency checks before release official CRAN policy","package release staged rollout registry canary propagation official","pre-publish package review staged publishing npm"],"source_ids":["SRC1","SRC3","SRC4"],"no_result_note":null},"component_combination":{"queries":["random hidden downstream canary builds package releases incentive stake","package ecosystem regression testing reverse dependencies rollout rollback","package ecosystem hidden random reverse dependency tests before publishing","software release bond stake incentive compatibility claim mechanism"],"source_ids":["SRC2","SRC3","SRC4"],"no_result_note":"Comparative downstream testing, private pre-publication staging, and compatibility metadata were found separately, but no retained source combined them with a forfeitable propagation privilege."}},"sources":[{"source_id":"SRC1","title":"About semantic versioning","publisher":"npm, Inc.","url":"https://docs.npmjs.com/about-semantic-versioning/","source_type":"OFFICIAL_GUIDANCE","claims_supported":["npm recommends major-version increments for backward-incompatible changes and patch or minor increments for backward-compatible changes.","Dependency consumers specify acceptable update types through version ranges, making the publisher's version classification relevant to automatic update eligibility."]},{"source_id":"SRC2","title":"I Depended on You and You Broke Me: An Empirical Study of Manifesting Breaking Changes in Client Packages","publisher":"Association for Computing Machinery","url":"https://experts.nau.edu/en/publications/i-depended-on-you-and-you-broke-me-an-empirical-study-of-manifest/","source_type":"PRIMARY_RESEARCH","claims_supported":["The peer-reviewed npm study found that about 12% of dependent packages and 14% of their releases were affected by breaking changes during non-major dependency updates.","It reports that 44% of observed manifesting breaking changes were introduced in minor or patch releases that should in principle have been backward compatible.","Affected clients commonly recovered by upgrading or downgrading the provider version."]},{"source_id":"SRC3","title":"CRAN Repository Policy","publisher":"The Comprehensive R Archive Network","url":"https://stat.ethz.ch/CRAN/web/packages/policies.html","source_type":"OFFICIAL_STANDARD","claims_supported":["CRAN requires package submissions to pass checks and instructs maintainers updating packages to check whether reverse dependencies still pass.","CRAN expects advance coordination when an API change will affect dependent packages and provides a submission process with review delay.","This establishes reverse-dependency verification and controlled publication as existing practices, without a maintainer bond or fast-lane credit system."]},{"source_id":"SRC4","title":"Drydock: pre-publish package review","publisher":"Drydock","url":"https://drydock.org/","source_type":"FIRST_PARTY_PRODUCT","claims_supported":["Drydock integrates with private staged npm candidates and gated PyPI, npm, and VS Code publishing workflows.","It compares a candidate artifact with the preceding published version and permits human approval or rejection before publication.","It supplies private staging and pre-propagation review but does not test downstream compatibility or impose a forfeitable propagation-credit stake."]}],"problem_evidence":{"status":"SUPPORTED","finding":"The problem is directly visible. npm's official guidance makes maintainer-assigned semantic versions consequential for which dependency updates consumers admit, while peer-reviewed npm evidence finds breaking changes in supposedly compatible non-major updates and resulting downstream build impact. CRAN's reverse-dependency policy independently shows that repositories treat downstream breakage from package updates as an operational problem requiring pre-release checking and coordination.","source_ids":["SRC1","SRC2","SRC3"]},"closest_prior_art":[{"name":"Semantic-version-controlled dependency updates","source_ids":["SRC1","SRC2"],"overlap":"Maintainers communicate compatibility through release classification, and consumer dependency ranges use that classification to admit updates automatically.","remaining_difference":"The classification is not backed by a forfeitable propagation privilege, concealed downstream evidence, or a fast-versus-staged self-selection menu."},{"name":"CRAN reverse-dependency checking and submission control","source_ids":["SRC3"],"overlap":"Package updates are checked against dependent packages before repository admission, and disruptive changes require coordination.","remaining_difference":"The review is a broadly applicable repository process rather than an optional bonded fast lane; it does not reserve future propagation credits, conceal a randomized canary sample, or reward prompt withdrawal by returning a bond."},{"name":"Drydock staged pre-publish review","source_ids":["SRC4"],"overlap":"A release candidate can remain private while evidence is reviewed, with publication proceeding only after approval.","remaining_difference":"The reviewed evidence concerns artifact-risk deltas rather than candidate-versus-predecessor downstream builds, and the product has no compatibility claim, randomized canaries, alternate propagation lanes, or temporary credit forfeiture."}],"prior_art_disposition":"ADJACENT_PRIOR_ART","contrastive_claim_remaining":"In an opt-in registry pilot, tying faster propagation to a finite maintainer-controlled credit bond and testing the compatibility claim on concealed randomized candidate-versus-predecessor downstream canaries will make confidence-based lane selection outperform always choosing the fast lane, while a no-stake staged lane preserves legitimate uncertain or breaking releases. The retained prior art contains the principal components separately but not this incentive-and-verification combination.","contrastive_claim_falsifier":"The claim would be falsified by finding an existing registry mechanism that already combines a forfeitable propagation privilege, self-selected fast and staged lanes, and concealed downstream compatibility canaries, or if retrospective replay under plausible credit values shows that always-fast selection yields at least as much propagation access as confidence-based selection without a higher expected consequence.","gates":{"adequate_source_search":{"status":"PASS","rationale":"The bounded search covered exact mechanism phrases, semantic-version and reverse-dependency terminology, official registry practices, staged-publishing products, downstream testing, and combinations involving canaries, stakes, and rollout. Exactly four opened sources span four publishers and include official, primary-research, and first-party material.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"supported_problem":{"status":"PASS","rationale":"Official npm documentation establishes the role of compatibility classifications in dependency acceptance, and primary research quantifies downstream breakage from supposedly compatible non-major releases. CRAN policy confirms that downstream regression risk motivates repository controls.","source_ids":["SRC1","SRC2","SRC3"]},"distinct_testable_claim":{"status":"PASS","rationale":"The retained art establishes compatibility metadata, downstream checks, controlled submission, and private staged review, but not their combination with a nonmonetary bond and concealed randomized canaries. The proposal predicts a measurable ordering among always-fast, always-staged, and confidence-based strategies.","source_ids":["SRC1","SRC2","SRC3","SRC4"]},"bounded_next_test":{"status":"PASS","rationale":"The proposed 30-release retrospective replay is finite and non-live. Candidate-versus-predecessor outcomes, blinded attribution, no consequence for ambiguous cases, and simulated strategy payoffs can test both attribution feasibility and whether the bond changes the preferred strategy before any registry rule is altered.","source_ids":["SRC2","SRC3"]},"no_obvious_safety_or_authority_stop":{"status":"PASS","rationale":"The authorized first step uses existing records from consenting internal packages, simulates rather than applies consequences, preserves human review and appeal, and excludes live propagation changes, monetary penalties, public ranking, unauthorized code execution, and automatic yanking. Privacy leakage, unauthorized inspection, or infrastructure-dominated attribution are explicit halt conditions.","source_ids":[]}},"screen_survival":true,"world_novelty_boundary":"This four-source public-web screen supports only coarse researchability and an adjacent-prior-art classification. It cannot establish world novelty, patentability, market size, expert acceptance, incentive compatibility in deployment, reliable attribution at registry scale, or realized value."}