{"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_task_feasibility_broker_002","proposal_index":2,"version":0,"title":"Evidence-Carrying Task Feasibility Broker for Interactive Help","problem":"A cross-application help assistant is required to answer every formalized user question of the form “Can I complete goal G from the current workspace state, and if so, how?” Its action model includes executable automations, conditional interface behavior, and steps performed by collaborators or support staff. The requirement leaves open whether the environment is finite and closed, whether an action simulation must terminate, and what powers external actors contribute. For an unrestricted executable workflow model, universal exact and terminating reachability is unavailable: a workflow can simulate an arbitrary computation and expose the goal state exactly when that computation halts. A search can therefore confirm feasibility by finding a replayable path, but exhaustion of a time budget cannot establish impossibility. Without a boundary, the assistant may call a timeout “impossible,” present a path conditional on another person as locally executable, or treat a human support agent as an infallible oracle.","actors":["People seeking contextual help while operating one or more applications","Help-experience designers who define goal and status presentations","Application owners who publish available actions and state predicates","Workflow and automation engineers who expose executable operations","Collaborators, approvers, and support staff whose actions may be required","Help-operations managers responsible for escalation and assurance policy"],"observable_state":"The assistant accepts a current-state snapshot and a requested goal, searches application actions and automations, and returns a Boolean possible/impossible result or a procedural answer. When an automation fails to terminate, the search space grows beyond its budget, an external approval is unavailable, or the goal cannot be translated into a stable predicate, those distinct states appear as the same negative answer. Returned plans lack a statement of whether they are exact, witnessed only in the model, conditional on an external actor, bounded, stale, or unresolved.","consequence":"A false impossibility verdict can cause a person to abandon or escalate a feasible task, while an overstated feasibility verdict can lead them into an incomplete workflow or leave them waiting on an undeclared dependency. Support capacity can be directed toward tasks that were merely search-inconclusive, and users may attribute responsibility to themselves for a failure caused by an unavailable collaborator, stale model, or nonterminating automation.","affected_objective":"Give users truthful task-feasibility guidance that distinguishes a witnessed route, proven closed-world unreachability, conditional external feasibility, incomplete search, model mismatch, and tool failure without promising universal answers for an unrestricted interactive environment.","intervention":"Introduce a Task Feasibility Contract and evidence-carrying broker. A query enters computation only after its goal is represented as a checkable state predicate; ambiguous requests are returned for clarification rather than classified. The broker then classifies the environment. Under an enforceable finite closed-world promise—finite states and actions, terminating transitions, frozen snapshot, and no undeclared external changes—it runs a total exact reachability procedure and may return EXACT_PLAN or EXACT_UNREACHABLE with a certificate. For open executable workflows, it fairly interleaves candidate action sequences and action simulations; a discovered route returns WITNESSED_PLAN with a replay trace, while a declared resource limit returns UNKNOWN_SEARCH_INCOMPLETE, never impossible. If success depends on a collaborator, support agent, sensor, or service, the result is CONDITIONAL_ON_EXTERNAL_CAPABILITY and names that capability’s latency, refusal, authorization, and failure conditions. OUT_OF_SCOPE_GOAL, STALE_MODEL, and TOOL_FAILURE remain separate. A versioned boundary record states the available modes, promises, evidence, and triggers for reclassification. The broker advises but does not execute actions during initial adoption.","structural_mapping":[{"archetype_element":"Problem-Class Specification","domain_realization":"The analyzed class consists of formal goal-reachability queries over encoded workspace states, application actions, executable automations, and declared external capabilities; natural-language requests without a stable goal predicate remain outside the computational classification."},{"archetype_element":"Instance Representation Contract","domain_realization":"Each instance contains a versioned state snapshot, a machine-checkable goal predicate, available action descriptions, transition semantics, credentials or role constraints, and explicit external dependencies."},{"archetype_element":"Computation Model Contract","domain_realization":"The contract distinguishes finite closed transition systems, unrestricted executable actions with potentially nonterminating simulations, and systems augmented by fallible external actors or services."},{"archetype_element":"Quantifier and Scope Map","domain_realization":"The universal product claim is separated into existential instance reachability, class-wide termination of the help procedure, exact unreachability claims, and results conditional on environmental promises."},{"archetype_element":"Constructive Procedure Witness","domain_realization":"For the promised finite closed-world class, exhaustive graph reachability supplies both a terminating decider and a predecessor trace for reachable goals."},{"archetype_element":"One-Sided Recognition Contract","domain_realization":"For unrestricted executable workflows, fair search confirms a reachable goal when it finds a finite terminating action path but makes no negative claim when it has not found one."},{"archetype_element":"Relative Capability Disclosure","domain_realization":"A collaborator, approver, support agent, sensor, or external service is represented as a named computational dependency with bounded authority and explicit failure modes, not as a magical oracle."},{"archetype_element":"Unknown and Nontermination Policy","domain_realization":"Incomplete search, nonterminating action simulations, model staleness, unformalized goals, and analyzer failure receive distinct statuses rather than being collapsed into impossible."},{"archetype_element":"Complexity Follow-On Gate","domain_realization":"Finite closed-world queries move to state-growth and resource assessment before the broker makes latency commitments; finiteness alone does not imply interactive responsiveness."},{"archetype_element":"Computability Guarantee Record","domain_realization":"A supersedable record links each user-facing status to the model, promise, algorithm, resource bound, external dependencies, and changes that require the query class to be reconsidered."}],"mechanism_mapping":[{"mechanism_slug":"halting_problem_reduction","role":"Test the unrestricted boundary by constructing, from a machine and input, an executable workflow whose goal becomes reachable exactly if the simulated computation halts.","counterfactual_removal":"Without a checked reduction, implementation timeouts could be mistaken for impossibility, or a loose halting analogy could be applied to finite closed workflows where it does not belong."},{"mechanism_slug":"constructive_algorithm_and_correctness_proof","role":"Provide an exact finite-state reachability algorithm with a termination argument based on the finite number of states and a correctness argument for its reachable and unreachable certificates.","counterfactual_removal":"Without the constructive witness, the closed-world promise would identify a supposedly decidable region without demonstrating the procedure that realizes its exact guarantee."},{"mechanism_slug":"promise_problem_restriction","role":"Limit EXACT_UNREACHABLE to queries satisfying mechanically checked promises about finite state, terminating transitions, snapshot stability, and absence of undeclared external changes.","counterfactual_removal":"Without the promise restriction, an exact negative verdict could escape into open workflows where the solver has no totality or completeness guarantee."},{"mechanism_slug":"enumeration_and_dovetailing","role":"Fairly interleave candidate action paths and potentially nonterminating action simulations so that one stuck automation cannot starve every later candidate.","counterfactual_removal":"Without dovetailing, a feasible path could remain undiscovered because the search committed indefinitely to an earlier nonterminating candidate."},{"mechanism_slug":"semi_decision_with_explicit_unknown","role":"Return a replayable WITNESSED_PLAN upon confirmation and UNKNOWN_SEARCH_INCOMPLETE at the declared bound, with no unqualified negative output in the open-workflow mode.","counterfactual_removal":"Without the explicit unknown protocol, time or depth exhaustion would tend to become a fabricated impossibility verdict."},{"mechanism_slug":"turing_reduction_analysis","role":"Classify feasibility relative to named external capabilities such as an approver or support service, including what the base system can decide with that capability and how its refusal or unavailability changes the result.","counterfactual_removal":"Without relative analysis, human and service dependencies would be hidden inside a plan and treated as free, instantaneous, reliable computational power."},{"mechanism_slug":"fallback_mode_router","role":"Route each query to exact closed-world decision, one-sided witnessed search, external-capability conditioning, clarification, or failure handling and attach the corresponding guarantee label.","counterfactual_removal":"Without a router, evidence from incompatible modes could collapse into the same possible/impossible interface."},{"mechanism_slug":"computational_complexity_analysis","role":"Assess state-space and search-cost growth after a finite query is shown decidable, separating exact solvability from responsiveness in an interactive help setting.","counterfactual_removal":"Without this gate, a terminating but prohibitively large state search could be presented as suitable for live assistance."},{"mechanism_slug":"computability_boundary_decision_record","role":"Record the query classes, promises, external capabilities, algorithms, labels, and recheck triggers alongside each deployed help-model version.","counterfactual_removal":"Without the record, added automations, applications, or collaborator roles could invalidate earlier guarantees while their user-facing language remains unchanged."}],"causal_chain":["A user asks whether a formal goal is reachable from a represented workspace state.","The help assistant's action model may include arbitrary executable automations and unbounded sequences rather than a finite closed transition graph.","A workflow can be constructed so that reaching the requested goal depends on whether an embedded arbitrary computation halts.","If the reduction is valid under the declared semantics, no total exact procedure can decide every unrestricted workflow-reachability query.","Reachability nevertheless has a useful one-sided property: a finite terminating route, when found, can be replayed and checked as a positive witness.","Fair enumeration prevents one nonterminating candidate action from blocking the discovery of every other finite route.","A resource bound converts the open search into an always-terminating service, but bound exhaustion is labeled UNKNOWN_SEARCH_INCOMPLETE rather than impossible.","Queries satisfying the enforceable finite closed-world promise are routed to exhaustive reachability, where both positive and negative answers can be exact.","Routes requiring another actor or service are labeled conditional and disclose that capability’s authority and failure modes instead of crediting the local system with the result.","Guarantee labels and a versioned boundary record preserve the distinctions when results enter the help interface and trigger reclassification when the environment changes."],"baseline":"A contextual help assistant retrieves documentation and searches a workflow graph until it finds a path or reaches a time limit. It may ask a support agent when automated search fails, but neither the graph's completeness nor the support agent's computational and operational role is specified. The user sees a plan, an impossibility message, or a generic error without a guarantee label or evidence trace.","nearest_rivals":["Static task documentation and decision trees: provide curated steps for anticipated cases but do not classify reachability from a versioned current state or disclose when missing documentation is being interpreted as impossibility.","A conventional workflow planner with a timeout: may find useful routes but cannot justify a negative verdict for unrestricted executable actions merely because its budget expires.","Process-mining or demonstration-replay help: can present previously observed paths, but absence of an observed path does not prove that no path exists from the current state.","A human help desk: can contribute contextual knowledge and coordinate with other people, but is an external capability with latency, refusal, competence, and authorization limits rather than a total reachability oracle.","An exact model checker over a manually curated workflow model: can decide the model's finite reachability problem but does not by itself enforce the closed-world promise, expose model staleness, or distinguish model reachability from execution in the live collaborative environment."],"remaining_contrastive_claim":"The proposal is limited to a guarantee-preserving help architecture: exact negative answers are confined to an enforceable finite closed world, open executable workflows yield positive witnesses or explicit unknowns, and external actors are exposed as conditional capabilities. Its advantage over timeout-based planning is status honesty, over static help is state-relative evidence, and over a detached finite model is an explicit promise and staleness contract. It does not claim that a witnessed route will be desirable to the user or remain executable after the represented state changes.","authority_safety":{"decision_authority":"The user retains authority to decide whether to attempt a suggested path. Application owners determine which actions may be represented, external actors retain authority to accept or refuse requested steps, and the help-operations owner may approve only the pilot's labeling policy. The broker has no authority to execute actions, contact collaborators, change permissions, or certify live task completion during the first evidence step.","authorized_first_step":"Run an offline, non-executing shadow evaluation for one documented multi-step workflow family using frozen synthetic state models and one archived, de-identified workflow snapshot. Freeze the goal predicates, action semantics, finite-world promises, external-capability contracts, search bound, and status alphabet before evaluation.","excluded_actions":["Executing a suggested application action or changing workspace state","Contacting collaborators, approvers, or support staff automatically","Returning impossible after a timeout, depth limit, nonterminating simulation, missing permission, or unavailable external actor","Issuing EXACT_UNREACHABLE unless every closed-world promise has been mechanically checked","Treating a natural-language request as a formal goal when material ambiguity remains","Presenting model reachability as proof that the route is socially appropriate, authorized, accessible, or still executable in the live environment","Hiding credentials, approvals, sensors, people, or services on which a route depends","Using pilot outputs to deny support or allocate responsibility for task failure"],"halt_rollback":"Halt the pilot if an exact negative is emitted outside the promised finite class, a witnessed plan cannot be replayed in its frozen model, dovetailing starves a seeded feasible path, an external dependency is omitted, a stale snapshot receives an unqualified result, or the interface collapses distinct statuses. Remove the shadow broker from the help workflow, restore the unchanged baseline, preserve fixtures and audit logs, and withdraw all pilot guarantees until the model or routing contract is corrected."},"negative_tests":{"strongest_counterevidence":"A mechanically checked constructive procedure that always terminates and correctly decides reachability for every workflow in the same unrestricted executable model would refute the proposed computability boundary. Evidence that every intended query is already confined by enforceable finite-state, terminating, snapshot-stable constraints would instead show that the unrestricted classification addresses the wrong problem and that only complexity assessment is needed.","problem_falsifier":"The inferred problem is falsified if the help system makes no feasibility or impossibility claim, merely retrieves potentially relevant instructions, or if all accepted queries already satisfy an enforced finite closed-world contract and retain separate unknown, stale, out-of-scope, and failure states.","intervention_falsifier":"The intervention is falsified if the finite promise cannot be mechanically checked, the exact algorithm misclassifies a well-formed finite fixture, fair search fails to discover a seeded finite witness within a sufficient declared schedule, a returned witness cannot be replayed under the frozen model, an external dependency is represented as locally controllable, or any incomplete status is presented as an exact negative.","risks":["The formal goal predicate may misrepresent what the user actually wants; ambiguous goals must return to clarification before computability analysis.","A path valid in the model may be inaccessible, unauthorized, socially inappropriate, or undesirable in practice.","Workspace state can change after snapshot capture, invalidating an otherwise correct route.","Finite closed-world state spaces may be too large for interactive response despite being decidable.","An incorrect fairness implementation may starve feasible candidates.","External actors and services may refuse, delay, change state, or provide erroneous information.","Replay traces may expose sensitive workflow structure or permission information.","Users or downstream systems may read UNKNOWN_SEARCH_INCOMPLETE as a euphemism for impossible.","An exact unreachable certificate about a model may be overgeneralized to the live environment." ]},"next_evidence_step":"Build a fixed offline fixture suite for one workflow family containing finite reachable and unreachable models, open executable models with early and late terminating witnesses, at least one nonterminating candidate that precedes a feasible path, bound-exhaustion cases, stale snapshots, unformalized goals, missing permissions, unavailable external actors, and simulated tool failures. Independently check the unrestricted reduction and the finite algorithm's termination and correctness arguments. Run the broker without executing any action. Continue only if every finite fixture is correctly classified under its promise, each WITNESSED_PLAN replays against the frozen model, the nonterminating candidate does not starve the feasible path, bound exhaustion remains UNKNOWN_SEARCH_INCOMPLETE, external dependencies are named, and all stale, out-of-scope, and failure cases remain distinct. This bounded step tests classification and evidence handling only; it estimates neither prevalence nor effect size.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Proposal 1 concerned release-time verification of a universal safety property for extensible protected-action interfaces: whether forbidden commits can ever occur. Its intervention centered on an enforceable declarative interface fragment, exact or abstract safety analysis, and release-assurance labels. This proposal addresses a different problem and causal direction: runtime help for whether a desired task state can be reached across interactive and collaborative workflows. It relies on positive path witnesses, fair semi-decision, a finite closed-world promise for exact negative answers, and explicit modeling of collaborators and services as relative capabilities. It can be adopted as a non-executing help broker without changing interface release verification, while Proposal 1 can be adopted without providing task-feasibility assistance; neither is a feature or implementation step of the other.","revision_record":{"parent_version":null,"progress_targets_addressed":["Created an independently adoptable second opportunity for the same archetype-domain cell","Selected task reachability and interactive help rather than protected-action release verification","Specified actors, state, consequences, boundary evidence, modes, authority, safeguards, falsifiers, risks, and bounded first evidence","Explicitly contrasted the proposal with every earlier sealed proposal"],"conceptual_changes":["Initial version; realized computability boundary mapping as user-facing task-feasibility classification over interactive and collaborative workflows.","Centered existential reachability, one-sided witness discovery, and capability-relative results rather than universal safety verification."],"operational_changes":["Initial version; defined the finite closed-world promise, fair search protocol, evidence-bearing status alphabet, external-capability contract, pilot authority, and rollback conditions."],"evidence_changes":["Initial version; defined an offline fixture evaluation that tests exact classification, dovetailing fairness, witness replay, staleness, dependency disclosure, and status preservation."],"claim_changes":["Initial version; limited the contrastive claim to guarantee-preserving task guidance and made no claim of novelty, prevalence, demand, or effect size."]}}