{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"context_keyed_representation_switching__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"context_keyed_representation_switching__computer_science__P1","proposal_index":1,"version":0,"title":"Build-Keyed Decoder Maps for Version-Skewed Telemetry","problem":"During rolling deployments and historical incident review, a service may reuse the same compact event code while changing that code's field meanings between build epochs. A telemetry explorer that keeps one mutable service-wide decoder interprets every stored event through the newest mapping, so old records can silently acquire new labels, units, or enum meanings even though their raw bytes have not changed.","actors":["Site reliability engineers querying telemetry","Service release owners defining event schemas","Telemetry-platform operators maintaining decoders","Incident commanders relying on rendered events"],"observable_state":"Records with the same service name and event code but different recorded artifact digests yield incompatible valid field interpretations. After a global decoder update, replaying a fixed historical query changes the rendered meaning of older records; mixed-version traces may also show mutually inconsistent interpretations without displaying which decoder governed each row.","consequence":"Operators can construct an incorrect incident timeline, correlate unlike quantities, or choose a remediation based on telemetry meanings that did not apply to the producing build.","affected_objective":"Reproducible, build-appropriate interpretation of telemetry across rolling deployments and historical re-entry.","intervention":"Keep a versioned bank of immutable decoder maps on the shared telemetry query substrate. Bind each map to an explicit schema epoch and authenticated build-manifest identifiers; route every record to its matching map; display the selected map and version beside the decoded output; prevent a map update from modifying other epochs; and preserve raw payloads plus prior maps for re-entry. Conflicting or absent context keys produce a constrained raw-payload view rather than selection of the nearest decoder. Map changes are evaluated in shadow, and an atomic switch guard prevents one record from being rendered with mixed decoder state.","structural_mapping":[{"archetype_element":"Shared Substrate Scope","domain_realization":"One telemetry store and query engine serves events from all retained service builds."},{"archetype_element":"Representation Portfolio","domain_realization":"Persistent decoder maps define event-code, field, unit, and enum correspondences for bounded schema epochs."},{"archetype_element":"Context Key Space","domain_realization":"Service identity, artifact digest, and declared schema epoch identify the producing context."},{"archetype_element":"Representation Selection Rule","domain_realization":"A validated build-manifest binding selects exactly one decoder map for each rendered record."},{"archetype_element":"Active Representation Indicator","domain_realization":"Each decoded row and exported result carries the selected decoder-map identifier and version."},{"archetype_element":"Representation Isolation Boundary","domain_realization":"Epoch-specific namespaces and immutable snapshots prevent edits to one decoder from changing another."},{"archetype_element":"Switch Transition Guard","domain_realization":"The renderer resolves and pins one decoder snapshot before decoding a record, avoiding mixed-map reads during registry updates."},{"archetype_element":"Re-Entry Integrity Test","domain_realization":"A frozen corpus from an older build is decoded before and after activation of newer maps and compared for semantic identity."},{"archetype_element":"Unknown-Context Fallback","domain_realization":"Records with missing, conflicting, or unrecognized build evidence remain visible only as raw payloads with an unresolved-context warning."},{"archetype_element":"Version and Provenance Trace","domain_realization":"Query results record the raw-event identity, context evidence, routing decision, decoder version, and registry version."}],"mechanism_mapping":[{"mechanism_slug":"context_to_map_routing_table","role":"Maps each authenticated service-build and schema-epoch tuple to one persistent decoder snapshot.","counterfactual_removal":"Without the routing table, the renderer must guess from event content or use the current global decoder, recreating silent wrong-map activation."},{"mechanism_slug":"context_tagged_namespace_partition","role":"Separates decoder definitions and update permissions by schema epoch while retaining a shared query engine.","counterfactual_removal":"Without namespace isolation, publishing a decoder correction for one epoch can overwrite an identically numbered event in another."},{"mechanism_slug":"active_map_status_indicator","role":"Makes the governing decoder visible and exportable for operator review and later reproduction.","counterfactual_removal":"Without the indicator, routing errors appear indistinguishable from malformed event content."},{"mechanism_slug":"minimal_pair_context_probe","role":"Feeds identical event codes paired with two valid build keys and verifies that each selects its distinct expected interpretation.","counterfactual_removal":"Without minimal-pair probes, testing may show that each decoder works alone while failing to detect context-key collisions."},{"mechanism_slug":"rollback_to_prior_map_snapshot","role":"Restores the prior registry binding if a candidate decoder or route changes established historical output unexpectedly.","counterfactual_removal":"Without snapshot rollback, recovery requires reconstructing earlier decoder state during an incident."}],"causal_chain":["Compact event codes are reused across build epochs while their field correspondences change.","A mutable decoder keyed only by service and event code replaces the prior correspondence with the newest one.","Historical and rolling-deployment records lack an enforced route to the decoder valid when they were produced.","The query engine silently renders some records through the wrong correspondence, and decoder updates alter past query output.","Build evidence is validated and used as an explicit context key for a versioned routing table.","The selected decoder snapshot is pinned, exposed, and applied while all inactive maps remain isolated from the read and update.","Unknown contexts abstain to raw display, and frozen-corpus re-entry tests detect cross-map overwrite or drift.","Historical interpretations therefore remain reproducible conditional on correct retained provenance and decoder definitions."],"baseline":"One mutable service-wide dictionary is keyed by event code, with the latest decoder definition winning; stored raw events are reinterpreted at query time, and the active definition is not shown in results.","nearest_rivals":["Allocate globally unique event identifiers and forbid semantic reuse; this removes the context-dependent collision but requires producer migration and does not preserve already-colliding identifiers by itself.","Normalize every event into one canonical schema at ingestion; this fixes an interpretation once but can discard epoch-specific distinctions and does not support later re-entry under the original map.","Maintain a separate telemetry index and query pipeline for every release; this isolates mappings through full substrate duplication rather than governed map selection on a shared substrate."],"remaining_contrastive_claim":"The candidate is specifically for recurring build contexts in which identical event codes have different legitimate correspondences and old correspondences must remain re-enterable. Its distinguishing structural claim is that decoding should select among persistent, isolated maps at interpretation time with visible provenance, rather than merely attach a version label, permanently canonicalize the data, or duplicate the entire telemetry system.","authority_safety":{"decision_authority":"The telemetry-platform owner may operate the registry, but activating or changing a service's build-to-decoder binding requires approval from that service's schema owner; incident responders may request raw fallback but may not rewrite provenance.","authorized_first_step":"Run an offline replay against copied, non-production telemetry using two already-retained build epochs and one bounded family of colliding event codes.","excluded_actions":["Changing producer event formats","Rewriting or deleting stored raw telemetry","Using inferred user identity or other sensitive proxies as context keys","Changing alert thresholds or automated remediation inputs","Activating the router in production","Silently selecting a nearest decoder when build evidence is absent"],"halt_rollback":"Stop the replay if a record lacks stable provenance, a decoder performs external effects, or output cannot be traced to one pinned map. Discard derived replay output and restore the test registry to its captured prior snapshot; raw source records remain unchanged."},"negative_tests":{"strongest_counterevidence":"A retained sample across deployment epochs shows that each event code has one invariant schema, or that every payload is already self-describing and independently resolves to the same interpretation without build context.","problem_falsifier":"For a frozen historical corpus, updating the current decoder never changes rendered fields, units, enums, or validation outcomes, and no valid pair of build contexts assigns different meanings to the same code.","intervention_falsifier":"In offline minimal-pair and re-entry tests, build-key routing cannot select the expected maps reliably, inactive-map output changes after another map is updated, or unresolved records are decoded with confident semantics instead of entering raw fallback.","risks":["Missing, forged, or incorrect artifact provenance can activate the wrong decoder.","A stale or vulnerable historical decoder may become executable again during re-entry.","Correlated records in one trace may legitimately span builds, confusing operators if map changes are visible only at row level.","Map proliferation and retention can increase maintenance burden and leave rarely used maps untested.","Incorrectly declaring fields shared across epochs can create hidden cross-map coupling.","Exposing detailed build identifiers may reveal operational metadata to viewers who do not need it.","Raw fallback can reduce usability during urgent investigations and may expose payload details that decoded views normally suppress."]},"next_evidence_step":"Select one service, two retained build epochs, and one event-code family known internally to have candidate semantic differences. Freeze a small replay corpus containing matched valid records, swapped-key minimal pairs, missing-key records, and a sequence that returns to the older epoch after updating a shadow copy of the newer map. Compare map selection, rendered semantics, fallback behavior, provenance completeness, and byte-for-byte re-entry output against the captured baseline; do not connect results to production alerts or remediation.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"No other experiment candidates or proposals were inspected; this isolated one-shot realization is centered on version-skewed telemetry interpretation within a shared software-observability substrate.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial one-shot candidate with complete causal, operational, safety, and falsification fields."],"conceptual_changes":["None; this is the initial version."],"operational_changes":["None; this is the initial version."],"evidence_changes":["None; prior art remains unsearched and the first evidence step is prospective."],"claim_changes":["No novelty, prevalence, demand, or effect-size claim is made."]}}