@powerhousedao/academy 0.1.0-dev.0

package/docs/academy/02-AdvancedTutorial/01-Create/02-StandardDocumentModelWorkflow.md

@@ -0,0 +1,229 @@
+# Standard Document Model Workflow
+This tutorial will guide you through the process of creating a new document model using the Document Model Editor in the Connect app. 
+We'll use the Document Model Boilerplate, which provides code generation for scaffolding editors and models. 
+This boilerplate ensures compatibility with host applications like Connect and the Reactors for seamless document model and editor integration.
+
+<details>
+<summary>Available NPM commands</summary>
+
+-   `generate`: Updates the generated code according to the JSON spec and GraphQL schema.
+-   `lint`: Checks for errors with ESLint and TypeScript checking.
+-   `format`: Formats the code using Prettier.
+-   `build`: Builds the library project using Vite.
+-   `storybook`: Starts Storybook in development mode.
+-   `build-storybook`: Builds Storybook.
+-   `test`: Runs Jest for testing.
+
+</details>
+
+# Run Connect Locally
+
+Running Connect locally allows builders and developers to create, test, and deploy document models.   
+Connect can be locally launched through a simple CLI command using the provided npm package.   
+Once launched, the studio allows any developer or document model builder to run a local instance of the Connect hub on their machine and begin working immediately.
+
+## Setup of the local reactor
+
+:::info
+**Powerhouse Reactors** are the nodes in the network that store documents, 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.
+:::
+
+When using Connect in Studio mode a local reactor will be spun up which will function as the back-end to your local Connect frond-end service. This local reactor will make use of your local document storage and will eventually be able to sync with other reactors on the network, or the 'Powergrid', you will set up.
+
+## Let's get started
+
+Connect can be spun up through CLI commands in your favorite IDE. 
+Connect offers an interface to add your graphql schema and configure the settings of your document model. 
+Start with the following command to get started with the Powerhouse CLI
+
+```
+$ pnpm install -g ph-cmd
+```
+
+Your next step is to initialize the CLI with the following command. This will prompt the creation of a local configuratior file and accompagning reactor set up in .ph/documents.
+
+```
+ph init
+```
+<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>
+
+To run a local version of the Connect in Studio Mode use the following command
+
+```
+ph connect
+```
+
+### 1. Defining Your Document Model GraphQL Schema
+Start by creating your own document model library.
+
+Step 1: Run the following command to set up your document model library:
+
+```bash
+ph init
+```
+
+Step 2: Use the Document Model Editor in the Connect app:
+
+Launch Connect Studio Mode:
+
+```bash
+ph connect
+```
+## Document Model Creation
+
+At the core of Connect is the Document Model Editor. This powerful editor enables business analysts, user researchers, or aspiring document model builders to craft a GraphQL Schema Definition that reflects the business domain the document model will operate in. The schema serves as the foundation of the document model, defining its structure and how it interacts with the broader business processes. To learn more about domain modeling, please visit our section on Document Model dee
+
+Open the Document Model Editor to define your document schema.
+This schema will define the structure and fields for your document model using GraphQL.
+
+
+### 2. Defining Document Model Operations
+Using the Document Model Operations Editor, define the operations for your document model and their GraphQL counterparts. These operations will handle state changes within your document model.
+
+**Best Practices:**
+
+- Clearly define CRUD operations (Create, Read, Update, Delete).
+- Use GraphQL input types to specify the parameters for each operation.
+- Ensure that operations align with user intent to maintain a clean and understandable API.
+
+### 3. Generating Scaffolding Code
+Export your document model as a .zip file from Connect.
+Import the .zip file into your project directory created in Step 1.
+Run the following command to generate the scaffolding code:
+
+```bash
+ph generate YourModelName.phdm.zip
+```
+
+This will create a new directory under /document-models containing:
+
+JSON file with the document model specification.
+GraphQL file with state and operation schemas.
+A gen/ folder with autogenerated code.
+A src/ folder for your custom code implementation.
+
+### 4. Implementing Reducer Code and Unit Tests
+Navigate to the reducer directory:
+
+```bash
+cd document-models/"YourModelName"/src/reducers
+```
+
+Implement the reducer functions for each document model operation. These functions will handle state transitions.
+
+Add utility functions in:
+
+```bash
+document-models/"YourModelName"/src/utils.ts
+```
+
+Write unit tests to ensure the correctness of your reducers:
+
+Test files should be located in:
+
+```bash
+document-models/"YourModelName"/src/reducers/tests
+```
+
+Run the tests:
+
+```bash
+pnpm run test
+```
+
+Test the editor functionality:
+
+```bash
+ph connect
+```
+
+### 5. Implementing Document Editors
+Generate the editor template for your document model:
+
+```bash
+ph generate -- --editor YourModelName --document-types powerhouse/YourModelName
+```
+
+The --editor flag specifies the name of your document model.
+The --document-types flag links the editor to your document model type.
+After generation:
+
+Open the editor template:
+
+```bash
+editors/YourModelName/editor.tsx
+```
+
+Customize the editor interface to suit your document model.
+
+### 6. Testing the Document Editor
+Run the Connect app to test your document editor:
+
+```bash
+ph connect
+```
+
+Verify that the editor functions as expected.
+Perform end-to-end testing to ensure smooth integration between the document model and its editor.
+
+### 7. Adding a Manifest File
+Create a manifest file to describe your document model and editor. This enables proper integration with the host application.
+
+**Example manifest.json:**
+
+```json
+{
+  "name": "your-model-name",
+  "description": "A brief description of your document model.",
+  "category": "your-category", // e.g., "Finance", "People Ops", "Legal"
+  "publisher": {
+    "name": "your-publisher-name",
+    "url": "your-publisher-url"
+  },
+  "documentModels": [
+    {
+      "id": "your-model-id",
+      "name": "your-model-name"
+    }
+  ],
+  "editors": [
+    {
+      "id": "your-editor-id",
+      "name": "your-editor-name",
+      "documentTypes": ["your-model-id"]
+    }
+  ]
+}
+```
+
+### Steps to finalize:
+
+Place the manifest file at your project root.
+Update your index.js to export your modules and include the new document model and editor.
+
+### Final Thoughts
+You've now successfully created a Document Model and its corresponding Editor using the Connect app! 🚀
+
+Next Steps:
+- Expand functionality: Add more operations or complex logic to your document model.
+- Improve UX: Enhance the document editor for a smoother user experience.
+- Integrate with other systems: Use APIs or GraphQL to connect your document model with external services.

package/docs/academy/02-AdvancedTutorial/03-BuildingUserExperiences/01-BuildingBeautifulDocumentEditors.md

@@ -0,0 +1,109 @@
+# Build Document Editors
+
+*Placeholder for a tutorial about building beautiful document editors.*
+
+## Build with React on Powerhouse
+
+At Powerhouse, frontend development follows a simple and familiar flow. Tailwind CSS is installed by default and fully managed by Connect Studio — you can use Tailwind classes freely, but you’re not required to. Regular CSS, inline styles, and any React-compatible styling method work exactly as you would expect in a standard React project. There is no need to manually configure or run Tailwind or build processes; **Connect Studio automatically handles everything during development.**
+
+For component visualization and testing, **Connect Studio replaces the need for Storybook**. Please do not use Storybook by default — Connect Studio provides a dynamic, local environment where you can define and preview your document models and editors live. If you still wish to set up Storybook on your own, you may, but it is unsupported and discouraged.
+
+During normal development, simply run Connect Studio with `ph connect`. Manual build commands are only needed when you publish a package, at which point the necessary build steps (including CSS generation) are handled automatically.
+
+Powerhouse aims to keep your developer experience clean, familiar, and focused.
+- Build React components as you would in any project.
+- Use styling approaches you're comfortable with.
+- Trust Connect Studio to handle the setup for you.
+
+### Building with react hooks
+
+What are React Hooks?
+
+From the React docs:
+
+"Hooks let you use different React features from your components. You can either use the built-in Hooks or combine them to build your own."
+https://react.dev/reference/react/hooks
+
+The "combine them to build your own" part is key here. A so-called "custom hook" is just a function that uses these built-in hooks.
+
+There are several types of built-in hooks which are used to solve different problems.
+
+For example:
+
+State lets a component “remember” information like user input. 
+
+Effects let a component connect to and synchronize with external systems.
+
+Context lets a component receive information from distant parents without passing it as props.
+
+Details about custom hooks are provided here: https://react.dev/learn/reusing-logic-with-custom-hooks
+
+In summary, there are three reasons to use custom hooks:
+
+To re-use logic that calls multiple hooks.
+To abstract away the complexity of multiple hooks.
+To isolate the side effects of the useEffect hook.
+
+Hook names must start with use followed by a capital letter, like useState (built-in) or useOnlineStatus (custom, like earlier on the page). Hooks may return arbitrary values.
+
+https://react.dev/learn/reusing-logic-with-custom-hooks#hook-names-always-start-with-use
+
+When you use any function that starts with "use", react will treat it as a hook and expect it to follow the rules of hooks.
+
+Rules of Hooks
+https://react.dev/reference/rules/rules-of-hooks
+
+Hooks are defined using JavaScript functions, but they represent a special type of reusable UI logic with restrictions on where they can be called.
+
+Only call Hooks at the top level
+Only call Hooks from React functions
+
+React needs these rules to ensure that the state is properly managed and that the component behaves as expected.
+
+So it is indeed possible to create a "hook" like so:
+
+```
+function useCurrentTime() {
+  const currentTime = new Date().toLocaleTimeString();
+
+  return currentTime;
+}
+```
+
+And this is technically a hook, but making it a hook is pointless because it doesn't use any of the built-in hooks.
+
+There is no reason that this could not just be:
+
+```
+function getCurrentTime() {
+  return new Date().toLocaleTimeString();
+}
+```
+
+Because in a component, both hooks and normal functions are called on every render.
+
+So if your component looks like this:
+
+```
+function MyComponent() {
+  const currentTimeFromFunc = getCurrentTime();
+}
+```
+
+or this:
+
+```
+function MyComponent() {
+  const currentTimeFromHook = useCurrentTime();
+}
+```
+
+The end result would be the same. The function would be called on every render.
+
+So in summary, the only reason a function should be a hook is if it uses one or more built-in hooks.
+
+In general, you will not want to take a normal function and turn it into a hook, because your normal function should not have been trying to use react hooks in the first place.
+
+## Powerhouse Component Library
+
+TBD

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

@@ -0,0 +1,51 @@
+# 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.   
+
+## Prerequisites
+
+Before configuring drives, ensure you have:
+- Powerhouse [CLI installed](/docs/academy/AdvancedTutorial/Create/BuilderTools)
+- Access to a Powerhouse instance
+- Appropriate permissions to create and manage drives
+
+## Understanding Drives
+
+### 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.
+
+### Remote Drives vs. reactors 
+
+Remote drives in Powerhouse allow you to connect to and work with data stored in external systems or cloud services. These drives act as bridges between Powerhouse contributors and/or other data sources, enabling seamless data synchronization. Drives can exist in 3 category locations.
+
+- **Local Storage**: For offline or on-device access.
+- **Cloud Storage**: For centralized, scalable data management.
+- **Decentralized Storage**: Such as Ceramic or IPFS, enabling distributed and blockchain-based storage options.
+
+:::info
+**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. 
+
+A reactor allows you to store multiple documents, but also host **drives** & Drive Explorers with different organisational purposes, users, access rights and more.
+:::
+
+A drive exists by making use of a reactor and the storagelayer that specific reactor is based on. A reactor is the lower level component that makes synchronisation of documents & drives possible. 
+
+### 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.
+
+
+## Creating a New Drive
+
+![Create Drive Modal](./images/CreateDrive.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.
+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).
+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.
+

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

@@ -0,0 +1,174 @@
+# Build a Drive Explorer
+
+**Drive Explorers or Drive Apps** enhance how contributors and organizations interact with document models.   
+An 'app-like' experience is created by providing a **custom interface** for working with or exploring the contents of a drive.  
+:::tip 
+A 'Drive Explorer or Drive App' offers a tailored application designed around its document models.   
+Think of a Drive Explorer as a specialized lens—it offers **different ways to visualize, organize, and interact with** the data stored within a drive, making it more intuitive and efficient for specific use cases.
+:::
+
+### **Designed for Specific Use Cases**
+
+Most Drive Explorers are built by organizations for specific purposes, aligning closely with a document model package or even being part of one. By integrating Drive Apps with document models, organizations can customize user experiences, streamline workflows, and maximize efficiency for their contributors.
+
+Drive Explorers or Drive Apps **bridge the gap between raw data and usability**, unlocking the full potential of document models within the Powerhouse framework.
+
+### **Key Features of Drive Apps**
+
+- **Custom Views & Organization** – Drive Apps can present data in formats like Kanban boards, list views, or other structured layouts to suit different workflows.
+- **Aggregated Insights** – They can provide high-level summaries of important details across document models, enabling quick decision-making.
+- **Enhanced Interactivity** – Drive Apps can include widgets, data processors, or read models to process and display document data dynamically.
+
+### **Building a Drive App**
+
+#### The steps of our tutorial
+
+Drive Apps provide custom interfaces for interacting with the contents of a drive. 
+Here is a **quick overview** of the 3 different steps towards building a Drive App **before we dive into the Todo List Drive App**
+
+#### Step 1. Generate the scaffolding code
+
+Use the `generate drive editor` command to create the basic template structure for your Drive App:
+
+```bash
+
+ph generate --drive-editor <Drive App>
+```
+
+#### Step 2. Update the manifest file
+
+After creating your Drive App, update the `manifest.json` file with relevant information:
+The manifest file identifies your project and its components within the Powerhouse ecosystem.
+
+#### Step 3. Customize the Drive App
+
+Review the generated template and modify it to better suit your document model:
+
+1. Remove unnecessary files and components
+2. Add custom views specific to your data model
+3. Implement specialized interactions for your use case
+
+### About the Drive App template
+
+The default template provides a solid foundation. It contains:
+- A tree structure navigation panel
+- Basic file/folder operations
+- Standard layout components   
+
+But the real power comes from tailoring the interface to your specific document models.   
+ Now let's implement a specific example for a more complex todo-list then the one we've been working on. 
+
+### Implementation Example: Todo Drive Explorer
+
+This example demonstrates how to create a Todo Drive Explorer application using the Powerhouse platform. 
+The application allows users to create and manage todo lists with a visual progress indicator.
+
+**1. Create a Todo Document Model:**
+   - Initialize a new project with `ph init` and give it a project name. 
+
+   - Start by running Connect locally with `ph connect`
+
+:::warning
+Since you've likely already run through the [document modeling process](/docs/academy/GetStarted/ToDoList/DefineToDoListDocumentModel) of a simplified todo list, we'll offer you a **slightly more advanced** todo list below! 
+:::
+
+     - Download [todo.phdm.zip](https://github.com/powerhouse-inc/todo-drive-explorer/blob/ee63786fa8ceed71de63cd9c52f1795ad11ac403/todo.phdm.zip) from our GitHub repo. 
+     - Place it in the project root of your project
+     - Generate the document model:
+
+       ```bash
+       ph generate todo.phdm.zip
+       ```
+
+**2. Add the reducers code:**
+   - Copy the code from [base-operations.ts](https://github.com/powerhouse-inc/todo-drive-explorer/blob/ee63786fa8ceed71de63cd9c52f1795ad11ac403/document-models/to-do/src/reducers/base-operations.ts)
+   - Paste it into `document-models/to-do/src/reducers/base-operations.ts`
+
+**3. Generate a document editor:**
+   ```bash
+   ph generate --editor ToDoList --document-types powerhouse/todo
+   ```
+
+**4. Add the editor code:**
+   - Copy the code from [editor.tsx](https://github.com/powerhouse-inc/todo-drive-explorer/blob/ee63786fa8ceed71de63cd9c52f1795ad11ac403/editors/to-do-list/editor.tsx)
+   - Paste it into `editors/to-do-list/editor.tsx`
+
+**5. Generate a drive explorer app:**
+   ```bash
+   ph generate --drive-editor todo-drive-explorer
+   ```
+
+**6. Update the `powerhouse.manifest.json` file to register your Drive App with all its modules.**
+
+  - The information of the manifest file is what the user of your package will see when installing the package:
+
+   ```json
+   {
+     "name": "Todo List Package",
+     "description": "A simple todo list with a dedicated Drive Explorer App",
+     "category": "Productivity",
+     "publisher": {
+       "name": "Powerhouse",
+       "url": "https://www.powerhouse.inc/"
+     },
+     "documentModels": [],
+     "editors": [],
+     "apps": [
+       {
+         "id": "todo-drive-explorer",
+         "name": "Todo Drive App",
+         "driveEditor": "todo-drive-explorer"
+       }
+     ],
+     "subgraphs": [],
+     "importScripts": []
+   }
+   ```
+
+### Customize the Drive Explorer App
+
+**1. Remove unnecessary default components:**   
+
+- Remove default template files that won't be needed for our specific demo. If you'd like to see what the default template Drive App looks like, you can visualize it by running `ph connect`.
+
+```bash
+rm -rf editors/todo-drive-explorer/hooks
+rm -rf editors/todo-drive-explorer/components/FileItemsGrid.tsx
+rm -rf editors/todo-drive-explorer/components/FolderItemsGrid.tsx
+rm -rf editors/todo-drive-explorer/components/FolderTree.tsx
+```
+
+**2. Create new custom components for you drive explorer app:**
+
+   - Create and populate the following files to create our types for the todos & our components to customize the Drive Explorer.
+
+     a. Create `editors/todo-drive-explorer/types/todo.ts`:
+     - Copy the code from [todo.ts](https://github.com/powerhouse-inc/todo-drive-explorer/blob/ee63786fa8ceed71de63cd9c52f1795ad11ac403/editors/todo-drive-explorer/types/todo.ts)
+
+     This type represents the specific data structure or state shape that the todo-drive-explorer component uses to manage or display To-Do items.
+
+     b. Create `editors/todo-drive-explorer/components/ProgressBar.tsx`:
+     - Copy the code from [ProgressBar.tsx](https://github.com/powerhouse-inc/todo-drive-explorer/blob/ee63786fa8ceed71de63cd9c52f1795ad11ac403/editors/todo-drive-explorer/components/ProgressBar.tsx)
+
+     c. Update `editors/todo-drive-explorer/components/DriveExplorer.tsx`:
+     - Copy the code from [DriveExplorer.tsx](https://github.com/powerhouse-inc/todo-drive-explorer/blob/ee63786fa8ceed71de63cd9c52f1795ad11ac403/editors/todo-drive-explorer/components/DriveExplorer.tsx)
+
+     d. Update `editors/todo-drive-explorer/components/EditorContainer.tsx`:
+     - Copy the code from [EditorContainer.tsx](https://github.com/powerhouse-inc/todo-drive-explorer/blob/ee63786fa8ceed71de63cd9c52f1795ad11ac403/editors/todo-drive-explorer/components/EditorContainer.tsx)
+
+**3. Now that we've written the functional code for our Drive App it's time to run the application:**
+   ```bash
+   ph connect
+   ```
+
+   ![Todo Drive Explorer Demo](https://raw.githubusercontent.com/powerhouse-inc/todo-drive-explorer/9a87871e61460e73ddf8635fd756a0cd991306d6/demo.gif)
+
+### **Start Building Your Own Drive Apps, Explorers or Experiences**
+Congratulations on completing this tutorial! You've successfully built a custom Drive Explorer, enhancing the way users interact with document models.
+
+Now, take a moment to think about the possibilities!
+- What **unique Drive Experiences** could you create for your own projects? 
+- How can you tailor interfaces and streamline workflows to unlock the full potential of your document models? 
+
+The Powerhouse platform provides the tools. It's time to start building!
+

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

@@ -0,0 +1,67 @@
+# Operations History
+
+## What Is a Document Model?
+A **document model** in Powerhouse is the core unit for managing business data. Each document (such as an invoice, contributor agreement, or scope of work) is created from a specific document model, which defines:
+
+- **State schema:** What data the document contains
+- **Operations:** What actions can modify that document
+
+## What Is Operations History?
+Every time a user edits a document, they do so by submitting a document operation (e.g., `ADD_LINE_ITEM`, `UPDATE_RECIPIENT`). These operations are:
+
+- **Appended** to the document's history
+- **Immutable** (you never overwrite; you always append)
+- **Replayable** — the current document state is the result of applying all past operations in sequence
+
+This design is based on **event sourcing** principles.
+
+## Why Use an Operations History?
+- **Auditability:** Inspect every change ever made to a document.
+- **Transparency:** Contributors see what others have done.
+- **Versioning:** Revert to any prior state or resolve conflicts using branching and merging.
+- **Interoperability:** Operations are just data—they can be signed, stored on-chain, or synchronized across systems.
+
+
+## Example: Invoice Document
+Suppose you're editing a `powerhouse/invoice` document. Its operations history might look like this:
+
+```plaintext
+SET_RECIPIENT(name: "Acme Corp")
+ADD_LINE_ITEM(description: "Design Work", unitCost: $500)
+UPDATE_DUE_DATE(date: "2025-06-01")
+```
+
+The document's state at any time is the result of running those operations in order.
+
+## Visualizing Operations History
+
+### Revision List and Details
+In Connect the Powerhouse UI displays a chronologic list of all applied modifications to the document, each with a unique event ID, state hash, and commit message. You can inspect each revision for signatures and errors.
+
+![Revision History List](./images/revision-history-list.png)
+
+
+### Viewing Revision Hashes and Event IDs
+Hovering over a revision reveals its event ID and state hash, providing traceability for every change.
+
+![Revision Hash Popup](./images/revision-hash-popup.png)
+
+
+### 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. 
+
+![Signature Details Popup](./images/signature-details-popup.png)
+
+
+### Viewing Committer Addresses
+You can also view the committer's address for each revision, supporting full transparency and accountability.
+
+![Committer Address Popup](./images/committer-address-popup.png)
+
+
+## Replay, Branch, and Merge (UNDER DEVELOPMENT)
+- **Replay:** When you load a document, the system replays all operations to build its state.
+- **Branch:** Create a parallel version of the document to test changes or handle conflicts.
+- **Merge:** Combine branches intelligently based on operations, not just raw field values.
+