{"schema_version":1,"experiment_id":"eoa_inverse_innovation_exp05_complete_proposal_portfolio20_20260803","cell_id":"computability_boundary_mapping__human_computer_interaction","arm":"COMPLETE_PROPOSAL_PORTFOLIO","candidate_id":"cbm_hci_protected_action_boundary_001","proposal_index":1,"version":0,"title":"Guarantee-Labeled Verification for Extensible Protected-Action Interfaces","problem":"A design-system team proposes a release checker that must always terminate and decide, for every interface extension written in an unrestricted executable plugin language, whether the extension can ever perform a protected action without the required interaction sequence: presentation of a declared confirmation view, availability of a cancel transition, and issuance of an undo token. The requirement silently quantifies over arbitrary program behavior and unbounded event sequences. Tests, timeouts, and manual reviews cannot establish that universal guarantee; under an unbounded program-semantics model, a plugin can simulate an arbitrary computation and enter the forbidden interaction state exactly when that computation halts. Without an explicit boundary, the checker may report timeout as safe, treat successful test traces as proof, or invoke undecidability too broadly against finite interface fragments that can be checked exactly.","actors":["Design-system maintainers who define the protected-action contract","Interface designers who specify confirmation, cancellation, and undo behavior","Front-end engineers who implement declarative flows and executable extensions","Accessibility and usability reviewers who assess whether represented controls are perceivable and understandable","Release managers who interpret assurance results","Users exposed to irreversible or difficult-to-reverse actions"],"observable_state":"The release pipeline accepts unrestricted executable interface extensions while exposing only a Boolean pass/fail assurance result. Some analyses time out, inspect only finitely many traces, or depend on manual review, yet their outputs do not distinguish exact proof, sound one-sided proof, witnessed violation, bounded non-finding, out-of-scope input, and tool failure. The documentation nevertheless describes the checker as covering every extension and every event sequence.","consequence":"A misleading pass can allow a protected action to occur without the represented confirmation, cancellation, or undo safeguards, while a misleading failure can block a compliant release. Repeated attempts to eliminate every inconclusive result can also consume implementation effort without resolving the unrestricted specification. Manual usability findings may be misrepresented as class-wide program guarantees, and formal results may be misrepresented as proof that users will actually perceive or understand the interface.","affected_objective":"Provide truthful, actionable release assurance for protected-action interaction contracts while preserving the separate human-centered objective of validating that the formalized confirmation, cancellation, and undo elements are perceivable and understandable in use.","intervention":"Create a Protected-Action Assurance Boundary. First, define the analyzed property, plugin encoding, event semantics, resource model, and universal quantifiers. Independently check the proposed halting-problem reduction before classifying the unrestricted executable-plugin question as undecidable under the stated unbounded semantics. Offer an enforceable finite-state declarative interaction fragment whose membership is decided at ingestion and whose protected-action property is checked exactly. For executable extensions, use a reviewed over-approximating abstraction that may prove the forbidden state unreachable; otherwise search for concrete violation traces only to a declared bound and return UNKNOWN when neither proof nor witness is obtained. Route every query to the strongest applicable mode and attach a machine-readable guarantee label. Preserve OUT_OF_SCOPE, UNKNOWN, TOOL_FAILURE, EXACT_SAFE, EXACT_VIOLATION, PROVED_SAFE_BY_OVERAPPROXIMATION, and WITNESSED_VIOLATION as distinct states. Record the boundary, assumptions, evidence links, and recheck triggers. Continue separate accessibility and usability review, explicitly treating it as evidence about semantic fidelity and human experience rather than as a computational oracle.","structural_mapping":[{"archetype_element":"Problem-Class Specification","domain_realization":"The class is every syntactically valid extension in the declared executable plugin language, evaluated over all event sequences under the stated operational semantics; the target property is reachability of a protected-action commit without the required formal interaction tokens."},{"archetype_element":"Instance Representation and Computation Model Contracts","domain_realization":"Each instance contains plugin source, interface-state declarations, event inputs, and the protected-action monitor. The unrestricted classification uses language semantics with unbounded computation; any claim about a fixed physical deployment is recorded separately as finite in principle and subject to complexity analysis."},{"archetype_element":"Constructive and Impossibility Evidence in Parallel","domain_realization":"A reviewed reduction tests the unrestricted impossibility claim, while an enforceable finite-state interaction grammar and its model checker provide a constructive total procedure for a narrower class."},{"archetype_element":"Decidable Subclass Map","domain_realization":"The map identifies the declarative grammar, bounded data domains, permitted transition guards, and prohibited executable escape hatches for which exact finite-state checking applies."},{"archetype_element":"Weaker Honest Fallback","domain_realization":"Executable extensions receive either a sound safe verdict from an over-approximation, a concrete witnessed violation, or an explicit UNKNOWN after bounded search; none inherits the finite fragment's exact total guarantee."},{"archetype_element":"Unknown and Nontermination Policy","domain_realization":"Resource exhaustion and inconclusive abstraction are surfaced as UNKNOWN, malformed or unsupported extensions as OUT_OF_SCOPE, and analyzer malfunction as TOOL_FAILURE; none is converted to safe or violating."},{"archetype_element":"Model Transparency","domain_realization":"Human reviewers validate whether the formal confirmation and undo concepts match users' experience, but they are not represented as deciding arbitrary future program behavior."},{"archetype_element":"Traceable Boundary and Recheck Trigger","domain_realization":"A versioned record links the grammar, semantics, reduction, abstraction review, checker version, shipped labels, and triggers such as new scripting features, changed event semantics, or altered protected-action requirements."}],"mechanism_mapping":[{"mechanism_slug":"halting_problem_reduction","role":"Test the claimed impossibility boundary by mapping a machine/input pair to a plugin that simulates it and enters the forbidden protected-action state exactly if the simulated computation halts.","counterfactual_removal":"Without the reduction, repeated analyzer failure could be mistaken for impossibility, or an informal halting analogy could be applied despite mismatched language semantics and quantifiers."},{"mechanism_slug":"proof_checking","role":"Have an independent reviewer re-derive the reduction, its encoding, answer preservation, and assumptions, and verify that it proves the stated unrestricted theorem rather than a broader claim.","counterfactual_removal":"Without independent checking, a reversed reduction, invalid simulation, or mismatch between the formal property and the interaction contract could acquire unwarranted authority."},{"mechanism_slug":"language_fragment_restriction","role":"Define a mechanically enforceable finite-state interaction grammar in which protected-action behavior has a total exact decision procedure.","counterfactual_removal":"Without an enforceable fragment, the proposal would identify an unrestricted boundary but provide no exact region users can intentionally target."},{"mechanism_slug":"abstract_interpretation_or_model_checking","role":"Model-check the finite fragment exactly and, for executable extensions, analyze a reviewed finite over-approximation so absence of the forbidden state in the abstraction supports a one-directional safe verdict.","counterfactual_removal":"Without this mechanism, executable extensions would have only tests and manual review, and the finite fragment would lack a procedure that realizes its promised guarantee."},{"mechanism_slug":"bounded_domain_exhaustive_search","role":"Enumerate all traces inside an explicit event-depth and data bound to find replayable violations or certify only the bounded region.","counterfactual_removal":"Without bounded exhaustive search, inconclusive executable cases would lose a terminating way to obtain concrete evidence, while ordinary sampled tests might be mistaken for exhaustive coverage."},{"mechanism_slug":"fallback_mode_router","role":"Dispatch each extension according to enforceable fragment membership and applicable evidence, then emit the strongest justified guarantee label without upgrading UNKNOWN or bounded evidence.","counterfactual_removal":"Without routing and labeling, exact, one-sided, bounded, and failed analyses could collapse back into the misleading Boolean interface that created the problem."},{"mechanism_slug":"computability_boundary_decision_record","role":"Version the chosen boundary, shipped guarantees, evidence, assumptions, and recheck triggers alongside the checker and interaction grammar.","counterfactual_removal":"Without the record, later language or policy changes could silently invalidate the boundary while old assurance language remains in use."},{"mechanism_slug":"computational_complexity_analysis","role":"After establishing that the finite fragment is decidable, assess state growth and resource requirements separately before making operational latency commitments.","counterfactual_removal":"Without the follow-on gate, in-principle decidability could be misreported as practical feasibility for large finite interface models."}],"causal_chain":["An unrestricted executable interface language can express plugins with unbounded computation and event-dependent behavior.","The requested checker quantifies over every valid plugin and every possible event sequence while requiring an exact answer and guaranteed termination.","A property-preserving reduction can encode a computation so that the plugin reaches the forbidden protected-action state exactly when that computation halts.","If independently validated under the declared semantics, the reduction rules out a total exact checker for that unrestricted class, but not for restricted or physically bounded classes.","A syntactically enforceable finite-state interaction fragment removes unbounded executable behavior and makes fragment membership decidable.","Exact model checking then decides the protected-action reachability property for every accepted fragment instance, subject to the formal property faithfully representing the intended interaction contract.","Executable extensions are instead analyzed through a reviewed over-approximation and bounded trace search, producing only sound safe proofs, concrete violation witnesses, or explicit inconclusive states.","The fallback router preserves these distinctions in machine-readable and human-readable outputs, preventing timeouts and bounded non-findings from becoming Boolean verdicts.","The boundary record ties each output guarantee to its model and causes language, semantics, abstraction, or policy changes to trigger reclassification.","Separate human review tests whether the formal interaction elements are meaningful and perceivable to users without being treated as proof over all program executions."],"baseline":"A Boolean release check combines syntactic lint rules, a finite automated test suite, time-limited execution, and manual design review. Passing observed cases is treated as evidence of universal safety, while timeout handling is left to pipeline defaults. The executable plugin language, event model, quantifiers, and role of human judgment are not part of a versioned guarantee contract.","nearest_rivals":["Conventional design-system linting and scenario tests: easier to operate and useful for known patterns, but passing finite checks does not establish the requested class-wide semantic guarantee.","A manually authored finite-state model checked independently of the implementation: can provide exact results about the model, but lacks the proposed enforceable link between accepted interface syntax, executable behavior, and the guarantee label.","Mandatory expert release review: can assess context, accessibility, and experiential meaning, but cannot serve as a total decider for all executions of arbitrary plugins and has explicit latency, competence, and accountability limits.","Rejecting all formal assurance because the plugin language is unrestricted: avoids an overclaim but discards the decidable declarative fragment, sound one-sided proofs, and concrete bounded witnesses."],"remaining_contrastive_claim":"The proposal's contrastive claim is limited to its guarantee architecture: it couples an independently checked boundary for unrestricted executable extensions with an enforceable exact fragment and guarantee-labeled fallback states. Unlike finite testing alone, it never treats non-finding as universal proof; unlike model checking a detached specification, it makes fragment membership an ingestion constraint; unlike blanket rejection, it retains exact, sound one-sided, and witnessed results where their stated preconditions hold. Whether this architecture is usable or semantically faithful remains to be tested.","authority_safety":{"decision_authority":"The design-system release owner retains the release decision, with the formal-methods reviewer authorized only to approve boundary evidence and the accessibility/usability leads authorized only to judge the human-facing adequacy of the represented interaction contract. The analyzer supplies evidence and labels but has no independent production-release authority during the first evidence step.","authorized_first_step":"Run an offline, non-blocking shadow evaluation on one existing protected-action component and a fixed synthetic fixture set. Formalize one protected-action property, define one finite fragment, construct the proposed reduction, and compare exact, abstract, bounded, and failure-state labels without changing production behavior or release criteria.","excluded_actions":["Automatically blocking or approving production releases from pilot results","Converting UNKNOWN, OUT_OF_SCOPE, or TOOL_FAILURE into safe or violating","Claiming that formal satisfaction proves users perceive or understand the confirmation and undo controls","Claiming that a timeout, failed proof search, or absence of a bounded counterexample proves undecidability or safety","Extending the unrestricted impossibility conclusion to the finite fragment, fixed physical deployment, or a changed computation model without a new argument","Accepting executable escape hatches inside the exact fragment without reclassification"],"halt_rollback":"Halt the pilot if the formal monitor does not represent the intended protected-action interaction, the fragment checker can be bypassed, the abstraction's over-approximation obligation cannot be reviewed, a seeded label is misclassified, or downstream tooling collapses distinct statuses. Remove the shadow analyzer from the pipeline, restore the unchanged baseline process, retain the fixtures and audit record, and mark all pilot guarantees withdrawn pending redesign."},"negative_tests":{"strongest_counterevidence":"A checkable constructive algorithm that terminates and correctly decides the protected-action property for every program in the declared unrestricted language under the same unbounded semantics would refute the proposed impossibility classification. Alternatively, evidence that the deployed requirement actually covers only an already enforced finite-state language would show that the unrestricted boundary analysis addresses the wrong class.","problem_falsifier":"The inferred problem is falsified if the release requirement is explicitly instance-bounded or fragment-bounded, all accepted inputs are mechanically confined to that bound, and existing outputs already keep exact, bounded, unknown, out-of-scope, and tool-failure states distinct. In that case the remaining issue would be complexity, implementation quality, or human evaluation rather than a confused computability boundary.","intervention_falsifier":"The intervention fails its central claim if fragment membership is not enforceable, the exact checker does not terminate or is incorrect on a well-formed fragment instance, the abstraction omits a concrete behavior while issuing a safe verdict, a violation witness cannot be replayed, or any routed output is presented with a stronger guarantee than its evidence supports.","risks":["The formal protected-action monitor may omit experiential facts such as whether a confirmation is noticed or understood, producing a correct proof of an inadequate specification.","A coarse abstraction may return UNKNOWN or possible-violation results so frequently that teams bypass it.","An unsound abstraction could produce false confidence; review of the simulation or over-approximation obligation is therefore a release prerequisite for its safe label.","The finite fragment may exclude interaction patterns designers consider necessary, encouraging untracked executable escape hatches.","Finite-state model checking may be decidable but operationally infeasible because of state-space growth.","Release tooling or staff may collapse nuanced labels back into a Boolean decision.","The impossibility result may be overgeneralized from unbounded language semantics to fixed physical systems or restricted grammars.","Human reviewers may be implicitly treated as an unlimited oracle despite workload, disagreement, refusal, and accountability constraints."]},"next_evidence_step":"Conduct one bounded offline boundary audit using one archived protected-action component plus a fixed synthetic suite containing: conforming finite-fragment cases, finite-fragment violations, executable cases with replayable violations at several declared depths, cases intended to exceed the bound, malformed inputs, and simulated tool failures. Before running the analyzer, freeze the grammar, event semantics, property monitor, bounds, expected status alphabet, and reduction statement. Require one reviewer who did not author the reduction to check its direction and preservation obligations, and one interaction reviewer to assess whether the monitor represents the intended confirmation/cancel/undo contract. The step supports continuation only if fragment membership is mechanically enforced, seeded exact cases receive correct exact labels, every witnessed violation replays, bound exhaustion remains UNKNOWN, failures remain distinct, and no safe-by-abstraction result lacks a reviewed over-approximation argument. This step estimates neither prevalence nor effect size and authorizes no production decision.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Not assessed in this sealed generation; no prior experiment candidates were consulted.","revision_record":{"parent_version":null,"progress_targets_addressed":["Initial complete proposal with a concrete HCI problem and an explicit class-wide guarantee at issue","Model-relative separation of unrestricted executable plugins, enforceable finite fragments, and fixed bounded deployments","Operational preservation of exact, one-sided, bounded, unknown, out-of-scope, and failure states","Bounded first evidence with authority limits, rollback conditions, and falsifiers"],"conceptual_changes":["Initial version; established protected-action interface verification as the domain realization of computability boundary mapping.","Separated formal execution assurance from accessibility and usability judgments about semantic fidelity."],"operational_changes":["Initial version; specified the fragment gate, analysis modes, status alphabet, decision authority, excluded actions, and halt criteria."],"evidence_changes":["Initial version; defined an offline fixture-based boundary audit and independent checks without using external prior-art evidence."],"claim_changes":["Initial version; limited the claim to the proposed guarantee architecture and made no claim of novelty, prevalence, demand, or effect size."]}}