{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp04_retrieval_first_paired20_20260802","cell_id":"deadweight_loss_reduction__systems_cybernetics","round_index":0,"assessments":[{"hypothesis_id":"H1","search_queries":["dynamic pricing internal credits HPC cluster scheduling load pricing research","HPC cluster spot pricing workload scheduling primary research","market based resource allocation HPC cluster credits auction scheduling research paper","computational grid economy credits pricing job scheduling primary research"],"sources":[{"source_id":"H1-S1","title":"Using a Market Economy to Provision Compute Resources Across Planet-wide Clusters","publisher":"Google Research","url":"https://research.google/pubs/using-a-market-economy-to-provision-compute-resources-across-planet-wide-clusters/","source_class":"PRIMARY_RESEARCH","claims_supported":["Google implemented an experimental compute-resource market using periodically recalculated prices and utilization-dependent reserve prices.","The experiment shifted users from congested resource pools toward underutilized pools and reduced shortages and surpluses."]},{"source_id":"H1-S2","title":"Tycoon: A Distributed Market-based Resource Allocation System","publisher":"arXiv / Tycoon researchers","url":"https://arxiv.org/abs/cs/0404013","source_class":"PRIMARY_RESEARCH","claims_supported":["Tycoon implemented auction-share scheduling for cluster resources.","Its prototype used market allocation to pursue low-latency, fair allocation while addressing strategic user behavior."]},{"source_id":"H1-S3","title":"Multifactor Priority Plugin","publisher":"SchedMD","url":"https://slurm.schedmd.com/priority_multifactor.html","source_class":"OFFICIAL_PRODUCT_DOCUMENTATION","claims_supported":["Slurm supports accounting-based fair-share, reservations, QOS, site-defined priority factors, and time-varying job priority.","Under-served accounts can be prioritized while over-served accounts run when capacity would otherwise be idle."]}],"closest_analogue":"Google's experimental utilization-priced compute-resource market, supplemented by Tycoon's credit-based auction scheduling and Slurm reservations/fair-share safeguards.","overlap":"The analogues already combine scarce shared compute, internal bids or credits, prices that respond to utilization, movement from congested to underused pools, urgency/value-sensitive allocation, fairness accounting, and protected reservations.","remaining_difference":"The hypothesis packages these elements as refundable job-level charges with explicit reservations for urgent and resource-poor users and tests a particular queue-time/equity threshold; that packaging and endpoint do not change the already-demonstrated causal mechanism.","classification":"OBVIOUS_COLLISION","disposition":"REJECT","rationale":"Primary research directly demonstrates utilization-responsive internal compute markets and job-level credit auctions, while standard cluster tooling supplies the proposed protection mechanisms. The remaining differences are implementation parameters and evaluation metrics."},{"hypothesis_id":"H2","search_queries":["official risk based change management low risk standard changes automated approval safety controller changes","IEC 61508 modification impact analysis functional safety controller change official","NIST cyber physical systems controller change management risk tier sandbox deployment","Google SRE canary deployment risk mitigation change official"],"sources":[{"source_id":"H2-S1","title":"GO-ITS 35 Ontario Public Service Enterprise Change Management Standard","publisher":"Government of Ontario","url":"https://www.ontario.ca/page/go-its-35-ontario-public-service-enterprise-change-management-standard","source_class":"GOVERNMENT_OR_REGULATOR","claims_supported":["The standard distinguishes standard, low-risk, repeatable changes from other change classes.","It permits change processing to vary with assessed risk and supports automated recording for orchestrated changes."]},{"source_id":"H2-S2","title":"Canarying Releases","publisher":"Google Site Reliability Engineering","url":"https://sre.google/workbook/canarying-releases/","source_class":"OFFICIAL_GUIDANCE","claims_supported":["Canarying is a partial, time-limited deployment evaluated against a control before wider rollout.","Monitoring and rollback contain the impact of defective changes while allowing faster releases."]},{"source_id":"H2-S3","title":"Firmware Upgrade Guidelines for Safety Controllers","publisher":"Rockwell Automation","url":"https://www.rockwellautomation.com/en-fi/docs/technical/logix5000/_online/1756-um900/controllogix-5590-controller-user-manual-ditamap/connect-to-the-controller/firmware-upgrade-guidelines-for-safety-controllers.html","source_class":"OFFICIAL_PRODUCT_DOCUMENTATION","claims_supported":["Safety-controller modifications require functional-safety impact analysis under IEC 61508.","Validated safety software modifications must be planned and analyzed for their safety-system effects."]},{"source_id":"H2-S4","title":"NIST SP 800-82 Rev. 3: Guide to Operational Technology Security","publisher":"National Institute of Standards and Technology","url":"https://csrc.nist.gov/pubs/sp/800/82/r3/final","source_class":"GOVERNMENT_OR_REGULATOR","claims_supported":["Operational technology controls physical processes and has distinctive performance, reliability, and safety requirements.","NIST provides risk-tailored control baselines for low-, moderate-, and high-impact OT systems."]}],"closest_analogue":"Risk-classified change management combined with monitored canary deployment, bounded by IEC 61508-style impact analysis for safety-controller modifications.","overlap":"Existing practice covers low-risk change classes, lighter or automated treatment for repeatable changes, partial monitored deployment, safety-impact analysis, risk-tailored controls, and rollback.","remaining_difference":"The testable difference is a single operational-controller workflow that sends reversible low-hazard parameter changes through parallel approval and a sandbox while retaining full safety-impact analysis. An independent critic can determine whether a safety-critical industrial operator has deployed and evaluated that exact end-to-end pathway rather than merely using its components separately.","classification":"POSSIBLE_DISTINCTION","disposition":"ADVANCE","rationale":"The components are established, but this shallow screen did not establish a direct analogue that integrates risk-tiered approval, parallel review, monitored sandbox deployment, and unchanged functional-safety obligations for live controller changes. The distinction is narrow and independently researchable."},{"hypothesis_id":"H3","search_queries":["transferable telemetry quota observability storage allocation service quotas","observability telemetry budget allocation per service dynamic quotas official","telemetry budget allocation optimization observability services research paper","adaptive telemetry sampling allocation incident detection budget primary research"],"sources":[{"source_id":"H3-S1","title":"Dynamic SLA-aware Network Slice Monitoring","publisher":"arXiv / University of Waterloo researchers","url":"https://arxiv.org/abs/2512.12123","source_class":"PRIMARY_RESEARCH","claims_supported":["SliceScope dynamically allocates a limited telemetry budget across slices according to SLA criticality.","Its closed-loop controller changes per-slice monitoring thresholds and reports substantially better tracking of critical slices than static allocation."]},{"source_id":"H3-S2","title":"Monitoring Services in the Internet of Things: An Optimization Approach","publisher":"IBM Research","url":"https://research.ibm.com/publications/monitoring-services-in-the-internet-of-things-an-optimization-approach","source_class":"PRIMARY_RESEARCH","claims_supported":["The framework optimizes which metrics to collect, their frequency, and their allocation to devices under time-varying capacity constraints.","It recomputes allocations when system triggers make earlier monitoring decisions obsolete."]},{"source_id":"H3-S3","title":"Metrics","publisher":"OpenTelemetry","url":"https://opentelemetry.io/docs/concepts/signals/metrics/","source_class":"OFFICIAL_GUIDANCE","claims_supported":["OpenTelemetry provides configurable per-stream cardinality limits to bound telemetry resource cost.","Overflow preserves aggregate totals but can remove attributes needed by filtered alerts, demonstrating the safety cost of coarse quota enforcement."]},{"source_id":"H3-S4","title":"Cloud Monitoring Quotas and Limits","publisher":"Google Cloud","url":"https://docs.cloud.google.com/monitoring/quotas","source_class":"OFFICIAL_PRODUCT_DOCUMENTATION","claims_supported":["Cloud Monitoring imposes telemetry quotas and fixed limits and exposes ingestion, cardinality, alert-use, and dashboard-use data for management decisions.","Quotas can be adjusted or automated, and unneeded metrics can be excluded to control cost."]}],"closest_analogue":"SliceScope's closed-loop, criticality-weighted reallocation of a fixed telemetry budget across network slices.","overlap":"Both retain an aggregate telemetry-capacity constraint, replace static per-unit allocation with dynamic risk or criticality weighting, shift observability toward high-value services, and seek better incident or SLA detection without adding total capacity.","remaining_difference":"The hypothesis uses organizationally transferable quotas, risk-weighted bids, explicit observability floors, and incident-time recall rather than a centralized optimizer selecting per-slice telemetry thresholds. Those governance details are separable implementation choices around an already demonstrated dynamic-allocation mechanism.","classification":"OBVIOUS_COLLISION","disposition":"REJECT","rationale":"Recent primary research directly addresses dynamic reallocation of a constrained telemetry budget according to service criticality, including bounded overhead and protection of high-criticality monitoring. The proposed bidding and recall rules do not preserve a sufficiently different core mechanism for this shallow screen."},{"hypothesis_id":"H4","search_queries":["standards body normative requirement sunset expiry review interoperability deprecation policy","IETF deprecate obsolete protocol requirements standards process official RFC","W3C obsolete rescinded specification feature deprecation policy official","ISO standard systematic review withdrawal official"],"sources":[{"source_id":"H4-S1","title":"ISO/IEC Directives, Part 1 and Consolidated ISO Supplement","publisher":"International Organization for Standardization","url":"https://www.iso.org/sites/directives/current/consolidated/index.html","source_class":"STANDARD","claims_supported":["Every ISO or joint ISO/IEC publication is subject to systematic review for confirmation, revision, amendment, conversion, or withdrawal.","International Standards normally face review within five years, while some provisional document types have recommended maximum lives and withdrawal defaults."]},{"source_id":"H4-S2","title":"Obsoleting and Rescinding W3C Specifications","publisher":"World Wide Web Consortium","url":"https://www.w3.org/guide/process/obsolete-rescinded-supserseded.html","source_class":"OFFICIAL_GUIDANCE","claims_supported":["W3C can mark specifications superseded, obsolete, or rescinded according to continued relevance, adoption, errors, and patent concerns.","Some status decisions are reversible, preserving a reinstatement path."]},{"source_id":"H4-S3","title":"ISO/IEC 18025:2013 Annex F — Change and Deprecation Plan","publisher":"ISO/IEC via SEDRIS Standards","url":"https://standards.sedris.org/18025/text/annex_f.html","source_class":"STANDARD","claims_supported":["The normative annex defines change, item-level deprecation, staged retention of deprecated items, deletion after at least five years, and reinstatement.","Its stated purpose is orderly evolution while protecting user investment."]},{"source_id":"H4-S4","title":"RFC 6410: Reducing the Standards Track to Two Maturity Levels","publisher":"RFC Editor / IETF","url":"https://www.rfc-editor.org/info/rfc6410/","source_class":"STANDARD","claims_supported":["IETF standards progression expects revisions and removal of unused features based on implementation and deployment experience.","The IETF removed a nominal annual-review requirement after finding that it was not performed in practice, illustrating the enforceability problem for scheduled reviews."]}],"closest_analogue":"ISO/IEC 18025's item-level staged deprecation and reinstatement process, within broader ISO systematic review and W3C obsolescence procedures.","overlap":"The analogues already provide scheduled review, withdrawal or obsolescence, item-level deprecation, migration protection, staged retention, reversibility, and evidence from adoption or deployment experience.","remaining_difference":"The bounded difference is automatic expiry attached to each normative interface requirement, with renewal conditioned on measured dependency, migration cost, security exposure, and asymmetric producer-consumer tolerance. An independent critic can test whether any standards body applies that evidence-triggered default to individual normative requirements rather than reviewing whole documents or accepting discretionary deprecation proposals.","classification":"POSSIBLE_DISTINCTION","disposition":"ADVANCE","rationale":"Item-level deprecation is a close collision, but the reviewed processes do not establish automatic per-requirement expiry tied to operational dependency and interface-tolerance measurements. RFC 6410 also shows that merely nominal review cycles may not implement the proposed default reversal."},{"hypothesis_id":"H5","search_queries":["shared experimental testbed clearinghouse constraint-aware matching research facilities experiments","federated testbed portal experiment resource discovery capability descriptors official","NSF testbed facility matching experiment requirements shared testbeds official","SLICES research infrastructure testbed resource discovery experiment portal"],"sources":[{"source_id":"H5-S1","title":"User Requirements and Reference Model for Testbed as a Service","publisher":"International Telecommunication Union","url":"https://www.itu.int/dms_pub/itu-t/opb/fg/T-FG-TBFXG-2024-05-PDF-E.pdf","source_class":"STANDARD","claims_supported":["The reference model calls for common testbed resource and capability descriptions, catalogues, reservation-state updates, open provisioning interfaces, and selection of resources across testbeds.","It covers authorization, experiment lifecycle management, monitoring, and provider-controlled policies."]},{"source_id":"H5-S2","title":"Evolution of the Testbeds Federations Reference Model","publisher":"International Telecommunication Union","url":"https://www.itu.int/dms_pub/itu-t/opb/fg/T-FG-TBFXG-2024-03-PDF-E.pdf","source_class":"STANDARD","claims_supported":["The model specifies an inter-testbed end-to-end universal resource broker using synchronized, uniform capability descriptions.","Users can query for testbeds satisfying requirements, select resources, undergo admission control, and book test sessions across multiple domains."]},{"source_id":"H5-S3","title":"SLICES-SC Testbed Portal","publisher":"SLICES-SC","url":"https://portal.slices-sc.eu/","source_class":"OFFICIAL_ORGANIZATION_DATA","claims_supported":["SLICES provides a shared portal for accounts and access to experimental testbed resources contributed by partners across multiple countries.","The federation targets heterogeneous networking, wireless, cloud, edge, IoT, security, and related experiments."]},{"source_id":"H5-S4","title":"Next Generation Portal for Federated Testbeds MySlice v2: From Prototype to Production","publisher":"arXiv / MySlice researchers","url":"https://arxiv.org/abs/1806.04467","source_class":"PRIMARY_RESEARCH","claims_supported":["MySlice is a production-oriented portal for accessing federated experimental facilities.","It provides a common access layer over distributed compute, storage, and network testbed resources."]}],"closest_analogue":"The ITU Testbed-as-a-Service federation model's universal resource broker, implemented in the same lineage as MySlice and SLICES federated testbed portals.","overlap":"The analogue includes standardized capability descriptions, discovery across independently operated testbeds, constraint queries, synchronized availability, admission and participation policies, reservation, experiment lifecycle support, and cross-domain execution.","remaining_difference":"Automated experiment-to-testbed ranking for rare disturbance profiles and explicit anti-withholding or ranking-game rules are narrower policy and algorithm choices inside the already specified clearinghouse architecture.","classification":"OBVIOUS_COLLISION","disposition":"REJECT","rationale":"An ITU reference model directly specifies the proposed cross-testbed broker workflow, while MySlice and SLICES provide first-party and research evidence of federated portals. The remaining matching heuristic and incentive rules are implementation refinements rather than a distinct intervention."}],"nominated_ids":["H2","H4"],"replenishment_recommended":false}