⌘K
ENES
GitHub
indexWASI, Components & WASI-NN#wasi#component-model#wit#wasi-nn#portability

WASI, Components & WASI-NN

Introduction and mental model

A core WebAssembly module provides portable computation. A component adds a typed contract around portable computation. WASI supplies host capabilities through explicit interfaces. Together they let a pipeline cross language and runtime boundaries without pretending the guest owns an operating system.

The central mental model is portable logic plus host-provided capabilities. WIT describes imports and exports; the Canonical ABI transports values across the boundary; the host decides which capabilities exist. WASI-NN applies that pattern to inference: the guest requests a graph, tensors, and an execution context, while the host chooses the actual ML backend and acceleration.

Reference baseline for this branch: WASI 0.3.0, released 2026-06-11 and consulted 2026-07-16. Pinning that release does not imply that every runtime implements every interface. WASI-NN remains a Phase 2 proposal as consulted 2026-07-16; it is not a universal inference API and must not be confused with browser WebNN.

Why it matters

Browser-only packaging cannot provide portability across edge, CLI, embedded, and server-side runtimes. Components offer a way to preserve the deterministic part of an AI pipeline — preprocessing, validation, scoring, or postprocessing — behind a stable, typed interface while allowing different hosts to supply storage, streams, clocks, or inference acceleration.

This separation makes portability testable. A component is portable only across hosts that satisfy its declared world, and an inference path is available only when the host implements the requested WASI-NN encoding and backend.

Questions this branch answers

  • How does a component differ from a core Wasm module?
  • What do WIT packages, worlds, interfaces, resources, imports, and exports describe?
  • What guarantees and copying costs belong to the Canonical ABI?
  • How are components composed and versioned across implementation languages?
  • Which capabilities does a WASI host provide, deny, or virtualize?
  • What changed in the WASI 0.3.0 baseline used by this Atlas?
  • How do WASI-NN graphs, tensors, execution contexts, encodings, and targets fit together?
  • How should a runtime report that WASI-NN or a requested backend is unavailable?

Scope

  • Core modules versus components and the role of adapters.
  • WIT packages, versions, worlds, interfaces, records, variants, results, and resources.
  • Canonical ABI lifting, lowering, ownership, strings, lists, and copying boundaries.
  • Component composition and explicit host imports.
  • WASI 0.3.0 as the pinned study baseline for portable host APIs.
  • WASI-NN graph loading, tensor contracts, execution contexts, encodings, and targets.
  • Runtime capability discovery and explicit unsupported paths.
  • Executing the same typed pipeline in a non-browser WASI runtime and comparing outputs.

Out of scope

  • Treating WASI as POSIX compatibility or granting ambient operating-system access.
  • Claiming that Component Model, WASI 0.3.0, or WASI-NN support is universal.
  • Equating WASI-NN with WebNN: one is a WASI host proposal, the other a Web browser neural-network API.
  • Defining a new ML operator graph API inside WIT.
  • Training models through WASI-NN.
  • Hiding host-selected backends, unsupported model encodings, or portability gaps.

Expected outcomes

After this branch, a reader should be able to design a versioned WIT world for a small AI pipeline, identify every host capability it imports, package the implementation as a component, and run its contract in a declared WASI runtime. They should be able to evaluate WASI-NN as an optional host integration, distinguish specification phase from runtime implementation, and record portable and non-portable assumptions precisely.

Candidate note roadmap

  • core-modules-components-and-adapters — separate binary computation from typed component contracts.
  • wit-packages-worlds-interfaces-and-versioning — model provided and required capabilities explicitly.
  • canonical-abi-lifting-lowering-and-copy-costs — trace values and ownership across component boundaries.
  • component-composition-resources-streams-and-futures — connect stateful and asynchronous interfaces without ambient access.
  • wasi-0-3-release-baseline-and-runtime-matrix — pin the 2026-06-11 release and test actual host coverage.
  • portable-ai-pipeline-contracts-in-wit — define preprocessing, inference-adapter, validation, and scoring boundaries.
  • wasi-nn-graphs-tensors-and-execution-contexts — study the Phase 2 proposal without assuming implementation parity.
  • host-provided-acceleration-and-explicit-fallbacks — expose encoding, backend, target, and unsupported outcomes.

Future runnable artifact

Package a deterministic slice of WasmAI Workbench — preprocessing plus output scoring and verification — as a versioned WebAssembly Component with a WIT world. Execute it under Wasmtime using only declared imports, feed it the same fixture used by the browser pipeline, and compare its output bytes and numerical tolerance with the browser and native golden references.

Add a separate optional WASI-NN adapter only when the selected host reports a supported encoding and backend. The adapter will record runtime, WASI version, proposal/API version, graph encoding, execution target, model checksum, and fallback reason. A host without WASI-NN must skip that path cleanly while the deterministic component remains testable.

How to verify and measure

  • Validate the component and WIT package, then enumerate every required import and provided export.
  • Run contract tests that cover records, variants, errors, resources, and ownership across the Canonical ABI.
  • Compare output checksums and numerical differences against the same golden fixture used in the browser.
  • Record instantiation time, first call, warm p50/p95, peak memory, component size, and boundary-copy bytes.
  • Run the declared runtime capability matrix; mark missing interfaces as unsupported, not failed inference.
  • For WASI-NN, record proposal phase, runtime implementation, model encoding, target, backend, and exact failure or fallback.
  • Confirm the component has no filesystem, network, clock, random, or secret access unless its WIT world imports it.

Primary sources

  • WebAssembly/WASI repository — authoritative WASI proposals, specifications, and release history; baseline pinned to 0.3.0 released 2026-06-11, consulted 2026-07-16.
  • WASI 0.3.0 release — exact release baseline for this branch; runtime coverage must be measured independently.
  • WebAssembly Component Model specification repository — primary specification and design history; evolving standardization work, consulted 2026-07-16.
  • Component Model documentation — Bytecode Alliance implementation-oriented guide to components, composition, and language tooling; version-sensitive, consulted 2026-07-16.
  • WIT reference — authoritative guide to WIT packages, worlds, interfaces, and types; consulted 2026-07-16.
  • WebAssembly/wasi-nn proposal — primary WASI-NN proposal; Phase 2 as consulted 2026-07-16, with no claim of universal runtime or backend support.
  • Wasmtime documentation — official runtime reference for components and WASI execution; implementation behavior is version-sensitive, consulted 2026-07-16.

Connects to: WebAssembly Execution Model · Toolchains & Language Targets · Linear Memory, ABI & Host Interop · Model Formats, Conversion & Quantization · Sandboxed AI Tools & Plugins · Wasm AI Performance, Security & Craftsmanship