Every row below is scored against a real crate, package, or blocker document in the repo — not against the roadmap. Where something is blocked, we link the doc that says so.
The default target and the most mature. traverse-runtime gives you full orchestration — NativeExecutor, ThreadPoolExecutor, and a Wasmtime-backed WasmExecutor for sandboxed capability execution. This is what traverse-cli runs on, and what every quickstart walks you through.
Two things are true here, both shipped. First, the runtime core builds for wasm32-unknown-unknown with native adapters excluded — contracts, registry resolution, routing, traces, and events all run in a browser or edge-WASM guest with your own executor behind CapabilityExecutor. Second, and newer: the public Web/TypeScript embedder SDK, shipped in v0.8.0, loads a bundle, digest-verifies every WASM capability, and executes it directly in the browser's native WebAssembly host through a minimal WASI preview1 shim — no nested engine, no server sidecar.
The public traverse-embedder crate implements embedder-api/1.0.0 — init, shutdown, submit, subscribe, and start/stop/kill — against an application-owned bundle, with real execution, a deterministic test double, and a CI-enforced conformance suite shared across every embedder SDK.
The formal certification path is blocked, as of a screen dated July 19, 2026: no candidate WASM engine currently exposes the public, documented resource-control APIs required for a certified native embedder baseline. WasmKit, WAMR, Wasmtime, and Wasmer were all screened and rejected — for missing resource-control APIs, no supported iOS profile, or JIT/entitlement conflicts with App Store distribution. The packages/swift/TraverseEmbedder package has a WasmKitRuntimeBridge implemented, but evidence publication and reference-app integration are explicitly tracked as blocked, not in progress.
Separately, a feasibility spike proved a workaround: embedding the wasmi interpreter directly via a Rust static library and a narrow C-compatible bridge, with the host enforcing memory and fuel limits — verified running on a physical iPhone. That's a real result, but it's a foundation for a future runtime path, not a shipped SDK.
packages/kotlin/TraverseEmbedder has a working ChicoryRuntimeBridge pinned to Chicory 1.7.5. Bundle validation and lifecycle types are in place. Compose reference-app integration is tracked by a separate open issue and hasn't landed yet — no public release.
packages/dotnet/TraverseEmbedder has a working WasmtimeRuntimeBridge pinned to Wasmtime .NET 44.0.0. Request marshalling, event subscriptions, evidence publication, the shared conformance suite, and WinUI reference-app integration remain tracked as open work — no public release.
On the public roadmap as the next executor adapter — same WASM binary, same contract, edge-specific placement. No code has shipped for this yet.
This isn't a "we haven't gotten to it yet" gap — it's an explicit non-goal of the current milestone. The project's own constitution excludes distributed orchestration, edge/cloud placement optimization, and multi-cloud runtime execution from v0.1 by design, to keep the core small and verifiable first.
You may see "AI pipeline" listed as a placement target elsewhere in our own marketing copy. Held to the same standard as this page: the real runtime target matrix has three targets — native, browser/edge core, and the WASI guest capability target capabilities compile to. "AI pipeline" describes how an MCP-connected agent calls into the native or browser target today, not a fourth, separate runtime placement. We're fixing that language sitewide.
Start with whichever embedder README matches your stack, or open an issue if you want to help unblock one of the ones above.