{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp04_retrieval_first_paired20_20260802","cell_id":"deadweight_loss_reduction__systems_cybernetics","arm":"RETRIEVAL_FIRST","candidate_id":"C-H4-V0","hypothesis_id":"H4","version":0,"title":"Adoption-Time Expiry and Evidence-Based Renewal for Normative Interface Requirements","problem":"Normative interface requirements can persist after their interoperability purpose has faded because continuation is automatic and review begins only when someone proposes deprecation. The resulting legacy obligations can preserve unnecessary implementation complexity and security exposure while blocking safer protocol evolution. The potentially avoidable wedge is the continued conformance burden of requirements with weak active dependency; requirements still needed for interoperability, migration, or vulnerable adopters remain protected.","actors":["Standards maintainers and the body authorized to revise the specification","Producers implementing or emitting the interface","Consumers depending on accepted interface behavior","SDK, tooling, and conformance-test maintainers","Operators and users exposed to interoperability or security failures","Legacy adopters requiring migration time or compatibility exceptions"],"observable_state":"For each normative interface requirement at a specification revision, the review record shows its adoption date, scheduled expiry-review date, observed producer implementation and consumer dependency, available migration path and estimated migration cost, associated maintenance and conformance effort, security exposure, interoperability incidents, and asymmetric tolerance for stricter or more permissive producer and consumer behavior. At the system level, observable outcomes are conformance effort, retained legacy code or tests, migration completion, compatibility failures, security regressions, exception use, and rollback events.","consequence":"Requirements with little remaining protective value persist as implementation and conformance burdens, retain legacy attack or misconfiguration surfaces, and constrain protocol evolution; indiscriminate retirement would instead fragment interoperability or strand dependent adopters. The affected value is therefore only the burden attributable to requirements that fail renewal while their legitimate protections can be preserved through migration, exception, or retention.","affected_objective":"Reduce avoidable conformance effort and legacy security exposure while keeping interoperability failures within a preset margin and protecting dependent or migration-constrained adopters.","intervention":"At adoption, assign every individual normative interface requirement an expiry-review date rather than an automatic removal date. At each review, the authorized standards body renews the requirement only after jointly examining active producer and consumer dependency, migration feasibility and cost, security exposure, implementation burden, and asymmetric producer-consumer tolerance. A requirement that does not justify renewal enters a documented, staged deprecation path with warnings, migration guidance, bounded compatibility exceptions, post-retirement monitoring, and restoration or rollback. The broad deprecation machinery is established prior art; the intervention's narrow test is whether applying this adoption-time expiry presumption and recurring combined renewal test to every normative requirement improves outcomes.","structural_mapping":[{"archetype_element":"Value-blocking wedge","domain_realization":"Default persistence of an individual normative requirement imposes continuing implementation, test, and legacy-support obligations even when active interoperability dependency may have faded."},{"archetype_element":"Beneficial activity blocked","domain_realization":"Maintainers and implementers cannot simplify conformance or evolve toward safer protocol behavior without initiating an exceptional deprecation campaign."},{"archetype_element":"Protected constraint","domain_realization":"Interoperability, rollback, migration time, stable expectations, and access for vulnerable or slow-moving adopters must survive any retirement decision."},{"archetype_element":"Distortion-versus-protection separation","domain_realization":"The recurring evidence test distinguishes low-dependency legacy burden from requirements whose producer-consumer dependencies still make them protective."},{"archetype_element":"Redesign lever","domain_realization":"Reverse the continuation default by scheduling an expiry review at adoption and requiring affirmative, requirement-level renewal on combined evidence."},{"archetype_element":"Incidence and behavioral response","domain_realization":"Record gains to new implementers and maintainers alongside migration burdens, compatibility risks, strategic underreporting, exception demand, and possible fragmentation among producers and consumers."},{"archetype_element":"Bounded implementation and rollback","domain_realization":"Use staged deprecation, warnings, migration paths, compatibility exceptions, monitoring, and authorized restoration rather than immediate deletion."},{"archetype_element":"Cybernetic feedback structure","domain_realization":"Requirement status is periodically updated from observed dependency, burden, security, migration, and interoperability signals, while asymmetric interface tolerance identifies which side of the interface can safely change."}],"mechanism_mapping":[{"mechanism_slug":"sunset_clause_review","role":"Creates the adoption-time expiry presumption, recurring re-justification event, and renew-revise-retire decision for each normative requirement.","counterfactual_removal":"Without it, requirements continue by inertia and the proposal collapses into ordinary discretionary deprecation after a maintainer independently initiates removal."},{"mechanism_slug":"cost_benefit_assessment_protocol","role":"Forces each renewal decision to compare reduced conformance and security burden with migration cost, interoperability protection, distributional effects, and sensitivity to uncertain dependency evidence.","counterfactual_removal":"Without it, expiry could become mechanical deletion or cost cutting, with no defensible comparison between recovered value and lost protection."},{"mechanism_slug":"impact_assessment_table","role":"Maintains a requirement-level record of producer, consumer, maintainer, operator, and legacy-adopter effects together with monitoring triggers and uncertain or missing evidence.","counterfactual_removal":"Without it, aggregate burden reduction could conceal concentrated migration harm, asymmetric compatibility failures, or dependencies that telemetry does not observe."}],"causal_chain":["Automatic continuation lets normative requirements survive without demonstrating current protective value.","Surviving requirements accumulate implementation, test, migration, and legacy-security burdens and can constrain safer protocol evolution.","Assigning an expiry-review date at adoption makes continued status a scheduled decision rather than an inert default.","The recurring joint test exposes whether producers still implement the behavior, consumers still depend on it, migration is feasible, security exposure favors retirement, and producer-consumer tolerance permits change.","Requirements with demonstrated protective value are renewed; uncertain or uneven cases are retained, revised, or given bounded exceptions; weakly justified cases enter staged deprecation.","Warnings, migration guidance, compatibility bridges, monitoring, and rollback convert retirement into a controlled transition.","If the diagnosis is correct, removable constraints retire, conformance effort and legacy exposure decline, and interoperability failures remain within the preset margin."],"baseline":"Existing located practice: standards and platforms can deprecate individual features or normative requirements, use telemetry and warnings, provide migration windows and compatibility trials, assess security and interoperability, and restore or except requirements when needed. MCP's draft lifecycle policy is especially close; Kubernetes, Chromium, OpenTelemetry, and IETF supply additional lifecycle and retirement analogues. These practices generally begin after discretionary selection for deprecation, use maturity or version clocks, or make one-off decisions. The comparison baseline for evaluation is the same specification lifecycle without adoption-time expiry assigned to every individual normative requirement and without a mandatory recurring combined renewal test.","nearest_rivals":["MCP SEP-2596 specification-feature lifecycle and deprecation policy","Chromium web-platform feature deprecation process","Kubernetes API deprecation policy","OpenTelemetry retirement of OpenTracing compatibility requirements","IETF RFC 9395 deprecation of IKEv1 and obsoleted algorithms"],"remaining_contrastive_claim":"Unlike the located practices, the candidate attaches an expiry presumption to every individual normative interface requirement when adopted and renews it only after a recurring joint evidence test of active dependency, migration cost, security exposure, and asymmetric producer-consumer tolerance. Dependency measurement, staged deprecation, migration protection, security review, and rollback are not claimed as novel.","authority_safety":{"decision_authority":"Only the standards body or specification governance body already authorized to adopt, revise, deprecate, and retire normative requirements may set review dates, renew requirements, approve exceptions, or authorize staged retirement and rollback.","authorized_first_step":"A designated review team may conduct a nonbinding shadow review of a bounded historical sample, using existing records and no production or specification changes, then submit findings to the authorized standards body.","excluded_actions":["Automatically removing a requirement when its review date arrives","Changing a published specification, conformance suite, SDK, or production implementation without the governing body's normal approval","Treating missing telemetry as proof of no dependency","Removing substantive security, privacy, rights, accessibility, safety, or interoperability protections merely because they impose cost","Forcing migration without a documented replacement, notice period, and review of affected adopters","Using aggregate burden reduction to override concentrated harm or unauthorized redistribution of compatibility obligations","Collecting new user-level telemetry or sensitive dependency data without applicable authorization and safeguards"],"halt_rollback":"Any later pilot must pause retirement and retain or restore the requirement if compatibility failures exceed the preset margin, security or safety outcomes worsen, an unmeasured dependent population appears, the migration path fails, or the governing body withdraws authorization. Expiry alone never changes normative status."},"negative_tests":{"strongest_counterevidence":"The closest counterevidence is MCP SEP-2596, which already applies lifecycle governance to individual protocol features and normative requirements using telemetry, maintenance cost, security and interoperability criteria, migration windows, warnings, removal dates, and possible restoration. Kubernetes and Chromium add staged clocks, usage measurement, trials, monitoring, and rollback; OpenTelemetry demonstrates actual retirement of normative compatibility requirements. These sources substantially collide with the broad proposal and leave only the adoption-time, every-requirement, recurring combined-test default as contrastive.","problem_falsifier":"The problem is falsified for the sampled requirements if continued requirements all show material active dependency or indispensable protective value, if their incremental conformance and security burden is negligible, or if protocol evolution is blocked by another cause rather than persistence by default.","intervention_falsifier":"The intervention is falsified if the shadow or authorized pilot finds that adoption-time expiry and the combined renewal test identify no additional safely removable requirements, consume more review and migration effort than the avoidable burden they expose, or—upon any authorized retirement—fail to lower conformance effort by at least 10% or increase interoperability failures beyond the preset margin. The residual contrastive claim is separately falsified by an official standard, deployed governance policy, product process, or patent already showing adoption-time expiry for each normative interface requirement with continuation contingent on the same combined evidence test.","risks":["Review overhead may exceed the burden of rarely consequential requirements.","Telemetry can miss private, offline, low-volume, or vulnerable consumers.","Producers and consumers may strategically overstate or understate dependency and migration cost.","Uniform expiry schedules may ignore differences in maturity, criticality, or ecosystem cadence.","Frequent status uncertainty may discourage adoption or fragment implementations.","Compatibility exceptions may become permanent and recreate the original inertia.","Retirement may remove a latent security, accessibility, or interoperability safeguard whose value appears only under rare conditions.","An every-requirement rule may create ritual renewal rather than substantive evidence review."]},"next_evidence_step":"Run a nonbinding retrospective shadow review on 20 individual normative requirements from one mature specification: 10 previously deprecated or retired and 10 retained, selected before scoring. For each, reconstruct what an adoption-time expiry record and the joint dependency, migration-cost, security-exposure, implementation-burden, and asymmetric-tolerance test would have concluded using only already authorized records. Measure reviewer hours, inter-rater agreement, requirements newly flagged beyond the ordinary lifecycle, estimated removable conformance effort, missed dependencies, and whether known historical compatibility outcomes would have triggered halt or rollback. Do not alter the specification or implementations. Advance only if the review identifies at least one additional plausibly removable requirement, produces a testable route to the 10% conformance-effort threshold, and reveals no known interoperability harm beyond the body’s preset margin; otherwise revise or reject the intervention.","prior_art_status":"SEARCHED_BOUNDED","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":["Restricted novelty to adoption-time expiry for every individual normative requirement plus a recurring combined renewal test.","Separated an expiry-review date from automatic removal and preserved interoperability as a protected constraint."],"operational_changes":["Defined requirement-level evidence fields, authorized decisions, exclusions, halt conditions, and a retrospective shadow review.","Specified staged deprecation, migration, exception, monitoring, and restoration controls."],"evidence_changes":["Integrated the independent prior-art record's substantial collision with MCP, Chromium, Kubernetes, OpenTelemetry, and IETF practices.","Treated broad feature lifecycle, telemetry, migration, warning, and rollback methods as established rather than novel."],"claim_changes":["Retained only the exact contrastive claim stated in the prior-art record.","Made the empirical 10% conformance-effort result conditional and explicitly falsifiable rather than an asserted benefit."]}}