[Pre-proposal] State Continuity Profiles for WebAssembly Components

Problem

The Component Model defines typed interfaces and ownership semantics for resource handles, while WASI defines host capabilities exposed through those interfaces. I could not find a cross-interface contract in the current WASI proposal set for stopping a stateful component in one runtime or host and resuming it in another, for example during recovery, rolling upgrades, node evacuation, or edge relocation.

• A WIT resource handle is scoped to an instantiated component graph. The logical resource it denotes, such as a timer, file cursor, key-value namespace, or request, may or may not be reconstructible elsewhere.
• Authority must be reacquired under destination policy and must not become broader. After a committed handoff, the source must no longer be able to act.
• An effect already issued to the host may have completed, failed, or have an indeterminate outcome. Treating any one of these as the default risks lost or duplicated effects.

Platforms supporting these workflows currently need private, incompatible answers to these questions.

Proposed direction

Define a continuity profile associated with an existing WIT/WASI resource interface. This proposal concerns semantic contracts, not a particular annotation syntax.

For each resource kind and relevant operation, a profile would specify:

• portable logical state, excluding file descriptors, sockets, native pointers, credentials, and runtime-private objects;
• permitted resource dispositions such as revalidate, recreate, reconnect, or reject, with typed failures;
• operation identity, idempotency, replay eligibility, and reconciliation requirements for completed, failed, and indeterminate outcomes; and
• a profile-defined authority compatibility and attenuation rule.

The contract would require source fencing before destination activation. How an orchestrator establishes durable coordination or fencing epochs is outside the profile itself.

Non-goals

This is not a standard snapshot format, a new handle system, transparent preemptive migration, transfer of live native resources, a consensus protocol, or a claim of universal exactly-once effects.

Reference implementation

vISA exercises timer/KV and regular-file profiles across all four source/destination pairings of Wasmtime and a source-locked Wacogo derivative on x86-64 Linux.

The timer/KV profile covers 31 cases, 124 executions, and 31 normalized equality groups. The regular-file profile uses a separate 12-case matrix in all four directions, with three required runs per cell. These results cover two runtime lineages under one shared coordinator, not two independently implemented end-to-end stacks, and they do not yet establish a physical cross-host deployment. A logical-request profile currently has separate Wasmtime-to-Wasmtime evidence and does not inherit either cross-runtime result.

The working discussion document contains the fuller contract, artifact links, and exact evidence boundaries.

Questions

Does this problem belong in WASI as a cross-cutting contract over host-resource interfaces? If so, which existing proposal owners and implementers should be involved? If a generic WIT or Canonical ABI hook is eventually required, which minimal part should instead be raised with the Component Model group?

At this stage I am primarily looking for feedback on the problem boundary, standardization home, and interoperability requirements. The concrete encoding is deliberately left open.

Start with docs/proposals/continuity-profile/README.md at the referenced revision, then review the issue's stated evidence boundaries and non-goals. This is a pre-proposal seeking feedback rather than a defined implementation; progress means reaching agreement on the problem boundary, standardization home, and interoperability requirements.