bytecodealliance · ricochet · Jun 12, 2026 · Apr 17, 2026 · Jun 10, 2026 · Jun 10, 2026
diff --git a/docs/contribute.md b/docs/contribute.md
@@ -1,6 +1,6 @@
 ---
 title: "Contribute"
-sidebar_position: 4
+sidebar_position: 6
 ---
 
 This site is a community effort supported by volunteers through the Bytecode Alliance's Special Interest Group for Documentation. 

diff --git a/docs/interfaces.md b/docs/interfaces.md
diff --git a/docs/introduction.md b/docs/introduction.md
@@ -4,26 +4,30 @@ slug: /
 sidebar_position: 1
 ---
 
-The **WebAssembly System Interface (WASI)** is a group of standards-track API specifications for software compiled to the **[W3C WebAssembly (Wasm) standard](https://www.w3.org/TR/wasm-core-2/)**. WASI is designed to provide a secure standard interface for applications that can be compiled to Wasm from any language, and that may run anywhere&mdash;from browsers to clouds to embedded devices.
+The **WebAssembly System Interface (WASI)** is a group of standards-track API specifications for software compiled to the **[W3C WebAssembly (Wasm) standard](https://www.w3.org/TR/wasm-core-2/)**. WASI is designed to provide a secure standard interface for applications that can be compiled to Wasm from any language, and that may run anywhere, from browsers to clouds to embedded devices.
 
-By standardizing APIs for WebAssembly, WASI provides a way to compose software written in different languages&mdash;without costly and clunky interface systems like HTTP-based microservices. We believe that every project with a plugin model should be using WASI, and that WASI is ideally suited for projects with SDKs for multiple languages, e.g. client libraries.
+By standardizing APIs for WebAssembly, WASI provides a way to compose software written in different languages without costly and clunky interface systems like HTTP-based microservices. We believe that every project with a plugin model should be using WASI, and that WASI is ideally suited for projects with SDKs for multiple languages, e.g. client libraries.
 
-To date, WASI has seen two milestone releases known as **0.1** and **0.2**. (Sometimes you will see these referred to as Preview 1 and Preview 2, or P1 and P2). The concepts and vocabulary of Wasm and WASI can sometimes be opaque to newcomers, so WASI.dev serves as an introduction to WASI for users of all backgrounds. It's very much a work-in-progress, and we welcome contributions on the [GitHub repo](https://github.com/bytecodealliance/wasi.dev). 
+To date, WASI has seen three milestone releases known as **P1**, **P2**, and **P3**. (Sometimes you will see these referred to as Preview 1/2/3 or 0.1/0.2/0.3.) WASI P3 adds native async support to the Component Model and refactors WASI interfaces to take advantage of async primitives like `stream<T>` and `future<T>`. For more details, see [WASI P3](releases/wasi-p3.md). 
 
 ## Who are we?
 
 WASI is an open standard under active development by the [**WASI Subgroup**](https://github.com/WebAssembly/WASI/blob/main/Charter.md) in the **W3C WebAssembly Community Group**. Discussions happen in [GitHub issues](https://github.com/WebAssembly/WASI/issues), [pull requests](https://github.com/WebAssembly/WASI/pulls), and [bi-weekly Zoom meetings](https://github.com/WebAssembly/meetings/tree/main/wasi).
 
 ## Who are you?
 
-WASI and Wasm are tools for any type of software developer: whether you're writing web apps, plugins, serverless functions, User-Defined Functions (UDFs) in a database, embedded controller components, sidecar networking filters, or something completely different. This site is intended to make WASI understandable regardless of your background, use-case, or familiarity with the WebAssembly ecosystem.
+WASI and Wasm are tools for any type of software developer: whether you're writing web apps, plugins, serverless functions, User-Defined Functions (UDFs) in a database, embedded controller components, sidecar networking filters, or something completely different. This site is intended to introduce the concepts and vocabulary of WASI regardless of your background, use-case, or familiarity with the WebAssembly ecosystem.
 
 ## How to get started
 
 There are many different runtimes that support WASI including [Wasmtime](https://wasmtime.dev/), [WAMR](https://bytecodealliance.github.io/wamr.dev/), [WasmEdge](https://wasmedge.org/), [wazero](https://wazero.io/), [Wasmer](https://wasmer.io/), [wasmi](https://github.com/wasmi-labs/wasmi), [wasm3](https://github.com/wasm3/wasm3), [jco](https://github.com/bytecodealliance/jco) and [pywasm](https://github.com/mohanson/pywasm). Many of these runtimes have different areas of focus (i.e., IoT, embedded devices, and edge for WAMR, server-side and non-web embeddings with components for Wasmtime, and running in JS environments and browsers for Jco). The introductory documentation for each is a great place to start.
 
-WASI can be implemented by both core Wasm modules and applications built according to the **Component Model**, a specification for Wasm applications that are interoperable and composable. You can learn more about components in the Bytecode Alliance's **[WebAssembly Component Model](https://component-model.bytecodealliance.org/)** documentation. 
+WASI can be implemented by both core Wasm modules and applications built according to the **Component Model**, a specification for Wasm applications that are interoperable and composable. You can learn more about components in the Bytecode Alliance's **[WebAssembly Component Model](https://component-model.bytecodealliance.org/)** documentation.
 
-[Continue reading](./interfaces.md) to learn more about WASI interfaces, including available APIs and how they are defined. 
+WASI applications run in a **capability-based** sandbox: a Wasm module or component starts with no ambient authority and can only do what the host explicitly grants. See the [Security](./security.md) page for more.
+
+When you're ready to start building, the [Component Model documentation](https://component-model.bytecodealliance.org/) walks through compiling a first component and running it on Wasmtime or jco, with tutorials for Rust, JavaScript, Python, Go, C, C#, and MoonBit.
+
+[Continue reading](./releases/) to learn more about WASI releases, including available APIs and how they are defined. 
 
 
diff --git a/docs/languages.md b/docs/languages.md
@@ -25,10 +25,10 @@ The languages below can be compiled to WebAssembly with WASI support. Some toolc
 
 ### Notes
 
-- **Modules vs components.** A Wasm **module** is a single binary in the core WebAssembly format and can use WASI 0.1. A **component** is built to the Component Model and can use WASI 0.2 or 0.3, gaining composability, cross-language interoperability, and richer interface types. See the [Interfaces](interfaces.md) and [Roadmap](roadmap.md) pages for more on the WASI releases.
+- **Modules vs components.** A Wasm **module** is a single binary in the core WebAssembly format and can use WASI 0.1. A **component** is built to the Component Model and can use WASI 0.2 or 0.3, gaining composability, cross-language interoperability, and richer interface types. See the [Releases](releases/index.md) and [Roadmap](roadmap.md) pages for more on the WASI releases.
 - **Adapting modules to components.** Several toolchains produce core modules today and wrap them into components using [`wasm-tools component new`](https://github.com/bytecodealliance/wasm-tools) with a P1-to-P2 adapter. This is the path for C/C++ and MoonBit.
 - **WASI 0.3 ecosystem state.** Broad language-level P3 support is still landing. The Rust `wasm32-wasip3` target is Tier 3 (nightly only). `jco` ships a `preview3-shim` package with streams support landed and futures support following. Other toolchains have not yet shipped P3 support.
-- **Snapshot pinning.** When working with WASI 0.3, all WIT-aware tools must target the same snapshot (currently `0.3.0-rc-2026-03-15`). Mismatches surface as confusing `wrong type` errors at instantiation.
+- **Version pinning.** The Component Model defines [canonical interface names](https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#-canonical-interface-name) so that components can link across compatible versions, but not all tools support this version-aware linking yet. Until they do, target the same version (`0.3.0`) across all WIT-aware tools. Mismatches surface as confusing `wrong type` errors at instantiation.
 
 ### Building guides
 
@@ -44,7 +44,7 @@ For hands-on guides covering setup and a "hello world" per language, see the Com
 
 ### Bindings generators
 
-The bindings generators below provide a way to make Wasm function calls using [interfaces](interfaces.md) in a given language.
+The bindings generators below provide a way to make Wasm function calls using [interfaces](releases/index.md) in a given language.
 
 | From                 | To                   | Name                                                                                              |
 | -------------------- | -------------------- | ------------------------------------------------------------------------------------------------- |