@powerhousedao/academy 0.1.0-dev.1 → 0.1.0-dev.3

package/CHANGELOG.md

@@ -1,3 +1,24 @@
+## 0.1.0-dev.3 (2025-05-27)
+
+### 🚀 Features
+
+- enforce conventional commits ([faa49da40](https://github.com/powerhouse-inc/powerhouse/commit/faa49da40))
+
+### ❤️ Thank You
+
+- Frank
+
+## 0.1.0-dev.2 (2025-05-26)
+
+### 🩹 Fixes
+
+- **academy:** deployment ([36e5f194d](https://github.com/powerhouse-inc/powerhouse/commit/36e5f194d))
+- **switchboard:** docker build ([7052e39e1](https://github.com/powerhouse-inc/powerhouse/commit/7052e39e1))
+
+### ❤️ Thank You
+
+- Frank
+
 ## 0.1.0-dev.1 (2025-05-25)
 
 ### 🚀 Features

package/Dockerfile

@@ -1,31 +1,18 @@
 # syntax=docker/dockerfile:1
 
-# Stage 1: Base image.
-## Start with a base image containing NodeJS so we can build Docusaurus.
 FROM node:lts AS base
-## Disable colour output from yarn to make logs easier to read.
 ENV FORCE_COLOR=0
-## Enable corepack.
-RUN corepack enable
-## Set the working directory to `/opt/docusaurus`.
-WORKDIR /opt/docusaurus
 
-# Stage 2b: Production build mode.
-FROM base AS prod
-## Set the working directory to `/opt/docusaurus`.
-WORKDIR /opt/docusaurus
-## Copy over the source code.
-COPY . /opt/docusaurus/
-## Install dependencies with `--frozen-lockfile` to ensure reproducibility.
+ENV PNPM_HOME="/pnpm"
+ENV PATH="$PNPM_HOME:$PATH"
+RUN corepack enable && corepack install --global pnpm@10.1.0
+ENV COREPACK_ENABLE_DOWNLOAD_PROMPT=0
+
+WORKDIR /app
+COPY . .
+RUN chmod +x entrypoint.sh
 RUN pnpm install --frozen-lockfile
-## Build the static site.
 RUN pnpm build
-
-# Stage 3a: Serve with `docusaurus serve`.
-FROM prod AS serve
-## Expose the port that Docusaurus will run on.
 ENV PORT=3000
 EXPOSE $PORT
-## Run the production server.
-ENTRYPOINT pnpm serve --host 0.0.0.0 --no-open --port $PORT
-
+ENTRYPOINT ["./entrypoint.sh"]

package/docs/academy/01-GetStarted/02-LoginWithRenown.md

@@ -0,0 +1,32 @@
+# Login with Renown
+
+Renown is Powerhouse's decentralized identity and reputation system designed to address the challenge of trust within DAOs, where contributors often operate under pseudonyms. In traditional organizations, personal identity and reputation are key to establishing trust and accountability. Renown replicates this dynamic in the digital space, allowing contributors to earn experience and build reputation without revealing their real-world identities.
+
+
+:::tip
+When signing in with Renown use an Ethereum or blockchain address that is fit to function as your 'identity' as over time more experience and history will be accrued by this address. 
+:::
+
+## Login Flow 
+
+### Find the Renown Icon
+"**Login with Renown**" is a decentralized authentication flow that enables users to log into applications by signing a credential with their Ethereum wallet. Upon signing in, a Decentralized Identifier (DID) is created based on the user's Ethereum key. 
+
+![Renown Login](./images/RenownLogin.png)
+
+### Generate a DID to sign operations in Connect
+This DID is then associated with a credential that authorizes a specific Connect instance to act on the user's behalf. That credential is stored securely on Ceramic, a decentralized data network. When the user performs actions through the Powerhouse Connect interface, those operations are signed with the DID and transmitted to Switchboard, which serves as the verifier. 
+
+![Renown Login](./images/ConnectAddress.png)
+
+![Renown Login](./images/LoginComplete.png)
+
+### Modify a document
+Switchboard checks the validity of the DID and credential, ensuring the operation request is legitimate. This flow is designed to offer a verifiable, cryptographically secure login system that replaces traditional password-based authentication with decentralized identity and signature-based trust.
+
+![Renown Login](./images/OperationsHistory.png)
+
+By leveraging this system, every operation or modification made to a document is cryptographically signed by the contributor's Renown identity. This ensures that each change is verifiable, traceable, and attributable to a specific pseudonymous user, providing a robust audit trail for all document activity. 
+
+For a deeper dive into how these signed operations are recorded and visualized, see the [Operations History](/docs/academy/AdvancedTutorial/BuildingUserExperiences/DocumentTools/OperationHistory) page.
+

package/docs/academy/01-GetStarted/_category_.json

@@ -0,0 +1,3 @@
+{
+    "label": "Get Started"
+  }

package/docs/academy/02-AdvancedTutorial/03-BuildingUserExperiences/02-ConfiguringDrives.md

@@ -1,10 +1,10 @@
 # Configure a Drive
 
-A drive in Powerhouse is a container for documents and data. This guide will walk you through the process of configuring and managing drives in your Powerhouse environment.   
+A drive in Powerhouse is a container or a wrapper for documents and data. It's a place where you can organize and store your documents and share them with others. This guide will walk you through the process of configuring and managing drives in your Powerhouse environment.   
 
 ## Prerequisites
 
-Before configuring drives, ensure you have:
+Before configuring a drive, ensure you have:
 - Powerhouse [CLI installed](/docs/academy/AdvancedTutorial/Create/BuilderTools)
 - Access to a Powerhouse instance
 - Appropriate permissions to create and manage drives
@@ -13,7 +13,7 @@ Before configuring drives, ensure you have:
 
 ### Local Drives
 
-A local drive is a container for local documents and data, hosted on your local machine. Technically a drive is just another document with a list of the documents inside the drive. When you run connect locally with `ph connect` a local drive is automatically added. You can also create a new local drive by clicking 'add drive' in connect.
+A local drive is a container for local documents and data, hosted on your local machine. Technically a drive is just another document model with a list of the documents inside the drive. When you run connect locally with `ph connect` a local drive is automatically added. You can also create a new local drive by clicking **'add drive'** in connect.
 
 ### Remote Drives vs. reactors 
 
@@ -23,7 +23,7 @@ Remote drives in Powerhouse allow you to connect to and work with data stored in
 - **Cloud Storage**: For centralized, scalable data management.
 - **Decentralized Storage**: Such as Ceramic or IPFS, enabling distributed and blockchain-based storage options.
 
-:::info
+:::tip
 **Powerhouse Reactors** are the nodes in the network that store and synchronise documents & drives , resolve conflicts and rerun operations to verify document event histories. 
 Reactors can be configured for local storage, centralized cloud storage or on a decentralized storage network. 
 
@@ -34,18 +34,91 @@ A drive exists by making use of a reactor and the storagelayer that specific rea
 
 ### Drive Apps 
 
-Drive Explorers (also known as Drive Apps) are specialized interfaces that enhance how users interact with document models within a drive. As mentioned previously, technically a drive is just another document, with a list of the documents inside the drive. So it is obvious that you can create a custom editor for your drive-document. These customized editors are called Drive explorers or Drive Apps. They provide custom views, organization tools, and interactive features tailored to specific use cases. For example, a Drive Explorer might present data as a Kanban board, provide aggregated insights, or offer specialized widgets for data processing. To learn more about building and customizing Drive Explorers, check out our [Building a Drive Explorer](/docs/academy/AdvancedTutorial/BuildingUserExperiences/BuildingADriveExplorer) guide.
+**Drive Explorers** (also known as Drive Apps) are specialized interfaces that enhance how users interact with document models within a drive. As mentioned previously, technically a drive is just another document, with a list of the documents inside the drive. So it is obvious that you can create a custom editor for your drive-document. 
+
+These customized editors are called Drive explorers or Drive Apps. They provide custom views, organization tools, and interactive features tailored to specific use cases. For example, a Drive Explorer might present data as a Kanban board, provide aggregated insights, or offer specialized widgets for data processing. 
+
+To learn more about building and customizing Drive Explorers, check out our [Building a Drive Explorer](/docs/academy/AdvancedTutorial/BuildingUserExperiences/BuildingADriveExplorer) guide.
 
 
 ## Creating a New Drive
 
-![Create Drive Modal](./images/CreateDrive.png)
+![Create New Drive](./images/CreateNewDrive.png)
 
 To create a new drive in Powerhouse, follow these steps:
-1. Click on the "Create New Drive" button in the Connect interface or in the Connect sidebar on the (+) Icon. 
-2. In the modal that appears, enter a name for your drive in the "Drive Name" field.
+1. Click on the "**Create New Drive**" button in the Connect interface or in the Connect sidebar on the (+) Icon. 
+2. In the modal that appears, enter a name for your drive in the "**Drive Name**" field.
 3. Select the desired Drive App (such as the Generic Drive Explorer, or any other Drive App you've installed).
-4. Choose the location for your drive: Local (only available to you), Cloud (available to people in this drive), or Public (available to everyone).
+4. Choose the location for your drive: **Local** (only available to you), **Cloud** (available to people in this drive), or **Public** (available to everyone).
 5. (Optional) Enable the "Make available offline" toggle if you want to keep a local backup of your drive.
 6. Once all options are set, click the "Create new drive" button to finalize and create your drive.
 
+## Adding a New Remote Drive via GraphQL Mutation
+
+You can also add a new remote drive to your Connect environment programmatically using GraphQL mutations. This is especially useful for automation, scripting, or integrating with external systems.
+
+### Prerequisites
+- Access to the Switchboard or remote reactor (server node) of your Connect instance.
+- The GraphQL endpoint for your instance. For example, for the staging environment, use: `https://staging.switchboard.phd/graphql/system` (this is a supergraph gateway).
+- Appropriate permissions to perform mutations.
+
+### Steps
+1. **Navigate to the GraphQL Playground or use a GraphQL client**
+   - Open [https://staging.switchboard.phd/graphql/system](https://staging.switchboard.phd/graphql/system) in your browser, or use a tool like [GraphQL Playground](https://www.apollographql.com/docs/apollo-server/testing/graphql-playground/).
+
+2. **Prepare the Mutation**
+   - Use the following mutation to create a new drive:
+
+   ```graphql
+   mutation Mutation($name: String!, $icon: String, $addDriveId: String, $slug: String) {
+     addDrive(name: $name, icon: $icon, id: $addDriveId, slug: $slug) {
+       icon
+       id
+       name
+       slug
+     }
+   }
+   ```
+
+   - Example variables:
+   ```json
+   {
+     "name": "AcademyTest",
+     "icon": "https://static.thenounproject.com/png/3009860-200.png",
+     "addDriveId": null,
+     "slug": null
+   }
+   ```
+   - You can also provide a custom `id`, `slug`, or `preferredEditor` if needed.
+
+3. **Execute the Mutation**
+   - Run the mutation. On success, you will receive a response containing the new drive's `icon`, `id`, `name`, and `slug`:
+
+   ```json
+   {
+     "data": {
+       "addDrive": {
+         "icon": "https://static.thenounproject.com/png/3009860-200.png",
+         "id": "6461580b-d317-4596-942d-f6b3d1bfc8fd",
+         "name": "AcademyTest",
+         "slug": "6461580b-d317-4596-942d-f6b3d1bfc8fd"
+       }
+     }
+   }
+   ```
+
+
+
+4. **Construct the Drive URL**
+   - Once you have the `id` or `slug`, you can construct the drive URL for Connect:
+     - Format: `domain/d/driveId` or `domain/d/driveSlug`
+     - Example: `https://staging.connect.phd/d/6461580b-d317-4596-942d-f6b3d1bfc8fd`
+
+5. **Add the Drive in Connect**
+   - Use the constructed URL to add or access the drive in your Connect environment.
+
+---
+
+This approach allows you to automate drive creation and integration with other systems, making it easy to manage drives at scale.
+
+

package/docs/academy/02-AdvancedTutorial/03-BuildingUserExperiences/07-DocumentTools/01-OperationHistory.md

@@ -49,7 +49,7 @@ Hovering over a revision reveals its event ID and state hash, providing traceabi
 
 ### Signature Verification
 Clicking the signature badge shows signature details, including signer address, hash, and verification status. This ensures every operation is cryptographically auditable.
-Read more about how we are using [Renown](/docs/renown/intro) for authentication & verification of signer data. 
+Read more about how we are using [Renown](/docs/academy/AdvancedTutorial/BuildingUserExperiences/Authorization/RenownAuthenticationFlow) for authentication & verification of signer data. 
 
 ![Signature Details Popup](./images/signature-details-popup.png)
 

package/docs/{renown/02-renown-login-flow.md → academy/02-AdvancedTutorial/03-BuildingUserExperiences/08-Authorization/01-RenownAuthenticationFlow.md}

@@ -1,22 +1,18 @@
----
-# sidebar_position: 1
-sidebar_label: Renown Login Flow
-displayed_sidebar: renownSidebar
----
-
-# Renown Login Flow
+# Renown Authentication Flow
 
 The Renown login flow leverages decentralized identity (DID) creation and the Ceramic network for credential storage and verification, ensuring secure and verifiable actions within decentralized organizations. Below is a detailed breakdown of the process, aimed at developers integrating the Renown, Connect, and Switchboard components.
 
-### Overview
-Renown provides a decentralized identity and reputation hub, where users connect their Ethereum address, creating a Decentralized Identifier (DID) tied to their wallet. The system uses Ceramic for credential generation and storage. Credentials are later verified through Switchboard for secure operation management.
+### Renown in the decentralized workplace
+Renown provides a decentralized identity and reputation hub, where users connect their Ethereum address, creating a **Decentralized Identifier (DID)** tied to their wallet. Renown is designed to address the challenge of trust within DAOs, where contributors often operate under pseudonyms. In traditional organizations, personal identity and reputation are key to establishing trust and accountability. Renown replicates this dynamic in the digital space, allowing contributors to earn experience and build reputation without revealing their real-world identities. Over time, contributors can share their pseudonymous profiles with other organizations as cryptographic resumes, helping to secure new opportunities while maintaining privacy.
 
-### Detailed Flow
+### Detailed Login Flow
 
 #### 1. User Login via Wallet Connection
 - The user starts by logging into Renown using their Ethereum address. This is done by signing a message with their wallet.
 - The Ethereum key is used to create a DID (Decentralized Identifier), which uniquely represents the user without exposing their personal identity.
 
+![Renown Login](./images/ConnectAddress.png)
+
 #### 2. DID Creation
 - A Decentralized Identifier (DID) is created based on the user's Ethereum key. The DID follows a specific format:  
   `did:example:123456789abcdefghijk`
@@ -30,6 +26,8 @@ Renown provides a decentralized identity and reputation hub, where users connect
 - Connect uses the newly created DID to sign operations performed by the user. For example, when a document or transaction is edited in Connect, the operation is signed with the user's DID.
 - This ensures that every action taken within the Connect system is linked to the user's decentralized identity, maintaining transparency and accountability.
 
+![Renown Login](./images/OperationsHistory.png)
+
 #### 5. Switchboard Verification
 - Once an operation is signed by the DID through Connect, it is sent to Switchboard for verification.
 - Switchboard verifies whether the DID has a valid credential stored on Ceramic and if the DID was indeed the one that signed the operation.
@@ -49,6 +47,9 @@ Renown provides a decentralized identity and reputation hub, where users connect
 - The operation is then either approved or rejected based on the verification results.
 - Approved operations are processed, and changes made within the Connect system are synchronized across the relevant nodes.
 
+<img src="/img/Renown Intro Diagram.png" alt="renown diagram"/>
+*An overview of the Holder - Issuer - Verifier relationship that the decentralised identity system Renown makes use of to establish a self sovereign identity for it's users.*
+
 :::info
 **Key Components used during login-flow**
 - **Renown**: Manages user identities via DID creation and Ethereum wallet integration.

package/docs/academy/02-AdvancedTutorial/03-BuildingUserExperiences/08-Authorization/_category_.json

@@ -0,0 +1,6 @@
+{
+    "label": "Authorization",
+    "link": {
+      "type": "generated-index"
+    }
+  }

package/docs/academy/03-APIReferences/00-PowerhouseCLI.md

@@ -1 +1,40 @@
-Placeholder
+# Powerhouse CLI
+
+### Installing the Powerhouse CLI 
+:::tip
+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
+- `ph help` to get an overview of all the available commands
+
+This tool will be fundamental on your journey when creating, building, and running Document Models
+
+<details>
+<summary> How to make use of different branches? </summary>
+
+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 |
+
+Please be aware that these versions can contain bugs and experimental features that aren't fully tested.
+</details>

package/docs/academy/03-APIReferences/01-ReactHooks.md

@@ -0,0 +1,3 @@
+# React Hooks
+
+Placeholder

package/docs/academy/03-APIReferences/02-ReactorUsage.md

@@ -0,0 +1 @@
+# Reactor Usage

package/docs/academy/04-ComponentLibrary/01-PowerhouseDesignSystem.md

@@ -1,8 +1,8 @@
-# Powerhouse Design System
+# Document-Engineering System
 
 The reusable components are a set of of front-end components based on graphQL scalars. 
 Powerhouse also has a set of custom scalars that are not part of the graphQL standard but are specific to the web3 ecosystem.
-These components are offered through the **Powerhouse Design System** with the help of storybook & the Academy documentation. 
+These components are offered through the **Powerhouse document-engineering system** with the help of storybook & the Academy documentation. 
 
 It provides a collection of pre-built, reusable UI components designed for consistency and efficiency across Powerhouse applications and editors. Think of it as a toolkit of standard UI elements like buttons, inputs, and checkboxes with many of these components based on graphql scalars. 
 
@@ -49,9 +49,9 @@ We use Storybook as an interactive catalog for our design system components. It
 2.  **Usage Snippet:** Below the demo, you'll typically find a basic code example demonstrating how to include the component in your code (e.g., `<Checkbox defaultValue label="Accept terms and conditions" />`). This provides a starting point for implementation.
 3.  **Props Table:** Further down, a table lists the properties (`props`) the component accepts. Props are like settings or configuration options. For the `Checkbox`, this table would show props like `label`, `defaultValue`, `value`, `onChange`, etc., often with descriptions of what they control.
 
-## Implementing a Design System Component
+## Implementing a Component
 
-Let's walk through the typical workflow for using a component from the design system, using the `Checkbox` from the [To-do List editor](/docs/academy/GetStarted/ToDoList/BuildToDoListEditor).
+Let's walk through the typical workflow for using a component from the document-engineering system, using the `Checkbox` from the [To-do List editor](/docs/academy/GetStarted/ToDoList/BuildToDoListEditor).
 
 1.  **Identify the Need:** While building your feature (e.g., the To-do List editor in `editor.tsx`), you determine the need for a standard UI element, like a checkbox.
 2.  **Consult the Resuable Components in Academy or in Storybook:**

package/docs/academy/05-Architecture/00-PowerhouseArchitecture.md

@@ -8,7 +8,7 @@ These five applications are:
 2. **Switchboard** – The data infrastructure and API engine.
 3. **Fusion** – The public-facing collaboration hub.
 4. **Renown** – The decentralized reputation and identity system.
-5. **Academy** – The onboarding and learning platform.
+5. **Academy** – The onboarding and learning modules.
 
 Each application is designed to be modular yet complementary, ensuring smooth data flows, structured collaboration, and scalable automation. The functionality of the four host apps offers an integrated experience for running decentralized operations.
 

package/docs/academy/06-Cookbook.md

@@ -636,6 +636,89 @@ ph generate --drive-editor <drive-app-name>
 - [Build a Drive-Explorer](/docs/academy/AdvancedTutorial/BuildingUserExperiences/BuildingADriveExplorer)
 </details>
 
+<details id="adding-a-new-drive-via-graphql-mutation">
+<summary>Adding a New Drive via GraphQL Mutation</summary>
+
+## How to Add a New Remote Drive via GraphQL Mutation
+---
+
+## Problem Statement
+You want to programmatically add a new remote drive to your Powerhouse Connect environment using a GraphQL mutation. This is useful for automation, scripting, or integrating with external systems.
+
+## Prerequisites
+- Access to the Switchboard or remote reactor (server node) of your Connect instance.
+- The GraphQL endpoint for your instance (e.g., `https://staging.switchboard.phd/graphql/system`).
+- Appropriate permissions to perform mutations.
+
+## Solution
+
+### Step 1: Access the GraphQL Playground or Client
+Open the GraphQL Playground at your endpoint (e.g., [https://staging.switchboard.phd/graphql/system](https://staging.switchboard.phd/graphql/system)), or use a GraphQL client of your choice.
+
+### Step 2: Prepare the Mutation
+Use the following mutation to create a new drive, set a name and add a drive icon. Weither or not you define a ID & Slug is up to you:
+
+```graphql
+mutation Mutation($name: String!, $icon: String, $addDriveId: String, $slug: String) {
+  addDrive(name: $name, icon: $icon, id: $addDriveId, slug: $slug) {
+    icon
+    id
+    name
+    slug
+  }
+}
+```
+
+Example variables:
+```json
+{
+  "name": "AcademyTest",
+  "icon": "https://static.thenounproject.com/png/3009860-200.png",
+  "addDriveId": null,
+  "slug": null
+}
+```
+You can also provide a custom `id`, `slug`, or `preferredEditor` if needed.
+
+### Step 3: Execute the Mutation
+Run the mutation. On success, you will receive a response containing the new drive's `icon`, `id`, `name`, and `slug`:
+
+```json
+{
+  "data": {
+    "addDrive": {
+      "icon": "https://static.thenounproject.com/png/3009860-200.png",
+      "id": "6461580b-d317-4596-942d-f6b3d1bfc8fd",
+      "name": "AcademyTest",
+      "slug": "6461580b-d317-4596-942d-f6b3d1bfc8fd"
+    }
+  }
+}
+```
+
+### Step 4: Construct the Drive URL
+Once you have the `id` or `slug`, you can construct the drive URL for Connect:
+- Format: `domain/d/driveId` or `domain/d/driveSlug`
+- Example: `https://staging.connect.phd/d/6461580b-d317-4596-942d-f6b3d1bfc8fd`
+
+### Step 5: Add the Drive in Connect
+Use the constructed URL to add or access the drive in your Connect environment.
+
+## Expected Outcome
+- A new drive is created and accessible in your Connect environment.
+- The drive can be managed or accessed using the generated URL.
+
+## Related Recipes
+- [Configuring Drives](/docs/academy/AdvancedTutorial/BuildingUserExperiences/ConfiguringDrives)
+- [Initializing a New Project & Document Model](#initializing-a-new-project-and-document-model)
+
+## Further Reading
+- [GraphQL Playground](https://www.apollographql.com/docs/apollo-server/testing/graphql-playground/)
+- [Powerhouse Builder Tools](/docs/academy/AdvancedTutorial/Create/BuilderTools)
+
+</details>
+
+
 ## Reactor Recipes
 
 <details id="starting-the-reactor">
@@ -839,7 +922,7 @@ You need to understand and manage different types of dependencies in your Powerh
 
 </details>
 
-Data Synchronisation Recipes
+## Data Synchronisation Recipes
 
 <details id="troubleshooting-document-syncing">
 <summary>Troubleshooting Document Syncing: Supergraph vs. Drive Endpoints</summary>

package/docs/academy/07-Glossary.md

@@ -1,5 +1,8 @@
 # Glossary
 
+A great way to get familiar with the vision, philosophy and terminology of Powerhouse is by reading the [Book Of Powerhouse](./docs/bookofpowerhouse/Overview).
+It offers an entry level, non-technical explainer to the high level vision of Powerhouse.
+
 ## General Terms
 - **Powerhouse** – A network organization that provides open-source software and services to support decentralized operations for other network organizations.
 - **Scalable Network Organization (SNO)** – A network organization structured according to the Powerhouse framework, designed for sustainable and scalable growth.

package/docs/bookofpowerhouse/02-GeneralFrameworkAndPhilosophy.md

@@ -1,15 +1,41 @@
-# Part 1: General Framework and Philosophy
+# **Part 1: Powerhouse General Framework and Open-Source Capitalism**
 
 Powerhouse emerged in the wake of Ethereum’s DAO movement, which began gaining momentum after the collapse of *The DAO* in 2016. This turning point spurred the creation of blockchain-enabled organizations capable of operating without centralized corporate structures. Over the years, governance systems and decentralized operational tools have advanced, paving the way for the next generation of organizations across chains like Solana, Ethereum Layer 2 solutions, and beyond. Powerhouse aims to advance these principles and build large, global organizations around networks.
 
-### Decentralized Operations and Collaboration
-    - Decentralization is central to Powerhouse’s philosophy. It extends beyond infrastructure to organizational design, enabling entities to function independently of centralized authorities. Just as Ethereum allows value to be transferred globally without intermediaries, **Powerhouse envisions organizations coordinating workflows without relying on traditional hierarchies or centralized services.**
-    - This marks a new era for decentralization—not just in the infrastructure we use, but in how organizations operate and how contributors collaborate. Instead of a traditional top-down hierarchy pursuing a singular vision, Powerhouse envisions a web of aligned, incentivized entities working together to build and deliver products and services. Powerhouse is designed to simplify the creation and assignment of workflows, empowering decentralized contributor networks to thrive.
+Powerhouse operates at the intersection of open-source innovation and decentralized coordination. This section outlines the philosophical foundation and systemic structure that guides its operations and vision—what we call “Open-Source Capitalism.”
 
-### Open Source and Transparency
-    - Open source lies at the heart of Powerhouse. By eliminating lock-in to centralized services, open-source software (OSS) creates trust within network organizations, as the codebase is accessible to all. Additionally, open-source ecosystems create an environment of rapid innovation and collaboration. Powerhouse goes beyond simply releasing software as open source—its legal infrastructure and innovative revenue models aim to make open-source development sustainable and investable at scale.
-    - Today’s organizations often operate as opaque black boxes, forcing consumers to trust that centralized entities aren’t extracting disproportionate value. Inspired by blockchain and DeFi’s transparency, Powerhouse promotes openness as a risk-lowering measure. In DeFi, collateral and liquidity are publicly verifiable on-chain. Similarly, Powerhouse encourages public scrutiny and contributions, where anyone can inspect, analyze, or build without needing permission.
 
-### Coordination at Massive Global Scale
-    - Scalable Network Organizations (SNOs), a concept pioneered by Powerhouse, go beyond DAOs by creating a coordinated network of specialized entities. These entities work together to pay service providers, generate revenue, manage IP, and enable strategic investments, all within a decentralized framework.
-    - Unlike traditional organizations, SNOs rely on decentralized ownership and operations, which makes them particularly well-suited for managing and growing software platforms with network effects. The corporate structures of the past were designed for a pre-digital world where networks were constrained by geography and jurisdiction. In today’s era of global communication and coordination, we need innovative structures and alignment mechanisms, such as SNOs, to support this new paradigm.
+## **Why Open-Source Capitalism?**
+
+Capitalism is the most powerful system of economic coordination ever invented. It incentivizes productivity, innovation, and risk-taking. But just as important—open-source has proven to be one of the most powerful engines of innovation within that system.
+
+Open-source unlocks coordination across boundaries: between companies, communities, and individuals. It builds shared infrastructure at unprecedented speed, allows bottom-up experimentation, and lowers barriers to participation. This is why Big Tech, for all its closed platforms and walled gardens, has embraced open-source at the core of its own operations—releasing projects like React, Kubernetes, and TensorFlow not out of charity, but because open collaboration is often the best way to build foundational technology.
+
+Yet this dynamic is incomplete. While open-source has dominated infrastructure, it has consistently struggled to capture value—particularly in consumer applications and services. The common assumption is that the challenge is distribution: how to equitably allocate funding, resources, and decision-making. But Open-Source Capitalism takes a broader view. Before we can redistribute value, we have to make sure value is being captured in the first place.
+
+That’s the central promise of Open-Source Capitalism: not just to build open alternatives, but to make them self-sustaining, investable, and scalable. It’s about combining the pro-market, pro-innovation ethos of open-source with incentive structures that actually work—so we can build networks that don’t just survive, but thrive.
+
+
+## **Four Principles of Open-Source Capitalism**
+
+
+
+1. **Coordination Through Marketplace Platforms** Open-Source Capitalism demands new types of platforms—public marketplaces where contributors, customers, and investors can interact transparently. Like Uber or Airbnb, these marketplaces optimize for liquidity and coordination, but with open governance and ownership. \
+
+2. **Incentive Alignment via Tokens and Revenue Sharing** Powerhouse uses Proof of Work Tokens (POWTs) to compensate contributors fairly over time, enabling deferred compensation models that align long-term incentives. \
+
+3. **Reinvestment Through Revenue-Generating Hubs** Monetized OSS must funnel returns back to the contributors. The RGH (Revenue Generating Hub) manages licensing, sales, and commercial transactions in alignment with decentralized values. \
+
+4. **Make Open Source Investable** By enabling investor flows through the Operational Collateral Fund (OCF), open-source projects gain sustainable funding channels. Returns are tied to the downstream use of open infrastructure. \
+
+
+
+## **Decentralized Operations and Collaboration**
+
+Open-Source Capitalism doesn’t work without new organizational structures. DAOs promised a way forward, but fell short: plagued by coordination failures, incentive misalignment, and lack of clarity around roles, responsibilities, and execution. Powerhouse emerged from this gap—building systems that retain the openness of decentralized networks while introducing the operational rigor of traditional institutions.
+
+At the core of this approach is a belief in structured decentralization. Powerhouse enables independent teams to coordinate around shared goals, using workflows encoded in software rather than enforced by hierarchy. Contributors take ownership over workstreams, reputations are built over time, and budgets are allocated based on transparent processes. This is not decentralization for its own sake—it is a functional reimagining of how work gets done at scale.
+
+Transparency plays a critical role. Rather than relying on opaque decision-making or internal politics, Powerhouse makes contributions, decisions, and payments legible. Governance and compensation are traceable across time, creating a persistent and auditable record of organizational behavior. The result is a system that fosters trust not just between individuals, but across entire networks.
+
+This is what makes Powerhouse unique: it’s not just about running decentralized software—it’s about running decentralized organizations. Open-Source Capitalism is the economic philosophy. Scalable Network Organizations are the structure. And these principles come to life through the operational frameworks that guide every action on the network.

package/docs/bookofpowerhouse/05-SNOsandANewModelForOSSandPublicGoods.md

@@ -1,73 +1,44 @@
-# Part 4: SNOs and a new model for OSS and Public Goods
+# Part 4: Scalable Network Organizations (SNOs) 
 
 Decentralized Autonomous Organizations (DAOs) once promised to revolutionize global collaboration by enabling decentralized governance, transparent decision-making, and equitable ownership. However, the reality has often fallen short. DAOs have struggled with legal ambiguity, resource allocation inefficiencies, and broken incentive structures. These challenges have stifled their ability to scale and compete with centralized organizations.
 
 Scalable Network Organizations (SNOs) emerge as the next evolutionary step. Combining the principles of decentralization with the operational rigor of traditional organizations, SNOs provide a structured framework for decentralized governance, sustainable operations, and global scalability. Powerhouse’s vision for SNOs aims to deliver on the original promise of DAOs, empowering organizations to scale without sacrificing their decentralized principles.
 
-### Core Components of SNOs
+
+### Core Components of SNOs[​](https://staging.powerhouse.academy/docs/bookofpowerhouse/SNOsandANewModelForOSSandPublicGoods#core-components-of-snos)
 
 At the heart of Scalable Network Organizations (SNOs) are five entities, each fulfilling a critical role in scaling decentralized operations. From governance to funding and IP management, these components work together to ensure alignment, collaboration, and financial sustainability.
 
-- **DAO**
-    - The DAO is the governing entity responsible for setting the strategic vision and ensuring alignment across the SNO. Through on-chain governance mechanisms powered by smart contracts, the DAO facilitates transparent decision-making, distributed ownership, and accountability. Members participate in proposing and voting on budgets, initiatives, and key operational decisions, creating a decentralized system where authority is widely distributed rather than concentrated in a single entity.
-    - By maintaining immutable records and eliminating the need for intermediaries, the DAO supports scalable and adaptable governance structures that suit decentralized networks. Its ability to flexibly adapt rules and processes ensures that the SNO remains efficient and innovative as it grows, while retaining the values of transparency and inclusivity.
-- **Operational Hub (OH)**
-    - The Operational Hub acts as the administrative core of the SNO, handling contributor relationships, compliance, and payment processing. By leveraging legal structures like Swiss Associations, the OH ensures contributors are protected from liability while enabling the SNO to interact with banks, vendors, and regulatory entities. This hub simplifies complex operations such as tax reporting, cross-border compliance, and contributor agreements, removing these burdens from individual participants.
-    - The Operational Hub acts as the administrative core of the SNO, handling contributor relationships, compliance, and payment processing. By leveraging legal structures like Swiss Associations, the OH ensures contributors are protected from liability while enabling the SNO to interact with banks, vendors, and regulatory entities. This hub simplifies complex operations such as tax reporting, cross-border compliance, and contributor agreements, removing these burdens from individual participants.
-- **Operational Collateral Fund (OCF)**
-    - The OCF provides the financial infrastructure to fuel the SNO’s growth. It allocates resources to high-potential initiatives and rewards contributors by issuing Proof of Work Tokens (POWTs). These tokens align incentives by linking compensation to measurable contributions, ensuring that individuals and teams are motivated to create long-term value. POWTs represent a stake in the success of the network, making contributors invested in the outcomes of the projects they support.
-    - Beyond its internal role, the OCF also attracts external investment by offering structured opportunities for funding impactful projects within the network. By maintaining transparency in its allocation processes and linking funding to measurable outputs, the OCF builds trust among both contributors and investors, creating a virtuous cycle where capital supports meaningful innovation.
-- **Revenue Generating Hub (RGH)**
-    - The RGH is the SNO’s commercial interface, enabling the network to generate sustainable revenue while maintaining its decentralized principles. It manages licensing agreements, product sales, and customer-facing activities, ensuring that all revenue-generating operations align with the broader goals set by the DAO. By addressing the regulatory complexities associated with handling fiat revenue or contractual obligations, the RGH provides a seamless bridge between decentralized networks and traditional market systems.
-    - The RGH supports multiple revenue streams, including enterprise licensing for proprietary versions of open-source software, subscription models for SaaS offerings, and consulting services tailored to client needs. A portion of the revenue collected flows back into the ecosystem, funding operations, rewarding contributors through the OCF, and sustaining the open-source projects that drive the SNO’s long-term success.
-- **IP-Holding Entity (IPSPV)**
-    - The IP-Holding Entity safeguards the SNO’s intellectual property assets, including trademarks, copyrights, and other IP rights. It is responsible for enforcing licensing agreements and ensuring that the use of the network’s IP aligns with governance decisions made by the DAO. By employing a dual licensing model, the IPSPV supports open-source availability through copyleft licenses while generating revenue from enterprise licenses, allowing businesses to use proprietary versions of the SNO’s software.
-    - The IPSPV also plays a critical role in protecting the network’s creative assets from exploitation or infringement. It ensures that the IP is managed as a collective resource, aligned with the community’s mission and values, while providing a steady revenue stream for reinvestment into the ecosystem. By separating IP management from operational activities, the IPSPV ensures that the SNO remains focused on innovation without losing control of its most valuable assets.
 
-### **Legal Foundations for SNOs**
 
-Legal structures are crucial for the success of SNOs, providing clarity, compliance, and protection.
+* DAO
+    * The DAO is the governing entity responsible for setting the strategic vision and ensuring alignment across the SNO. Through on-chain governance mechanisms powered by smart contracts, the DAO facilitates transparent decision-making, distributed ownership, and accountability. Members participate in proposing and voting on budgets, initiatives, and key operational decisions, creating a decentralized system where authority is widely distributed rather than concentrated in a single entity.
+    * By maintaining immutable records and eliminating the need for intermediaries, the DAO supports scalable and adaptable governance structures that suit decentralized networks. Its ability to flexibly adapt rules and processes ensures that the SNO remains efficient and innovative as it grows, while retaining the values of transparency and inclusivity.
+* Operational Hub (OH)
+    * The Operational Hub acts as the administrative core of the SNO, handling contributor relationships, compliance, and payment processing. By leveraging legal structures like Swiss Associations, the OH ensures contributors are protected from liability while enabling the SNO to interact with banks, vendors, and regulatory entities. This hub simplifies complex operations such as tax reporting, cross-border compliance, and contributor agreements, removing these burdens from individual participants.
+    * The Operational Hub acts as the administrative core of the SNO, handling contributor relationships, compliance, and payment processing. By leveraging legal structures like Swiss Associations, the OH ensures contributors are protected from liability while enabling the SNO to interact with banks, vendors, and regulatory entities. This hub simplifies complex operations such as tax reporting, cross-border compliance, and contributor agreements, removing these burdens from individual participants.
+* Operational Collateral Fund (OCF)
+    * The OCF provides the financial infrastructure to fuel the SNO’s growth. It allocates resources to high-potential initiatives and rewards contributors by issuing Proof of Work Tokens (POWTs). These tokens align incentives by linking compensation to measurable contributions, ensuring that individuals and teams are motivated to create long-term value. POWTs represent a stake in the success of the network, making contributors invested in the outcomes of the projects they support.
+    * Beyond its internal role, the OCF also attracts external investment by offering structured opportunities for funding impactful projects within the network. By maintaining transparency in its allocation processes and linking funding to measurable outputs, the OCF builds trust among both contributors and investors, creating a virtuous cycle where capital supports meaningful innovation.
+* Revenue Generating Hub (RGH)
+    * The RGH is the SNO’s commercial interface, enabling the network to generate sustainable revenue while maintaining its decentralized principles. It manages licensing agreements, product sales, and customer-facing activities, ensuring that all revenue-generating operations align with the broader goals set by the DAO. By addressing the regulatory complexities associated with handling fiat revenue or contractual obligations, the RGH provides a seamless bridge between decentralized networks and traditional market systems.
+    * The RGH supports multiple revenue streams, including enterprise licensing for proprietary versions of open-source software, subscription models for SaaS offerings, and consulting services tailored to client needs. A portion of the revenue collected flows back into the ecosystem, funding operations, rewarding contributors through the OCF, and sustaining the open-source projects that drive the SNO’s long-term success.
+* IP-Holding Entity (IPSPV)
+    * The IP-Holding Entity safeguards the SNO’s intellectual property assets, including trademarks, copyrights, and other IP rights. It is responsible for enforcing licensing agreements and ensuring that the use of the network’s IP aligns with governance decisions made by the DAO. By employing a dual licensing model, the IPSPV supports open-source availability through copyleft licenses while generating revenue from enterprise licenses, allowing businesses to use proprietary versions of the SNO’s software.
+    * The IPSPV also plays a critical role in protecting the network’s creative assets from exploitation or infringement. It ensures that the IP is managed as a collective resource, aligned with the community’s mission and values, while providing a steady revenue stream for reinvestment into the ecosystem. By separating IP management from operational activities, the IPSPV ensures that the SNO remains focused on innovation without losing control of its most valuable assets.
 
-- **Multisig Participation Agreements (MPAs)**
-    
-    MPAs are a foundational legal tool within the SNO framework. These agreements define the roles and responsibilities of multisig wallet signers, ensuring accountability and mitigating internal liability risks. By formalizing governance processes, MPAs reduce the chaos and inefficiency often associated with decentralized decision-making. They also protect contributors by clarifying liability boundaries, preventing signers from inadvertently exposing themselves to legal risks.
-    
-    MPAs are fully customizable, allowing SNOs to adapt them to their specific operational needs. They integrate seamlessly with Gnosis Safe wallets, creating a transparent and secure environment for managing resources.
-    
-- **Swiss Associations**
-    
-    Swiss Associations offer a flexible and cost-effective legal wrapper for early-stage SNOs. These entities provide liability protection, separate legal personhood, and the ability to engage in commercial activities that support the SNO’s mission. Notably, Swiss Associations do not require registration, preserving privacy while maintaining compliance. Their reputation as part of Switzerland’s crypto-friendly regulatory environment makes them ideal for DAOs transitioning into SNOs. These are typically used as legal structures for the OCR and IPSPV, while the OH and RGH may be Swiss foundations but their jurisdiction is likely determined by where inbound and outbound payments are taking place.
-    
-- **Open Source Legal Templates**
-    
-    Powerhouse has developed a library of open-source legal templates to simplify the setup and operation of SNO entities. These templates include Contributor Agreements, MPAs, and licensing contracts, reducing the complexity and cost of navigating legal requirements. By standardizing these processes, Powerhouse enables SNOs to focus on innovation and growth.
-    
 
-### Financial Sustainability and Growing SNOs
+### Legal Foundations for SNOs[​](https://staging.powerhouse.academy/docs/bookofpowerhouse/SNOsandANewModelForOSSandPublicGoods#legal-foundations-for-snos)
 
-SNOs leverage innovative financial mechanisms to incentivize contributions and ensure sustainability. **Contributor Proof of Work Tokens (POWTs)** are a mechanism in the Powerhouse ecosystem that acknowledge and quantify contributions to open-source public goods. They serve as both a **record of work done** and a **unit for potential future value capture**, ensuring contributors are recognized and fairly compensated within Scalable Network Organizations (SNOs).
+Legal structures are crucial for the success of SNOs, providing clarity, compliance, and protection.
 
-- **Aligning Incentives for Long-Term Value Creation**
-    
-    POWTs ensure that contributors to open-source public goods receive recognition and potential future upside when their work enables successful projects. By retroactively distributing revenue from monetized components, POWTs create a self-sustaining funding loop, reducing dependence on grants or donations. Multipliers further incentivize contributions to high-impact, long-term infrastructure, ensuring that even foundational work—often undervalued in traditional models—receives proper recognition and financial participation.
-    
-- **Efficient Compensation & Scalable Contribution Tracking**
-    
-    Instead of outdated timelogs, POWTs offer a transparent, structured accounting model that ties contributions directly to project components. Contributors receive compensation as a mix of cash and POWTs, with opportunity cost calculations ensuring fair valuation. POWTs act as on-chain attestations, enabling clear tracking of work history, efficient resource allocation, and dynamic revenue-sharing mechanisms that scale with the ecosystem’s growth. This structured approach streamlines financial operations across Scalable Network Organizations (SNOs).
-    
-- **Building Sustainable, Reputation-Driven Network Organizations**
-    
-    POWTs reinforce decentralized governance by embedding reputation and financial sustainability into the ecosystem. Contributors accumulate POWTs as proof of their impact, unlocking higher compensation tiers, governance privileges, and access to new opportunities. Since POWTs are non-transferable but convertible into Investor POWTs, they balance incentive alignment with long-term network resilience. This model attracts builders, investors, and organizations to SNOs by ensuring that contributions are rewarded while keeping the system free from short-term speculation.
-    
 
-### IP Management
 
-Intellectual property management is a cornerstone of SNOs, ensuring that contributions remain open and accessible while generating revenue.
+* Multisig Participation Agreements (MPAs) \
+MPAs are a foundational legal tool within the SNO framework. These agreements define the roles and responsibilities of multisig wallet signers, ensuring accountability and mitigating internal liability risks. By formalizing governance processes, MPAs reduce the chaos and inefficiency often associated with decentralized decision-making. They also protect contributors by clarifying liability boundaries, preventing signers from inadvertently exposing themselves to legal risks. \
+MPAs are fully customizable, allowing SNOs to adapt them to their specific operational needs. They integrate seamlessly with Gnosis Safe wallets, creating a transparent and secure environment for managing resources.
+* Swiss Associations \
+Swiss Associations offer a flexible and cost-effective legal wrapper for early-stage SNOs. These entities provide liability protection, separate legal personhood, and the ability to engage in commercial activities that support the SNO’s mission. Notably, Swiss Associations do not require registration, preserving privacy while maintaining compliance. Their reputation as part of Switzerland’s crypto-friendly regulatory environment makes them ideal for DAOs transitioning into SNOs. These are typically used as legal structures for the OCR and IPSPV, while the OH and RGH may be Swiss foundations but their jurisdiction is likely determined by where inbound and outbound payments are taking place.
+* Open Source Legal Templates \
+Powerhouse has developed a library of open-source legal templates to simplify the setup and operation of SNO entities. These templates include Contributor Agreements, MPAs, and licensing contracts, reducing the complexity and cost of navigating legal requirements. By standardizing these processes, Powerhouse enables SNOs to focus on innovation and growth.
 
-- **Dual Licensing Model**
-    
-    SNOs use a dual licensing approach to balance openness and monetization. A copyleft license governs the open-source version, requiring derivative works to remain open-source. Enterprise licenses allow proprietary use, generating revenue for the ecosystem.
-    
-- **IP-Holding Entity**
-    
-    The IPSPV serves as the guardian of intellectual property, managing licenses and defending against infringement. Structured as a neutral, autonomous entity, the IPSPV ensures that IP remains aligned with the SNO’s mission while facilitating revenue generation through licensing agreements.

package/docs/bookofpowerhouse/06-SNOsInActionAndPlatformEconomies.md

@@ -1,17 +1,48 @@
-# Part 5: SNOs in action and platform economies
-
-The **Powerhouse Operations Platform** is the core infrastructure that enables **Scalable Network Organizations (SNOs)** to function efficiently. It streamlines operations by integrating automated workflows, smart contracts, and model-driven development, ensuring efficient and transparent collaboration across distributed teams.
-
-- The Powerhouse Operations Platform
-    - **Payments & Compensation Management -** The platform facilitates seamless compensation processing by enabling contributors to receive payments in a structured and verifiable manner. It automates invoicing, integrates with fiat and crypto payment systems, and ensures compliance with contributor agreements. This eliminates manual overhead while maintaining clear records of work completed and payments disbursed.
-    - **Intellectual Property & Contribution Tracking -** To support open-source and collaborative innovation, the platform provides tools for managing IP ownership, licensing, and contribution history. It ensures that contributors are properly attributed for their work while protecting key assets that drive long-term sustainability.
-    - **Budgeting & Project Management -** Operational Hubs (Ops Hubs) use the platform to allocate budgets, track project milestones, and manage resources effectively. Smart contracts enforce budget limits, trigger payments upon project completion, and provide real-time financial insights. This enables scalable, transparent decision-making and ensures that funding is distributed efficiently across initiatives.
-    - The Powerhouse Operations Platform functions as a **full-stack operational system** for decentralized teams, ensuring smooth financial operations, legal clarity, and structured project execution in a distributed environment.
-    
-- Potential SNO use cases:
-    1. Open-source software Platforms
-    2. Decentralized networks and DAOs
-    3. Networks requiring IP management
-    4. Global Collaborative Networks
-    5. Consumer Marketplaces and Platforms
-    6. Public Goods
+# **Part 5: Powerhouse Platforms – Decentralized Operations and Builder**
+
+
+## **Introduction**
+
+The Powerhouse architecture is not only organizational but also deeply technological. To enable scalable network organizations (SNOs) to operate effectively, Powerhouse has developed two core platforms that provide the infrastructure for decentralized coordination and execution: the **Decentralized Operations Platform** and the **Builder Platform**. These platforms are complementary: one structures and stabilizes daily operations; the other opens up participation and innovation.
+
+Together, they form the digital substrate of the Powerhouse model, encoding its governance logic, collaboration structures, and incentive mechanisms directly into software.
+
+
+---
+
+
+## **Decentralized Operations Platform**
+
+The Decentralized Operations Platform serves as the operational engine of a SNO. It provides the workflows, rules, and execution logic required for contributors to collaborate without a central management layer. This includes systems for compensation, budgeting, IP management, and contributor reputation.
+
+At its core, the platform acts as a programmable coordination system. Contributors are onboarded, assigned tasks, compensated, and recognized through transparent, rule-based processes encoded in smart contracts and synchronized document models. These workflows are not static: they evolve based on activity, inputs, and contributor feedback, adapting to the changing needs of the network.
+
+The Decentralized Operations Platform also embeds accountability. Actions taken on the platform generate verifiable records—both financial and reputational—that form a shared source of truth. Disputes can be resolved, work can be audited, and contributors can prove their track record across projects and teams. This persistent memory allows SNOs to grow while retaining coherence and trust.
+
+Strategically, the platform supports multiple service categories, including governance operations, legal and financial services, and compliance. Each of these is modular, and the marketplace of service providers enables networks to plug in what they need, when they need it. Revenue is structured around project-based transactions and reinforced by policies that encourage on-platform fulfillment, ensuring alignment across stakeholders.
+
+
+---
+
+
+## **Builder Platform**
+
+While the Decentralized Operations Platform governs execution, the Builder Platform governs creation. It is designed for extending the Powerhouse architecture—enabling developers and contributors to build new tools, workflows, and modules that others in the ecosystem can use.
+
+The Builder Platform represents a shift in how coordination infrastructure is developed. Instead of building monolithic applications, contributors define document types, schemas, automation rules, and interfaces as reusable modules. These are published to a shared registry, where they can be discovered, forked, extended, or monetized.
+
+Every time a module is used in another network’s deployment, its original authors receive a share of the value generated. In this way, Powerhouse makes open-source infrastructure economically sustainable and creates a new incentive model for public goods.
+
+Technically, the Builder Platform is integrated with the rest of the Powerhouse stack. Its outputs are interoperable with the Operations Platform, the Governance layer, and the contributor onboarding systems. It uses typed schemas, CLI scaffolding, and standardized packaging to ensure modules are composable and production-ready.
+
+Strategically, the platform ensures that innovation remains decentralized. No single team or organization controls what can or cannot be built. Any contributor with sufficient context and intent can extend the system—and be rewarded for doing so. This model transforms Powerhouse from a static platform into a living ecosystem.
+
+
+---
+
+
+## **A Unified Infrastructure Layer**
+
+Together, these platforms operationalize the vision of scalable, decentralized networks. The Operations Platform provides the scaffolding for work: roles, rules, payments, and projects. The Builder Platform enables the ecosystem to evolve: by building, sharing, and monetizing new capabilities. They are not products to be sold—they are foundational infrastructure for a new kind of organization.
+
+Powerhouse is not simply offering software; it is building the operating system for a post-corporate world.

package/entrypoint.sh

@@ -0,0 +1,3 @@
+#!/bin/sh
+
+pnpm serve --host 0.0.0.0 --no-open --port $PORT

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@powerhousedao/academy",
-  "version": "0.1.0-dev.1",
+  "version": "0.1.0-dev.3",
   "homepage": "https://powerhouse.academy",
   "dependencies": {
     "@codesandbox/sandpack-react": "^2.14.4",

package/sidebars.ts

@@ -12,22 +12,56 @@ import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
  */
 const sidebars: SidebarsConfig = {
   // By default, Docusaurus generates a sidebar from the docs folder structure
-  academySidebar: [{type: 'autogenerated', dirName: 'academy'}],
-  bookofpowerhouseSidebar: [{type: 'autogenerated', dirName: 'bookofpowerhouse'}],
-  renownSidebar: [{type: 'autogenerated', dirName: 'renown'}],
+  academySidebar: [
+    {
+      type: 'category',
+      label: 'Get Started',
+      items: [{ type: 'autogenerated', dirName: 'academy/01-GetStarted' }],
+    },
+    {
+      type: 'category',
+      label: 'Advanced Tutorial',
+      items: [{ type: 'autogenerated', dirName: 'academy/02-AdvancedTutorial' }],
+    },
+    {
+      type: 'category',
+      label: 'API References',
+      items: [{ type: 'autogenerated', dirName: 'academy/03-APIReferences' }],
+    },
 
-  // But you can create a sidebar manually
-  /*
-  tutorialSidebar: [
-    'intro',
-    'hello',
+    // Manually define the Component Library category
     {
       type: 'category',
-      label: 'Tutorial',
-      items: ['tutorial-basics/create-a-document'],
+      label: 'Component Library',
+      items: [
+        {
+          type: 'html',
+          value: `
+            <a href="https://storybook.powerhouse.academy/" target="_blank" rel="noopener" style="display: flex; align-items: center; gap: 6px; font-weight: 500; text-decoration: none;">
+              <svg width="18" height="18" viewBox="0 0 24 24" fill="none" style="vertical-align: middle; margin-left: 13px;">
+                <rect width="24" height="24" rx="4" fill="#FF4785"/>
+                <text x="12" y="16" text-anchor="middle" fill="white" font-size="12" font-family="Arial" font-weight="bold">SB</text>
+              </svg>
+              Storybook
+            </a>
+          `,
+        },
+        // Autogenerate the rest of the docs in this folder
+        {type: 'autogenerated', dirName: 'academy/04-ComponentLibrary'},
+      ],
     },
+
+    // Everything after Component Library is still autogenerated
+    {
+      type: 'category',
+      label: 'Architecture',
+      items: [{ type: 'autogenerated', dirName: 'academy/05-Architecture' }],
+    },
+    { type: 'doc', id: 'academy/Cookbook', label: 'Cookbook' },
+    { type: 'doc', id: 'academy/Glossary', label: 'Glossary' },
+    // ...add more as needed
   ],
-   */
+  bookofpowerhouseSidebar: [{type: 'autogenerated', dirName: 'bookofpowerhouse'}],
 };
 
 export default sidebars;

package/src/components/HomepageFeatures/index.tsx

@@ -41,7 +41,7 @@ const FeatureList: FeatureItem[] = [
   {
     title: "Renown",
     imageSrc: require("@site/static/img/renown.png").default,
-    docPath: "/docs/renown/intro",
+    docPath: "/docs/academy/AdvancedTutorial/BuildingUserExperiences/Authorization/RenownAuthenticationFlow",
     description: (
       <>
         Dive into the customizable reputation system 

package/ProcFile

@@ -1 +0,0 @@
-web: npm run serve -- --port $PORT --host 0.0.0.0

package/docs/renown/01-intro.md

@@ -1,18 +0,0 @@
----
-# sidebar_position: 1
-sidebar_label: Renown
-displayed_sidebar: renownSidebar
----
-
-# Intro to Renown
-
-Renown is Powerhouse's decentralized identity and reputation system designed to address the challenge of trust within DAOs, where contributors often operate under pseudonyms. In traditional organizations, personal identity and reputation are key to establishing trust and accountability. Renown replicates this dynamic in the digital space, allowing contributors to earn experience and build reputation without revealing their real-world identities.
-
-## Decentralised identifiers & Verifiable Credentials
-
-At its core, Renown uses **decentralized identifiers and credentials**, enabling contributors to sign actions and contributions with their digital identity (tethered to Ethereum addresses), ensuring verifiable proof of their work. This reputation system incentivizes value-aligned behavior through gamification rewards, fostering collaboration without the need for direct management oversight. Over time, contributors can share their pseudonymous profiles with other organizations as cryptographic resumes, helping to secure new opportunities while maintaining privacy.
-
-By enabling trust and accountability in a pseudonymous environment, Renown strengthens decentralized collaboration and contributes to the scalability and efficiency of DAOs and open organisations.
-
-<img src="/img/Renown Intro Diagram.png" alt="renown diagram"/>
-*An overview of the Holder - Issuer - Verifier relationship that the decentralised identity system Renown makes use of to establish a self sovereign identity for it's users.*