{"schema_version":1,"research_id":"eoa_inverse_innovation_exp04_external_evaluation_20260802","source_assessment_id":"deadweight_loss_reduction__systems_cybernetics:RETRIEVAL_FIRST:v0","cell_id":"deadweight_loss_reduction__systems_cybernetics","search_queries":["site:modelcontextprotocol.io/seps/2596 specification feature lifecycle deprecation policy normative requirements","site:kubernetes.io/docs/reference/using-api/deprecation-policy API deprecation policy warnings metrics","site:chromium.org/blink/launching-features deprecation use counter compatibility trial rollback","site:opentelemetry.io/blog/2026 deprecating OpenTracing compatibility requirements","site:chromium.org/blink/launching-features \"Feature Deprecations\" use counters","site:rfc-editor.org RFC 9395 deprecation IKEv1 obsolete algorithms implementation complexity security","\"A First Look at the Deprecation of RESTful APIs\" empirical study deprecation","site:iso.org systematic review standards every five years confirmation revision withdrawal","RFC 6410 annual review requirement not performed remove annual review unused features implementation experience","normative requirements sunset expiration review standards interface requirement adoption time"],"sources":[{"source_id":"S1","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","publication_date":"2026-04","accessed_at":"2026-08-02","claims_supported":["MCP maintainers and large implementers expressly identified indefinite legacy support, ambiguous deprecation states, and lack of a defined cycle as problems.","The policy covers protocol features and normative behavioral requirements, permits deprecation for supersession, unmitigable risk, or negligible adoption relative to maintenance cost, and requires migration documentation and at least a twelve-month window.","It provides SDK warnings, a registry, restoration, and identified Core-Maintainer approval authority.","Its lifecycle begins with discretionary selection for deprecation; active features have no planned removal, and it does not assign an adoption-time review date to every requirement."]},{"source_id":"S2","title":"Kubernetes Deprecation Policy","publisher":"Kubernetes","url":"https://kubernetes.io/docs/reference/using-api/deprecation-policy/","source_class":"OFFICIAL_GUIDANCE","publication_date":"not stated; living documentation","accessed_at":"2026-08-02","claims_supported":["Kubernetes governs removal of fine-grained API elements, including resources, fields, annotations, constants, configuration structures, flags, behaviors, feature gates, and metrics.","It uses maturity-dependent minimum lifetimes, warnings, audit annotations, usage metrics, round-trip compatibility, rollback protection, and migration escape hatches.","Its clocks are tied primarily to API stability and versioning, not recurring evidence-based renewal of every normative requirement."]},{"source_id":"S3","title":"Launching Features: Feature Deprecations","publisher":"Chromium Project","url":"https://www.chromium.org/blink/launching-features/","source_class":"OFFICIAL_GUIDANCE","publication_date":"not stated; living documentation","accessed_at":"2026-08-02","claims_supported":["Chromium requires security, code-health, interoperability, usage, breakage, and replacement evidence to be weighed before removing a feature.","It uses UseCounters, affected-site analysis, cross-engine coordination, staged disabling, deprecation trials, post-removal monitoring, and restoration when removal performs badly.","Chromium warns that telemetry undercounts long-tail dependencies and that removals can harm livelihoods or prevent vital tasks.","The process applies after a selected feature is proposed for deprecation rather than imposing adoption-time expiry on every interface requirement."]},{"source_id":"S4","title":"Deprecating OpenTracing Compatibility Requirements","publisher":"OpenTelemetry","url":"https://opentelemetry.io/blog/2026/deprecating-opentracing-compatibility/","source_class":"OFFICIAL_GUIDANCE","publication_date":"2026-04-23","accessed_at":"2026-08-02","claims_supported":["OpenTelemetry actually deprecated specification-level compatibility requirements after the predecessor project was archived and ecosystem use converged on native OpenTelemetry interfaces.","New implementations no longer need the legacy requirements, while existing shims may remain during migration.","Removal cannot occur before March 2027, demonstrating staged rather than immediate retirement."]},{"source_id":"S5","title":"RFC 9395: Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms","publisher":"RFC Editor / Internet Engineering Task Force","url":"https://www.rfc-editor.org/info/rfc9395/","source_class":"STANDARD","publication_date":"2023-04","accessed_at":"2026-08-02","claims_supported":["IETF deprecated a legacy protocol and individual obsolete algorithms after considering replacement coverage and residual use cases.","The standard states that unused legacy algorithms create unknown security risk and that dropping support simplifies implementations and reduces misconfiguration and downgrade risk.","The migration discussion preserves special-use requirements by identifying IKEv2 equivalents or work still needed."]},{"source_id":"S6","title":"A First Look at the Deprecation of RESTful APIs: An Empirical Study","publisher":"arXiv / Yasmin, Tian, and Yang","url":"https://arxiv.org/abs/2008.12808","source_class":"PRIMARY_RESEARCH","publication_date":"2020-08-28","accessed_at":"2026-08-02","claims_supported":["The study analyzed 2,224 OpenAPI specifications representing 1,368 RESTful APIs and reported severe gaps in deprecated-then-removed practice.","Only 16% of the sampled APIs contained deprecation-related versions, and the authors identified unresolved lifecycle and migration-communication problems.","This supports the need for better deprecation records and signaling, but does not measure the candidate's proposed renewal default."]},{"source_id":"S7","title":"ISO/IEC Directives, Part 1 and Consolidated ISO Supplement — Systematic Review","publisher":"International Organization for Standardization","url":"https://www.iso.org/sites/directives/current/consolidated/index.html","source_class":"STANDARD","publication_date":"current edition accessed 2026-08-02","accessed_at":"2026-08-02","claims_supported":["Every ISO or joint ISO/IEC publication is subject to systematic review for confirmation, revision, amendment, conversion, or withdrawal.","International Standards normally have a five-year review interval, while some provisional document types have limited recommended lives and withdrawal defaults.","The process operates at document level, permits repeated confirmation, and does not establish expiry and combined operational renewal evidence for each normative requirement."]},{"source_id":"S8","title":"RFC 6410: Reducing the Standards Track to Two Maturity Levels","publisher":"RFC Editor / Internet Engineering Task Force","url":"https://www.rfc-editor.org/info/rfc6410/","source_class":"STANDARD","publication_date":"2011-10","accessed_at":"2026-08-02","claims_supported":["IETF recognizes that implementation and deployment experience can justify removing unused features that increase implementation complexity.","IETF eliminated a nominal annual-review requirement because the reviews had not occurred and the absence of review had shown no ill effects.","This is direct counterevidence to assuming that a universal recurring review mandate will be performed or produce net benefit."]}],"problem_evidence":{"support":"STRONG","rationale":"The problem class is visible in first-party and standards evidence: MCP maintainers expressly call indefinite legacy support corrosive technical debt and report an unmet need for a defined lifecycle; OpenTelemetry and RFC 9395 show actual retirement of obsolete compatibility requirements and security-sensitive algorithms; the API study finds lifecycle and communication deficiencies. The evidence establishes that obsolete interface obligations and unsafe legacy surface can matter, but it does not establish the prevalence or burden of inertially retained requirements within any specific candidate adopter's specification.","source_ids":["S1","S4","S5","S6","S8"]},"stakeholder_evidence":{"support":"MODERATE","rationale":"MCP Core Maintainers are an identifiable authorizer, explicitly agreed that a formal status and deprecation cycle was needed, and possess approval and removal authority. Kubernetes, Chromium, OpenTelemetry, ISO, and IETF demonstrate credible governance bodies with relevant powers. However, no source expresses demand for the candidate's incremental rule: adoption-time expiry review for every individual normative requirement. RFC 6410 supplies contrary institutional experience with mandatory recurring review.","source_ids":["S1","S2","S3","S4","S7","S8"]},"prior_art":{"proximity":"SUBSTANTIAL_COLLISION","closest_analogues":[{"name":"MCP SEP-2596 specification-feature lifecycle","similarity":"Very close: requirement-level scope, maintenance-versus-adoption evidence, security and interoperability criteria, migration paths, minimum windows, registries, SDK warnings, restoration, and explicit decision authority.","remaining_difference":"Deprecation starts after a discretionary proposal; active requirements do not receive adoption-time expiry-review dates or recurring combined renewal tests.","source_ids":["S1"]},{"name":"Chromium feature-deprecation process","similarity":"Close operational analogue using usage telemetry, breakage analysis, cross-implementer coordination, alternatives, staged trials, monitoring, and rollback.","remaining_difference":"It governs selected implementation features and explicitly treats telemetry as incomplete; it is not a universal requirement-level renewal regime.","source_ids":["S3"]},{"name":"Kubernetes API deprecation policy","similarity":"Close fine-grained lifecycle policy with stability-tiered clocks, warnings, usage metrics, migration windows, compatibility guarantees, and escape hatches.","remaining_difference":"The clocks follow maturity and version state rather than recurring multi-factor evidence-based renewal of every requirement.","source_ids":["S2"]},{"name":"ISO systematic review","similarity":"Applies scheduled confirmation, revision, or withdrawal review across all covered publications and can reinstate withdrawn standards.","remaining_difference":"Review is document-level, standards can be confirmed indefinitely, and the prescribed evidence is not the candidate's requirement-level dependency, migration, security, burden, and asymmetric-tolerance test.","source_ids":["S7"]},{"name":"OpenTelemetry OpenTracing compatibility deprecation","similarity":"A deployed case of retiring normative compatibility requirements after ecosystem convergence while preserving a migration interval and existing shims.","remaining_difference":"A one-off decision rather than an adoption-time expiry and recurring renewal rule.","source_ids":["S4"]}],"distinctive_claim_remaining":"For one authorized specification, assigning every newly adopted individual normative interface requirement an expiry-review date and requiring affirmative recurring renewal based jointly on active producer and consumer dependency, migration cost, security exposure, implementation burden, and asymmetric producer-consumer tolerance will identify additional safely removable requirements and reduce conformance effort by at least 10%, without increasing interoperability failures beyond a preset margin, compared with the same lifecycle using discretionary deprecation initiation.","confidence":"HIGH"},"implementation_evidence":{"support":"MODERATE","rationale":"The constituent workflow is technically credible because official processes already maintain feature registries, collect usage telemetry, issue warnings, run staged trials, preserve migration windows, approve exceptions, and restore features. A retrospective shadow review requires no production change. Feasibility is weakened by missing or biased dependency telemetry, unobserved private and legacy consumers, requirement-to-code traceability, strategic reporting, review workload, and RFC 6410's evidence that nominal universal reviews may not happen. Legal authority is governance-specific: only the body already empowered to amend the specification can implement the policy, and no production retirement is authorized by this evaluation.","source_ids":["S1","S2","S3","S4","S7","S8"]},"scores":{"meaningful_impact":{"score":3,"rationale":"Obsolete obligations can add complexity and security exposure, but candidate-specific prevalence, burden, and realized harm are unmeasured.","source_ids":["S1","S4","S5"]},"stakeholder_pull":{"score":3,"rationale":"MCP maintainers express a concrete lifecycle need and have clear authority, but there is no expressed demand for blanket adoption-time expiry.","source_ids":["S1","S8"]},"incremental_advantage":{"score":2,"rationale":"The candidate could surface requirements that discretionary processes miss, but no evidence shows that the extra findings or savings exceed universal review overhead.","source_ids":["S1","S3","S8"]},"distinctiveness_plausibility":{"score":3,"rationale":"No exact match was located for the combined per-requirement adoption-time renewal default, although nearly every operational component and document-level recurring review already exists.","source_ids":["S1","S2","S3","S7"]},"technical_implementability":{"score":4,"rationale":"Registries, telemetry, staged deprecation, warnings, migration, monitoring, and rollback are established; the main limitations are data coverage and traceability rather than basic engineering possibility.","source_ids":["S1","S2","S3"]},"adoption_authority_feasibility":{"score":3,"rationale":"Standards and platform governance bodies have identifiable decision authority, but adopting a universal renewal obligation requires sponsor commitment and normal consensus procedures not yet demonstrated.","source_ids":["S1","S7","S8"]},"evidence_readiness":{"score":2,"rationale":"Public sources support the problem class and analogues, but the core outcome requires historical requirement records, dependency data, reviewer labor, and live or retrospective comparison.","source_ids":["S3","S6","S8"]},"safety_net_benefit":{"score":3,"rationale":"Migration paths, exceptions, monitoring, and restoration are credible safeguards, but hidden dependencies and long-tail users remain capable of defeating them.","source_ids":["S1","S2","S3","S4"]},"scalability":{"score":2,"rationale":"A requirement-level registry can be replicated, but universal recurring review risks ritual renewal, high workload, and nonperformance as specifications and requirement counts grow.","source_ids":["S7","S8"]}},"score_confidence":"MODERATE","costs":{"first_evidence":{"band_2026_usd":"10K_TO_50K","scope":"Pre-register and conduct the proposed retrospective shadow review of 20 requirements, including two independent reviewers, adjudication, historical-record extraction, analysis, and a short governance report.","confidence":"MODERATE","assumptions":["One mature specification and no production changes.","Approximately 120-300 hours of standards, engineering, security, and analysis labor valued at 2026 resource-equivalent loaded rates.","Existing records are accessible without new telemetry collection or licensing expense."],"source_ids":["S1","S3","S8"]},"initial_deployment_startup":{"band_2026_usd":"50K_TO_250K","scope":"For one specification, draft and approve governance changes; inventory and trace normative requirements; create the evidence schema, review calendar, exception rules, registry, and prototype reporting workflow.","confidence":"LOW","assumptions":["One medium-sized specification with roughly 50-300 individually traceable requirements.","Existing issue tracking and documentation systems can be extended.","Excludes production deprecation, migration engineering, and new user-level telemetry."],"source_ids":["S1","S2","S7"]},"operational_launch":{"band_2026_usd":"250K_TO_1M","scope":"Run the first authorized review cycle and a bounded staged-deprecation cohort, including dependency validation, SDK and conformance updates, migration guidance, stakeholder consultation, compatibility monitoring, exceptions, and rollback readiness.","confidence":"LOW","assumptions":["A limited cohort rather than specification-wide simultaneous retirement.","Multiple implementations and maintainer groups participate.","No safety-critical or regulated interface is changed without its additional required assurance process."],"source_ids":["S1","S2","S3","S4"]},"annual_recurring":{"band_2026_usd":"50K_TO_250K","scope":"Maintain the registry and evidence records, schedule and conduct renewal reviews, update migration material, administer exceptions, and report compatibility and security outcomes for one medium-sized specification.","confidence":"LOW","assumptions":["Reviews are risk-tiered and batched rather than annually reassessing every requirement in full.","Most requirements renew through documented evidence without migration engineering.","Major removals or new telemetry systems are separately funded."],"source_ids":["S1","S3","S7","S8"]}},"verified_pipeline_gates":{"externally_supported_problem":{"status":"YES","reason":"Multiple official and primary sources show legacy interface obligations, obsolete algorithms, lifecycle ambiguity, security exposure, and poor deprecation communication.","source_ids":["S1","S4","S5","S6"]},"externally_credible_adopter_or_authorizer":{"status":"YES","reason":"MCP Core Maintainers are explicitly identified as lifecycle and removal authorizers and have expressed need for a formal deprecation cycle, though not yet for the candidate's full incremental rule.","source_ids":["S1"]},"distinct_testable_incremental_claim":{"status":"YES","reason":"The residual claim specifies the differing default, evidence fields, comparator, 10% conformance-effort threshold, and interoperability margin.","source_ids":["S1","S2","S3","S7"]},"bounded_next_evidence_step":{"status":"YES","reason":"A 20-requirement retrospective shadow review can be pre-registered, time-bounded, performed without changing specifications, and evaluated against explicit comparators and falsifiers.","source_ids":["S1","S3","S8"]},"no_unresolved_safety_or_authority_stop":{"status":"YES","reason":"The immediate step is nonbinding and uses existing authorized records; any later retirement remains subject to the governing body's normal approval, migration, monitoring, exception, and rollback controls.","source_ids":["S1","S2","S3"]},"credible_cost_scope_and_range":{"status":"UNCERTAIN","reason":"Scopes and labor assumptions are bounded, but no first-party source reports costs for universal requirement-level review, traceability, or migration; actual requirement count and telemetry access could move costs by more than one band.","source_ids":["S1","S3","S7","S8"]}},"next_evidence_step":"With written permission from one specification's authorized governance body, pre-register a retrospective shadow review of 20 individual normative requirements: 10 historically deprecated or retired and 10 retained, sampled before scoring and stratified by requirement criticality. Two independent reviewers should apply the proposed combined renewal test using only contemporaneous authorized records, while a comparator team reconstructs the ordinary discretionary lifecycle decision without the adoption-time-expiry presumption. Measure reviewer hours, inter-rater agreement, missing-data rates, additional requirements flagged, estimated removable conformance effort, known dependencies missed, migration feasibility, and whether historical compatibility or security outcomes would have triggered halt or rollback. Advance to an authorized prospective pilot only if agreement is at least 0.60, at least one additional plausibly removable requirement is found, the findings provide a credible path to at least 10% lower conformance effort, estimated review cost is below estimated removable burden, and no known interoperability harm exceeds the body's preset margin. Falsify or materially revise the intervention if it finds no additional requirement, review cost exceeds recoverable burden, agreement is below 0.60, missing dependency evidence makes classification unsafe, or a known affected population or historical incident breaches the margin.","blocking_evidence":["No requirement-level prevalence estimate shows how often automatic continuation, rather than active dependency, explains retention.","No standards body has committed to sponsor or authorize the adoption-time every-requirement rule.","No comparative evidence shows that universal recurring review finds more safely removable requirements than ordinary discretionary deprecation.","The proposed 10% conformance-effort reduction and interoperability margin have not been measured.","Dependency telemetry may omit private, offline, low-volume, enterprise, or vulnerable consumers.","No observed reviewer-hours or migration-cost distribution supports the cost bands.","The bounded web search cannot establish world novelty, patentability, freedom to operate, market size, or realized impact."],"research_disposition":"PARTNERED_RESEARCH_PROGRAM","world_novelty_boundary":"Broad feature and normative-requirement lifecycle governance—including telemetry, security and interoperability assessment, migration paths, warnings, scheduled removal windows, exceptions, monitoring, and restoration—is established practice. ISO also establishes recurring document-level review. This bounded ordinary-web search found no exact deployed policy assigning an adoption-time expiry-review date to every individual normative interface requirement and making continuation contingent on the stated combined evidence test. That absence is not proof of world novelty; patents, private governance processes, non-English materials, market size, freedom to operate, and realized impact were not assessed.","arm":"RETRIEVAL_FIRST","candidate_version":0,"controller_recommendation":{"action":"STOP_EMPIRICAL_RESEARCH_NEEDED","repairable":true,"material_progress_observed":true,"progress_targets":["Obtain written sponsorship and data-access authorization from one specification's governing body.","Pre-register the 20-requirement sample, ordinary-lifecycle comparator, scoring rubric, criticality strata, interoperability margin, and analysis plan.","Demonstrate inter-rater agreement of at least 0.60 and quantify missing or unobservable dependency evidence.","Identify at least one additional safely removable requirement and a credible route to at least 10% lower conformance effort versus the comparator.","Show that reviewer and migration effort is lower than the avoidable burden identified.","Validate long-tail dependencies with maintainers and affected implementers rather than treating absent telemetry as absent use.","Document halt, exception, and restoration triggers before any prospective specification change.","Perform a focused follow-on search of emerging standards policies and relevant patents before asserting the narrow distinctiveness boundary."],"reason":"The remaining question is no longer answerable by bounded public-web research alone. The candidate's incremental advantage, cost, safety, and outcome thresholds require governance participation, historical or proprietary requirement records, expert review, and eventually an authorized comparative pilot. Broad prior art substantially collides with the treatment, while RFC 6410 makes universal-review overhead and nonperformance a serious empirical risk."}}