{"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_automation_completion_contract_005","proposal_index":5,"version":0,"title":"Honest Completion Contracts for End-User Automations","problem":"A no-code interaction builder lets users create automations containing conditions, loops, executable steps, and calls to external services. Its interface is required to decide before every run whether the automation will finish and to return a definitive success or failure after a fixed wait. The requirement leaves the workflow language, input bounds, external capabilities, and meaning of failure implicit. For an unrestricted executable workflow language, a workflow can simulate an arbitrary computation, so a total exact termination predictor would decide whether arbitrary computations halt. A runtime timeout also cannot distinguish nontermination from slow computation, an unavailable service, a request awaiting human action, or a platform failure. Treating all of these as failure encourages unsafe retries and misrepresents what the system knows.","actors":["People authoring automations through a no-code interface","People monitoring, pausing, resuming, or cancelling automation runs","Interaction designers responsible for progress and status feedback","Workflow-platform engineers implementing the language and runtime","Owners of external services or approval steps invoked by workflows","Operations and governance staff setting execution and side-effect policies"],"observable_state":"The builder accepts unbounded loops or executable extensions while presenting a Run control, progress indicator, and preflight result that imply every workflow can be classified as completing or noncompleting. At a time limit, the interface reports failed or not completable without distinguishing budget exhaustion, external waiting, user input, cancellation, nontermination, and tool failure. Retrying may repeat already committed effects because the visible status is not linked to a checkpoint or side-effect ledger.","consequence":"Users may wait without actionable status, abandon a computation that remains unresolved, or rerun a suspended workflow as though nothing occurred. Re-execution can duplicate messages, submissions, or other effects. Platform teams may continue investing in an unrestricted termination predictor, silently narrow the accepted language, or present a bounded runtime policy as proof that workflows outside its guaranteed fragment do not terminate.","affected_objective":"Provide predictable user control and truthful completion status for end-user automation while preserving a useful distinction between proved completion, observed completion, bounded suspension, external waiting, cancellation, and system failure.","intervention":"Replace the universal preflight promise with a Completion Contract and checkpointed execution protocol. Define the workflow encoding, runtime semantics, input assumptions, side effects, and external capabilities. Independently check a halting-based reduction before classifying unrestricted preflight termination as unavailable under the declared unbounded model. Offer an enforceable guaranteed-completion fragment whose loops range over frozen finite collections or carry mechanically checked decreasing measures, whose local steps terminate, and whose external waits have declared bounds or are excluded. For this fragment, ship a constructive termination argument and separately assess completion cost. Route all other workflows to budgeted execution: run for a declared step or resource allowance, return COMPLETED_OBSERVED only when the run finishes, and otherwise checkpoint the state and return SUSPENDED_BUDGET rather than failed or nonterminating. Represent WAITING_EXTERNAL, USER_ACTION_REQUIRED, CANCELLED, OUT_OF_SCOPE, and TOOL_FAILURE separately. Mediate effects through a commit ledger and idempotency contract so resumption does not silently repeat a completed effect. Give the author explicit resume, cancel, inspect, and revise controls, and version the completion boundary and its recheck triggers.","structural_mapping":[{"archetype_element":"Problem-Class Specification","domain_realization":"The unrestricted class contains every workflow expressible in the no-code platform, including executable steps, loops, conditionals, mutable state, and declared external calls; the class-wide question asks whether each workflow terminates for every covered input."},{"archetype_element":"Instance Representation Contract","domain_realization":"Each instance specifies the workflow graph or program, initial state, input domains, loop bounds or measures, side-effect operations, external calls, resource budget, and runtime version."},{"archetype_element":"Computation Model Contract","domain_realization":"The contract separates unbounded executable semantics, an enforceable structurally terminating fragment, finite resource-bounded execution, and computation relative to fallible services or human approvals."},{"archetype_element":"Solvability Guarantee Profile","domain_realization":"GUARANTEED_COMPLETE applies only to workflows admitted by the checked fragment; COMPLETED_OBSERVED describes a finished unrestricted run; SUSPENDED_BUDGET records unresolved completion after a bounded run."},{"archetype_element":"Computability Impossibility Certificate","domain_realization":"A reviewed construction maps a machine and input to a workflow that finishes exactly when the simulated computation halts, testing the unrestricted termination-predictor claim."},{"archetype_element":"Decidable Subclass Map","domain_realization":"The map identifies acyclic workflows, bounded iteration over frozen finite collections, and loops with checked decreasing measures, while excluding unbounded executable escape hatches from the guaranteed mode."},{"archetype_element":"Termination Condition","domain_realization":"Guaranteed workflows terminate by their structural proof; unrestricted runtime requests terminate operationally at a resource bound by returning a checkpointed suspension rather than a fabricated semantic verdict."},{"archetype_element":"One-Sided Recognition Contract","domain_realization":"Actual completion is a positive witness that a particular workflow run halts, while failure to finish within the resource allowance supplies no claim that the run would never halt."},{"archetype_element":"Model Transparency","domain_realization":"External services and people are named capabilities with latency, refusal, authorization, and failure conditions, not assumed instantaneous subroutines."},{"archetype_element":"Unknown and Nontermination Policy","domain_realization":"Budget suspension, external waiting, required user action, cancellation, platform failure, and proved fragment completion remain distinct in storage, APIs, and the user interface."},{"archetype_element":"Computability Guarantee Record","domain_realization":"A supersedable record links each completion label to the workflow-language version, proof rules, resource model, checkpoint format, side-effect contract, and changes requiring reclassification."}],"mechanism_mapping":[{"mechanism_slug":"halting_problem_reduction","role":"Test the unrestricted impossibility boundary by constructing a workflow that completes if and only if an embedded arbitrary computation halts.","counterfactual_removal":"Without the reduction, repeated predictor failure could be mistaken for impossibility, or a halting analogy could be applied despite mismatched workflow semantics and input quantifiers."},{"mechanism_slug":"proof_checking","role":"Independently review the reduction and the termination arguments accepted for guaranteed workflows, including their assumptions about primitive steps, loop measures, and external calls.","counterfactual_removal":"Without independent checking, a decreasing measure that does not match runtime behavior or an incorrectly scoped reduction could authorize false guarantees."},{"mechanism_slug":"language_fragment_restriction","role":"Define a mechanically enforceable workflow fragment with acyclic composition, bounded collections, or verified well-founded iteration.","counterfactual_removal":"Without an enforceable fragment, the platform could not offer a class-wide completion guarantee without extending it to unrestricted workflows."},{"mechanism_slug":"constructive_algorithm_and_correctness_proof","role":"Provide the fragment evaluator together with a termination proof and an argument that execution preserves the declared workflow semantics.","counterfactual_removal":"Without the constructive procedure and proof, GUARANTEED_COMPLETE would be based on approved syntax alone rather than a demonstrated total evaluator."},{"mechanism_slug":"promise_problem_restriction","role":"Condition guaranteed completion on mechanically checked promises about finite inputs, terminating primitives, frozen collections, and excluded or bounded external waits.","counterfactual_removal":"Without enforced promises, callers could supply an unbounded collection or nonterminating primitive while the interface retained its completion guarantee."},{"mechanism_slug":"semi_decision_with_explicit_unknown","role":"Treat an observed finish as confirmation for an unrestricted run and return SUSPENDED_BUDGET when its declared allowance is exhausted, never WILL_NOT_COMPLETE.","counterfactual_removal":"Without explicit suspension, the runtime bound would become a false negative termination verdict."},{"mechanism_slug":"fallback_mode_router","role":"Route workflows to guaranteed-fragment execution, unrestricted checkpointed execution, external waiting, user-action handling, cancellation, or failure recovery with distinct labels.","counterfactual_removal":"Without routing, semantic completion status and operational runtime status would collapse into a misleading success/failure Boolean."},{"mechanism_slug":"computational_complexity_analysis","role":"Assess how guaranteed workflows' time, memory, and external-call counts grow with bounded inputs before making responsiveness commitments.","counterfactual_removal":"Without the complexity gate, a provably terminating workflow could still be presented as suitable for interactive execution despite impractical cost."},{"mechanism_slug":"computability_boundary_decision_record","role":"Version the guaranteed fragment, proof obligations, fallback statuses, resource budgets, checkpoint semantics, side-effect guarantees, and recheck triggers.","counterfactual_removal":"Without the record, new primitives or changed retry semantics could invalidate completion and resumption guarantees while old interface language remains."}],"causal_chain":["The no-code language gains loops, executable steps, mutable state, or external calls so users can express open-ended automations.","The interface nevertheless promises an exact and terminating preflight completion answer for every accepted workflow and input.","Under unrestricted semantics, a workflow can simulate an arbitrary computation and finish precisely when that computation halts.","A checked reduction therefore blocks the universal termination predictor without implying that every useful workflow is unclassifiable.","An enforceable structurally terminating fragment supplies a constructive class-wide completion guarantee under explicit input and primitive-step promises.","Complexity analysis separately determines whether a guaranteed workflow is operationally suitable for interactive execution.","Unrestricted workflows run only for a declared allowance; observed completion confirms the instance, while exhaustion creates a checkpointed SUSPENDED_BUDGET state.","External waiting, user action, cancellation, and platform failure are routed independently so none masquerades as nontermination.","A commit ledger links completed side effects to the checkpoint, allowing an authorized resume without silently replaying them.","Visible resume, cancel, inspect, and revise controls convert the computability boundary into an honest interaction lifecycle rather than an indefinite spinner or false failure."],"baseline":"The builder performs syntactic linting and sample runs, then launches workflows under a wall-clock timeout. Completion returns success; reaching the timeout returns failed or not completable. External waits and platform errors use the same status, checkpoints are optional, and retry behavior is not tied to a visible side-effect record. Tests and observed runs are treated as evidence that accepted workflows generally finish.","nearest_rivals":["A larger timeout: allows more workflows to finish but still cannot turn bounded noncompletion into proof of nontermination and lengthens unresolved waiting.","A static loop linter: can reject recognizable risky patterns but does not establish totality for an unrestricted executable language or classify external waiting.","A sandbox with a kill switch: contains resource use but supplies no semantic distinction between suspended computation, failure, cancellation, and nontermination.","An acyclic-only workflow builder: offers a simple termination boundary but may exclude bounded iteration that can carry a constructive guarantee and does not address already-supported executable workflows.","Manual administrator approval: can inspect intent and operational risk but cannot act as a uniform total termination decider and has explicit latency and accountability limits.","Automatic retries after failure: may recover transient faults but can repeat completed effects when failure, suspension, and external waiting are not distinguished."],"remaining_contrastive_claim":"The proposal's contrastive claim is limited to its completion contract: it confines class-wide termination guarantees to an enforceable proven fragment and converts unrestricted execution into a total user-facing protocol through bounded suspension, checkpoints, and distinct external or failure states. It does not claim that every guaranteed workflow is fast, that every suspended workflow will eventually finish, or that checkpointing makes arbitrary external effects reversible.","authority_safety":{"decision_authority":"The workflow author retains authority to resume, cancel, or revise a suspended run. Platform operations sets maximum resource budgets, application owners authorize available primitives, and external service or approval owners retain control over their actions. Only the platform release owner, after independent proof review, may mark a fragment version GUARANTEED_COMPLETE. The pilot runtime cannot execute production effects.","authorized_first_step":"Run an offline, side-effect-free evaluation using a fixed synthetic workflow suite and mocked external capabilities. Freeze the workflow grammar, primitive-step semantics, input promises, proof rules, resource allowances, status alphabet, checkpoint format, and mock-effect idempotency contract before execution.","excluded_actions":["Executing production side effects or contacting real external services during the first evidence step","Returning WILL_NOT_COMPLETE from a timeout, step bound, missing proof, or failed search","Marking a workflow GUARANTEED_COMPLETE when it uses an unchecked primitive, unbounded input, or executable escape hatch","Automatically resuming or retrying a suspended workflow without the author's authorization","Collapsing WAITING_EXTERNAL, USER_ACTION_REQUIRED, CANCELLED, SUSPENDED_BUDGET, and TOOL_FAILURE into failed","Claiming a completion proof establishes acceptable latency or resource consumption","Claiming a checkpoint can reverse an external effect that lacks a verified compensation or idempotency contract","Silently narrowing the workflow language while preserving an unrestricted completion claim"],"halt_rollback":"Halt the pilot if a guaranteed-fragment fixture fails to terminate under its frozen promises, an unrestricted run exceeds its allowance without returning SUSPENDED_BUDGET, a checkpoint cannot resume consistently, a mocked committed effect is duplicated, an external wait is labeled as computation failure, or the interface collapses distinct statuses. Disable the pilot runner, restore the unchanged baseline test harness, retain the fixtures and audit record, and withdraw the affected guarantee until the fragment or execution contract is corrected."},"negative_tests":{"strongest_counterevidence":"A mechanically checked constructive procedure that always terminates and correctly decides termination for every workflow in the same unrestricted executable model would refute the proposed boundary. Evidence that the accepted language is already mechanically finite, acyclic, and composed only of total primitives would instead show that unrestricted termination is not the operative question and that complexity assessment is sufficient.","problem_falsifier":"The inferred problem is falsified if every accepted workflow is already confined to an enforced terminating fragment, the product makes no claim about unrestricted executable steps, and runtime statuses already distinguish completion, suspension, external waiting, required user action, cancellation, and failure with checkpoint-linked effects.","intervention_falsifier":"The intervention fails if a well-formed guaranteed workflow can violate its termination argument, fragment membership or input promises can be bypassed, an unrestricted timeout becomes a negative semantic verdict, resumption repeats a committed effect contrary to its contract, an external dependency is hidden, or users cannot distinguish suspended from failed.","risks":["The guaranteed fragment may exclude automation patterns users consider necessary.","A proven terminating workflow may still consume unacceptable time, memory, or external-call capacity.","A small budget may overproduce SUSPENDED_BUDGET and make unrestricted execution cumbersome.","Users may interpret suspension as a promise that eventual completion is merely delayed.","Checkpoint contents may expose sensitive workflow state or credentials.","External state can change between suspension and resumption, invalidating prior assumptions.","Some external effects cannot be made idempotent or compensated after partial completion.","A proof rule may match the workflow syntax but not the actual runtime implementation.","Frequent status distinctions may confuse users unless their controls and consequences are tested." ]},"next_evidence_step":"Construct a frozen offline suite containing acyclic guaranteed workflows; bounded nested loops over empty, typical, and maximum collections; loops with valid and invalid decreasing measures; unchecked executable primitives; unrestricted workflows that complete before and after the first budget; an infinite loop; mocked external waits, user-input pauses, cancellation, and tool crashes; stale checkpoints; and mocked side effects followed by suspension and resumption. Independently check the unrestricted reduction and the fragment evaluator's termination argument. Continue only if every admitted guaranteed fixture terminates under its promises, rejected fixtures cannot acquire the guarantee, observed unrestricted completion is labeled COMPLETED_OBSERVED, every bound exhaustion becomes SUSPENDED_BUDGET, external and failure states remain distinct, checkpoints resume consistently, and no mocked committed effect is duplicated. This bounded step tests status and execution semantics only and estimates neither prevalence nor effect size.","prior_art_status":"UNSEARCHED","diversity_from_prior_proposals":"Proposal 1 addressed release-time verification of whether an extensible interface could ever reach a forbidden protected-action state. Proposal 5 instead governs the runtime completion lifecycle of user-authored automations; its intervention is a proven terminating authoring fragment plus checkpointed bounded execution, user resume or cancel controls, and a side-effect ledger. It neither certifies protected-action safety nor depends on Proposal 1. Proposal 2 addressed whether a user could reach a desired workspace goal and returned a task plan, exact closed-world unreachability, or conditional help. Proposal 5 does not search for a plan: the user has already authored the workflow, and the problem is whether its execution may be guaranteed, observed, suspended, or externally blocked. Proposal 3 addressed whole-behavior equivalence between a legacy interface and an accessible replacement at a prototype-to-build decision. Proposal 5 compares no systems and requires no migration or Wizard-of-Oz prototype. Proposal 4 addressed the scope of explanations for adaptive-interface feature influence, separating trace provenance from global causal claims. Proposal 5 concerns computation completion and recoverable runtime control, not why an adaptive output changed. Its formal predicate, intervention, user action, evidence artifacts, adoption owner, and causal path are distinct from all four earlier proposals.","revision_record":{"parent_version":null,"progress_targets_addressed":["Created a fifth independently adoptable opportunity for the same archetype-domain cell","Selected end-user automation termination and runtime control rather than safety verification, task reachability, migration equivalence, or adaptive explanation","Specified a proven fragment, checkpointed fallback protocol, status semantics, side-effect safeguards, authority, falsifiers, risks, and bounded evidence","Explicitly contrasted the candidate with all four earlier sealed proposals"],"conceptual_changes":["Initial version; realized computability boundary mapping as an honest completion contract for end-user-programmed workflows.","Separated class-wide guaranteed completion, observed instance completion, bounded suspension, external waiting, cancellation, and platform failure."],"operational_changes":["Initial version; defined the terminating fragment, promise checks, budgeted runner, checkpoint and side-effect ledger, user controls, decision authority, exclusions, and rollback conditions."],"evidence_changes":["Initial version; defined a side-effect-free fixture evaluation covering valid and invalid termination proofs, resource suspension, checkpoint resumption, external waits, failures, and idempotent mock effects."],"claim_changes":["Initial version; limited the claim to guarantee-preserving execution status and control and made no claim of novelty, prevalence, demand, or effect size."]}}