From d43e340afaf794ce727740bd9d4faa1e3161c7d8 Mon Sep 17 00:00:00 2001
From: Alexander Sandor <alexander@serverpod.dev>
Date: Fri, 13 Dec 2024 14:07:52 +0100
Subject: [PATCH 1/6] refactor: change from bold to code to match directory
 definition in models.md

---
 docs/06-concepts/01-working-with-endpoints.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/06-concepts/01-working-with-endpoints.md b/docs/06-concepts/01-working-with-endpoints.md
index 84722348..72f155da 100644
--- a/docs/06-concepts/01-working-with-endpoints.md
+++ b/docs/06-concepts/01-working-with-endpoints.md
@@ -1,6 +1,6 @@
 # Working with endpoints
 
-Endpoints are the connection points to the server from the client. With Serverpod, you add methods to your endpoint, and your client code will be generated to make the method call. For the code to be generated, you need to place the endpoint file anywhere under the **lib** directory of your server. Your endpoint should extend the `Endpoint` class. For methods to be generated, they need to return a typed `Future`, and its first argument should be a `Session` object. The `Session` object holds information about the call being made and provides access to the database.
+Endpoints are the connection points to the server from the client. With Serverpod, you add methods to your endpoint, and your client code will be generated to make the method call. For the code to be generated, you need to place the endpoint file anywhere under the `lib` directory of your server. Your endpoint should extend the `Endpoint` class. For methods to be generated, they need to return a typed `Future`, and its first argument should be a `Session` object. The `Session` object holds information about the call being made and provides access to the database.
 
 ```dart
 import 'package:serverpod/serverpod.dart';

From 398ad851c4473b8bd5ee91323d5533546b21a122 Mon Sep 17 00:00:00 2001
From: Alexander Sandor <alexander@serverpod.dev>
Date: Fri, 13 Dec 2024 14:15:00 +0100
Subject: [PATCH 2/6] fix: fix a typo.

---
 docs/06-concepts/02-models.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/06-concepts/02-models.md b/docs/06-concepts/02-models.md
index 103805a9..d5e2ffb9 100644
--- a/docs/06-concepts/02-models.md
+++ b/docs/06-concepts/02-models.md
@@ -114,7 +114,7 @@ Serverpod generates some convenience methods on the Dart classes.
 
 ### copyWith
 
-The `copyWith` method allows for efficient object copying with selective field updates and is available on all generated `class`es. Here's how it operates:
+The `copyWith` method allows for efficient object copying with selective field updates and is available on all generated classes. Here's how it operates:
 
 ```dart
 var john = User(name: 'John Doe', age: 25);

From 94551f8a005fd4bab56e32d02dfcd08cca64158f Mon Sep 17 00:00:00 2001
From: Alexander Sandor <alexander@serverpod.dev>
Date: Fri, 13 Dec 2024 14:32:14 +0100
Subject: [PATCH 3/6] fix: Add documentation around placing model files with
 spy extension anywhere.

---
 docs/01-get-started.md           | 6 +++---
 docs/02-get-started-with-mini.md | 4 ++--
 docs/06-concepts/02-models.md    | 4 +++-
 docs/06-concepts/10-modules.md   | 2 +-
 4 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/docs/01-get-started.md b/docs/01-get-started.md
index 30fea52e..8fe6a133 100644
--- a/docs/01-get-started.md
+++ b/docs/01-get-started.md
@@ -122,7 +122,7 @@ These are the most important directories:
 
 - `config`: These are the configuration files for your Serverpod. These include a `password.yaml` file with your passwords and configurations for running your server in development, staging, and production. By default, everything is correctly configured to run your server locally.
 - `lib/src/endpoints`: This is the default location for your server's endpoints. When you add methods to an endpoint, Serverpod will generate the corresponding methods in your client.
-- `lib/src/models`: The model definition files are placed here. The files define the classes you can pass through your API and how they relate to your database. Serverpod generates serializable objects from the model definitions.
+- `lib/src/models`: Default location for your model definition files. The files define the classes you can pass through your API and how they relate to your database. Serverpod generates serializable objects from the model definitions.
 
 Both the `endpoints` and `models` directories contain sample files that give a quick idea of how they work. So this a great place to start learning.
 
@@ -167,9 +167,9 @@ To learn more about endpoints, see the [Working with endpoints](concepts/working
 
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
-The structure for your serialized classes is defined in yaml-files in the `lib/src/models` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in `spy.yaml` files anywhere in the `lib` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a `spy.yaml` file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/docs/02-get-started-with-mini.md b/docs/02-get-started-with-mini.md
index 66c56cf4..9a305c60 100644
--- a/docs/02-get-started-with-mini.md
+++ b/docs/02-get-started-with-mini.md
@@ -36,7 +36,7 @@ If you are using VS Code, install our Serverpod extension. It will help you vali
 :::
 
 ## Creating models
-In Serverpod, you define your models in easy-to-read YAML-files, which you place in your server’s `lib/src/models` directory. Model files will be converted to Dart classes that can be serialized and sent to and from the server to your app. This is an example of a model file:
+In Serverpod, you define your models in easy-to-read YAML-files, which you place anywhere in your server’s `lib` directory with the `spy.yaml` extension. Model files will be converted to Dart classes that can be serialized and sent to and from the server to your app. This is an example of a model file:
 
 ```yaml
 class: Company
@@ -111,4 +111,4 @@ var result = await client.company.isLegit(company);
 ```
 
 ## Conclusion
-You are now ready to start exploring the exciting world of Serverpod! And even if you start out with Serverpod mini, you can always [upgrade](upgrading/upgrade-from-mini) to the full version later.
\ No newline at end of file
+You are now ready to start exploring the exciting world of Serverpod! And even if you start out with Serverpod mini, you can always [upgrade](upgrading/upgrade-from-mini) to the full version later.
diff --git a/docs/06-concepts/02-models.md b/docs/06-concepts/02-models.md
index d5e2ffb9..f6d24b00 100644
--- a/docs/06-concepts/02-models.md
+++ b/docs/06-concepts/02-models.md
@@ -1,6 +1,8 @@
 # Working with models
 
-Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server. Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Server Pod Yaml") to leverage syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
+Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server.
+
+Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Server Pod Yaml"). Using this file type allows placing the model files anywhere in your servers `lib` directory and enables syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
 
 The files are analyzed by the Serverpod CLI when generating the project and creating migrations.
 
diff --git a/docs/06-concepts/10-modules.md b/docs/06-concepts/10-modules.md
index 6dab7425..3e4db07a 100644
--- a/docs/06-concepts/10-modules.md
+++ b/docs/06-concepts/10-modules.md
@@ -67,7 +67,7 @@ dependencies:
 
 ## Referencing a module
 
-It can be useful to reference serializable objects in other modules from the yaml-files in your model directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your models. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass

From 5b46b8d603968455072e1295b898cb30bcc2726e Mon Sep 17 00:00:00 2001
From: Alexander Sandor <alexander@serverpod.dev>
Date: Fri, 13 Dec 2024 14:32:44 +0100
Subject: [PATCH 4/6] refactor: Change yaml-file to YAML-file for all versions
 for consistency.

---
 docs/06-concepts/04-exceptions.md                           | 2 +-
 docs/06-concepts/06-database/04-indexing.md                 | 4 ++--
 .../version-0.9.10/03-concepts/02-serialization.md          | 4 ++--
 .../version-0.9.10/03-concepts/03-database-communication.md | 2 +-
 .../version-0.9.11/03-concepts/02-serialization.md          | 4 ++--
 .../version-0.9.11/03-concepts/03-database-communication.md | 2 +-
 .../version-0.9.20/04-concepts/02-serialization.md          | 4 ++--
 .../version-0.9.20/04-concepts/03-database-communication.md | 2 +-
 versioned_docs/version-0.9.20/04-concepts/06-modules.md     | 4 ++--
 .../version-0.9.21/04-concepts/02-serialization.md          | 4 ++--
 .../version-0.9.21/04-concepts/03-database-communication.md | 2 +-
 versioned_docs/version-0.9.21/04-concepts/06-modules.md     | 4 ++--
 .../version-0.9.22/04-concepts/02-serialization.md          | 4 ++--
 .../version-0.9.22/04-concepts/03-database-communication.md | 2 +-
 versioned_docs/version-0.9.22/04-concepts/06-modules.md     | 4 ++--
 .../version-0.9.5/02-concepts/02-serialization.md           | 4 ++--
 .../version-0.9.5/02-concepts/03-database-communication.md  | 2 +-
 .../version-0.9.6/02-concepts/02-serialization.md           | 4 ++--
 .../version-0.9.6/02-concepts/03-database-communication.md  | 2 +-
 .../version-0.9.7/03-concepts/02-serialization.md           | 4 ++--
 .../version-0.9.7/03-concepts/03-database-communication.md  | 2 +-
 .../version-0.9.8/03-concepts/02-serialization.md           | 4 ++--
 .../version-0.9.8/03-concepts/03-database-communication.md  | 2 +-
 .../version-0.9.9/03-concepts/02-serialization.md           | 4 ++--
 .../version-0.9.9/03-concepts/03-database-communication.md  | 2 +-
 .../version-1.0.0/04-concepts/02-serialization.md           | 4 ++--
 .../version-1.0.0/04-concepts/03-database-communication.md  | 2 +-
 versioned_docs/version-1.0.0/04-concepts/06-modules.md      | 4 ++--
 .../version-1.1.0/04-concepts/02-serialization.md           | 4 ++--
 versioned_docs/version-1.1.0/04-concepts/04-exceptions.md   | 4 ++--
 .../version-1.1.0/04-concepts/05-database-communication.md  | 2 +-
 versioned_docs/version-1.1.0/04-concepts/08-modules.md      | 4 ++--
 versioned_docs/version-1.1.1/01-get-started.md              | 6 +++---
 .../version-1.1.1/05-concepts/02-serialization.md           | 4 ++--
 versioned_docs/version-1.1.1/05-concepts/04-exceptions.md   | 4 ++--
 .../version-1.1.1/05-concepts/05-database-communication.md  | 2 +-
 versioned_docs/version-1.1.1/05-concepts/08-modules.md      | 2 +-
 versioned_docs/version-1.2.0/01-get-started.md              | 4 ++--
 versioned_docs/version-1.2.0/05-concepts/04-exceptions.md   | 2 +-
 .../version-1.2.0/05-concepts/06-database/04-indexing.md    | 6 +++---
 versioned_docs/version-1.2.0/05-concepts/09-modules.md      | 2 +-
 versioned_docs/version-2.0.0/01-get-started.md              | 4 ++--
 versioned_docs/version-2.0.0/05-concepts/04-exceptions.md   | 2 +-
 .../version-2.0.0/05-concepts/06-database/04-indexing.md    | 4 ++--
 versioned_docs/version-2.0.0/05-concepts/09-modules.md      | 2 +-
 versioned_docs/version-2.1.0/01-get-started.md              | 4 ++--
 versioned_docs/version-2.1.0/06-concepts/04-exceptions.md   | 2 +-
 .../version-2.1.0/06-concepts/06-database/04-indexing.md    | 4 ++--
 versioned_docs/version-2.1.0/06-concepts/10-modules.md      | 2 +-
 versioned_docs/version-2.2.0/01-get-started.md              | 4 ++--
 versioned_docs/version-2.2.0/06-concepts/04-exceptions.md   | 2 +-
 .../version-2.2.0/06-concepts/06-database/04-indexing.md    | 4 ++--
 versioned_docs/version-2.2.0/06-concepts/10-modules.md      | 2 +-
 53 files changed, 85 insertions(+), 85 deletions(-)

diff --git a/docs/06-concepts/04-exceptions.md b/docs/06-concepts/04-exceptions.md
index 85800db8..e4baa660 100644
--- a/docs/06-concepts/04-exceptions.md
+++ b/docs/06-concepts/04-exceptions.md
@@ -12,7 +12,7 @@ Use the Serverpod Insights app to view your logs. It will show any failed or slo
 
 ## Serializable exceptions
 
-Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same yaml-files to define the serializable exceptions as you would with any serializable model (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
+Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same YAML-files to define the serializable exceptions as you would with any serializable model (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
 
 ```yaml
 exception: MyException
diff --git a/docs/06-concepts/06-database/04-indexing.md b/docs/06-concepts/06-database/04-indexing.md
index 8bae058f..f28ae772 100644
--- a/docs/06-concepts/06-database/04-indexing.md
+++ b/docs/06-concepts/06-database/04-indexing.md
@@ -1,10 +1,10 @@
 # Indexing
 
-For performance reasons, you may want to add indexes to your database tables. These are added in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. These are added in the YAML-files defining the serializable objects.
 
 ### Add an index
 
-To add an index, add an `indexes` section to the yaml-file. The `indexes` section is a map where the key is the name of the index and the value is a map with the index details.
+To add an index, add an `indexes` section to the YAML-file. The `indexes` section is a map where the key is the name of the index and the value is a map with the index details.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.10/03-concepts/02-serialization.md b/versioned_docs/version-0.9.10/03-concepts/02-serialization.md
index 3c4759b3..db433d8a 100644
--- a/versioned_docs/version-0.9.10/03-concepts/02-serialization.md
+++ b/versioned_docs/version-0.9.10/03-concepts/02-serialization.md
@@ -1,7 +1,7 @@
 # Serialization
-Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.10/03-concepts/03-database-communication.md b/versioned_docs/version-0.9.10/03-concepts/03-database-communication.md
index e7b5600f..314f10da 100644
--- a/versioned_docs/version-0.9.10/03-concepts/03-database-communication.md
+++ b/versioned_docs/version-0.9.10/03-concepts/03-database-communication.md
@@ -27,7 +27,7 @@ fields:
 Likewise, if you only want a field to be accessible in the protocol but not stored in the server, you can add the `api` flag. By default, a field is accessible to both the API and the database.
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.11/03-concepts/02-serialization.md b/versioned_docs/version-0.9.11/03-concepts/02-serialization.md
index a5dc23c3..2363fdce 100644
--- a/versioned_docs/version-0.9.11/03-concepts/02-serialization.md
+++ b/versioned_docs/version-0.9.11/03-concepts/02-serialization.md
@@ -1,7 +1,7 @@
 # Serialization
-Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.11/03-concepts/03-database-communication.md b/versioned_docs/version-0.9.11/03-concepts/03-database-communication.md
index 01bbd076..e9736e32 100644
--- a/versioned_docs/version-0.9.11/03-concepts/03-database-communication.md
+++ b/versioned_docs/version-0.9.11/03-concepts/03-database-communication.md
@@ -33,7 +33,7 @@ If you use the `database` or `api` options the field must be nullable.
 :::
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.20/04-concepts/02-serialization.md b/versioned_docs/version-0.9.20/04-concepts/02-serialization.md
index b439347a..7d01e3e7 100644
--- a/versioned_docs/version-0.9.20/04-concepts/02-serialization.md
+++ b/versioned_docs/version-0.9.20/04-concepts/02-serialization.md
@@ -2,9 +2,9 @@
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
 ## Serverpod's native serialization
-The structure for your serialized classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.20/04-concepts/03-database-communication.md b/versioned_docs/version-0.9.20/04-concepts/03-database-communication.md
index 5af51d94..388f59b3 100644
--- a/versioned_docs/version-0.9.20/04-concepts/03-database-communication.md
+++ b/versioned_docs/version-0.9.20/04-concepts/03-database-communication.md
@@ -39,7 +39,7 @@ If you use the `database` or `api` options the field must be nullable.
 :::
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.20/04-concepts/06-modules.md b/versioned_docs/version-0.9.20/04-concepts/06-modules.md
index ca2956a8..9426b505 100644
--- a/versioned_docs/version-0.9.20/04-concepts/06-modules.md
+++ b/versioned_docs/version-0.9.20/04-concepts/06-modules.md
@@ -57,7 +57,7 @@ dependencies:
 ```
 
 ## Referencing a module
-It can be useful to reference serializable objects in other modules from the yaml-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass
@@ -84,4 +84,4 @@ In your Flutter package, you most likely want to import the client libraries cre
 
 Most modules will need a set of database tables to function. When naming the tables, you should use the module name as a prefix to the table name to avoid any conflicts. For instance, the Serverpod tables are prefixed with `serverpod_`.
 
-:::
\ No newline at end of file
+:::
diff --git a/versioned_docs/version-0.9.21/04-concepts/02-serialization.md b/versioned_docs/version-0.9.21/04-concepts/02-serialization.md
index dace8e14..8117f7ab 100644
--- a/versioned_docs/version-0.9.21/04-concepts/02-serialization.md
+++ b/versioned_docs/version-0.9.21/04-concepts/02-serialization.md
@@ -2,9 +2,9 @@
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
 ## Serverpod's native serialization
-The structure for your serialized classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.21/04-concepts/03-database-communication.md b/versioned_docs/version-0.9.21/04-concepts/03-database-communication.md
index 5af51d94..388f59b3 100644
--- a/versioned_docs/version-0.9.21/04-concepts/03-database-communication.md
+++ b/versioned_docs/version-0.9.21/04-concepts/03-database-communication.md
@@ -39,7 +39,7 @@ If you use the `database` or `api` options the field must be nullable.
 :::
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.21/04-concepts/06-modules.md b/versioned_docs/version-0.9.21/04-concepts/06-modules.md
index ca2956a8..9426b505 100644
--- a/versioned_docs/version-0.9.21/04-concepts/06-modules.md
+++ b/versioned_docs/version-0.9.21/04-concepts/06-modules.md
@@ -57,7 +57,7 @@ dependencies:
 ```
 
 ## Referencing a module
-It can be useful to reference serializable objects in other modules from the yaml-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass
@@ -84,4 +84,4 @@ In your Flutter package, you most likely want to import the client libraries cre
 
 Most modules will need a set of database tables to function. When naming the tables, you should use the module name as a prefix to the table name to avoid any conflicts. For instance, the Serverpod tables are prefixed with `serverpod_`.
 
-:::
\ No newline at end of file
+:::
diff --git a/versioned_docs/version-0.9.22/04-concepts/02-serialization.md b/versioned_docs/version-0.9.22/04-concepts/02-serialization.md
index cf6cd259..9445fa3a 100644
--- a/versioned_docs/version-0.9.22/04-concepts/02-serialization.md
+++ b/versioned_docs/version-0.9.22/04-concepts/02-serialization.md
@@ -2,9 +2,9 @@
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
 ## Serverpod's native serialization
-The structure for your serialized classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.22/04-concepts/03-database-communication.md b/versioned_docs/version-0.9.22/04-concepts/03-database-communication.md
index 5af51d94..388f59b3 100644
--- a/versioned_docs/version-0.9.22/04-concepts/03-database-communication.md
+++ b/versioned_docs/version-0.9.22/04-concepts/03-database-communication.md
@@ -39,7 +39,7 @@ If you use the `database` or `api` options the field must be nullable.
 :::
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.22/04-concepts/06-modules.md b/versioned_docs/version-0.9.22/04-concepts/06-modules.md
index ca2956a8..9426b505 100644
--- a/versioned_docs/version-0.9.22/04-concepts/06-modules.md
+++ b/versioned_docs/version-0.9.22/04-concepts/06-modules.md
@@ -57,7 +57,7 @@ dependencies:
 ```
 
 ## Referencing a module
-It can be useful to reference serializable objects in other modules from the yaml-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass
@@ -84,4 +84,4 @@ In your Flutter package, you most likely want to import the client libraries cre
 
 Most modules will need a set of database tables to function. When naming the tables, you should use the module name as a prefix to the table name to avoid any conflicts. For instance, the Serverpod tables are prefixed with `serverpod_`.
 
-:::
\ No newline at end of file
+:::
diff --git a/versioned_docs/version-0.9.5/02-concepts/02-serialization.md b/versioned_docs/version-0.9.5/02-concepts/02-serialization.md
index 3c4759b3..db433d8a 100644
--- a/versioned_docs/version-0.9.5/02-concepts/02-serialization.md
+++ b/versioned_docs/version-0.9.5/02-concepts/02-serialization.md
@@ -1,7 +1,7 @@
 # Serialization
-Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.5/02-concepts/03-database-communication.md b/versioned_docs/version-0.9.5/02-concepts/03-database-communication.md
index e7b5600f..314f10da 100644
--- a/versioned_docs/version-0.9.5/02-concepts/03-database-communication.md
+++ b/versioned_docs/version-0.9.5/02-concepts/03-database-communication.md
@@ -27,7 +27,7 @@ fields:
 Likewise, if you only want a field to be accessible in the protocol but not stored in the server, you can add the `api` flag. By default, a field is accessible to both the API and the database.
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.6/02-concepts/02-serialization.md b/versioned_docs/version-0.9.6/02-concepts/02-serialization.md
index 3c4759b3..db433d8a 100644
--- a/versioned_docs/version-0.9.6/02-concepts/02-serialization.md
+++ b/versioned_docs/version-0.9.6/02-concepts/02-serialization.md
@@ -1,7 +1,7 @@
 # Serialization
-Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.6/02-concepts/03-database-communication.md b/versioned_docs/version-0.9.6/02-concepts/03-database-communication.md
index e7b5600f..314f10da 100644
--- a/versioned_docs/version-0.9.6/02-concepts/03-database-communication.md
+++ b/versioned_docs/version-0.9.6/02-concepts/03-database-communication.md
@@ -27,7 +27,7 @@ fields:
 Likewise, if you only want a field to be accessible in the protocol but not stored in the server, you can add the `api` flag. By default, a field is accessible to both the API and the database.
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.7/03-concepts/02-serialization.md b/versioned_docs/version-0.9.7/03-concepts/02-serialization.md
index 3c4759b3..db433d8a 100644
--- a/versioned_docs/version-0.9.7/03-concepts/02-serialization.md
+++ b/versioned_docs/version-0.9.7/03-concepts/02-serialization.md
@@ -1,7 +1,7 @@
 # Serialization
-Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.7/03-concepts/03-database-communication.md b/versioned_docs/version-0.9.7/03-concepts/03-database-communication.md
index e7b5600f..314f10da 100644
--- a/versioned_docs/version-0.9.7/03-concepts/03-database-communication.md
+++ b/versioned_docs/version-0.9.7/03-concepts/03-database-communication.md
@@ -27,7 +27,7 @@ fields:
 Likewise, if you only want a field to be accessible in the protocol but not stored in the server, you can add the `api` flag. By default, a field is accessible to both the API and the database.
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.8/03-concepts/02-serialization.md b/versioned_docs/version-0.9.8/03-concepts/02-serialization.md
index 3c4759b3..db433d8a 100644
--- a/versioned_docs/version-0.9.8/03-concepts/02-serialization.md
+++ b/versioned_docs/version-0.9.8/03-concepts/02-serialization.md
@@ -1,7 +1,7 @@
 # Serialization
-Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.8/03-concepts/03-database-communication.md b/versioned_docs/version-0.9.8/03-concepts/03-database-communication.md
index e7b5600f..314f10da 100644
--- a/versioned_docs/version-0.9.8/03-concepts/03-database-communication.md
+++ b/versioned_docs/version-0.9.8/03-concepts/03-database-communication.md
@@ -27,7 +27,7 @@ fields:
 Likewise, if you only want a field to be accessible in the protocol but not stored in the server, you can add the `api` flag. By default, a field is accessible to both the API and the database.
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.9/03-concepts/02-serialization.md b/versioned_docs/version-0.9.9/03-concepts/02-serialization.md
index 3c4759b3..db433d8a 100644
--- a/versioned_docs/version-0.9.9/03-concepts/02-serialization.md
+++ b/versioned_docs/version-0.9.9/03-concepts/02-serialization.md
@@ -1,7 +1,7 @@
 # Serialization
-Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database. The structure for the classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-0.9.9/03-concepts/03-database-communication.md b/versioned_docs/version-0.9.9/03-concepts/03-database-communication.md
index e7b5600f..314f10da 100644
--- a/versioned_docs/version-0.9.9/03-concepts/03-database-communication.md
+++ b/versioned_docs/version-0.9.9/03-concepts/03-database-communication.md
@@ -27,7 +27,7 @@ fields:
 Likewise, if you only want a field to be accessible in the protocol but not stored in the server, you can add the `api` flag. By default, a field is accessible to both the API and the database.
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-1.0.0/04-concepts/02-serialization.md b/versioned_docs/version-1.0.0/04-concepts/02-serialization.md
index cf6cd259..9445fa3a 100644
--- a/versioned_docs/version-1.0.0/04-concepts/02-serialization.md
+++ b/versioned_docs/version-1.0.0/04-concepts/02-serialization.md
@@ -2,9 +2,9 @@
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
 ## Serverpod's native serialization
-The structure for your serialized classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-1.0.0/04-concepts/03-database-communication.md b/versioned_docs/version-1.0.0/04-concepts/03-database-communication.md
index 5af51d94..388f59b3 100644
--- a/versioned_docs/version-1.0.0/04-concepts/03-database-communication.md
+++ b/versioned_docs/version-1.0.0/04-concepts/03-database-communication.md
@@ -39,7 +39,7 @@ If you use the `database` or `api` options the field must be nullable.
 :::
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-1.0.0/04-concepts/06-modules.md b/versioned_docs/version-1.0.0/04-concepts/06-modules.md
index ca2956a8..9426b505 100644
--- a/versioned_docs/version-1.0.0/04-concepts/06-modules.md
+++ b/versioned_docs/version-1.0.0/04-concepts/06-modules.md
@@ -57,7 +57,7 @@ dependencies:
 ```
 
 ## Referencing a module
-It can be useful to reference serializable objects in other modules from the yaml-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass
@@ -84,4 +84,4 @@ In your Flutter package, you most likely want to import the client libraries cre
 
 Most modules will need a set of database tables to function. When naming the tables, you should use the module name as a prefix to the table name to avoid any conflicts. For instance, the Serverpod tables are prefixed with `serverpod_`.
 
-:::
\ No newline at end of file
+:::
diff --git a/versioned_docs/version-1.1.0/04-concepts/02-serialization.md b/versioned_docs/version-1.1.0/04-concepts/02-serialization.md
index 47dc8b5c..2bac42f7 100644
--- a/versioned_docs/version-1.1.0/04-concepts/02-serialization.md
+++ b/versioned_docs/version-1.1.0/04-concepts/02-serialization.md
@@ -2,9 +2,9 @@
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
 ## Serverpod's native serialization
-The structure for your serialized classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-1.1.0/04-concepts/04-exceptions.md b/versioned_docs/version-1.1.0/04-concepts/04-exceptions.md
index edbe9fdf..b6e0db7d 100644
--- a/versioned_docs/version-1.1.0/04-concepts/04-exceptions.md
+++ b/versioned_docs/version-1.1.0/04-concepts/04-exceptions.md
@@ -10,7 +10,7 @@ Use the Serverpod Insights app to view your logs. It will show any failed or slo
 :::
 
 ## Serializable exceptions
-Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same yaml-files to define the serializable exceptions as you would with any serializable entity (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
+Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same YAML-files to define the serializable exceptions as you would with any serializable entity (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
 
 ```yaml
 exception: MyException
@@ -47,4 +47,4 @@ on (MyException) catch(e) {
 catch(e) {
   print('Something else went wrong.');
 }
-```
\ No newline at end of file
+```
diff --git a/versioned_docs/version-1.1.0/04-concepts/05-database-communication.md b/versioned_docs/version-1.1.0/04-concepts/05-database-communication.md
index d316818a..eb9a8e95 100644
--- a/versioned_docs/version-1.1.0/04-concepts/05-database-communication.md
+++ b/versioned_docs/version-1.1.0/04-concepts/05-database-communication.md
@@ -39,7 +39,7 @@ If you use the `database` or `api` options the field must be nullable.
 :::
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-1.1.0/04-concepts/08-modules.md b/versioned_docs/version-1.1.0/04-concepts/08-modules.md
index ca2956a8..9426b505 100644
--- a/versioned_docs/version-1.1.0/04-concepts/08-modules.md
+++ b/versioned_docs/version-1.1.0/04-concepts/08-modules.md
@@ -57,7 +57,7 @@ dependencies:
 ```
 
 ## Referencing a module
-It can be useful to reference serializable objects in other modules from the yaml-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass
@@ -84,4 +84,4 @@ In your Flutter package, you most likely want to import the client libraries cre
 
 Most modules will need a set of database tables to function. When naming the tables, you should use the module name as a prefix to the table name to avoid any conflicts. For instance, the Serverpod tables are prefixed with `serverpod_`.
 
-:::
\ No newline at end of file
+:::
diff --git a/versioned_docs/version-1.1.1/01-get-started.md b/versioned_docs/version-1.1.1/01-get-started.md
index bf8cc145..7b60dd2f 100644
--- a/versioned_docs/version-1.1.1/01-get-started.md
+++ b/versioned_docs/version-1.1.1/01-get-started.md
@@ -109,9 +109,9 @@ To learn more about endpoints, see the [Working with endpoints](concepts/working
 ### Serializing data
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
-The structure for your serialized classes is defined in yaml-files in the `lib/src/protocol` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `lib/src/protocol` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
@@ -204,4 +204,4 @@ Working with a database is an extensive subject. Learn more in the [Database com
 ## Where to go next
 You should now have a basic understanding of how Serverpod works. The different topics are described in more detail in the _Concepts_ section of the documentation. If you are unfamiliar with server-side development, a good staring place for learning is to do the [Build your first app](tutorials/first-app) tutorial. There are also many good video tutorials linked in the _Tutorials_ section.
 
-If you get stuck, never be afraid to ask questions in our [community on Github](https://github.com/serverpod/serverpod/discussions). The Serverpod team is very active there, and many questions are also answered by other developers in the community.
\ No newline at end of file
+If you get stuck, never be afraid to ask questions in our [community on Github](https://github.com/serverpod/serverpod/discussions). The Serverpod team is very active there, and many questions are also answered by other developers in the community.
diff --git a/versioned_docs/version-1.1.1/05-concepts/02-serialization.md b/versioned_docs/version-1.1.1/05-concepts/02-serialization.md
index 47dc8b5c..2bac42f7 100644
--- a/versioned_docs/version-1.1.1/05-concepts/02-serialization.md
+++ b/versioned_docs/version-1.1.1/05-concepts/02-serialization.md
@@ -2,9 +2,9 @@
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
 ## Serverpod's native serialization
-The structure for your serialized classes is defined in yaml-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `protocol` directory. Run `serverpod generate` to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-1.1.1/05-concepts/04-exceptions.md b/versioned_docs/version-1.1.1/05-concepts/04-exceptions.md
index edbe9fdf..b6e0db7d 100644
--- a/versioned_docs/version-1.1.1/05-concepts/04-exceptions.md
+++ b/versioned_docs/version-1.1.1/05-concepts/04-exceptions.md
@@ -10,7 +10,7 @@ Use the Serverpod Insights app to view your logs. It will show any failed or slo
 :::
 
 ## Serializable exceptions
-Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same yaml-files to define the serializable exceptions as you would with any serializable entity (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
+Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same YAML-files to define the serializable exceptions as you would with any serializable entity (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
 
 ```yaml
 exception: MyException
@@ -47,4 +47,4 @@ on (MyException) catch(e) {
 catch(e) {
   print('Something else went wrong.');
 }
-```
\ No newline at end of file
+```
diff --git a/versioned_docs/version-1.1.1/05-concepts/05-database-communication.md b/versioned_docs/version-1.1.1/05-concepts/05-database-communication.md
index 20ecb48b..a1215b5f 100644
--- a/versioned_docs/version-1.1.1/05-concepts/05-database-communication.md
+++ b/versioned_docs/version-1.1.1/05-concepts/05-database-communication.md
@@ -39,7 +39,7 @@ If you use the `database` or `api` options the field must be nullable.
 :::
 
 ### Database indexes
-For performance reasons, you may want to add indexes to your database tables. You add these in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. You add these in the YAML-files defining the serializable objects.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-1.1.1/05-concepts/08-modules.md b/versioned_docs/version-1.1.1/05-concepts/08-modules.md
index 23103ae4..e28c4b23 100644
--- a/versioned_docs/version-1.1.1/05-concepts/08-modules.md
+++ b/versioned_docs/version-1.1.1/05-concepts/08-modules.md
@@ -64,7 +64,7 @@ dependencies:
 
 ## Referencing a module
 
-It can be useful to reference serializable objects in other modules from the yaml-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your protocol directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass
diff --git a/versioned_docs/version-1.2.0/01-get-started.md b/versioned_docs/version-1.2.0/01-get-started.md
index f779693a..047228a3 100644
--- a/versioned_docs/version-1.2.0/01-get-started.md
+++ b/versioned_docs/version-1.2.0/01-get-started.md
@@ -115,9 +115,9 @@ To learn more about endpoints, see the [Working with endpoints](concepts/working
 ### Serializing data
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
-The structure for your serialized classes is defined in yaml-files in the `lib/src/models` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `lib/src/models` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-1.2.0/05-concepts/04-exceptions.md b/versioned_docs/version-1.2.0/05-concepts/04-exceptions.md
index 0fd3a6fb..a74c880a 100644
--- a/versioned_docs/version-1.2.0/05-concepts/04-exceptions.md
+++ b/versioned_docs/version-1.2.0/05-concepts/04-exceptions.md
@@ -10,7 +10,7 @@ Use the Serverpod Insights app to view your logs. It will show any failed or slo
 :::
 
 ## Serializable exceptions
-Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same yaml-files to define the serializable exceptions as you would with any serializable model (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
+Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same YAML-files to define the serializable exceptions as you would with any serializable model (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
 
 ```yaml
 exception: MyException
diff --git a/versioned_docs/version-1.2.0/05-concepts/06-database/04-indexing.md b/versioned_docs/version-1.2.0/05-concepts/06-database/04-indexing.md
index 71fe56ac..7caef4ce 100644
--- a/versioned_docs/version-1.2.0/05-concepts/06-database/04-indexing.md
+++ b/versioned_docs/version-1.2.0/05-concepts/06-database/04-indexing.md
@@ -1,9 +1,9 @@
 # Indexing
 
-For performance reasons, you may want to add indexes to your database tables. These are added in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. These are added in the YAML-files defining the serializable objects.
 
 ### Add an index
-To add an index, add an `indexes` section to the yaml-file. The `indexes` section is a map where the key is the name of the index and the value is a map with the index details.
+To add an index, add an `indexes` section to the YAML-file. The `indexes` section is a map where the key is the name of the index and the value is a map with the index details.
 
 ```yaml
 class: Company
@@ -57,4 +57,4 @@ indexes:
     fields: name
     type: brin
 ```
-If no type is specified the default is `btree`. All [PostgreSQL index types](https://www.postgresql.org/docs/current/indexes-types.html) are supported, `btree`, `hash`, `gist`, `spgist`, `gin`, `brin`.
\ No newline at end of file
+If no type is specified the default is `btree`. All [PostgreSQL index types](https://www.postgresql.org/docs/current/indexes-types.html) are supported, `btree`, `hash`, `gist`, `spgist`, `gin`, `brin`.
diff --git a/versioned_docs/version-1.2.0/05-concepts/09-modules.md b/versioned_docs/version-1.2.0/05-concepts/09-modules.md
index 6328b6c8..eee00e5c 100644
--- a/versioned_docs/version-1.2.0/05-concepts/09-modules.md
+++ b/versioned_docs/version-1.2.0/05-concepts/09-modules.md
@@ -68,7 +68,7 @@ dependencies:
 
 ## Referencing a module
 
-It can be useful to reference serializable objects in other modules from the yaml-files in your model directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your model directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass
diff --git a/versioned_docs/version-2.0.0/01-get-started.md b/versioned_docs/version-2.0.0/01-get-started.md
index 75e1c323..d16ff989 100644
--- a/versioned_docs/version-2.0.0/01-get-started.md
+++ b/versioned_docs/version-2.0.0/01-get-started.md
@@ -131,9 +131,9 @@ To learn more about endpoints, see the [Working with endpoints](concepts/working
 
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
-The structure for your serialized classes is defined in yaml-files in the `lib/src/models` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `lib/src/models` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-2.0.0/05-concepts/04-exceptions.md b/versioned_docs/version-2.0.0/05-concepts/04-exceptions.md
index f53d61ac..21152af4 100644
--- a/versioned_docs/version-2.0.0/05-concepts/04-exceptions.md
+++ b/versioned_docs/version-2.0.0/05-concepts/04-exceptions.md
@@ -12,7 +12,7 @@ Use the Serverpod Insights app to view your logs. It will show any failed or slo
 
 ## Serializable exceptions
 
-Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same yaml-files to define the serializable exceptions as you would with any serializable model (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
+Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same YAML-files to define the serializable exceptions as you would with any serializable model (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
 
 ```yaml
 exception: MyException
diff --git a/versioned_docs/version-2.0.0/05-concepts/06-database/04-indexing.md b/versioned_docs/version-2.0.0/05-concepts/06-database/04-indexing.md
index 8bae058f..f28ae772 100644
--- a/versioned_docs/version-2.0.0/05-concepts/06-database/04-indexing.md
+++ b/versioned_docs/version-2.0.0/05-concepts/06-database/04-indexing.md
@@ -1,10 +1,10 @@
 # Indexing
 
-For performance reasons, you may want to add indexes to your database tables. These are added in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. These are added in the YAML-files defining the serializable objects.
 
 ### Add an index
 
-To add an index, add an `indexes` section to the yaml-file. The `indexes` section is a map where the key is the name of the index and the value is a map with the index details.
+To add an index, add an `indexes` section to the YAML-file. The `indexes` section is a map where the key is the name of the index and the value is a map with the index details.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-2.0.0/05-concepts/09-modules.md b/versioned_docs/version-2.0.0/05-concepts/09-modules.md
index 6dab7425..0d2c1334 100644
--- a/versioned_docs/version-2.0.0/05-concepts/09-modules.md
+++ b/versioned_docs/version-2.0.0/05-concepts/09-modules.md
@@ -67,7 +67,7 @@ dependencies:
 
 ## Referencing a module
 
-It can be useful to reference serializable objects in other modules from the yaml-files in your model directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your model directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass
diff --git a/versioned_docs/version-2.1.0/01-get-started.md b/versioned_docs/version-2.1.0/01-get-started.md
index 7207ec55..e4d74993 100644
--- a/versioned_docs/version-2.1.0/01-get-started.md
+++ b/versioned_docs/version-2.1.0/01-get-started.md
@@ -167,9 +167,9 @@ To learn more about endpoints, see the [Working with endpoints](concepts/working
 
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
-The structure for your serialized classes is defined in yaml-files in the `lib/src/models` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `lib/src/models` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-2.1.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.1.0/06-concepts/04-exceptions.md
index 85800db8..e4baa660 100644
--- a/versioned_docs/version-2.1.0/06-concepts/04-exceptions.md
+++ b/versioned_docs/version-2.1.0/06-concepts/04-exceptions.md
@@ -12,7 +12,7 @@ Use the Serverpod Insights app to view your logs. It will show any failed or slo
 
 ## Serializable exceptions
 
-Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same yaml-files to define the serializable exceptions as you would with any serializable model (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
+Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same YAML-files to define the serializable exceptions as you would with any serializable model (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
 
 ```yaml
 exception: MyException
diff --git a/versioned_docs/version-2.1.0/06-concepts/06-database/04-indexing.md b/versioned_docs/version-2.1.0/06-concepts/06-database/04-indexing.md
index 8bae058f..f28ae772 100644
--- a/versioned_docs/version-2.1.0/06-concepts/06-database/04-indexing.md
+++ b/versioned_docs/version-2.1.0/06-concepts/06-database/04-indexing.md
@@ -1,10 +1,10 @@
 # Indexing
 
-For performance reasons, you may want to add indexes to your database tables. These are added in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. These are added in the YAML-files defining the serializable objects.
 
 ### Add an index
 
-To add an index, add an `indexes` section to the yaml-file. The `indexes` section is a map where the key is the name of the index and the value is a map with the index details.
+To add an index, add an `indexes` section to the YAML-file. The `indexes` section is a map where the key is the name of the index and the value is a map with the index details.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-2.1.0/06-concepts/10-modules.md b/versioned_docs/version-2.1.0/06-concepts/10-modules.md
index 6dab7425..0d2c1334 100644
--- a/versioned_docs/version-2.1.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.1.0/06-concepts/10-modules.md
@@ -67,7 +67,7 @@ dependencies:
 
 ## Referencing a module
 
-It can be useful to reference serializable objects in other modules from the yaml-files in your model directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your model directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass
diff --git a/versioned_docs/version-2.2.0/01-get-started.md b/versioned_docs/version-2.2.0/01-get-started.md
index 7207ec55..e4d74993 100644
--- a/versioned_docs/version-2.2.0/01-get-started.md
+++ b/versioned_docs/version-2.2.0/01-get-started.md
@@ -167,9 +167,9 @@ To learn more about endpoints, see the [Working with endpoints](concepts/working
 
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
-The structure for your serialized classes is defined in yaml-files in the `lib/src/models` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in YAML-files in the `lib/src/models` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a yaml-file defining a serializable class:
+Here is a simple example of a YAML-file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-2.2.0/06-concepts/04-exceptions.md b/versioned_docs/version-2.2.0/06-concepts/04-exceptions.md
index 85800db8..e4baa660 100644
--- a/versioned_docs/version-2.2.0/06-concepts/04-exceptions.md
+++ b/versioned_docs/version-2.2.0/06-concepts/04-exceptions.md
@@ -12,7 +12,7 @@ Use the Serverpod Insights app to view your logs. It will show any failed or slo
 
 ## Serializable exceptions
 
-Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same yaml-files to define the serializable exceptions as you would with any serializable model (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
+Serverpod allows adding data to an exception you throw on the server and extracting that data in the client. This is useful for passing error messages back to the client when a call fails. You use the same YAML-files to define the serializable exceptions as you would with any serializable model (see [serialization](serialization) for details). The only difference is that you use the keyword `exception` instead of `class`.
 
 ```yaml
 exception: MyException
diff --git a/versioned_docs/version-2.2.0/06-concepts/06-database/04-indexing.md b/versioned_docs/version-2.2.0/06-concepts/06-database/04-indexing.md
index 8bae058f..f28ae772 100644
--- a/versioned_docs/version-2.2.0/06-concepts/06-database/04-indexing.md
+++ b/versioned_docs/version-2.2.0/06-concepts/06-database/04-indexing.md
@@ -1,10 +1,10 @@
 # Indexing
 
-For performance reasons, you may want to add indexes to your database tables. These are added in the yaml-files defining the serializable objects.
+For performance reasons, you may want to add indexes to your database tables. These are added in the YAML-files defining the serializable objects.
 
 ### Add an index
 
-To add an index, add an `indexes` section to the yaml-file. The `indexes` section is a map where the key is the name of the index and the value is a map with the index details.
+To add an index, add an `indexes` section to the YAML-file. The `indexes` section is a map where the key is the name of the index and the value is a map with the index details.
 
 ```yaml
 class: Company
diff --git a/versioned_docs/version-2.2.0/06-concepts/10-modules.md b/versioned_docs/version-2.2.0/06-concepts/10-modules.md
index 6dab7425..0d2c1334 100644
--- a/versioned_docs/version-2.2.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.2.0/06-concepts/10-modules.md
@@ -67,7 +67,7 @@ dependencies:
 
 ## Referencing a module
 
-It can be useful to reference serializable objects in other modules from the yaml-files in your model directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
+It can be useful to reference serializable objects in other modules from the YAML-files in your model directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
 
 ```yaml
 class: MyClass

From 73d3ac21156491c785a46f59ca7ad32a31901743 Mon Sep 17 00:00:00 2001
From: Alexander Sandor <alexander@serverpod.dev>
Date: Fri, 13 Dec 2024 15:14:41 +0100
Subject: [PATCH 5/6] fix(review): add leading dot when presenting extension.

---
 docs/01-get-started.md           | 4 ++--
 docs/02-get-started-with-mini.md | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/01-get-started.md b/docs/01-get-started.md
index 8fe6a133..95a2d73b 100644
--- a/docs/01-get-started.md
+++ b/docs/01-get-started.md
@@ -167,9 +167,9 @@ To learn more about endpoints, see the [Working with endpoints](concepts/working
 
 Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.
 
-The structure for your serialized classes is defined in `spy.yaml` files anywhere in the `lib` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
+The structure for your serialized classes is defined in `.spy.yaml` files anywhere in the `lib` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
 
-Here is a simple example of a `spy.yaml` file defining a serializable class:
+Here is a simple example of a `.spy.yaml` file defining a serializable class:
 
 ```yaml
 class: Company
diff --git a/docs/02-get-started-with-mini.md b/docs/02-get-started-with-mini.md
index 9a305c60..b85c171f 100644
--- a/docs/02-get-started-with-mini.md
+++ b/docs/02-get-started-with-mini.md
@@ -36,7 +36,7 @@ If you are using VS Code, install our Serverpod extension. It will help you vali
 :::
 
 ## Creating models
-In Serverpod, you define your models in easy-to-read YAML-files, which you place anywhere in your server’s `lib` directory with the `spy.yaml` extension. Model files will be converted to Dart classes that can be serialized and sent to and from the server to your app. This is an example of a model file:
+In Serverpod, you define your models in easy-to-read YAML-files, which you place anywhere in your server’s `lib` directory with the `.spy.yaml` extension. Model files will be converted to Dart classes that can be serialized and sent to and from the server to your app. This is an example of a model file:
 
 ```yaml
 class: Company

From 23139d7ee019aef4934b400cfc636e6ea30d0e37 Mon Sep 17 00:00:00 2001
From: Alexander Sandor <alexander@serverpod.dev>
Date: Fri, 13 Dec 2024 15:16:12 +0100
Subject: [PATCH 6/6] fix(review): Fix typo in explanation

---
 docs/06-concepts/02-models.md                         | 2 +-
 versioned_docs/version-1.2.0/05-concepts/02-models.md | 2 +-
 versioned_docs/version-2.0.0/05-concepts/02-models.md | 2 +-
 versioned_docs/version-2.1.0/06-concepts/02-models.md | 2 +-
 versioned_docs/version-2.2.0/06-concepts/02-models.md | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/06-concepts/02-models.md b/docs/06-concepts/02-models.md
index f6d24b00..e807f617 100644
--- a/docs/06-concepts/02-models.md
+++ b/docs/06-concepts/02-models.md
@@ -2,7 +2,7 @@
 
 Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server.
 
-Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Server Pod Yaml"). Using this file type allows placing the model files anywhere in your servers `lib` directory and enables syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
+Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Serverpod YAML"). Using this file type allows placing the model files anywhere in your servers `lib` directory and enables syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
 
 The files are analyzed by the Serverpod CLI when generating the project and creating migrations.
 
diff --git a/versioned_docs/version-1.2.0/05-concepts/02-models.md b/versioned_docs/version-1.2.0/05-concepts/02-models.md
index 47fdce8f..d6a2ea9c 100644
--- a/versioned_docs/version-1.2.0/05-concepts/02-models.md
+++ b/versioned_docs/version-1.2.0/05-concepts/02-models.md
@@ -1,6 +1,6 @@
 # Working with models
 
-Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server. Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Server Pod Yaml") to leverage syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
+Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server. Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Serverpod YAML") to leverage syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
 
 The files are analyzed by the Serverpod CLI when generating the project and creating migrations.
 
diff --git a/versioned_docs/version-2.0.0/05-concepts/02-models.md b/versioned_docs/version-2.0.0/05-concepts/02-models.md
index 47fdce8f..d6a2ea9c 100644
--- a/versioned_docs/version-2.0.0/05-concepts/02-models.md
+++ b/versioned_docs/version-2.0.0/05-concepts/02-models.md
@@ -1,6 +1,6 @@
 # Working with models
 
-Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server. Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Server Pod Yaml") to leverage syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
+Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server. Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Serverpod YAML") to leverage syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
 
 The files are analyzed by the Serverpod CLI when generating the project and creating migrations.
 
diff --git a/versioned_docs/version-2.1.0/06-concepts/02-models.md b/versioned_docs/version-2.1.0/06-concepts/02-models.md
index d7cd3b02..ad6de85c 100644
--- a/versioned_docs/version-2.1.0/06-concepts/02-models.md
+++ b/versioned_docs/version-2.1.0/06-concepts/02-models.md
@@ -1,6 +1,6 @@
 # Working with models
 
-Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server. Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Server Pod Yaml") to leverage syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
+Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server. Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Serverpod YAML") to leverage syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
 
 The files are analyzed by the Serverpod CLI when generating the project and creating migrations.
 
diff --git a/versioned_docs/version-2.2.0/06-concepts/02-models.md b/versioned_docs/version-2.2.0/06-concepts/02-models.md
index 103805a9..bd80dadd 100644
--- a/versioned_docs/version-2.2.0/06-concepts/02-models.md
+++ b/versioned_docs/version-2.2.0/06-concepts/02-models.md
@@ -1,6 +1,6 @@
 # Working with models
 
-Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server. Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Server Pod Yaml") to leverage syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
+Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server. Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Serverpod YAML") to leverage syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
 
 The files are analyzed by the Serverpod CLI when generating the project and creating migrations.