From 23424f33b396b63740165b6993d301db079c6b2a Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Tue, 15 Jul 2025 16:23:38 -0700
Subject: [PATCH 01/32] Revise and reorganize "Why the Component Model?"
 section

---
 .../src/design/why-component-model.md         | 121 +++++++++++++++++-
 1 file changed, 114 insertions(+), 7 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 4882d797..ced49752 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -1,19 +1,126 @@
 # Why the Component Model?
 
-If you've tried out WebAssembly, you'll be familiar with the concept of a _module_. Roughly speaking, a module corresponds to a single `.wasm` file, with functions, memory, imports and exports, and so on. These "core" modules can run in the browser, or via a separate runtime such as Wasmtime or WAMR. A module is defined by the [WebAssembly Core Specification](https://webassembly.github.io/spec/core/), and if you compile a program written in Rust, C, Go or whatever to WebAssembly, then a core module is what you'll get.
+WebAssembly programs can be written by hand,
+but it's more likely that you will use a compiler to generate your programs.
+In general, a compiler translates programs from a source language
+to a target language.
+Compilers whose target language is WebAssembly may take
+Rust, C, Go, or a variety of other languages as a source language.
+In this case, the compiler produces a WebAssembly _core module_.
+Core modules have some limitations, which components address.
 
-Core modules are, however, limited in how they expose their functionality to the outside world to functions that take and return only a small number of core WebAssembly types (essentially only integers and floating-point numbers). Richer types, such as strings, lists, records (a.k.a. structs), etc. have to be represented in terms of integers and floating point numbers, for example by the use of pointers and offsets. Those representations are often times not interchangeable across languages. For example, a string in C might be represented entirely differently from a string in Rust or in JavaScript.
+## Core modules
 
-For Wasm modules to interoperate, therefore, there needs to be an agreed-upon way for exposing those richer types across module boundaries.
+Typically, a core module defines a set of _functions_
+along with auxiliary definitions
+that are necessary for executing those functions.
+Functions are made up of _instructions_.
+Auxiliary definitions include:
+* _Linear memories_ define untyped buffers that can be read from
+  and written to by instructions.
+* _Imports_ define the names of other modules
+   that are required to be available to execute
+   the functions in the module,
+   along with type signatures for required functions
+   in the imported module.
+* _Exports_ define the names of functions within
+  the module that should be accessible externally.
+* And others; see [the Core Specification](https://webassembly.github.io/spec/core/syntax/modules.html)
+  for the complete list.
 
-In the component model, these type definitions are written in a language called [WIT (Wasm Interface Type)](./wit.md), and the way they translate into bits and bytes is called the [Canonical ABI (Application Binary Interface)](./../advanced/canonical-abi.md). A Wasm [component](./components.md) is thus a wrapper around a core module that specifies its imports and exports using such [Interfaces](./interfaces.md).
+A core module usually corresponds to a single `.wasm` file.
+These modules can be run in the browser,
+or via a separate runtime such as [Wasmtime](https://wasmtime.dev/)
+or [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime).
 
-The agreement of an interface adds a new dimension to Wasm portability. Not only are components portable across architectures and operating systems, but they are now portable across languages. A Go component can communicate directly and safely with a C or Rust component. It need not even know which language another component was written in - it needs only the component interface, expressed in WIT. Additionally, components can be linked into larger graphs, with one component's exports satisfying another's imports.
+A module is defined by the [WebAssembly Core Specification](https://webassembly.github.io/spec/core/).
 
-Combined with Wasm's strong sandboxing, this opens the door to yet further benefits. By expressing higher-level semantics than integers and floats, it becomes possible to statically analyse and reason about a component's behaviour - to enforce and guarantee properties just by looking at the surface of the component. The relationships within a graph of components can be analysed, for example to verify that a component containing business logic has no access to a component containing personally identifiable information.
+### Limitations of core modules
 
-Moreover, a component interacts with a runtime or other components _only_ by calling its imports and having its exports called. Specifically, unlike core modules, a component may not export Wasm memory, and thus it cannot indirectly communicate to others by writing to its memory and having others read from that memory. This not only reinforces sandboxing, but enables interoperation between languages that make different assumptions about memory - for example, allowing a component that relies on Wasm GC (garbage collected) memory to collaborate with one that uses conventional linear memory.
+Core modules are, however, limited in how they expose their functionality to the outside world.
+Core modules expose their functionality by exporting functions.
+These functions' argument and return types are restricted, essentially,
+to only integers and floating-point numbers.
+Compound types, such as strings, lists, arrays, records, or structs,
+have to be represented in terms of integers and floating-point numbers.
+
+Recall that a linear memory is an uninitialized region of bytes
+declared within a module.
+So, a string argument might be represented as two separate arguments:
+an integer offset into a memory,
+and an integer representing the length of the string.
+These representations are frequently specific to each programming language.
+For example, a string in C might be represented entirely differently
+from a string in Rust or in JavaScript.
+Moreover, to make this approach work, modules must import and export memories,
+which can be error-prone, as different languages
+make different assumptions about memory layout.
+
+For WebAssembly modules to interoperate, therefore, there needs to be an agreed-upon way
+to expose these richer types across module boundaries.
+
+## Components
+
+Components were developed to ease interoperability between modules.
+Conceptually, a component is a module that is restricted
+to interact only through its imported and exported functions.
+Compared to core modules, components also use a richer
+mechanism for expressing the types of functions.
+
+### Interfaces
+
+These interfaces are expressed in a separate language called [WIT (Wasm Interface Type)](./wit.md).
+Interfaces contain _types_.
+The bit-level representations of these types are specified by
+the [Canonical ABI (Application Binary Interface)](./../advanced/canonical-abi.md).
+
+### Interoperability
+
+Interfaces make it possible to write components that are
+portable across different architectures and operating systems.
+Not only that, components are portable across different programming languages.
+A component implemented in Go can communicate directly and safely
+with a C or Rust component.
+Writing a component doesn't even require knowledge
+of which language its dependent components are implemented in,
+only the component interface expressed in WIT.
+Additionally, components can be linked into larger graphs,
+with one component's exports satisfying another's imports.
+
+### Benefits of the component model
+
+Putting all of the pieces together:
+the component model is a way of writing WebAssembly modules
+that interact with each other only through exports and imports of functions
+whose types are expressed using WIT.
+
+When combined with Wasm's strong [sandboxing](https://webassembly.org/docs/security/),
+the component model has further benefits.
+Richer type signatures express richer semantic properties
+than type signatures made up only of integers and floats.
+Rich types make it possible to statically analyse
+and reason about a component's behaviour.
+Simply by examining the surface of the component—the types
+of its imports and exports—properties can be
+enforced and guaranteed.
+The relationships within a graph of components can be analysed:
+for example, to verify that a component containing business logic
+has no access to a component containing personally identifiable information.
+
+Moreover, a component interacts with a runtime or other components
+_only_ by calling its imports and having its exports called.
+Specifically, unlike core modules, a component may not export a memory
+and thus it cannot indirectly communicate to others
+by writing to its memory and having others read from that memory.
+This not only reinforces sandboxing, but enables interoperation
+between languages that make different assumptions about memory:
+for example, allowing a component that relies garbage-collected memory
+to interoperate with one that uses conventional linear memory.
+
+## Using components
 
 Now that you have a better idea about how the component model can help you, take a look at [how to build components](../language-support.md) in your favorite language!
 
+## Further reading
+
 > For more background on why the component model was created, take a look at the specification's [goals](https://github.com/WebAssembly/component-model/blob/main/design/high-level/Goals.md), [use cases](https://github.com/WebAssembly/component-model/blob/main/design/high-level/UseCases.md) and [design choices](https://github.com/WebAssembly/component-model/blob/main/design/high-level/Choices.md).

From e509a073d82b6a2bcc2c482153a4dfb2a3fdad72 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 15:14:01 -0700
Subject: [PATCH 02/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index ced49752..2ac6fdbb 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -9,7 +9,7 @@ Rust, C, Go, or a variety of other languages as a source language.
 In this case, the compiler produces a WebAssembly _core module_.
 Core modules have some limitations, which components address.
 
-## Core modules
+## WebAssembly Core modules
 
 Typically, a core module defines a set of _functions_
 along with auxiliary definitions

From 9f86658d3e0e237cdae8e5c499db928913fd45b9 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 15:23:08 -0700
Subject: [PATCH 03/32] Revise introductory para

---
 component-model/src/design/why-component-model.md | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 2ac6fdbb..83d88de6 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -1,5 +1,14 @@
 # Why the Component Model?
 
+At a high level, the component model builds upon WebAssembly _core modules_
+to enhance interoperability, both by enriching the type system
+used for checking the safety of interactions between modules,
+and by removing potentially error-prone ways for modules to interact.
+To understand what the limitations of core modules are,
+we start by defining them.
+
+## WebAssembly Core modules
+
 WebAssembly programs can be written by hand,
 but it's more likely that you will use a compiler to generate your programs.
 In general, a compiler translates programs from a source language
@@ -7,9 +16,6 @@ to a target language.
 Compilers whose target language is WebAssembly may take
 Rust, C, Go, or a variety of other languages as a source language.
 In this case, the compiler produces a WebAssembly _core module_.
-Core modules have some limitations, which components address.
-
-## WebAssembly Core modules
 
 Typically, a core module defines a set of _functions_
 along with auxiliary definitions

From 0c2edc503abc6131618aa014e8b717ca229dfd71 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 15:32:59 -0700
Subject: [PATCH 04/32] Integrate review feedback into 'WebAssembly core
 modules' section

---
 .../src/design/why-component-model.md         | 23 ++++++++++---------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 83d88de6..d506b054 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -9,20 +9,23 @@ we start by defining them.
 
 ## WebAssembly Core modules
 
+A module is defined by the [WebAssembly Core Specification](https://webassembly.github.io/spec/core/).
+
 WebAssembly programs can be written by hand,
 but it's more likely that you will use a compiler to generate your programs.
 In general, a compiler translates programs from a source language
 to a target language.
 Compilers whose target language is WebAssembly may take
 Rust, C, Go, or a variety of other languages as a source language.
-In this case, the compiler produces a WebAssembly _core module_.
-
-Typically, a core module defines a set of _functions_
-along with auxiliary definitions
-that are necessary for executing those functions.
-Functions are made up of _instructions_.
-Auxiliary definitions include:
-* _Linear memories_ define untyped buffers that can be read from
+In this case, the compiler produces a WebAssembly [core module](https://webassembly.github.io/spec/core/syntax/modules.html).
+
+A core module is a set of definitions.
+Kinds of definitions include:
+* _Functions_ define executable units of code
+  (sequences of instructions along with declarations
+  for argument names and types and return types).
+* [_Linear memories_](https://webassembly.github.io/spec/core/syntax/modules.html#syntax-mem)
+  define buffers of uninterpreted bytes that can be read from
   and written to by instructions.
 * _Imports_ define the names of other modules
    that are required to be available to execute
@@ -34,13 +37,11 @@ Auxiliary definitions include:
 * And others; see [the Core Specification](https://webassembly.github.io/spec/core/syntax/modules.html)
   for the complete list.
 
-A core module usually corresponds to a single `.wasm` file.
+A core module usually corresponds to a single binary `.wasm` file.
 These modules can be run in the browser,
 or via a separate runtime such as [Wasmtime](https://wasmtime.dev/)
 or [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime).
 
-A module is defined by the [WebAssembly Core Specification](https://webassembly.github.io/spec/core/).
-
 ### Limitations of core modules
 
 Core modules are, however, limited in how they expose their functionality to the outside world.

From b5042bceb04e5248d6876da02fc3c8c989bb7b02 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 15:35:18 -0700
Subject: [PATCH 05/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index d506b054..9143cc33 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -39,7 +39,7 @@ Kinds of definitions include:
 
 A core module usually corresponds to a single binary `.wasm` file.
 These modules can be run in the browser,
-or via a separate runtime such as [Wasmtime](https://wasmtime.dev/)
+or via a server-side WebAssembly runtime such as [Wasmtime](https://wasmtime.dev/)
 or [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime).
 
 ### Limitations of core modules

From e1876e924563d796aff46c654a39e12addcc6026 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 15:48:10 -0700
Subject: [PATCH 06/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 9143cc33..bfd47151 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -63,7 +63,7 @@ Moreover, to make this approach work, modules must import and export memories,
 which can be error-prone, as different languages
 make different assumptions about memory layout.
 
-For WebAssembly modules to interoperate, therefore, there needs to be an agreed-upon way
+For WebAssembly modules written in different languages to interoperate smoothly, there needs to be an agreed-upon way
 to expose these richer types across module boundaries.
 
 ## Components

From 17b64a492b6292100a9ebbfb0b7df0d203f4eb4a Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 15:53:09 -0700
Subject: [PATCH 07/32] Integrate review feedback into 'Limitations of core
 modules' section

---
 .../src/design/why-component-model.md         | 41 +++++++++++++++----
 1 file changed, 32 insertions(+), 9 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index bfd47151..0a7cbeb2 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -39,16 +39,18 @@ Kinds of definitions include:
 
 A core module usually corresponds to a single binary `.wasm` file.
 These modules can be run in the browser,
-or via a server-side WebAssembly runtime such as [Wasmtime](https://wasmtime.dev/)
+or via a separate runtime such as [Wasmtime](https://wasmtime.dev/)
 or [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime).
 
 ### Limitations of core modules
 
 Core modules are, however, limited in how they expose their functionality to the outside world.
-Core modules expose their functionality by exporting functions.
-These functions' argument and return types are restricted, essentially,
-to only integers and floating-point numbers.
-Compound types, such as strings, lists, arrays, records, or structs,
+In WebAssembly core modules, functions are restricted, essentially,
+to using integer (`i32` or `i64`) or floating-point (`f32` or `f64`) types.
+Only these types can be passed as arguments to functions,
+and only these types can be returned from functions as results.
+Compound types common in higher-level programming languages,
+such as strings, lists, arrays, enums (enumerations), or structs (records),
 have to be represented in terms of integers and floating-point numbers.
 
 Recall that a linear memory is an uninitialized region of bytes
@@ -56,15 +58,36 @@ declared within a module.
 So, a string argument might be represented as two separate arguments:
 an integer offset into a memory,
 and an integer representing the length of the string.
-These representations are frequently specific to each programming language.
-For example, a string in C might be represented entirely differently
+
+In pseudocode, a type signature for a string-manipulating function
+might look like:
+
+```
+remove-duplicates: func(offset: i32, length: i32) -> [i32, i32]
+```
+
+supposing that `remove-duplicates` is a function
+to create a new string consisting of the unique characters
+in its argument.
+The return type is a pair of 32-bit integers,
+reflecting that the function must return
+the new offset for the newly allocated string, as well as its length.
+
+We would prefer to write a pseudocode type signature like this:
+
+```
+remove-duplicates: func(s: string) -> string
+```
+
+Data representations are frequently specific to each programming language.
+For example, a string in C is represented entirely differently
 from a string in Rust or in JavaScript.
 Moreover, to make this approach work, modules must import and export memories,
 which can be error-prone, as different languages
 make different assumptions about memory layout.
 
-For WebAssembly modules written in different languages to interoperate smoothly, there needs to be an agreed-upon way
-to expose these richer types across module boundaries.
+For WebAssembly modules written in different languages to interoperate smoothly,
+there needs to be an agreed-upon way to expose these richer types across module boundaries.
 
 ## Components
 

From dfcffbd5b13200330e7cae1f7e2511cebaf73aaa Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 16:01:36 -0700
Subject: [PATCH 08/32] Add memory details to pseudocode example

---
 .../src/design/why-component-model.md         | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 0a7cbeb2..5068a388 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -73,12 +73,34 @@ The return type is a pair of 32-bit integers,
 reflecting that the function must return
 the new offset for the newly allocated string, as well as its length.
 
+For this to work, the module defining the `remove-duplicates` function
+would also need to include
+an export declaration that exports a memory to be used
+for the argument and result strings. Pseudocode:
+
+```
+export "string_mem" (mem 1)
+```
+
+And, the module using the `remove-duplicates` function
+would need to import this memory. Pseudocode:
+
+```
+import "strings" "string_mem"
+```
+
+(This pseudocode is still simplified, since the importer
+also needs to declare the size of the memory being
+imported.)
+
 We would prefer to write a pseudocode type signature like this:
 
 ```
 remove-duplicates: func(s: string) -> string
 ```
 
+and dispense with the memory exports and imports altogether.
+
 Data representations are frequently specific to each programming language.
 For example, a string in C is represented entirely differently
 from a string in Rust or in JavaScript.

From 5e65915ed87c1d8acd3aef90895fb9f6dcb81a09 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 16:03:38 -0700
Subject: [PATCH 09/32] Integrate review feedback in 'Components' section

---
 component-model/src/design/why-component-model.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 5068a388..bd5b3145 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -113,7 +113,9 @@ there needs to be an agreed-upon way to expose these richer types across module
 
 ## Components
 
-Components were developed to ease interoperability between modules.
+Components solve the two problems that we've seen so far:
+the limited type system of core module functions,
+and cross-language interoperability.
 Conceptually, a component is a module that is restricted
 to interact only through its imported and exported functions.
 Compared to core modules, components also use a richer

From 005f1a652211cdbd397759678732a0c4d15ffa24 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 19:35:12 -0700
Subject: [PATCH 10/32] Integrate review feedback into 'Interfaces' section

---
 component-model/src/design/why-component-model.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index bd5b3145..1ac2f3bb 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -124,8 +124,9 @@ mechanism for expressing the types of functions.
 ### Interfaces
 
 These interfaces are expressed in a separate language called [WIT (Wasm Interface Type)](./wit.md).
-Interfaces contain _types_.
-The bit-level representations of these types are specified by
+[Interfaces](./wit.md#interfaces) contain definitions of _types_
+and type signatures for [_functions_](./wit.md#functions).
+The bit-level representations of types are specified by
 the [Canonical ABI (Application Binary Interface)](./../advanced/canonical-abi.md).
 
 ### Interoperability

From 8ef12b25d199034e5bd75913fcf7780f6d080f67 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 19:48:17 -0700
Subject: [PATCH 11/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 1ac2f3bb..782043ee 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -139,7 +139,7 @@ with a C or Rust component.
 Writing a component doesn't even require knowledge
 of which language its dependent components are implemented in,
 only the component interface expressed in WIT.
-Additionally, components can be linked into larger graphs,
+Additionally, components can be composed into larger graphs,
 with one component's exports satisfying another's imports.
 
 ### Benefits of the component model

From bb98ade0a37e182d0e0041c487a9c5d461bbf572 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 19:50:17 -0700
Subject: [PATCH 12/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 782043ee..0f1137be 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -135,7 +135,7 @@ Interfaces make it possible to write components that are
 portable across different architectures and operating systems.
 Not only that, components are portable across different programming languages.
 A component implemented in Go can communicate directly and safely
-with a C or Rust component.
+with a C or Rust component, by relying on the shared conventions of the Component Model ABI.
 Writing a component doesn't even require knowledge
 of which language its dependent components are implemented in,
 only the component interface expressed in WIT.

From 0aea4b327e477c26a059653918d3efde4eeae828 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 19:51:06 -0700
Subject: [PATCH 13/32] Integrate review comments in 'Interoperability' section

---
 component-model/src/design/why-component-model.md | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 0f1137be..36d71ee6 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -131,15 +131,16 @@ the [Canonical ABI (Application Binary Interface)](./../advanced/canonical-abi.m
 
 ### Interoperability
 
-Interfaces make it possible to write components that are
-portable across different architectures and operating systems.
-Not only that, components are portable across different programming languages.
+WebAssembly core modules are already portable across different architectures
+and operating systems;
+components retain these benefits and, using interfaces,
+add portability across different programming languages.
 A component implemented in Go can communicate directly and safely
 with a C or Rust component, by relying on the shared conventions of the Component Model ABI.
 Writing a component doesn't even require knowledge
 of which language its dependent components are implemented in,
 only the component interface expressed in WIT.
-Additionally, components can be composed into larger graphs,
+Additionally, components can be [composed](../composing-and-distributing.md) into larger graphs,
 with one component's exports satisfying another's imports.
 
 ### Benefits of the component model

From 262cec0552e319c517020d165626db81dc9dcd08 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Wed, 16 Jul 2025 19:57:50 -0700
Subject: [PATCH 14/32] Integrate review feedback in the rest of the doc

---
 component-model/src/design/why-component-model.md | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 36d71ee6..e90c9157 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -150,7 +150,7 @@ the component model is a way of writing WebAssembly modules
 that interact with each other only through exports and imports of functions
 whose types are expressed using WIT.
 
-When combined with Wasm's strong [sandboxing](https://webassembly.org/docs/security/),
+Building upon Wasm's strong [sandboxing](https://webassembly.org/docs/security/),
 the component model has further benefits.
 Richer type signatures express richer semantic properties
 than type signatures made up only of integers and floats.
@@ -179,4 +179,7 @@ Now that you have a better idea about how the component model can help you, take
 
 ## Further reading
 
-> For more background on why the component model was created, take a look at the specification's [goals](https://github.com/WebAssembly/component-model/blob/main/design/high-level/Goals.md), [use cases](https://github.com/WebAssembly/component-model/blob/main/design/high-level/UseCases.md) and [design choices](https://github.com/WebAssembly/component-model/blob/main/design/high-level/Choices.md).
+For more background on why the component model was created,
+take a look at the specification's [goals](https://github.com/WebAssembly/component-model/blob/main/design/high-level/Goals.md),
+[use cases](https://github.com/WebAssembly/component-model/blob/main/design/high-level/UseCases.md)
+and [design choices](https://github.com/WebAssembly/component-model/blob/main/design/high-level/Choices.md).

From 873fb8ee1d48c7fae51629b2aee4892068e75002 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:08:08 -0700
Subject: [PATCH 15/32] Add 'file' output and fix a weird transition

---
 component-model/src/design/why-component-model.md | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index e90c9157..93b8adcc 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -38,6 +38,11 @@ Kinds of definitions include:
   for the complete list.
 
 A core module usually corresponds to a single binary `.wasm` file.
+Here's what the `file` command outputs for a sample `.wasm` file:
+```console
+$ file adder.wasm
+adder.wasm: WebAssembly (wasm) binary module version 0x1 (MVP)
+```
 These modules can be run in the browser,
 or via a separate runtime such as [Wasmtime](https://wasmtime.dev/)
 or [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime).
@@ -119,11 +124,11 @@ and cross-language interoperability.
 Conceptually, a component is a module that is restricted
 to interact only through its imported and exported functions.
 Compared to core modules, components also use a richer
-mechanism for expressing the types of functions.
+mechanism for expressing the types of functions: _interfaces_.
 
 ### Interfaces
 
-These interfaces are expressed in a separate language called [WIT (Wasm Interface Type)](./wit.md).
+Interfaces are expressed in a separate language called [WIT (Wasm Interface Type)](./wit.md).
 [Interfaces](./wit.md#interfaces) contain definitions of _types_
 and type signatures for [_functions_](./wit.md#functions).
 The bit-level representations of types are specified by

From 11153b28e459bb800d81b13924d7f8d8d6347bb6 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:19:12 -0700
Subject: [PATCH 16/32] More detail in remove-duplicates example

---
 .../src/design/why-component-model.md         | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 93b8adcc..3c11e4bb 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -74,9 +74,13 @@ remove-duplicates: func(offset: i32, length: i32) -> [i32, i32]
 supposing that `remove-duplicates` is a function
 to create a new string consisting of the unique characters
 in its argument.
-The return type is a pair of 32-bit integers,
-reflecting that the function must return
-the new offset for the newly allocated string, as well as its length.
+The return type is a list of two 32-bit integers.
+The first integer is an offset into one of the linear memories
+declared by the module—where the newly allocated string starts—and
+the second integer is the length of the string.
+After calling the function,
+the caller has to reach into the appropriate linear memory
+and read the output string, using the returned offset and length.
 
 For this to work, the module defining the `remove-duplicates` function
 would also need to include
@@ -98,6 +102,15 @@ import "strings" "string_mem"
 also needs to declare the size of the memory being
 imported.)
 
+Note that there is nothing in the type system to prevent
+the returned length from being confused with the returned offset,
+since both are integers.
+Also, the name of the memory used for the input and output strings
+must be established by convention,
+and there is also nothing in the type system to stop client code
+from indexing into a different memory
+(as long as the sum of the offset and length is within bounds).
+
 We would prefer to write a pseudocode type signature like this:
 
 ```

From 117804e6f61c79c1def68d165d566b276f615329 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:22:24 -0700
Subject: [PATCH 17/32] Fix WIT acronym

---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 3c11e4bb..ee93fa23 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -141,7 +141,7 @@ mechanism for expressing the types of functions: _interfaces_.
 
 ### Interfaces
 
-Interfaces are expressed in a separate language called [WIT (Wasm Interface Type)](./wit.md).
+Interfaces are expressed in a separate language called [WebAssembly Interface Types (WIT)](./wit.md).
 [Interfaces](./wit.md#interfaces) contain definitions of _types_
 and type signatures for [_functions_](./wit.md#functions).
 The bit-level representations of types are specified by

From 12351e2bbd283851738d3428414ee562d2658ecd Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:27:52 -0700
Subject: [PATCH 18/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
---
 component-model/src/design/why-component-model.md | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index ee93fa23..d0baf393 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -12,11 +12,8 @@ we start by defining them.
 A module is defined by the [WebAssembly Core Specification](https://webassembly.github.io/spec/core/).
 
 WebAssembly programs can be written by hand,
-but it's more likely that you will use a compiler to generate your programs.
-In general, a compiler translates programs from a source language
-to a target language.
-Compilers whose target language is WebAssembly may take
-Rust, C, Go, or a variety of other languages as a source language.
+but it's more likely that you will use a higher level programming language
+such as Rust, C, Go, Javascript, or Python to build WebAssembly programs.
 In this case, the compiler produces a WebAssembly [core module](https://webassembly.github.io/spec/core/syntax/modules.html).
 
 A core module is a set of definitions.

From 509ded0e670dbb0d73d0b59475e09ce551887839 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:28:59 -0700
Subject: [PATCH 19/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index d0baf393..59ac06fa 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -14,7 +14,7 @@ A module is defined by the [WebAssembly Core Specification](https://webassembly.
 WebAssembly programs can be written by hand,
 but it's more likely that you will use a higher level programming language
 such as Rust, C, Go, Javascript, or Python to build WebAssembly programs.
-In this case, the compiler produces a WebAssembly [core module](https://webassembly.github.io/spec/core/syntax/modules.html).
+Many existing toolchains currently produce a [WebAssembly core module](https://webassembly.github.io/spec/core/syntax/modules.html) -- a single binary `.wasm` file.
 
 A core module is a set of definitions.
 Kinds of definitions include:

From 428763eeee8d98570aea44fe9910986beccd7b41 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:32:04 -0700
Subject: [PATCH 20/32] Review feedback in 'WebAssembly core modules' section

---
 .../src/design/why-component-model.md         | 21 +++++++++++--------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 59ac06fa..e5fa5741 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -13,8 +13,17 @@ A module is defined by the [WebAssembly Core Specification](https://webassembly.
 
 WebAssembly programs can be written by hand,
 but it's more likely that you will use a higher level programming language
-such as Rust, C, Go, Javascript, or Python to build WebAssembly programs.
-Many existing toolchains currently produce a [WebAssembly core module](https://webassembly.github.io/spec/core/syntax/modules.html) -- a single binary `.wasm` file.
+such as Rust, C, Go, JavaScript, or Python to build WebAssembly programs.
+Many existing toolchains currently produce a
+[WebAssembly core module](https://webassembly.github.io/spec/core/syntax/modules.html)—a single
+binary `.wasm` file.
+
+A core module usually corresponds to a single binary `.wasm` file.
+Here's what the `file` command outputs for a sample `.wasm` file:
+```console
+$ file adder.wasm
+adder.wasm: WebAssembly (wasm) binary module version 0x1 (MVP)
+```
 
 A core module is a set of definitions.
 Kinds of definitions include:
@@ -34,13 +43,7 @@ Kinds of definitions include:
 * And others; see [the Core Specification](https://webassembly.github.io/spec/core/syntax/modules.html)
   for the complete list.
 
-A core module usually corresponds to a single binary `.wasm` file.
-Here's what the `file` command outputs for a sample `.wasm` file:
-```console
-$ file adder.wasm
-adder.wasm: WebAssembly (wasm) binary module version 0x1 (MVP)
-```
-These modules can be run in the browser,
+Core modules can be run in the browser,
 or via a separate runtime such as [Wasmtime](https://wasmtime.dev/)
 or [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime).
 

From 6314db1ef2bfd4b61c9d911bdc0e4dc1ee24ba22 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:32:47 -0700
Subject: [PATCH 21/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
---
 component-model/src/design/why-component-model.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index e5fa5741..4238fa44 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -49,7 +49,8 @@ or [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime).
 
 ### Limitations of core modules
 
-Core modules are, however, limited in how they expose their functionality to the outside world.
+Core modules are limited in the computation they can perform and 
+how they expose their functionality to the outside world.
 In WebAssembly core modules, functions are restricted, essentially,
 to using integer (`i32` or `i64`) or floating-point (`f32` or `f64`) types.
 Only these types can be passed as arguments to functions,

From bfe929b6e611c4459b712d96343ebc13c35e3ecd Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:34:44 -0700
Subject: [PATCH 22/32] Review feedback in 'Limitations of core modules'
 section

---
 component-model/src/design/why-component-model.md | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 4238fa44..1e88fd4c 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -7,7 +7,7 @@ and by removing potentially error-prone ways for modules to interact.
 To understand what the limitations of core modules are,
 we start by defining them.
 
-## WebAssembly Core modules
+## WebAssembly core modules
 
 A module is defined by the [WebAssembly Core Specification](https://webassembly.github.io/spec/core/).
 
@@ -59,11 +59,12 @@ Compound types common in higher-level programming languages,
 such as strings, lists, arrays, enums (enumerations), or structs (records),
 have to be represented in terms of integers and floating-point numbers.
 
-Recall that a linear memory is an uninitialized region of bytes
-declared within a module.
-So, a string argument might be represented as two separate arguments:
-an integer offset into a memory,
+For example, for a function to accept a string, the string argument
+might be represented as two separate arguments:
+an integer offset into a memory
 and an integer representing the length of the string.
+Recall that a (linear) memory is an uninitialized region of bytes
+declared within a module.
 
 In pseudocode, a type signature for a string-manipulating function
 might look like:
@@ -120,6 +121,7 @@ remove-duplicates: func(s: string) -> string
 
 and dispense with the memory exports and imports altogether.
 
+The complexity doesn't stop there!
 Data representations are frequently specific to each programming language.
 For example, a string in C is represented entirely differently
 from a string in Rust or in JavaScript.

From 217acbdbfb11cb691300dac96d673e921deebc34 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:36:10 -0700
Subject: [PATCH 23/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 1e88fd4c..26674c4a 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -137,7 +137,7 @@ there needs to be an agreed-upon way to expose these richer types across module
 Components solve the two problems that we've seen so far:
 the limited type system of core module functions,
 and cross-language interoperability.
-Conceptually, a component is a module that is restricted
+Conceptually, a component is a WebAssembly binary (which may or may not contain modules) that is restricted
 to interact only through its imported and exported functions.
 Compared to core modules, components also use a richer
 mechanism for expressing the types of functions: _interfaces_.

From 28bc29768170bc15e7ce2501f237a2bbac7b42bd Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:39:14 -0700
Subject: [PATCH 24/32] Review feedback in 'Components' section

---
 component-model/src/design/why-component-model.md | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 26674c4a..30424b93 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -137,10 +137,13 @@ there needs to be an agreed-upon way to expose these richer types across module
 Components solve the two problems that we've seen so far:
 the limited type system of core module functions,
 and cross-language interoperability.
-Conceptually, a component is a WebAssembly binary (which may or may not contain modules) that is restricted
-to interact only through its imported and exported functions.
+Conceptually, a component is a WebAssembly binary
+(which may or may not contain modules)
+that is restricted to interact
+only through the modules' imported and exported functions.
+Components use a different binary format.
 Compared to core modules, components also use a richer
-mechanism for expressing the types of functions: _interfaces_.
+mechanism by default for expressing the types of functions: _interfaces_.
 
 ### Interfaces
 

From 3d171abe57a82aff6c6b18a2be495b1ae599d1f3 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:41:01 -0700
Subject: [PATCH 25/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Victor Adossi <123968127+vados-cosmonic@users.noreply.github.com>
---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 30424b93..aa52599e 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -157,7 +157,7 @@ the [Canonical ABI (Application Binary Interface)](./../advanced/canonical-abi.m
 
 WebAssembly core modules are already portable across different architectures
 and operating systems;
-components retain these benefits and, using interfaces,
+components retain these benefits and, using the Component Model ABI,
 add portability across different programming languages.
 A component implemented in Go can communicate directly and safely
 with a C or Rust component, by relying on the shared conventions of the Component Model ABI.

From 078c5622bc7dcce3faca191b4a345b4452a17dd3 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:44:21 -0700
Subject: [PATCH 26/32] Review feedback in 'Benefits of the component model'
 section

---
 component-model/src/design/why-component-model.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index aa52599e..dcb3c743 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -170,7 +170,9 @@ with one component's exports satisfying another's imports.
 ### Benefits of the component model
 
 Putting all of the pieces together:
-the component model is a way of writing WebAssembly modules
+the component model introduces a binary WebAssembly format
+that encapsulates WebAssembly modules.
+This format enables the construction of WebAssembly modules
 that interact with each other only through exports and imports of functions
 whose types are expressed using WIT.
 

From 74dfd2cc6c4ab5e558c94bfef5dffc21f7678e72 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:46:53 -0700
Subject: [PATCH 27/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Luke Wagner <mail@lukewagner.name>
---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index dcb3c743..c8e6f360 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -1,7 +1,7 @@
 # Why the Component Model?
 
 At a high level, the component model builds upon WebAssembly _core modules_
-to enhance interoperability, both by enriching the type system
+to enhance interoperability between languages and libraries, both by enriching the type system
 used for checking the safety of interactions between modules,
 and by removing potentially error-prone ways for modules to interact.
 To understand what the limitations of core modules are,

From d2dfbd7c59d766fe0ac1a69c86ed929c662b64cb Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:47:10 -0700
Subject: [PATCH 28/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Luke Wagner <mail@lukewagner.name>
---
 component-model/src/design/why-component-model.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index c8e6f360..553fc997 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -3,7 +3,7 @@
 At a high level, the component model builds upon WebAssembly _core modules_
 to enhance interoperability between languages and libraries, both by enriching the type system
 used for checking the safety of interactions between modules,
-and by removing potentially error-prone ways for modules to interact.
+and by clearly defining and enforcing the low-level calling contract between separately-compiled modules.
 To understand what the limitations of core modules are,
 we start by defining them.
 

From 88b76e8ad2aa1b2e2a8a13afbdd5916c6d5d9902 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:49:41 -0700
Subject: [PATCH 29/32] Use semantic line breaks; call back to the introduction
 in the 'Interfaces' section

---
 component-model/src/design/why-component-model.md | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 553fc997..3a95a8ba 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -1,9 +1,11 @@
 # Why the Component Model?
 
 At a high level, the component model builds upon WebAssembly _core modules_
-to enhance interoperability between languages and libraries, both by enriching the type system
+to enhance interoperability between languages and libraries,
+both by enriching the type system
 used for checking the safety of interactions between modules,
-and by clearly defining and enforcing the low-level calling contract between separately-compiled modules.
+and by clearly defining and enforcing
+the low-level calling contract between separately-compiled modules.
 To understand what the limitations of core modules are,
 we start by defining them.
 
@@ -152,6 +154,9 @@ Interfaces are expressed in a separate language called [WebAssembly Interface Ty
 and type signatures for [_functions_](./wit.md#functions).
 The bit-level representations of types are specified by
 the [Canonical ABI (Application Binary Interface)](./../advanced/canonical-abi.md).
+Together, interfaces and the Canonical ABI
+achieve the goal of clearly defining and enforcing
+the low-level calling contract between modules.
 
 ### Interoperability
 

From 2eab4a258105d9dd07052ee5a54c9074ec71cd97 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:50:47 -0700
Subject: [PATCH 30/32] Update
 component-model/src/design/why-component-model.md

Co-authored-by: Luke Wagner <mail@lukewagner.name>
---
 component-model/src/design/why-component-model.md | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 3a95a8ba..fda8c8a9 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -185,10 +185,8 @@ Building upon Wasm's strong [sandboxing](https://webassembly.org/docs/security/)
 the component model has further benefits.
 Richer type signatures express richer semantic properties
 than type signatures made up only of integers and floats.
-Rich types make it possible to statically analyse
-and reason about a component's behaviour.
-Simply by examining the surface of the component—the types
-of its imports and exports—properties can be
+Rich types make it easier to know what a component or interface is 
+doing at a glance and have guarantees of what bad things cannot happen.
 enforced and guaranteed.
 The relationships within a graph of components can be analysed:
 for example, to verify that a component containing business logic

From f1be23abfe3b946b4f3dabea6a459c0d1ac92542 Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:52:29 -0700
Subject: [PATCH 31/32] Clean up para on rich types

---
 component-model/src/design/why-component-model.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index fda8c8a9..7b572e71 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -51,7 +51,7 @@ or [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime).
 
 ### Limitations of core modules
 
-Core modules are limited in the computation they can perform and 
+Core modules are limited in the computation they can perform and
 how they expose their functionality to the outside world.
 In WebAssembly core modules, functions are restricted, essentially,
 to using integer (`i32` or `i64`) or floating-point (`f32` or `f64`) types.
@@ -183,12 +183,12 @@ whose types are expressed using WIT.
 
 Building upon Wasm's strong [sandboxing](https://webassembly.org/docs/security/),
 the component model has further benefits.
+Rich types make it easier to know what a component or interface
+is doing at a glance
+and have guarantees of what bad things cannot happen.
 Richer type signatures express richer semantic properties
 than type signatures made up only of integers and floats.
-Rich types make it easier to know what a component or interface is 
-doing at a glance and have guarantees of what bad things cannot happen.
-enforced and guaranteed.
-The relationships within a graph of components can be analysed:
+The relationships within a graph of components can be statically analysed:
 for example, to verify that a component containing business logic
 has no access to a component containing personally identifiable information.
 

From 3a4ec9332972504e59100750a305b39926e7be3e Mon Sep 17 00:00:00 2001
From: Tim Chevalier <tjc@igalia.com>
Date: Thu, 17 Jul 2025 13:58:20 -0700
Subject: [PATCH 32/32] Misc copyedits

---
 component-model/src/design/why-component-model.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/component-model/src/design/why-component-model.md b/component-model/src/design/why-component-model.md
index 7b572e71..f8946842 100644
--- a/component-model/src/design/why-component-model.md
+++ b/component-model/src/design/why-component-model.md
@@ -31,7 +31,8 @@ A core module is a set of definitions.
 Kinds of definitions include:
 * _Functions_ define executable units of code
   (sequences of instructions along with declarations
-  for argument names and types and return types).
+  for the names of arguments
+  and the types of arguments and return values).
 * [_Linear memories_](https://webassembly.github.io/spec/core/syntax/modules.html#syntax-mem)
   define buffers of uninterpreted bytes that can be read from
   and written to by instructions.
@@ -199,7 +200,7 @@ and thus it cannot indirectly communicate to others
 by writing to its memory and having others read from that memory.
 This not only reinforces sandboxing, but enables interoperation
 between languages that make different assumptions about memory:
-for example, allowing a component that relies garbage-collected memory
+for example, allowing a component that relies on garbage-collected memory
 to interoperate with one that uses conventional linear memory.
 
 ## Using components