@powerhousedao/academy 0.1.0-dev.0

package/docs/academy/07-Glossary.md

@@ -0,0 +1,50 @@
+# Glossary
+
+## 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.
+
+## Organizational Concepts
+- **Network Organization** – A group of independent contributors and teams working together towards a common purpose, relying on decentralization and resource sharing.
+- **Keiretsu** – A Japanese term referring to networks of independent companies collaborating while maintaining their legal autonomy.
+- **Mondragon Corporation** – A Spanish federation of worker cooperatives that exemplifies the network organization model.
+- **Genesis Wrapper** – The initial legal entity representing a SNO, usually a Swiss Association that acts as a wrapper around the multisig wallet.
+
+## Governance & Legal
+- **Proof of Work Tokens (POWts)** – A legal instrument used to measure opportunity costs for contributors in a SNO.
+- **Multisig Participation Agreement (MPA)** – A contractual agreement regulating the responsibilities of multisig signers within the network.
+- **Operational Hub (OH)** – An entity within the SNO responsible for managing contributors, contracts, and payments.
+
+## Technology & Framework
+- **Powerhouse Framework** – A technical architecture designed to support SNOs by capturing data and automating processes.
+- **CQRS (Command Query Responsibility Segregation)** – A pattern that separates read and write operations to improve scalability.
+- **Event Sourcing** – A method of storing system state as a sequence of immutable events rather than modifying a single record.
+- **Event-Driven Architecture (EDA)** – A software design approach where system flows are determined by events that trigger actions asynchronously.
+
+## Powerhouse Platforms
+- **Dope** – A decentralized operations platform connecting finance, legal, governance, and people ops service providers with SNOs.
+- **Modlr** – A builder platform that helps users create SNO software platforms using the Powerhouse framework.
+
+## Software Components
+- **Reactor** – A storage node for Powerhouse documents and files with multiple storage adapters (local, cloud, decentralized).
+- **Powerhouse Switchboard** – A scalable API service that aggregates and processes document data.
+- **Powerhouse Fusion** – A platform front-end that hosts the public marketplace for SNO interactions.
+- **Powerhouse Renown** – A decentralized authentication system managing contributor reputation.
+- **Powerhouse Academy** – A training platform for onboarding and upskilling SNO contributors.
+- **Powergrid** – A decentralized network of reactors that sync with each other.
+
+## Development & Data Modeling
+- **Document Models** – Structured data models that define how Powerhouse documents store and process information.
+- **Document Model Editors** – An interface or UI to a document model that allows users to create and modify the data captured by the document models.
+- **Powerhouse Project** – A collection of document models, document model editors, and other resources being build in Connect Studio.
+- **Host Applications** – Applications that use the Powerhouse framework to create and manage documents and data.
+- **Packages** – A collection of document models, document model editors, and other resources that are published as a package and can be used in any of the host applications.
+- **GraphQL Scalars** – Data types used in Powerhouse document modeling (e.g., `String`, `Int`, `Currency`, `OID` for unique object IDs).
+- **NanoID** – A small, unique identifier used to reference objects within the Powerhouse framework.
+- **Model-Driven Development (MDD)** – A software approach that uses high-level models to generate system logic and configurations.
+- **Strands** – A single synchronization channel that connects exactly one unit of synchronization to another, with all four parameters (drive_url, doc_id, scope, branch) set to fixed values. This allows synchronization between two distinct points of instances of a document or document drive.
+
+## AI & Automation
+- **AI Assistants** – AI-powered contributors paired with human contributors to automate tasks and improve productivity.
+- **AI Contributor Modes** – Configurable states that determine the AI assistant’s behavior, permissions, and task focus.
+- **Task Automation & Scaling** – The use of AI to streamline repetitive tasks, improve communications, and enhance decision-making.

package/docs/bookofpowerhouse/01-Overview.md

@@ -0,0 +1,29 @@
+# Overview
+
+Powerhouse is an initiative at the intersection of software development, legal innovation, and new business models for open-source projects. These elements form a common vision for reimagining how software is created, funded, and sustained. While each component has its own purpose, they are deeply interconnected and designed to support one another.
+
+<div style={{ margin: '20px 0', textAlign: 'center' }}>
+  <iframe
+    src="https://drive.google.com/file/d/125zalHkrfpEsunm4b_5q6cQEHSmDsOKc/preview"
+    frameBorder="0"
+    allow="autoplay; fullscreen"
+    allowFullScreen
+    title="Powerhouse Overview Video"
+    style={{
+      width: '100%',
+      maxWidth: '960px',
+      aspectRatio: '16 / 9',
+      borderRadius: '8px',
+      display: 'block',
+      margin: '0 auto'
+    }}
+  ></iframe>
+</div>
+
+Book of Powerhouse Outline: 
+
+1. General Framework and Philosophy
+2. Powerhouse Software Architecture
+3. Technical Development Approaches
+4. SNOs as an extension of DAOs
+5. The Powerhouse Operations Platform

package/docs/bookofpowerhouse/02-GeneralFrameworkAndPhilosophy.md

@@ -0,0 +1,15 @@
+# Part 1: General Framework and Philosophy
+
+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.
+
+### 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.

package/docs/bookofpowerhouse/03-PowerhouseSoftwareArchitecture.md

@@ -0,0 +1,33 @@
+# Part 2: Powerhouse Software Architecture
+
+Powerhouse’s software architecture is designed to empower scalable, decentralized organizations with a modular, layered approach. It uses document models as the core unit that used across three layers: 
+- the **Data Infrastructure Layer**, which handles secure storage and synchronization across local, cloud, and decentralized systems; 
+- the **Host Application Layer**, which provides contributor tools like Powerhouse Connect and Fusion; 
+- and the Customization **Layer**, enabling bespoke solutions for specific use cases. 
+
+## Software Architecture
+
+### Document Models
+    - A **document model** is a structured representation of data and workflows that captures relationships, states, and operations within a system. By treating documents as dynamic entities that evolve over time, document models allow multiple people to contribute, make changes, and track progress in a flexible and transparent way. Document models are central to Powerhouse’s development approach, forming the backbone of adaptable workflows and versatile data management. In environments where contributors work asynchronously and systems must respond to evolving needs, document models provide the flexibility and responsiveness that traditional, static structures often lack.
+    - Building on this foundation, Powerhouse’s document models are designed to go beyond static data storage, encapsulating the complex relationships, states, and operations that drive decentralized workflows. Each document functions as a living entity, continuously evolving to reflect updates and interactions among contributors. This allows for:
+        - **Asynchronous Collaboration**: Contributors can work on documents without being bound by linear processes. For example, a task document can move through different states (e.g., draft, review, approved) based on specific triggers or events.
+        - **Customizable Processes**: Document models are highly adaptable, supporting unique workflows for different teams or organizations. This flexibility ensures that systems can address specialized requirements while maintaining overall consistency and transparency.
+        - **Event-Driven Updates**: By integrating with Powerhouse’s event-driven architecture, documents can respond to real-time changes, such as new data inputs or status updates, ensuring workflows remain efficient and responsive.
+
+### Three layers of Powerhouse
+    1. **Data Infrastructure Layer -** This layer is responsible for data storage and synchronization, whether locally, in the cloud, or on decentralized storage networks like Ceramic or IPFS. It includes: 	
+        - **Reactor**: A storage node for documents and files, supporting multiple storage adapters for various environments.
+        - **Powerhouse Network Components**: services required to build scalable networks of Reactor nodes, such as event buses, queues, caching services, and load balancers.
+
+    2. **Host Application Layer - t**his layer provides the tools to build apps and platforms using modular host applications. Each host application is an empty shell that gains functionality through plugins. The key host applications include: 
+        - **Powerhouse Connect**: Tools for contributors to perform their roles with tailored plugins for document management.
+        - **Powerhouse Switchboard**: A scalable API service for aggregating data into operational, analytical, or other specialized read models.
+        - **Powerhouse Fusion**: Public-facing collaboration platforms or marketplaces for the SNO’s platform economy.
+        - **Powerhouse Renown**: Decentralized authentication and reputation management for contributors.
+        - **Powerhouse Academy**: Onboarding and training tools for contributors, offering tutorials and reputation badges.
+
+    3. **Customization Layer - t**his layer consists of organization-specific plugins and instances of the host applications. It enables customization and deployment of unique platforms for each network organization. Examples include: 
+        - **Connect Plugins**: Tailored apps for contributors.
+        - **Switchboard Plugins**: Aggregated data and API services.
+        - **Fusion Plugins**: Custom marketplaces and user-facing platforms.
+        - **Renown and Academy Plugins**: Contributor reputation systems and training resources.

package/docs/bookofpowerhouse/04-DevelopmentApproaches.md

@@ -0,0 +1,36 @@
+# Part 3: Development Approaches
+
+Powerhouse’s development approaches are designed to enable efficient, scalable, and innovative solutions for decentralized organizations. By drawing from blockchain principles, adopting Model-Driven Development (MDD), leveraging dynamic document models, and employing a Rapid Application Development (RAD) process, Powerhouse provides a comprehensive framework to address the unique challenges of decentralized systems. 
+
+These methodologies enhance collaboration, streamline workflows, and accelerate iteration cycles, empowering teams to design, implement, and adapt their solutions seamlessly while staying aligned with Powerhouse’s vision for sustainable and decentralized growth.
+
+### Blockchain principles applied to decentralized operations
+    - Powerhouse’s development approach draws inspiration from the principles of blockchain technology while adapting them to meet the specific needs of decentralized organizations. These principles heavily influence its architecture, blending blockchain’s strengths with practical adaptations for scalable operations.
+    - Powerhouse shares several core ideas with blockchain:
+        - **Immutability**: Like a blockchain, Powerhouse emphasizes immutable data records. Through event sourcing, every state change is preserved as an append-only event, ensuring transparent, auditable histories.
+        - **Decentralization**: Both systems operate without relying on a centralized authority. Powerhouse’s Document Synchronization Protocol (DocSync) does not rely on a centralized server but can run P2P. It is also storage agnostic, so there is no lock-in. Users have the option to rely on decentralized, centralized or local storage solutions.
+        - **Transparency**: Inspired by the visibility of blockchain transactions, Powerhouse ensures operational workflows and changes are traceable, which makes governance and accountability easier.
+    - While Powerhouse builds on blockchain principles, it diverges in key ways to address operational challenges:
+        - **Local Scalability**: Blockchain’s global consensus can limit speed and scalability. Powerhouse prioritizes local-first workflows, ensuring contributors can operate efficiently without requiring global synchronization.
+        - **Tailored Operations**: Unlike blockchain’s general-purpose design, Powerhouse’s architecture focuses on organizational needs, supporting custom workflows, dynamic governance, and flexible scaling.
+
+### Model-Driven Development & Rapid Application Development (RAD)
+    - Powerhouse leverages **Model-Driven Development (MDD)** and **Rapid Application Development (RAD)** to streamline the creation of scalable, decentralized systems.
+    - MDD enables cross-functional collaboration by using **abstract models** as blueprints for workflows, data, and system behaviors—similar to how GraphQL schemas unify API design. These models ensure alignment across teams, enable early validation, and support seamless system evolution. **Meta-models** extend this by automating code generation, documentation, and workflow updates, reducing manual effort and ensuring consistency.
+    - RAD accelerates development by eliminating backend complexity and leveraging **automated code generation**. Pre-built frameworks and reusable components let developers focus on UI/UX without managing backend logic. An **event-driven architecture** handles state and data sync, while document models serve as a **source of truth**, ensuring APIs, data structures, and front-end scaffolding stay in sync. Developers can rapidly iterate on tailored user experiences—akin to “swapping skins” in a game—without disrupting core functionality.
+
+        
+### CQRS (Command Query Responsibility Segregation)
+    - CQRS, or Command Query Responsibility Segregation, is a key design principle in Powerhouse’s software architecture. It separates the responsibilities of handling write operations (commands) and read operations (queries) into distinct models, optimizing both for their specific purposes.
+    - In the Powerhouse framework:
+        - **Commands** handle operations that modify the state, such as creating or updating documents. These commands are validated and stored as events, forming the immutable history central to the system’s transparency and auditability.
+        - **Queries** are optimized for retrieving data, leveraging read models designed for performance, scalability, and flexibility. These models aggregate data from events to provide users with tailored insights, whether for analytics, search, or operational tasks.
+    - This separation offers significant advantages:
+        1. **Scalability**: Write and read models can scale independently, allowing Powerhouse to support large decentralized organizations without performance bottlenecks.
+        2. **Maintainability**: By isolating business logic (commands) from query logic, developers can iterate on one without affecting the other, ensuring the system evolves efficiently.
+        3. **Flexibility**: Powerhouse supports multiple types of read models—such as operational databases, full-text search, and analytics—each tailored to specific organizational needs.
+        
+### Event-driven Architectures (EDA)
+    - Event-Driven Architecture (EDA) is a foundational element of Powerhouse’s software philosophy, designed to create responsive, scalable systems that support asynchronous workflows. In EDA, events represent meaningful changes or actions, such as “Document Updated” or “Contributor Added,” and these events trigger reactions across the system in real time.
+    - EDA enables Powerhouse to design systems that are inherently responsive and scalable. By decoupling components, EDA allows systems to react to events independently, ensuring high availability and performance even as complexity grows. For example, when a document is updated, different processes like validation, notifications, and analytics generation can run in parallel without blocking each other. This architecture makes Powerhouse systems highly efficient in handling distributed operations, as it allows them to scale dynamically by adding or replicating components where needed. It also improves fault tolerance, as failures in one part of the system do not cascade to others due to the loosely coupled design.
+    - **Asynchronous Workflows -** EDA is particularly effective in supporting asynchronous workflows, which are critical for decentralized organizations. In this model, components communicate through events, eliminating the need for direct dependencies. This loose coupling enables workflows to operate flexibly, allowing different tasks to be executed simultaneously without blocking others. For instance, when a contributor submits work, separate processes—like task approval, logging, and analytics—can run independently, ensuring smoother coordination. Additionally, event histories can be replayed to debug workflows or audit past operations, providing transparency and traceability essential to decentralized systems.

package/docs/bookofpowerhouse/05-SNOsandANewModelForOSSandPublicGoods.md

@@ -0,0 +1,73 @@
+# Part 4: SNOs and a new model for OSS and Public Goods
+
+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
+
+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.
+
+- **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
+
+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).
+
+- **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.
+
+- **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

@@ -0,0 +1,17 @@
+# 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

package/docs/renown/01-intro.md

@@ -0,0 +1,18 @@
+---
+# 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.*

package/docs/renown/02-renown-login-flow.md

@@ -0,0 +1,60 @@
+---
+# sidebar_position: 1
+sidebar_label: Renown Login Flow
+displayed_sidebar: renownSidebar
+---
+
+# Renown Login 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.
+
+### Detailed 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.
+
+#### 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`
+- This DID acts as the user's digital identifier across decentralized systems.
+
+#### 3. Credential Generation
+- A credential is generated, allowing the DID to sign operations on behalf of the user. This credential is stored on Ceramic, a decentralized data stream network.
+- Ceramic ensures that the credentials are securely stored and verifiable across the network. Credentials include the user's signing permissions and are linked to the DID.
+
+#### 4. Operation Signing with 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.
+
+#### 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.
+- The request includes critical metadata such as the user's Ethereum address, the DID, the signed operation, and other parameters required for validation.
+
+  ```json
+  {
+    "signerAddress": "0x1234...",
+    "hash": "did:key:2be4x...",
+    "signatureBytes": "Xmqy8FNz...",
+    "isVerified": true
+  } 
+  ```
+
+#### 6. Operation Validation and Execution
+- After Switchboard validates the operation, it ensures the operation context is accurate and the credentials match the signer. 
+- 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.
+
+:::info
+**Key Components used during login-flow**
+- **Renown**: Manages user identities via DID creation and Ethereum wallet integration.
+- **Ceramic**: Decentralized data stream where user credentials are stored and verified. 
+- **Connect**: The interface for users to perform operations. It uses the DID for signing operations.
+- **Switchboard**: Responsible for verifying credentials and operation signatures to ensure authenticity.
+:::
+
+This flow ensures that all actions within the Powerhouse ecosystem are secure, transparent, and verifiable, promoting trust in a pseudonymous contributor environment.

package/docusaurus.config.ts

@@ -0,0 +1,170 @@
+import { themes as prismThemes } from 'prism-react-renderer';
+import type { Config } from '@docusaurus/types';
+import type * as Preset from '@docusaurus/preset-classic';
+
+const config: Config = {
+  title: 'Powerhouse Academy',
+  tagline: 'Get started with the Powerhouse ecosystem',
+  favicon: 'img/ph-icon-light.svg',
+
+  // Set the production url of your site here
+  url: 'https://powerhouse.academy',
+  // Set the /<baseUrl>/ pathname under which your site is served
+  // For GitHub pages deployment, it is often '/<projectName>/'
+  baseUrl: '/',
+
+  // GitHub pages deployment config.
+  // If you aren't using GitHub pages, you don't need these.
+  organizationName: '', // Usually your GitHub org/user name.
+  projectName: '', // Usually your repo name.
+
+  onBrokenLinks: 'warn',
+  onBrokenMarkdownLinks: 'warn',
+  deploymentBranch: 'gh-pages',
+  trailingSlash: false,
+  onBrokenAnchors: 'ignore',
+
+  // Even if you don't use internationalization, you can use this field to set
+  // useful metadata like html lang. For example, if your site is Chinese, you
+  // may want to replace "en" with "zh-Hans".
+  i18n: {
+    defaultLocale: 'en',
+    locales: ['en'],
+  },
+
+  presets: [
+    [
+      'classic',
+      {
+        docs: {
+          sidebarPath: './sidebars.ts',
+          // Please change this to your repo.
+          // Remove this to remove the "edit this page" links.
+          editUrl:
+            'https://github.com/powerhouse-inc/powerhouse-docs/tree/dev',
+          showLastUpdateTime: false,
+          showLastUpdateAuthor: false,
+        },
+        theme: {
+          customCss: './src/css/custom.css',
+        },
+        blog: {
+          showReadingTime: false,
+          editUrl:
+            'https://github.com/powerhouse-inc/powerhouse-docs/tree/dev',
+          onInlineAuthors: 'ignore',
+          showLastUpdateTime: false,
+          showLastUpdateAuthor: false,
+        },
+        sitemap: {
+          changefreq: 'weekly',
+          priority: 0.5,
+          ignorePatterns: ['/tags/**'],
+          filename: 'sitemap.xml',
+        },
+      } satisfies Preset.Options,
+    ],
+  ],
+
+  themeConfig: {
+    // Replace with your project's social card
+    image: 'img/docusaurus-social-card.jpg',
+    algolia: {
+      appId: '2P4JJIQAAV',
+      apiKey: 'b5d796c3c48626f107dabdcb1cd77f29',
+      indexName: 'staging-powerhouse',
+      contextualSearch: true,
+    },
+    navbar: {
+      title: '',
+      logo: {
+        alt: 'My Site Logo',
+        src: 'img/Powerhouse-main.svg',
+        srcDark: 'img/Powerhouse-main-light.svg',
+      },
+      items: [
+        {
+          type: 'docSidebar',
+          sidebarId: 'academySidebar',
+          position: 'left',
+          label: 'Academy',
+        },
+        {
+          type: 'docSidebar',
+          sidebarId: 'bookofpowerhouseSidebar',
+          position: 'left',
+          label: 'Book of Powerhouse',
+        },
+        {to: '/blog', label: 'Blog', position: 'left'},
+        {
+          href: 'https://github.com/powerhouse-inc/powerhouse-docs',
+          label: 'GitHub',
+          position: 'right',
+        },
+      ],
+    },
+    footer: {
+      style: 'dark',
+      links: [
+        {
+          title: 'Docs',
+          items: [
+            {
+              label: 'Connect',
+              to: 'docs/academy/Architecture/PowerhouseArchitecture',
+            },
+            {
+              label: 'Reactor',
+              to: 'docs/academy/Architecture/PowerhouseArchitecture',
+            },
+            {
+              label: 'Switchboard',
+              to: 'docs/academy/Architecture/PowerhouseArchitecture',
+            },
+            {
+              label: 'Renown',
+              to: 'docs/academy/Architecture/PowerhouseArchitecture',
+            },
+            {
+              label: 'FAQ',
+              to: 'docs/academy/Architecture/PowerhouseArchitecture',
+            },
+            {
+              label: "Blog",
+              to: '/blog'
+            }
+          ],
+        },
+        {
+          title: 'Community',
+          items: [
+            {
+              label: 'Discord',
+              href: 'https://discord.gg/h7GKvqDyDP',
+            },
+            {
+              label: 'X',
+              href: 'https://x.com/PowerhouseDAO',
+            },
+          ],
+        },
+        {
+          title: 'More',
+          items: [
+            {
+              label: 'GitHub',
+              href: 'https://github.com/powerhouse-inc',
+            },
+          ],
+        },
+      ],
+      copyright: `Copyright © ${new Date().getFullYear()} Powerhouse, Inc.`,
+    },
+    prism: {
+      theme: prismThemes.github,
+      darkTheme: prismThemes.dracula,
+    },
+  } satisfies Preset.ThemeConfig,
+};
+
+export default config;

package/package.json

@@ -0,0 +1,50 @@
+{
+  "name": "@powerhousedao/academy",
+  "version": "0.1.0-dev.0",
+  "homepage": "https://powerhouse.academy",
+  "packageManager": "pnpm@10.9.0",
+  "scripts": {
+    "docusaurus": "docusaurus",
+    "start": "docusaurus serve",
+    "dev": "docusaurus start",
+    "build": "NODE_OPTIONS=--max_old_space_size=2048 docusaurus build",
+    "swizzle": "docusaurus swizzle",
+    "deploy": "docusaurus deploy",
+    "clear": "docusaurus clear",
+    "serve": "docusaurus serve",
+    "write-translations": "docusaurus write-translations",
+    "write-heading-ids": "docusaurus write-heading-ids",
+    "typecheck": "tsc",
+    "heroku-postbuild": "npm run build"
+  },
+  "dependencies": {
+    "@codesandbox/sandpack-react": "^2.14.4",
+    "@docusaurus/core": "^3.6.3",
+    "@docusaurus/preset-classic": "^3.6.3",
+    "@docusaurus/theme-search-algolia": "^3.7.0",
+    "@mdx-js/react": "^3.0.0",
+    "@powerhousedao/design-system": "^1.6.0",
+    "clsx": "^2.0.0",
+    "prism-react-renderer": "^2.3.0",
+    "react": "^18.0.0",
+    "react-dom": "^18.0.0"
+  },
+  "devDependencies": {
+    "@docusaurus/module-type-aliases": "^3.6.3",
+    "@docusaurus/tsconfig": "^3.6.3",
+    "@docusaurus/types": "^3.6.3",
+    "typescript": "^5.7.3"
+  },
+  "browserslist": {
+    "production": [
+      ">0.5%",
+      "not dead",
+      "not op_mini all"
+    ],
+    "development": [
+      "last 3 chrome version",
+      "last 3 firefox version",
+      "last 5 safari version"
+    ]
+  }
+}

package/sidebars.ts

@@ -0,0 +1,33 @@
+import type {SidebarsConfig} from '@docusaurus/plugin-content-docs';
+
+/**
+ * Creating a sidebar enables you to:
+ - create an ordered group of docs
+ - render a sidebar for each doc of that group
+ - provide next/previous navigation
+
+ The sidebars can be generated from the filesystem, or explicitly defined here.
+
+ Create as many sidebars as you want.
+ */
+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'}],
+
+  // But you can create a sidebar manually
+  /*
+  tutorialSidebar: [
+    'intro',
+    'hello',
+    {
+      type: 'category',
+      label: 'Tutorial',
+      items: ['tutorial-basics/create-a-document'],
+    },
+  ],
+   */
+};
+
+export default sidebars;