@powerhousedao/academy 5.0.0-staging.9 → 5.0.1-staging.3

package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/03-BuilderTools.md

@@ -1,23 +1,27 @@
 # Powerhouse builder tooling
 
-This page provides an overview of all the builder tooling offered by the Powerhouse ecosystem.   
+This page provides an overview of all the builder tooling offered by the Powerhouse ecosystem.  
 This list will be maintained and updated as our toolkit grows.
 
 ## Powerhouse command line interface
-___
 
-### Installing the Powerhouse CLI 
+---
+
+### Installing the Powerhouse CLI
+
 :::tip
-The Powerhouse CLI tool is the only essential tool to install on this page.   
+The Powerhouse CLI tool is the only essential tool to install on this page.  
 Once you've installed it with the command below you can continue to the next steps.
 :::
 
 The Powerhouse CLI (`ph-cmd`) is a command-line interface tool that provides essential commands for managing Powerhouse projects. You can get access to the Powerhouse ecosystem tools by installing them globally using:
+
 ```bash
 pnpm install -g ph-cmd
-``` 
+```
 
 Key commands include:
+
 - `ph connect` for running the Connect application locally
 - `ph switchboard` or `ph reactor` for starting the API service
 - `ph init` to start a new project and build a Document Model
@@ -30,19 +34,20 @@ This tool will be fundamental on your journey when creating, building, and runni
 
 When installing or using the Powerhouse CLI commands you are able to make use of the dev & staging branches. These branches contain more experimental features then the latest stable release the PH CLI uses by default. They can be used to get access to a bugfix or features under development.
 
-| Command | Description |
-|---------|-------------|
-| **pnpm install -g ph-cmd** | Install latest stable version |
-| **pnpm install -g ph-cmd@dev** | Install development version |
-| **pnpm install -g ph-cmd@staging** | Install staging version |
-| **ph init** | Use latest stable version of the boilerplate |
-| **ph init --dev** | Use development version of the boilerplate |
-| **ph init --staging** | Use staging version of the boilerplate |
-| **ph use** | Switch all dependencies to latest production versions |
-| **ph use dev** | Switch all dependencies to development versions |
-| **ph use prod** | Switch all dependencies to production versions |
+| Command                            | Description                                           |
+| ---------------------------------- | ----------------------------------------------------- |
+| **pnpm install -g ph-cmd**         | Install latest stable version                         |
+| **pnpm install -g ph-cmd@dev**     | Install development version                           |
+| **pnpm install -g ph-cmd@staging** | Install staging version                               |
+| **ph init**                        | Use latest stable version of the boilerplate          |
+| **ph init --dev**                  | Use development version of the boilerplate            |
+| **ph init --staging**              | Use staging version of the boilerplate                |
+| **ph use**                         | Switch all dependencies to latest production versions |
+| **ph use dev**                     | Switch all dependencies to development versions       |
+| **ph use prod**                    | Switch all dependencies to production versions        |
 
 Please be aware that these versions can contain bugs and experimental features that aren't fully tested.
+
 </details>
 
 <details>
@@ -54,16 +59,19 @@ Please be aware that these versions can contain bugs and experimental features t
 If you need to perform a clean reinstallation of the Powerhouse CLI (`ph-cmd`), follow these steps:
 
 1. First, uninstall the global ph-cmd package:
+
 ```bash
 pnpm uninstall -g ph-cmd
 ```
 
 2. Remove the Powerhouse configuration directory:
+
 ```bash
 rm -rf ~/.ph
 ```
 
 3. Reinstall the CLI tool (choose one):
+
 ```bash
 # For the latest stable version
 pnpm install -g ph-cmd
@@ -76,20 +84,24 @@ pnpm install -g ph-cmd@<version>
 ```
 
 This process ensures a clean slate by removing both the CLI tool and its configuration files before installing the desired version. It's particularly useful when:
+
 - Troubleshooting CLI issues
 - Upgrading to a new version
 - Switching between stable and staging versions
-- Resolving configuration conflicts 			
+- Resolving configuration conflicts
 
 </details>
 
 ### The use command
+
 The use command allows you to switch between different environments for your Powerhouse project dependencies.
 
 ```bash
 ph use <environment> [localPath]
-``` 
+```
+
 **Available Environments**
+
 - latest - Uses the latest stable version of all Powerhouse packages.
 - dev - Uses development versions of the packages.
 - prod - Uses production versions of the packages.
@@ -98,26 +110,31 @@ ph use <environment> [localPath]
 **Examples**
 
 #### Switch to latest stable versions
+
 ```bash
 ph use latest
-``` 
+```
 
 #### Switch to development versions
+
 ```bash
 ph use dev
-``` 
+```
 
 #### Use local versions from a specific path
+
 ```bash
 ph use local /path/to/local/packages
-``` 
+```
 
 #### Use a specific package manager
+
 ```bash
 ph use latest --package-manager pnpm
-``` 
+```
 
 ### The update command
+
 The update command allows you to update your Powerhouse dependencies to their latest versions based on the version ranges specified in your package.json.
 
 ```bash
@@ -125,22 +142,27 @@ ph update [options]
 ```
 
 **Examples**
+
 #### Update dependencies based on package.json ranges
+
 ```bash
 ph update
 ```
 
 #### Force update to latest dev versions
+
 ```bash
 ph update --force dev
 ```
 
 #### Force update to latest stable versions
+
 ```bash
 ph update --force prod
 ```
 
 #### Use a specific package manager
+
 ```bash
 ph update --package-manager pnpm
 ```
@@ -148,11 +170,13 @@ ph update --package-manager pnpm
 ## **Key differences**
 
 ### **Use command**
+
 - For switching between different **environments**.
 - Requires you to specify an environment.
 - Can work with **local packages**.
 
 ### **Update command**
+
 - Updating **dependencies** within your current environment.
 - Optional with its parameters.
 - Focused on updating **remote package** versions.
@@ -160,12 +184,15 @@ ph update --package-manager pnpm
 Both commands support multiple package managers (npm, yarn, pnpm, and bun) and will automatically detect your project's package manager based on the lockfile present in your project directory.
 
 ## Boilerplate
-___
-The Document Model Boilerplate is a foundational template that is used for code generation when scaffolding your editors and models. It ensures compatibility with host applications like Connect and Switchboard for seamless Document Model and editor integration. 
 
-After installing `ph-cmd`, you will run `ph init` to initialize a project directory and structure. This initialization command makes use of the boilerplate. 
+---
+
+The Document Model Boilerplate is a foundational template that is used for code generation when scaffolding your editors and models. It ensures compatibility with host applications like Connect and Switchboard for seamless Document Model and editor integration.
+
+After installing `ph-cmd`, you will run `ph init` to initialize a project directory and structure. This initialization command makes use of the boilerplate.
 
 The boilerplate includes essential commands with NPM/PNPM scripts for:
+
 - Generating code
 - Linting
 - Formatting
@@ -173,8 +200,11 @@ The boilerplate includes essential commands with NPM/PNPM scripts for:
 - Testing
 
 ## Design system
-___
+
+---
+
 The Powerhouse Design System is a collection of reusable front-end components based on GraphQL scalars, including custom scalars specific to the web3 ecosystem. It provides:
+
 - Consistent UI components across Powerhouse applications
 - Automatic inclusion as a dependency in new Document Model projects
 - Customization options using CSS variables
@@ -182,29 +212,37 @@ The Powerhouse Design System is a collection of reusable front-end components ba
 We cover some of these topics in our design system documentation. Read more about the [design system here](/academy/ComponentLibrary/DocumentEngineering)
 
 ## Reactor libraries
-___
-Reactors are the nodes in the Powerhouse network that handle document storage, conflict resolution, and operation verification. 
+
+---
+
+Reactors are the nodes in the Powerhouse network that handle document storage, conflict resolution, and operation verification.
 The Reactor Libraries include:
 
 ### API
+
 - **Subgraphs**: Modular GraphQL services that connect to the Reactor for structured data access
 - **Processors**: Event-driven components that react to document changes and process data
 
 ### Browser
+
 Handles client-side interactions
 
 ### Local
+
 Manages local storage and offline functionality
 
 ### Drive app
-Handles document organization and storage management, but can also be customized to offer specific functionality, categorization, or tailored interfaces for your documents. 
+
+Handles document organization and storage management, but can also be customized to offer specific functionality, categorization, or tailored interfaces for your documents.
 
 ## Code generators
-___
+
+---
+
 Powerhouse provides several code generation tools to streamline development:
 
     ### Document model scaffolding
-    Generates the basic structure for new Document Models with the command `ph init` based on the boilerplate. 
+    Generates the basic structure for new Document Models with the command `ph init` based on the boilerplate.
 
     ### Editor generator
     Creates template code for Document Model editors with the command `ph generate --editor <name> --document-types <documenttype>`
@@ -222,14 +260,18 @@ Powerhouse provides several code generation tools to streamline development:
     Creates specialized processors for analytics tracking
 
 ## Analytics engine
-___
+
+---
+
 The Analytics Engine is a system that allows tracking and analyzing operations and state changes on Document Models. Features include:
+
 - Custom dashboard and report generation
 - Document Model-specific analytics
 - Metric and dimension tracking
 - Data combination from multiple Document Models
 
 Generate an analytics processor using:
+
 ```bash
 ph generate --processor-type analytics
-```
+```

package/docs/academy/02-MasteryTrack/01-BuilderEnvironment/_category_.json

@@ -1,7 +1,7 @@
 {
-    "label": "Builder environment",
-    "link": {
-      "type": "doc",
-      "id": "academy/MasteryTrack/BuilderEnvironment/Prerequisites"
-    }
-  }
+  "label": "Builder environment",
+  "link": {
+    "type": "doc",
+    "id": "academy/MasteryTrack/BuilderEnvironment/Prerequisites"
+  }
+}

package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/01-WhatIsADocumentModel.md

@@ -1,20 +1,21 @@
 # What is a document model?
 
 :::tip
-This chapter on **Document Model Creation** will help you with an in depth practicial understanding while building an **advanced to-do list** document model. 
+This chapter on **Document Model Creation** will help you with an in depth practicial understanding while building an **advanced to-do list** document model.
 Although not required, if you have completed the 'Get Started' tutorial you will revisit familiar topics and can update your existing document model.
 :::
 
 :::info **Definition: What is a Document Model?**
 A Document Model is a programmable document structure that defines how data is stored, changed, and interpreted in a decentralized system. It acts like a living blueprint—capturing state, tracking changes, and enabling interaction through defined operations.
 
-For instance, an invoice document model might define fields like *issuer*, *lineItems*, and *status*, with operations such as *AddLineItem* and *MarkAsPaid*.
+For instance, an invoice document model might define fields like _issuer_, _lineItems_, and _status_, with operations such as _AddLineItem_ and _MarkAsPaid_.
 :::
 
-A Document Model can be understood as: 
-- A structured software framework that represents and **manages business logic** within a digital environment. 
-- A sophisticated template that **encapsulates the essential aspects of a digital process or a set of data**. 
-- A blueprints that define how data is **captured, manipulated, and visualised** within a system. 
+A Document Model can be understood as:
+
+- A structured software framework that represents and **manages business logic** within a digital environment.
+- A sophisticated template that **encapsulates the essential aspects of a digital process or a set of data**.
+- A blueprints that define how data is **captured, manipulated, and visualised** within a system.
 - A **standardized way to store, modify, and query data** in scalable, decentralized applications.
 
 ### **How does a document model function?**
@@ -27,7 +28,7 @@ Each document model consists of three key components:
 2. **Document Operations** – Defines how the document can be modified.
 3. **Event History** – Maintains an append-only log of changes.
 
-Document models leverage **event sourcing, CQRS (Command Query Responsibility Segregation), and an append-only architecture** to ensure immutability, auditability, and scalability. 
+Document models leverage **event sourcing, CQRS (Command Query Responsibility Segregation), and an append-only architecture** to ensure immutability, auditability, and scalability.
 
 ---
 
@@ -43,19 +44,19 @@ Example of a **GraphQL-like state schema** for an invoice document:
 
 ```graphql
 type InvoiceState {
-  id: OID!                # Unique identifier for the invoice
-  issuer: OID!            # Reference to the issuing entity
-  recipient: OID!         # Reference to the recipient entity
-  status: String          # (value: "DRAFT") # Invoice status
-  dueDate: DateTime       # Payment due date
+  id: OID! # Unique identifier for the invoice
+  issuer: OID! # Reference to the issuing entity
+  recipient: OID! # Reference to the recipient entity
+  status: String # (value: "DRAFT") # Invoice status
+  dueDate: DateTime # Payment due date
   lineItems: [LineItem!]! # List of line items
-  totalAmount: Currency   # Computed field for total invoice value
+  totalAmount: Currency # Computed field for total invoice value
 }
 
 type LineItem {
   id: OID!
   description: String
-  quantity: Int 
+  quantity: Int
   unitPrice: Currency
 }
 ```
@@ -80,7 +81,7 @@ Example operations for modifying an invoice:
 input AddLineItemInput {
   invoiceId: OID!
   description: String
-  quantity: Int 
+  quantity: Int
   unitPrice: Currency
 }
 
@@ -94,7 +95,7 @@ input MarkAsPaidInput {
 }
 ```
 
-Each operation **modifies the document state** without altering past data.    
+Each operation **modifies the document state** without altering past data.  
 Instead, a new event is appended to the document history.
 
 ---
@@ -109,7 +110,7 @@ Every operation applied to a document is **stored as an event** in an append-onl
 [
   { "timestamp": 1700000001, "operation": "CREATE_INVOICE", "data": { "id": "inv-001", "issuer": "company-123", "recipient": "client-456" } },
   { "timestamp": 1700000100, "operation": "ADD_LINE_ITEM", "data": { "description": "Software Development", "quantity": 10, "unitPrice": 100 } },
-  { "timestamp": 1700000200, "operation": "MARK_AS_PAID", "data": {} 
+  { "timestamp": 1700000200, "operation": "MARK_AS_PAID", "data": {}
 ```
 
 ### **Event history benefits:**
@@ -136,7 +137,11 @@ Document models in Powerhouse rely on **event-driven architecture, event sourcin
 ```json
 {
   "operation": "CREATE_INVOICE",
-  "data": { "id": "inv-001", "issuer": "company-123", "recipient": "client-456" }
+  "data": {
+    "id": "inv-001",
+    "issuer": "company-123",
+    "recipient": "client-456"
+  }
 }
 ```
 
@@ -155,7 +160,11 @@ Adding a line item:
 ```json
 {
   "operation": "ADD_LINE_ITEM",
-  "data": { "description": "Software Development", "quantity": 10, "unitPrice": 100 }
+  "data": {
+    "description": "Software Development",
+    "quantity": 10,
+    "unitPrice": 100
+  }
 }
 ```
 
@@ -198,8 +207,8 @@ Document Models offer a range of features that can be leveraged to create sophis
 - **Collaboration**: Empower decentralized teams to build, modify, and share documents asynchronously.
 - **Extensibility**: Add new fields, operations, and integrations over time without rewriting logic.
 
-Document Models are a powerful primitive within the Powerhouse vision, offering a flexible, structured, and efficient way to manage business logic and data. 
+Document Models are a powerful primitive within the Powerhouse vision, offering a flexible, structured, and efficient way to manage business logic and data.
 
 ### Up next: How to build a document model
 
-In the next chapters, we'll teach you how to build a To-do List document model while explaining all of the theory that is involved.
+In the next chapters, we'll teach you how to build a To-do List document model while explaining all of the theory that is involved.

package/docs/academy/02-MasteryTrack/02-DocumentModelCreation/02-SpecifyTheStateSchema.md

@@ -5,29 +5,34 @@ The state schema is the backbone of your document model. It defines the structur
 ## Core concepts
 
 ### Types
+
 At the heart of GraphQL SDL are **types**. Types define the shape of your data. You can define custom object types that represent the entities in your document. For example, in a `ToDoList` document, you might have a `ToDoListState` type and a `ToDoItem` type.
 
-*   **`ToDoListState`**: This could be the root type representing the overall state of the to-do list. It might contain a list of `ToDoItem` objects.
-*   **`ToDoItem`**: This type would represent an individual to-do item, with properties like an `id`, `text` (the task description), and `checked` (a boolean indicating if the task is completed).
+- **`ToDoListState`**: This could be the root type representing the overall state of the to-do list. It might contain a list of `ToDoItem` objects.
+- **`ToDoItem`**: This type would represent an individual to-do item, with properties like an `id`, `text` (the task description), and `checked` (a boolean indicating if the task is completed).
 
 ### Fields
+
 Each type has **fields**, which represent the properties of that type. Each field has a name and a type. For instance, the `ToDoItem` type would have an `id` field of type `ID!`, a `text` field of type `String!`, and a `checked` field of type `Boolean!`.
 
 ### Scalars
+
 GraphQL has a set of built-in **scalar types**:
-*   `String`: A UTF‐8 character sequence.
-*   `Int`: A signed 32‐bit integer.
-*   `Float`: A signed double-precision floating-point value.
-*   `Boolean`: `true` or `false`.
-*   `ID`: A unique identifier, often used as a key for a field. It is serialized in the same way as a String; however, it is not intended to be human-readable.
+
+- `String`: A UTF‐8 character sequence.
+- `Int`: A signed 32‐bit integer.
+- `Float`: A signed double-precision floating-point value.
+- `Boolean`: `true` or `false`.
+- `ID`: A unique identifier, often used as a key for a field. It is serialized in the same way as a String; however, it is not intended to be human-readable.
 
 In addition to these standard types, the Powerhouse Document-Engineering system introduces custom scalars that are linked to reusable front-end components. These scalars are tailored for the web3 ecosystem and will be explored in the Component Library section of the documentation.
 
 ### Lists and non-null
 
 You can modify types using lists and non-null indicators:
-*   **Lists**: To indicate that a field will return a list of a certain type, you wrap the type in square brackets, e.g., `[ToDoItem!]!`. This means the field `items` in `ToDoListState` will be a list of `ToDoItem` objects.
-*   **Non-Null**: To indicate that a field cannot be null, you add an exclamation mark `!` after the type name, e.g., `String!`. This means that the `text` field of a `ToDoItem` must always have a value. The outer `!` in `[ToDoItem!]!` means the list itself cannot be null (it must be at least an empty list), and the inner `!` on `ToDoItem!` means that every item within that list must also be non-null.
+
+- **Lists**: To indicate that a field will return a list of a certain type, you wrap the type in square brackets, e.g., `[ToDoItem!]!`. This means the field `items` in `ToDoListState` will be a list of `ToDoItem` objects.
+- **Non-Null**: To indicate that a field cannot be null, you add an exclamation mark `!` after the type name, e.g., `String!`. This means that the `text` field of a `ToDoItem` must always have a value. The outer `!` in `[ToDoItem!]!` means the list itself cannot be null (it must be at least an empty list), and the inner `!` on `ToDoItem!` means that every item within that list must also be non-null.
 
 ## Example: ToDoList state schema
 
@@ -56,21 +61,21 @@ type ToDoListStats {
 
 ### Breakdown:
 
-*   **`ToDoListState` type**:
-    *   `items: [ToDoItem!]!`: This field defines that our `ToDoListState` contains a list called `items`.
-        *   `[ToDoItem!]`: This signifies that `items` is a list of `ToDoItem` objects.
-        *   `ToDoItem!`: The `!` after `ToDoItem` means that no item in the list can be null. Each entry must be a valid `ToDoItem`.
-        *   The final `!` after `[ToDoItem!]` means that the `items` list itself cannot be null. It can be an empty list `[]`, but it cannot be absent.
+- **`ToDoListState` type**:
+  - `items: [ToDoItem!]!`: This field defines that our `ToDoListState` contains a list called `items`.
+    - `[ToDoItem!]`: This signifies that `items` is a list of `ToDoItem` objects.
+    - `ToDoItem!`: The `!` after `ToDoItem` means that no item in the list can be null. Each entry must be a valid `ToDoItem`.
+    - The final `!` after `[ToDoItem!]` means that the `items` list itself cannot be null. It can be an empty list `[]`, but it cannot be absent.
 
-*   **`ToDoItem` type**:
-    *   `id: ID!`: Each `ToDoItem` has a unique identifier that cannot be null. This is crucial for referencing specific items, for example, when updating or deleting them.
-    *   `text: String!`: The textual description of the to-do item. It cannot be null, ensuring every to-do has a description.
-    *   `checked: Boolean!`: Indicates whether the to-do item is completed. It defaults to a boolean value (true or false) and cannot be null.
+- **`ToDoItem` type**:
+  - `id: ID!`: Each `ToDoItem` has a unique identifier that cannot be null. This is crucial for referencing specific items, for example, when updating or deleting them.
+  - `text: String!`: The textual description of the to-do item. It cannot be null, ensuring every to-do has a description.
+  - `checked: Boolean!`: Indicates whether the to-do item is completed. It defaults to a boolean value (true or false) and cannot be null.
 
-*   **`ToDoListStats` type**: This type holds the summary statistics for the to-do list.
-    *   `total: Int!`: The total count of all to-do items. This field must be an integer and cannot be null.
-    *   `checked: Int!`: The number of to-do items that are marked as completed. This must be an integer and cannot be null.
-    *   `unchecked: Int!`: The number of to-do items that are still pending. This also must be an integer and cannot be null.
+- **`ToDoListStats` type**: This type holds the summary statistics for the to-do list.
+  - `total: Int!`: The total count of all to-do items. This field must be an integer and cannot be null.
+  - `checked: Int!`: The number of to-do items that are marked as completed. This must be an integer and cannot be null.
+  - `unchecked: Int!`: The number of to-do items that are still pending. This also must be an integer and cannot be null.
 
 ## Best practices for designing your state schema
 
@@ -78,9 +83,9 @@ type ToDoListStats {
 2.  **Clarity and Explicitness**: Name your types and fields clearly and descriptively. This makes the schema easier to understand and maintain.
 3.  **Use Non-Null Wisely**: Enforce data integrity by using non-null (`!`) for fields that must always have a value. However, be mindful not to over-constrain if a field can genuinely be optional.
 4.  **Normalize vs. Denormalize**:
-    *   **Normalization**: Similar to relational databases, you can normalize your data by having distinct types and linking them via IDs. This can reduce data redundancy. For example, if you had `User` and `ToDoItem` and wanted to assign tasks, you might have an `assigneeId` field in `ToDoItem` that links to a `User`'s `id`.
-    *   **Denormalization**: Sometimes, for performance or simplicity, you might embed data directly. For instance, if user information associated with a to-do item was very simple and only used in that context, you might embed user fields directly in `ToDoItem`.
-    *   The choice depends on your specific use case, query patterns, and how data is updated.
+    - **Normalization**: Similar to relational databases, you can normalize your data by having distinct types and linking them via IDs. This can reduce data redundancy. For example, if you had `User` and `ToDoItem` and wanted to assign tasks, you might have an `assigneeId` field in `ToDoItem` that links to a `User`'s `id`.
+    - **Denormalization**: Sometimes, for performance or simplicity, you might embed data directly. For instance, if user information associated with a to-do item was very simple and only used in that context, you might embed user fields directly in `ToDoItem`.
+    - The choice depends on your specific use case, query patterns, and how data is updated.
 5.  **Consider Future Needs**: While you shouldn't over-engineer, think a little about potential future enhancements. For example, adding a `createdAt: String` or `dueDate: String` field to `ToDoItem` might be useful later.
 6.  **Root State Type**: It's a common pattern to have a single root type for your document state (e.g., `ToDoListState`). This provides a clear entry point for accessing all document data.
 
@@ -91,26 +96,26 @@ By carefully defining your state schema, you lay a solid foundation for your Pow
 Now that you understand the concepts behind the state schema, let's put it into practice. This section will guide you through creating a document model specification for the advanced ToDoList example discussed above.
 
 <details>
-<summary>Tutorial: The state schema specification</summary> 
+<summary>Tutorial: The state schema specification</summary>
 
 ### Prerequisites
 
--   You have a Powerhouse project set up. If not, please follow the [Create a new Powerhouse Project](../../GetStarted/CreateNewPowerhouseProject) tutorial.
--   Connect Studio is running. If not, navigate to your project directory in the terminal and run `ph connect`.
+- You have a Powerhouse project set up. If not, please follow the [Create a new Powerhouse Project](../../GetStarted/CreateNewPowerhouseProject) tutorial.
+- Connect Studio is running. If not, navigate to your project directory in the terminal and run `ph connect`.
 
 ### Steps
 
 1.  **Create a New Document Model**:
-    -   With Connect Studio open in your browser, navigate into your local drive.
-    -   At the bottom of the page in the 'New Document' section, click the `DocumentModel` button to create a new document model specification.
+    - With Connect Studio open in your browser, navigate into your local drive.
+    - At the bottom of the page in the 'New Document' section, click the `DocumentModel` button to create a new document model specification.
 
 2.  **Define Document Metadata**:
-    -   **Name**: Give your document model a descriptive name, for example, `ToDoList`. **Pay close attention to capitalization, as it influences our code.**
-    -   **Document Type**: In the 'Document Type' field, enter a unique identifier for this document type: `powerhouse/todolist`.
+    - **Name**: Give your document model a descriptive name, for example, `ToDoList`. **Pay close attention to capitalization, as it influences our code.**
+    - **Document Type**: In the 'Document Type' field, enter a unique identifier for this document type: `powerhouse/todolist`.
 
 3.  **Specify the State Schema**:
-    -   In the code editor provided, you'll see a template for a GraphQL schema.
-    -   Replace the entire content of the editor with the advanced `ToDoList` schema we've designed in this chapter:
+    - In the code editor provided, you'll see a template for a GraphQL schema.
+    - Replace the entire content of the editor with the advanced `ToDoList` schema we've designed in this chapter:
 
     ```graphql
     # The state of our ToDoList
@@ -134,8 +139,8 @@ Now that you understand the concepts behind the state schema, let's put it into
     ```
 
 4.  **Sync Schema and View Initial State**:
-    -   After pasting the schema, click the **'Sync with schema'** button.
-    -   This action processes your schema and generates an initial JSON state for your document model based on the `ToDoListState` type. You can view this initial state, which helps you verify that your schema is structured correctly.
+    - After pasting the schema, click the **'Sync with schema'** button.
+    - This action processes your schema and generates an initial JSON state for your document model based on the `ToDoListState` type. You can view this initial state, which helps you verify that your schema is structured correctly.
 
     For now, you can ignore the "Modules & Operations" section. We will define and implement the operations that modify this state in the upcoming sections of this Mastery Track.
 
@@ -144,4 +149,3 @@ By completing these steps, you have successfully specified the data structure fo
 </details>
 
 For a complete, working example, you can always have a look at the [Example ToDoList Repository](/academy/MasteryTrack/DocumentModelCreation/ExampleToDoListRepository) which contains the full implementation of the concepts discussed in this Mastery Track.
-