{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp04_retrieval_first_paired20_20260802","cell_id":"layer_decay_and_expiration_management__computer_science","arm":"RETRIEVAL_FIRST","round_index":0,"hypotheses":[{"hypothesis_id":"H1","title":"Renewable leases for feature flags","problem":"Feature flags persist after rollout or experiment completion, expanding configuration state and retaining dead behavior.","affected_stakeholder":"Service owners maintaining long-lived applications","workflow_boundary":"Flag creation through runtime evaluation and retirement","failure_mode":"Unowned flags silently remain active or are deleted while live code still depends on them.","unit_of_analysis":"One feature flag and its code/configuration references","causal_lever":"Require creation-time expiry, explicit renewal, dependency-gated retirement, and reversible quarantine.","archetype_mapping":"Flags are sequential control layers whose usefulness decays but whose removal can break live paths.","expected_value":"A smaller configuration state space, less dead code, and safer flag cleanup.","falsifiable_claim":"Compared with dashboard-only review, renewable leases plus dependency checks reduce overdue flags and flag-conditioned test cases without increasing flag-related rollback incidents.","diversity_rationale":"Targets executable runtime controls, with renewal and reference safety as the intervention.","mechanism_slugs":["time_to_live_ttl_policy","dependency_safe_delete_check","soft_delete_quarantine_window"],"search_questions":["Have feature-flag systems already combined mandatory renewable TTLs with code-reference gates and quarantine?","How prevalent are overdue flags, and do adopters report measurable testing or incident costs?"]},{"hypothesis_id":"H2","title":"Supersession-aware expiry for coding-assistant indexes","problem":"Retrieval indexes retain obsolete documentation chunks that coding assistants present as current API guidance.","affected_stakeholder":"Developers using repository-grounded coding assistants","workflow_boundary":"Documentation ingestion through retrieval and answer generation","failure_mode":"A semantically stale chunk outranks its replacement and induces unsupported code.","unit_of_analysis":"One indexed documentation chunk and its successor relation","causal_lever":"Detect semantic staleness, demote expired chunks, and leave successor-resolving tombstones.","archetype_mapping":"Indexed chunks accumulate as knowledge layers; stale layers retain authority unless explicitly superseded.","expected_value":"Fewer obsolete API recommendations while preserving historical traceability.","falsifiable_claim":"On versioned-API tasks, supersession-aware expiry lowers obsolete-code suggestions versus age-only pruning without reducing recall for currently supported APIs.","diversity_rationale":"Targets retrieval authority rather than storage or executable state; the key lever is semantic supersession.","mechanism_slugs":["stale_layer_detection_dashboard","tombstone_or_deletion_marker"],"search_questions":["Do existing code-retrieval systems model chunk-level supersession rather than merely reindexing documents?","Which benchmark can distinguish obsolete-answer reduction from loss of valid historical context?"]},{"hypothesis_id":"H3","title":"Restore-tested lifecycle for ML lineage bundles","problem":"Archived model, feature, environment, and dataset snapshots appear available but cannot be reconstructed after formats and tooling drift.","affected_stakeholder":"ML reliability engineers investigating or reproducing past model behavior","workflow_boundary":"Model release archival through later incident reconstruction","failure_mode":"Metadata and checksums pass while an archived lineage bundle cannot be parsed or reconnected.","unit_of_analysis":"One release-specific ML lineage bundle","causal_lever":"Tier bundles by use and run end-to-end restore tests sampled across age and format strata.","archetype_mapping":"Release bundles are historical layers whose active value decays, yet rare reconstruction value requires verified archives.","expected_value":"Cheaper retention with earlier discovery of irrecoverable releases.","falsifiable_claim":"Stratified end-to-end restore drills detect more reconstruction failures before incidents and improve successful time-bounded restores versus checksum-only archive monitoring.","diversity_rationale":"Targets latent recoverability at the archive boundary; the unit is a multi-artifact reconstruction bundle.","mechanism_slugs":["lifecycle_storage_tiering_policy","archive_restore_test"],"search_questions":["Which ML platforms test full historical reconstruction rather than artifact integrity alone?","What failure rates and restore-time requirements exist across bundle ages and formats?"]},{"hypothesis_id":"H4","title":"Decay-governed database optimizer hints","problem":"Query hints and plan baselines accumulate after workloads and data distributions change, preserving formerly useful but now harmful optimizer overrides.","affected_stakeholder":"Database performance engineers","workflow_boundary":"Hint admission through query-plan selection and retirement","failure_mode":"A stale override remains authoritative and causes latency regressions that the native optimizer would avoid.","unit_of_analysis":"One query-specific hint or plan-baseline version","causal_lever":"Age-discount each override using recent benefit evidence, revalidate low-scoring layers, and quarantine before removal.","archetype_mapping":"Optimizer overrides form sequential policy layers whose value decays as workload context changes.","expected_value":"Fewer hint-induced regressions and less manual tuning debt.","falsifiable_claim":"Benefit-decayed hint demotion reduces hint-attributable tail-latency regressions versus indefinite retention while preserving median performance gains from still-useful hints.","diversity_rationale":"Targets performance-control layers at an automated decision boundary; removal is driven by observed benefit decay.","mechanism_slugs":["age_weighted_value_score","soft_delete_quarantine_window"],"search_questions":["Do database systems already expire hints using measured counterfactual benefit and reversible demotion?","What telemetry can attribute a regression to a stale hint rather than workload noise?"]},{"hypothesis_id":"H5","title":"Expiring leases for CI test quarantines","problem":"Temporary test quarantines accumulate and permanently weaken continuous-integration quality gates.","affected_stakeholder":"Release engineers and teams relying on CI pass signals","workflow_boundary":"Failure suppression approval through revalidation or reinstatement","failure_mode":"An obsolete quarantine continues masking a real regression because no owner must renew it.","unit_of_analysis":"One test-quarantine exception","causal_lever":"Assign class-based maximum durations, named owners, renewal evidence, and preservation exceptions for documented cases.","archetype_mapping":"Quarantines are exception layers deposited over a quality gate; indefinite activation converts temporary relief into hidden policy debt.","expected_value":"More trustworthy CI signals and faster repair of suppressed tests.","falsifiable_claim":"Owner-renewed quarantine leases reduce overdue suppressions and regressions first detected after release versus indefinite quarantines without materially increasing flaky-test blockage.","diversity_rationale":"Targets governance exceptions and release assurance; the disposition decision depends on accountable renewal rather than access or storage pressure.","mechanism_slugs":["retention_schedule","time_to_live_ttl_policy","stale_layer_detection_dashboard"],"search_questions":["Which CI systems enforce evidence-backed expiry rather than optional quarantine dates?","How often do quarantined tests mask later regressions, and what renewal burden will teams accept?"]}]}