{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp04_retrieval_first_paired20_20260802","cell_id":"computability_boundary_mapping__engineering_design","arm":"RETRIEVAL_FIRST","round_index":0,"hypotheses":[{"hypothesis_id":"H1","title":"Boundary review for firmware-equivalence automation","problem":"A project funds a total checker for behavioral equivalence of arbitrary embedded programs without testing whether the unrestricted claim is decidable.","affected_stakeholder":"Firmware assurance leads and certification managers","workflow_boundary":"From proposed component substitution to approval of equivalence evidence","failure_mode":"Timeouts or passing regression tests are reported as proof of equivalence or non-equivalence.","unit_of_analysis":"A pair of firmware builds plus its declared behavior model","causal_lever":"Require a model-specific reduction or constructive decider before accepting a universal equivalence requirement; otherwise narrow the claim and expose UNKNOWN.","archetype_mapping":"Applies computability boundary mapping at requirements review, using a halting-style reduction and independent direction check to distinguish impossible universal equivalence from bounded evidence.","expected_value":"Could prevent investment in an unsupported total checker while preserving bounded or one-sided assurance.","falsifiable_claim":"For the declared unrestricted firmware language, a total computable reduction from halting instances to equivalence instances can be constructed with answer preservation; failure of any reduction obligation under independent review falsifies the hypothesis.","diversity_rationale":"Targets an impossibility decision at project authorization, unlike the abstraction, synthesis-search, language-governance, and external-oracle interventions.","mechanism_slugs":["halting_problem_reduction","many_one_reduction_proof","reduction_direction_checklist"],"search_questions":["Have firmware or embedded-system equivalence projects published undecidability boundaries for unrestricted programs?","What restricted equivalence checkers are used after universal equivalence is rejected?","Which proof obligations are commonly missed in reductions concerning program equivalence?"]},{"hypothesis_id":"H2","title":"Sound abstraction for controller safety analysis","problem":"Simulation-based controller reviews cannot exhaust unbounded plant and software behaviors but are communicated as universal safety checks.","affected_stakeholder":"Control-system safety engineers and design authorities","workflow_boundary":"From controller-model submission to safety-analysis sign-off","failure_mode":"A finite simulation campaign misses a reachable hazard while its clean result is interpreted as proof of safety.","unit_of_analysis":"One controller–plant model and one formal hazard property","causal_lever":"Over-approximate the concrete dynamics with a finite abstraction, model-check it, and label counterexamples as real or potentially spurious.","archetype_mapping":"Moves an exact unrestricted reachability claim into a decidable abstract model with one-directional soundness and explicit uncertainty residue.","expected_value":"Could provide trustworthy safe verdicts while directing engineering effort toward reviewing false alarms rather than extrapolating simulations.","falsifiable_claim":"On a benchmark with seeded reachable hazards, the abstraction misses zero concrete hazards; any missed seeded hazard falsifies its claimed soundness, while extra alarms do not.","diversity_rationale":"Changes the analyzed representation and permits false positives at model sign-off; H1 instead tests impossibility, and the other hypotheses govern search, language, or external dependencies.","mechanism_slugs":["abstract_interpretation_or_model_checking","proof_by_counterexample","computability_boundary_decision_record"],"search_questions":["Where has sound over-approximation replaced simulation-only assurance in physical control design?","How are abstraction soundness and spurious counterexamples validated in engineering practice?","What evidence exists on alarm burden and adoption by safety engineers?"]},{"hypothesis_id":"H3","title":"Explicit UNKNOWN for enumerative design synthesis","problem":"An enumerative design generator reports infeasible when it fails to find a compliant design before its compute budget expires.","affected_stakeholder":"Concept-design engineers using automated synthesis","workflow_boundary":"From formalized requirements entering the synthesizer to concept-selection handoff","failure_mode":"Search timeout is collapsed into a negative feasibility verdict, potentially discarding feasible concepts.","unit_of_analysis":"One requirement set and its synthesis run","causal_lever":"Dovetail enumerable candidate generators, return YES only with a checkable design witness, and return UNKNOWN—not NO—at the resource bound.","archetype_mapping":"Reclassifies synthesis from total decision to bounded one-sided recognition and makes nontermination residue operationally visible.","expected_value":"Could reduce false infeasibility decisions without overstating what bounded search establishes.","falsifiable_claim":"In a shadow evaluation, every YES carries a valid witness and no budget exhaustion produces NO; any witnessless YES or timeout-derived NO falsifies the protocol.","diversity_rationale":"Intervenes in the output alphabet and scheduling of instance-level synthesis jobs, distinct from proving class impossibility, abstract safety analysis, restricting a language, or modeling an oracle.","mechanism_slugs":["enumeration_and_dovetailing","semi_decision_with_explicit_unknown","proof_checking"],"search_questions":["Do engineering synthesis tools distinguish infeasible from not found within budget?","Which enumerative or dovetailed search methods are used in mechanical, circuit, or structural synthesis?","How do users act on UNKNOWN outputs in design-selection workflows?"]},{"hypothesis_id":"H4","title":"Decidable fragment for executable design rules","problem":"A CAD or product-configuration rule language gains recursion and unrestricted extensions while documentation retains a guaranteed-termination claim.","affected_stakeholder":"Design-rule platform owners and downstream configuration engineers","workflow_boundary":"From rule-language change proposal to release of a new rule-set version","failure_mode":"An accepted rule set can diverge, silently invalidating compatibility and configuration checks.","unit_of_analysis":"One rule-language release and its mechanically accepted rule sets","causal_lever":"Define an enforceable syntactic fragment, provide a total evaluator with termination proof, and trigger reclassification whenever expressiveness changes.","archetype_mapping":"Trades expressiveness for a decidable, mechanically policed subclass and version-links the guarantee to its assumptions.","expected_value":"Could preserve predictable rule evaluation and prevent guarantee drift as the language evolves.","falsifiable_claim":"Every accepted program belongs to the stated fragment and terminates under the reference evaluator; one accepted nonmember or nonterminating program falsifies the guarantee.","diversity_rationale":"Uses release-level language governance and admission control, whereas H1 concerns an unrestricted proof boundary and H2–H3 operate on submitted analysis instances.","mechanism_slugs":["language_fragment_restriction","constructive_algorithm_and_correctness_proof","computability_boundary_decision_record"],"search_questions":["Which engineering rule languages enforce decidable or terminating fragments?","What expressiveness losses cause designers to bypass restricted configuration languages?","How are termination guarantees rechecked after language extensions?"]},{"hypothesis_id":"H5","title":"Oracle-aware routing for multidisciplinary optimization","problem":"A multidisciplinary optimizer treats vendor simulation, laboratory measurement, or expert judgment as an always-available deterministic subroutine.","affected_stakeholder":"Systems engineers and program design-review boards","workflow_boundary":"From candidate-design evaluation request to optimization verdict at a design gate","failure_mode":"Oracle delay, refusal, inconsistency, or failure is converted into infeasible or optimal, laundering missing information into a definitive result.","unit_of_analysis":"One candidate evaluation requiring an external capability","causal_lever":"Declare the oracle contract and input promise, route unavailable or violated cases to labeled escalation, and record triggers that invalidate the guarantee.","archetype_mapping":"Makes solvability relative to an explicit external capability rather than treating human or vendor input as magical computation.","expected_value":"Could prevent false optimization verdicts and expose where schedule, competence, or data availability limits the guarantee.","falsifiable_claim":"During shadow operation, no oracle failure or promise violation yields an unqualified feasible, infeasible, or optimal verdict; any such verdict falsifies the routing contract.","diversity_rationale":"Changes the computation model around an external dependency and measures routing behavior, unlike the internally computed proofs, abstractions, searches, and language restrictions in H1–H4.","mechanism_slugs":["promise_problem_restriction","fallback_mode_router","computability_boundary_decision_record"],"search_questions":["How do multidisciplinary design optimizers specify failures of external simulations, experiments, or human evaluations?","Are promise conditions mechanically checked before engineering optimization calls?","What fallback labels prevent unavailable evidence from becoming a false feasibility verdict?"]}]}