{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp04_retrieval_first_paired20_20260802","cell_id":"layer_decay_and_expiration_management__aviation_aeronautics","arm":"PROPOSAL_FIRST","candidate_id":"pf_aero_flight_test_config_lifecycle_001","hypothesis_id":null,"version":0,"title":"Lifecycle-Governed Flight-Test Processing Configurations","problem":"A flight-test organization accumulates successive versions of sensor-calibration files, telemetry parameter maps, derived-variable algorithms, flight-control software labels, and correction tables across aircraft, modifications, and test campaigns. When these processing configurations lack explicit applicability, supersession, expiry, dependency, and archival states, obsolete packages remain selectable beside current ones. Analysts can process a flight with a configuration that is internally valid but inapplicable to that aircraft state, while indiscriminate cleanup can destroy the exact configuration needed to reconstruct an earlier result or investigation.","actors":["flight-test data engineers","flight-test analysts","instrumentation engineers","flight-control engineers","configuration managers","airworthiness and safety reviewers","accident or anomaly investigators"],"observable_state":"For a sampled aircraft and campaign, the processing repository contains multiple generations of configuration packages with overlapping names or applicability intervals; some lack a declared successor, last-validation date, owner, dependent report list, or lifecycle state; superseded packages remain visible in ordinary selection interfaces; and archived packages have not been proven restorable with the current toolchain.","consequence":"An analyst may select stale calibration or derivation logic, producing results that appear plausible but do not represent the tested aircraft configuration. Review effort increases because provenance must be reconstructed manually, while aggressive deletion can make prior plots, reports, limit findings, or anomaly investigations irreproducible.","affected_objective":"Integrity, timely interpretation, and reproducibility of flight-test evidence used for engineering and airworthiness decisions.","intervention":"Place a lifecycle-governance layer over flight-test processing configurations. Give every immutable configuration package an identity, aircraft and modification applicability interval, creation and validation dates, owner, successor, dependent outputs, retention class, and hot, archived, quarantined, or removed state. Expired or superseded packages become unavailable to ordinary new-run selection but remain addressable through historical manifests. Before disposition, check live dependencies and preservation holds; archive reconstructively important packages; test restoration across age and format bands; and use reversible quarantine plus a durable deletion or supersession marker for any package approved for removal.","structural_mapping":[{"archetype_element":"Accumulated sequential layers","domain_realization":"Successive immutable versions of calibration files, parameter maps, correction tables, algorithms, and software-label manifests deposited during flight-test campaigns."},{"archetype_element":"Age and validity change","domain_realization":"A package loses active applicability when instrumentation, aircraft modification state, software load, processing tools, or validated engineering assumptions change, even though it remains necessary for historical reconstruction."},{"archetype_element":"Stale layers masquerade as current","domain_realization":"Superseded packages remain searchable and selectable in the same interface as current packages without prominent applicability or successor markers."},{"archetype_element":"Dependency and reconstruction risk","domain_realization":"Prior reports, plots, certification evidence, and anomaly investigations may depend on the exact historical package and compatible processing environment."},{"archetype_element":"Differentiated disposition","domain_realization":"Current packages stay hot; superseded but referenced packages are archived; uncertain candidates enter review; approved removals enter quarantine; and held evidence is preserved by exception."},{"archetype_element":"Accountable bounded lifecycle","domain_realization":"Every transition records authority, reason, dependency result, hold status, successor, rollback deadline, and restore evidence."}],"mechanism_mapping":[{"mechanism_slug":"stale_layer_detection_dashboard","role":"Creates the identity-resolved inventory and flags packages whose aircraft applicability, validation context, owner, references, or described processing environment no longer matches current reality; it only produces a review queue.","counterfactual_removal":"Without it, stale packages remain distributed and lifecycle decisions revert to directory names, age, or individual memory."},{"mechanism_slug":"time_to_live_ttl_policy","role":"Assigns a review or active-selection expiry when each package is released. Clock expiry removes default selectable status or requests revalidation; it does not authorize destruction.","counterfactual_removal":"Without it, active status persists by default after the package's assumed freshness horizon."},{"mechanism_slug":"dependency_safe_delete_check","role":"Traces inbound references from flight manifests, derived datasets, reports, plots, investigations, scripts, and scheduled processing before any package can leave recoverable storage.","counterfactual_removal":"Without it, apparently obsolete packages could be removed while still load-bearing for reconstruction."},{"mechanism_slug":"retention_schedule","role":"Maps configuration classes and evidence roles to minimum and maximum retention rules and records safety, investigation, contractual, or legal preservation holds that override ordinary expiry.","counterfactual_removal":"Without it, disposition would lack a class-based authority and exceptions could become informal or invisible."},{"mechanism_slug":"lifecycle_storage_tiering_policy","role":"Moves infrequently accessed but reconstructively valuable packages and their compatible runtime artifacts from active storage to progressively colder archival tiers without treating demotion as deletion.","counterfactual_removal":"Without it, the organization faces a false choice between keeping every historical package active and destroying it."},{"mechanism_slug":"archive_restore_test","role":"Samples archived packages across campaigns, ages, and formats and exercises retrieval, integrity verification, toolchain recreation, reprocessing, and linkage to a historical flight manifest.","counterfactual_removal":"Without it, archive status would not demonstrate that a historical result can actually be reconstructed."},{"mechanism_slug":"soft_delete_quarantine_window","role":"Hides an approved removal candidate from routine use while retaining a recoverable copy for an impact-scaled grace period with a recorded restoration path.","counterfactual_removal":"Without it, classification or dependency-detection errors could become immediately irreversible."},{"mechanism_slug":"tombstone_or_deletion_marker","role":"Preserves the removed package identity, disposition reason, date, and successor or archive reference so an old manifest encounters an explicit status rather than an ambiguous missing file.","counterfactual_removal":"Without it, absence could be mistaken for corruption or nonexistence, and stale indexes could reintroduce superseded packages."}],"causal_chain":["Processing-configuration versions accumulate as aircraft, instrumentation, software, and analysis methods change.","Missing lifecycle metadata leaves old packages active and visually equivalent to applicable packages.","Analysts face a larger ambiguous selection set, while maintainers hesitate to clean it because historical dependencies are uncertain.","The inventory and applicability checks identify stale or superseded packages, and review-expiry rules prevent them from remaining active by default.","Retention rules, holds, and inbound-dependency checks divide candidates into preserve, archive, revalidate, or quarantine paths.","Tiering reduces active clutter while historical manifests retain exact package identities; restore drills test whether archived evidence remains reconstructable.","Reversible quarantine and tombstones make approved cleanup accountable without turning disappearance into lost lineage.","The active selection set becomes bounded and context-specific while historical reconstruction paths remain explicit."],"baseline":"Configuration packages are retained in shared repositories or program-specific stores, distinguished mainly by filenames, folder conventions, release notes, and analyst knowledge. Teams may freeze configurations for particular flights, but old packages commonly remain accessible, and cleanup or archival occurs through campaign closeout or storage-pressure projects rather than a continuously inspected lifecycle.","nearest_rivals":["Immutable per-flight processing manifests that bind each flight to exact configuration versions and preserve every referenced artifact","Conventional configuration-control boards that approve releases and supersession but retain all versions in the same active repository","Repository access controls and interface filters that show only an administrator-designated current package","Campaign closeout archiving that moves an entire completed program to offline storage without per-package dependency classification"],"remaining_contrastive_claim":"The candidate's testable contrast is not immutable versioning alone; it is whether explicit expiry of active visibility, dependency-gated differentiated disposition, reversible removal, and exercised restoration can bound the ordinary selection set while preserving reconstruction of historical processing.","authority_safety":{"decision_authority":"The flight-test data configuration manager may classify and recommend lifecycle transitions; the designated flight-test chief engineer and records or safety authority must approve removal rules and preservation exceptions. Investigative or legally held material remains under the responsible authority's control.","authorized_first_step":"Run a read-only, offline pilot on copied metadata and configuration artifacts from one completed campaign. Produce proposed states and conduct restore exercises on test copies; do not change production visibility or retention.","excluded_actions":["changing aircraft software, avionics, instrumentation, or flight-control parameters","altering an approved historical flight manifest or engineering result","automatically deleting any authoritative configuration or evidence","overriding an investigation, safety, contractual, or legal hold","making lifecycle scores authoritative engineering judgments","using the pilot's classifications in live flight operations"],"halt_rollback":"Stop the pilot if inventory reconciliation cannot uniquely identify packages, a proposed transition conflicts with a manifest or hold, copied artifacts include uncontrolled sensitive data, or a restore produces nonidentical processing inputs. Because the first step is read-only and uses test copies, rollback consists of discarding pilot metadata and leaving authoritative repositories unchanged."},"negative_tests":{"strongest_counterevidence":"For the sampled campaign, every flight and derived output already resolves through an immutable manifest to a unique configuration; superseded packages are excluded from normal selection; every retained package has an enforced disposition state and hold status; and sampled archives can be restored and reprocessed with the current controlled procedure.","problem_falsifier":"The problem is falsified for the pilot scope if a reconciled inventory finds no ambiguous package identities, no superseded package exposed for ordinary new-run selection, no missing applicability or dependency metadata, and no failed reconstruction path among the prespecified sample.","intervention_falsifier":"The intervention is not supported if blinded analysts do not make fewer stale-package selections or complete configuration selection more reliably in a simulated task, or if lifecycle classification causes any prespecified historical reconstruction to fail compared with the baseline repository.","risks":["Incorrect applicability metadata could hide the only valid package for a test condition.","An incomplete dependency graph could misclassify a referenced package as an orphan.","Expiry language could be mistaken for permission to destroy safety evidence.","Archive formats, credentials, licenses, or runtime dependencies could decay despite successful file retrieval.","Lifecycle scores could create false precision and suppress engineering review.","Quarantined copies could conflict with required destruction or data-control obligations.","A dashboard could add administrative burden without changing analyst selection behavior."]},"next_evidence_step":"Using test copies from one completed campaign, pre-register a sample of 30 configuration packages spanning current, superseded, referenced, apparently orphaned, and archived states. Have two configuration engineers independently assign applicability, dependencies, holds, and proposed disposition; reconcile disagreements against manifests and reports. Then ask blinded analysts to select the correct package for a fixed set of historical and hypothetical new-run scenarios using the baseline interface versus a prototype lifecycle-filtered interface, and execute end-to-end restoration and deterministic input comparison for five archived packages. Record ambiguous selections, unsupported classifications, dependency misses, restore failures, elapsed selection time, and every proposed transition that would have harmed reconstruction; make no production changes.","prior_art_status":"UNSEARCHED","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}