{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp09_archetype_breadth150_20260804","cell_id":"preimage_set_characterization__computer_science","arm":"BREADTH_PROBE_ONE_SHOT","candidate_id":"preimage_set_characterization__computer_science__P1","proposal_index":1,"version":0,"title":"Checkout Feature-Flag Output Collision Ledger","problem":"A checkout team observes the rendered output state checkout_variant=legacy and treats it as evidence that a particular feature flag is off or redundant. Under the versioned flag evaluator and renderer, however, distinct combinations of flag values, targeting-context classes, override precedence, and fallback states can all produce that same output. A rollback or flag-removal decision made from the output alone can therefore rest on a false assumption of a unique underlying configuration.","actors":["Checkout service owner","Feature-flag platform engineer","Release manager","Incident commander"],"observable_state":"In a frozen checkout release, synthetic requests with different flag-evaluation traces produce the identical checkout_variant=legacy label and legacy render signature, while the release dashboard retains only that projected output and not the complete set of compatible input tuples.","consequence":"A maintainer may force, delete, or roll back the flag believed to be responsible, changing behavior for another context class, removing a usable rollback path, or failing to address the configuration that generated the observed request.","affected_objective":"Correct and safely reversible checkout configuration changes.","intervention":"Create a read-only preimage ledger for the output condition checkout_variant=legacy. Fix the evaluator, rule snapshot, precedence semantics, fallbacks, and renderer version; declare a finite input domain of relevant flag assignments, synthetic context-equivalence classes, and evaluator availability states; evaluate or symbolically backsolve every domain member; record all members producing the target output, their collision groups, boundary cases, and completeness evidence; and prohibit using membership alone as proof of the actual production configuration or as authorization to change a flag.","structural_mapping":[{"archetype_element":"Mapping Under Review","domain_realization":"The frozen composition of checkout flag evaluation, override precedence, SDK fallback behavior, and rendering logic that maps an input tuple to a checkout variant and render signature."},{"archetype_element":"Output Condition or Target Value","domain_realization":"The exact output predicate checkout_variant=legacy with a specified legacy render signature."},{"archetype_element":"Input Domain Boundary","domain_realization":"All enabled/disabled assignments for four named checkout flags, crossed with six predefined synthetic context-equivalence classes and two evaluator availability states, under one frozen configuration and code version."},{"archetype_element":"Preimage Membership Rule","domain_realization":"Include a tuple only when the hermetic evaluator and renderer return the target variant and exact render signature."},{"archetype_element":"Candidate Input Enumeration","domain_realization":"Exhaustively evaluate the 192 tuples in the bounded pilot domain and retain concrete witnesses for each included tuple."},{"archetype_element":"Collision and Multiplicity Check","domain_realization":"Group distinct tuples that collapse to the same target output and count the target fiber without interpreting any member as the actual production source."},{"archetype_element":"Completeness Evidence","domain_realization":"Reconcile evaluated tuple count with the declared Cartesian product, require a determinate result for every tuple, and label all configurations outside that product as unknown."},{"archetype_element":"Boundary Case Register","domain_realization":"Record context classes on targeting boundaries, conflicting overrides, missing attributes, SDK unavailability, and fallback-value cases separately."},{"archetype_element":"Projection Loss Note","domain_realization":"Document which evaluated flag values and context distinctions disappear when the dashboard retains only checkout_variant=legacy."},{"archetype_element":"Downstream Use Guardrail","domain_realization":"Use the ledger to choose discriminating observations or tests; do not infer causality, production prevalence, or deletion safety from membership."}],"mechanism_mapping":[{"mechanism_slug":"constraint_solver_backsolve","role":"Constraint-Solver Backsolve derives satisfying input families for the frozen evaluator when later domains are too large for direct enumeration, with every symbolic family checked by a concrete witness.","counterfactual_removal":"Without backsolving or exhaustive enumeration, the ledger would contain selected examples rather than a bounded characterization of the output's preimage."},{"mechanism_slug":"collision_analysis_matrix","role":"The Collision Analysis Matrix shows which distinct flag, context, and fallback tuples become indistinguishable after rendering and dashboard projection.","counterfactual_removal":"Without collision analysis, maintainers could see matching tuples yet still overlook that the output is many-to-one."},{"mechanism_slug":"coverage_completeness_audit","role":"The Coverage Completeness Audit accounts for every tuple in the declared domain and distinguishes exhaustive bounded coverage from unknown states outside it.","counterfactual_removal":"Without the audit, an interrupted run or omitted context class could be presented as a complete inverse set."},{"mechanism_slug":"witness_and_counterexample_set","role":"Concrete witnesses reproduce membership, while counterexamples near each rule boundary demonstrate exclusions and help select observations that separate rival configurations.","counterfactual_removal":"Without witnesses and counterexamples, symbolic membership and boundary handling would be difficult to verify independently."}],"causal_chain":["The flag evaluator and checkout renderer map a rich configuration-and-context tuple to a compact variant label and render signature.","Distinct tuples can collide at the target output because precedence, inactive flags, and fallbacks erase distinctions.","The dashboard preserves the compact output while omitting distinctions among compatible tuples.","A maintainer can mistake output equality for equality or uniqueness of the underlying flag state.","A flag change based on that inference can behave differently in context classes represented by other members of the preimage.","The ledger exposes the bounded satisfying set, multiplicity, boundaries, and unknown region before a change is considered.","Witnesses or additional telemetry can then discriminate among compatible tuples, while change authority remains with the service owner and release manager."],"baseline":"For the bounded pilot, the comparison baseline is manual toggling of one flag at a time, inspection of a flag inventory, and a small set of sampled cohort previews. It can produce useful examples but does not require an explicit input domain, a complete satisfying set, a multiplicity count, or an unknown-region label.","nearest_rivals":["Pairwise or combinatorial flag testing samples interactions for fault discovery; the nearest implementation does not organize results as the complete bounded inverse set of one specified rendered output.","A flag decision table documents forward rule evaluation; the nearest implementation does not enumerate and audit every input tuple that collapses to the target output.","Per-request evaluation tracing identifies the path for one observed request; it does not characterize all other inputs compatible with the same projected output.","Dead-flag analysis asks whether a flag can affect reachable behavior; it does not preserve the full collision set for a specified output condition."],"remaining_contrastive_claim":"Within the same frozen evaluator and 192-tuple pilot domain, the intervention is distinguished if it returns every and only tuple producing the target output, reports their multiplicity and boundary cases, and marks states outside the domain as unknown, while the specified baseline and rival implementations return samples, forward descriptions, single traces, or influence judgments without that inverse-set completeness contract.","authority_safety":{"decision_authority":"The checkout service owner and release manager jointly retain authority over flag changes and deployment; during an incident, the incident commander controls operational timing. The ledger has advisory authority only.","authorized_first_step":"Run the bounded enumeration against a frozen configuration in a hermetic sandbox using synthetic context classes and read-only copies of flag metadata.","excluded_actions":["Automatically changing, deleting, or forcing any production flag","Sending synthetic combinations to production checkout systems","Using real customer identifiers or exposing sensitive targeting attributes","Declaring one preimage member to be the actual cause without discriminating evidence","Declaring a flag safe to remove solely because multiple tuples share the target output"],"halt_rollback":"Halt if any domain tuple is unevaluated, the frozen versions cannot be reproduced, sensitive attributes enter the artifact, or a concrete witness disagrees with symbolic membership. Mark the ledger incomplete, discard the generated advisory artifact, and continue with existing change controls; the first step makes no production mutation to roll back."},"negative_tests":{"strongest_counterevidence":"A frozen evaluator may already emit a verified decision diagram or equivalent artifact containing all satisfying assignments, the declared domain, collision counts, boundary semantics, and completeness status for each rendered output. If operators already use that artifact before flag changes, the proposed ledger adds no distinct decision support.","problem_falsifier":"For the declared checkout domain, demonstrate that the target output has exactly one input tuple and that the dashboard preserves that tuple, or show that no flag decision is made from the projected output or assumed configuration equivalence.","intervention_falsifier":"On a seeded finite domain with an independently computed ground-truth preimage, the ledger omits a satisfying tuple, includes a nonsatisfying tuple, reports completeness after an indeterminate evaluation, or fails to reproduce membership under the frozen versions.","risks":["Combinatorial growth can cause timeouts that users misread as exhaustive results.","A stale rule, SDK, renderer, or fallback version can produce a valid ledger for the wrong mapping.","Poorly chosen context-equivalence classes can hide distinctions outside the declared domain.","The artifact could expose sensitive targeting logic or attributes.","Users may confuse compatibility with the target output for actual causation or production frequency.","Symbolic models can diverge from concrete evaluator behavior at precedence or missing-attribute boundaries."]},"next_evidence_step":"Freeze one nonproduction checkout configuration and renderer version; select four binary flags, six synthetic context-equivalence classes, and available/unavailable evaluator states; enumerate all 192 tuples in a hermetic harness; independently review the domain count and membership predicate; seed at least one precedence conflict, missing-attribute boundary, and fallback case; then compare the ledger with manual one-flag toggling for set accuracy, multiplicity reporting, and explicit unknown handling. Stop after this single bounded artifact and review; do not alter production flags.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Runtime isolation was preserved and no prior proposals or experiment artifacts were inspected. The candidate is grounded solely in the supplied archetype and domain card, so no comparative diversity claim about other proposals is made.","revision_record":{"parent_version":null,"progress_targets_addressed":[],"conceptual_changes":[],"operational_changes":[],"evidence_changes":[],"claim_changes":[]}}