{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp04_retrieval_first_paired20_20260802","cell_id":"deadweight_loss_reduction__systems_cybernetics","hypothesis_id":"H4","search_queries":["site:kubernetes.io API deprecation policy usage metrics removal deprecated APIs official","protocol feature deprecation telemetry compatibility usage threshold standard removal","standards normative requirement expiration sunset clause interface compatibility","site:chromium.org feature deprecation removal usage metrics interoperability","site:ietf.org RFC deprecate backward compatibility requirement security legacy protocol migration","\"compatibility requirements\" deprecation specification requirements implementation burden","patent automatic deprecation software interface usage telemetry compatibility feature removal","site:opentelemetry.io/blog \"Deprecating OpenTracing compatibility requirements\""],"sources":[{"source_id":"PA-1","title":"SEP-2596: Specification Feature Lifecycle and Deprecation Policy","publisher":"Model Context Protocol","url":"https://modelcontextprotocol.io/seps/2596-spec-feature-lifecycle-and-deprecation","source_class":"OFFICIAL_GUIDANCE","claims_supported":["The draft policy governs individual protocol features and normative behavioral requirements independently of whole-document revision lifecycles.","It permits deprecation based on supersession, security/privacy/interoperability risk, or ecosystem telemetry indicating negligible adoption relative to maintenance cost.","It requires a migration path, a timed deprecation window, a registry, SDK warnings, discretionary removal, and possible restoration to Active status.","It explicitly identifies indefinite legacy support as corrosive technical debt, directly supporting the nominated problem."]},{"source_id":"PA-2","title":"Kubernetes Deprecation Policy","publisher":"Kubernetes","url":"https://kubernetes.io/docs/reference/using-api/deprecation-policy/","source_class":"OFFICIAL_GUIDANCE","claims_supported":["Kubernetes applies maturity-dependent lifetimes and staged removal rules to API versions, resources, fields, constants, flags, and metrics.","Deprecated API use produces warnings, audit annotations, usage metrics, and a labeled prospective removal release.","The policy preserves round-trip compatibility, rollback, minimum migration windows, and exceptions for cases where removal would seriously impede users."]},{"source_id":"PA-3","title":"Launching Features: Feature Deprecations","publisher":"Chromium Project","url":"https://www.chromium.org/blink/launching-features/","source_class":"OFFICIAL_GUIDANCE","claims_supported":["Chromium balances security, code health, and interoperability benefits against removal costs measured with use counters and affected-site analysis.","Its staged process includes deadlines, migration alternatives, temporary compatibility trials, post-removal monitoring, and rollback.","Deprecation-trial renewal depends partly on reducing observed dependencies; failure to demonstrate migration progress can cause a feature to be undeprecated because compatibility remains necessary."]},{"source_id":"PA-4","title":"Deprecating OpenTracing Compatibility Requirements","publisher":"OpenTelemetry","url":"https://opentelemetry.io/blog/2026/deprecating-opentracing-compatibility/","source_class":"OFFICIAL_GUIDANCE","claims_supported":["OpenTelemetry deprecated normative compatibility requirements after the predecessor ecosystem was archived and adoption converged on native OpenTelemetry interfaces.","New implementations no longer need to implement the legacy requirements, while existing shims remain available during a migration period.","The actual retirement has a stated one-year minimum interval, demonstrating staged removal of obsolete interface requirements rather than merely whole-specification withdrawal."]},{"source_id":"PA-5","title":"RFC 9395: Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms","publisher":"Internet Engineering Task Force","url":"https://www.ietf.org/rfc/rfc9395.pdf","source_class":"STANDARD","claims_supported":["The RFC deprecates a legacy protocol and individual algorithms after assessing replacement coverage, deployment, maintenance status, interoperability, and security exposure.","It states that removing unused deprecated algorithms simplifies implementations and reduces misconfiguration and downgrade-attack risks.","It supplies direct evidence that retained compatibility obligations can preserve unmaintained code and obstruct safer protocol evolution."]},{"source_id":"PA-6","title":"A First Look at the Deprecation of RESTful APIs: An Empirical Study","publisher":"arXiv / Yasmin and Tian","url":"https://arxiv.org/abs/2008.12808","source_class":"PRIMARY_RESEARCH","claims_supported":["The study analyzed 2,224 OpenAPI specifications representing 1,368 RESTful APIs and found widespread failures to warn consumers before breaking changes.","Only 3 of 219 deprecation-related APIs used proactive runtime communication, while replacement guidance was also incomplete.","The findings support the need for measurable dependency discovery and migration signaling, while showing that deprecation governance is often poorly implemented."]}],"proximity":"SUBSTANTIAL_COLLISION","closest_analogues":[{"name":"MCP specification-feature lifecycle and deprecation policy","similarity":"Very close: it operates below the document level on protocol features and normative requirements, uses adoption-versus-maintenance telemetry plus security and interoperability criteria, schedules migration windows, records removal dates, surfaces runtime warnings, and allows reinstatement.","remaining_difference":"It is a 2026 draft and starts its clock only after a discretionary deprecation proposal; it does not give every requirement an expiry at adoption or require a recurring joint renewal test covering dependency, migration cost, security exposure, and asymmetric interface tolerance.","source_ids":["PA-1"]},{"name":"Chromium web-platform feature deprecation process","similarity":"Close operational analogue: it measures affected usage, weighs code-health/security/interoperability benefits, stages disabling through trials, conditions extensions on migration evidence, monitors failures, and can restore a feature.","remaining_difference":"It governs selected implementation features proposed for removal, not every normative requirement in a consensus specification under an adoption-time sunset default.","source_ids":["PA-3"]},{"name":"Kubernetes API deprecation policy","similarity":"Close lifecycle analogue: it covers fine-grained interface elements, applies stability-tiered clocks, exposes real use through warnings and metrics, protects rollback and migration, and announces removal releases.","remaining_difference":"Its lifetimes are primarily maturity- and version-based; observed usage helps operators migrate but is not a mandatory multi-factor renewal test for each normative constraint.","source_ids":["PA-2"]},{"name":"OpenTelemetry retirement of OpenTracing compatibility requirements","similarity":"Direct real-world instance of deprecating normative interface-compatibility requirements after ecosystem convergence, while retaining a staged migration bridge.","remaining_difference":"It is a one-off governance decision supported by qualitative ecosystem evidence, not an automatic per-requirement expiration and renewal system.","source_ids":["PA-4"]}],"overlapping_components":["Individual feature or interface-requirement lifecycle rather than only whole-document review","Scheduled deprecation and earliest-removal dates","Dependency or adoption measurement","Security-exposure and interoperability assessment","Maintenance-cost and implementation-complexity assessment","Documented replacement and migration path","Producer and consumer migration protection","Runtime deprecation warnings and usage telemetry","Staged withdrawal with bounded compatibility escape hatches","Restoration, exception, or rollback path","Post-removal monitoring","Removal of legacy requirements to reduce implementation and attack surface"],"remaining_contrastive_claim":"Unlike the located practices, H4 would attach an expiry presumption to every individual normative interface requirement when adopted and renew it only after a recurring joint evidence test of active dependency, migration cost, security exposure, and asymmetric producer-consumer tolerance.","claim_falsifier":"The contrastive claim would be falsified by an official standard, deployed governance policy, product process, or patent showing adoption-time expiry for each normative interface requirement with continuation contingent on that combined evidence test, rather than merely discretionary deprecation, version-level aging, or whole-document review.","problem_support":"STRONG","recommendation":"RESEARCH","world_novelty_boundary":"The broad treatment—identify obsolete compatibility obligations, measure dependencies and risks, stage deprecation, protect migration, and permit rollback—is already practiced and therefore is not world-novel. This bounded ordinary-web search found no deployed process combining adoption-time automatic expiry with a mandatory multi-factor renewal test for every normative requirement; that narrow default-reversal remains the only defensible novelty boundary, and the very close April 2026 MCP draft means it should be validated against emerging standards activity before advancement."}