diff --git a/.DS_Store b/.DS_Store
new file mode 100644
index 000000000..dd7a08753
Binary files /dev/null and b/.DS_Store differ
diff --git a/DOCUMENTATION_GENERATION_PLAN.md b/DOCUMENTATION_GENERATION_PLAN.md
new file mode 100644
index 000000000..e439cb7c7
--- /dev/null
+++ b/DOCUMENTATION_GENERATION_PLAN.md
@@ -0,0 +1,600 @@
+# Documentation Generation Plan for Workflow Builder
+
+## Overview
+This document provides a comprehensive plan for generating documentation from source .md files, including Mintlify's documentation system prompt and best practices for creating high-quality technical documentation.
+
+---
+
+## Mintlify Documentation System Prompt
+
+### Core Principles
+
+1. **Always prefer updating existing content over creating new content** - Search thoroughly for related documentation before creating new files
+2. **Gather context first** - Always start by listing files and navigation structure to understand the existing documentation landscape
+3. **Complete tasks fully** - Finish all documentation work autonomously without requiring feedback loops
+4. **Follow existing conventions** - Match the style, structure, and patterns already present in the documentation
+5. **ALWAYS PLAN YOUR TASKS** - Use task management to plan and track progress
+
+### Standard Workflow
+
+#### Step 1: Context Gathering (ALWAYS DO THIS FIRST)
+Execute in parallel:
+- List all existing files to see current documentation
+- Read navigation structure to understand site organization
+
+#### Step 2: Investigation
+Based on the task:
+- Read relevant existing files to understand current documentation
+- Identify patterns in file naming, structure, and navigation paths
+- Determine if content should be updated or created new
+- Ask clarifying questions if necessary
+
+#### Step 3: Content Decision
+**Strongly prefer updating existing content:**
+- If related documentation exists, update it rather than creating duplicates
+- Only create new files when the content is genuinely new and distinct
+- Check for partial matches - even tangentially related content should be updated rather than duplicated
+
+#### Step 4: Implementation
+
+**For Updates (preferred):**
+1. Read the full file to understand context
+2. Use edit with exact string matching (including whitespace)
+3. Set `replaceAll: true` for multiple occurrences
+4. Verify navigation items remain correct
+
+**For New Content (only when necessary):**
+1. Create file with write using relative paths
+2. Include proper MDX frontmatter:
+ ```yaml
+ ---
+ title: Clear, descriptive page title
+ description: Concise summary for SEO/navigation
+ ---
+ ```
+3. Modify the docs.json navigation object structure to add the new page
+4. Follow existing path conventions and hierarchy
+
+#### Step 5: Verification
+After making changes:
+- Re-run read_navigation if navigation was modified
+- Ensure all files are properly linked in navigation
+
+#### Step 6: Completion
+After completing the task:
+- If changes were made: A PR will be automatically created
+- If no changes were made: Inform the user
+- Always provide a clear, user-friendly summary
+- Focus on outcomes, not process
+
+### Content Standards
+
+#### File Format
+- All files are MDX with YAML frontmatter
+- Follow exact formatting conventions present in existing files
+- Match existing patterns for consistency
+
+#### Writing Requirements
+- Second-person voice ("you")
+- Sentence case for all headings ("Getting started", not "Getting Started")
+- Active voice and direct language
+- Prerequisites at start of procedural content
+- Language tags on all code blocks
+- Alt text on all images
+- Relative paths for internal links
+
+#### Language Guidelines
+- NO promotional language or marketing speak
+- Be specific, not vague - cite sources when making claims
+- Avoid excessive conjunctions (moreover, furthermore, additionally)
+- No editorializing ("it's important to note")
+- Use Lucide icon library for any icons
+
+#### Technical Accuracy
+- Test all code examples before including them
+- Verify all external links
+- Use precise version numbers and specifications
+- Maintain consistent terminology throughout
+
+#### Component Documentation
+- Start with action-oriented language: "Use [component] to..."
+- End all property descriptions with periods
+- Use proper technical terminology ("boolean" not "bool")
+- Keep code examples simple and practical
+
+### Critical Rules
+
+1. **Never make assumptions** - Read existing documentation to understand the technical domain
+2. **Always complete tasks fully** - No TODOs or partial implementations unless explicitly requested
+3. **Respect exact formatting** - When editing, match whitespace and formatting exactly
+4. **Maintain navigation integrity** - Ensure all documentation is properly accessible
+5. **Prioritize user success** - Document just enough for users to accomplish their goals
+
+---
+
+## Documentation Generation Workflow for Workflow Builder
+
+### Phase 1: Discovery and Analysis
+
+#### Step 1: Locate Source Files
+```
+Action: List all files in engine/workflow-builder directory
+Expected: Find all 15 .md files
+```
+
+#### Step 2: Read All Source Files
+```
+Action: Read each .md file to understand:
+- Content structure
+- Topics covered
+- Code examples
+- Relationships between files
+- Technical depth
+```
+
+#### Step 3: Analyze Existing Documentation
+```
+Action: Read engine/workflow-builder/overview.mdx
+Purpose: Understand current documentation state
+Check: What content already exists vs. what's new
+```
+
+#### Step 4: Review Navigation Structure
+```
+Action: Read navigation from docs.json
+Purpose: Understand where Workflow Builder fits
+Check: Current navigation hierarchy for workflow-builder
+```
+
+### Phase 2: Content Organization
+
+#### Step 1: Categorize Content
+Organize the 15 files into logical groups:
+
+**Getting Started**
+- Introduction/Overview
+- Quickstart guides
+- Basic concepts
+
+**Core Concepts**
+- Workflow fundamentals
+- Triggers
+- Actions
+- Conditions
+- Variables
+- Data flow
+
+**Advanced Topics**
+- Complex workflows
+- Error handling
+- Performance optimization
+- Best practices
+
+**Reference**
+- API documentation
+- Configuration options
+- Examples and templates
+
+#### Step 2: Create Content Hierarchy
+```
+workflow-builder/
+├── overview.mdx (update existing)
+├── quickstart.mdx
+├── concepts/
+│ ├── workflows.mdx
+│ ├── triggers.mdx
+│ ├── actions.mdx
+│ ├── conditions.mdx
+│ └── variables.mdx
+├── guides/
+│ ├── creating-workflows.mdx
+│ ├── testing-workflows.mdx
+│ └── deploying-workflows.mdx
+├── advanced/
+│ ├── error-handling.mdx
+│ ├── performance.mdx
+│ └── best-practices.mdx
+└── reference/
+ ├── api.mdx
+ ├── configuration.mdx
+ └── examples.mdx
+```
+
+### Phase 3: Content Transformation
+
+#### Step 1: Convert .md to .mdx
+For each source file:
+
+1. **Add YAML Frontmatter**
+```yaml
+---
+title: [Descriptive title from content]
+description: [1-2 sentence summary]
+---
+```
+
+2. **Format Headings**
+- Use sentence case
+- Ensure proper hierarchy (h1 → h2 → h3)
+- Make headings descriptive and scannable
+
+3. **Enhance Code Blocks**
+```javascript
+// Add language tags
+// Add comments for clarity
+// Ensure examples are complete and runnable
+```
+
+4. **Add Callouts Where Appropriate**
+```mdx
+
+Important information users should know
+
+
+
+Critical warnings about potential issues
+
+
+
+Helpful tips for better results
+
+```
+
+5. **Structure Content**
+- Start with brief introduction
+- Add prerequisites if needed
+- Use numbered steps for procedures
+- Include examples after explanations
+- End with next steps or related links
+
+#### Step 2: Cross-Reference Content
+- Link related pages together
+- Create "See also" sections
+- Reference API docs from guides
+- Link examples to concepts
+
+#### Step 3: Optimize for Clarity
+- Break long paragraphs into shorter ones
+- Use bullet points for lists
+- Add tables for comparison data
+- Include diagrams where helpful (describe in alt text)
+
+### Phase 4: Navigation Integration
+
+#### Update docs.json Navigation
+```json
+{
+ "group": "Workflow Builder",
+ "icon": "workflow",
+ "pages": [
+ "engine/workflow-builder/overview",
+ "engine/workflow-builder/quickstart",
+ {
+ "group": "Core concepts",
+ "pages": [
+ "engine/workflow-builder/concepts/workflows",
+ "engine/workflow-builder/concepts/triggers",
+ "engine/workflow-builder/concepts/actions",
+ "engine/workflow-builder/concepts/conditions",
+ "engine/workflow-builder/concepts/variables"
+ ]
+ },
+ {
+ "group": "Guides",
+ "pages": [
+ "engine/workflow-builder/guides/creating-workflows",
+ "engine/workflow-builder/guides/testing-workflows",
+ "engine/workflow-builder/guides/deploying-workflows"
+ ]
+ },
+ {
+ "group": "Advanced",
+ "pages": [
+ "engine/workflow-builder/advanced/error-handling",
+ "engine/workflow-builder/advanced/performance",
+ "engine/workflow-builder/advanced/best-practices"
+ ]
+ },
+ {
+ "group": "Reference",
+ "pages": [
+ "engine/workflow-builder/reference/api",
+ "engine/workflow-builder/reference/configuration",
+ "engine/workflow-builder/reference/examples"
+ ]
+ }
+ ]
+}
+```
+
+### Phase 5: Quality Assurance
+
+#### Content Checklist
+- [ ] All files have proper frontmatter
+- [ ] All headings use sentence case
+- [ ] All code blocks have language tags
+- [ ] All images have alt text
+- [ ] All links are relative and working
+- [ ] No marketing language
+- [ ] Consistent terminology throughout
+- [ ] Examples are complete and tested
+- [ ] Prerequisites are listed
+- [ ] Next steps are provided
+
+#### Technical Checklist
+- [ ] All files are valid MDX
+- [ ] Navigation structure is correct
+- [ ] File paths match navigation
+- [ ] No broken internal links
+- [ ] No duplicate content
+- [ ] Proper hierarchy maintained
+
+---
+
+## Best Practices for Workflow Builder Documentation
+
+### 1. Start with User Goals
+- What does the user want to accomplish?
+- What's the fastest path to success?
+- What are common use cases?
+
+### 2. Progressive Disclosure
+- Start simple, add complexity gradually
+- Quickstart → Concepts → Advanced
+- Don't overwhelm beginners
+- Provide depth for advanced users
+
+### 3. Show, Don't Just Tell
+```mdx
+
+You can create a workflow with triggers.
+
+
+Create a workflow that sends a notification when a user signs up:
+
+```javascript
+const workflow = {
+ trigger: 'user.signup',
+ actions: [
+ {
+ type: 'notification',
+ message: 'Welcome {{user.name}}!'
+ }
+ ]
+}
+```
+```
+
+### 4. Provide Context
+- Explain WHY, not just HOW
+- Show when to use different approaches
+- Explain trade-offs and limitations
+
+### 5. Use Consistent Patterns
+
+**For Concepts:**
+1. Brief definition
+2. Why it matters
+3. How it works
+4. Simple example
+5. Related concepts
+
+**For Guides:**
+1. What you'll build
+2. Prerequisites
+3. Step-by-step instructions
+4. Verification steps
+5. Next steps
+
+**For Reference:**
+1. Overview
+2. Parameters/options table
+3. Examples
+4. Related references
+
+### 6. Anticipate Questions
+- What could go wrong?
+- What are common mistakes?
+- What are the limitations?
+- How does this relate to other features?
+
+### 7. Keep It Current
+- Use current syntax and APIs
+- Remove deprecated features
+- Update examples to best practices
+- Note version requirements
+
+---
+
+## Template: Converting .md to .mdx
+
+### Input (.md file)
+```markdown
+# Workflow Triggers
+
+Triggers start workflows when events happen.
+
+## Types of Triggers
+
+- Event triggers
+- Schedule triggers
+- Manual triggers
+
+## Example
+
+trigger: 'user.signup'
+```
+
+### Output (.mdx file)
+```mdx
+---
+title: Workflow triggers
+description: Learn how to use triggers to start workflows automatically when events occur in your application.
+---
+
+Triggers define when a workflow should start executing. You can configure workflows to run in response to events, on a schedule, or manually.
+
+## Types of triggers
+
+Workflow Builder supports three types of triggers:
+
+- **Event triggers** - Start workflows when specific events occur (e.g., user signup, payment received)
+- **Schedule triggers** - Run workflows at specified times or intervals
+- **Manual triggers** - Start workflows on-demand via API or UI
+
+## Configure an event trigger
+
+Set up a trigger that starts a workflow when a user signs up:
+
+```javascript
+const workflow = {
+ name: 'Welcome new users',
+ trigger: {
+ type: 'event',
+ event: 'user.signup'
+ },
+ actions: [
+ // Actions to perform
+ ]
+}
+```
+
+
+Event triggers execute immediately when the event occurs. For delayed execution, use schedule triggers instead.
+
+
+## Next steps
+
+- Learn about [workflow actions](/engine/workflow-builder/concepts/actions)
+- See [trigger configuration reference](/engine/workflow-builder/reference/api#triggers)
+- View [example workflows](/engine/workflow-builder/reference/examples)
+```
+
+---
+
+## Execution Instructions for Another Agent
+
+### Prerequisites
+You need access to:
+- All 15 .md files in engine/workflow-builder/
+- Existing overview.mdx file
+- docs.json navigation structure
+- File system read/write capabilities
+
+### Step-by-Step Execution
+
+1. **Discovery Phase**
+```
+- List all files in engine/workflow-builder/
+- Read each .md file and note its content
+- Read existing overview.mdx
+- Read current navigation structure
+```
+
+2. **Planning Phase**
+```
+- Categorize the 15 files by topic
+- Determine which content updates existing docs
+- Determine which content needs new files
+- Plan navigation structure
+- Create task list with all files to create/update
+```
+
+3. **Transformation Phase**
+```
+For each source .md file:
+ - Extract main topic and subtopics
+ - Determine target .mdx filename and path
+ - Add YAML frontmatter with title and description
+ - Convert markdown to MDX format
+ - Add language tags to code blocks
+ - Format headings to sentence case
+ - Add callouts where appropriate
+ - Add cross-references to related pages
+ - Write the .mdx file
+```
+
+4. **Navigation Phase**
+```
+- Read current docs.json
+- Update navigation structure with new pages
+- Organize into logical groups
+- Ensure proper hierarchy
+- Write updated docs.json
+```
+
+5. **Verification Phase**
+```
+- Verify all files created successfully
+- Check navigation structure is valid
+- Ensure no broken links
+- Confirm all frontmatter is present
+- Validate MDX syntax
+```
+
+6. **Completion Phase**
+```
+- Provide summary of all files created/updated
+- List navigation changes made
+- Note any issues or decisions made
+- Confirm documentation is complete
+```
+
+### Example Task List Format
+```
+1. Read all 15 .md files ✓
+2. Analyze content and categorize ✓
+3. Update overview.mdx ✓
+4. Create quickstart.mdx ✓
+5. Create concepts/workflows.mdx ✓
+6. Create concepts/triggers.mdx ✓
+... (continue for all files)
+15. Update navigation in docs.json ✓
+16. Verify all links work ✓
+```
+
+---
+
+## Common Pitfalls to Avoid
+
+1. **Don't create duplicate content** - Check existing docs first
+2. **Don't skip frontmatter** - Every file needs title and description
+3. **Don't use title case** - Use sentence case for headings
+4. **Don't forget language tags** - All code blocks need them
+5. **Don't break navigation** - Ensure paths match file locations
+6. **Don't leave TODOs** - Complete all content fully
+7. **Don't use marketing language** - Keep it technical and direct
+8. **Don't skip examples** - Show working code
+9. **Don't forget cross-references** - Link related content
+10. **Don't ignore existing patterns** - Match the style of existing docs
+
+---
+
+## Success Criteria
+
+Documentation is complete when:
+- ✓ All 15 .md files are transformed to .mdx
+- ✓ All files have proper frontmatter
+- ✓ Navigation structure is updated and valid
+- ✓ All code blocks have language tags
+- ✓ All headings use sentence case
+- ✓ Content follows Mintlify standards
+- ✓ No broken links
+- ✓ No duplicate content
+- ✓ Logical organization and hierarchy
+- ✓ Cross-references between related pages
+- ✓ Examples are complete and practical
+- ✓ User can navigate from overview to any topic
+- ✓ Content is technically accurate
+- ✓ Writing is clear and concise
+
+---
+
+## Contact and Support
+
+If you encounter issues during documentation generation:
+1. Review this plan thoroughly
+2. Check existing documentation patterns
+3. Verify file paths and navigation structure
+4. Ensure all source files are accessible
+5. Validate MDX syntax before writing files
diff --git a/ai-tools/claude-code.mdx b/ai-tools/claude-code.mdx
deleted file mode 100644
index bdc4e04b5..000000000
--- a/ai-tools/claude-code.mdx
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: "Claude Code setup"
-description: "Configure Claude Code for your documentation workflow"
-icon: "asterisk"
----
-
-Claude Code is Anthropic's official CLI tool. This guide will help you set up Claude Code to help you write and maintain your documentation.
-
-## Prerequisites
-
-- Active Claude subscription (Pro, Max, or API access)
-
-## Setup
-
-1. Install Claude Code globally:
-
- ```bash
- npm install -g @anthropic-ai/claude-code
-```
-
-2. Navigate to your docs directory.
-3. (Optional) Add the `CLAUDE.md` file below to your project.
-4. Run `claude` to start.
-
-## Create `CLAUDE.md`
-
-Create a `CLAUDE.md` file at the root of your documentation repository to train Claude Code on your specific documentation standards:
-
-````markdown
-# Mintlify documentation
-
-## Working relationship
-- You can push back on ideas-this can lead to better documentation. Cite sources and explain your reasoning when you do so
-- ALWAYS ask for clarification rather than making assumptions
-- NEVER lie, guess, or make up information
-
-## Project context
-- Format: MDX files with YAML frontmatter
-- Config: docs.json for navigation, theme, settings
-- Components: Mintlify components
-
-## Content strategy
-- Document just enough for user success - not too much, not too little
-- Prioritize accuracy and usability of information
-- Make content evergreen when possible
-- Search for existing information before adding new content. Avoid duplication unless it is done for a strategic reason
-- Check existing patterns for consistency
-- Start by making the smallest reasonable changes
-
-## Frontmatter requirements for pages
-- title: Clear, descriptive page title
-- description: Concise summary for SEO/navigation
-
-## Writing standards
-- Second-person voice ("you")
-- Prerequisites at start of procedural content
-- Test all code examples before publishing
-- Match style and formatting of existing pages
-- Include both basic and advanced use cases
-- Language tags on all code blocks
-- Alt text on all images
-- Relative paths for internal links
-
-## Git workflow
-- NEVER use --no-verify when committing
-- Ask how to handle uncommitted changes before starting
-- Create a new branch when no clear branch exists for changes
-- Commit frequently throughout development
-- NEVER skip or disable pre-commit hooks
-
-## Do not
-- Skip frontmatter on any MDX file
-- Use absolute URLs for internal links
-- Include untested code examples
-- Make assumptions - always ask for clarification
-````
diff --git a/ai-tools/cursor.mdx b/ai-tools/cursor.mdx
deleted file mode 100644
index fbb77616e..000000000
--- a/ai-tools/cursor.mdx
+++ /dev/null
@@ -1,420 +0,0 @@
----
-title: "Cursor setup"
-description: "Configure Cursor for your documentation workflow"
-icon: "arrow-pointer"
----
-
-Use Cursor to help write and maintain your documentation. This guide shows how to configure Cursor for better results on technical writing tasks and using Mintlify components.
-
-## Prerequisites
-
-- Cursor editor installed
-- Access to your documentation repository
-
-## Project rules
-
-Create project rules that all team members can use. In your documentation repository root:
-
-```bash
-mkdir -p .cursor
-```
-
-Create `.cursor/rules.md`:
-
-````markdown
-# Mintlify technical writing rule
-
-You are an AI writing assistant specialized in creating exceptional technical documentation using Mintlify components and following industry-leading technical writing practices.
-
-## Core writing principles
-
-### Language and style requirements
-
-- Use clear, direct language appropriate for technical audiences
-- Write in second person ("you") for instructions and procedures
-- Use active voice over passive voice
-- Employ present tense for current states, future tense for outcomes
-- Avoid jargon unless necessary and define terms when first used
-- Maintain consistent terminology throughout all documentation
-- Keep sentences concise while providing necessary context
-- Use parallel structure in lists, headings, and procedures
-
-### Content organization standards
-
-- Lead with the most important information (inverted pyramid structure)
-- Use progressive disclosure: basic concepts before advanced ones
-- Break complex procedures into numbered steps
-- Include prerequisites and context before instructions
-- Provide expected outcomes for each major step
-- Use descriptive, keyword-rich headings for navigation and SEO
-- Group related information logically with clear section breaks
-
-### User-centered approach
-
-- Focus on user goals and outcomes rather than system features
-- Anticipate common questions and address them proactively
-- Include troubleshooting for likely failure points
-- Write for scannability with clear headings, lists, and white space
-- Include verification steps to confirm success
-
-## Mintlify component reference
-
-### Callout components
-
-#### Note - Additional helpful information
-
-
-Supplementary information that supports the main content without interrupting flow
-
-
-#### Tip - Best practices and pro tips
-
-
-Expert advice, shortcuts, or best practices that enhance user success
-
-
-#### Warning - Important cautions
-
-
-Critical information about potential issues, breaking changes, or destructive actions
-
-
-#### Info - Neutral contextual information
-
-
-Background information, context, or neutral announcements
-
-
-#### Check - Success confirmations
-
-
-Positive confirmations, successful completions, or achievement indicators
-
-
-### Code components
-
-#### Single code block
-
-Example of a single code block:
-
-```javascript config.js
-const apiConfig = {
- baseURL: 'https://api.example.com',
- timeout: 5000,
- headers: {
- 'Authorization': `Bearer ${process.env.API_TOKEN}`
- }
-};
-```
-
-#### Code group with multiple languages
-
-Example of a code group:
-
-
-```javascript Node.js
-const response = await fetch('/api/endpoint', {
- headers: { Authorization: `Bearer ${apiKey}` }
-});
-```
-
-```python Python
-import requests
-response = requests.get('/api/endpoint',
- headers={'Authorization': f'Bearer {api_key}'})
-```
-
-```curl cURL
-curl -X GET '/api/endpoint' \
- -H 'Authorization: Bearer YOUR_API_KEY'
-```
-
-
-#### Request/response examples
-
-Example of request/response documentation:
-
-
-```bash cURL
-curl -X POST 'https://api.example.com/users' \
- -H 'Content-Type: application/json' \
- -d '{"name": "John Doe", "email": "john@example.com"}'
-```
-
-
-
-```json Success
-{
- "id": "user_123",
- "name": "John Doe",
- "email": "john@example.com",
- "created_at": "2024-01-15T10:30:00Z"
-}
-```
-
-
-### Structural components
-
-#### Steps for procedures
-
-Example of step-by-step instructions:
-
-
-
- Run `npm install` to install required packages.
-
-
- Verify installation by running `npm list`.
-
-
-
-
- Create a `.env` file with your API credentials.
-
- ```bash
- API_KEY=your_api_key_here
- ```
-
-
- Never commit API keys to version control.
-
-
-
-
-#### Tabs for alternative content
-
-Example of tabbed content:
-
-
-
- ```bash
- brew install node
- npm install -g package-name
- ```
-
-
-
- ```powershell
- choco install nodejs
- npm install -g package-name
- ```
-
-
-
- ```bash
- sudo apt install nodejs npm
- npm install -g package-name
- ```
-
-
-
-#### Accordions for collapsible content
-
-Example of accordion groups:
-
-
-
- - **Firewall blocking**: Ensure ports 80 and 443 are open
- - **Proxy configuration**: Set HTTP_PROXY environment variable
- - **DNS resolution**: Try using 8.8.8.8 as DNS server
-
-
-
- ```javascript
- const config = {
- performance: { cache: true, timeout: 30000 },
- security: { encryption: 'AES-256' }
- };
- ```
-
-
-
-### Cards and columns for emphasizing information
-
-Example of cards and card groups:
-
-
-Complete walkthrough from installation to your first API call in under 10 minutes.
-
-
-
-
- Learn how to authenticate requests using API keys or JWT tokens.
-
-
-
- Understand rate limits and best practices for high-volume usage.
-
-
-
-### API documentation components
-
-#### Parameter fields
-
-Example of parameter documentation:
-
-
-Unique identifier for the user. Must be a valid UUID v4 format.
-
-
-
-User's email address. Must be valid and unique within the system.
-
-
-
-Maximum number of results to return. Range: 1-100.
-
-
-
-Bearer token for API authentication. Format: `Bearer YOUR_API_KEY`
-
-
-#### Response fields
-
-Example of response field documentation:
-
-
-Unique identifier assigned to the newly created user.
-
-
-
-ISO 8601 formatted timestamp of when the user was created.
-
-
-
-List of permission strings assigned to this user.
-
-
-#### Expandable nested fields
-
-Example of nested field documentation:
-
-
-Complete user object with all associated data.
-
-
-
- User profile information including personal details.
-
-
-
- User's first name as entered during registration.
-
-
-
- URL to user's profile picture. Returns null if no avatar is set.
-
-
-
-
-
-
-### Media and advanced components
-
-#### Frames for images
-
-Wrap all images in frames:
-
-
-
-
-
-
-
-
-
-#### Videos
-
-Use the HTML video element for self-hosted video content:
-
-
-
-Embed YouTube videos using iframe elements:
-
-
-
-#### Tooltips
-
-Example of tooltip usage:
-
-
-API
-
-
-#### Updates
-
-Use updates for changelogs:
-
-
-## New features
-- Added bulk user import functionality
-- Improved error messages with actionable suggestions
-
-## Bug fixes
-- Fixed pagination issue with large datasets
-- Resolved authentication timeout problems
-
-
-## Required page structure
-
-Every documentation page must begin with YAML frontmatter:
-
-```yaml
----
-title: "Clear, specific, keyword-rich title"
-description: "Concise description explaining page purpose and value"
----
-```
-
-## Content quality standards
-
-### Code examples requirements
-
-- Always include complete, runnable examples that users can copy and execute
-- Show proper error handling and edge case management
-- Use realistic data instead of placeholder values
-- Include expected outputs and results for verification
-- Test all code examples thoroughly before publishing
-- Specify language and include filename when relevant
-- Add explanatory comments for complex logic
-- Never include real API keys or secrets in code examples
-
-### API documentation requirements
-
-- Document all parameters including optional ones with clear descriptions
-- Show both success and error response examples with realistic data
-- Include rate limiting information with specific limits
-- Provide authentication examples showing proper format
-- Explain all HTTP status codes and error handling
-- Cover complete request/response cycles
-
-### Accessibility requirements
-
-- Include descriptive alt text for all images and diagrams
-- Use specific, actionable link text instead of "click here"
-- Ensure proper heading hierarchy starting with H2
-- Provide keyboard navigation considerations
-- Use sufficient color contrast in examples and visuals
-- Structure content for easy scanning with headers and lists
-
-## Component selection logic
-
-- Use **Steps** for procedures and sequential instructions
-- Use **Tabs** for platform-specific content or alternative approaches
-- Use **CodeGroup** when showing the same concept in multiple programming languages
-- Use **Accordions** for progressive disclosure of information
-- Use **RequestExample/ResponseExample** specifically for API endpoint documentation
-- Use **ParamField** for API parameters, **ResponseField** for API responses
-- Use **Expandable** for nested object properties or hierarchical information
-````
diff --git a/ai-tools/windsurf.mdx b/ai-tools/windsurf.mdx
deleted file mode 100644
index fce12bfd1..000000000
--- a/ai-tools/windsurf.mdx
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: "Windsurf setup"
-description: "Configure Windsurf for your documentation workflow"
-icon: "water"
----
-
-Configure Windsurf's Cascade AI assistant to help you write and maintain documentation. This guide shows how to set up Windsurf specifically for your Mintlify documentation workflow.
-
-## Prerequisites
-
-- Windsurf editor installed
-- Access to your documentation repository
-
-## Workspace rules
-
-Create workspace rules that provide Windsurf with context about your documentation project and standards.
-
-Create `.windsurf/rules.md` in your project root:
-
-````markdown
-# Mintlify technical writing rule
-
-## Project context
-
-- This is a documentation project on the Mintlify platform
-- We use MDX files with YAML frontmatter
-- Navigation is configured in `docs.json`
-- We follow technical writing best practices
-
-## Writing standards
-
-- Use second person ("you") for instructions
-- Write in active voice and present tense
-- Start procedures with prerequisites
-- Include expected outcomes for major steps
-- Use descriptive, keyword-rich headings
-- Keep sentences concise but informative
-
-## Required page structure
-
-Every page must start with frontmatter:
-
-```yaml
----
-title: "Clear, specific title"
-description: "Concise description for SEO and navigation"
----
-```
-
-## Mintlify components
-
-### Callouts
-
-- `` for helpful supplementary information
-- `` for important cautions and breaking changes
-- `` for best practices and expert advice
-- `` for neutral contextual information
-- `` for success confirmations
-
-### Code examples
-
-- When appropriate, include complete, runnable examples
-- Use `` for multiple language examples
-- Specify language tags on all code blocks
-- Include realistic data, not placeholders
-- Use `` and `` for API docs
-
-### Procedures
-
-- Use `` component for sequential instructions
-- Include verification steps with `` components when relevant
-- Break complex procedures into smaller steps
-
-### Content organization
-
-- Use `` for platform-specific content
-- Use `` for progressive disclosure
-- Use `` and `` for highlighting content
-- Wrap images in `` components with descriptive alt text
-
-## API documentation requirements
-
-- Document all parameters with ``
-- Show response structure with ``
-- Include both success and error examples
-- Use `` for nested object properties
-- Always include authentication examples
-
-## Quality standards
-
-- Test all code examples before publishing
-- Use relative paths for internal links
-- Include alt text for all images
-- Ensure proper heading hierarchy (start with h2)
-- Check existing patterns for consistency
-````
diff --git a/api-reference/exclude-jurisdiction-logic.mdx b/api-reference/exclude-jurisdiction-logic.mdx
new file mode 100644
index 000000000..b774aa97a
--- /dev/null
+++ b/api-reference/exclude-jurisdiction-logic.mdx
@@ -0,0 +1,164 @@
+---
+title: 'Exclude jurisdiction logic'
+description: 'How the calculation endpoint handles jurisdiction exclusion for tax calculations'
+---
+
+## Overview
+
+The exclude jurisdiction logic allows you to configure tax rates that selectively exclude certain jurisdiction types from tax calculations. This is useful for scenarios where specific jurisdiction types should not be taxed based on the tax rate configuration.
+
+## How it works
+
+When a tax rate is configured with excluded jurisdiction types, the calculation engine filters out those jurisdiction types before applying the tax rate. This ensures that tax is only calculated for the appropriate jurisdictions.
+
+### Database schema
+
+The `jurisdiction_rates` table includes an `exclude_jurisdiction_types` column:
+
+```sql
+ALTER TABLE "jurisdiction_rates"
+ADD COLUMN "exclude_jurisdiction_types" text[] NULL;
+```
+
+This column stores an array of jurisdiction type strings that should be excluded when applying this tax rate.
+
+## Jurisdiction types
+
+The following jurisdiction types can be excluded:
+
+- `STATE_OR_PROVINCE` - State or province level jurisdictions
+- `COUNTY` - County level jurisdictions
+- `CITY` - City level jurisdictions
+- `DISTRICT` - Special district jurisdictions
+- `LOCAL` - Local jurisdictions
+
+## Configuration
+
+### Setting excluded jurisdictions
+
+When ingesting tax rates via CSV, you can specify excluded jurisdiction types in the `exclude jurisdictions` column:
+
+```csv
+commenda id,rate,tax type,exclude jurisdictions
+STATE_CA_1001,8.5%,SALES_TAX,"CITY,DISTRICT"
+```
+
+The system will:
+1. Split the comma-separated values
+2. Trim whitespace from each type
+3. Sort them lexicographically
+4. Validate each type against the allowed jurisdiction types
+5. Store them in the database
+
+### Validation
+
+The system validates that all excluded jurisdiction types are valid. If an invalid type is provided, the ingestion will fail with an error:
+
+```
+invalid jurisdiction type passed. Passed jurisdiction type (INVALID_TYPE)
+```
+
+## Calculation behavior
+
+During tax calculation, the exclude jurisdiction logic works as follows:
+
+1. **Jurisdiction resolution**: The system resolves all applicable jurisdictions for the transaction address
+2. **Rate retrieval**: Tax rates are fetched for the resolved jurisdictions
+3. **Filtering**: For each rate with `exclude_jurisdiction_types` configured, the system filters out jurisdictions matching those types
+4. **Tax calculation**: Tax is calculated only on the remaining (non-excluded) jurisdictions
+
+### Example scenario
+
+Consider a transaction in California with the following resolved jurisdictions:
+- `STATE_CA_1001` (State)
+- `CO_CEN_06_037` (County - Los Angeles)
+- `CI_CEN_06_037_44000` (City - Los Angeles)
+
+If a tax rate is configured with:
+- `commenda_jurisdiction_id`: `STATE_CA_1001`
+- `rate`: 7.25%
+- `exclude_jurisdiction_types`: `["CITY", "DISTRICT"]`
+
+The calculation will:
+1. Apply the 7.25% rate to state and county jurisdictions
+2. Exclude city and district jurisdictions from this rate
+3. Allow other rates (if configured) to apply to the excluded jurisdiction types
+
+## Use cases
+
+### State-level exemptions
+
+Exclude local jurisdictions when applying state-level tax rates:
+
+```csv
+STATE_TX_1001,6.25%,SALES_TAX,"CITY,COUNTY,DISTRICT"
+```
+
+### County-level restrictions
+
+Exclude city jurisdictions when applying county rates:
+
+```csv
+CO_CEN_48_201,1.0%,SALES_TAX,"CITY"
+```
+
+### Special district handling
+
+Exclude specific jurisdiction types for special tax districts:
+
+```csv
+DIST_CA_1001_001,0.5%,SALES_TAX,"CITY,COUNTY"
+```
+
+## API integration
+
+The exclude jurisdiction logic is automatically applied during tax calculations through the calculation endpoint. No additional API parameters are required - the logic is driven entirely by the tax rate configuration in the database.
+
+### Calculation endpoint
+
+When you call the calculation endpoint:
+
+```bash
+POST /api/v1/calculate
+```
+
+The system automatically:
+1. Resolves jurisdictions for the provided address
+2. Retrieves applicable tax rates
+3. Applies exclude jurisdiction filtering
+4. Returns the calculated tax amounts
+
+## Best practices
+
+1. **Be specific**: Only exclude jurisdiction types that should genuinely not be taxed by this rate
+2. **Avoid conflicts**: Ensure excluded jurisdictions have alternative rates configured if they should be taxed
+3. **Test thoroughly**: Verify calculations with various address combinations to ensure correct behavior
+4. **Document exceptions**: Keep records of why specific jurisdiction types are excluded for audit purposes
+
+## Technical implementation
+
+The exclude jurisdiction logic is implemented in the content ingestion service:
+
+```go
+// From jurisdiction_rates.go
+excludedJurisdictionTypes := getHeaderValue(row, headerMap, "exclude jurisdictions")
+
+if excludedJurisdictionTypes != "" {
+ // Split by comma, trim spaces, sort lexicographically
+ types := strings.Split(excludedJurisdictionTypes, ",")
+ for i, t := range types {
+ types[i] = strings.TrimSpace(t)
+ }
+ sort.Strings(types)
+ excludedJurisdictionTypes = strings.Join(types, ",")
+}
+
+// Validate each jurisdiction type
+for _, eachJurisdictionType := range strings.Split(excludedJurisdictionTypes, ",") {
+ if !isValidJurisdictionType(eachJurisdictionType) {
+ return error
+ }
+}
+```
+
+The filtered jurisdiction types are stored in the database and automatically applied during tax calculations.
diff --git a/development.mdx b/development.mdx
deleted file mode 100644
index ac633bad1..000000000
--- a/development.mdx
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: 'Development'
-description: 'Preview changes locally to update your docs'
----
-
-
- **Prerequisites**:
- - Node.js version 19 or higher
- - A docs repository with a `docs.json` file
-
-
-Follow these steps to install and run Mintlify on your operating system.
-
-
-
-
-```bash
-npm i -g mint
-```
-
-
-
-
-Navigate to your docs directory where your `docs.json` file is located, and run the following command:
-
-```bash
-mint dev
-```
-
-A local preview of your documentation will be available at `http://localhost:3000`.
-
-
-
-
-## Custom ports
-
-By default, Mintlify uses port 3000. You can customize the port Mintlify runs on by using the `--port` flag. For example, to run Mintlify on port 3333, use this command:
-
-```bash
-mint dev --port 3333
-```
-
-If you attempt to run Mintlify on a port that's already in use, it will use the next available port:
-
-```md
-Port 3000 is already in use. Trying 3001 instead.
-```
-
-## Mintlify versions
-
-Please note that each CLI release is associated with a specific version of Mintlify. If your local preview does not align with the production version, please update the CLI:
-
-```bash
-npm mint update
-```
-
-## Validating links
-
-The CLI can assist with validating links in your documentation. To identify any broken links, use the following command:
-
-```bash
-mint broken-links
-```
-
-## Deployment
-
-If the deployment is successful, you should see the following:
-
-
-
-
-
-## Code formatting
-
-We suggest using extensions on your IDE to recognize and format MDX. If you're a VSCode user, consider the [MDX VSCode extension](https://marketplace.visualstudio.com/items?itemName=unifiedjs.vscode-mdx) for syntax highlighting, and [Prettier](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) for code formatting.
-
-## Troubleshooting
-
-
-
-
- This may be due to an outdated version of node. Try the following:
- 1. Remove the currently-installed version of the CLI: `npm remove -g mint`
- 2. Upgrade to Node v19 or higher.
- 3. Reinstall the CLI: `npm i -g mint`
-
-
-
-
- Solution: Go to the root of your device and delete the `~/.mintlify` folder. Then run `mint dev` again.
-
-
-
-Curious about what changed in the latest CLI version? Check out the [CLI changelog](https://www.npmjs.com/package/mintlify?activeTab=versions).
diff --git a/docs.json b/docs.json
index 46b44cc4a..1d9abb636 100644
--- a/docs.json
+++ b/docs.json
@@ -1,122 +1,236 @@
{
"$schema": "https://mintlify.com/docs.json",
- "theme": "mint",
- "name": "Mint Starter Kit",
+ "theme": "linden",
+ "name": "Commenda Platform Documentation",
"colors": {
- "primary": "#16A34A",
- "light": "#07C983",
- "dark": "#15803D"
+ "primary": "#026EB9",
+ "light": "#F8F6F1",
+ "dark": "#F8F6F1"
},
- "favicon": "/favicon.svg",
+ "favicon": "/favicon-32x32.png",
"navigation": {
"tabs": [
{
- "tab": "Guides",
+ "tab": "Engine",
"groups": [
{
- "group": "Getting started",
+ "group": "CommendaOS",
"pages": [
- "index",
- "quickstart",
- "development"
+ "engine/commendaos/overview",
+ {
+ "group": "APIs",
+ "pages": [
+ "engine/commendaos/business-entity",
+ "engine/commendaos/government-identifiers",
+ "engine/commendaos/registrations",
+ "engine/commendaos/locations",
+ "engine/commendaos/credentials",
+ "engine/commendaos/documents"
+ ]
+ }
]
},
{
- "group": "Customization",
+ "group": "Indirect Tax",
"pages": [
- "essentials/settings",
- "essentials/navigation"
+ "engine/indirect-tax/overview"
]
},
{
- "group": "Writing content",
+ "group": "Workflow Builder",
"pages": [
- "essentials/markdown",
- "essentials/code",
- "essentials/images",
- "essentials/reusable-snippets"
+ "engine/workflow-builder/overview",
+ "engine/workflow-builder/quickstart",
+ {
+ "group": "Concepts",
+ "pages": [
+ "engine/workflow-builder/concepts/core-concepts",
+ "engine/workflow-builder/concepts/step-types",
+ "engine/workflow-builder/concepts/json-schemas"
+ ]
+ },
+ {
+ "group": "Guides",
+ "pages": [
+ "engine/workflow-builder/guides/creating-workflows",
+ "engine/workflow-builder/guides/local-development"
+ ]
+ },
+ {
+ "group": "Reference",
+ "pages": [
+ "engine/workflow-builder/reference/dsl-types",
+ "engine/workflow-builder/reference/definition-types",
+ "engine/workflow-builder/reference/runtime-types",
+ "engine/workflow-builder/reference/data-models",
+ "engine/workflow-builder/reference/validation-rules",
+ "engine/workflow-builder/reference/service-request-integration"
+ ]
+ }
]
},
{
- "group": "AI tools",
+ "group": "Form Builder",
"pages": [
- "ai-tools/cursor",
- "ai-tools/claude-code",
- "ai-tools/windsurf"
+ "engine/form-builder/overview"
]
}
]
},
{
- "tab": "API reference",
+ "tab": "Product",
"groups": [
{
- "group": "API documentation",
+ "group": "Indirect Tax",
"pages": [
- "api-reference/introduction"
- ]
- },
- {
- "group": "Endpoint examples",
- "pages": [
- "api-reference/endpoint/get",
- "api-reference/endpoint/create",
- "api-reference/endpoint/delete",
- "api-reference/endpoint/webhook"
+ "product/indirect-tax/guarantees",
+ {
+ "group": "Incident Response SOP",
+ "pages": [
+ "product/indirect-tax/incident-response-sop/overview",
+ "product/indirect-tax/incident-response-sop/scenarios",
+ "product/indirect-tax/incident-response-sop/remediation",
+ "product/indirect-tax/incident-response-sop/templates",
+ "product/indirect-tax/incident-response-sop/assessment"
+ ]
+ },
+ {
+ "group": "Integrations",
+ "pages": [
+ "integrations/supported-integrations",
+ {
+ "group": "Integration Guidelines",
+ "pages": [
+ "integrations/guidelines/overview",
+ {
+ "group": "Integration Checklist",
+ "pages": [
+ "integrations/guidelines/integration-checklist/general-behaviors",
+ "integrations/guidelines/integration-checklist/syncing",
+ "integrations/guidelines/integration-checklist/calculation"
+ ]
+ },
+ {
+ "group": "Existing Integration Behaviors",
+ "pages": [
+ "integrations/guidelines/existing-integration-behaviors/stripe",
+ "integrations/guidelines/existing-integration-behaviors/shopify",
+ "integrations/guidelines/existing-integration-behaviors/xero",
+ "integrations/guidelines/existing-integration-behaviors/netsuite",
+ "integrations/guidelines/existing-integration-behaviors/quickbooks",
+ "integrations/guidelines/existing-integration-behaviors/zoho",
+ "integrations/guidelines/existing-integration-behaviors/woocommerce"
+ ]
+ },
+ "integrations/guidelines/fallback-address-resolver",
+ "integrations/guidelines/sales-tax-address-resolution-hierarchy",
+ "integrations/guidelines/shipping-tax-calculations"
+ ]
+ },
+ {
+ "group": "Stripe",
+ "pages": [
+ "integrations/stripe/overview"
+ ]
+ },
+ {
+ "group": "Shopify",
+ "pages": [
+ "integrations/shopify/overview"
+ ]
+ },
+ {
+ "group": "Xero",
+ "pages": [
+ "integrations/xero/overview"
+ ]
+ },
+ {
+ "group": "Zoho",
+ "pages": [
+ "integrations/zoho/overview"
+ ]
+ },
+ {
+ "group": "WooCommerce",
+ "pages": [
+ "integrations/woocommerce/setup"
+ ]
+ },
+ {
+ "group": "QuickBooks",
+ "pages": [
+ "integrations/quickbooks/overview"
+ ]
+ },
+ {
+ "group": "NetSuite",
+ "pages": [
+ "integrations/netsuite/overview"
+ ]
+ }
+ ]
+ }
]
}
]
+ },
+ {
+ "tab": "Rootfi",
+ "groups": []
}
],
"global": {
"anchors": [
{
- "anchor": "Documentation",
- "href": "https://mintlify.com/docs",
+ "anchor": "Commenda Public Docs",
+ "href": "https://sales-tax-docs.commenda.io/introduction",
+ "icon": "book-open-cover"
+ },
+ {
+ "anchor": "Rootfi Public Docs",
+ "href": "https://rootfi-commenda.mintlify.app/documentation/general/introduction",
"icon": "book-open-cover"
},
{
- "anchor": "Blog",
- "href": "https://mintlify.com/blog",
- "icon": "newspaper"
+ "anchor": "Status",
+ "href": "https://commenda.betteruptime.com/",
+ "icon": "triangle-exclamation"
+ },
+ {
+ "anchor": "Baserow",
+ "href": "https://baserow.io/login",
+ "icon": "table"
}
]
}
},
"logo": {
- "light": "/logo/light.svg",
- "dark": "/logo/dark.svg"
+ "light": "/logo/FullLogoLockupBlack.svg",
+ "dark": "/logo/FullLogoLockupWhite.svg"
},
"navbar": {
- "links": [
- {
- "label": "Support",
- "href": "mailto:hi@mintlify.com"
- }
- ],
"primary": {
"type": "button",
- "label": "Dashboard",
- "href": "https://dashboard.mintlify.com"
+ "label": "Report a bug",
+ "href": "https://linear.app/commenda/team/ONC/new?template=a04ed671-96f2-4df0-882c-62e7ccf8a27c"
}
},
"contextual": {
"options": [
- "copy",
- "view",
- "chatgpt",
- "claude",
- "perplexity",
- "mcp",
- "cursor",
- "vscode"
- ]
+ "copy",
+ "view",
+ "chatgpt",
+ "claude",
+ "perplexity",
+ "mcp",
+ "cursor",
+ "vscode"
+ ]
},
"footer": {
"socials": {
- "x": "https://x.com/mintlify",
- "github": "https://github.com/mintlify",
- "linkedin": "https://linkedin.com/company/mintlify"
+ "github": "https://github.com/commenda-eng"
}
}
}
diff --git a/engine/commendaos/business-entity.mdx b/engine/commendaos/business-entity.mdx
new file mode 100644
index 000000000..abcc2ddc3
--- /dev/null
+++ b/engine/commendaos/business-entity.mdx
@@ -0,0 +1,228 @@
+---
+title: 'Business entity API'
+description: 'Manage business entities and their core information'
+icon: 'building'
+---
+
+## Overview
+
+The Business Entity API provides endpoints for managing legal business entities (corporations, LLCs, partnerships, etc.) and their associated data including locations, persons, government identifiers, registrations, documents, and credentials.
+
+## Core endpoints
+
+### Get business entity
+
+Retrieve a single business entity by ID.
+
+```http
+GET /business-entity/:businessEntityId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Unique identifier for the business entity |
+
+**Query parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `extends` | string[] | Optional fields to include: `governmentIdentifiers`, `locations` |
+
+**Response**
+
+```json
+{
+ "id": 123,
+ "legalName": "Acme Corporation",
+ "dbaName": "Acme",
+ "incorporationCountry": "US",
+ "incorporationJurisdiction": "DE",
+ "entityType": "C_CORP",
+ "formationDate": "2020-01-15",
+ "businessDescription": "Software development",
+ "fiscalYearEnd": "12-31",
+ "accountingBasis": "ACCRUAL",
+ "governmentIdentifiers": [...],
+ "locations": [...]
+}
+```
+
+### Update business entity
+
+Update core business entity information.
+
+```http
+POST /business-entity/:businessEntityId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Unique identifier for the business entity |
+
+**Request body**
+
+```json
+{
+ "legalName": "Acme Corporation Inc.",
+ "dbaName": "Acme",
+ "businessDescription": "Enterprise software development",
+ "fiscalYearEnd": "12-31",
+ "accountingBasis": "ACCRUAL",
+ "taxClassification": "C_CORP"
+}
+```
+
+**Response**
+
+Returns `200 OK` on success.
+
+### List business entities
+
+Get all business entities for a company.
+
+```http
+GET /business-entity/list/company/:companyId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `companyId` | integer | Unique identifier for the company |
+
+**Response**
+
+```json
+{
+ "entities": [
+ {
+ "id": 123,
+ "legalName": "Acme Corporation",
+ "incorporationCountry": "US",
+ "incorporationJurisdiction": "DE"
+ }
+ ]
+}
+```
+
+## Key persons
+
+### Add key person
+
+Associate a person with a business entity.
+
+```http
+POST /business-entity/:businessEntityId/persons/:personId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `personId` | integer | Person ID |
+
+**Request body**
+
+```json
+{
+ "role": "DIRECTOR",
+ "startDate": "2020-01-15",
+ "endDate": null,
+ "ownershipPercentage": 25.5
+}
+```
+
+**Response**
+
+Returns `200 OK` on success.
+
+### Remove key person
+
+Remove a person from a business entity.
+
+```http
+DELETE /business-entity/:businessEntityId/persons/:personId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `personId` | integer | Person ID |
+
+**Response**
+
+Returns `204 No Content` on success.
+
+## Bulk operations
+
+### Bulk assign
+
+Assign multiple business entities to companies.
+
+```http
+POST /business-entity/bulk/assign
+```
+
+**Request body**
+
+```json
+[
+ {
+ "businessEntityId": 123,
+ "companyId": 456
+ },
+ {
+ "businessEntityId": 124,
+ "companyId": 456
+ }
+]
+```
+
+**Response**
+
+```json
+{
+ "success": [
+ {
+ "businessEntityId": 123,
+ "companyId": 456
+ }
+ ],
+ "failed": []
+}
+```
+
+### Unassign business entity
+
+Remove a business entity from a company.
+
+```http
+POST /business-entity/unassign
+```
+
+**Request body**
+
+```json
+{
+ "businessEntityId": 123
+}
+```
+
+**Response**
+
+Returns `200 OK` on success.
+
+## Related resources
+
+- [Locations API](/engine/commendaos/locations) - Manage business entity addresses
+- [Government Identifiers API](/engine/commendaos/government-identifiers) - Manage tax IDs and official numbers
+- [Registrations API](/engine/commendaos/registrations) - Manage government registrations
+- [Documents API](/engine/commendaos/documents) - Manage entity documents
+- [Credentials API](/engine/commendaos/credentials) - Manage portal access credentials
diff --git a/engine/commendaos/credentials.mdx b/engine/commendaos/credentials.mdx
new file mode 100644
index 000000000..07987eccd
--- /dev/null
+++ b/engine/commendaos/credentials.mdx
@@ -0,0 +1,398 @@
+---
+title: 'Credentials API'
+description: 'Manage secure login credentials for government portals and systems'
+icon: 'key'
+---
+
+## Overview
+
+The Credentials API provides secure storage for login credentials to government portals and systems, including tax filing portals, corporate registries, payroll systems, and banking portals. Credentials can be linked to business entities and registrations, and shared with accountants and service providers.
+
+## Core endpoints
+
+### List credentials
+
+Get all credentials accessible to the user.
+
+```http
+GET /credentials
+```
+
+**Query parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Filter by business entity (optional) |
+| `extends` | string[] | Optional fields to include |
+
+**Response**
+
+```json
+{
+ "credentials": [
+ {
+ "id": "cred_abc123",
+ "name": "IRS e-Services",
+ "type": "CORPORATE_TAX_PORTAL",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "url": "https://www.irs.gov/e-services",
+ "blocks": [
+ {
+ "type": "PLAIN_TEXT",
+ "label": "Username",
+ "value": "john.doe@acme.com"
+ },
+ {
+ "type": "SECURE_STRING",
+ "label": "Password",
+ "value": "***"
+ }
+ ],
+ "createdAt": "2020-01-15T10:00:00Z",
+ "updatedAt": "2024-03-20T15:30:00Z"
+ }
+ ],
+ "count": 1
+}
+```
+
+### Get credential
+
+Retrieve a single credential by ID.
+
+```http
+GET /credentials/:credentialId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `credentialId` | string | Credential ID |
+
+**Query parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `includeSecrets` | boolean | Include decrypted secure strings (default: false) |
+| `includeRegistrations` | boolean | Include linked registrations (default: false) |
+
+**Response**
+
+```json
+{
+ "credential": {
+ "id": "cred_abc123",
+ "name": "IRS e-Services",
+ "type": "CORPORATE_TAX_PORTAL",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "url": "https://www.irs.gov/e-services",
+ "blocks": [
+ {
+ "type": "PLAIN_TEXT",
+ "label": "Username",
+ "value": "john.doe@acme.com"
+ },
+ {
+ "type": "SECURE_STRING",
+ "label": "Password",
+ "value": "MySecurePassword123!"
+ }
+ ],
+ "registrations": [
+ {
+ "id": "reg_xyz789",
+ "type": "INCOME_TAX"
+ }
+ ]
+ }
+}
+```
+
+### Create credential
+
+Add a new credential.
+
+```http
+POST /credentials
+```
+
+**Request body**
+
+```json
+{
+ "name": "IRS e-Services",
+ "type": "CORPORATE_TAX_PORTAL",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "url": "https://www.irs.gov/e-services",
+ "blocks": [
+ {
+ "type": "PLAIN_TEXT",
+ "label": "Username",
+ "value": "john.doe@acme.com"
+ },
+ {
+ "type": "SECURE_STRING",
+ "label": "Password",
+ "value": "MySecurePassword123!"
+ },
+ {
+ "type": "PLAIN_TEXT",
+ "label": "Account Number",
+ "value": "12-3456789"
+ }
+ ]
+}
+```
+
+**Response**
+
+```json
+{
+ "credential": {
+ "id": "cred_abc123"
+ }
+}
+```
+
+### Update credential
+
+Update an existing credential.
+
+```http
+POST /credentials/:credentialId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `credentialId` | string | Credential ID |
+
+**Request body**
+
+```json
+{
+ "name": "IRS e-Services (Updated)",
+ "url": "https://www.irs.gov/e-services-new",
+ "blocks": [
+ {
+ "type": "PLAIN_TEXT",
+ "label": "Username",
+ "value": "jane.smith@acme.com"
+ },
+ {
+ "type": "SECURE_STRING",
+ "label": "Password",
+ "value": "NewPassword456!"
+ }
+ ]
+}
+```
+
+**Response**
+
+```json
+{
+ "credential": {
+ "id": "cred_abc123"
+ }
+}
+```
+
+### Delete credential
+
+Remove a credential.
+
+```http
+DELETE /credentials/:credentialId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `credentialId` | string | Credential ID |
+
+**Response**
+
+Returns `204 No Content` on success.
+
+## Supported credentials
+
+### Get supported credential types
+
+Get all credential types available for a country.
+
+```http
+GET /credentials/supportedCredentials
+```
+
+**Query parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `country` | string | ISO 3166-1 alpha-2 country code (optional) |
+
+**Response**
+
+```json
+{
+ "supportedCredentials": [
+ {
+ "type": "CORPORATE_TAX_PORTAL",
+ "displayName": "Corporate Tax Portal",
+ "description": "Federal corporate income tax filing system",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "url": "https://www.irs.gov/e-services",
+ "blocks": [
+ {
+ "type": "PLAIN_TEXT",
+ "label": "Username",
+ "required": true
+ },
+ {
+ "type": "SECURE_STRING",
+ "label": "Password",
+ "required": true
+ }
+ ]
+ }
+ ],
+ "count": 1
+}
+```
+
+## Credential types
+
+### Corporate tax portals
+
+Federal/national income tax filing systems:
+- **US**: IRS e-Services, state tax portals
+- **UK**: HMRC online services
+- **India**: Income Tax e-Filing portal
+- **Canada**: CRA My Business Account
+- **Singapore**: myTax Portal
+
+### Indirect tax portals
+
+VAT/GST/sales tax filing systems:
+- **US**: State sales tax portals
+- **UK**: HMRC VAT online
+- **India**: GST portal
+- **Singapore**: myTax GST
+- **UAE**: Federal Tax Authority portal
+
+### Payroll tax portals
+
+Withholding and unemployment insurance systems:
+- **US**: State withholding portals, SUTA portals
+- **UK**: HMRC PAYE online
+- **India**: ESIC, EPFO portals
+- **Singapore**: CPF portal
+
+### Company secretarial portals
+
+Business registry filing systems:
+- **US**: State Secretary of State portals
+- **UK**: Companies House WebFiling
+- **India**: MCA portal
+- **Singapore**: BizFile+
+
+### Social security portals
+
+Employee benefit systems:
+- **US**: Social Security Business Services Online
+- **India**: ESIC, EPFO
+- **Singapore**: CPF Board
+
+### Banking portals
+
+Financial institution access:
+- Bank online banking
+- Payment processing portals
+- Treasury management systems
+
+## Credential blocks
+
+Credentials consist of flexible blocks that can store different types of information:
+
+### Plain text blocks
+
+Store non-sensitive information:
+- Usernames
+- Account numbers
+- Email addresses
+- User IDs
+- Reference numbers
+
+```json
+{
+ "type": "PLAIN_TEXT",
+ "label": "Username",
+ "value": "john.doe@acme.com"
+}
+```
+
+### Secure string blocks
+
+Store sensitive information (encrypted at rest):
+- Passwords
+- PINs
+- Access tokens
+- API keys
+- Security answers
+
+```json
+{
+ "type": "SECURE_STRING",
+ "label": "Password",
+ "value": "MySecurePassword123!"
+}
+```
+
+### Custom blocks
+
+Add jurisdiction-specific fields as needed. The block structure is flexible to accommodate any credential format.
+
+## Linking credentials
+
+### Link to business entity
+
+Associate a credential with a business entity:
+
+```http
+POST /business-entity/:businessEntityId/credentials/:credentialId
+```
+
+This makes the credential accessible when viewing the business entity.
+
+### Link to registration
+
+Associate a credential with a specific registration:
+
+```http
+POST /business-entity/:businessEntityId/registrations/:registrationId/credential/:credentialId
+```
+
+This links the credential to a specific government registration, enabling automated filing workflows.
+
+## Security
+
+- **Encryption**: Secure string blocks are encrypted at rest using industry-standard encryption
+- **Access control**: Credentials are only accessible to authorized users
+- **Audit logging**: All credential access and modifications are logged
+- **Sharing**: Credentials can be shared with accountants and service providers
+
+## Sharing with accountants
+
+Credentials can be shared with external accountants and service providers who need portal access for filing and compliance work. The sharing mechanism ensures proper authorization and audit trails.
+
+## Related resources
+
+- [Business Entity API](/engine/commendaos/business-entity) - Link credentials to entities
+- [Registrations API](/engine/commendaos/registrations) - Link credentials to registrations
diff --git a/engine/commendaos/documents.mdx b/engine/commendaos/documents.mdx
new file mode 100644
index 000000000..96dbdc4b3
--- /dev/null
+++ b/engine/commendaos/documents.mdx
@@ -0,0 +1,299 @@
+---
+title: 'Documents API'
+description: 'Manage business entity documents and files'
+icon: 'file-text'
+---
+
+## Overview
+
+The Documents API manages business entity documents organized by category, including formation documents, tax certificates, compliance filings, financial records, and contracts. Documents support time-sensitive periods, version control, and service request associations.
+
+## Core endpoints
+
+### List documents
+
+Get all documents for a business entity.
+
+```http
+GET /business-entity/:businessEntityId/documents
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Unique identifier for the business entity |
+
+**Response**
+
+```json
+{
+ "documents": [
+ {
+ "id": 123,
+ "documentType": "FORMATION_DOCUMENT",
+ "documentSubType": "CertificateOfIncorporation",
+ "documentName": "Certificate of Incorporation",
+ "fileId": "file_abc123",
+ "fileName": "Certificate_of_Incorporation.pdf",
+ "effectiveStartDate": "2020-01-15",
+ "effectiveEndDate": null,
+ "serviceRequestId": null,
+ "createdAt": "2020-01-15T10:00:00Z"
+ }
+ ],
+ "count": 1
+}
+```
+
+### Create document
+
+Add a new document to a business entity.
+
+```http
+POST /business-entity/:businessEntityId/documents
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+
+**Request body**
+
+```json
+{
+ "documentType": "FORMATION_DOCUMENT",
+ "documentSubType": "CertificateOfIncorporation",
+ "fileId": "file_abc123",
+ "effectiveStartDate": "2020-01-15",
+ "serviceRequestId": 456
+}
+```
+
+**Response**
+
+```json
+{
+ "document": {
+ "id": 123,
+ "documentType": "FORMATION_DOCUMENT",
+ "documentSubType": "CertificateOfIncorporation",
+ "fileId": "file_abc123"
+ }
+}
+```
+
+### Update document
+
+Update an existing document.
+
+```http
+POST /business-entity/:businessEntityId/documents/:documentId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `documentId` | integer | Document ID |
+
+**Request body**
+
+```json
+{
+ "effectiveStartDate": "2020-01-15",
+ "effectiveEndDate": "2025-12-31",
+ "serviceRequestId": 456
+}
+```
+
+**Response**
+
+Returns `200 OK` on success.
+
+## Supported documents
+
+### Get supported document types
+
+Get all document types available for a business entity.
+
+```http
+GET /business-entity/:businessEntityId/documents/supported
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+
+**Response**
+
+```json
+{
+ "supportedDocumentTypes": [
+ {
+ "documentName": "Certificate of Incorporation",
+ "documentType": "FORMATION_DOCUMENT",
+ "documentSubType": "CertificateOfIncorporation",
+ "country": "US",
+ "jurisdiction": null,
+ "corporationType": "C_CORP",
+ "isTimeSensitive": false,
+ "isUnique": true,
+ "canBeAddedByAddDocument": true
+ }
+ ]
+}
+```
+
+## Document categories
+
+### Formation documents
+
+Company formation and incorporation documents:
+- **Certificate of Incorporation**: Official incorporation certificate
+- **Articles of Incorporation**: Corporate charter
+- **Bylaws**: Corporate governance rules
+- **Operating Agreement**: LLC governance document
+- **Memorandum of Association**: Company constitution
+- **Articles of Association**: Shareholder rights and obligations
+
+### Tax and compliance documents
+
+Tax registration and compliance certificates:
+- **EIN Letter**: IRS Employer Identification Number confirmation
+- **Tax Registration Certificate**: State/national tax registration
+- **VAT Certificate**: VAT/GST registration certificate
+- **PAYE Certificate**: Payroll tax registration
+- **PF Registration**: Provident fund registration
+- **ESIC Registration**: Employee insurance registration
+
+### Financial records
+
+Financial statements and accounting documents:
+- **Balance Sheet**: Statement of financial position
+- **Income Statement**: Profit and loss statement
+- **Cash Flow Statement**: Cash flow analysis
+- **Bank Statements**: Monthly bank account statements
+- **Card Statements**: Credit card statements
+- **Audit Reports**: Annual audit documents
+
+### Shareholder documents
+
+Shareholder and equity-related documents:
+- **Share Certificates**: Stock ownership certificates
+- **Share Purchase Agreement**: Equity transfer agreements
+- **Board Resolutions**: Board meeting minutes
+- **Shareholder Resolutions**: Shareholder meeting minutes
+- **Stock Option Plans**: Employee equity plans
+
+### Contracts and agreements
+
+Business contracts and legal agreements:
+- **Lease Agreement**: Office rental contracts
+- **Service Agreements**: Vendor contracts
+- **Employment Agreements**: Employee contracts
+- **Partnership Agreements**: Business partnership documents
+
+### Miscellaneous
+
+Other business documents:
+- **Utility Bills**: Proof of address documents
+- **Office Photos**: Physical location verification
+- **Director Identification**: Director ID documents
+- **Company Profile**: Business information summaries
+
+## Document properties
+
+### Time-sensitive documents
+
+Some documents have effective date ranges:
+- `effectiveStartDate`: When the document becomes valid
+- `effectiveEndDate`: When the document expires (optional)
+
+Examples: Tax returns (fiscal year), financial statements (period), audit reports (year)
+
+### Unique documents
+
+Some document types can only exist once per entity:
+- `isUnique: true`: Only one instance allowed (e.g., Certificate of Incorporation)
+- `isUnique: false`: Multiple versions allowed (e.g., Board Resolutions)
+
+### Service request association
+
+Documents can be linked to service requests:
+- `serviceRequestId`: Associates document with a specific service request
+- Enables tracking of documents generated through compliance workflows
+
+## Jurisdiction-specific documents
+
+Document types vary by country and entity type:
+
+### United States (C-Corp, LLC)
+- Certificate of Incorporation
+- EIN Confirmation Letter
+- State tax registration certificates
+- Annual reports
+- Franchise tax filings
+
+### India (Pvt Ltd, LLP)
+- Certificate of Incorporation
+- PAN Card
+- GST Certificate
+- TAN Document
+- Annual audit reports
+
+### United Kingdom (Ltd)
+- Certificate of Incorporation
+- Memorandum of Association
+- VAT Certificate
+- PAYE Reference Letter
+- HMRC UTR Letter
+
+### Singapore (Pte Ltd, LLP)
+- Certificate of Incorporation
+- GST Certificate
+- CPF Activation Letter
+- Articles of Association
+
+### Canada (Corporation)
+- Certificate of Incorporation
+- CRA Business Number Confirmation
+- Articles of Incorporation
+- Initial Return
+
+### UAE (Free Zone Company)
+- Trade License Certificate
+- TRN Letter
+- Employer Establishment Card
+
+### Australia (Pty Ltd)
+- Certificate of Incorporation
+- Company Constitution
+- Director's Consent
+
+### Germany (GmbH)
+- Notarial Deed of Incorporation
+- Commercial Register Extract
+- Shareholder List
+
+### France (SAS)
+- Extrait Kbis
+- Articles of Association (Statuts)
+- Shareholders' Agreement
+
+## File management
+
+Documents reference files stored in the Files API:
+1. Upload file using Files API to get `fileId`
+2. Create document record with `fileId` reference
+3. Document metadata stored separately from file content
+
+## Related resources
+
+- [Business Entity API](/engine/commendaos/business-entity) - Manage parent business entities
+- [Registrations API](/engine/commendaos/registrations) - Documents linked to registrations
diff --git a/engine/commendaos/government-identifiers.mdx b/engine/commendaos/government-identifiers.mdx
new file mode 100644
index 000000000..2fdbb8f03
--- /dev/null
+++ b/engine/commendaos/government-identifiers.mdx
@@ -0,0 +1,254 @@
+---
+title: 'Government identifiers API'
+description: 'Manage official government identification numbers for business entities'
+icon: 'id-card'
+---
+
+## Overview
+
+The Government Identifiers API manages official identification numbers issued by government authorities, such as EINs, VAT numbers, tax IDs, and company registration numbers across 50+ countries.
+
+## Core endpoints
+
+### List government identifiers
+
+Get all government identifiers for a business entity.
+
+```http
+GET /business-entity/:businessEntityId/government-identifiers
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Unique identifier for the business entity |
+
+**Query parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `extend` | string[] | Optional fields to include: `supportingDocument` |
+
+**Response**
+
+```json
+{
+ "governmentIdentifiers": [
+ {
+ "id": "gi_abc123",
+ "type": "EIN",
+ "value": "12-3456789",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "issuedDate": "2020-01-15",
+ "expiryDate": null,
+ "status": "ACTIVE",
+ "supportingDocument": {
+ "fileId": "file_xyz789",
+ "fileName": "EIN_Letter.pdf"
+ }
+ }
+ ],
+ "count": 1
+}
+```
+
+### Get government identifier
+
+Retrieve a single government identifier by ID.
+
+```http
+GET /business-entity/:businessEntityId/government-identifiers/:governmentIdentifierId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `governmentIdentifierId` | string | Government identifier ID |
+
+**Response**
+
+```json
+{
+ "id": "gi_abc123",
+ "type": "EIN",
+ "value": "12-3456789",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "issuedDate": "2020-01-15",
+ "expiryDate": null,
+ "status": "ACTIVE",
+ "purpose": "TAXATION",
+ "supportingDocument": {
+ "fileId": "file_xyz789",
+ "fileName": "EIN_Letter.pdf"
+ }
+}
+```
+
+### Create government identifier
+
+Add a new government identifier to a business entity.
+
+```http
+POST /business-entity/:businessEntityId/government-identifiers
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+
+**Request body**
+
+```json
+{
+ "type": "EIN",
+ "value": "12-3456789",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "issuedDate": "2020-01-15",
+ "status": "ACTIVE",
+ "supportingDocument": {
+ "fileId": "file_xyz789",
+ "description": "EIN confirmation letter from IRS"
+ }
+}
+```
+
+**Response**
+
+```json
+{
+ "governmentIdentifier": {
+ "id": "gi_abc123"
+ }
+}
+```
+
+### Update government identifier
+
+Update an existing government identifier.
+
+```http
+POST /business-entity/:businessEntityId/government-identifiers/:governmentIdentifier
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `governmentIdentifier` | string | Government identifier ID |
+
+**Request body**
+
+```json
+{
+ "value": "12-3456789",
+ "issuedDate": "2020-01-15",
+ "expiryDate": "2025-01-15",
+ "status": "ACTIVE",
+ "supportingDocument": {
+ "fileId": "file_xyz789",
+ "description": "Updated EIN letter"
+ }
+}
+```
+
+**Response**
+
+Returns `200 OK` on success.
+
+## Supported identifier types
+
+### United States
+
+| Type | Description | Format | Jurisdiction |
+|------|-------------|--------|--------------|
+| `EIN` | Employer Identification Number | `XX-XXXXXXX` | Federal |
+| `STATE_ENTITY_NUMBER` | State entity registration number | Varies by state | State-level |
+
+### India
+
+| Type | Description | Format |
+|------|-------------|--------|
+| `PAN` | Permanent Account Number | `[A-Z]{5}[0-9]{4}[A-Z]` |
+| `TAN` | Tax Deduction Account Number | `[A-Z]{4}[0-9]{5}[A-Z]` |
+| `GSTIN` | Goods and Services Tax ID | `[0-9]{2}[A-Z]{5}[0-9]{4}[A-Z][0-9][Z][0-9A-Z]` |
+| `CIN` | Corporate Identity Number | `[LU][0-9]{5}[A-Z]{2}[0-9]{4}[A-Z]{3}[0-9]{6}` |
+| `LLPIN` | Limited Liability Partnership ID | `[A-Z]{3}-[0-9]{4}` |
+
+### United Kingdom
+
+| Type | Description | Format |
+|------|-------------|--------|
+| `COMPANY_REGISTRATION_NUMBER` | Companies House number | `[A-Z0-9]{8}` |
+| `UTR` | Unique Taxpayer Reference | `[0-9]{10}` |
+| `VAT_NUMBER` | VAT registration number | `GB[0-9]{9}` |
+| `PAYE_NUMBER` | Pay As You Earn reference | `[0-9]{3}/[A-Z0-9]+` |
+
+### Canada
+
+| Type | Description | Format |
+|------|-------------|--------|
+| `BUSINESS_NUMBER` | CRA Business Number | `[0-9]{9}` |
+| `CORPORATION_NUMBER` | Federal corporation number | `[0-9]{7}` |
+| `COMPANY_KEY` | Provincial company key | Varies by province |
+
+### Singapore
+
+| Type | Description | Format |
+|------|-------------|--------|
+| `UEN` | Unique Entity Number | `[0-9]{9}[A-Z]` or `[0-9]{10}[A-Z]` |
+| `GST_NUMBER` | GST registration number | `M[0-9]{8}[A-Z]` |
+| `CPF_SUBMISSION_NUMBER` | CPF submission number | `[0-9]{8}[A-Z]` |
+
+### United Arab Emirates
+
+| Type | Description |
+|------|-------------|
+| `LICENSE_NUMBER` | Trade license number |
+| `TRN` | Tax Registration Number |
+
+### Australia
+
+| Type | Description | Format |
+|------|-------------|--------|
+| `ACN` | Australian Company Number | `[0-9]{9}` |
+| `ABN` | Australian Business Number | `[0-9]{11}` |
+| `TFN` | Tax File Number | `[0-9]{9}` |
+| `GST_NUMBER` | GST registration number | `[0-9]{11}` |
+
+### Germany
+
+| Type | Description | Format |
+|------|-------------|--------|
+| `HRB_NUMBER` | Commercial register number | `HRB [0-9]+` |
+| `STEUERNUMMER` | Tax number | Varies by state |
+| `VAT_NUMBER` | VAT identification number | `DE[0-9]{9}` |
+
+### France
+
+| Type | Description | Format |
+|------|-------------|--------|
+| `SIREN` | Business identification number | `[0-9]{9}` |
+| `CORPORATE_TAX_NUMBER` | Corporate tax number | `[0-9]{13}` |
+| `TVA_NUMBER` | VAT number | `FR[0-9A-Z]{2}[0-9]{9}` |
+
+## Validation rules
+
+Government identifiers are validated using jurisdiction-specific regex patterns. Invalid formats will return a `400 Bad Request` error.
+
+## Supporting documents
+
+Each government identifier can have an associated supporting document (e.g., EIN letter, tax registration certificate). Upload the file first using the Files API, then reference the `fileId` when creating or updating the identifier.
+
+## Related resources
+
+- [Business Entity API](/engine/commendaos/business-entity) - Manage parent business entities
+- [Registrations API](/engine/commendaos/registrations) - Link identifiers to registrations
diff --git a/engine/commendaos/locations.mdx b/engine/commendaos/locations.mdx
new file mode 100644
index 000000000..583475178
--- /dev/null
+++ b/engine/commendaos/locations.mdx
@@ -0,0 +1,248 @@
+---
+title: 'Locations API'
+description: 'Manage physical addresses and locations for business entities'
+icon: 'map-pin'
+---
+
+## Overview
+
+The Locations API manages physical addresses where business entities operate, including registered offices, operating addresses, warehouses, branches, and points of sale. Locations are used for nexus determination, compliance tracking, and employee management.
+
+## Core endpoints
+
+### List locations
+
+Get all locations for a business entity.
+
+```http
+GET /business-entity/:businessEntityId/locations
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Unique identifier for the business entity |
+
+**Response**
+
+```json
+{
+ "locations": [
+ {
+ "id": "loc_abc123",
+ "addressLine1": "123 Main Street",
+ "addressLine2": "Suite 100",
+ "city": "San Francisco",
+ "state": "CA",
+ "postalCode": "94105",
+ "country": "US",
+ "locationType": ["REGISTERED_OFFICE", "OPERATING"],
+ "startDate": "2020-01-15",
+ "endDate": null,
+ "employeeCount": 25,
+ "source": "COMMENDA",
+ "sourceId": null
+ }
+ ],
+ "count": 1
+}
+```
+
+### Get location
+
+Retrieve a single location by ID.
+
+```http
+GET /business-entity/:businessEntityId/locations/:locationId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `locationId` | string | Location ID |
+
+**Response**
+
+```json
+{
+ "id": "loc_abc123",
+ "addressLine1": "123 Main Street",
+ "addressLine2": "Suite 100",
+ "city": "San Francisco",
+ "state": "CA",
+ "postalCode": "94105",
+ "country": "US",
+ "locationType": ["REGISTERED_OFFICE", "OPERATING"],
+ "startDate": "2020-01-15",
+ "endDate": null,
+ "employeeCount": 25,
+ "source": "COMMENDA",
+ "sourceId": null
+}
+```
+
+### Create location
+
+Add a new location to a business entity.
+
+```http
+POST /business-entity/:businessEntityId/locations
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+
+**Request body**
+
+```json
+{
+ "addressLine1": "123 Main Street",
+ "addressLine2": "Suite 100",
+ "city": "San Francisco",
+ "state": "CA",
+ "postalCode": "94105",
+ "country": "US",
+ "locationType": ["OPERATING"],
+ "startDate": "2020-01-15",
+ "employeeCount": 25
+}
+```
+
+**Response**
+
+```json
+{
+ "location": {
+ "id": "loc_abc123"
+ }
+}
+```
+
+### Update location
+
+Update an existing location.
+
+```http
+POST /business-entity/:businessEntityId/locations/:locationId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `locationId` | string | Location ID |
+
+**Request body**
+
+```json
+{
+ "addressLine1": "456 Market Street",
+ "addressLine2": "Floor 5",
+ "city": "San Francisco",
+ "state": "CA",
+ "postalCode": "94103",
+ "employeeCount": 30,
+ "endDate": "2025-12-31"
+}
+```
+
+**Response**
+
+Returns `200 OK` on success.
+
+### Delete location
+
+Remove a location from a business entity.
+
+```http
+DELETE /business-entity/:businessEntityId/locations/:locationId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `locationId` | string | Location ID |
+
+**Response**
+
+Returns `204 No Content` on success.
+
+## Location types
+
+A single location can have multiple types:
+
+| Type | Description | Use case |
+|------|-------------|----------|
+| `REGISTERED_OFFICE` | Official legal address on file with authorities | Required for corporate filings |
+| `OPERATING` | Primary business operations location | Main office or headquarters |
+| `MAILING` | Correspondence address | Where mail is received |
+| `HEADQUARTERS` | Main administrative office | Corporate HQ |
+| `POINT_OF_SALE` | Retail or customer-facing location | Stores, showrooms |
+| `WAREHOUSE` | Inventory storage facility | Distribution centers |
+| `BRANCH` | Secondary office location | Regional offices |
+| `EMPLOYEE_WORK_LOCATION` | Where staff are based | Remote offices, coworking spaces |
+
+## Address fields
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `addressLine1` | string | Yes | Street address |
+| `addressLine2` | string | No | Apartment, suite, unit, building, floor |
+| `city` | string | Yes | City or locality |
+| `state` | string | Conditional | State/province (required for US, Canada, India, Australia) |
+| `postalCode` | string | Yes | ZIP/postal code |
+| `country` | string | Yes | ISO 3166-1 alpha-2 country code |
+
+## Employee tracking
+
+Track employee count at each location for:
+- Payroll tax nexus determination
+- Workers' compensation requirements
+- Local tax obligations
+- Headcount reporting
+
+Update `employeeCount` as staff levels change.
+
+## Nexus determination
+
+Use `startDate` to track when physical presence began in a jurisdiction. This is critical for:
+- Sales tax nexus
+- Income tax nexus
+- Payroll tax obligations
+- Registration requirements
+
+## Location sources
+
+Locations can be created from multiple sources:
+
+| Source | Description |
+|--------|-------------|
+| `COMMENDA` | Manually entered in CommendaOS |
+| `GUSTO` | Synced from Gusto payroll |
+| `RIPPLING` | Synced from Rippling HRIS |
+| `JUSTWORKS` | Synced from Justworks |
+| `DEEL` | Synced from Deel |
+
+External locations include a `sourceId` for reference back to the originating system.
+
+## Time periods
+
+Track location validity with `startDate` and `endDate`:
+- `startDate`: When the location became active (required)
+- `endDate`: When the location was closed (optional, null for active locations)
+
+This enables historical tracking of where entities operated over time.
+
+## Related resources
+
+- [Business Entity API](/engine/commendaos/business-entity) - Manage parent business entities
+- [Registrations API](/engine/commendaos/registrations) - Registrations triggered by location nexus
diff --git a/engine/commendaos/overview.mdx b/engine/commendaos/overview.mdx
new file mode 100644
index 000000000..e094c873b
--- /dev/null
+++ b/engine/commendaos/overview.mdx
@@ -0,0 +1,173 @@
+---
+title: 'CommendaOS'
+description: 'Global entity data modeling system for business entities'
+icon: 'microchip'
+---
+
+## Overview
+
+CommendaOS is Commenda's comprehensive data modeling system for managing business entity information across jurisdictions worldwide. It provides a unified API for modeling, storing, and retrieving entity data including government identifiers, registrations, locations, credentials, and documents.
+
+## Core concepts
+
+### Business entity
+
+The central model representing a legal business entity (corporation, LLC, partnership, etc.) operating in any jurisdiction. Business entities contain:
+
+- **General information**: Legal name, DBA name, business description, formation date
+- **Jurisdiction details**: Incorporation country, jurisdiction, entity type
+- **Addresses**: Registered office, operating, and mailing addresses
+- **Tax information**: Fiscal year, accounting basis, tax classification
+
+### Government identifiers
+
+Official identification numbers issued by government authorities for business entities. Examples include:
+
+- **US**: EIN (Employer Identification Number), state entity numbers
+- **India**: PAN, TAN, GSTIN, CIN/LLPIN
+- **UK**: Company Registration Number, UTR, VAT Number, PAYE Number
+- **Canada**: Business Number, Corporation Number, Company Key
+- **Singapore**: UEN, GST Number, CPF Submission Number
+- **UAE**: License Number, TRN
+- **Australia**: ACN, ABN, TFN, GST Number
+- **Germany**: HRB Number, Steuernummer, VAT Number
+- **France**: SIREN, Corporate Tax Number, TVA Number
+
+Each identifier includes:
+- Display name and description
+- Validation rules (regex patterns)
+- Supporting document requirements
+- Purpose (formation, taxation, payroll, etc.)
+- Function criticality level
+
+### Registrations
+
+Formal registrations with government agencies that enable business operations. Common registration types:
+
+- **Formation**: Company registration with corporate registry
+- **Income tax**: Federal/national tax identification
+- **Indirect tax**: VAT/GST/sales tax registration
+- **Payroll**: Employer withholding and unemployment insurance
+- **Social security**: Employee benefit programs
+- **Trade**: Import/export licenses
+- **Corporate registry**: Access credentials for filing systems
+
+Registrations can be:
+- **Domestic**: For entities formed in the jurisdiction
+- **Foreign**: For entities qualified to do business from another jurisdiction
+- **Expirable**: Some registrations require renewal
+
+### Locations
+
+Physical addresses where business entities operate, categorized by type:
+
+- **Registered office address**: Official legal address on file with authorities
+- **Operating address**: Primary business operations location
+- **Mailing address**: Correspondence address
+- **Headquarters**: Main administrative office
+- **Point of sale**: Retail or customer-facing locations
+- **Warehouse**: Inventory storage facilities
+- **Branch**: Secondary office locations
+- **Employee work location**: Where staff are based
+
+Locations support:
+- Employee count tracking
+- Start date for nexus determination
+- Multiple location types per address
+- Integration with external data sources
+
+### Credentials
+
+Secure storage for login credentials to government portals and systems. Credential types include:
+
+- **Corporate tax portals**: IRS e-Services, state franchise tax systems
+- **Indirect tax portals**: VAT/GST/sales tax filing systems
+- **Payroll tax portals**: Withholding and unemployment insurance systems
+- **Company secretarial portals**: Secretary of State business registries
+- **Social security portals**: Employee benefit systems
+- **Banking portals**: Financial institution access
+
+Credentials consist of:
+- **Plain text blocks**: Usernames, account numbers, identifiers
+- **Secure string blocks**: Passwords, PINs, access tokens (encrypted)
+- **Custom blocks**: Jurisdiction-specific fields
+
+Credentials can be:
+- Linked to registrations
+- Shared across business entities
+- Shared with accountants and service providers
+
+### Documents
+
+Business entity documents organized by category:
+
+- **Formation documents**: Articles of incorporation, bylaws, operating agreements
+- **Tax documents**: EIN letters, tax registration certificates
+- **Compliance documents**: Annual reports, franchise tax filings
+- **Financial documents**: Bank statements, financial statements
+- **Personnel documents**: Director identification, employment records
+
+Documents support:
+- Time-sensitive periods (effective start/end dates)
+- Version control
+- Unique constraints (one per entity)
+- Service request associations
+
+## Key features
+
+### Multi-jurisdiction support
+
+CommendaOS models entities across 50+ countries with jurisdiction-specific rules for:
+- Required government identifiers
+- Mandatory registrations
+- Document requirements
+- Credential portal access
+- Compliance obligations
+
+### Intelligent validation
+
+Built-in validation rules ensure data quality:
+- Regex patterns for identifier formats
+- Uniqueness constraints for critical identifiers
+- Date validation for time-sensitive data
+- Cross-entity relationship validation
+
+### Audit logging
+
+Comprehensive audit trails track all changes to:
+- Business entity core data
+- Government identifiers
+- Registrations
+- Locations
+- Credentials
+- Documents
+
+### API-first design
+
+RESTful API endpoints for all operations:
+- Create, read, update, delete operations
+- Bulk operations for efficiency
+- Relationship management
+- Credential sharing and access control
+
+## Use cases
+
+CommendaOS enables:
+
+1. **Entity formation**: Track incorporation process and obtain required identifiers
+2. **Tax compliance**: Manage tax registrations and filing credentials across jurisdictions
+3. **Payroll operations**: Store employer registrations and portal access
+4. **Multi-entity management**: Handle parent-subsidiary relationships and corporate groups
+5. **Accountant collaboration**: Share credentials and documents with service providers
+6. **Nexus tracking**: Monitor physical presence through location data
+7. **Compliance automation**: Link registrations to filing obligations
+8. **Document management**: Organize entity documents by type and time period
+
+## Architecture
+
+CommendaOS is built on:
+- **Database**: PostgreSQL with Prisma ORM
+- **Backend**: NestJS TypeScript services
+- **Security**: Encrypted credential storage in MongoDB
+- **Validation**: DTO-based request validation with class-validator
+- **Audit**: Comprehensive change tracking system
diff --git a/engine/commendaos/registrations.mdx b/engine/commendaos/registrations.mdx
new file mode 100644
index 000000000..5951723fd
--- /dev/null
+++ b/engine/commendaos/registrations.mdx
@@ -0,0 +1,327 @@
+---
+title: 'Registrations API'
+description: 'Manage government registrations for business entities'
+icon: 'file-check'
+---
+
+## Overview
+
+The Registrations API manages formal registrations with government agencies that enable business operations, including tax registrations, payroll accounts, corporate registry access, and trade licenses.
+
+## Core endpoints
+
+### List registrations
+
+Get all registrations for a business entity.
+
+```http
+GET /business-entity/:businessEntityId/registrations
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Unique identifier for the business entity |
+
+**Query parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `extends` | string[] | Optional fields to include: `credentials` |
+
+**Response**
+
+```json
+{
+ "registrations": [
+ {
+ "id": "reg_abc123",
+ "type": "INCOME_TAX",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "registrationDate": "2020-01-15",
+ "status": "ACTIVE",
+ "isDomestic": true,
+ "expiryDate": null,
+ "governmentIdentifierId": "gi_xyz789",
+ "credentials": [...]
+ }
+ ],
+ "count": 1
+}
+```
+
+### Get registration
+
+Retrieve a single registration by ID.
+
+```http
+GET /business-entity/:businessEntityId/registrations/:registrationId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `registrationId` | string | Registration ID |
+
+**Query parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `extends` | string[] | Optional fields to include: `credentials` |
+
+**Response**
+
+```json
+{
+ "registration": {
+ "id": "reg_abc123",
+ "type": "INCOME_TAX",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "registrationDate": "2020-01-15",
+ "status": "ACTIVE",
+ "isDomestic": true,
+ "expiryDate": null,
+ "governmentIdentifierId": "gi_xyz789",
+ "credentials": [
+ {
+ "id": "cred_123",
+ "name": "IRS e-Services"
+ }
+ ]
+ }
+}
+```
+
+### Create registration
+
+Add a new registration to a business entity.
+
+```http
+POST /business-entity/:businessEntityId/registrations
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+
+**Request body**
+
+```json
+{
+ "type": "INCOME_TAX",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "registrationDate": "2020-01-15",
+ "status": "ACTIVE",
+ "isDomestic": true,
+ "governmentIdentifierId": "gi_xyz789"
+}
+```
+
+**Response**
+
+```json
+{
+ "registration": {
+ "id": "reg_abc123"
+ }
+}
+```
+
+### Update registration
+
+Update an existing registration.
+
+```http
+POST /business-entity/:businessEntityId/registrations/:registrationId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `registrationId` | string | Registration ID |
+
+**Request body**
+
+```json
+{
+ "status": "INACTIVE",
+ "expiryDate": "2025-12-31",
+ "registrationDate": "2020-01-15"
+}
+```
+
+**Response**
+
+Returns `200 OK` on success.
+
+### Delete registration
+
+Remove a registration from a business entity.
+
+```http
+DELETE /business-entity/:businessEntityId/registrations/:registrationId
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+| `registrationId` | string | Registration ID |
+
+**Response**
+
+Returns `204 No Content` on success.
+
+## Supported registrations
+
+### Get supported registrations
+
+Get all registration types available for a business entity or country.
+
+```http
+GET /business-entity/registrations/supportedRegistrations
+```
+
+**Query parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Filter by business entity (optional) |
+| `country` | string | Filter by country code (optional) |
+
+**Response**
+
+```json
+{
+ "supportedRegistrations": [
+ {
+ "type": "INCOME_TAX",
+ "displayName": "Federal Income Tax",
+ "description": "IRS federal income tax registration",
+ "country": "US",
+ "jurisdiction": "FEDERAL",
+ "requiredIdentifiers": ["EIN"],
+ "isExpirable": false,
+ "purpose": "TAXATION"
+ }
+ ],
+ "count": 1
+}
+```
+
+### Get supported registrations for entity
+
+Get registration types available for a specific business entity.
+
+```http
+GET /business-entity/:businessEntityId/registrations/supportedRegistrations
+```
+
+**Path parameters**
+
+| Parameter | Type | Description |
+|-----------|------|-------------|
+| `businessEntityId` | integer | Business entity ID |
+
+**Response**
+
+Same format as above, filtered by the entity's incorporation country and jurisdiction.
+
+## Registration types
+
+### Formation
+
+Company registration with corporate registry:
+- **US**: Secretary of State registration
+- **UK**: Companies House registration
+- **India**: ROC (Registrar of Companies) registration
+- **Singapore**: ACRA registration
+
+### Income tax
+
+Federal/national tax identification:
+- **US**: IRS federal income tax
+- **UK**: HMRC Corporation Tax
+- **India**: Income Tax Department
+- **Canada**: CRA corporate income tax
+
+### Indirect tax
+
+VAT/GST/sales tax registration:
+- **US**: State sales tax permits
+- **UK**: VAT registration
+- **India**: GST registration
+- **Singapore**: GST registration
+- **UAE**: VAT registration
+
+### Payroll
+
+Employer withholding and unemployment insurance:
+- **US**: State withholding tax, unemployment insurance
+- **UK**: PAYE registration
+- **India**: Professional Tax, ESI, EPF
+- **Singapore**: CPF registration
+
+### Social security
+
+Employee benefit programs:
+- **US**: Social Security Administration
+- **India**: ESIC, EPFO
+- **Singapore**: CPF Board
+
+### Trade
+
+Import/export licenses:
+- **US**: Customs and Border Protection
+- **India**: Import Export Code (IEC)
+- **UAE**: Trade license
+
+### Corporate registry
+
+Access credentials for filing systems:
+- **US**: State business portals
+- **UK**: Companies House WebFiling
+- **India**: MCA portal
+- **Singapore**: BizFile+
+
+## Registration status
+
+| Status | Description |
+|--------|-------------|
+| `ACTIVE` | Registration is current and valid |
+| `INACTIVE` | Registration has been deactivated |
+| `PENDING` | Registration application in progress |
+| `EXPIRED` | Registration has expired (for expirable types) |
+| `SUSPENDED` | Registration temporarily suspended by authority |
+
+## Domestic vs foreign registrations
+
+- **Domestic**: For entities formed in the jurisdiction (e.g., Delaware corporation registering in Delaware)
+- **Foreign**: For entities qualified to do business from another jurisdiction (e.g., Delaware corporation registering in California)
+
+## Linking credentials
+
+Associate portal access credentials with registrations:
+
+```http
+POST /business-entity/:businessEntityId/registrations/:registrationId/credential/:credentialId
+```
+
+This links a credential to a specific registration, enabling automated filing and compliance workflows.
+
+## Related resources
+
+- [Business Entity API](/engine/commendaos/business-entity) - Manage parent business entities
+- [Government Identifiers API](/engine/commendaos/government-identifiers) - Required identifiers for registrations
+- [Credentials API](/engine/commendaos/credentials) - Portal access for registrations
diff --git a/engine/form-builder/overview.mdx b/engine/form-builder/overview.mdx
new file mode 100644
index 000000000..3fb5fd37b
--- /dev/null
+++ b/engine/form-builder/overview.mdx
@@ -0,0 +1,10 @@
+---
+title: 'Form Builder'
+description: 'Create and manage custom forms'
+icon: 'file-lines'
+---
+
+## Overview
+
+Form Builder documentation coming soon.
+
diff --git a/engine/indirect-tax/overview.mdx b/engine/indirect-tax/overview.mdx
new file mode 100644
index 000000000..930dcf3a7
--- /dev/null
+++ b/engine/indirect-tax/overview.mdx
@@ -0,0 +1,10 @@
+---
+title: 'Indirect Tax'
+description: 'Overview of Indirect Tax'
+icon: 'receipt'
+---
+
+## Overview
+
+Indirect Tax documentation coming soon.
+
diff --git a/engine/workflow-builder/concepts/core-concepts.mdx b/engine/workflow-builder/concepts/core-concepts.mdx
new file mode 100644
index 000000000..239559a19
--- /dev/null
+++ b/engine/workflow-builder/concepts/core-concepts.mdx
@@ -0,0 +1,172 @@
+---
+title: 'Core concepts'
+description: 'Understand the fundamental building blocks of Workflow Builder'
+icon: 'book'
+---
+
+This guide explains the core concepts you need to understand when working with Workflow Builder.
+
+## Workflow templates
+
+A workflow template is a reusable definition of a business process. Templates contain:
+
+- **Name and description** - Human-readable identifiers
+- **Steps** - Individual units of work
+- **Transitions** - Connections between steps
+- **Step groups** - Logical groupings for UI organization
+
+Templates support multiple versions, allowing you to iterate on designs while maintaining stable production workflows.
+
+## Workflow versions
+
+Each template can have multiple versions with different statuses:
+
+| Status | Description |
+|--------|-------------|
+| **DRAFT** | In development, can be edited |
+| **PUBLISHED** | Ready to be activated, cannot be edited |
+| **DEPRECATED** | No longer recommended for use |
+
+Only one version can be **active** at a time. When a workflow is triggered, the active version is used.
+
+## Workflow executions
+
+An execution is a running instance of a workflow template version. Each execution tracks:
+
+- **Runtime status** - Current state (NOT_STARTED, IN_PROGRESS, COMPLETED, FAILED, CANCELLED)
+- **Step states** - Status of each step in the execution
+- **Context** - Data passed into and generated by the workflow
+- **Timestamps** - When the execution started, completed, or failed
+
+## Workflow links
+
+Links determine when workflows are triggered automatically:
+
+- **SERVICE_CATALOG** - Triggered when a specific service request type is created
+- **PRODUCT** - Triggered when a specific product is purchased
+
+## Expressions and evaluation
+
+Workflow Builder uses [JSONata](https://jsonata.org/) expressions for dynamic values and conditions.
+
+### Evaluation scope
+
+All expressions are evaluated against an environment with these properties:
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `__context__` | Access the global workflow context | `__context__.customerId` |
+| `__steps__` | Access any step's output | `__steps__.stepId.name` |
+| `__datasources__` | Access fetched datasource outputs | `__datasources__.dsId.data` |
+| `__each__` | Access current item in iterations | `__each__.id` |
+
+### Example expression
+
+```jsonata
+__context__.customer.type = 'premium' and __steps__.verification.approved = true
+```
+
+## Value providers
+
+Value providers define how to produce a value in mappings and configurations:
+
+### Constant value
+
+A hardcoded value:
+
+```json
+{
+ "type": "const",
+ "value": "Hello World"
+}
+```
+
+### Field reference
+
+Access a value from context, step output, datasource, or iteration:
+
+```json
+{
+ "type": "field",
+ "ref": {
+ "source": "CONTEXT",
+ "path": "customer.email"
+ }
+}
+```
+
+### Expression
+
+Compute a value using JSONata:
+
+```json
+{
+ "type": "expr",
+ "expr": {
+ "type": "jsonata",
+ "src": "__context__.firstName & ' ' & __context__.lastName"
+ }
+}
+```
+
+## Mappings
+
+Mappings define how to transform and assign values:
+
+```json
+{
+ "id": "map-customer-name",
+ "targetPath": "customerName",
+ "value": {
+ "type": "expr",
+ "expr": { "src": "__context__.customer.fullName" }
+ },
+ "mode": "set"
+}
+```
+
+| Property | Description |
+|----------|-------------|
+| `targetPath` | Dot-notation path for the destination |
+| `value` | Value provider defining the source |
+| `mode` | `set` (replace) or `append` (for arrays) |
+
+## Datasource calls
+
+Fetch external data during workflow execution:
+
+```json
+{
+ "id": "fetch-customer",
+ "alias": "customer",
+ "type": "COMMENDA_LOGICAL_BACKEND",
+ "dataSourceID": "ds-customer-api",
+ "params": {
+ "customerId": {
+ "type": "field",
+ "ref": { "source": "CONTEXT", "path": "customerId" }
+ }
+ },
+ "select": { "type": "jsonata", "src": "$.data" },
+ "scope": "per-step"
+}
+```
+
+| Property | Description |
+|----------|-------------|
+| `dataSourceID` | Reference to the datasource definition |
+| `params` | Parameters to pass to the datasource |
+| `select` | Transform the response (optional) |
+| `scope` | `per-step` or `per-item` for batch workflows |
+
+## Next steps
+
+
+
+ Learn about all available step types
+
+
+ Understand data validation with schemas
+
+
+
diff --git a/engine/workflow-builder/concepts/json-schemas.mdx b/engine/workflow-builder/concepts/json-schemas.mdx
new file mode 100644
index 000000000..a2b7f129d
--- /dev/null
+++ b/engine/workflow-builder/concepts/json-schemas.mdx
@@ -0,0 +1,242 @@
+---
+title: 'JSON schemas'
+description: 'Define and validate data structures using JSON Schema'
+icon: 'brackets-curly'
+---
+
+JSON Schema is used in Workflow Builder to define the expected structure of step outputs and validate data throughout workflow execution.
+
+## What is JSON?
+
+JSON (JavaScript Object Notation) is a structured way to represent information that computers can easily understand.
+
+**Human language:** "A person has a name Ravi and age 26."
+
+**JSON version:**
+
+```json
+{
+ "name": "Ravi",
+ "age": 26
+}
+```
+
+## Data types
+
+### Objects
+
+Containers for multiple fields using `{ }` with key-value pairs:
+
+```json
+{
+ "name": "Ravi",
+ "age": 26
+}
+```
+
+
+Keys must be wrapped in double quotes. This is invalid:
+```json
+{ name: "Ravi" }
+```
+
+
+### Numbers
+
+Numeric values without quotes:
+
+```json
+{
+ "age": 26,
+ "price": 99.99
+}
+```
+
+### Strings
+
+Text values wrapped in double quotes:
+
+```json
+{
+ "name": "Ravi",
+ "city": "Mumbai"
+}
+```
+
+### Booleans
+
+Simple true/false values:
+
+```json
+{
+ "isActive": true,
+ "isVerified": false
+}
+```
+
+### Arrays
+
+Lists of values using `[ ]`:
+
+```json
+{
+ "fruits": ["apple", "banana", "orange"],
+ "numbers": [1, 2, 3]
+}
+```
+
+### Null
+
+Empty or undefined values:
+
+```json
+{
+ "middleName": null
+}
+```
+
+## What is JSON Schema?
+
+A JSON Schema defines the rules and structure that data must follow. Think of it as a blueprint that tells the system:
+
+- What fields are expected
+- What type each field should be
+- Which fields are required
+
+### Example schema
+
+```json
+{
+ "type": "object",
+ "properties": {
+ "name": { "type": "string" },
+ "age": { "type": "number" },
+ "gender": {
+ "type": "string",
+ "enum": ["male", "female", "other"]
+ }
+ },
+ "required": ["name"]
+}
+```
+
+This schema says:
+- Expect an object with `name`, `age`, and `gender` fields
+- `name` must be a string and is required
+- `age` must be a number
+- `gender` must be one of the allowed values
+
+## Key schema properties
+
+| Property | Description |
+|----------|-------------|
+| `type` | The data type (object, array, string, number, boolean) |
+| `properties` | Field definitions for objects |
+| `required` | Array of required field names |
+| `enum` | Allowed values for a field |
+| `items` | Schema for array elements |
+
+## Using schemas in workflows
+
+### Output schemas
+
+Define the expected output structure for steps:
+
+```json
+{
+ "type": "SYS_SUB_WORKFLOW",
+ "name": "Verify Customer",
+ "outputSchema": {
+ "type": "object",
+ "properties": {
+ "verified": { "type": "boolean" },
+ "verificationId": { "type": "string" }
+ },
+ "required": ["verified"]
+ }
+}
+```
+
+### Validation
+
+Output schemas are used for:
+
+- **Validation** - Ensure step outputs match expected structure
+- **Tooling** - Help the editor infer available data fields
+- **Documentation** - Self-documenting workflow definitions
+
+## JSON Schema builder
+
+For non-developers, Workflow Builder includes a visual JSON Schema Builder that lets you create schemas without writing code:
+
+1. Add a field
+2. Choose its type (text, number, boolean, date)
+3. Mark if it's required
+4. Set allowed values (for enums)
+
+The builder converts your choices into proper JSON Schema automatically.
+
+## Common patterns
+
+### Nested objects
+
+```json
+{
+ "type": "object",
+ "properties": {
+ "customer": {
+ "type": "object",
+ "properties": {
+ "name": { "type": "string" },
+ "email": { "type": "string" }
+ }
+ }
+ }
+}
+```
+
+### Arrays of objects
+
+```json
+{
+ "type": "object",
+ "properties": {
+ "items": {
+ "type": "array",
+ "items": {
+ "type": "object",
+ "properties": {
+ "id": { "type": "string" },
+ "quantity": { "type": "number" }
+ }
+ }
+ }
+ }
+}
+```
+
+### Optional fields with defaults
+
+```json
+{
+ "type": "object",
+ "properties": {
+ "status": {
+ "type": "string",
+ "default": "pending"
+ }
+ }
+}
+```
+
+## Next steps
+
+
+
+ Learn about the workflow DSL type system
+
+
+ Understand workflow validation
+
+
+
diff --git a/engine/workflow-builder/concepts/step-types.mdx b/engine/workflow-builder/concepts/step-types.mdx
new file mode 100644
index 000000000..5286d6dc8
--- /dev/null
+++ b/engine/workflow-builder/concepts/step-types.mdx
@@ -0,0 +1,216 @@
+---
+title: 'Step types'
+description: 'Learn about the different types of steps available in Workflow Builder'
+icon: 'shapes'
+---
+
+Workflow Builder provides several step types to handle different aspects of your business processes.
+
+## Control flow steps
+
+### START
+
+The entry point of every workflow. Each workflow must have exactly one START step.
+
+- No incoming transitions allowed
+- Exactly one outgoing transition required
+
+```
+┌─────────┐
+│ START │───▶ (next step)
+└─────────┘
+```
+
+### END
+
+The terminal point of every workflow. When execution reaches this step, the workflow is complete.
+
+- Exactly one incoming transition required
+- No outgoing transitions allowed
+
+```
+(previous step) ───▶ ┌─────────┐
+ │ END │
+ └─────────┘
+```
+
+## Human steps
+
+### HUMAN_CONFIRM
+
+A step that waits for human confirmation before the workflow can continue. The assigned person must explicitly mark the step as completed.
+
+**Use cases:**
+- Waiting for an agent to complete a manual task
+- Requiring approval before proceeding
+- Confirming external actions are done
+
+```
+┌─────────────────┐
+│ HUMAN_CONFIRM │
+│ │
+│ "Verify docs" │
+└─────────────────┘
+```
+
+
+Additional human step types like `HUMAN_FORM`, `HUMAN_URL_REDIRECT`, and `HUMAN_DOC_UPLOAD` are planned but not yet implemented.
+
+
+## System steps
+
+### SYS_SUB_WORKFLOW
+
+Triggers another workflow (child workflow) from within the current workflow. Supports two modes:
+
+#### Single mode
+
+Execute one child workflow:
+
+```json
+{
+ "type": "SYS_SUB_WORKFLOW",
+ "mode": "SINGLE",
+ "childWorkflowTemplateVersionId": "version-123",
+ "inputMapping": [...]
+}
+```
+
+#### Batch mode
+
+Execute multiple child workflows by iterating over a collection:
+
+```json
+{
+ "type": "SYS_SUB_WORKFLOW",
+ "mode": "BATCH",
+ "childWorkflowTemplateVersionId": "version-123",
+ "iterable": {
+ "type": "EXPRESSION",
+ "expr": { "src": "__context__.directors" }
+ },
+ "inputMapping": [...]
+}
+```
+
+**Use case:** Trigger multiple DSC workflows from an India Private Incorporation workflow, one for each director.
+
+## Gateway steps
+
+Gateways control the flow of execution through branching and merging.
+
+### GATEWAY_PARALLEL_SPLIT
+
+Branches the workflow into multiple paths that execute simultaneously.
+
+```
+ ┌───▶ Path A ───┐
+ │ │
+───▶ [PARALLEL] ────┼───▶ Path B ───┼───▶
+ [ SPLIT ] │ │
+ └───▶ Path C ───┘
+```
+
+- All outgoing paths start at the same time
+- Must be paired with a GATEWAY_PARALLEL_JOIN
+
+### GATEWAY_PARALLEL_JOIN
+
+Waits for all incoming parallel branches to complete before proceeding.
+
+```
+ Path A ───┐
+ │
+ Path B ───┼───▶ [PARALLEL] ───▶
+ │ [ JOIN ]
+ Path C ───┘
+```
+
+- Requires at least 2 incoming transitions
+- Exactly 1 outgoing transition
+
+### GATEWAY_EXCLUSIVE_SPLIT
+
+A yes/no decision point where exactly one path is taken based on a condition.
+
+```
+ ┌───▶ Yes path (condition = true)
+ │
+───▶ [EXCLUSIVE] ───┤
+ [ SPLIT ] │
+ └───▶ No path (default)
+```
+
+**Requirements:**
+- Exactly 2 outgoing transitions
+- One transition must have a condition
+- One transition must be marked as default
+
+**Example condition:**
+
+```jsonata
+__context__.customer.verified = true
+```
+
+### GATEWAY_INCLUSIVE_SPLIT
+
+A flexible decision point where multiple paths can be taken based on conditions.
+
+```
+ ┌───▶ Path A (if condition A)
+ │
+───▶ [INCLUSIVE] ───┼───▶ Path B (if condition B)
+ [ SPLIT ] │
+ └───▶ Default path
+```
+
+**Use case:** Send different notifications based on user attributes:
+- If user is new → send onboarding email
+- If user is premium → send perks notification
+- If both conditions are true → do both
+
+## Step configuration
+
+All steps share these base properties:
+
+| Property | Description |
+|----------|-------------|
+| `id` | Unique identifier within the workflow |
+| `type` | The step type |
+| `name` | Human-readable label |
+| `outputSchema` | JSON Schema for step output validation |
+| `group` | Grouping metadata (groupId, order) |
+| `activationPolicy` | Default runtime activation state |
+| `ui.reactFlow.position` | Visual editor coordinates (x, y) |
+
+## Step groups
+
+Steps can be organized into logical groups for UI presentation:
+
+```json
+{
+ "stepGroups": [
+ {
+ "id": "group-verification",
+ "name": "Verification",
+ "stepIds": ["step-1", "step-2", "step-3"]
+ }
+ ]
+}
+```
+
+
+START, END, and gateway steps cannot be added to groups. Only human and system steps can be grouped.
+
+
+## Next steps
+
+
+
+ Step-by-step workflow creation guide
+
+
+ Technical reference for step definitions
+
+
+
diff --git a/engine/workflow-builder/guides/creating-workflows.mdx b/engine/workflow-builder/guides/creating-workflows.mdx
new file mode 100644
index 000000000..5150aa34d
--- /dev/null
+++ b/engine/workflow-builder/guides/creating-workflows.mdx
@@ -0,0 +1,291 @@
+---
+title: 'Creating workflows'
+description: 'Detailed guide for building workflows with Workflow Builder'
+icon: 'hammer'
+---
+
+This guide provides detailed instructions for creating effective workflows using the Workflow Builder.
+
+## Planning your workflow
+
+Before building, consider:
+
+1. **What process are you automating?** - Map out the business process
+2. **What are the steps involved?** - Identify each action or decision point
+3. **Who needs to act?** - Determine human vs. automated steps
+4. **What conditions exist?** - Identify branching logic
+5. **What data flows through?** - Plan data requirements
+
+## Accessing workflow management
+
+1. Navigate to the **Admin Portal**
+2. Click **Workflow Management** in the left sidebar
+3. You'll see all existing workflows listed
+
+## Creating a template
+
+1. Click **Create Workflow** (top right)
+2. Enter workflow details:
+ - **Name** - Descriptive identifier
+ - **Description** - Purpose and scope
+3. Click **Create**
+
+## Version management
+
+### Creating a version
+
+1. Open a workflow from the list
+2. Click **Add Version**
+3. Configure:
+ - **Version number** - Use semantic versioning (e.g., "1.0.0")
+ - **Starter version** - Optionally copy from existing version
+4. Click **Create** to open the editor
+
+### Version lifecycle
+
+```
+DRAFT → PUBLISHED → ACTIVE
+ │ │
+ └── (edit allowed) └── (in production)
+```
+
+## Using the workflow editor
+
+### Interface overview
+
+| Panel | Location | Purpose |
+|-------|----------|---------|
+| Steps Panel | Left | Available step types |
+| Canvas | Center | Visual workflow design |
+| Configuration | Right | Step settings |
+
+### Adding steps
+
+1. **Drag** a step type from the Steps Panel
+2. **Drop** it onto the Canvas
+3. **Click** the step to configure
+
+### Connecting steps
+
+1. Hover over a step to reveal handles
+2. **Drag** from the source handle
+3. **Drop** on the target step's input handle
+4. A transition line appears
+
+### Configuring steps
+
+When you select a step, the Configuration Panel shows:
+
+- **Basic info** - Name, ID, description
+- **Step-specific settings** - Varies by type
+- **Output schema** - Expected output structure
+- **Group assignment** - UI organization
+
+## Building step flows
+
+### Linear flow
+
+The simplest pattern - steps execute one after another:
+
+```
+START → Task 1 → Task 2 → Task 3 → END
+```
+
+### Conditional branching
+
+Use exclusive split for yes/no decisions:
+
+```
+START → Check Status → [EXCLUSIVE SPLIT]
+ │
+ ┌─────────┴─────────┐
+ ▼ ▼
+ (approved) (rejected)
+ │ │
+ Process Notify
+ │ │
+ └─────────┬─────────┘
+ ▼
+ END
+```
+
+**Configuration:**
+1. Add `GATEWAY_EXCLUSIVE_SPLIT`
+2. Create two outgoing transitions
+3. Set condition on one: `__context__.status = 'approved'`
+4. Mark the other as default
+
+### Parallel execution
+
+Run multiple paths simultaneously:
+
+```
+START → [PARALLEL SPLIT]
+ │
+ ┌─────────┼─────────┐
+ ▼ ▼ ▼
+ Task A Task B Task C
+ │ │ │
+ └─────────┼─────────┘
+ ▼
+ [PARALLEL JOIN] → END
+```
+
+**Configuration:**
+1. Add `GATEWAY_PARALLEL_SPLIT`
+2. Connect to all parallel tasks
+3. Connect all tasks to `GATEWAY_PARALLEL_JOIN`
+4. Connect join to next step
+
+### Sub-workflows
+
+Execute child workflows for modular design:
+
+#### Single sub-workflow
+
+```json
+{
+ "type": "SYS_SUB_WORKFLOW",
+ "mode": "SINGLE",
+ "childWorkflowTemplateVersionId": "child-version-id",
+ "inputMapping": [
+ {
+ "targetPath": "customerId",
+ "value": {
+ "type": "field",
+ "ref": { "source": "CONTEXT", "path": "customer.id" }
+ }
+ }
+ ]
+}
+```
+
+#### Batch sub-workflows
+
+For iterating over a collection:
+
+```json
+{
+ "type": "SYS_SUB_WORKFLOW",
+ "mode": "BATCH",
+ "childWorkflowTemplateVersionId": "child-version-id",
+ "iterable": {
+ "type": "EXPRESSION",
+ "expr": { "src": "__context__.directors" }
+ },
+ "inputMapping": [
+ {
+ "targetPath": "directorId",
+ "value": {
+ "type": "expr",
+ "expr": { "src": "__each__.id" }
+ }
+ }
+ ]
+}
+```
+
+## Working with data
+
+### Accessing context data
+
+Use `__context__` to access workflow context:
+
+```jsonata
+__context__.customer.email
+```
+
+### Accessing step outputs
+
+Use `__steps__` to access previous step results:
+
+```jsonata
+__steps__.verificationStep.approved
+```
+
+### Accessing datasources
+
+Use `__datasources__` after fetching data:
+
+```jsonata
+__datasources__.customerData.profile.name
+```
+
+### In batch iterations
+
+Use `__each__` to access the current item:
+
+```jsonata
+__each__.id
+```
+
+## Saving and publishing
+
+
+**No autosave!** Save frequently using the **Save** button.
+
+
+### Save workflow
+
+Click **Save** (top right) to preserve your work.
+
+### Publish version
+
+1. Review your workflow design
+2. Click **Publish**
+3. Status changes to **Published**
+
+### Activate version
+
+1. Return to the versions list
+2. Click **Activate Version** on your published version
+3. This version is now used for new executions
+
+## Setting up triggers
+
+### Service request triggers
+
+1. Go to **Workflow Links** tab
+2. Click **Add Link**
+3. Select:
+ - **Link Type**: Service Request Type
+ - **Identifier**: The service request type
+4. Save
+
+### Product triggers
+
+1. Go to **Workflow Links** tab
+2. Click **Add Link**
+3. Select:
+ - **Link Type**: Product ID
+ - **Identifier**: The product ID from billing
+4. Save
+
+## Best practices
+
+
+
+ Begin with a basic flow and add complexity incrementally.
+
+
+ Organize related steps into logical groups for clarity.
+
+
+ Use descriptive names for steps and transitions.
+
+
+ Test each version before publishing to production.
+
+
+
+## Next steps
+
+
+
+ Set up local development environment
+
+
+ Understand workflow validation
+
+
+
diff --git a/engine/workflow-builder/guides/local-development.mdx b/engine/workflow-builder/guides/local-development.mdx
new file mode 100644
index 000000000..6e2bf67c9
--- /dev/null
+++ b/engine/workflow-builder/guides/local-development.mdx
@@ -0,0 +1,177 @@
+---
+title: 'Local development'
+description: 'Set up your local environment for Workflow Builder development'
+icon: 'laptop-code'
+---
+
+This guide explains how to set up and run the Workflow Builder project locally for development.
+
+## Prerequisites
+
+- Node.js installed
+- Homebrew (for macOS)
+- Access to the commenda-temporal-dsl repository
+
+## Step 1: Install Temporal CLI
+
+Install the Temporal CLI using Homebrew:
+
+```bash
+brew install temporal
+```
+
+## Step 2: Clone the repository
+
+```bash
+git clone https://github.com/commenda-eng/commenda-temporal-dsl
+cd commenda-temporal-dsl
+```
+
+## Step 3: Configure environment variables
+
+Create a `.env` file in the project root with the following variables:
+
+```bash
+# API Keys for service communication
+COMMENDA_TEMPORAL_BACKEND_API_KEY=your-temporal-backend-api-key
+COMMENDA_LOGICAL_BACKEND_API_KEY=your-logical-backend-api-key
+COMMENDA_LOGICAL_BACKEND_API_URL=http://localhost:8000/api/v1
+
+# Temporal configuration
+TEMPORAL_NAMESPACE=default
+TEMPORAL_WORKER_ROLE=DSL_ENGINE
+TEMPORAL_TASK_QUEUE=dsl-engine
+TEMPORAL_WORKER_BUILD_ID=1
+
+# Required only for staging/production
+# TEMPORAL_API_KEY=xxxx
+# TEMPORAL_ADDRESS=xxxx
+
+# AWS configuration (same as Commenda Logical Backend)
+AWS_ACCESS_KEY_ID=your-aws-access-key
+AWS_SECRET_ACCESS_KEY=your-aws-secret-key
+AWS_REGION=ap-south-1
+
+# Server configuration
+PORT=8001
+NODE_ENV=development
+```
+
+## Step 4: Configure logical backend
+
+In the Commenda Logical Backend, add these environment variables:
+
+```bash
+COMMENDA_TEMPORAL_BACKEND_API_KEY=your-temporal-backend-api-key
+COMMENDA_TEMPORAL_BACKEND_URL=http://localhost:8001
+TEMPORAL_BACKEND_CLIENT_KEY=your-logical-backend-api-key
+```
+
+
+**API Key matching is critical:**
+- `COMMENDA_LOGICAL_BACKEND_API_KEY` (temporal) must match `COMMENDA_TEMPORAL_BACKEND_API_KEY` (logical)
+- `TEMPORAL_BACKEND_CLIENT_KEY` (logical) must match `COMMENDA_LOGICAL_BACKEND_API_KEY` (temporal)
+
+
+## Step 5: Start the services
+
+Start the services in this order:
+
+### 1. Start Temporal server
+
+```bash
+npm run temporal:dev
+```
+
+This starts the Temporal server at `http://localhost:8233`. A `temporal.db` file is created in the root directory to store executions.
+
+### 2. Start the Node.js server
+
+```bash
+npm run start:dev
+```
+
+This starts the backend server on port 8001.
+
+### 3. Start the Temporal worker
+
+```bash
+npm run temporal:worker
+```
+
+This starts the worker that executes your workflow code.
+
+## Service architecture
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ Local Development │
+│ │
+│ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │
+│ │ Temporal │ │ Node.js │ │ Temporal │ │
+│ │ Server │◀──▶│ Server │◀──▶│ Worker │ │
+│ │ :8233 │ │ :8001 │ │ │ │
+│ └──────────────┘ └──────────────┘ └───────────┘ │
+│ │ │ │
+│ │ ▼ │
+│ │ ┌──────────────┐ │
+│ │ │ Logical │ │
+│ │ │ Backend │ │
+│ │ │ :8000 │ │
+│ │ └──────────────┘ │
+│ ▼ │
+│ ┌──────────────┐ │
+│ │ temporal.db │ │
+│ └──────────────┘ │
+└─────────────────────────────────────────────────────────┘
+```
+
+## Temporal UI
+
+Access the Temporal UI at `http://localhost:8233` to:
+
+- View workflow executions
+- Inspect workflow history
+- Debug execution issues
+- Monitor worker activity
+
+## Updating environment variables
+
+
+When modifying environment variables:
+1. Update them locally in `.env`
+2. Add to GitHub secrets
+3. Update `deploy-app.yaml` for deployments
+
+
+## Troubleshooting
+
+### Temporal server won't start
+
+- Check if port 8233 is available
+- Verify Temporal CLI installation: `temporal --version`
+- Check for existing `temporal.db` corruption (delete and restart)
+
+### Worker not connecting
+
+- Ensure Temporal server is running first
+- Verify `TEMPORAL_TASK_QUEUE` matches across services
+- Check network connectivity between services
+
+### API key errors
+
+- Double-check key matching between services
+- Ensure no whitespace in key values
+- Verify keys are properly exported in environment
+
+## Next steps
+
+
+
+ Understand the database schema
+
+
+ Learn the workflow DSL type system
+
+
+
diff --git a/engine/workflow-builder/overview.mdx b/engine/workflow-builder/overview.mdx
new file mode 100644
index 000000000..d39f85a36
--- /dev/null
+++ b/engine/workflow-builder/overview.mdx
@@ -0,0 +1,89 @@
+---
+title: 'Workflow Builder'
+description: 'Build automated workflows to orchestrate complex business processes and streamline operations'
+icon: 'diagram-project'
+---
+
+The Workflow Builder is a powerful visual tool for creating and managing automated workflows that orchestrate your business processes. It enables you to define complex multi-step processes, handle conditional logic, and integrate with external systems.
+
+## What is Workflow Builder?
+
+Workflow Builder allows you to:
+
+- **Design visual workflows** using a drag-and-drop canvas interface
+- **Define step types** including human tasks, system operations, and decision gateways
+- **Create conditional logic** with exclusive and inclusive branching
+- **Orchestrate sub-workflows** for modular, reusable process design
+- **Manage versions** with draft, published, and active states
+
+## Key concepts
+
+
+
+ Individual units of work in a workflow, including start/end points, human tasks, system tasks, and gateways.
+
+
+ Connections between steps that define the flow of execution, optionally with conditions.
+
+
+ Reusable workflow definitions that can be versioned and activated.
+
+
+ Running instances of workflow templates that track progress and state.
+
+
+
+## Workflow architecture
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│ Workflow Template │
+│ ┌─────────┐ ┌──────────┐ ┌─────────┐ ┌─────────┐ │
+│ │ START │───▶│ Task 1 │───▶│ Gateway │───▶│ END │ │
+│ └─────────┘ └──────────┘ └────┬────┘ └─────────┘ │
+│ │ │
+│ ▼ │
+│ ┌──────────┐ │
+│ │ Task 2 │ │
+│ └──────────┘ │
+└─────────────────────────────────────────────────────────────┘
+```
+
+## Step types
+
+| Type | Description |
+|------|-------------|
+| **START** | Entry point of the workflow (exactly one required) |
+| **END** | Terminal point of the workflow (exactly one required) |
+| **HUMAN_CONFIRM** | Waits for human confirmation before continuing |
+| **SYS_SUB_WORKFLOW** | Triggers child workflows (single or batch mode) |
+| **GATEWAY_PARALLEL_SPLIT** | Branches into multiple parallel paths |
+| **GATEWAY_PARALLEL_JOIN** | Waits for all parallel branches to complete |
+| **GATEWAY_EXCLUSIVE_SPLIT** | Yes/no decision point (one path taken) |
+| **GATEWAY_INCLUSIVE_SPLIT** | Multiple paths based on conditions |
+
+## Workflow lifecycle
+
+1. **Create template** - Define a new workflow template with name and description
+2. **Add version** - Create a version in draft status
+3. **Design workflow** - Use the visual editor to add steps and transitions
+4. **Publish version** - Mark the version ready for activation
+5. **Activate version** - Set as the active version for new executions
+6. **Link triggers** - Connect to service request types or products
+
+## Next steps
+
+
+
+ Create your first workflow in minutes
+
+
+ Deep dive into workflow concepts
+
+
+ Learn about available step types
+
+
+ Technical reference for workflow DSL
+
+
diff --git a/engine/workflow-builder/quickstart.mdx b/engine/workflow-builder/quickstart.mdx
new file mode 100644
index 000000000..32dba2ea9
--- /dev/null
+++ b/engine/workflow-builder/quickstart.mdx
@@ -0,0 +1,118 @@
+---
+title: 'Quickstart'
+description: 'Create your first workflow in the Workflow Builder'
+icon: 'rocket'
+---
+
+This guide walks you through creating, publishing, and activating your first workflow.
+
+## Prerequisites
+
+- Access to the Admin Portal
+- Appropriate permissions for workflow management
+
+## Step 1: Access workflow management
+
+1. Go to the **Admin Portal**
+2. In the left sidebar, scroll to the bottom and click **Workflow Management**
+3. You'll see a page listing all existing workflows
+4. At the top right, you'll find two tabs:
+ - **Workflow Links** - Configure triggers
+ - **Create Workflow** - Create new templates
+
+## Step 2: Create a workflow template
+
+1. Click **Create Workflow**
+2. In the modal that appears, enter:
+ - **Workflow name** - A descriptive name for your workflow
+ - Other optional fields as needed
+3. Click **Create** to add the new workflow
+4. The new workflow appears in the workflows table
+
+## Step 3: Create a version
+
+1. Click any row in the workflow list to open the **Workflow Detail Page**
+2. Click **Add Version** (top right)
+3. In the modal, enter:
+ - **Version number** - Semantic version (e.g., "1.0.0")
+ - **Starter version** (optional) - Copy from an existing version
+4. Click **Create** to generate the new version
+5. The system opens the **Workflow Editor**
+
+## Step 4: Design your workflow
+
+Inside the editor, you'll see:
+
+- **Steps Panel** (left) - All available step types
+- **Canvas** (center) - Drag and drop steps here
+- **Configuration Panel** (right) - Appears when you click any step
+
+### Add steps
+
+1. Drag a step type from the Steps Panel onto the Canvas
+2. Click the step to configure it in the Configuration Panel
+3. Connect steps by dragging from output handles to input handles
+
+### Configure transitions
+
+1. Click on a transition line to select it
+2. For conditional gateways, set the condition expression
+3. Mark one transition as the default for exclusive/inclusive splits
+
+
+There is no autosave. Save your progress frequently using the **Save** button (top right).
+
+
+## Step 5: Publish your version
+
+1. Review your workflow design
+2. Click **Publish** (top right)
+3. The version status changes from **Draft** to **Published**
+
+
+Newly created versions start in **Draft** status. Publishing makes the version eligible to be activated.
+
+
+## Step 6: Activate the version
+
+1. Return to the workflow's versions list
+2. Find the published version
+3. Click **Activate Version**
+4. This version is now used whenever this workflow is triggered
+
+## Step 7: Create workflow links
+
+Workflow links determine how and when a workflow is triggered.
+
+### Access workflow links
+
+1. Go to the main workflow page
+2. Click the **Workflow Links** tab
+3. View, edit, or delete existing links
+
+### Create a new link
+
+1. Click **Add Link**
+2. In the modal, select:
+ - **Workflow Template** - Choose from all templates
+ - **Link Type**:
+ - **Service Request Type** - Trigger on specific service requests
+ - **Product ID** - Trigger when a product is purchased
+ - **Identifier** - The specific service request type or product ID
+3. Click **Save**
+
+
+When a matching service request is created or a product with the specified ID is purchased, the system automatically generates and starts the workflow.
+
+
+## Next steps
+
+
+
+ Learn about workflow fundamentals
+
+
+ Explore all available step types
+
+
+
diff --git a/engine/workflow-builder/reference/data-models.mdx b/engine/workflow-builder/reference/data-models.mdx
new file mode 100644
index 000000000..5e228d586
--- /dev/null
+++ b/engine/workflow-builder/reference/data-models.mdx
@@ -0,0 +1,281 @@
+---
+title: 'Data models'
+description: 'Database schema reference for Workflow Builder'
+icon: 'database'
+---
+
+This reference documents the database models used by Workflow Builder in the Commenda Logical Backend.
+
+## WorkflowTemplate
+
+Stores workflow template definitions:
+
+```prisma
+model WorkflowTemplate {
+ id String @id @default(cuid())
+ name String
+ description String?
+
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+
+ ActiveVersion WorkflowTemplateVersion? @relation(
+ fields: [activeVersionId],
+ references: [id],
+ name: "active_workflow_template_version"
+ )
+ activeVersionId String? @unique
+
+ Versions WorkflowTemplateVersion[] @relation("workflow_template_has_version")
+ WorkflowTemplateLinks WorkflowTemplateLink[]
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `id` | Unique identifier |
+| `name` | Template name |
+| `description` | Optional description |
+| `activeVersionId` | Currently active version |
+| `Versions` | All versions of this template |
+| `WorkflowTemplateLinks` | Trigger configurations |
+
+## WorkflowTemplateVersion
+
+Stores versions of workflow templates:
+
+```prisma
+enum WorkflowTemplateVersionStatus {
+ DRAFT
+ PUBLISHED
+ DEPRECATED
+}
+
+model WorkflowTemplateVersion {
+ id String @id @default(cuid())
+
+ WorkflowTemplate WorkflowTemplate @relation(
+ fields: [workflowTemplateId],
+ references: [id],
+ onDelete: Cascade,
+ name: "workflow_template_has_version"
+ )
+ workflowTemplateId String
+
+ version String
+ versionNote String?
+ definition Json
+
+ createdAt DateTime @default(now())
+ updatedAt DateTime @updatedAt
+
+ status WorkflowTemplateVersionStatus @default(DRAFT)
+
+ ActiveWorkflowTemplate WorkflowTemplate? @relation(
+ name: "active_workflow_template_version"
+ )
+
+ WorkflowExecutions WorkflowExecution[]
+
+ @@unique([workflowTemplateId, version])
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `id` | Unique identifier |
+| `workflowTemplateId` | Parent template reference |
+| `version` | Semantic version (e.g., "1.0.0") |
+| `versionNote` | Changelog for this version |
+| `definition` | JSON workflow definition |
+| `status` | DRAFT, PUBLISHED, or DEPRECATED |
+
+### Version status lifecycle
+
+```
+DRAFT → PUBLISHED → (activate) → Active
+ │ │
+ │ └──→ DEPRECATED
+ │
+ └── (edit allowed)
+```
+
+- **DRAFT** - Can be edited, not yet ready for production
+- **PUBLISHED** - Ready to be activated, cannot be edited
+- **DEPRECATED** - No longer recommended for use
+
+
+Only one version can be linked as the active version for a template at a time.
+
+
+## WorkflowTemplateLink
+
+Defines how workflows are triggered:
+
+```prisma
+enum WorkflowLinkType {
+ SERVICE_CATALOG
+ PRODUCT
+}
+
+model WorkflowTemplateLink {
+ id String @id @default(cuid())
+
+ WorkflowTemplate WorkflowTemplate @relation(
+ fields: [workflowTemplateId],
+ references: [id],
+ onDelete: Cascade
+ )
+ workflowTemplateId String
+
+ entityType WorkflowLinkType
+ entityId String
+
+ @@unique([entityType, entityId])
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `workflowTemplateId` | Template to trigger |
+| `entityType` | SERVICE_CATALOG or PRODUCT |
+| `entityId` | Service request type or product ID |
+
+### Link types
+
+| Type | Trigger condition |
+|------|-------------------|
+| `SERVICE_CATALOG` | When a specific service request type is created |
+| `PRODUCT` | When a specific product is purchased (from billing) |
+
+When a matching entity is created/purchased and a workflow link exists, the active version of the linked template is automatically instantiated.
+
+## WorkflowExecution
+
+Represents a running workflow instance:
+
+```prisma
+enum WorkflowExecutionStatus {
+ CREATED
+ STARTED
+ FAILED_TO_START
+ COMPLETED
+}
+
+model WorkflowExecution {
+ id String @id @default(cuid())
+ name String
+
+ WorkflowTemplateVersion WorkflowTemplateVersion @relation(
+ fields: [workflowTemplateVersionId],
+ references: [id]
+ )
+ workflowTemplateVersionId String
+
+ createdAt DateTime @default(now())
+
+ ParentWorkflowExecution WorkflowExecution? @relation(
+ fields: [parentWorkflowExecutionId],
+ references: [id],
+ onDelete: Cascade,
+ name: "parent_workflow_execution"
+ )
+ parentWorkflowExecutionId String?
+
+ RootWorkflowExecution WorkflowExecution? @relation(
+ fields: [rootWorkflowExecutionId],
+ references: [id],
+ onDelete: Cascade,
+ name: "root_workflow_execution"
+ )
+ rootWorkflowExecutionId String?
+
+ context Json?
+ status WorkflowExecutionStatus @default(CREATED)
+
+ ChildWorkflowExecutions WorkflowExecution[] @relation("parent_workflow_execution")
+ DescendantWorkflowExecutionsFromRoot WorkflowExecution[] @relation("root_workflow_execution")
+
+ ServiceRequest ServiceRequest?
+ ServiceRequestTaskGroup ServiceRequestTaskGroup?
+}
+```
+
+| Field | Description |
+|-------|-------------|
+| `id` | Unique execution identifier |
+| `name` | Execution name |
+| `workflowTemplateVersionId` | Template version being executed |
+| `parentWorkflowExecutionId` | Parent execution (for sub-workflows) |
+| `rootWorkflowExecutionId` | Root execution (for correlation) |
+| `context` | Metadata and global context |
+| `status` | Execution lifecycle status |
+
+### Execution status
+
+| Status | Description |
+|--------|-------------|
+| `CREATED` | Instance created, not yet started |
+| `STARTED` | Execution has begun |
+| `FAILED_TO_START` | Execution failed to start |
+| `COMPLETED` | Execution finished successfully |
+
+
+The `status` field tracks the database record lifecycle, not the runtime status. Runtime status is tracked in Temporal.
+
+
+### Context field
+
+The `context` field stores:
+
+- **Workflow metadata** - e.g., `directorId` for DSC workflows
+- **Global context** - Accessible via `__context__` in expressions
+
+Note: This context is separate from the Temporal runtime context.
+
+### Hierarchy relationships
+
+```
+Root Execution
+ │
+ ├── Child Execution 1 (parentWorkflowExecutionId = root)
+ │ │
+ │ └── Grandchild Execution (rootWorkflowExecutionId = root)
+ │
+ └── Child Execution 2 (parentWorkflowExecutionId = root)
+```
+
+- `parentWorkflowExecutionId` - Direct parent
+- `rootWorkflowExecutionId` - Ultimate ancestor (for correlation)
+
+## Entity relationships
+
+```
+┌──────────────────┐
+│ WorkflowTemplate │
+└────────┬─────────┘
+ │ 1:N
+ ▼
+┌────────────────────────┐ ┌─────────────────────┐
+│ WorkflowTemplateVersion│──────│ WorkflowTemplateLink│
+└────────┬───────────────┘ └─────────────────────┘
+ │ 1:N
+ ▼
+┌───────────────────┐
+│ WorkflowExecution │──┐
+└───────────────────┘ │
+ ▲ │ (parent/child)
+ └─────────────┘
+```
+
+## Next steps
+
+
+
+ Definition validation rules
+
+
+ Legacy service request mapping
+
+
+
diff --git a/engine/workflow-builder/reference/definition-types.mdx b/engine/workflow-builder/reference/definition-types.mdx
new file mode 100644
index 000000000..955e0ce0c
--- /dev/null
+++ b/engine/workflow-builder/reference/definition-types.mdx
@@ -0,0 +1,298 @@
+---
+title: 'Definition types'
+description: 'Technical reference for workflow definition structures'
+icon: 'file-code'
+---
+
+This reference documents the types used to define workflows.
+
+## TWorkflowDefinition
+
+The root type for a workflow definition:
+
+```typescript
+export type TWorkflowDefinition = {
+ id: string;
+ name: string;
+ steps: TWorkflowStepDefinition[];
+ stepTransitions: TWorkflowStepTransition[];
+ stepGroups?: TStepGroup[];
+ legacyServiceRequestType?: string;
+};
+```
+
+| Property | Description |
+|----------|-------------|
+| `id` | Unique identifier |
+| `name` | Human-readable name |
+| `steps` | Array of step definitions |
+| `stepTransitions` | Connections between steps |
+| `stepGroups` | UI groupings for steps |
+| `legacyServiceRequestType` | Maps to service request type |
+
+## Step definitions
+
+### TWorkflowBaseStepDefinition
+
+Base properties shared by all steps:
+
+```typescript
+export type TWorkflowBaseStepDefinition = {
+ id: string;
+ type: WorkflowStepType;
+ name: string;
+ outputSchema?: Record;
+ group?: {
+ groupId: string;
+ order: number;
+ };
+ legacyServiceRequestTaskKey?: string;
+ activationPolicy?: TStepActivationPolicy;
+ ui: {
+ reactFlow: {
+ position: {
+ x: number;
+ y: number;
+ };
+ };
+ };
+};
+```
+
+| Property | Description |
+|----------|-------------|
+| `id` | Unique step identifier |
+| `type` | Step type enum value |
+| `name` | Display label |
+| `outputSchema` | JSON Schema for output validation |
+| `group` | Grouping metadata |
+| `legacyServiceRequestTaskKey` | Legacy task mapping |
+| `activationPolicy` | Default activation state |
+| `ui.reactFlow.position` | Visual editor coordinates |
+
+### TStepActivationPolicy
+
+```typescript
+export type TStepActivationPolicy = {
+ defaultStatus?: WorkflowRuntimeStepStatus;
+};
+```
+
+### Control flow steps
+
+```typescript
+export type TStartWorkflowStepDefinition = TWorkflowBaseStepDefinition & {
+ type: WorkflowStepType.START;
+};
+
+export type TEndWorkflowStepDefinition = TWorkflowBaseStepDefinition & {
+ type: WorkflowStepType.END;
+};
+```
+
+### Human steps
+
+```typescript
+export type TBaseHumanStepDefinition = TWorkflowBaseStepDefinition & {
+ type:
+ | WorkflowStepType.HUMAN_URL_REDIRECT
+ | WorkflowStepType.HUMAN_FORM
+ | WorkflowStepType.HUMAN_CONFIRM
+ | WorkflowStepType.HUMAN_DOC_UPLOAD;
+};
+```
+
+### Gateway steps
+
+```typescript
+export type TBaseGatewayStepDefinition = TWorkflowBaseStepDefinition & {
+ type:
+ | WorkflowStepType.GATEWAY_PARALLEL_SPLIT
+ | WorkflowStepType.GATEWAY_PARALLEL_JOIN
+ | WorkflowStepType.GATEWAY_EXCLUSIVE_SPLIT
+ | WorkflowStepType.GATEWAY_INCLUSIVE_SPLIT;
+};
+```
+
+### Sub-workflow steps
+
+#### Base definition
+
+```typescript
+export type TBaseSubWorkflowStepDefinition = TWorkflowBaseStepDefinition & {
+ type: WorkflowStepType.SYS_SUB_WORKFLOW;
+ mode: SubWorkflowStepMode;
+ childWorkflowTemplateVersionId: string;
+ dataSources?: TDataSourceCall[];
+ inputMapping?: TMapping[];
+ contextProjection?: TMapping[];
+ childWorkflowName?: TExpr;
+};
+```
+
+| Property | Description |
+|----------|-------------|
+| `mode` | SINGLE or BATCH |
+| `childWorkflowTemplateVersionId` | Child workflow to execute |
+| `dataSources` | Data to fetch before execution |
+| `inputMapping` | How to populate child context |
+| `contextProjection` | How to project child outputs back |
+| `childWorkflowName` | Dynamic naming expression |
+
+#### Single mode
+
+```typescript
+export type TSingleWorkflowStepDefinition = TBaseSubWorkflowStepDefinition & {
+ mode: SubWorkflowStepMode.SINGLE;
+};
+```
+
+#### Batch mode
+
+```typescript
+export type TBatchWorkflowStepDefinition = TBaseSubWorkflowStepDefinition & {
+ mode: SubWorkflowStepMode.BATCH;
+ iterable: TIterableProvider;
+};
+```
+
+The `iterable` property defines how to construct the batch collection.
+
+### Union type
+
+```typescript
+export type TWorkflowStepDefinition =
+ | TWorkflowBaseStepDefinition
+ | TSingleWorkflowStepDefinition
+ | TBatchWorkflowStepDefinition
+ | TStartWorkflowStepDefinition
+ | TEndWorkflowStepDefinition
+ | TBaseHumanStepDefinition
+ | TBaseGatewayStepDefinition;
+```
+
+## Step transitions
+
+### TWorkflowStepTransition
+
+```typescript
+export type TWorkflowStepTransition = {
+ id: string;
+ fromStepId: string;
+ toStepId: string;
+ condition?: TExpr;
+ isDefault?: boolean;
+ label?: string;
+ onArrival?: TStepTransitionOnArrival;
+ ui: {
+ reactFlow: {
+ handle: {
+ sourceHandle: string;
+ targetHandle: string;
+ };
+ };
+ };
+};
+```
+
+| Property | Description |
+|----------|-------------|
+| `id` | Unique identifier |
+| `fromStepId` | Source step |
+| `toStepId` | Target step |
+| `condition` | Optional conditional expression |
+| `isDefault` | Default branch for exclusive gateways |
+| `label` | Display label |
+| `onArrival` | Actions when transition activates target |
+| `ui.reactFlow.handle` | Visual editor handle references |
+
+### TStepTransitionOnArrival
+
+```typescript
+export type TStepTransitionOnArrival = {
+ status?: WorkflowRuntimeStepStatus;
+};
+```
+
+Use this to set the target step's status when the transition fires. For example, set to `ACTION_REQUIRED` when an issue is reported.
+
+## Step groups
+
+### TStepGroup
+
+```typescript
+export type TStepGroup = {
+ id: string;
+ name: string;
+ stepIds: string[];
+ legacyServiceRequestTaskGroupKey?: string;
+};
+```
+
+| Property | Description |
+|----------|-------------|
+| `id` | Unique identifier |
+| `name` | Display name |
+| `stepIds` | Steps belonging to this group |
+| `legacyServiceRequestTaskGroupKey` | Legacy task group mapping |
+
+## Example definition
+
+```json
+{
+ "id": "workflow-1",
+ "name": "Customer Verification",
+ "steps": [
+ {
+ "id": "start",
+ "type": "start",
+ "name": "Start",
+ "ui": { "reactFlow": { "position": { "x": 0, "y": 0 } } }
+ },
+ {
+ "id": "verify",
+ "type": "human.confirm",
+ "name": "Verify Documents",
+ "outputSchema": {
+ "type": "object",
+ "properties": {
+ "verified": { "type": "boolean" }
+ }
+ },
+ "ui": { "reactFlow": { "position": { "x": 200, "y": 0 } } }
+ },
+ {
+ "id": "end",
+ "type": "end",
+ "name": "End",
+ "ui": { "reactFlow": { "position": { "x": 400, "y": 0 } } }
+ }
+ ],
+ "stepTransitions": [
+ {
+ "id": "t1",
+ "fromStepId": "start",
+ "toStepId": "verify",
+ "ui": { "reactFlow": { "handle": { "sourceHandle": "out", "targetHandle": "in" } } }
+ },
+ {
+ "id": "t2",
+ "fromStepId": "verify",
+ "toStepId": "end",
+ "ui": { "reactFlow": { "handle": { "sourceHandle": "out", "targetHandle": "in" } } }
+ }
+ ]
+}
+```
+
+## Next steps
+
+
+
+ Execution runtime types
+
+
+ Definition validation rules
+
+
+
diff --git a/engine/workflow-builder/reference/dsl-types.mdx b/engine/workflow-builder/reference/dsl-types.mdx
new file mode 100644
index 000000000..c27a87a91
--- /dev/null
+++ b/engine/workflow-builder/reference/dsl-types.mdx
@@ -0,0 +1,236 @@
+---
+title: 'DSL types'
+description: 'Technical reference for the Workflow Builder Domain Specific Language types'
+icon: 'code'
+---
+
+This reference documents the type system used in Workflow Builder's Domain Specific Language (DSL).
+
+## Expressions
+
+Expressions evaluate to a value using a specified expression engine. Currently, JSONata is the supported expression type.
+
+### ExpressionType
+
+```typescript
+export enum ExpressionType {
+ JSONATA = 'jsonata',
+}
+```
+
+### TExpr
+
+```typescript
+export type TExpr = {
+ type: ExpressionType.JSONATA;
+ src: string
+};
+```
+
+### Evaluation scope
+
+All expressions are evaluated against an environment containing:
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `__context__` | Global workflow context | `__context__.customerId` |
+| `__steps__` | Step outputs by ID | `__steps__.stepId.name` |
+| `__datasources__` | Datasource outputs by alias | `__datasources__.dsId.data` |
+| `__each__` | Current item in iterations | `__each__.id` |
+
+## Value providers
+
+### TFieldRef
+
+Defines how to access a field from different sources.
+
+```typescript
+export enum FieldRefSource {
+ CONTEXT = 'CONTEXT',
+ STEP = 'STEP',
+ DATASOURCE = 'DATASOURCE',
+ EACH = 'EACH',
+}
+
+export type TFieldRef =
+ | { source: FieldRefSource.CONTEXT; path: string }
+ | { source: FieldRefSource.STEP; stepId: string; path: string }
+ | { source: FieldRefSource.DATASOURCE; key: string; path: string }
+ | { source: FieldRefSource.EACH; path: string };
+```
+
+| Source | Description |
+|--------|-------------|
+| `CONTEXT` | Access from global context |
+| `STEP` | Access from step output |
+| `DATASOURCE` | Access from datasource output |
+| `EACH` | Access current item in loops |
+
+
+The `path` property uses dot notation (e.g., `"director.id"`) powered by the `dot-props` library.
+
+
+### TValueProvider
+
+Defines how to produce a value:
+
+```typescript
+export type TValueProvider =
+ | { type: "const"; value: unknown }
+ | { type: "field"; ref: TFieldRef }
+ | { type: "expr"; expr: TExpr };
+```
+
+| Type | Description |
+|------|-------------|
+| `const` | Hardcoded value |
+| `field` | Value from a field reference |
+| `expr` | Computed expression result |
+
+### TParamValue
+
+Used for datasource or function parameters:
+
+```typescript
+export type TParamValue =
+ | TValueProvider
+ | { [k: string]: TParamValue }
+ | TParamValue[];
+```
+
+## Datasource calls
+
+### TDataSourceCall
+
+```typescript
+export enum DataSourceType {
+ COMMENDA_LOGICAL_BACKEND = 'COMMENDA_LOGICAL_BACKEND',
+}
+
+export type TDataSourceCall = {
+ id: string;
+ alias: string;
+ type: DataSourceType.COMMENDA_LOGICAL_BACKEND;
+ dataSourceID: string;
+ params?: TParamValue;
+ select?: TExpr;
+ scope?: 'per-step' | 'per-item';
+};
+```
+
+| Property | Description |
+|----------|-------------|
+| `id` | Unique identifier |
+| `alias` | Reference name for accessing results |
+| `type` | Datasource type |
+| `dataSourceID` | Database reference to datasource definition |
+| `params` | Parameters to pass to the datasource |
+| `select` | Expression to transform output (default: entire output) |
+| `scope` | `per-step` (default) or `per-item` for batch workflows |
+
+## Iterator providers
+
+### TIterableProvider
+
+Provides an array for iteration:
+
+```typescript
+export enum IterableType {
+ EXPRESSION = 'EXPRESSION',
+ STEP = 'STEP',
+ DATASOURCE = 'DATASOURCE',
+}
+
+export type TIterableProvider =
+ | { type: IterableType.EXPRESSION; expr: TExpr }
+ | { type: IterableType.STEP; stepId: string; select?: TExpr }
+ | { type: IterableType.DATASOURCE; key: string; select?: TExpr };
+```
+
+| Type | Description |
+|------|-------------|
+| `EXPRESSION` | Evaluate expression against context |
+| `STEP` | Access step output array |
+| `DATASOURCE` | Access datasource output array |
+
+## Mappings
+
+### TMapping
+
+Specifies how to write values to a target:
+
+```typescript
+export type TMapping = {
+ id: string;
+ targetPath: string;
+ value: TValueProvider;
+ mode?: 'set' | 'append';
+};
+```
+
+| Property | Description |
+|----------|-------------|
+| `id` | Unique identifier |
+| `targetPath` | Dot-notation destination path |
+| `value` | How to derive the value |
+| `mode` | `set` (replace, default) or `append` (for arrays) |
+
+### Example
+
+```json
+{
+ "id": "map-directorId",
+ "targetPath": "directorId",
+ "value": {
+ "type": "expr",
+ "expr": { "src": "__each__.id" }
+ },
+ "mode": "set"
+}
+```
+
+This sets `directorId` to the current batch item's `id`.
+
+## Step types enum
+
+```typescript
+export enum WorkflowStepType {
+ START = 'start',
+ END = 'end',
+ HUMAN_URL_REDIRECT = 'human.url_redirect',
+ HUMAN_FORM = 'human.form',
+ HUMAN_CONFIRM = 'human.confirm',
+ HUMAN_DOC_UPLOAD = 'human.doc_upload',
+ SYS_SUB_WORKFLOW = 'sys.sub_workflow',
+ GATEWAY_PARALLEL_SPLIT = 'gateway.parallel_split',
+ GATEWAY_PARALLEL_JOIN = 'gateway.parallel_join',
+ GATEWAY_EXCLUSIVE_SPLIT = 'gateway.exclusive_split',
+ GATEWAY_INCLUSIVE_SPLIT = 'gateway.inclusive_split',
+}
+```
+
+## Sub-workflow modes
+
+```typescript
+export enum SubWorkflowStepMode {
+ SINGLE = 'SINGLE',
+ BATCH = 'BATCH',
+}
+```
+
+| Mode | Description |
+|------|-------------|
+| `SINGLE` | Execute one child workflow |
+| `BATCH` | Execute child workflow for each item in collection |
+
+## Next steps
+
+
+
+ Workflow definition structure
+
+
+ Execution runtime types
+
+
+
diff --git a/engine/workflow-builder/reference/runtime-types.mdx b/engine/workflow-builder/reference/runtime-types.mdx
new file mode 100644
index 000000000..192a7f338
--- /dev/null
+++ b/engine/workflow-builder/reference/runtime-types.mdx
@@ -0,0 +1,206 @@
+---
+title: 'Runtime types'
+description: 'Technical reference for workflow execution runtime types'
+icon: 'play'
+---
+
+This reference documents the types used during workflow execution.
+
+## Workflow runtime status
+
+```typescript
+export enum WorkflowRuntimeStatus {
+ NOT_STARTED = 'NotStarted',
+ IN_PROGRESS = 'InProgress',
+ COMPLETED = 'Completed',
+ FAILED = 'Failed',
+ CANCELLED = 'Cancelled',
+}
+```
+
+| Status | Description |
+|--------|-------------|
+| `NOT_STARTED` | Workflow defined but not yet begun |
+| `IN_PROGRESS` | Actively executing steps |
+| `COMPLETED` | All steps finished successfully |
+| `FAILED` | One or more steps failed |
+| `CANCELLED` | Execution was explicitly cancelled |
+
+## Step runtime status
+
+```typescript
+export enum WorkflowRuntimeStepStatus {
+ NOT_STARTED = 'NotStarted',
+ IN_PROGRESS = 'InProgress',
+ COMPLETED = 'Completed',
+ DISABLED = 'Disabled',
+ FAILED = 'Failed',
+}
+```
+
+| Status | Description |
+|--------|-------------|
+| `NOT_STARTED` | Step has not started |
+| `IN_PROGRESS` | Step is currently executing |
+| `COMPLETED` | Step finished successfully |
+| `DISABLED` | Step is disabled |
+| `FAILED` | Step execution failed |
+
+## TRuntimeWorkflowExecution
+
+Represents a running workflow instance:
+
+```typescript
+export type TRuntimeWorkflowExecution = {
+ id: string;
+ correlationId: string;
+ parentWorkflowExecutionId?: string;
+ rootWorkflowExecutionId?: string;
+ workflowTemplateVersionId: string;
+ runtimeStatus: WorkflowRuntimeStatus;
+ startedAt: string;
+ completedAt?: string;
+ failedAt?: string;
+ lastActivityAt?: string;
+ context: Record;
+ steps: Record;
+};
+```
+
+| Property | Description |
+|----------|-------------|
+| `id` | Unique execution identifier |
+| `correlationId` | Correlation ID for tracing |
+| `parentWorkflowExecutionId` | Parent workflow if spawned as sub-workflow |
+| `rootWorkflowExecutionId` | Root workflow in nested hierarchies |
+| `workflowTemplateVersionId` | Template version being executed |
+| `runtimeStatus` | Current overall status |
+| `startedAt` | Execution start timestamp |
+| `completedAt` | Completion timestamp (if completed) |
+| `failedAt` | Failure timestamp (if failed) |
+| `lastActivityAt` | Last step update timestamp |
+| `context` | Global workflow context data |
+| `steps` | Map of step execution states by ID |
+
+### Context usage
+
+The `context` property serves two purposes:
+
+1. **Global context** - Accessible via `__context__` in expressions
+2. **Metadata storage** - Additional execution information (e.g., `directorId` for DSC workflows)
+
+## TRuntimeWorkflowStepExecution
+
+Represents a step's execution state:
+
+```typescript
+export type TRuntimeWorkflowStepExecution = {
+ id: string;
+ type: WorkflowStepType;
+ stepId: string;
+ status: WorkflowRuntimeStepStatus;
+ attempt: number;
+ startedAt?: string;
+ completedAt?: string;
+ failedAt?: string;
+ dueAt?: string;
+ outputData?: Record;
+ childWorkflowExecutions?: { id: string }[];
+};
+```
+
+| Property | Description |
+|----------|-------------|
+| `id` | Unique step execution ID |
+| `type` | Step type |
+| `stepId` | Reference to step definition ID |
+| `status` | Current step status |
+| `attempt` | Attempt number (for retries) |
+| `startedAt` | Step start timestamp |
+| `completedAt` | Completion timestamp |
+| `failedAt` | Failure timestamp |
+| `dueAt` | Due date for the step |
+| `outputData` | Step output (follows outputSchema) |
+| `childWorkflowExecutions` | Child workflows triggered by this step |
+
+## Runtime flow
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ Workflow Execution │
+│ │
+│ Status: IN_PROGRESS │
+│ Context: { customerId: "123", ... } │
+│ │
+│ Steps: │
+│ ┌─────────────┬──────────────┬─────────────────┐ │
+│ │ start │ IN_PROGRESS │ outputData: {} │ │
+│ ├─────────────┼──────────────┼─────────────────┤ │
+│ │ verify │ NOT_STARTED │ outputData: null│ │
+│ ├─────────────┼──────────────┼─────────────────┤ │
+│ │ end │ NOT_STARTED │ outputData: null│ │
+│ └─────────────┴──────────────┴─────────────────┘ │
+└─────────────────────────────────────────────────────────┘
+```
+
+## Accessing runtime data
+
+In expressions, access step outputs via the `__steps__` variable:
+
+```jsonata
+__steps__.verify.outputData.verified
+```
+
+This returns the `verified` field from the `verify` step's output.
+
+## Child workflow executions
+
+For sub-workflow steps, `childWorkflowExecutions` contains references to spawned workflows:
+
+```json
+{
+ "id": "step-exec-1",
+ "type": "sys.sub_workflow",
+ "stepId": "dsc-step",
+ "status": "Completed",
+ "childWorkflowExecutions": [
+ { "id": "child-exec-1" },
+ { "id": "child-exec-2" },
+ { "id": "child-exec-3" }
+ ]
+}
+```
+
+## Status transitions
+
+### Workflow status flow
+
+```
+NOT_STARTED → IN_PROGRESS → COMPLETED
+ │
+ ├──────→ FAILED
+ │
+ └──────→ CANCELLED
+```
+
+### Step status flow
+
+```
+NOT_STARTED → IN_PROGRESS → COMPLETED
+ │
+ └──────→ FAILED
+
+(DISABLED can be set at any point via activation policy)
+```
+
+## Next steps
+
+
+
+ Database schema reference
+
+
+ Definition validation rules
+
+
+
diff --git a/engine/workflow-builder/reference/service-request-integration.mdx b/engine/workflow-builder/reference/service-request-integration.mdx
new file mode 100644
index 000000000..7a6d730fa
--- /dev/null
+++ b/engine/workflow-builder/reference/service-request-integration.mdx
@@ -0,0 +1,231 @@
+---
+title: 'Service request integration'
+description: 'How workflows integrate with the legacy service request system'
+icon: 'link'
+---
+
+This reference explains how Workflow Builder integrates with the existing service request system during the transition period.
+
+
+This is a temporary solution until form builder fully powers the workflow UI. Currently, workflows handle **orchestration only** while service requests maintain business context (files, assignees, corporations, etc.).
+
+
+## Architecture overview
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ Service Request │
+│ ┌─────────────────────────────────────────────────────┐│
+│ │ Business Context: files, assignees, corporations... ││
+│ └─────────────────────────────────────────────────────┘│
+│ │ │
+│ ▼ │
+│ ┌─────────────────────────────────────────────────────┐│
+│ │ Task Groups & Tasks ││
+│ │ (Statuses synced from Workflow Execution) ││
+│ └─────────────────────────────────────────────────────┘│
+└─────────────────────────────────────────────────────────┘
+ │
+ │ (sync)
+ ▼
+┌─────────────────────────────────────────────────────────┐
+│ Workflow Execution │
+│ ┌─────────────────────────────────────────────────────┐│
+│ │ Step Groups & Steps (Source of Truth) ││
+│ └─────────────────────────────────────────────────────┘│
+└─────────────────────────────────────────────────────────┘
+```
+
+## Service request configuration
+
+For each service request type, we maintain a configuration defining:
+
+- Which **task groups** exist
+- Which **tasks** belong to each group
+
+These are represented using `TaskGroup` and `Task` enums.
+
+At runtime, this configuration generates service request instances on the backend.
+
+## Frontend rendering
+
+The frontend uses a `componentMap` that maps each `taskKey` to a React component:
+
+```typescript
+const componentMap = {
+ 'add-bank-account': AddBankAccount,
+ 'mark-as-completed': MarkAsCompleted,
+ // ... other mappings
+};
+```
+
+When rendering a task:
+1. Look up the `taskKey` in `componentMap`
+2. If found, render the custom component
+3. If not found, render a **Generic Task** (assigned to an agent, "Mark as Completed" behavior)
+
+## Workflow as source of truth
+
+When a service request is initiated:
+
+1. Check if a **workflow link** exists for that service request type
+2. If yes, start a **workflow execution**
+3. The workflow execution becomes the **source of truth** for task statuses
+
+
+Service request instances and workflow execution instances co-exist and must be **kept in sync**. Statuses should always come from the workflow execution.
+
+
+## Syncing task updates
+
+When updating a task in the service request:
+
+```
+1. Check if service request has associated workflow execution
+ │
+ ▼
+2. Propagate update to workflow execution
+ │
+ ▼
+3. Wait for update to complete
+ │
+ ▼
+4. Fetch latest runtime statuses from workflow
+ │
+ ▼
+5. Build Prisma mutations for each status change
+ │
+ ▼
+6. Execute updates in a transaction
+```
+
+If something fails midway, a manual **"Sync" button** allows reconciliation between the service request and workflow.
+
+## Mapping workflows to service requests
+
+When creating a new workflow, connect it to a service request using these fields:
+
+### Workflow level
+
+```typescript
+{
+ legacyServiceRequestType: "INDIA_PVT_LTD_INCORPORATION"
+}
+```
+
+### Step group level
+
+```typescript
+{
+ stepGroups: [
+ {
+ id: "group-1",
+ name: "Document Verification",
+ legacyServiceRequestTaskGroupKey: "DOCUMENT_VERIFICATION"
+ }
+ ]
+}
+```
+
+### Step level
+
+```typescript
+{
+ steps: [
+ {
+ id: "step-1",
+ type: "human.confirm",
+ legacyServiceRequestTaskKey: "VERIFY_PAN_CARD"
+ }
+ ]
+}
+```
+
+### Mapping flow
+
+1. **Select** the `legacyServiceRequestType`
+2. **Select** the `taskGroup` for each `stepGroup`
+3. For each step, **select** the `taskKey`
+
+## Component rendering logic
+
+```
+Task has legacyServiceRequestTaskKey?
+ │
+ ┌─────┴─────┐
+ │ │
+ YES NO
+ │ │
+ ▼ ▼
+Look up in Render
+componentMap Generic Task
+ │
+ ▼
+Found?
+ │
+┌───┴───┐
+│ │
+YES NO
+│ │
+▼ ▼
+Render Render
+Custom Generic
+Comp. Task
+```
+
+## Handling dynamic DSC task groups
+
+The India Pvt Ltd incorporation workflow requires dynamic task groups—each director without a DSC goes through a separate DSC onboarding flow.
+
+### Domain mismatch
+
+| Domain | Representation |
+|--------|----------------|
+| Workflow | One child workflow per director |
+| Service Request | Separate task group per DSC workflow |
+
+### Current solution
+
+```typescript
+// Determine which workflow execution to update
+workflowExecutionToUpdate =
+ serviceRequestTaskGroup.workflowExecutionId
+ || serviceRequest.workflowExecutionId
+```
+
+The system:
+
+1. Identifies DSC-related child workflow executions
+2. Creates/updates corresponding Service Request task groups
+3. Links each task group to the correct `workflowExecutionId`
+4. Ensures group names and ordering follow SR UI conventions
+
+### Update routing
+
+- If task belongs to a DSC group → update **child workflow execution**
+- Otherwise → update **parent workflow execution**
+
+## Future considerations
+
+
+We have not yet generalized this pattern. Open questions include:
+
+- Should all child workflows appear as Service Request task groups?
+- Should child-of-child workflows be shown?
+- How should workflows with multiple step groups be projected?
+- Should we introduce a generic "projection type" system?
+
+These will be revisited as more diverse workflows are built and real patterns emerge.
+
+
+## Next steps
+
+
+
+ Database schema reference
+
+
+ Build workflows with legacy mapping
+
+
+
diff --git a/engine/workflow-builder/reference/validation-rules.mdx b/engine/workflow-builder/reference/validation-rules.mdx
new file mode 100644
index 000000000..779e55c5a
--- /dev/null
+++ b/engine/workflow-builder/reference/validation-rules.mdx
@@ -0,0 +1,330 @@
+---
+title: 'Validation rules'
+description: 'Reference for workflow definition validation rules'
+icon: 'check'
+---
+
+This reference documents all validation rules applied to workflow definitions before they can be published.
+
+## Graph rules
+
+These rules validate the workflow graph structure and topology.
+
+### GRAPH_EXACTLY_ONE_START
+
+**Rule:** Workflow must have exactly 1 START step
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Validation counts START steps and fails if count ≠ 1.
+
+### GRAPH_EXACTLY_ONE_END
+
+**Rule:** Workflow must have exactly 1 END step
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Validation counts END steps and fails if count ≠ 1.
+
+### START_STEP_NO_INCOMING
+
+**Rule:** START step must not have any incoming transitions
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Checks incoming transitions for START steps.
+
+### END_STEP_SINGLE_INCOMING
+
+**Rule:** END step must have exactly 1 incoming transition
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Checks incoming count for END steps.
+
+### END_STEP_NO_OUTGOING
+
+**Rule:** END step must not have outgoing transitions
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Checks outgoing transitions for END steps.
+
+### TRANSITIONS_UNIQUE
+
+**Rule:** No duplicate (from, to) transition pairs
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Ensures no duplicate `(fromStepId, toStepId)` pairs.
+
+### NO_SELF_LOOPS
+
+**Rule:** Self-loop transitions are not allowed
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Checks that `fromStepId !== toStepId` for all transitions.
+
+### NO_ISOLATED_STEPS
+
+**Rule:** Steps with no incoming or outgoing transitions are isolated
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Checks for steps (excluding START/END) with 0 incoming and 0 outgoing transitions.
+
+### ONLY_SPLIT_GATEWAY_CAN_FAN_OUT
+
+**Rule:** Only split gateways may have more than one outgoing transition
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Non-split gateway steps cannot have >1 outgoing transitions.
+
+### JOIN_GATEWAY_MANY_IN_SINGLE_OUT
+
+**Rule:** Join gateway must have at least 2 incoming transitions and exactly 1 outgoing transition
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Applies to `GATEWAY_PARALLEL_JOIN` steps.
+
+### CONDITIONAL_SPLIT_SINGLE_DEFAULT
+
+**Rule:** Conditional split gateway must have exactly 1 default transition
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Applies to `GATEWAY_EXCLUSIVE_SPLIT` and `GATEWAY_INCLUSIVE_SPLIT`.
+
+### EXCLUSIVE_SPLIT_TWO_OUTGOING
+
+**Rule:** Exclusive gateway must have exactly 2 outgoing transitions (1 default, 1 conditional)
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Applies to `GATEWAY_EXCLUSIVE_SPLIT` steps.
+
+### ONLY_EXCLUSIVE_INCLUSIVE_STEP_HAVE_CONDITION
+
+**Rule:** Regular steps cannot have conditional transitions
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+Only exclusive/inclusive split gateways can have conditional transitions.
+
+### MISSING_BATCH_ITERATOR
+
+**Rule:** Batch workflow should have an iterator
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GRAPH_INVALID |
+
+BATCH mode sub-workflow steps must have an `iterable` property.
+
+## ID rules
+
+These rules ensure unique identifiers across workflow entities.
+
+### STEP_IDS_UNIQUE
+
+**Rule:** Step IDs must be unique
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | ID_INVALID |
+
+Ensures no duplicate step IDs in the workflow.
+
+### TRANSITION_IDS_UNIQUE
+
+**Rule:** Transition IDs must be unique
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | ID_INVALID |
+
+Ensures no duplicate transition IDs.
+
+### STEP_GROUP_IDS_UNIQUE
+
+**Rule:** Step group IDs must be unique
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | ID_INVALID |
+
+Ensures no duplicate step group IDs.
+
+## Group rules
+
+These rules validate step grouping and organization.
+
+### NO_GROUP_FOR_SPECIAL_NODES
+
+**Rule:** Start/end/gateways cannot be grouped
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GROUPING_INVALID |
+
+Only human nodes and system nodes can be grouped; START, END, and gateway steps cannot.
+
+### GROUP_STEP_IDS_EXISTS
+
+**Rule:** Step group contains stepIds that do not reference existing steps
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GROUPING_INVALID |
+
+All stepIds in a stepGroup must reference existing steps.
+
+### STEP_BELONGS_TO_ONLY_ONE_GROUP
+
+**Rule:** Each step can only belong to one group
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GROUPING_INVALID |
+
+Ensures each step appears in at most one stepGroup.
+
+### STEP_GROUP_CANNOT_BE_EMPTY
+
+**Rule:** Each step group must contain at least one step
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GROUPING_INVALID |
+
+Each stepGroup must have at least one stepId.
+
+### LEGACY_SERVICE_REQUEST_REQUIRES_STEP_GROUPS
+
+**Rule:** Workflow with legacyServiceRequestType must have at least one step group
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | GROUPING_INVALID |
+
+If `legacyServiceRequestType` is set, at least one stepGroup must exist.
+
+## Legacy service request rules
+
+These rules validate legacy service request mappings and compatibility.
+
+### LEGACY_SERVICE_REQUEST_TYPE_GROUP_TASK_UNIQUE
+
+**Rule:** Multiple steps share the same legacy combination (serviceRequestType, taskGroup, taskKey)
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | LEGACY_CONFIG_INVALID |
+
+The tuple `(serviceRequestType, taskGroupKey, taskKey)` must be unique across all steps.
+
+### LEGACY_SERVICE_REQUEST_TASK_GROUP_EXISTS_IN_TEMPLATE
+
+**Rule:** Step group with legacyServiceRequestTaskGroupKey does not exist in serviceRequestTemplate
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | LEGACY_CONFIG_INVALID |
+
+StepGroups with `legacyServiceRequestTaskGroupKey` must exist in the service request template.
+
+### LEGACY_SERVICE_REQUEST_TASK_EXISTS_IN_TEMPLATE
+
+**Rule:** Step with legacyServiceRequestTaskKey does not exist in the corresponding taskGroup template
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | LEGACY_CONFIG_INVALID |
+
+Steps with `legacyServiceRequestTaskKey` must exist in the corresponding taskGroup's tasks in the template.
+
+### LEGACY_SERVICE_REQUEST_TASK_ONLY_ON_HUMAN_STEP
+
+**Rule:** Only human steps can have legacyServiceRequestTask mapping
+
+| Property | Value |
+|----------|-------|
+| Severity | ERROR |
+| Error Code | LEGACY_CONFIG_INVALID |
+
+Only human node types can have `legacyServiceRequestTaskKey` set.
+
+## Error code summary
+
+| Error Code | Category |
+|------------|----------|
+| `GRAPH_INVALID` | Workflow graph structure issues |
+| `ID_INVALID` | Duplicate or missing identifiers |
+| `GROUPING_INVALID` | Step grouping issues |
+| `LEGACY_CONFIG_INVALID` | Legacy mapping issues |
+
+## Next steps
+
+
+
+ Legacy service request mapping
+
+
+ Build your first workflow
+
+
+
diff --git a/essentials/code.mdx b/essentials/code.mdx
deleted file mode 100644
index ae2abbfec..000000000
--- a/essentials/code.mdx
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: 'Code blocks'
-description: 'Display inline code and code blocks'
-icon: 'code'
----
-
-## Inline code
-
-To denote a `word` or `phrase` as code, enclose it in backticks (`).
-
-```
-To denote a `word` or `phrase` as code, enclose it in backticks (`).
-```
-
-## Code blocks
-
-Use [fenced code blocks](https://www.markdownguide.org/extended-syntax/#fenced-code-blocks) by enclosing code in three backticks and follow the leading ticks with the programming language of your snippet to get syntax highlighting. Optionally, you can also write the name of your code after the programming language.
-
-```java HelloWorld.java
-class HelloWorld {
- public static void main(String[] args) {
- System.out.println("Hello, World!");
- }
-}
-```
-
-````md
-```java HelloWorld.java
-class HelloWorld {
- public static void main(String[] args) {
- System.out.println("Hello, World!");
- }
-}
-```
-````
diff --git a/essentials/images.mdx b/essentials/images.mdx
deleted file mode 100644
index 1144eb2cc..000000000
--- a/essentials/images.mdx
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: 'Images and embeds'
-description: 'Add image, video, and other HTML elements'
-icon: 'image'
----
-
-
-
-## Image
-
-### Using Markdown
-
-The [markdown syntax](https://www.markdownguide.org/basic-syntax/#images) lets you add images using the following code
-
-```md
-
-```
-
-Note that the image file size must be less than 5MB. Otherwise, we recommend hosting on a service like [Cloudinary](https://cloudinary.com/) or [S3](https://aws.amazon.com/s3/). You can then use that URL and embed.
-
-### Using embeds
-
-To get more customizability with images, you can also use [embeds](/writing-content/embed) to add images
-
-```html
-
-```
-
-## Embeds and HTML elements
-
-
-
-
-
-
-
-Mintlify supports [HTML tags in Markdown](https://www.markdownguide.org/basic-syntax/#html). This is helpful if you prefer HTML tags to Markdown syntax, and lets you create documentation with infinite flexibility.
-
-
-
-### iFrames
-
-Loads another HTML page within the document. Most commonly used for embedding videos.
-
-```html
-
-```
diff --git a/essentials/markdown.mdx b/essentials/markdown.mdx
deleted file mode 100644
index a45c1d569..000000000
--- a/essentials/markdown.mdx
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: 'Markdown syntax'
-description: 'Text, title, and styling in standard markdown'
-icon: 'text-size'
----
-
-## Titles
-
-Best used for section headers.
-
-```md
-## Titles
-```
-
-### Subtitles
-
-Best used for subsection headers.
-
-```md
-### Subtitles
-```
-
-
-
-Each **title** and **subtitle** creates an anchor and also shows up on the table of contents on the right.
-
-
-
-## Text formatting
-
-We support most markdown formatting. Simply add `**`, `_`, or `~` around text to format it.
-
-| Style | How to write it | Result |
-| ------------- | ----------------- | --------------- |
-| Bold | `**bold**` | **bold** |
-| Italic | `_italic_` | _italic_ |
-| Strikethrough | `~strikethrough~` | ~strikethrough~ |
-
-You can combine these. For example, write `**_bold and italic_**` to get **_bold and italic_** text.
-
-You need to use HTML to write superscript and subscript text. That is, add `` or `` around your text.
-
-| Text Size | How to write it | Result |
-| ----------- | ------------------------ | ---------------------- |
-| Superscript | `superscript` | superscript |
-| Subscript | `subscript` | subscript |
-
-## Linking to pages
-
-You can add a link by wrapping text in `[]()`. You would write `[link to google](https://google.com)` to [link to google](https://google.com).
-
-Links to pages in your docs need to be root-relative. Basically, you should include the entire folder path. For example, `[link to text](/writing-content/text)` links to the page "Text" in our components section.
-
-Relative links like `[link to text](../text)` will open slower because we cannot optimize them as easily.
-
-## Blockquotes
-
-### Singleline
-
-To create a blockquote, add a `>` in front of a paragraph.
-
-> Dorothy followed her through many of the beautiful rooms in her castle.
-
-```md
-> Dorothy followed her through many of the beautiful rooms in her castle.
-```
-
-### Multiline
-
-> Dorothy followed her through many of the beautiful rooms in her castle.
->
-> The Witch bade her clean the pots and kettles and sweep the floor and keep the fire fed with wood.
-
-```md
-> Dorothy followed her through many of the beautiful rooms in her castle.
->
-> The Witch bade her clean the pots and kettles and sweep the floor and keep the fire fed with wood.
-```
-
-### LaTeX
-
-Mintlify supports [LaTeX](https://www.latex-project.org) through the Latex component.
-
-8 x (vk x H1 - H2) = (0,1)
-
-```md
-8 x (vk x H1 - H2) = (0,1)
-```
diff --git a/essentials/navigation.mdx b/essentials/navigation.mdx
deleted file mode 100644
index 60adeff23..000000000
--- a/essentials/navigation.mdx
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: 'Navigation'
-description: 'The navigation field in docs.json defines the pages that go in the navigation menu'
-icon: 'map'
----
-
-The navigation menu is the list of links on every website.
-
-You will likely update `docs.json` every time you add a new page. Pages do not show up automatically.
-
-## Navigation syntax
-
-Our navigation syntax is recursive which means you can make nested navigation groups. You don't need to include `.mdx` in page names.
-
-
-
-```json Regular Navigation
-"navigation": {
- "tabs": [
- {
- "tab": "Docs",
- "groups": [
- {
- "group": "Getting Started",
- "pages": ["quickstart"]
- }
- ]
- }
- ]
-}
-```
-
-```json Nested Navigation
-"navigation": {
- "tabs": [
- {
- "tab": "Docs",
- "groups": [
- {
- "group": "Getting Started",
- "pages": [
- "quickstart",
- {
- "group": "Nested Reference Pages",
- "pages": ["nested-reference-page"]
- }
- ]
- }
- ]
- }
- ]
-}
-```
-
-
-
-## Folders
-
-Simply put your MDX files in folders and update the paths in `docs.json`.
-
-For example, to have a page at `https://yoursite.com/your-folder/your-page` you would make a folder called `your-folder` containing an MDX file called `your-page.mdx`.
-
-
-
-You cannot use `api` for the name of a folder unless you nest it inside another folder. Mintlify uses Next.js which reserves the top-level `api` folder for internal server calls. A folder name such as `api-reference` would be accepted.
-
-
-
-```json Navigation With Folder
-"navigation": {
- "tabs": [
- {
- "tab": "Docs",
- "groups": [
- {
- "group": "Group Name",
- "pages": ["your-folder/your-page"]
- }
- ]
- }
- ]
-}
-```
-
-## Hidden pages
-
-MDX files not included in `docs.json` will not show up in the sidebar but are accessible through the search bar and by linking directly to them.
diff --git a/essentials/reusable-snippets.mdx b/essentials/reusable-snippets.mdx
deleted file mode 100644
index 376e27bd9..000000000
--- a/essentials/reusable-snippets.mdx
+++ /dev/null
@@ -1,110 +0,0 @@
----
-title: "Reusable snippets"
-description: "Reusable, custom snippets to keep content in sync"
-icon: "recycle"
----
-
-import SnippetIntro from '/snippets/snippet-intro.mdx';
-
-
-
-## Creating a custom snippet
-
-**Pre-condition**: You must create your snippet file in the `snippets` directory.
-
-
- Any page in the `snippets` directory will be treated as a snippet and will not
- be rendered into a standalone page. If you want to create a standalone page
- from the snippet, import the snippet into another file and call it as a
- component.
-
-
-### Default export
-
-1. Add content to your snippet file that you want to re-use across multiple
- locations. Optionally, you can add variables that can be filled in via props
- when you import the snippet.
-
-```mdx snippets/my-snippet.mdx
-Hello world! This is my content I want to reuse across pages. My keyword of the
-day is {word}.
-```
-
-
- The content that you want to reuse must be inside the `snippets` directory in
- order for the import to work.
-
-
-2. Import the snippet into your destination file.
-
-```mdx destination-file.mdx
----
-title: My title
-description: My Description
----
-
-import MySnippet from '/snippets/path/to/my-snippet.mdx';
-
-## Header
-
-Lorem impsum dolor sit amet.
-
-
-```
-
-### Reusable variables
-
-1. Export a variable from your snippet file:
-
-```mdx snippets/path/to/custom-variables.mdx
-export const myName = 'my name';
-
-export const myObject = { fruit: 'strawberries' };
-```
-
-2. Import the snippet from your destination file and use the variable:
-
-```mdx destination-file.mdx
----
-title: My title
-description: My Description
----
-
-import { myName, myObject } from '/snippets/path/to/custom-variables.mdx';
-
-Hello, my name is {myName} and I like {myObject.fruit}.
-```
-
-### Reusable components
-
-1. Inside your snippet file, create a component that takes in props by exporting
- your component in the form of an arrow function.
-
-```mdx snippets/custom-component.mdx
-export const MyComponent = ({ title }) => (
-
-
{title}
-
... snippet content ...
-
-);
-```
-
-
- MDX does not compile inside the body of an arrow function. Stick to HTML
- syntax when you can or use a default export if you need to use MDX.
-
-
-2. Import the snippet into your destination file and pass in the props
-
-```mdx destination-file.mdx
----
-title: My title
-description: My Description
----
-
-import { MyComponent } from '/snippets/custom-component.mdx';
-
-Lorem ipsum dolor sit amet.
-
-
-```
diff --git a/essentials/settings.mdx b/essentials/settings.mdx
deleted file mode 100644
index 884de13a4..000000000
--- a/essentials/settings.mdx
+++ /dev/null
@@ -1,318 +0,0 @@
----
-title: 'Global Settings'
-description: 'Mintlify gives you complete control over the look and feel of your documentation using the docs.json file'
-icon: 'gear'
----
-
-Every Mintlify site needs a `docs.json` file with the core configuration settings. Learn more about the [properties](#properties) below.
-
-## Properties
-
-
-Name of your project. Used for the global title.
-
-Example: `mintlify`
-
-
-
-
- An array of groups with all the pages within that group
-
-
- The name of the group.
-
- Example: `Settings`
-
-
-
- The relative paths to the markdown files that will serve as pages.
-
- Example: `["customization", "page"]`
-
-
-
-
-
-
-
- Path to logo image or object with path to "light" and "dark" mode logo images
-
-
- Path to the logo in light mode
-
-
- Path to the logo in dark mode
-
-
- Where clicking on the logo links you to
-
-
-
-
-
- Path to the favicon image
-
-
-
- Hex color codes for your global theme
-
-
- The primary color. Used for most often for highlighted content, section
- headers, accents, in light mode
-
-
- The primary color for dark mode. Used for most often for highlighted
- content, section headers, accents, in dark mode
-
-
- The primary color for important buttons
-
-
- The color of the background in both light and dark mode
-
-
- The hex color code of the background in light mode
-
-
- The hex color code of the background in dark mode
-
-
-
-
-
-
-
- Array of `name`s and `url`s of links you want to include in the topbar
-
-
- The name of the button.
-
- Example: `Contact us`
-
-
- The url once you click on the button. Example: `https://mintlify.com/docs`
-
-
-
-
-
-
-
-
- Link shows a button. GitHub shows the repo information at the url provided including the number of GitHub stars.
-
-
- If `link`: What the button links to.
-
- If `github`: Link to the repository to load GitHub information from.
-
-
- Text inside the button. Only required if `type` is a `link`.
-
-
-
-
-
-
- Array of version names. Only use this if you want to show different versions
- of docs with a dropdown in the navigation bar.
-
-
-
- An array of the anchors, includes the `icon`, `color`, and `url`.
-
-
- The [Font Awesome](https://fontawesome.com/search?q=heart) icon used to feature the anchor.
-
- Example: `comments`
-
-
- The name of the anchor label.
-
- Example: `Community`
-
-
- The start of the URL that marks what pages go in the anchor. Generally, this is the name of the folder you put your pages in.
-
-
- The hex color of the anchor icon background. Can also be a gradient if you pass an object with the properties `from` and `to` that are each a hex color.
-
-
- Used if you want to hide an anchor until the correct docs version is selected.
-
-
- Pass `true` if you want to hide the anchor until you directly link someone to docs inside it.
-
-
- One of: "brands", "duotone", "light", "sharp-solid", "solid", or "thin"
-
-
-
-
-
-
- Override the default configurations for the top-most anchor.
-
-
- The name of the top-most anchor
-
-
- Font Awesome icon.
-
-
- One of: "brands", "duotone", "light", "sharp-solid", "solid", or "thin"
-
-
-
-
-
- An array of navigational tabs.
-
-
- The name of the tab label.
-
-
- The start of the URL that marks what pages go in the tab. Generally, this
- is the name of the folder you put your pages in.
-
-
-
-
-
- Configuration for API settings. Learn more about API pages at [API Components](/api-playground/demo).
-
-
- The base url for all API endpoints. If `baseUrl` is an array, it will enable for multiple base url
- options that the user can toggle.
-
-
-
-
-
- The authentication strategy used for all API endpoints.
-
-
- The name of the authentication parameter used in the API playground.
-
- If method is `basic`, the format should be `[usernameName]:[passwordName]`
-
-
- The default value that's designed to be a prefix for the authentication input field.
-
- E.g. If an `inputPrefix` of `AuthKey` would inherit the default input result of the authentication field as `AuthKey`.
-
-
-
-
-
- Configurations for the API playground
-
-
-
- Whether the playground is showing, hidden, or only displaying the endpoint with no added user interactivity `simple`
-
- Learn more at the [playground guides](/api-playground/demo)
-
-
-
-
-
- Enabling this flag ensures that key ordering in OpenAPI pages matches the key ordering defined in the OpenAPI file.
-
- This behavior will soon be enabled by default, at which point this field will be deprecated.
-
-
-
-
-
-
- A string or an array of strings of URL(s) or relative path(s) pointing to your
- OpenAPI file.
-
- Examples:
-
- ```json Absolute
- "openapi": "https://example.com/openapi.json"
- ```
- ```json Relative
- "openapi": "/openapi.json"
- ```
- ```json Multiple
- "openapi": ["https://example.com/openapi1.json", "/openapi2.json", "/openapi3.json"]
- ```
-
-
-
-
-
- An object of social media accounts where the key:property pair represents the social media platform and the account url.
-
- Example:
- ```json
- {
- "x": "https://x.com/mintlify",
- "website": "https://mintlify.com"
- }
- ```
-
-
- One of the following values `website`, `facebook`, `x`, `discord`, `slack`, `github`, `linkedin`, `instagram`, `hacker-news`
-
- Example: `x`
-
-
- The URL to the social platform.
-
- Example: `https://x.com/mintlify`
-
-
-
-
-
- Configurations to enable feedback buttons
-
-
-
- Enables a button to allow users to suggest edits via pull requests
-
-
- Enables a button to allow users to raise an issue about the documentation
-
-
-
-
-
- Customize the dark mode toggle.
-
-
- Set if you always want to show light or dark mode for new users. When not
- set, we default to the same mode as the user's operating system.
-
-
- Set to true to hide the dark/light mode toggle. You can combine `isHidden` with `default` to force your docs to only use light or dark mode. For example:
-
-
- ```json Only Dark Mode
- "modeToggle": {
- "default": "dark",
- "isHidden": true
- }
- ```
-
- ```json Only Light Mode
- "modeToggle": {
- "default": "light",
- "isHidden": true
- }
- ```
-
-
-
-
-
-
-
-
- A background image to be displayed behind every page. See example with
- [Infisical](https://infisical.com/docs) and [FRPC](https://frpc.io).
-
diff --git a/favicon-32x32.png b/favicon-32x32.png
new file mode 100644
index 000000000..1b1d1795f
Binary files /dev/null and b/favicon-32x32.png differ
diff --git a/favicon.svg b/favicon.svg
deleted file mode 100644
index b785c738b..000000000
--- a/favicon.svg
+++ /dev/null
@@ -1,19 +0,0 @@
-
diff --git a/index.mdx b/index.mdx
deleted file mode 100644
index 15c23fb6c..000000000
--- a/index.mdx
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: "Introduction"
-description: "Welcome to the new home for your documentation"
----
-
-## Setting up
-
-Get your documentation site up and running in minutes.
-
-
- Follow our three step quickstart guide.
-
-
-## Make it yours
-
-Design a docs site that looks great and empowers your users.
-
-
-
- Edit your docs locally and preview them in real time.
-
-
- Customize the design and colors of your site to match your brand.
-
-
- Organize your docs to help users find what they need and succeed with your product.
-
-
- Auto-generate API documentation from OpenAPI specifications.
-
-
-
-## Create beautiful pages
-
-Everything you need to create world-class documentation.
-
-
-
- Use MDX to style your docs pages.
-
-
- Add sample code to demonstrate how to use your product.
-
-
- Display images and other media.
-
-
- Write once and reuse across your docs.
-
-
-
-## Need inspiration?
-
-
- Browse our showcase of exceptional documentation sites.
-
diff --git a/integrations/guidelines/existing-integration-behaviors/netsuite.mdx b/integrations/guidelines/existing-integration-behaviors/netsuite.mdx
new file mode 100644
index 000000000..c0496e097
--- /dev/null
+++ b/integrations/guidelines/existing-integration-behaviors/netsuite.mdx
@@ -0,0 +1,53 @@
+---
+title: 'Netsuite'
+description: 'Netsuite integration behaviors'
+---
+
+Netsuite supports both calculations and sync.
+
+Netsuite calculations are not implemented in the commenda logical backend, we built a plugin that each customer needs to install.
+
+## Sync:
+
+We sync the following data models (through Rootfi and logical backend, same as other integrations):
+
+**Netsuite Payment Vouchers: (**INVOICES, INVOICE_CREDIT_NOTES, CASH_REFUNDS, CASH_SALES)
+
+We follow the following hierarchy:
+
+- Invoice-level SHIPPING (extracted from Rootfi webhook payload)
+- customer-level default shipping (retrieved via Rootfi passthrough)
+- invoice-level BILLING (extracted from Rootfi webhook payload)
+- customer-level default billing (retrieved from Rootfi passthrough)
+
+When extracting an address from the rootfi webhook payload, we discard the address if raw_data is not present on the payload, but we never actually use the raw_data field.
+
+If there is exactly one customer-level shipping address or customer-level billing address, we do not seem to consider them unless they are explicitly set to default. But test this to see how the integration actually works.
+
+**Customers**: CONTACTS
+
+We extract the customer-level shipping address and billing address from the webhook payload’s raw_data field.
+
+- If the shipping address is set, we set the contact shipping address to the webhook payload shipping address.
+- If the billing address is set, we set the contact billing address to the webhook payload billing address
+- If the billing address is set but the shipping address is not set, we set the contact shipping address to the webhook payload *billing *address
+
+## Calculations:
+
+Address resolution for calculations is both divergent from the Rootfi/ Commenda implementation, and contains several questionable implementation decisions that do not align with the sales tax API or with our best practices.
+
+The code is heavily dependent on netsuite internal details.
+
+We start by defining a ‘complete address’ as one with address line 1 and country set, where the country is not “IN”.
+
+We then try to extract the invoice shipping address with several different calls to netsuite internals that I don’t understand. These netsuite internals all need to be individually audited, because a lurking bug in any one would be unlikely to surface for any given customer. We pick the first non-null one of these addresses, regardless of whether it is a “complete address” as defined above.
+
+If the first non-null of the addresses is a “complete address”, we select it as our calculation address, otherwise we discard the other non-null shipping addresses and continue.
+
+We then do exactly the same for invoice billing address.
+
+If that also fails, we load the customer record and attempt to retrieve its billing address. If that succeeds, and is “complete”, we return it.
+
+Otherwise, we do a bunch of stuff I don’t understand to get a “fallback” address.
+
+
diff --git a/integrations/guidelines/existing-integration-behaviors/quickbooks.mdx b/integrations/guidelines/existing-integration-behaviors/quickbooks.mdx
new file mode 100644
index 000000000..62fffbe57
--- /dev/null
+++ b/integrations/guidelines/existing-integration-behaviors/quickbooks.mdx
@@ -0,0 +1,24 @@
+---
+title: 'Quickbooks'
+description: 'Quickbooks integration behaviors'
+---
+
+Quickbooks supports both calculations and sync.
+
+There are two different code paths for Quickbooks address resolution, one for calculations and one for sync. They are currently implemented differently in a way that may be error-prone, and this should be reviewed.
+
+## Sync:
+
+**Quickbooks Transactions**: INVOICES, INVOICE_CREDIT_NOTES, CASH_REFUNDS
+
+We use addresses directly from Rootfi. We use the invoice-level shipping address if present, if it is null, we fall back to the invoice-level billing address. We do not do any validation checks on the shipping address, so if it’s non-null but incomplete we will still propagate it forwards.
+
+ Customer-level addresses are not considered.
+
+**Quickbooks Contacts: **CONTACTS
+
+We record the shipping and billing addresses on the contact, synced through Rootfi.
+
+## Calculations:
+
+We retrieve the transaction from rootfi’s passthrough API and then only consider the shipping address, calculating based on it no matter what.
diff --git a/integrations/guidelines/existing-integration-behaviors/shopify.mdx b/integrations/guidelines/existing-integration-behaviors/shopify.mdx
new file mode 100644
index 000000000..03f7f65c6
--- /dev/null
+++ b/integrations/guidelines/existing-integration-behaviors/shopify.mdx
@@ -0,0 +1,24 @@
+---
+title: 'Shopify'
+description: 'Shopify integration behaviors'
+---
+
+Commenda does not support tax calculations in Shopify, the following doc refers only to their sync flow.
+
+**Shopify Transactions **(ECOMMERCE_TRANSACTIONS in Rootfi)
+
+We follow this hierarchy to pick the first non-null address (with no validity checks other than whether the address is null or not):
+
+- Shopify’s transaction shipping address (from raw data)
+- Shopify’s transaction billing address (from raw data)
+
+We don’t seem to fall back to a customer-level address if those fields are missing
+
+**Shopify Customers** (ECOMMERCE_CUSTOMERS in rootfi)
+
+We follow this hierarchy to pick the first valid address:
+
+- Rootfi SHIPPING address
+- Rootfi BILLING address
+
+We select exactly one of these addresses, geocode it, and sync it to the sales tax API.
diff --git a/integrations/guidelines/existing-integration-behaviors/stripe.mdx b/integrations/guidelines/existing-integration-behaviors/stripe.mdx
new file mode 100644
index 000000000..56056027f
--- /dev/null
+++ b/integrations/guidelines/existing-integration-behaviors/stripe.mdx
@@ -0,0 +1,54 @@
+---
+title: 'Stripe'
+description: 'Stripe integration behaviors'
+---
+
+We have a calculations flow which is somewhat broken and unused. The following documentation ignores that flow, and only refers to the sync flow, which is implemented in a totally separate way. The sync flow’s implementation should be merged with the calculation implementation - both should use the exact same code for processing invoices to identify and geocode the transaction address.
+
+**Invoices ** (PAYMENT_INVOICES in rootfi)
+
+We extract addresses from the raw_data field directly from Stripe, instead of relying on the Rootfi mapping.
+
+We follow this hierarchy to pick the first valid shipping address AND the first “Valid” billing address.
+
+1. Invoice-level shipping address
+2. Invoice-level “Customer shipping address”
+3. Customer-level shipping address
+4. Invoice-level billing address (invoice.customer_address)
+5. Customer-level billing address (customer.address)
+6. Customer’s payment method billing address (payment_method.billing_details.address)
+ 1. only if the ‘fallbackToPaymentMethodAddressEnabled’ setting is set to true
+
+“Valid” is defined as having ANY field set - country, city, zip, address line 1, or state.
+
+We take the highest-ranked shipping and billing addresses in the above hierarchy. We select only one of those addresses - the shipping address, if available, otherwise the billing address.
+
+Then we geocode it → write it into the “Ship To …” columns of the Transactions CSV → upload that CSV to the Sales Tax API.
+
+Notes:
+
+invoice level 'customer address' field is not always the same as the customer-level 'address' field, it gets locked when the invoice is finalized
+
+Address is considered valid if any of its fields are set (if it has a street, OR a city, OR a zip, OR a country).
+
+**Stripe Customers** (PAYMENT_CUSTOMERS in rootfi)
+
+We follow this hierarchy to pick the first valid address:
+
+- Rootfi SHIPPING address
+- Rootfi BILLING address
+- Payment method billing address, retrieved via the pass-through API
+ - only if the ‘fallbackToPaymentMethodAddressEnabled’ setting is set to true
+
+We select exactly one of these addresses, geocode it, and sync it to the sales tax API.
+
+**Stripe Credit Notes **(PAYMENT_CREDIT_NOTES in rootfi)
+
+We follow this hierarchy to pick the first valid address:
+
+- Rootfi SHIPPING address
+- Rootfi BILLING address
+- Payment method billing address, retrieved via the pass-through API
+ - only if the ‘fallbackToPaymentMethodAddressEnabled’ setting is set to true
+
+We select exactly one of these addresses, geocode it, and sync it to the sales tax API.
diff --git a/integrations/guidelines/existing-integration-behaviors/woocommerce.mdx b/integrations/guidelines/existing-integration-behaviors/woocommerce.mdx
new file mode 100644
index 000000000..3f58cc736
--- /dev/null
+++ b/integrations/guidelines/existing-integration-behaviors/woocommerce.mdx
@@ -0,0 +1,44 @@
+---
+title: 'WooCommerce'
+description: 'WooCommerce integration behaviors'
+---
+
+WooCommerce supports both calculations and sync.
+
+WooCommerce calculations are not implemented in the commenda logical backend, we built a plugin that each customer needs to install.
+
+WooCommerce sync is a work in progress, not launched yet.
+
+## Sync:
+
+**Transactions**: ECOMMERCE_ORDERS
+
+We extract the order-level shipping and billing addresses, if not null, and pass them along.
+
+If either one is missing, we retrieve the customer from the Rootfi pass-through API.
+
+If the order-level shipping address is missing and the customer has a shipping address, we pass along the customer-level shipping address instead.
+
+If the order-level billing address is missing and the customer has a billing address, we pass along the customer-level billing address instead.
+
+Finally, we pick the available shipping address, or the billing address if there is none.
+
+**Customers**: ECOMMERCE_CUSTOMERS
+
+We record the shipping and billing addresses on the contact, synced through Rootfi.
+
+## Calculations:
+
+The WooCommerce plugin has two code paths to calculate tax, one based on an in-progress cart (Before the order is complete) and the other based on an order.
+
+The two paths have different behaviors.
+
+The in-progress cart path calculates on the cart-level shipping address, if available, arbitrarily choosing the first shipping destination if there is more than one. Otherwise, it falls back to the customer-level billing address:
+
+Cart/checkout calculation (commenda_cart_tax)
+
+- Primary: first shipping package destination: WC()->shipping->get_packages()[0]['destination']
+- Fallback: customer billing fields from WC()->customer
+
+The order path calculates on the order-level shipping address, and will fall back to the customer shipping address if not set. Customer-level fields are ignored.
+
diff --git a/integrations/guidelines/existing-integration-behaviors/xero.mdx b/integrations/guidelines/existing-integration-behaviors/xero.mdx
new file mode 100644
index 000000000..be9271f3e
--- /dev/null
+++ b/integrations/guidelines/existing-integration-behaviors/xero.mdx
@@ -0,0 +1,36 @@
+---
+title: 'Xero'
+description: 'Xero integration behaviors'
+---
+
+Xero supports both calculations and sync.
+
+We think Xero only has customer-level addresses, but Aryan thinks that Avalara has invoice-level address support for Xero. We need some more research here.
+
+There are two different code paths for Xero address resolution, one for calculations and one for sync. These should be merged so the implementations don’t diverge, which would lead to bugs that get caught when our back calcs don’t match forward calcs.
+
+## Sync:
+
+**Xero payment vouchers:** (INVOICES / INVOICE_CREDIT_NOTES / CASH_REFUNDS in Rootfi):
+
+Fetch the linked contact using the Rootfi passthrough API, and then check for:
+
+- Raw data STREET address → treated as shipping
+- Raw data POBOX address → treated as billing
+
+We choose the shipping address if it’s non-null, and the billing address if the shipping address is null.
+
+**Xero contacts **(CONTACTS in rootfi):
+
+Read contact-level addresses from Raw Data (bypassing a Rootfi bug that switches STREET and POBOX addresses), and follow the following hierarchy:
+
+- Raw data STREET address → treated as shipping
+- Raw data POBOX address → treated as billing
+
+We choose the shipping address if it’s non-null, and the billing address if the shipping address is null.
+
+## Calculations:
+
+This pipeline is mostly similar with one exception: It check whether any of the fields are set on the shipping address, and if not it falls back to the billing address.
+
+Like on Stripe invoices, an address is considered valid if any of its fields are set (if it has a street, OR a city, OR a zip, OR a country).
diff --git a/integrations/guidelines/existing-integration-behaviors/zoho.mdx b/integrations/guidelines/existing-integration-behaviors/zoho.mdx
new file mode 100644
index 000000000..e9d9fe721
--- /dev/null
+++ b/integrations/guidelines/existing-integration-behaviors/zoho.mdx
@@ -0,0 +1,24 @@
+---
+title: 'Zoho'
+description: 'Zoho integration behaviors'
+---
+
+Zoho supports both calculations and sync. The address implementation looks identical to Quickbooks.
+
+There are two different code paths for Zoho address resolution, one for calculations and one for sync. They are currently implemented differently in a way that may be error-prone, and this should be reviewed.
+
+## Sync:
+
+**Zoho Transactions**: INVOICES, INVOICE_CREDIT_NOTES, CASH_REFUNDS
+
+We use addresses directly from Rootfi. We use the invoice-level shipping address if present, if it is null, we fall back to the invoice-level billing address. We do not do any validation checks on the shipping address, so if it’s non-null but incomplete we will still propagate it forwards.
+
+ Customer-level addresses are not considered.
+
+**Zoho Contacts: **CONTACTS
+
+We record the shipping and billing addresses on the contact, synced through Rootfi.
+
+## Calculations:
+
+We retrieve the transaction from rootfi's passthrough API and then only consider the shipping address, calculating based on it no matter what.
diff --git a/integrations/guidelines/fallback-address-resolver.mdx b/integrations/guidelines/fallback-address-resolver.mdx
new file mode 100644
index 000000000..620c4ec3c
--- /dev/null
+++ b/integrations/guidelines/fallback-address-resolver.mdx
@@ -0,0 +1,71 @@
+---
+title: 'Fallback Address Resolver'
+description: 'Fallback address resolver documentation'
+---
+
+## __Enabling fallback Address resolver on Commenda Logical backend__
+
+### __Current Behavior__
+
+For each transaction, the system selects __only the first available address__ based on the defined hierarchy and sends it for geocoding.
+If geocoding fails to resolve this address, the __entire transaction fails__ and is moved to the __holding pen__, even if other valid addresses are available for the transaction.
+
+### __Impact__
+
+- Transactions get blocked unnecessarily
+
+- Valid fallback addresses are ignored
+
+- Increased manual intervention due to holding-pen accumulation
+
+## __Expected Behavior__
+
+For each transaction, the system should __attempt calling a geocoding api using all available addresses in hierarchical order__, instead of failing immediately on the first failure.
+
+### __Address Resolution Logic__
+
+1. Identify all available addresses for the transaction.
+
+2. Sort them according to the predefined hierarchy
+
+ - Example hierarchy:
+ __Customer Shipping > Invoice Billing > Customer Billing > Card Information
+__
+3. Attempt geocoding using the highest-priority address.
+
+4. If geocoding fails:
+
+ - __Do not fail the transaction
+__
+ - Automatically attempt the __next address in the hierarchy
+__
+5. Mark the transaction as failed __only if all available addresses fail to resolve__.
+
+## __Example__
+
+__Available addresses:__
+
+- Customer Shipping
+
+- Invoice Billing
+
+__Hierarchy:
+__ Customer Shipping > Invoice Billing
+
+__Flow:__
+
+1. Attempt geocoding with Customer Shipping address
+
+2. If it fails, retry using Invoice Billing address
+
+3. Transaction proceeds successfully if Invoice Billing resolves
+
+4. Transaction moves to holding pen __only if both addresses fail__
+
+## __Acceptance Criteria__
+
+- System iterates through all available addresses in hierarchical order
+
+- Transaction does __not__ fail on the first geocoding failure
+
+- Transaction is sent to holding pen only when __no address resolves successfully__
diff --git a/integrations/guidelines/integration-checklist/calculation.mdx b/integrations/guidelines/integration-checklist/calculation.mdx
new file mode 100644
index 000000000..b011ec9c9
--- /dev/null
+++ b/integrations/guidelines/integration-checklist/calculation.mdx
@@ -0,0 +1,75 @@
+---
+title: 'Calculation'
+description: 'Calculation behavior checklist for integrations'
+---
+
+__Calculation tab__
+
+This tab will be used as the base source of truth for all the calculations behaviors for the supported integrations.
+
+1. Shipping (how to store shipping related taxes)
+2. Handling (If it exists as a specific field), and how tax calculated on that will be stored.
+3. Discount
+ 1. Calculating taxes when discount on line item
+ 2. Calculating taxes on Pro-rata when discount on line item level
+ 3. Tax calculation when discounts are applicable on line item as well as on invoice level
+4. Vouchers
+ 1. Type of vouchers supported for calculation
+ 2. Refund vouchers
+ 3. Partial vouchers
+5. What’s the trigger for calculating the taxes on the invoice in the real time
+6. If an invoice is locked, will the tax amount be updated when updating the invoice, if not what we are flagging to the client and how
+7. GL Account
+ 1. Tax amount should be mapped with the appropriate tax authority
+ 2. Tax amount should be mapped with the appropriate tax classes in case of marketplace.
+8. Overwriting of Taxes
+ 1. Storing taxes in ERP (separate line item, on the line item, etc.)
+ 2. Negative amount handling
+ 3. Disable/enable tax calculation should work
+ 4. Adding the same SKU as different line items with different values should display different taxes at the line item level.
+ 5. Check if the calculation output is getting updated based on PTC.
+ 6. Tax calculated can get rounded by the ERP (like Netsuite), if it happens document it.
+ 7. Displaying Error message
+ 8. Updating a locked invoice: Behavior and how to reflect the error
+ 9. Wrong address has been passed or an empty string has been passed: Behavior and error message
+ 10. Which time zone Calculation start date is following
+ 11. Set the calculation start date as 1st january, create an invoice for 2nd jan, the tax should be calculated. Then update the calculation start date to 5st January, then we update the invoice we created on 2nd, what should happen in this case?
+ 12. What is the trigger to initiate the calculation on the invoices also what’s an average time for it to calculate
+ 13. The action if we manually override the tax rate or amount in the ERP
+ 14. How can a customer mark a line item as exempted. Same for marking the entire transaction as exempted.
+
+ __For example:__ In NetSuite, TRX asked us to give a checkbox with, "mark as exempted", which when clicked, the tax rate for every line item should have 0% tax rate. Customers could also ask for a special tax code they can use to mark a line item as non taxable for a particular transaction.
+
+ 15. Tax Calculation on the Fees and which PTC should we link the fees to
+ 16. Calculation of taxes should be triggered irrespective of the administrative access of ERP
+
+9. **Address**
+
+ a. **Address fallback hierarchy**
+
+
+ The system follows this hierarchy when resolving addresses for calculations:
+
+ **1.** Invoice Shipping
+ **↓**
+ **2.** Customer Shipping (default)
+ **↓**
+ **3.** Customer Shipping (any)
+ **↓**
+ **4.** Invoice Billing
+ **↓**
+ **5.** Customer Billing (default)
+ **↓**
+ **6.** Customer Billing (any)
+ **↓**
+ **7.** Payment Metadata address
+ **↓**
+ **8.** IP Address
+
+ The system selects the first available address in this order.
+
+
+10. **Customer Exemption**
+ 1. If applied, Pass the reason "Customer is exempted"
+ 2. Exemption work through our ECM portal and not the Exemption checkbox on the ERP portal (Flag it to customer as well)
+11. How to identify and disable calculation of taxes on the marketplace sales.
diff --git a/integrations/guidelines/integration-checklist/general-behaviors.mdx b/integrations/guidelines/integration-checklist/general-behaviors.mdx
new file mode 100644
index 000000000..357df6fa1
--- /dev/null
+++ b/integrations/guidelines/integration-checklist/general-behaviors.mdx
@@ -0,0 +1,23 @@
+---
+title: 'General Behaviors'
+description: 'General behavior checklist for integrations'
+---
+
+__General Behavior__
+
+1. Testing should be enabled on:
+ 1. Staging
+ 2. Demo
+ 3. Dev
+ 4. Prod
+2. Documentation for setting up the integration/plugin:
+ 1. Sync
+ 2. Calculation
+3. Integration Connection Details:
+ 1. How long this connection will be valid for
+ 2. How often the sync runs
+ 3. Does Incremental sync works
+ 4. Any rate limit or exception we should be aware of
+ 5. Does the Sync status work
+ 6. Which integration versions we support (Xero US, XERO UK)
+
diff --git a/integrations/guidelines/integration-checklist/syncing.mdx b/integrations/guidelines/integration-checklist/syncing.mdx
new file mode 100644
index 000000000..e5ba67b19
--- /dev/null
+++ b/integrations/guidelines/integration-checklist/syncing.mdx
@@ -0,0 +1,83 @@
+---
+title: 'Syncing'
+description: 'Syncing behavior checklist for integrations'
+---
+
+__Syncing__
+
+This tab provides the checklist required for checking all the syncing behavior for this integration.
+
+1. Shipping
+ 1. Syncing on Line item/Invoice level
+ 2. Syncing the taxes collected on the Shipping Value
+2. Handling
+ 1. How to sync handling amounts
+ 2. How to sync tax calculated on that
+3. Discounts
+ 1. Line item level discounts
+ 2. Invoice level discounts
+4. Vouchers
+ 1. Type of vouchers supported for syncing
+ 2. Refund vouchers
+ 3. Partial vouchers
+5. What’s the trigger for syncing the invoice (Like the status: like we don’t sync DRAFT invoices)
+6. Order status updated for an invoice (Order status to Refund, define the behavior)
+ 1. LOCKED: Add a different Refund invoice
+ 2. UNLOCKED: Update the same invoice
+7. Mapping on Commenda
+ 1. If we are able to map all the types of Invoices: One-time purchases, Recurring, etc.
+ 2. Is it possible to pass 0 quantity with positive amount and if yes, how to sync it
+ 3. How does the One-time good and Subscription items get synced
+ 4. Also allowing the sync for card address or IP address, if it’s a marketplace to get enough fallbacks to support
+ 5. Invoice number on Commenda should be same as Document ID on ERP
+ 6. What should be mapped if SKUs not available in that ERP
+ 7. Negative amount handling
+ 8. Syncing behavior for the Fees added and the tax calculated on it
+8. **Address**
+
+ a. **Address fallback hierarchy**
+
+
+
+ The system follows this hierarchy when resolving addresses for syncing:
+
+ **1.** Invoice Shipping
+ **↓**
+ **2.** Customer Shipping (default)
+ **↓**
+ **3.** Customer Shipping (any)
+ **↓**
+ **4.** Invoice Billing
+ **↓**
+ **5.** Customer Billing (default)
+ **↓**
+ **6.** Customer Billing (any)
+ **↓**
+ **7.** Payment Metadata address
+ **↓**
+ **8.** IP Address
+
+ The system selects the first available address in this order.
+
+
+ b. **Updating the address on ERP**
+
+ i. Behavior when the invoice is unlocked (Recorded):
+
+ - It should update the address
+ - It should take it out of the Holding Pen
+
+ ii. Behavior when the invoice is Locked
+
+ c. **If the GeoEncoding fails to parse the address**, pass the next possible address
+
+ d. **Some softwares** (like NetSuite and Stripe) will always populate the country code on the customer level by default. This will look like the address is actually populated on the code level but it isn't. Make sure we parse the next possible address if this address is not complete. Check [netsuite.handler.ts](http://netsuite.handler.ts) for more information around this.
+
+9. Product
+ 1. Handling behaviors where SKUs are absent especially accounting softwares
+ 2. SKU updated on the invoice in ERP should be synced in Commenda
+10. How to identify and handle Marketplace sales.
+11. Deletion of Invoices:
+ 1. When it is not Locked
+ 2. When it is Locked
+
diff --git a/integrations/guidelines/overview.mdx b/integrations/guidelines/overview.mdx
new file mode 100644
index 000000000..8ad5d8ad8
--- /dev/null
+++ b/integrations/guidelines/overview.mdx
@@ -0,0 +1,57 @@
+---
+title: 'Guide'
+description: 'Hub for integration testing, behaviors, and address/tax logic.'
+---
+
+## Integration Guidelines Guide
+
+Use this hub to jump into the most important integration docs: checklists, per‑integration behaviors, and address/tax logic.
+
+
+
+ Baseline checklist to validate whether an integration is working end‑to‑end.
+ Start here when testing a new or updated integration.
+
+
+
+ Stripe, Shopify, Xero, NetSuite, QuickBooks, and Zoho behavior notes:
+ how we sync, calculate, and resolve addresses today.
+
+
+
+ How the logical backend walks through fallback addresses and how to
+ enable or adjust that behavior.
+
+
+
+ The authoritative address hierarchy used for sales tax decisions
+ across integrations.
+
+
+
+ How shipping charges and their taxes are calculated, stored, and
+ synced across systems.
+
+
+
+
diff --git a/integrations/guidelines/sales-tax-address-resolution-hierarchy.mdx b/integrations/guidelines/sales-tax-address-resolution-hierarchy.mdx
new file mode 100644
index 000000000..d8c4ce3a2
--- /dev/null
+++ b/integrations/guidelines/sales-tax-address-resolution-hierarchy.mdx
@@ -0,0 +1,61 @@
+---
+title: 'Sales Tax Address Resolution Hierarchy'
+description: 'Sales tax address resolution hierarchy'
+---
+
+# Sales Tax Address Resolution Hierarchy
+
+## Purpose
+
+This document defines the __hierarchy for address resolution__ used by the Sales Tax Engine when determining the applicable tax jurisdiction for a transaction.
+
+The hierarchy ensures: - Deterministic and auditable address selection - Consistent behavior across integrations - Graceful fallback when preferred address data is unavailable
+
+The engine __must evaluate addresses strictly in the order defined below__ and select the __first available address__ encountered. If an address at a given level is unavailable or invalid, the engine proceeds to the next level.
+
+## Address Resolution Order (Highest → Lowest Priority)
+
+### 1. Invoice Shipping Address
+
+- Explicit shipping address provided at invoice level
+- Considered the most accurate representation of where goods/services are delivered
+
+### 2. Customer Shipping Address (Default or Single)
+
+- Use the customer’s __default shipping address if available__
+- If no default is set, but __only one shipping address exists__, use that address
+- If multiple shipping addresses exist and no default is defined, skip this level
+
+### 3. Invoice Billing Address
+
+- Billing address explicitly attached to the invoice
+
+### 4. Customer Shipping Address (Any – Arbitrary)
+
+- Select __any available shipping address__
+- Used only when no invoice-level or default shipping address is available but there are few shipping address associated with the customer, just take the first one.
+
+### 5. Customer Billing Address (Default or Single)
+
+- Use the customer’s __default billing address__
+- If no default is set, but __only one billing address exists__, use that address
+- If multiple billing addresses exist and no default is defined, skip this level
+
+### 6. Payment Metadata Address
+
+__Source:__ Payment provider metadata
+
+- Address obtained from payment instruments (e.g., card billing address)
+- Considered lower confidence due to potential mismatch with delivery location
+
+### 7. Customer Billing Address (Any – Arbitrary)
+
+__Source:__ Customer profile
+
+- Select __any available billing address __associated with the customer.
+
+### 8. IP Address (Geolocation)
+
+- Infer location via IP-based geolocation
+- Lowest confidence signal
+- Should be used __only when no explicit address data is availab__
diff --git a/integrations/guidelines/shipping-tax-calculations.mdx b/integrations/guidelines/shipping-tax-calculations.mdx
new file mode 100644
index 000000000..d79d32f6f
--- /dev/null
+++ b/integrations/guidelines/shipping-tax-calculations.mdx
@@ -0,0 +1,85 @@
+---
+title: 'Shipping Tax Calculations'
+description: 'Shipping tax calculations'
+---
+
+__Assumptions:__
+
+Shipping should not be done by the company itself. If the company is shipping the products themselves, then the tax applicability rules are very different. We will assume all the shipping is done through a common carrier.
+
+__Acceptable behaviors:__
+
+- Shipping can be on the line item level
+- Shipping can be on the invoice level
+
+__Unacceptable behaviors:__
+
+- Shipping can’t be on both line item and invoice level
+
+__Calculation behaviors:__
+
+1. __If the shipping is on the invoice level__
+ 1. In such cases, the base rates 3* of the jurisdictions are applied to the shipping line item. Below are the exact steps.
+ 2. Treat shipping as a separate line item. This means while passing it to the sales tax backend, you will have to pass this as a separate line item with tax code “SRV_SHIPPING”. (Explicitly mentioning that we shouldn’t distribute this to every line item, that is wrong).
+ 3. First calculate taxable amounts for every other line item in the transaction. This should give you the total taxable amount and total non taxable amount on the invoice level.
+ 4. Check which product rules apply for `SRV_SHIPPING`. There are two possibilities
+ 1. EXEMPT : In which case the tax on this line item will be zero.
+ 2. PROPORTIONAL: There are a few steps to calculate proportional tax. Look below
+ 3. No product rule is present
+ 5. Calculate proportional tax on line item:
+ 1. Figure out the base adjustment factor. This is the “taxable amount / total amount”.
+ 2. Adjust the tax base for shipping. Adjusted base is “base adjustment factor * amount”.
+ 3. Calculate the tax. For this you can now pass the amount to the calculateTaxOnLineItem function with applyProductRules = false and applyTransactionRules = false. This way you will prevent reapplying the “EXEMPTION” and “PROPORTIONAL” rules as they are already applied.
+ 4. The resultant effective tax rate is the tax we should calculate on this shipping line item (invoice level shipping).
+ 6. If no product rule is present, then shipping is taxable as a normal line item.
+2. __If the shipping is on the line item level__
+ 1. First we will have to check what are the product rules applied on SRV_SHIPPING for this state. There are three possibilities
+ 1. EXEMPT
+ 2. PROPORTIONAL
+ 3. TAXABLE (This is when product rules are missing)
+ 2. EXEMPT : This is the easiest case. No matter if the line item is taxable or not, the shipping tax amount will be zero.
+ 3. PROPORTIONAL: In this case, we simply use the product rate to calculate the shipping tax amount.
+ 4. TAXABLE: In this case, there are two scenarios
+ 1. If the product rate is zero > Then use the base rates to calculate the shipping tax amount.
+ 2. If the product rates are non zero > Use the product rates to calculate the shipping tax amount.
+ 5. Calculate the tax on the line item without considering shipping. This should also give you the base rates for all the jurisdictions applicable on this line item.
+ 6. Add the shipping tax to the line item tax and then return the totals.
+ 1. NOTE: Now the tax rates will seem inflated. This is fine from a reporting perspective (Just confirmed this with Phani that none of the states asks for tax collected on shipping explicitly) .
+ 2. But we won’t be able to give accurate reasoning for this to the customer. It will just look like our rates are wrong. But maybe this is fine? The alternative is that just like “tax_type” we add another field on the tax breakdowns to reflect the extra charges collected by our engine.
+ 3. The third option is to give a separate column called “shipping_tax_amount” on the API response from the calculation engine.
+
+__Integration behaviors:__
+
+1. __Allows invoice level shipping. __
+ 1. Allows invoice level shipping tax amount
+ 1. This is the ideal case. You will pass SRV_SHIPPING as a separate line item. The tax engine will explicitly tell the tax amount on this line item. That tax amount will be applied on the invoice level shipping tax amount.
+ 2. Doesn’t allow invoice level shipping tax amount
+ 1. This is the common case. In such a case, we will pass SRV_SHIPPING as a separate line item on which the tax amount will be returned by the tax engine. Now there are two approaches
+ 1. Take the shipping tax amount and add it as a separate line item on the invoice. Label it as a tax item so we don’t calculate tax on it during re processing of the invoice. (This is a bad approach).
+ 2. Take the shipping tax amount and distribute it proportionally to all the physical positive non tax line items 1*. If no physical goods are found, then proportionally distribute the shipping tax amount among all the positive line items.
+ 1. Weird weird scenario : All the line items are negative. This shouldn’t happen.
+2. __Allows line item level shipping__
+ 1. Allows line item level shipping tax amount
+ 1. This case is very rare from an accounting software perspective. But right now the tax engine will give the shipping tax amount included in the line item tax amount. Right now we don’t support it.
+ 1. NEW FEATURE: Explicitly return the calculated shipping tax amount from the calculation engine.
+ 2. Doesn’t allow line item level shipping tax amount
+ 1. This is the real world case. This will work perfectly. The shipping tax amount will come included in the line item tax amount and that will be reflected on the only “tax amount” field available on the line item.
+
+__Shipping storage behavior on sales tax (integration -> logical backend -> sales tax):__
+
+1. __Invoice level shipping__
+
+If the shipping amount is on the invoice level we will create a new line item on the sales tax backend. This line item will have a tax code as “SRV_SHIPPING”. The amounts and taxes will act as they do on a normal line item.
+
+1. __Line item level shipping__
+
+If the shipping amount is on the line item itself, we can pass the shipping amount simply to the sales tax backend. Right now the shipping will be available as an explicit field on the line item. Reminder that based on the current behavior, sub total is “unit price * quantity + shipping - discount”. And total is “sub total + tax collected”.
+
+__Glossary:__
+
+1. Non-tax line items are all the line items except a line item that reflects “tax”. In quickbooks tax amount is added as a separate line item with certain code.
+2. After looking at years of TRX data, we barely find invoices where the overall invoice is positive and individual line items are negative. In GAP accountants prefer to create a separate credit invoice to reflect negative line items.
+
+__Things to think about:__
+
+1. If a line item has a shipping amount, Avalara will link a second record (probably a record called Taxes) that is linked to the original line item. This Tax record contains the tax type, in this case it will be shipping. But I think the original tax that is applicable on the line item level is also stored as a separate record on this Tax table. That means, the tax table will look like [{taxOn: “shipping”, taxAmount: $25, taxType: “sales_tax”, taxAuthority: “United States”}]
diff --git a/integrations/netsuite/overview.mdx b/integrations/netsuite/overview.mdx
new file mode 100644
index 000000000..85a27721e
--- /dev/null
+++ b/integrations/netsuite/overview.mdx
@@ -0,0 +1,9 @@
+---
+title: 'NetSuite'
+description: 'NetSuite integration'
+---
+
+## Overview
+
+NetSuite integration documentation coming soon.
+
diff --git a/integrations/quickbooks/overview.mdx b/integrations/quickbooks/overview.mdx
new file mode 100644
index 000000000..d5c109bd9
--- /dev/null
+++ b/integrations/quickbooks/overview.mdx
@@ -0,0 +1,9 @@
+---
+title: 'QuickBooks'
+description: 'QuickBooks integration'
+---
+
+## Overview
+
+QuickBooks integration documentation coming soon.
+
diff --git a/integrations/shopify/overview.mdx b/integrations/shopify/overview.mdx
new file mode 100644
index 000000000..b7f971ed1
--- /dev/null
+++ b/integrations/shopify/overview.mdx
@@ -0,0 +1,9 @@
+---
+title: 'Shopify'
+description: 'Shopify integration'
+---
+
+## Overview
+
+Shopify integration documentation coming soon.
+
diff --git a/integrations/stripe/overview.mdx b/integrations/stripe/overview.mdx
new file mode 100644
index 000000000..45c25a8af
--- /dev/null
+++ b/integrations/stripe/overview.mdx
@@ -0,0 +1,9 @@
+---
+title: 'Stripe'
+description: 'Stripe integration'
+---
+
+## Overview
+
+Stripe integration documentation coming soon.
+
diff --git a/integrations/supported-integrations.mdx b/integrations/supported-integrations.mdx
new file mode 100644
index 000000000..441b4d497
--- /dev/null
+++ b/integrations/supported-integrations.mdx
@@ -0,0 +1,17 @@
+---
+title: 'Supported Integrations'
+description: 'Overview of integrations supported by Commenda'
+---
+
+## Integrations Supported by Commenda
+
+| Integration | Syncing | Calculation | Notes |
+|---------------|-------------|---------------|-------|
+| **Stripe** | Supported | Not supported | — |
+| **Xero** | Supported | Supported | Xero UK |
+| **QuickBooks** | Supported | Supported | — |
+| **Zoho Books** | Supported | Supported | Calculation requires manual webhook setup |
+| **Shopify** | Supported | Not supported | — |
+| **NetSuite** | Supported | Supported | Calculation requires plugin installation |
+| **WooCommerce**| Supported | Supported | Plugin supports both syncing and calculation |
+
diff --git a/integrations/woocommerce/setup.mdx b/integrations/woocommerce/setup.mdx
new file mode 100644
index 000000000..f9c7701be
--- /dev/null
+++ b/integrations/woocommerce/setup.mdx
@@ -0,0 +1,432 @@
+---
+title: "WooCommerce"
+description: "Learn how Rootfi integrates with WooCommerce to fetch e-commerce data"
+---
+
+## Overview
+
+Rootfi's WooCommerce integration enables you to seamlessly fetch and synchronize e-commerce data from WooCommerce stores. This integration provides access to orders, products, customers, inventory, and other critical business data.
+
+## How it works
+
+The WooCommerce integration connects to your WooCommerce store using the WooCommerce REST API. Once authenticated, Rootfi can fetch data from your store and keep it synchronized in real-time through webhooks.
+
+### Architecture
+
+1. **Authentication**: Secure connection using WooCommerce API keys
+2. **Data fetching**: Periodic synchronization of store data via REST API
+3. **Real-time updates**: Webhook notifications for immediate data changes
+4. **Data normalization**: Standardized data format across all integrations
+
+## Authentication
+
+### Prerequisites
+
+- WooCommerce store with REST API enabled
+- Admin access to generate API credentials
+- HTTPS enabled on your store (required for API access)
+
+### Connection process
+
+1. Navigate to your WooCommerce admin dashboard
+2. Go to **WooCommerce** \> **Settings** \> **Advanced** \> **REST API**
+3. Click **Add key** to generate new API credentials
+4. Set the following:
+ - **Description**: Rootfi Integration
+ - **User**: Select an admin user
+ - **Permissions**: Read/Write
+5. Copy the generated **Consumer Key** and **Consumer Secret**
+6. In Rootfi, provide:
+ - Store URL
+ - Consumer Key
+ - Consumer Secret
+7. Test the connection to verify access
+
+### Security considerations
+
+- API keys should be stored securely and never exposed in client-side code
+- Use HTTPS for all API communications
+- Regularly rotate API credentials
+- Monitor API access logs for suspicious activity
+
+## Data entities
+
+Rootfi fetches the following data entities from WooCommerce:
+
+### Orders
+
+Complete order information including line items, customer details, and fulfillment status.
+
+**Key fields:**
+
+- `id` - Unique order identifier
+- `order_number` - Human-readable order number
+- `status` - Order status (pending, processing, completed, etc.)
+- `date_created` - Order creation timestamp
+- `date_modified` - Last modification timestamp
+- `total` - Order total amount
+- `subtotal` - Subtotal before taxes and shipping
+- `total_tax` - Total tax amount
+- `shipping_total` - Shipping cost
+- `discount_total` - Total discount amount
+- `currency` - Order currency code
+- `customer_id` - Associated customer ID
+- `billing` - Billing address object
+- `shipping` - Shipping address object
+- `payment_method` - Payment method used
+- `payment_method_title` - Payment method display name
+- `line_items` - Array of ordered products
+- `shipping_lines` - Shipping method details
+- `tax_lines` - Tax breakdown
+- `fee_lines` - Additional fees
+- `coupon_lines` - Applied coupons
+- `refunds` - Refund information
+
+### Products
+
+Product catalog including variations, pricing, and inventory.
+
+**Key fields:**
+
+- `id` - Unique product identifier
+- `name` - Product name
+- `slug` - URL-friendly product identifier
+- `type` - Product type (simple, variable, grouped, external)
+- `status` - Publication status (publish, draft, pending)
+- `sku` - Stock keeping unit
+- `price` - Current price
+- `regular_price` - Regular price before discounts
+- `sale_price` - Sale price if on sale
+- `date_on_sale_from` - Sale start date
+- `date_on_sale_to` - Sale end date
+- `stock_quantity` - Available stock count
+- `stock_status` - Stock status (instock, outofstock, onbackorder)
+- `manage_stock` - Whether stock is managed
+- `categories` - Product categories
+- `tags` - Product tags
+- `images` - Product images array
+- `attributes` - Product attributes
+- `variations` - Product variations (for variable products)
+- `weight` - Product weight
+- `dimensions` - Product dimensions (length, width, height)
+- `description` - Full product description
+- `short_description` - Short product description
+
+### Customers
+
+Customer profiles and contact information.
+
+**Key fields:**
+
+- `id` - Unique customer identifier
+- `email` - Customer email address
+- `first_name` - Customer first name
+- `last_name` - Customer last name
+- `username` - Customer username
+- `date_created` - Account creation date
+- `date_modified` - Last modification date
+- `billing` - Billing address object
+ - `first_name`
+ - `last_name`
+ - `company`
+ - `address_1`
+ - `address_2`
+ - `city`
+ - `state`
+ - `postcode`
+ - `country`
+ - `email`
+ - `phone`
+- `shipping` - Shipping address object
+ - `first_name`
+ - `last_name`
+ - `company`
+ - `address_1`
+ - `address_2`
+ - `city`
+ - `state`
+ - `postcode`
+ - `country`
+- `orders_count` - Total number of orders
+- `total_spent` - Total amount spent
+- `avatar_url` - Customer avatar URL
+
+### Inventory
+
+Stock levels and inventory management data.
+
+**Key fields:**
+
+- `product_id` - Associated product ID
+- `variation_id` - Variation ID (if applicable)
+- `sku` - Stock keeping unit
+- `stock_quantity` - Current stock level
+- `stock_status` - Stock availability status
+- `manage_stock` - Whether stock management is enabled
+- `backorders` - Backorder settings (no, notify, yes)
+- `low_stock_amount` - Low stock threshold
+
+### Categories
+
+Product categorization and taxonomy.
+
+**Key fields:**
+
+- `id` - Unique category identifier
+- `name` - Category name
+- `slug` - URL-friendly identifier
+- `parent` - Parent category ID
+- `description` - Category description
+- `display` - Display type
+- `image` - Category image
+- `count` - Number of products in category
+
+### Coupons
+
+Discount codes and promotional offers.
+
+**Key fields:**
+
+- `id` - Unique coupon identifier
+- `code` - Coupon code
+- `amount` - Discount amount
+- `discount_type` - Type of discount (percent, fixed_cart, fixed_product)
+- `description` - Coupon description
+- `date_expires` - Expiration date
+- `usage_count` - Number of times used
+- `usage_limit` - Maximum usage limit
+- `usage_limit_per_user` - Per-user usage limit
+- `individual_use` - Whether coupon can be used with other coupons
+- `product_ids` - Applicable product IDs
+- `excluded_product_ids` - Excluded product IDs
+- `minimum_amount` - Minimum order amount
+- `maximum_amount` - Maximum order amount
+
+### Refunds
+
+Order refund information.
+
+**Key fields:**
+
+- `id` - Unique refund identifier
+- `order_id` - Associated order ID
+- `date_created` - Refund creation date
+- `amount` - Refund amount
+- `reason` - Refund reason
+- `refunded_by` - User who processed refund
+- `line_items` - Refunded line items
+
+### Tax rates
+
+Tax configuration and rates.
+
+**Key fields:**
+
+- `id` - Unique tax rate identifier
+- `country` - Country code
+- `state` - State code
+- `postcode` - Postal code
+- `city` - City name
+- `rate` - Tax rate percentage
+- `name` - Tax rate name
+- `priority` - Tax priority
+- `compound` - Whether tax is compound
+- `shipping` - Whether tax applies to shipping
+- `class` - Tax class
+
+## API endpoints
+
+Rootfi uses the following WooCommerce REST API endpoints:
+
+### Orders
+
+- `GET /wp-json/wc/v3/orders` - List all orders
+- `GET /wp-json/wc/v3/orders/{id}` - Get single order
+- `POST /wp-json/wc/v3/orders` - Create order
+- `PUT /wp-json/wc/v3/orders/{id}` - Update order
+
+### Products
+
+- `GET /wp-json/wc/v3/products` - List all products
+- `GET /wp-json/wc/v3/products/{id}` - Get single product
+- `POST /wp-json/wc/v3/products` - Create product
+- `PUT /wp-json/wc/v3/products/{id}` - Update product
+
+### Customers
+
+- `GET /wp-json/wc/v3/customers` - List all customers
+- `GET /wp-json/wc/v3/customers/{id}` - Get single customer
+- `POST /wp-json/wc/v3/customers` - Create customer
+- `PUT /wp-json/wc/v3/customers/{id}` - Update customer
+
+### Product variations
+
+- `GET /wp-json/wc/v3/products/{product_id}/variations` - List variations
+- `GET /wp-json/wc/v3/products/{product_id}/variations/{id}` - Get variation
+
+### Categories
+
+- `GET /wp-json/wc/v3/products/categories` - List categories
+- `GET /wp-json/wc/v3/products/categories/{id}` - Get category
+
+### Coupons
+
+- `GET /wp-json/wc/v3/coupons` - List coupons
+- `GET /wp-json/wc/v3/coupons/{id}` - Get coupon
+
+### Refunds
+
+- `GET /wp-json/wc/v3/orders/{order_id}/refunds` - List refunds
+- `GET /wp-json/wc/v3/orders/{order_id}/refunds/{id}` - Get refund
+
+### Tax rates
+
+- `GET /wp-json/wc/v3/taxes` - List tax rates
+- `GET /wp-json/wc/v3/taxes/{id}` - Get tax rate
+
+## Webhooks
+
+Rootfi configures webhooks to receive real-time updates from WooCommerce.
+
+### Supported webhook events
+
+**Orders:**
+
+- `order.created` - New order created
+- `order.updated` - Order updated
+- `order.deleted` - Order deleted
+
+**Products:**
+
+- `product.created` - New product created
+- `product.updated` - Product updated
+- `product.deleted` - Product deleted
+
+**Customers:**
+
+- `customer.created` - New customer registered
+- `customer.updated` - Customer profile updated
+- `customer.deleted` - Customer deleted
+
+**Inventory:**
+
+- `product.updated` - Stock level changed (via product update)
+
+### Webhook configuration
+
+Webhooks are automatically configured during the integration setup:
+
+1. Rootfi creates webhook subscriptions via the WooCommerce API
+2. Webhook endpoint: `https://api.rootfi.com/webhooks/woocommerce/{integration_id}`
+3. Webhook secret is generated for signature verification
+4. Events are delivered in real-time as they occur
+
+### Webhook payload
+
+Each webhook includes:
+
+- `event` - Event type
+- `created_at` - Event timestamp
+- `resource` - Resource type (order, product, customer)
+- `data` - Complete resource data
+
+### Webhook security
+
+- All webhooks are signed with HMAC-SHA256
+- Signatures are verified before processing
+- Invalid signatures are rejected
+- Webhook endpoints use HTTPS only
+
+## Data synchronization
+
+### Initial sync
+
+When you first connect a WooCommerce store:
+
+1. Rootfi fetches all historical data
+2. Data is processed in batches to avoid rate limits
+3. Sync progress is tracked and resumable
+4. Typical sync time: 5-30 minutes depending on store size
+
+### Incremental sync
+
+After initial sync:
+
+1. Webhooks provide real-time updates
+2. Periodic polling ensures data consistency
+3. Modified records are detected and updated
+4. Deleted records are marked as inactive
+
+### Rate limits
+
+WooCommerce API rate limits:
+
+- Default: 25 requests per 10 seconds
+- Configurable per store
+- Rootfi automatically handles rate limiting with exponential backoff
+
+## Troubleshooting
+
+### Common issues
+
+**Authentication failed:**
+
+- Verify API credentials are correct
+- Ensure REST API is enabled in WooCommerce settings
+- Check that HTTPS is enabled on your store
+- Confirm the API user has admin permissions
+
+**Missing data:**
+
+- Check that the API user has appropriate permissions
+- Verify the data exists in WooCommerce
+- Review API rate limits and sync status
+- Check webhook delivery logs
+
+**Webhook not receiving updates:**
+
+- Verify webhook is active in WooCommerce settings
+- Check webhook delivery logs in WooCommerce
+- Ensure firewall allows outbound connections
+- Verify webhook URL is accessible
+
+**Sync performance issues:**
+
+- Large product catalogs may take longer to sync
+- Consider increasing API rate limits
+- Check for API errors in logs
+- Monitor server resources
+
+### Support
+
+For additional help:
+
+- Check Rootfi integration logs
+- Review WooCommerce system status
+- Contact Rootfi support with integration ID
+- Provide relevant error messages and timestamps
+
+## Best practices
+
+1. **Regular monitoring**: Check sync status and webhook delivery regularly
+2. **API key rotation**: Rotate API credentials periodically for security
+3. **Test environment**: Test integration changes in staging before production
+4. **Data validation**: Verify critical data after initial sync
+5. **Error handling**: Monitor error logs and set up alerts for failures
+6. **Performance optimization**: Use webhooks for real-time updates instead of frequent polling
+7. **Backup**: Maintain regular backups of your WooCommerce data
+
+## Limitations
+
+- Historical data retention depends on WooCommerce configuration
+- Some custom fields may require additional mapping
+- Third-party plugin data may not be included by default
+- API rate limits may affect sync speed for large stores
+- Webhook delivery is not guaranteed (use polling as backup)
+
+## Next steps
+
+- [Configure data mappings](#)
+- [Set up automated workflows](#)
+- [Monitor integration health](#)
+- [Explore analytics and reporting](#)
\ No newline at end of file
diff --git a/integrations/xero/overview.mdx b/integrations/xero/overview.mdx
new file mode 100644
index 000000000..313837f02
--- /dev/null
+++ b/integrations/xero/overview.mdx
@@ -0,0 +1,9 @@
+---
+title: 'Xero'
+description: 'Xero integration'
+---
+
+## Overview
+
+Xero integration documentation coming soon.
+
diff --git a/integrations/zoho/overview.mdx b/integrations/zoho/overview.mdx
new file mode 100644
index 000000000..bb25a2285
--- /dev/null
+++ b/integrations/zoho/overview.mdx
@@ -0,0 +1,9 @@
+---
+title: 'Zoho'
+description: 'Zoho integration'
+---
+
+## Overview
+
+Zoho integration documentation coming soon.
+
diff --git a/logo/FullLogoLockupBlack.svg b/logo/FullLogoLockupBlack.svg
new file mode 100644
index 000000000..1b3479175
--- /dev/null
+++ b/logo/FullLogoLockupBlack.svg
@@ -0,0 +1,9 @@
+
diff --git a/logo/FullLogoLockupWhite.svg b/logo/FullLogoLockupWhite.svg
new file mode 100644
index 000000000..2214250b2
--- /dev/null
+++ b/logo/FullLogoLockupWhite.svg
@@ -0,0 +1,9 @@
+
diff --git a/logo/dark.svg b/logo/dark.svg
deleted file mode 100644
index 8b343cd6f..000000000
--- a/logo/dark.svg
+++ /dev/null
@@ -1,21 +0,0 @@
-
diff --git a/logo/light.svg b/logo/light.svg
deleted file mode 100644
index 03e62bf1d..000000000
--- a/logo/light.svg
+++ /dev/null
@@ -1,21 +0,0 @@
-
diff --git a/product/indirect-tax/guarantees.mdx b/product/indirect-tax/guarantees.mdx
new file mode 100644
index 000000000..31143ad83
--- /dev/null
+++ b/product/indirect-tax/guarantees.mdx
@@ -0,0 +1,500 @@
+---
+title: 'Service guarantees'
+description: 'Internal reference for accuracy and on-time filing guarantees'
+icon: 'shield-check'
+---
+
+## Overview
+
+Commenda provides two service guarantees for indirect tax services: the **Accuracy Guarantee** and the **On-Time Filing Guarantee**. These guarantees protect customers from financial exposure due to Commenda errors, subject to specific conditions and caps.
+
+Both guarantees are capped at the **Rolling ACV** — the fees the customer paid to Commenda for Services during the twelve (12) months preceding the tax period at issue.
+
+## Accuracy guarantee
+
+### What's covered
+
+If the customer properly configures and uses the Services and Commenda's tax calculation, rate, or taxability determination is inaccurate such that the return is filed incorrectly and a tax authority assesses uncollected sales tax, penalties, or interest (collectively, "Tax Shortfall"), Commenda will reimburse or credit the customer for the Tax Shortfall.
+
+### Coverage cap
+
+Reimbursement is capped at the **Rolling ACV** — the fees the customer paid to Commenda during the twelve (12) months preceding the tax period at issue.
+
+### Process
+
+#### Step 1: Customer receives assessment notice
+
+Customer receives a notice from a tax authority assessing uncollected sales tax, penalties, or interest due to an inaccuracy in Commenda's tax calculation, rate, or taxability determination.
+
+#### Step 2: Customer notifies Commenda (within 14 days)
+
+Customer must notify Commenda in writing within **fourteen (14) days** after receiving the first notice of assessment.
+
+**Required information:**
+- Copy of the assessment notice
+- Tax period(s) affected
+- Jurisdiction(s) involved
+- Amount assessed (tax, penalties, interest)
+- Description of the transactions at issue
+
+**Notification channel:**
+- Email: [support contact]
+- Subject line: "Accuracy Guarantee Claim - [Company Name]"
+- All required documentation attached
+
+#### Step 3: Customer cooperation with investigation
+
+Customer must provide all relevant information and reasonably cooperate with Commenda's investigation and any effort to contest or mitigate the assessment.
+
+**This includes:**
+- Transaction data and records
+- Configuration settings used
+- Communication with tax authority
+- Supporting documentation requested by Commenda
+- Participation in calls or meetings as needed
+- Authorization for Commenda to communicate with tax authority (if needed)
+
+#### Step 4: Commenda investigation
+
+Commenda will:
+- Review the assessment and underlying transactions
+- Verify whether the error was due to Commenda's calculation, rate, or taxability determination
+- Determine if all guarantee conditions are met
+- Assess whether the assessment can be contested or mitigated
+- Calculate the covered amount (up to Rolling ACV cap)
+
+#### Step 5: Resolution
+
+If the guarantee applies, Commenda will:
+- Reimburse the customer for the covered Tax Shortfall, or
+- Apply a credit to the customer's account for the covered amount
+
+**Timeline:** Commenda will make a determination and provide reimbursement or credit within a reasonable timeframe after completing the investigation.
+
+### What's NOT covered
+
+The Accuracy Guarantee does not apply to errors caused by:
+
+#### 1. Customer's incorrect or incomplete data or configurations
+
+**Examples:**
+- Wrong addresses provided
+- Incorrect product taxability mappings
+- Missing or invalid exemption certificates
+- Incorrect nexus settings
+- Wrong customer classifications
+- Incomplete transaction data
+
+**Rationale:** Commenda's calculations are only as accurate as the data provided. Incorrect information or misconfigured systems shift responsibility to the customer.
+
+#### 2. Legal positions or classifications selected by customer
+
+**Examples:**
+- Customer chooses to treat a product as non-taxable when it's actually taxable
+- Customer selects a specific tax treatment based on their legal interpretation
+- Customer decides not to collect tax in a jurisdiction where they have nexus
+- Customer applies an exemption based on their legal position
+
+**Rationale:** When customers make legal or classification decisions, they own the outcome. Commenda provides tools and guidance, but ultimate responsibility for legal positions rests with the customer.
+
+#### 3. Changes in law after the transaction date
+
+**Examples:**
+- Tax rate increases after transaction but before filing
+- New taxability rules enacted retroactively
+- Jurisdiction changes sourcing rules
+- New exemption requirements imposed
+
+**Rationale:** Commenda maintains current tax content but cannot predict or be responsible for retroactive legal changes.
+
+#### 4. Events outside Commenda's reasonable control
+
+**Examples:**
+- Third-party service failures (geocoding, address validation)
+- Force majeure events
+- Customer's system failures affecting data transmission
+- Tax authority system errors
+- Jurisdiction provides incorrect guidance
+
+**Rationale:** Commenda cannot guarantee against events beyond reasonable control.
+
+### Sole and exclusive remedy
+
+The remedies in the Accuracy Guarantee are the customer's sole and exclusive remedies for inaccuracies in tax calculations or content. This means:
+
+- Customer cannot seek additional damages beyond the Rolling ACV cap
+- Customer cannot pursue other legal remedies for covered inaccuracies
+- The guarantee represents the full extent of Commenda's liability for calculation errors
+
+## On-time filing guarantee
+
+### What's covered
+
+If the customer has met all their obligations and Commenda fails to file a sales tax return by its statutory due date solely due to Commenda's error, Commenda will:
+
+1. **Complete and submit the delinquent filing** at no additional charge
+2. **Waive or refund any service fee** for that return
+3. **Reimburse any late-filing penalties and interest** imposed by the tax authority, up to the Rolling ACV cap
+
+### Coverage cap
+
+Reimbursement of penalties and interest is capped at the **Rolling ACV** — the fees the customer paid to Commenda during the twelve (12) months preceding the tax period at issue.
+
+### Process
+
+#### Step 1: Missed deadline discovered
+
+Customer discovers that a return was not filed by its statutory due date, or receives a penalty notice from a tax authority for late filing.
+
+#### Step 2: Customer notifies Commenda (within 10 days)
+
+Customer must notify Commenda within **ten (10) days** of discovering the missed deadline or receiving a penalty notice to qualify for the guarantee.
+
+**Required information:**
+- Jurisdiction and tax type
+- Filing period
+- Statutory due date
+- Date customer discovered the issue or received penalty notice
+- Copy of penalty notice (if applicable)
+
+**Notification channel:**
+- Email: [support contact]
+- Subject line: "On-Time Filing Guarantee Claim - [Company Name]"
+- All required documentation attached
+
+#### Step 3: Commenda investigation
+
+Commenda will:
+- Verify the statutory due date
+- Review the filing timeline and any communications
+- Determine if the late filing was solely due to Commenda's error
+- Verify that the customer met all their obligations
+- Assess whether any exclusions apply
+
+#### Step 4: Resolution
+
+If the guarantee applies, Commenda will:
+1. **Immediately file the delinquent return** (if not already filed)
+2. **Waive or refund the service fee** for that return
+3. **Reimburse the late-filing penalties and interest** (up to Rolling ACV cap)
+
+### Customer obligations
+
+To qualify for the On-Time Filing Guarantee, the customer must have met all obligations:
+
+#### Timely data provision
+
+- Provide complete and accurate transaction data by agreed-upon deadlines
+- Respond to data quality issues or questions promptly
+- Ensure data feeds or integrations are functioning properly
+
+#### Sufficient funds
+
+- Maintain sufficient funds in account for tax remittance
+- Provide remittance authorization in advance of due dates
+- Respond to remittance issues promptly
+
+#### Required tax accounts
+
+- Maintain active tax registration accounts in all required jurisdictions
+- Provide Commenda with current login credentials or filing authorization
+- Notify Commenda of any account status changes
+
+#### Timely approvals
+
+- Review and approve returns by agreed-upon deadlines
+- Respond to questions or issues that require customer input
+- Provide necessary documentation when requested
+
+#### Accurate configuration
+
+- Maintain accurate nexus settings
+- Keep product taxability mappings current
+- Update exemption certificates as needed
+
+### What's NOT covered
+
+The On-Time Filing Guarantee does not apply to late filings caused by:
+
+#### 1. Customer's delayed or inaccurate data
+
+**Examples:**
+- Transaction data provided after the deadline
+- Incomplete or incorrect transaction data requiring correction
+- Data quality issues that delay processing
+- Integration failures on customer's side
+
+**Rationale:** Commenda cannot file returns without complete, accurate data. Late data provision shifts responsibility to the customer.
+
+#### 2. Insufficient funds
+
+**Examples:**
+- Insufficient balance for tax remittance
+- Remittance authorization not provided
+- Remittance method declined or failed
+- Customer delays remittance approval
+
+**Rationale:** Returns cannot be filed without remittance. Ensuring sufficient funds is the customer's responsibility.
+
+#### 3. Failure to maintain required tax accounts
+
+**Examples:**
+- Tax registration account suspended or closed
+- Login credentials expired or invalid
+- Filing authorization revoked or expired
+- Account locked due to prior issues
+
+**Rationale:** Commenda cannot file to accounts that are not active and accessible.
+
+#### 4. Events outside Commenda's reasonable control
+
+**Examples:**
+- Tax authority system outages on filing deadline
+- Force majeure events
+- Third-party service failures
+- Jurisdiction changes filing requirements without notice
+
+**Rationale:** Commenda cannot guarantee against events beyond reasonable control.
+
+#### 5. Customer delays in approvals or responses
+
+**Examples:**
+- Return approval delayed past internal deadline
+- Questions or issues not addressed timely
+- Required documentation not provided
+- Customer unavailable during critical filing window
+
+**Rationale:** Filing deadlines require timely customer participation. Delays on the customer's end shift responsibility to them.
+
+## Guarantee comparison
+
+| Feature | Accuracy guarantee | On-time filing guarantee |
+|---------|-------------------|-------------------------|
+| **What's covered** | Tax Shortfall from inaccurate calculations | Late-filing penalties and interest |
+| **Coverage cap** | Rolling ACV | Rolling ACV |
+| **Notification deadline** | 14 days after first assessment notice | 10 days after discovering issue |
+| **Additional remedies** | Reimbursement or credit | Delinquent filing + fee waiver + penalties |
+| **Key exclusion** | Customer data/configuration errors | Customer delays or insufficient funds |
+| **Cooperation required** | Yes - investigation and mitigation | Yes - meeting all obligations |
+
+## Maximizing guarantee protection
+
+### For accuracy guarantee
+
+#### 1. Complete, accurate data
+
+- Verify addresses are correct and complete
+- Ensure product taxability mappings are accurate
+- Keep exemption certificates current
+- Maintain accurate nexus settings
+
+#### 2. Proper configuration
+
+- Follow Commenda's configuration guidance
+- Test configurations before going live
+- Review configuration regularly
+- Update settings when business changes
+
+#### 3. Documentation
+
+- Keep records of all transactions
+- Save configuration settings and changes
+- Document legal positions and decisions
+- Maintain audit trail
+
+#### 4. Prompt notification
+
+- Monitor for assessment notices
+- Notify Commenda within 14 days
+- Provide complete documentation
+- Respond to information requests quickly
+
+#### 5. Full cooperation
+
+- Participate in investigation
+- Provide requested information
+- Authorize Commenda to communicate with tax authority
+- Work collaboratively on mitigation
+
+### For on-time filing guarantee
+
+#### 1. Meet all deadlines
+
+- Provide data by agreed-upon deadlines
+- Approve returns promptly
+- Respond to questions quickly
+- Don't delay critical decisions
+
+#### 2. Maintain account health
+
+- Keep sufficient funds available
+- Maintain active tax accounts
+- Keep credentials current
+- Monitor account status
+
+#### 3. Data quality
+
+- Validate data before submission
+- Address data quality issues promptly
+- Test integrations regularly
+- Monitor data feeds
+
+#### 4. Proactive communication
+
+- Notify Commenda of business changes
+- Report issues immediately
+- Respond to communications promptly
+- Keep contact information current
+
+#### 5. Plan ahead
+
+- Build buffer time before deadlines
+- Don't wait until last minute for approvals
+- Address issues early
+- Maintain backup remittance methods
+
+## Common guarantee scenarios
+
+### Scenario 1: Inaccurate rate applied
+
+**Situation:** Commenda applied a 7% rate when the correct rate was 8%. The tax authority assesses:
+- $5,000 in uncollected tax
+- $500 in penalties and interest
+
+**Guarantee applies?** Yes, if:
+- Customer provided correct address and transaction data
+- Customer properly configured the system
+- Customer notified within 14 days
+- Customer cooperated with investigation
+
+**Covered amount:** $5,500 (tax + penalties + interest), up to Rolling ACV cap
+
+### Scenario 2: Wrong product taxability
+
+**Situation:** Customer classified a product as non-taxable based on their legal interpretation. Tax authority disagrees and assesses $10,000.
+
+**Guarantee applies?** No — this is a legal position selected by customer (exclusion #2)
+
+**Responsibility:** Customer owns the outcome of legal classification decisions
+
+### Scenario 3: Late filing due to customer data delay
+
+**Situation:** Customer provided transaction data 3 days late. Commenda filed the return 2 days after the due date. Tax authority assesses $200 in late-filing penalties.
+
+**Guarantee applies?** No — late filing was caused by customer's delayed data (exclusion #1)
+
+**Responsibility:** Customer is responsible for penalties due to their data delay
+
+### Scenario 4: Late filing due to Commenda error
+
+**Situation:** Customer provided all data on time and approved the return 5 days before the due date. Commenda failed to submit the return due to an internal processing error. Tax authority assesses $300 in penalties.
+
+**Guarantee applies?** Yes, if:
+- Customer met all obligations (timely data, approval, sufficient funds)
+- Customer notified within 10 days
+- Late filing was solely due to Commenda's error
+
+**Covered amount:** $300 in penalties + fee waiver for that return, up to Rolling ACV cap
+
+### Scenario 5: Incorrect address provided
+
+**Situation:** Customer provided a billing address instead of shipping address. Commenda calculated tax for the wrong jurisdiction. Tax authority assesses $3,000 in uncollected tax.
+
+**Guarantee applies?** No — this is customer's incorrect data (exclusion #1)
+
+**Responsibility:** Customer is responsible for providing correct addresses
+
+### Scenario 6: Retroactive law change
+
+**Situation:** A jurisdiction retroactively changed a product's taxability. Commenda's calculation was correct at the time of transaction but is now deemed incorrect. Tax authority assesses $8,000.
+
+**Guarantee applies?** No — this is a change in law after the transaction date (exclusion #3)
+
+**Responsibility:** Retroactive law changes are not covered by the guarantee
+
+## FAQ
+
+### What is "Rolling ACV"?
+
+Rolling ACV is the total fees the customer paid to Commenda for the Services during the twelve (12) months preceding the tax period at issue. This is the cap for both guarantees.
+
+**Example:** If the tax period at issue is Q2 2024, Rolling ACV is the fees paid from Q2 2023 through Q1 2024.
+
+### Can the customer get more than Rolling ACV in coverage?
+
+No. Both guarantees are capped at Rolling ACV. This is the maximum recovery under either guarantee.
+
+### What if the customer disagrees with Commenda's determination?
+
+If the customer believes the guarantee should apply but Commenda determines it doesn't:
+1. Provide a detailed explanation of the determination
+2. Request any additional information that supports their position
+3. Escalate to executive team if needed
+4. Review the service agreement for dispute resolution procedures
+
+### Do the guarantees cover state income tax or other taxes?
+
+No. These guarantees specifically cover sales tax (indirect tax) services only. They do not cover income tax, payroll tax, or other tax types.
+
+### What if multiple issues occur in the same period?
+
+Each issue is evaluated separately. However, the total recovery across all issues is still capped at Rolling ACV for that period.
+
+### How long does the investigation take?
+
+Investigation timelines vary based on complexity. Commenda will:
+- Acknowledge the claim within 2 business days
+- Provide initial assessment within 10 business days
+- Complete investigation within 30 days (for most cases)
+- Communicate timeline if more time is needed
+
+### What if the tax authority is wrong?
+
+If Commenda believes the tax authority's assessment is incorrect:
+- Work with the customer to contest the assessment
+- Provide supporting documentation and analysis
+- Participate in appeals or protests (as appropriate)
+- Help minimize or eliminate the assessment
+
+If the assessment is successfully reduced or eliminated, the guarantee covers only the final assessed amount.
+
+### Can the customer purchase additional coverage?
+
+The guarantees are included with the service agreement and cannot be increased beyond Rolling ACV. Options to consider:
+- Maintaining their own tax liability insurance
+- Increasing Rolling ACV by using more Commenda services
+- Working with their insurance broker on additional coverage
+
+### What happens if Commenda goes out of business?
+
+The guarantees are only valid while Commenda is operating. Customers should consider:
+- Maintaining their own documentation and records
+- Having backup tax service providers identified
+- Maintaining tax liability insurance
+- Keeping sufficient reserves for potential tax liabilities
+
+## Best practices for guarantee claims
+
+### Do's
+
+- **Notify promptly** — Don't wait until the deadline
+- **Provide complete documentation** — Include everything requested
+- **Cooperate fully** — Respond quickly to information requests
+- **Document everything** — Keep records of all communications
+- **Be professional** — Work collaboratively with Commenda
+- **Follow up** — Check on status if there's no response
+
+### Don'ts
+
+- **Don't delay notification** — Missing the deadline disqualifies the claim
+- **Don't withhold information** — Full disclosure is required
+- **Don't ignore requests** — Lack of cooperation can disqualify the claim
+- **Don't make assumptions** — Ask questions if unsure
+- **Don't escalate prematurely** — Give the process time to work
+- **Don't agree to settlements** — Consult with Commenda before agreeing to anything with tax authority
+
+## Related documentation
+
+- [Incident Response SOP](/product/indirect-tax/incident-response-sop/overview) — How Commenda handles tax incidents
+- [Scenario classification](/product/indirect-tax/incident-response-sop/scenarios) — Types of tax issues and remedies
+- [Communication templates](/product/indirect-tax/incident-response-sop/templates) — Templates for customer communications
diff --git a/product/indirect-tax/incident-response-sop/assessment.mdx b/product/indirect-tax/incident-response-sop/assessment.mdx
new file mode 100644
index 000000000..c1933442d
--- /dev/null
+++ b/product/indirect-tax/incident-response-sop/assessment.mdx
@@ -0,0 +1,742 @@
+---
+title: 'Assessment framework'
+description: 'Incident evaluation criteria and decision-making framework'
+---
+
+## Overview
+
+This framework provides structured criteria for assessing incidents and determining appropriate response levels. Use these dimensions to classify incidents and guide decision-making.
+
+## Assessment dimensions
+
+### 1. Scope of impact
+
+Determines how many customers are affected and whether the issue is isolated or systemic.
+
+#### 1.1 Single-customer impact
+
+**Characteristics:**
+- Only one legal entity/customer affected
+- Often customer-specific configuration or integration issue
+- May be reproducible for other customers if triggered the same way
+
+**Examples:**
+- Bad address payload from specific customer
+- Customer-specific nexus configuration error
+- Customer-specific product mapping issue
+- Customer-specific exemption logic error
+
+**Response level:** Account manager handles with manager oversight
+
+**Key question:** Is this truly isolated or could it affect others?
+
+#### 1.2 Multi-customer partial impact
+
+**Characteristics:**
+- Subset of customers affected
+- Often tied to specific integration, jurisdiction, or feature
+- Most dangerous because it looks isolated but is systemic
+
+**Examples:**
+- Customers using specific integration (e.g., Shopify only)
+- Customers in specific jurisdiction (e.g., CA sourcing rule bug)
+- Customers using specific feature (MPU, marketplace logic, reverse charge)
+
+**Response level:** Manager involvement required; potential SWAT team
+
+**Key question:** What's the common factor? How many customers share it?
+
+#### 1.3 Global impact
+
+**Characteristics:**
+- All customers or all transactions affected
+- Platform-level issue
+- Immediate escalation required
+
+**Examples:**
+- Tax engine unavailable
+- Core ruleset regression
+- Address resolution failure
+- Rate service failure
+
+**Response level:** Immediate SWAT team activation; executive involvement
+
+**Key question:** How quickly can we contain and resolve?
+
+### 2. Temporal nature
+
+Determines when the issue occurred and how long it persisted.
+
+#### 2.1 Hard downtime
+
+**Characteristics:**
+- Tax calculation endpoint unavailable
+- Timeouts/5xx errors
+- Explicit fail-closed behavior
+
+**Risk profile:**
+- Missed tax collection
+- Missing invoice fields
+- Customer operational blockage
+- Highly visible to customers
+
+**Response level:** Immediate; P0 incident
+
+**Key question:** How long was service unavailable?
+
+#### 2.2 Soft downtime
+
+**Characteristics:**
+- Calculations occur but are wrong
+- More dangerous than hard downtime
+- Often detected late
+
+**Examples:**
+- Zero tax applied incorrectly
+- Wrong jurisdiction sourced
+- Wrong rate applied
+- Exempt logic misfiring
+
+**Risk profile:**
+- Historical correction required
+- Compliance implications
+- Customer trust impact
+- May affect filed returns
+
+**Response level:** High priority; requires immediate investigation
+
+**Key question:** How long before we detected it?
+
+#### 2.3 Intermittent/partial failures
+
+**Characteristics:**
+- Only some transactions fail
+- Retry-dependent behavior
+- Time-window specific
+
+**Risk profile:**
+- Hardest to detect and explain
+- Difficult to reproduce
+- Customer confusion
+
+**Response level:** Moderate to high; requires detailed investigation
+
+**Key question:** Can we identify the pattern?
+
+### 3. Financial exposure magnitude
+
+Determines the dollar value at risk.
+
+#### 3.1 De minimis exposure
+
+**Threshold:** < $1,000 total misreported tax
+
+**Characteristics:**
+- Low volume or test transactions
+- No filings impacted yet
+- Minimal customer impact
+
+**Response level:** Account manager handles; document and inform
+
+**Remedy approach:** Low-dollar, low-visibility (Scenario 1)
+
+#### 3.2 Material but contained exposure
+
+**Threshold:** $1,000 - $10,000
+
+**Characteristics:**
+- One or two jurisdictions
+- May affect filed vs. unfiled boundary
+- Moderate customer impact
+
+**Response level:** Manager oversight required
+
+**Remedy approach:** Standard remediation (Scenarios 2-5)
+
+#### 3.3 Material and reportable exposure
+
+**Threshold:** $10,000 - $100,000
+
+**Characteristics:**
+- Multiple jurisdictions
+- Potential customer restatement or amended filings
+- Significant customer impact
+
+**Response level:** Executive involvement required
+
+**Remedy approach:** Enhanced support; potential fee credits
+
+#### 3.4 Systemic financial risk
+
+**Threshold:** > $100,000 or growing without cap
+
+**Characteristics:**
+- Exposure grows with every transaction
+- No natural cap
+- Time-sensitive to stop propagation
+
+**Response level:** SWAT team activation; executive leadership
+
+**Remedy approach:** All available resources; potential customer tax recovery services
+
+### 4. Compliance lifecycle impact
+
+Determines where in the tax lifecycle the error occurred.
+
+#### 4.1 Pre-invoice
+
+**Characteristics:**
+- Checkout failures
+- Draft invoices
+- Quoting flows
+- No compliance filing impact yet
+
+**Risk profile:**
+- Customer operational impact
+- Revenue blocking
+- No regulatory exposure yet
+
+**Response level:** Moderate to high depending on customer impact
+
+**Remediation complexity:** Low - can be corrected before finalization
+
+#### 4.2 Post-invoice, pre-filing
+
+**Characteristics:**
+- Incorrect tax on issued invoices
+- Can be corrected via credit memos/re-invoicing
+- Not yet reported to jurisdictions
+
+**Risk profile:**
+- Customer relationship impact
+- Billing corrections needed
+- No regulatory exposure yet
+
+**Response level:** Moderate to high
+
+**Remediation complexity:** Moderate - requires customer coordination
+
+#### 4.3 Post-filing
+
+**Characteristics:**
+- Returns already filed with incorrect data
+- Triggers amendments, penalties, interest
+- High reputational risk
+
+**Risk profile:**
+- Regulatory visibility
+- Potential penalties and interest
+- Audit risk
+- Significant remediation effort
+
+**Response level:** High to critical
+
+**Remediation complexity:** High - requires amended returns and jurisdiction coordination
+
+### 5. Direction of error
+
+Determines whether tax was over-collected, under-collected, or mis-sourced.
+
+#### 5.1 Under-collection
+
+**Characteristics:**
+- Tax not charged when it should have been
+- Customer absorbs liability or must recover from end customers
+- Higher customer urgency
+
+**Risk profile:**
+- Customer out-of-pocket
+- Customer relationship strain
+- Difficult recovery from end customers
+- Audit exposure
+
+**Response level:** High - customer will escalate quickly
+
+**Remedy approach:** Scenario 2 (Under-collection)
+
+#### 5.2 Over-collection
+
+**Characteristics:**
+- Excess tax charged
+- Refund obligations
+- Customer trust issue
+
+**Risk profile:**
+- Customer complaints
+- Refund processing required
+- Lower regulatory risk
+- Reputational impact
+
+**Response level:** High - customer complaints drive urgency
+
+**Remedy approach:** Scenario 3 (Over-collection)
+
+#### 5.3 Misclassification without immediate dollar impact
+
+**Characteristics:**
+- Wrong tax code
+- Wrong exemption tagging
+- Latent risk that materializes later
+
+**Risk profile:**
+- May not be immediately visible
+- Audit risk
+- Future compliance issues
+
+**Response level:** Moderate - depends on potential future impact
+
+**Remedy approach:** Varies based on specific misclassification
+
+### 6. Detectability and observability
+
+Determines how the issue was discovered.
+
+#### 6.1 Customer-reported
+
+**Characteristics:**
+- Found via support ticket
+- Often already escalated emotionally
+- Customer may have already contacted their customers
+
+**Response level:** High - customer is already upset
+
+**Approach:**
+- Acknowledge immediately
+- Investigate urgently
+- Provide frequent updates
+- Escalate if needed
+
+#### 6.2 Internally detected (automated)
+
+**Characteristics:**
+- Monitoring/anomaly detection
+- Rate spikes, zero-tax anomalies, jurisdiction drift
+- Caught before customer notices
+
+**Response level:** Moderate to high depending on impact
+
+**Approach:**
+- Investigate thoroughly before notifying customer
+- Prepare complete analysis
+- Proactive notification
+- Demonstrate competence
+
+#### 6.3 Latent/discovered during filing
+
+**Characteristics:**
+- Found weeks later
+- Highest remediation cost
+- Customer may be surprised
+
+**Response level:** High - requires careful communication
+
+**Approach:**
+- Complete investigation first
+- Prepare comprehensive remediation plan
+- Emphasize that we caught it before audit
+- Provide full support
+
+### 7. Blast radius expansion risk
+
+Determines whether the issue is growing or contained.
+
+#### 7.1 Static
+
+**Characteristics:**
+- Historical only
+- No new transactions affected
+- Issue is resolved
+
+**Response level:** Moderate - focus on remediation
+
+**Approach:**
+- Quantify total impact
+- Execute remediation plan
+- Document lessons learned
+
+#### 7.2 Growing
+
+**Characteristics:**
+- Every new transaction compounds exposure
+- Issue is ongoing
+- Urgent containment needed
+
+**Response level:** Critical - stop the bleeding first
+
+**Approach:**
+- Immediate containment
+- Halt affected processes if necessary
+- Fix before full remediation
+- Communicate status to customers
+
+#### 7.3 Cascading
+
+**Characteristics:**
+- Downstream systems affected
+- Reporting, filings, ledger exports impacted
+- Multiple systems need correction
+
+**Response level:** Critical - SWAT team activation
+
+**Approach:**
+- Map all affected systems
+- Coordinate cross-functional response
+- Prioritize containment
+- Systematic remediation
+
+### 8. Customer operational dependence
+
+Determines how critical tax calculation is to customer's business flow.
+
+#### 8.1 Non-blocking
+
+**Characteristics:**
+- Back-office reconciliation only
+- Customer can continue operations
+- Lower urgency
+
+**Response level:** Moderate
+
+**Approach:**
+- Standard remediation timeline
+- Regular updates
+- Focus on accuracy over speed
+
+#### 8.2 Revenue-blocking
+
+**Characteristics:**
+- Checkout or invoicing blocked
+- Customer cannot process sales
+- High urgency
+
+**Response level:** Critical - P0 incident
+
+**Approach:**
+- Immediate response
+- Workaround if possible
+- Frequent updates (hourly if needed)
+- Executive involvement
+
+#### 8.3 Regulator-facing
+
+**Characteristics:**
+- Real-time e-invoicing
+- SAF-T reporting
+- Clearance models
+- Regulatory deadline risk
+
+**Response level:** Critical - regulatory implications
+
+**Approach:**
+- Immediate escalation
+- Regulatory expertise involved
+- Coordinate with customer's compliance team
+- Document everything
+
+### 9. Regulatory sensitivity
+
+Determines jurisdiction-specific risk factors.
+
+#### High-sensitivity jurisdictions
+
+**Characteristics:**
+- Real-time reporting requirements (e.g., Brazil, Italy, Mexico)
+- High penalty severity
+- Aggressive audit practices
+- Short correction windows
+
+**Examples:**
+- Brazil (NF-e)
+- Italy (FatturaPA)
+- Mexico (CFDI)
+- California (aggressive audits)
+
+**Response level:** Elevated for these jurisdictions
+
+**Approach:**
+- Involve jurisdiction specialists
+- Prioritize these jurisdictions in remediation
+- Extra documentation
+- Consider local counsel
+
+#### Moderate-sensitivity jurisdictions
+
+**Characteristics:**
+- Standard audit practices
+- Reasonable correction windows
+- Moderate penalties
+
+**Examples:**
+- Most U.S. states
+- Canada
+- UK
+
+**Response level:** Standard
+
+**Approach:**
+- Follow standard remediation procedures
+- Document thoroughly
+- Timely corrections
+
+#### Low-sensitivity jurisdictions
+
+**Characteristics:**
+- Infrequent audits
+- Low penalties
+- Flexible correction processes
+
+**Response level:** Standard to low
+
+**Approach:**
+- Standard remediation
+- May prioritize other jurisdictions first
+
+### 10. Internal responsibility classification
+
+Determines accountability and response approach.
+
+#### Platform bug
+
+**Characteristics:**
+- Core tax engine issue
+- Affects multiple customers
+- Commenda's responsibility
+
+**Response approach:**
+- Full ownership
+- Proactive notification
+- Enhanced support
+- Consider fee credits
+
+#### Content/rules bug
+
+**Characteristics:**
+- Tax rate or rule error
+- Often jurisdiction-specific
+- Commenda's responsibility
+
+**Response approach:**
+- Full ownership
+- Verify with jurisdiction
+- Proactive notification
+- Standard support
+
+#### Integration bug
+
+**Characteristics:**
+- Connector or API issue
+- May be Commenda or third-party
+- Shared responsibility
+
+**Response approach:**
+- Determine root cause
+- Coordinate with third party if needed
+- Proactive notification
+- Standard support
+
+#### Customer misconfiguration
+
+**Characteristics:**
+- Customer setup error
+- Customer's responsibility
+- Commenda provides guidance
+
+**Response approach:**
+- Educate customer
+- Help correct configuration
+- May charge for extensive support
+- Document proper setup
+
+#### Third-party dependency failure
+
+**Characteristics:**
+- External service issue
+- Outside Commenda's control
+- Shared impact
+
+**Response approach:**
+- Coordinate with third party
+- Keep customer informed
+- Provide workarounds if possible
+- Document for SLA purposes
+
+## Decision matrix
+
+Use this matrix to determine response level based on key factors:
+
+| Exposure | Customers | Filings | Response level | Approval needed |
+|----------|-----------|---------|----------------|-----------------|
+| < $1K | Single | None | Low | Account manager |
+| < $5K | Single | None | Moderate | Manager |
+| < $5K | Multiple | None | High | Manager |
+| $5K-$10K | Single | None | High | Manager |
+| $5K-$10K | Multiple | None | Critical | Executive |
+| $10K-$100K | Any | None | Critical | Executive |
+| > $100K | Any | Any | SWAT team | Executive |
+| Any | Any | Filed | +1 level | +1 level |
+| Any | Revenue-blocking | Any | Critical | Executive |
+
+## Assessment checklist
+
+Use this checklist when assessing any incident:
+
+### Initial assessment (within 1 hour)
+
+- [ ] How was issue detected?
+- [ ] Is issue ongoing or resolved?
+- [ ] How many customers affected?
+- [ ] Estimated financial exposure?
+- [ ] Are customers blocked from operations?
+- [ ] Have any returns been filed?
+
+### Detailed assessment (within 4 hours)
+
+- [ ] Exact customer list identified?
+- [ ] Precise financial exposure calculated?
+- [ ] Root cause identified?
+- [ ] Fix verified?
+- [ ] Compliance lifecycle impact determined?
+- [ ] Direction of error confirmed?
+- [ ] Blast radius assessed?
+- [ ] Regulatory sensitivity evaluated?
+- [ ] Responsibility determined?
+
+### Remediation planning (within 8 hours)
+
+- [ ] Scenario classification determined?
+- [ ] Remediation approach selected?
+- [ ] Customer communications drafted?
+- [ ] Approval obtained?
+- [ ] Resources allocated?
+- [ ] Timeline established?
+
+### Execution tracking (ongoing)
+
+- [ ] Customers notified?
+- [ ] Remediation actions in progress?
+- [ ] Customer responses tracked?
+- [ ] Technical corrections completed?
+- [ ] Documentation maintained?
+- [ ] Lessons learned captured?
+
+## Escalation triggers
+
+Escalate immediately if any of these conditions are met:
+
+### To manager
+
+- Exposure > $5,000
+- Multiple customers affected
+- Customer is upset or threatening
+- Unclear how to proceed
+- Issue is growing
+
+### To executive team
+
+- Exposure > $10,000
+- Filed returns impacted
+- Customer threatens legal action
+- Media attention
+- Regulatory inquiry
+- Platform-wide issue
+
+### To SWAT team
+
+- Exposure > $100,000
+- Real-time reporting jurisdictions affected
+- Cascading downstream effects
+- Reputational risk
+- Multiple executives involved
+
+## Common assessment mistakes
+
+### Underestimating scope
+
+**Mistake:** Assuming issue is isolated when it's actually systemic
+
+**Prevention:**
+- Always ask: "Could this affect other customers?"
+- Check for common factors (integration, jurisdiction, feature)
+- Review recent changes that could have broader impact
+
+### Overestimating urgency
+
+**Mistake:** Treating every issue as critical
+
+**Prevention:**
+- Use decision matrix objectively
+- Consider actual customer impact, not just dollar amount
+- Distinguish between urgent and important
+
+### Delayed escalation
+
+**Mistake:** Trying to handle beyond your authority level
+
+**Prevention:**
+- Escalate early when in doubt
+- Use escalation triggers as guide
+- Better to escalate unnecessarily than too late
+
+### Incomplete assessment
+
+**Mistake:** Starting remediation before full assessment
+
+**Prevention:**
+- Complete assessment checklist
+- Gather all facts first
+- Don't rush to solutions
+
+### Poor documentation
+
+**Mistake:** Not documenting assessment and decisions
+
+**Prevention:**
+- Document as you go
+- Record key decisions and rationale
+- Maintain audit trail
+
+## Assessment tools
+
+### Exposure calculator
+
+```
+Total Exposure = Σ (Transaction Amount × Tax Rate Difference)
+
+Where:
+- Transaction Amount = Taxable amount per transaction
+- Tax Rate Difference = |Correct Rate - Applied Rate|
+- Σ = Sum across all affected transactions
+```
+
+### Customer impact score
+
+```
+Impact Score = (Exposure × Urgency × Relationship Value) / 1000
+
+Where:
+- Exposure = Dollar amount
+- Urgency = 1 (low) to 5 (critical)
+- Relationship Value = 1 (small) to 5 (strategic)
+
+Score > 50 = Executive involvement
+Score 20-50 = Manager involvement
+Score < 20 = Account manager handles
+```
+
+### Remediation complexity score
+
+```
+Complexity = (Customers × Jurisdictions × Filing Status × Direction)
+
+Where:
+- Customers = Number affected
+- Jurisdictions = Number affected
+- Filing Status = 1 (pre-filing) or 3 (post-filing)
+- Direction = 1 (over) or 2 (under) or 3 (wrong jurisdiction)
+
+Score > 50 = High complexity (SWAT team)
+Score 20-50 = Moderate complexity (Manager + team)
+Score < 20 = Low complexity (Account manager)
+```
+
+Use these tools as guides, not absolute rules. Apply judgment based on specific circumstances.
diff --git a/product/indirect-tax/incident-response-sop/overview.mdx b/product/indirect-tax/incident-response-sop/overview.mdx
new file mode 100644
index 000000000..fe3a5cb24
--- /dev/null
+++ b/product/indirect-tax/incident-response-sop/overview.mdx
@@ -0,0 +1,122 @@
+---
+title: 'Incident Response SOP'
+description: 'Standard operating procedures for handling indirect tax incidents'
+icon: 'triangle-exclamation'
+---
+
+## Overview
+
+This document outlines the standard operating procedures for responding to incidents related to indirect tax operations. These procedures ensure consistent, effective handling of tax calculation errors, service outages, and compliance issues.
+
+## Core principles
+
+### Always inform the customer
+
+As a service provider, always inform customers of issues that affect their tax calculations, regardless of dollar amount or visibility. Customers discovering issues after the fact undermines trust in the entire system.
+
+### Tax reimbursement is contractual
+
+Sales tax in the U.S. is a reimbursable tax. The buyer owes the tax to the jurisdiction, and the seller acts as a conduit to collect and remit it. When tax is under-collected, the liability remains with the buyer, not the seller.
+
+### Timeliness matters
+
+The customer's willingness to adjust tax reimbursement diminishes over time. Issues discovered and addressed within the same reporting period are significantly easier to resolve than those discovered years later.
+
+### We don't pay tax
+
+Commenda's liability is limited to service fees paid, not tax amounts. We provide support, documentation, and remediation assistance, but do not reimburse customers for tax liabilities.
+
+## When to use this SOP
+
+Use these procedures when:
+
+- Tax calculation errors are detected (over-collection, under-collection, or mis-sourcing)
+- Service outages affect tax calculations
+- Integration issues cause incorrect tax treatment
+- Exemption certificate processing delays impact transactions
+- Address hierarchy or sourcing logic produces incorrect results
+
+## Response framework
+
+All incidents follow a standard response framework:
+
+1. **Detect and classify** - Identify the issue type, scope, and severity
+2. **Assess impact** - Determine financial exposure, compliance risk, and customer impact
+3. **Execute remedy** - Follow the appropriate remediation playbook
+4. **Communicate** - Notify affected customers with clear, actionable guidance
+5. **Document** - Record root cause, resolution, and lessons learned
+
+## Incident classification
+
+Incidents are classified into five primary categories:
+
+### 1. Low-dollar, low-visibility issues
+
+Small amounts per transaction spread across many customers. Treated as audit risk rather than immediate remediation.
+
+### 2. Under-collection
+
+Tax under-charged to end customers. Requires customer to re-bill or obtain affidavits.
+
+### 3. Over-collection
+
+Tax over-charged to end customers. Requires refunds and potential amended returns.
+
+### 4. Wrong jurisdiction
+
+Tax collected and remitted to incorrect jurisdiction. Requires amendments in both jurisdictions.
+
+### 5. Tardy exemption certificate
+
+Late or delayed exemption application. Requires amended returns and billing adjustments.
+
+## Escalation thresholds
+
+### Account manager discretion
+
+- Single customer impact
+- Exposure < $5,000
+- No filings affected
+- Recent issue (within current reporting period)
+
+### Executive involvement required
+
+- Multiple customer impact
+- Exposure > $10,000
+- Filed returns affected
+- Issue spans multiple reporting periods
+- Customer threatens legal action
+
+### SWAT team activation
+
+- Platform-wide impact
+- Exposure > $100,000
+- Real-time reporting jurisdictions affected
+- Cascading downstream effects
+- Regulatory inquiry received
+
+## Service guarantees and limitations
+
+### What we provide
+
+- Root cause analysis and documentation
+- Customer communication templates
+- Remediation guidance and support
+- Account credits for service fees (at discretion)
+- Assistance with amended returns
+- Customer tax recovery support (for key accounts)
+
+### What we don't provide
+
+- Direct payment of tax liabilities
+- Payment of penalties or interest (except in specific guarantee scenarios)
+- Legal representation
+- Guarantee beyond service fees paid
+
+## Related documentation
+
+- [Scenario classification](/product/indirect-tax/incident-response-sop/scenarios) - Detailed breakdown of incident types
+- [Remediation playbook](/product/indirect-tax/incident-response-sop/remediation) - Step-by-step procedures
+- [Communication templates](/product/indirect-tax/incident-response-sop/templates) - Customer notification templates
+- [Assessment framework](/product/indirect-tax/incident-response-sop/assessment) - Incident evaluation criteria
+
diff --git a/product/indirect-tax/incident-response-sop/remediation.mdx b/product/indirect-tax/incident-response-sop/remediation.mdx
new file mode 100644
index 000000000..403767291
--- /dev/null
+++ b/product/indirect-tax/incident-response-sop/remediation.mdx
@@ -0,0 +1,605 @@
+---
+title: 'Remediation playbook'
+description: 'Step-by-step procedures for incident resolution'
+---
+
+## Overview
+
+This playbook provides detailed, step-by-step procedures for remediating each incident scenario. Follow these procedures to ensure consistent, effective incident resolution.
+
+## General response workflow
+
+All incidents follow this standard workflow:
+
+### 1. Initial detection and triage
+
+**Actions:**
+- Document how issue was discovered (customer-reported, internal monitoring, filing review)
+- Identify affected time window
+- Determine if issue is ongoing or resolved
+- Assess immediate containment needs
+
+**Outputs:**
+- Incident ticket created
+- Initial scope assessment
+- Containment actions taken (if needed)
+
+### 2. Impact assessment
+
+**Actions:**
+- Identify affected customers
+- Calculate financial exposure
+- Determine compliance lifecycle impact (pre-invoice, post-invoice, post-filing)
+- Assess blast radius (single customer, multiple customers, platform-wide)
+- Evaluate direction of error (under-collection, over-collection, mis-sourcing)
+
+**Outputs:**
+- Affected customer list
+- Financial exposure by customer and jurisdiction
+- Compliance impact assessment
+- Scenario classification
+
+### 3. Root cause analysis
+
+**Actions:**
+- Identify technical root cause
+- Determine contributing factors
+- Document timeline of issue
+- Verify issue is resolved or implement fix
+
+**Outputs:**
+- Root cause documentation
+- Fix verification
+- Prevention recommendations
+
+### 4. Remediation execution
+
+**Actions:**
+- Follow scenario-specific remediation steps (see below)
+- Prepare customer communications
+- Coordinate with affected teams (engineering, support, compliance)
+- Execute technical corrections (amended returns, refunds, etc.)
+
+**Outputs:**
+- Remediation actions completed
+- Customer notifications sent
+- Technical corrections filed
+
+### 5. Documentation and follow-up
+
+**Actions:**
+- Document full incident timeline
+- Record lessons learned
+- Update monitoring/alerting if needed
+- Schedule follow-up with affected customers
+- Track resolution to completion
+
+**Outputs:**
+- Incident post-mortem
+- Process improvements identified
+- Customer satisfaction confirmed
+
+## Scenario-specific procedures
+
+### Scenario 1: Low-dollar, low-visibility issues
+
+#### Step 1: Quantify and document
+
+**Actions:**
+1. Calculate total exposure across all affected transactions
+2. Identify number of customers and transactions affected
+3. Calculate average exposure per customer
+4. Document affected jurisdictions
+5. Verify issue is resolved going forward
+
+**Documentation required:**
+- Transaction-level detail (customer, date, amount, jurisdiction)
+- Root cause analysis
+- Fix verification
+- Time window affected
+
+#### Step 2: Prepare customer notification
+
+**Actions:**
+1. Draft notification email explaining:
+ - What happened
+ - Time window affected
+ - Total exposure for their account
+ - Why customer tax recovery is not recommended
+ - How issue is resolved
+ - What to do if audited
+2. Include supporting documentation
+3. Get approval from manager
+
+**Template:** See "Low-dollar issue notification" in communication templates
+
+#### Step 3: Notify customer
+
+**Actions:**
+1. Send notification via email
+2. Offer to schedule call if customer has questions
+3. Provide documentation for their records
+4. Confirm receipt and understanding
+
+**Follow-up:**
+- Respond to questions within 24 hours
+- Escalate if customer demands remediation
+- Document customer response
+
+#### Step 4: Document for audit support
+
+**Actions:**
+1. Prepare audit defense package:
+ - Detailed calculations
+ - Timeline of issue and resolution
+ - Supporting evidence
+ - Jurisdiction-specific considerations
+2. Store in customer's account for future reference
+
+**Retention:** Keep for statute of limitations period (typically 3-4 years)
+
+### Scenario 2: Under-collection
+
+#### Step 1: Assess scope and timing
+
+**Actions:**
+1. Identify all affected transactions
+2. Calculate under-collected tax by customer and jurisdiction
+3. Determine if any returns have been filed
+4. Assess whether registrations are in place
+5. Evaluate customer's ability to re-bill
+
+**Key questions:**
+- How recent is the issue? (within current period vs. multiple periods)
+- Have returns been filed? (pre-filing vs. post-filing)
+- Are registrations in place? (registered vs. in-process)
+- What is customer's contract with their buyers? (can they re-bill?)
+
+#### Step 2: Prepare customer notification and templates
+
+**Actions:**
+1. Draft notification email to customer explaining:
+ - What happened and why
+ - Financial impact to their account
+ - Tax reimbursement principles
+ - Recommended next steps
+ - Support we'll provide
+2. Prepare customer tax recovery template for them to send to their buyers
+3. Prepare transaction detail spreadsheet
+4. Get approval from manager (if exposure > $5,000, get executive approval)
+
+**Templates:** See "Under-collection notification" and "Customer tax recovery letter" in communication templates
+
+#### Step 3: Notify customer and provide support
+
+**Actions:**
+1. Send notification email with:
+ - Explanation of issue
+ - Transaction detail spreadsheet
+ - Customer tax recovery template
+ - Offer to review their outreach before sending
+2. Schedule call to walk through details (if exposure > $5,000)
+3. Offer to participate in customer conversations (if exposure > $10,000)
+
+**Talking points:**
+- Tax reimbursement is contractual between buyer and seller
+- This is a timely issue (emphasize recency)
+- We'll support them throughout the process
+- We can provide documentation for their customers
+
+#### Step 4: Support customer tax recovery
+
+**Actions:**
+1. Review customer's draft communication before they send
+2. Provide jurisdiction-specific guidance
+3. Prepare affidavit templates (XYZ letter style)
+4. Track recovery progress
+5. Assist with any buyer questions (if authorized)
+
+**For high-value accounts (exposure > $25,000):**
+- Consider offering discounted/no-charge customer tax recovery service
+- Direct outreach to top customers representing 80% of liability
+- Executive involvement in key customer conversations
+
+#### Step 5: Handle filing implications
+
+**Actions:**
+
+**If returns not yet filed:**
+1. Ensure correct amounts are reported on upcoming returns
+2. Document under-collection and recovery efforts
+3. Report actual collected amounts (not amounts that should have been collected)
+
+**If returns already filed:**
+1. Assess whether amended returns are needed
+2. If customer successfully recovers tax, file amended returns to report additional tax
+3. If customer cannot recover tax, document efforts and maintain records for audit
+
+**Documentation:**
+- Recovery efforts and results
+- Customer communications
+- Affidavits received
+- Amended return support
+
+#### Step 6: Escalation procedures
+
+**If customer refuses to pursue recovery:**
+1. Reiterate tax reimbursement principles
+2. Emphasize their contractual rights
+3. Explain audit risk if not addressed
+4. Escalate to executive team
+5. Review service agreement limitations
+6. Consider fee credits (at discretion)
+
+**If customer demands Commenda pay the tax:**
+1. Refer to service agreement limitations
+2. Explain we don't pay tax, only support recovery
+3. Offer fee credits up to service fees paid
+4. Escalate to executive team
+5. Involve legal if necessary
+
+### Scenario 3: Over-collection
+
+#### Step 1: Assess scope and refund obligations
+
+**Actions:**
+1. Identify all affected transactions
+2. Calculate over-collected tax by customer and jurisdiction
+3. Determine if tax was remitted to jurisdictions
+4. Assess customer's refund obligations to their buyers
+5. Evaluate materiality per buyer
+
+**Key questions:**
+- Has tax been remitted? (affects refund process)
+- How much per buyer? (affects refund method)
+- Are buyers complaining? (affects urgency)
+- What is customer's refund policy?
+
+#### Step 2: Prepare customer notification and refund guidance
+
+**Actions:**
+1. Draft notification email explaining:
+ - What happened and why
+ - Financial impact
+ - Customer's obligations to refund buyers
+ - Refund process options
+ - Support we'll provide
+2. Prepare transaction detail spreadsheet
+3. Prepare refund process guidance
+4. Get approval from manager
+
+**Templates:** See "Over-collection notification" in communication templates
+
+#### Step 3: Notify customer and coordinate refund approach
+
+**Actions:**
+1. Send notification email with:
+ - Explanation of issue
+ - Transaction detail spreadsheet
+ - Refund process guidance
+ - Offer to assist with refund logistics
+2. Schedule call to discuss refund approach
+3. Determine refund method:
+ - Credits on future invoices
+ - Direct refunds
+ - Combination approach
+
+**Refund method considerations:**
+- **Credits**: Easier administratively, but only works for repeat customers
+- **Direct refunds**: Required for one-time customers or large amounts
+- **Materiality**: Small amounts (< $25) may warrant credits; larger amounts warrant refunds
+
+#### Step 4: Support refund execution
+
+**Actions:**
+1. Help customer identify affected buyers
+2. Provide refund notification templates
+3. Assist with refund calculations
+4. Track refund progress
+5. Document refunds issued
+
+**For key accounts:**
+- Offer hands-on support with refund logistics
+- Help generate refund letters
+- Provide buyer-specific calculations
+
+#### Step 5: Handle filing implications
+
+**Actions:**
+
+**If tax not yet remitted:**
+1. Simply adjust reporting to reflect correct amounts
+2. No amendments needed
+3. Refund customers from over-collected amounts
+
+**If tax already remitted:**
+1. File amended returns with claims for refund in affected jurisdictions
+2. Provide supporting documentation:
+ - Original return
+ - Corrected calculations
+ - Refund documentation
+3. Track refund status by jurisdiction
+4. Coordinate timing: refund customers after receiving refund from jurisdiction (or before, depending on cash flow)
+
+**Amended return process:**
+- Prepare amended return schedules
+- Document reason for amendment
+- Include supporting calculations
+- Track refund claims (can take 3-6 months)
+- Follow up on delayed refunds
+
+#### Step 6: Monitor and close
+
+**Actions:**
+1. Track refund completion (both to customers and from jurisdictions)
+2. Confirm customer satisfaction
+3. Document lessons learned
+4. Update monitoring to prevent recurrence
+
+### Scenario 4: Wrong jurisdiction
+
+#### Step 1: Reconstruct correct sourcing
+
+**Actions:**
+1. Identify all affected transactions
+2. Determine correct jurisdiction for each transaction
+3. Calculate amounts by:
+ - Jurisdiction that incorrectly received tax
+ - Jurisdiction that should have received tax
+4. Verify address data and sourcing logic
+5. Document root cause
+
+**Analysis required:**
+- Transaction-level detail with addresses
+- Original jurisdiction assigned
+- Correct jurisdiction
+- Tax amount by jurisdiction
+- Net over/under by jurisdiction
+
+#### Step 2: Prepare amendment strategy
+
+**Actions:**
+1. Determine amendment approach by jurisdiction:
+ - Some jurisdictions allow cross-jurisdiction adjustments
+ - Others require separate refund and payment processes
+2. Prepare amendment schedules for both jurisdictions
+3. Calculate net impact to customer (usually zero if tax amount was correct)
+4. Get approval from manager
+
+**Documentation:**
+- Original returns filed
+- Corrected sourcing analysis
+- Amendment schedules
+- Supporting workpapers
+
+#### Step 3: Notify customer
+
+**Actions:**
+1. Draft notification email explaining:
+ - What happened (sourcing error)
+ - Why net impact is minimal (tax amount was correct)
+ - Amendment process required
+ - Timeline expectations
+ - Support we'll provide
+2. Send notification with supporting documentation
+3. Schedule call to walk through amendments
+
+**Templates:** See "Wrong jurisdiction notification" in communication templates
+
+**Key message:** "The good news is the tax amount was correct, we just need to move it from Jurisdiction A to Jurisdiction B."
+
+#### Step 4: File amendments
+
+**Actions:**
+
+**In jurisdiction that incorrectly received tax:**
+1. File amended return showing reduction
+2. Request refund or credit
+3. Provide supporting documentation
+4. Track refund/credit status
+
+**In jurisdiction that should have received tax:**
+1. File amended return showing increase
+2. Pay additional tax due (plus interest if applicable)
+3. Provide supporting documentation
+4. Confirm payment processed
+
+**Coordination:**
+- Some jurisdictions allow offset (pay net difference)
+- Others require separate processes
+- Document all communications with both jurisdictions
+
+#### Step 5: Monitor resolution
+
+**Actions:**
+1. Track refund from incorrect jurisdiction
+2. Confirm payment to correct jurisdiction
+3. Reconcile net impact to customer
+4. Document resolution
+5. Update address hierarchy/sourcing logic to prevent recurrence
+
+**Timeline expectations:**
+- Refunds can take 3-6 months
+- Some jurisdictions are faster than others
+- Keep customer updated on status
+
+### Scenario 5: Tardy exemption certificate
+
+#### Step 1: Clarify sequence and validity
+
+**Actions:**
+1. Determine timeline:
+ - When was transaction processed?
+ - When was exemption certificate received?
+ - When was it applied in system?
+2. Verify exemption certificate validity:
+ - Covers transaction date?
+ - Correct jurisdiction?
+ - Properly completed?
+3. Determine billing and reporting status:
+ - Was tax billed to buyer?
+ - Was tax collected from buyer?
+ - Was tax reported to jurisdiction?
+
+**Key questions:**
+- Is certificate valid for the transaction date?
+- Was tax actually collected or just reported?
+- Which returns are affected?
+
+#### Step 2: Determine correction approach
+
+**Actions:**
+
+**Scenario A: Tax reported but not collected**
+1. File amended returns to remove exempt tax
+2. No customer refund needed
+3. Track refund/credit from jurisdiction
+
+**Scenario B: Tax reported and collected**
+1. File amended returns to remove exempt tax
+2. Refund customer for tax collected
+3. Track refund/credit from jurisdiction
+4. Coordinate timing of customer refund
+
+**Scenario C: Tax not yet reported**
+1. Simply report correctly on upcoming return
+2. Refund customer if tax was collected
+3. No amendments needed
+
+#### Step 3: Notify customer
+
+**Actions:**
+1. Draft notification email explaining:
+ - Exemption certificate received
+ - Correction process required
+ - Timeline expectations
+ - Any refund due to their buyer
+2. Send notification with:
+ - Copy of exemption certificate
+ - Transaction detail
+ - Amendment schedule (if applicable)
+3. Coordinate refund to buyer (if applicable)
+
+**Templates:** See "Tardy exemption notification" in communication templates
+
+#### Step 4: File amendments and process refunds
+
+**Actions:**
+1. File amended returns in affected jurisdictions
+2. Provide copy of exemption certificate as support
+3. Track refund/credit from jurisdictions
+4. Coordinate customer refund to buyer (if applicable)
+5. Update exemption status in system
+
+**Documentation:**
+- Exemption certificate
+- Original return
+- Amended return
+- Refund documentation
+
+#### Step 5: Process improvement
+
+**Actions:**
+1. Review exemption certificate intake process
+2. Identify delays in processing
+3. Implement improvements:
+ - Automated exemption validation
+ - Faster upload process
+ - Better integration syncing
+ - SLAs for exemption processing
+4. Document lessons learned
+
+**If Commenda processing delays contributed:**
+- Consider fee credits
+- Prioritize future exemption processing for this customer
+- Implement monitoring to prevent recurrence
+
+## Escalation procedures
+
+### When to escalate to manager
+
+- Exposure > $5,000
+- Customer is upset or threatening
+- Multiple customers affected
+- Unclear how to proceed
+- Customer demands Commenda pay tax
+
+### When to escalate to executive team
+
+- Exposure > $10,000
+- Multiple customers affected
+- Filed returns impacted
+- Customer threatens legal action
+- Media or regulatory attention
+- Platform-wide issue
+
+### When to activate SWAT team
+
+- Exposure > $100,000
+- Platform-wide impact
+- Real-time reporting jurisdictions affected
+- Cascading downstream effects
+- Regulatory inquiry received
+- Reputational risk
+
+## Service gestures and fee credits
+
+### Account manager discretion (up to $500)
+
+- Single customer impact
+- Exposure < $5,000
+- Clear Commenda fault
+- Customer relationship at risk
+
+### Manager approval required ($500-$2,500)
+
+- Multiple customers affected
+- Exposure $5,000-$10,000
+- Significant customer impact
+- Retention risk
+
+### Executive approval required (> $2,500)
+
+- Large exposure
+- Multiple customers
+- Significant business impact
+- Strategic account
+
+### Customer tax recovery services
+
+**Standard offering (paid service):**
+- Hourly rate for customer tax recovery
+- Typically used during VDA process
+- Helps minimize VDA liability
+
+**Discounted/free offering (incident response):**
+- For key accounts with large under-collection exposure
+- Focus on top customers representing 80% of liability
+- Executive involvement
+- Helps maintain customer relationship
+
+## Documentation requirements
+
+### All incidents require
+
+- Incident ticket with full timeline
+- Root cause analysis
+- Affected customer list
+- Financial exposure calculation
+- Customer communications
+- Resolution documentation
+
+### Additional documentation for material incidents (> $10,000)
+
+- Executive briefing
+- Detailed remediation plan
+- Customer-by-customer status tracking
+- Amended return support
+- Post-mortem analysis
+- Process improvement recommendations
+
+### Retention requirements
+
+- Keep all incident documentation for statute of limitations period (typically 3-4 years)
+- Store in customer account for easy retrieval
+- Include in audit defense package if needed
diff --git a/product/indirect-tax/incident-response-sop/scenarios.mdx b/product/indirect-tax/incident-response-sop/scenarios.mdx
new file mode 100644
index 000000000..01c65eb49
--- /dev/null
+++ b/product/indirect-tax/incident-response-sop/scenarios.mdx
@@ -0,0 +1,424 @@
+---
+title: 'Scenario classification'
+description: 'Detailed breakdown of incident types and patterns'
+---
+
+## Overview
+
+This page provides detailed classification of the five primary incident scenarios, including risk profiles, common patterns, and recommended remedies.
+
+## Scenario 1: Low-dollar, low-visibility issues
+
+### Pattern characteristics
+
+- Small under- or over-collections per transaction (typically a few dollars)
+- Spread across many customers
+- No amended returns filed yet
+- Often invisible to tax authorities unless discovered on audit
+
+### Example situations
+
+- Rounding errors affecting multiple transactions
+- Minor rate discrepancies in small jurisdictions
+- Temporary calculation delays causing small under-collections
+- Address resolution issues affecting low-value transactions
+
+### Risk profile
+
+**Aggregate exposure**: Can be non-trivial when summed across all transactions
+
+**Discovery likelihood**: Low - only found if specific taxpayer is audited
+
+**Customer recovery friction**: High - low yield relative to effort required
+
+**Compliance risk**: Low to moderate - depends on jurisdiction and audit patterns
+
+### Recommended remedy
+
+#### 1. Acknowledge and document internally
+
+Quantify total exposure and document:
+- Root cause analysis
+- Time window affected
+- Number of transactions and customers
+- Jurisdictions involved
+- Whether issue is resolved
+
+#### 2. Inform the client
+
+Explain what happened, estimated exposure, and why customer tax recovery is impractical:
+
+- Frame as audit-risk issue, not current cash issue
+- Emphasize low dollars per customer make recovery uneconomical
+- Provide documentation for their records
+- Confirm issue is resolved going forward
+
+#### 3. No proactive customer tax recovery
+
+Do not advise large-scale re-billing for trivial amounts. Position as: "We've corrected the issue; if this ever comes up on audit, we'll help support the position."
+
+#### 4. Support in event of audit
+
+Be prepared to provide:
+- Detailed calculations and documentation
+- Timeline of issue and resolution
+- Supporting evidence for audit defense
+- Fee credits per service agreement terms
+
+### Decision criteria
+
+Use this remedy when:
+- Per-transaction exposure < $10
+- Total exposure < $5,000
+- No single customer exposure > $500
+- Issue is historical and resolved
+- No filings affected yet
+
+## Scenario 2: Under-collection
+
+### Pattern characteristics
+
+- Engine, integration, or configuration issue causes under-collection of tax
+- Liability ultimately still owed to the jurisdiction
+- Often limited set of transactions, but dollars per transaction can be material
+- Client failed to collect full tax reimbursement from their customer
+
+### Example situations
+
+- Address hierarchy logic error (billing used instead of shipping)
+- Integration connector regression
+- Nexus configuration error
+- Product taxability mapping issue
+- Rate table not updated timely
+- Exemption logic misfiring
+
+### Risk profile
+
+**Client liability**: Client remains liable to jurisdiction even if they failed to collect from customer
+
+**Timing sensitivity**: Recent issues are easier to fix than ones discovered years later
+
+**Customer relationship impact**: Late tax charges can strain customer relationships
+
+**Audit exposure**: Moderate to high if filings already submitted
+
+### Recommended remedy
+
+#### 1. Have the client go back to their customers
+
+Advise client to re-bill end customers for under-collected tax, or request documentation that customer has self-reported the use tax (affidavit).
+
+#### 2. Provide a template notice
+
+Supply a letter/email template explaining:
+- There was a tax calculation issue
+- Sales tax is a reimbursable tax and remains the buyer's obligation
+- The seller is a conduit obligated to collect and remit to the state
+- The buyer can either:
+ - Pay the tax to the seller (who remits it), or
+ - Provide an affidavit that they have already paid the use tax directly
+
+#### 3. Use XYZ letter-style documentation
+
+Especially in California, leverage an "XYZ letter" style affidavit where buyer certifies whether they:
+- Were exempt from the transaction
+- Self-accrued and paid use tax
+- Still owe the tax
+
+#### 4. Escalation based on materiality
+
+For larger exposures:
+- Offer higher-touch support (calls with client and, if authorized, with their customer)
+- Consider discounted/no-charge "customer tax recovery" services
+- Help them reach out to customers and reduce net liability
+- Provide detailed transaction lists and jurisdiction breakdowns
+
+### Decision criteria
+
+Use this remedy when:
+- Per-transaction exposure > $50
+- Total exposure > $1,000
+- Limited number of customers affected (< 50)
+- Issue is recent (within 2-3 months)
+- Client has contractual right to re-bill
+
+### Special considerations
+
+#### No registrations filed yet
+
+If affected jurisdictions haven't been filed yet, you can adjust the narrative:
+
+"Our tax engine didn't collect tax because you weren't authorized to collect the tax at that time. Your customer still owes the tax. Now that we've determined you are required to collect the tax for that reporting period, your customer either needs to sign an affidavit that they paid the use tax, or be willing to be billed for the tax."
+
+This is technically accurate when registrations are being backdated.
+
+#### Multiple reporting periods
+
+If issue spans multiple reporting periods:
+- Prioritize most recent period first
+- Consider statute of limitations for older periods
+- Assess whether older periods are worth pursuing
+
+## Scenario 3: Over-collection
+
+### Pattern characteristics
+
+- Tax engine or rule error leads to over-collecting from end customers
+- Tax may have already been remitted to jurisdiction, or still sitting on client's books
+- Customer complaints and potential reputational harm
+- Operational friction of refunding customers and amending returns
+
+### Example situations
+
+- Rate table error (wrong rate applied)
+- Exemption logic failure (exempt customer charged tax)
+- Jurisdiction boundary error
+- Product taxability error (non-taxable item taxed)
+- Duplicate tax calculation
+
+### Risk profile
+
+**Customer complaints**: High - customers notice when overcharged
+
+**Reputational harm**: Moderate to high if not handled promptly
+
+**Regulatory scrutiny**: Low to moderate - depends on jurisdiction
+
+**Operational complexity**: High - refunding and amending is time-consuming
+
+### Recommended remedy
+
+#### 1. Explain obligations clearly to the client
+
+Over-collected tax generally must be:
+- Refunded to the customer, or
+- Remitted and managed via claim for refund, depending on jurisdiction rules
+
+#### 2. Assist with returning tax to customers
+
+Provide process guidance or, for key clients, hands-on support:
+- Identifying impacted transactions
+- Calculating over-collected tax per customer
+- Generating lists/letters offering refunds or credits
+- Determining whether to issue credits or cash refunds
+
+#### 3. Handle filings and amendments
+
+Where tax was already remitted:
+- Assist with amended returns and claims for refund
+- Flag that these processes can be slow and may increase audit visibility
+- Provide supporting documentation and schedules
+- Track refund status by jurisdiction
+
+#### 4. Differentiate by materiality
+
+**For small individual amounts across many customers:**
+- Client may provide credits on future invoices
+- Or, where allowed, decide not to pursue individual refunds but ensure they are not unjustly enriched (remit the tax to the state)
+
+**For large amounts or few customers:**
+- Direct refunds are typically required
+- More formal communication and documentation
+- May require executive involvement
+
+### Decision criteria
+
+Use this remedy when:
+- Any amount of over-collection is detected
+- Customer complaints received
+- Filings may or may not be affected
+- Client has obligation to make customers whole
+
+### Special considerations
+
+#### Already remitted to jurisdiction
+
+If tax was already remitted, the process becomes more complex:
+- File amended returns with claims for refund
+- Process can take 3-6 months or longer
+- Some jurisdictions require specific documentation
+- May trigger audit or additional scrutiny
+
+#### Not yet remitted
+
+If tax hasn't been remitted yet:
+- Simply refund customers and adjust reporting
+- Much cleaner process
+- Lower visibility to tax authorities
+
+## Scenario 4: Wrong jurisdiction
+
+### Pattern characteristics
+
+- Tax correctly calculated in aggregate, but collected and remitted to wrong jurisdiction
+- Often caused by bad address sourcing or hierarchy logic
+- One jurisdiction has money it shouldn't have; correct jurisdiction is shorted
+- Visibility risk if/when either jurisdiction audits
+
+### Example situations
+
+- Address hierarchy logic error (billing address used when shipping should have been)
+- Geocoding service error
+- Jurisdiction boundary data error
+- State vs. local misallocation
+- Cross-state sourcing error
+
+### Risk profile
+
+**Dual jurisdiction exposure**: Both jurisdictions may have questions
+
+**Audit visibility**: Moderate to high - amendments draw attention
+
+**Operational complexity**: High - requires coordination across jurisdictions
+
+**Customer impact**: Low if net tax amount was correct
+
+### Recommended remedy
+
+#### 1. Reconstruct correct sourcing
+
+Identify affected transactions and where tax should have been sourced:
+- Review address data used
+- Verify correct sourcing rules
+- Calculate correct jurisdiction for each transaction
+- Quantify over/under remittance by jurisdiction
+
+#### 2. Two sets of amendments
+
+File:
+- **Refund/amended returns** in the jurisdiction that incorrectly received the tax
+- **Underpayment/amended returns** in the jurisdiction that should have received the tax
+
+#### 3. Minimize client friction
+
+Provide clear schedules and workpapers supporting:
+- Original remittances by jurisdiction
+- Corrected sourcing analysis
+- Net effect by jurisdiction
+- Timeline for amendments and refunds
+
+#### 4. Address root cause
+
+Review and fix:
+- Address hierarchy logic
+- Integration address mapping
+- Geocoding service configuration
+- Jurisdiction boundary data
+
+### Decision criteria
+
+Use this remedy when:
+- Tax was calculated correctly but sourced to wrong jurisdiction
+- Affects any dollar amount (all mis-sourcing should be corrected)
+- May affect filed or unfiled returns
+- Root cause is identified and fixed
+
+### Special considerations
+
+#### Timing of corrections
+
+- If returns not yet filed: Simply file correctly
+- If returns already filed: Amendments required in both jurisdictions
+- Consider statute of limitations for older periods
+
+#### Jurisdiction cooperation
+
+Some jurisdictions are more cooperative than others:
+- Document all communications
+- Provide clear audit trail
+- Be prepared for questions from both jurisdictions
+
+## Scenario 5: Tardy exemption certificate
+
+### Pattern characteristics
+
+- Customer is (or claims to be) exempt, but exemption certificate is provided late
+- Delay in uploading/applying exemption certificates in the system
+- Transactions may have been billed tax-inclusive but never fully collected, and/or reported as taxable on prior returns
+
+### Example situations
+
+- Customer provides exemption certificate after invoice issued
+- Exemption certificate received but not uploaded timely
+- Integration delay in syncing exemption status
+- Manual exemption application backlog
+- Exemption certificate validation delays
+
+### Risk profile
+
+**Over-reporting of tax**: Tax reported but not actually due
+
+**Operational complexity**: Separating billing vs. reporting issues
+
+**Client expectations**: May expect Commenda to resolve when caused by our processing delays
+
+**Audit exposure**: Low - correcting over-reporting is generally welcomed
+
+### Recommended remedy
+
+#### 1. Clarify sequence of events
+
+Determine:
+- When was the transaction taxed and reported?
+- When was the exemption certificate received?
+- When was it applied in the system?
+- Was tax billed, collected, or just reported?
+
+#### 2. Correct prior filings where appropriate
+
+For certificates that are valid for the sale:
+- File amended returns to remove the now-exempt tax from prior periods
+- Provide supporting documentation (copy of exemption certificate)
+- Track refund or credit from jurisdiction
+
+#### 3. Separate billing vs. reporting
+
+Distinguish:
+- **Over-billing that was never collected but was reported**: Amend return only
+- **Tax that was billed, collected, and reported**: Amend return and refund customer
+
+Adjust future invoices, issue credits, or refunds to reconcile.
+
+#### 4. Tighten exemption workflows
+
+Encourage clients to:
+- Route exemption certificates through defined intake channel
+- Minimize lag between receipt and application
+- Set up automated exemption validation where possible
+- Establish SLAs for exemption processing
+
+Where Commenda's processing delays contribute, consider service gestures (fee credits, prioritized support) depending on impact.
+
+### Decision criteria
+
+Use this remedy when:
+- Valid exemption certificate received after transaction
+- Tax was reported but customer was actually exempt
+- Any dollar amount (all incorrect exemption treatment should be corrected)
+- Certificate is valid for the transaction date
+
+### Special considerations
+
+#### Retroactive exemption certificates
+
+Some jurisdictions allow retroactive application, others don't:
+- Verify jurisdiction rules
+- Document certificate validity period
+- Ensure certificate covers transaction date
+
+#### Partial period exemptions
+
+If customer became exempt mid-period:
+- Separate exempt vs. taxable transactions
+- Apply exemption only to qualifying transactions
+- Document effective date of exemption
+
+## Summary comparison
+
+| Scenario | Core issue | Primary remedy | Urgency |
+|----------|-----------|----------------|---------|
+| **Low-dollar, low-visibility** | Trivial amounts per transaction, many txns | Document, inform client, treat as audit risk | Low |
+| **Under-collection** | Tax under-billed/under-collected | Have client re-bill or get affidavits | High |
+| **Over-collection** | Customer overcharged tax | Refund/credit customers, amend returns | High |
+| **Wrong jurisdiction** | Tax remitted to wrong place | Amend in both jurisdictions | Moderate |
+| **Tardy exemption** | Late/slow exemption application | Amend returns, align billing/collections | Moderate |
diff --git a/product/indirect-tax/incident-response-sop/templates.mdx b/product/indirect-tax/incident-response-sop/templates.mdx
new file mode 100644
index 000000000..295e3f207
--- /dev/null
+++ b/product/indirect-tax/incident-response-sop/templates.mdx
@@ -0,0 +1,620 @@
+---
+title: 'Communication templates'
+description: 'Customer notification and outreach templates'
+---
+
+## Overview
+
+This page provides email templates for notifying customers of incidents and supporting their remediation efforts. Customize these templates based on the specific situation while maintaining the core messaging principles.
+
+## Template usage guidelines
+
+### Customization points
+
+Each template includes placeholders in brackets `[like this]` that should be customized:
+- `[Customer name]` - Customer's company name
+- `[Contact name]` - Primary contact's first name
+- `[Your name]` - Your full name
+- `[Dollar amount]` - Specific financial figures
+- `[Number]` - Transaction counts, time periods, etc.
+- `[Jurisdiction]` - State, county, or city names
+- `[Date]` - Specific dates or date ranges
+
+### Tone and messaging
+
+- **Be direct and transparent** - Explain what happened clearly
+- **Lead with facts** - Provide specific numbers and timelines
+- **Emphasize recency** - Highlight that issues were caught quickly
+- **Offer support** - Make it clear you'll help them through the process
+- **Avoid blame** - Focus on resolution, not fault
+
+### Approval requirements
+
+- **< $5,000 exposure**: Account manager approval
+- **$5,000-$10,000 exposure**: Manager approval
+- **> $10,000 exposure**: Executive approval
+
+## Template 1: Under-collection notification
+
+Use this template when tax was under-collected and customer needs to recover from their buyers.
+
+### Subject line
+
+```
+Follow-up on recent sales tax under-collection
+```
+
+### Email body
+
+```
+Hi [Contact name],
+
+We identified a recent issue that affected how sales tax was calculated on a [small/limited] number of your transactions. Due to [brief description of root cause, e.g., "an integration issue related to address mapping"], our tax engine under-collected tax on [number] invoices, representing approximately $[amount] in total sales tax.
+
+A few important points to keep in mind:
+
+As a reminder, under U.S. sales tax rules, the tax itself is owed by the buyer, not by [Customer name]. [Customer name]'s role is to remit that tax to the appropriate authorities on the buyer's behalf. When tax is under-collected at checkout, the remaining amount typically needs to be rebilled to the customer so it can be properly remitted.
+
+No previously filed returns have been impacted. All affected transactions are recent [or: occurred between [start date] and [end date]], and the relevant returns have not yet been filed, so this was identified within a relatively timely window.
+
+Our recommended next step is for [Customer name] to rebill the affected customers for the under-collected tax. To make this as straightforward as possible, we'll provide a template email you can use. In summary, that outreach will:
+
+• Explain that there was a temporary issue in the tax calculation logic that resulted in under-collection
+• Clarify that the sales tax remains due to the taxing authorities, and that [Customer name] serves as the collector and remitter on the government's behalf
+• Ask the customer to either:
+ - Pay the additional tax so it can be properly remitted, or
+ - Provide confirmation that they have already self-assessed and paid the applicable use tax
+
+We recognize that this is a sensitive customer communication, and we'll support you throughout the process:
+
+• We'll share a clear, auditor-defensible outreach template
+• We've attached the exact list of affected invoices, amounts, and jurisdictions for your records
+• If helpful, we're happy to review your final email or letter before it's sent
+• [For large exposures: We're available to participate in conversations with your customers if that would be helpful]
+
+Please let us know who on your team should receive the customer outreach template, and whether you'd like to schedule a quick call to walk through the specifics.
+
+Best,
+[Your name]
+```
+
+### Attachments to include
+
+1. **Transaction detail spreadsheet** with columns:
+ - Invoice number
+ - Invoice date
+ - Customer name
+ - Ship-to address
+ - Jurisdiction
+ - Taxable amount
+ - Tax that should have been collected
+ - Tax that was collected
+ - Under-collected amount
+
+2. **Customer tax recovery template** (see Template 6 below)
+
+## Template 2: Over-collection notification
+
+Use this template when tax was over-collected and customer needs to refund their buyers.
+
+### Subject line
+
+```
+Action required: Sales tax over-collection identified
+```
+
+### Email body
+
+```
+Hi [Contact name],
+
+We identified an issue that caused sales tax to be over-collected on [number] of your transactions. Due to [brief description of root cause], our tax engine over-collected approximately $[amount] in total sales tax between [start date] and [end date].
+
+Here's what this means for [Customer name]:
+
+The over-collected tax needs to be returned to your customers. You have a few options for how to handle this:
+
+1. Issue credits on future invoices (works well for repeat customers)
+2. Process direct refunds (required for one-time customers or large amounts)
+3. A combination approach based on customer relationship and amount
+
+We've prepared a detailed breakdown of affected transactions to help you determine the best approach for each customer.
+
+Filing implications:
+
+[If tax not yet remitted:]
+Since the affected returns haven't been filed yet, we'll simply report the correct amounts on your upcoming filings. No amendments are needed.
+
+[If tax already remitted:]
+Since tax was already remitted to [jurisdiction(s)], we'll need to file amended returns with claims for refund. This process typically takes 3-6 months. We can coordinate the timing of customer refunds based on your cash flow preferences.
+
+Next steps:
+
+1. Review the attached transaction detail to understand the impact by customer
+2. Decide on your refund approach (credits vs. direct refunds)
+3. We'll provide refund notification templates for your customers
+4. [If applicable: We'll prepare and file amended returns]
+5. We'll track the process through completion
+
+We're here to support you through this process. Please let us know if you'd like to schedule a call to discuss the best approach for your business.
+
+Best,
+[Your name]
+```
+
+### Attachments to include
+
+1. **Transaction detail spreadsheet** with columns:
+ - Invoice number
+ - Invoice date
+ - Customer name
+ - Jurisdiction
+ - Taxable amount
+ - Tax that should have been collected
+ - Tax that was collected
+ - Over-collected amount
+
+2. **Refund notification template** (see Template 7 below)
+
+## Template 3: Low-dollar, low-visibility issue notification
+
+Use this template when amounts are too small to warrant customer tax recovery.
+
+### Subject line
+
+```
+FYI: Minor sales tax calculation issue identified and resolved
+```
+
+### Email body
+
+```
+Hi [Contact name],
+
+We wanted to make you aware of a minor sales tax calculation issue that affected [Customer name]'s account between [start date] and [end date].
+
+What happened:
+
+Due to [brief description of root cause], our tax engine [under-collected/over-collected] small amounts of tax across [number] transactions. The total exposure for your account is approximately $[amount], with an average of $[amount] per transaction.
+
+Why we're not recommending customer outreach:
+
+Given the small dollar amounts per transaction (averaging $[amount]), attempting to recover these amounts from your customers would be impractical and likely cost more in administrative time than the tax amounts involved.
+
+Instead, we recommend treating this as an audit-risk issue:
+
+• The issue has been fully resolved as of [date]
+• The likelihood of discovery is low (would only surface if a specific customer is audited)
+• We've documented everything for your records
+• If this ever comes up on audit, we'll provide full support and documentation
+
+What we've prepared for you:
+
+• Detailed transaction-level documentation
+• Root cause analysis
+• Timeline of issue and resolution
+• Audit defense package (if needed in the future)
+
+No action is required on your part. We're providing this information for transparency and your records. If you have any questions or concerns, please don't hesitate to reach out.
+
+Best,
+[Your name]
+```
+
+### Attachments to include
+
+1. **Transaction detail spreadsheet**
+2. **Root cause analysis document**
+3. **Audit defense package**
+
+## Template 4: Wrong jurisdiction notification
+
+Use this template when tax was remitted to the wrong jurisdiction.
+
+### Subject line
+
+```
+Sales tax sourcing correction required
+```
+
+### Email body
+
+```
+Hi [Contact name],
+
+We identified an issue with how sales tax was sourced for [number] of your transactions between [start date] and [end date]. Due to [brief description of root cause, e.g., "an address hierarchy logic error"], tax was collected and remitted to [incorrect jurisdiction] when it should have been remitted to [correct jurisdiction].
+
+The good news:
+
+The total tax amount collected was correct - we just need to move it from [incorrect jurisdiction] to [correct jurisdiction]. This means there's minimal net impact to your business.
+
+What needs to happen:
+
+We'll file two sets of amended returns:
+
+1. In [incorrect jurisdiction]: Amended return requesting refund of $[amount]
+2. In [correct jurisdiction]: Amended return paying $[amount] (plus any applicable interest)
+
+Timeline expectations:
+
+• Amended returns will be filed within [timeframe]
+• Refunds from [incorrect jurisdiction] typically take 3-6 months
+• Payment to [correct jurisdiction] will be processed immediately
+• We'll track both processes through completion
+
+Your involvement:
+
+Minimal - we'll handle the amendment process and keep you updated on status. You may need to approve the amended returns and payment, depending on your account setup.
+
+We've attached detailed documentation showing the original sourcing, corrected sourcing, and net impact by jurisdiction. Please let us know if you'd like to schedule a call to walk through the details.
+
+Best,
+[Your name]
+```
+
+### Attachments to include
+
+1. **Sourcing analysis spreadsheet** with columns:
+ - Invoice number
+ - Invoice date
+ - Customer name
+ - Ship-to address
+ - Original jurisdiction assigned
+ - Correct jurisdiction
+ - Tax amount
+ - Net impact by jurisdiction
+
+2. **Amendment schedules** for both jurisdictions
+
+## Template 5: Tardy exemption certificate notification
+
+Use this template when an exemption certificate was applied late.
+
+### Subject line
+
+```
+Exemption certificate applied - amended return required
+```
+
+### Email body
+
+```
+Hi [Contact name],
+
+We've received and applied the exemption certificate for [customer name]. However, since the certificate was received after transactions were processed and reported, we need to file amended returns to correct the reporting.
+
+Transaction details:
+
+• [Number] transactions were processed as taxable between [start date] and [end date]
+• Total tax reported: $[amount]
+• Exemption certificate received: [date]
+• Exemption certificate is valid for these transactions
+
+What needs to happen:
+
+[If tax was collected:]
+1. File amended returns in [jurisdiction(s)] to remove the exempt tax
+2. Refund $[amount] to [customer name]
+3. Track refund/credit from [jurisdiction(s)]
+
+[If tax was not collected:]
+1. File amended returns in [jurisdiction(s)] to remove the exempt tax
+2. No customer refund needed
+3. Track refund/credit from [jurisdiction(s)]
+
+Timeline:
+
+• Amended returns will be filed within [timeframe]
+• [If applicable: Customer refund will be processed within [timeframe]]
+• Refunds from jurisdictions typically take 3-6 months
+
+We've updated our system to ensure [customer name] is properly marked as exempt going forward. Please let us know if you have any questions.
+
+Best,
+[Your name]
+```
+
+### Attachments to include
+
+1. **Copy of exemption certificate**
+2. **Transaction detail**
+3. **Amendment schedule**
+
+## Template 6: Customer tax recovery letter
+
+This template is provided to your customer for them to send to their buyers when tax was under-collected.
+
+### Subject line (for customer to use)
+
+```
+Important: Sales tax adjustment required
+```
+
+### Letter body (for customer to use)
+
+```
+Dear [Buyer name],
+
+We're writing to inform you of a sales tax adjustment required on your recent purchase(s) from [Customer name].
+
+What happened:
+
+Due to a temporary issue with our tax calculation system, we under-collected sales tax on the following transaction(s):
+
+[Transaction details - invoice number, date, amount]
+
+Total additional tax due: $[amount]
+
+Important information about sales tax:
+
+Under U.S. sales tax law, sales tax is the buyer's obligation. [Customer name] serves as the collector and remitter of this tax on behalf of the government. When tax is under-collected at the time of sale, the buyer remains responsible for ensuring the tax is paid.
+
+Your options:
+
+1. Pay the additional tax to [Customer name]
+ We will remit this tax to [jurisdiction] on your behalf. Please remit $[amount] to [payment instructions].
+
+2. Provide confirmation that you've already paid the use tax
+ If you've already self-assessed and paid use tax on this purchase to [jurisdiction], please provide us with an affidavit confirming payment, and no further action is needed.
+
+3. Pay the use tax directly to [jurisdiction]
+ You may choose to pay the use tax directly to [jurisdiction] and provide us with confirmation of payment.
+
+Timeline:
+
+Please respond by [date - typically 30 days] to let us know how you'd like to proceed.
+
+We apologize for any inconvenience this may cause. This was an isolated issue that has been fully resolved. If you have any questions, please contact [contact name] at [contact email/phone].
+
+Sincerely,
+[Customer name]
+```
+
+### Customization notes for your customer
+
+When providing this template to your customer, include these notes:
+
+```
+Customization notes:
+
+• Replace [Buyer name] with your customer's name
+• Insert specific transaction details (invoice numbers, dates, amounts)
+• Provide your payment instructions
+• Set an appropriate response deadline (typically 30 days)
+• Include your contact information
+
+We recommend:
+
+• Sending via email with read receipt
+• Following up with phone call for amounts > $500
+• Keeping detailed records of all communications
+• Providing us with copies of responses received
+
+We're here to support you through this process. If you'd like us to review your final letter before sending, or if you'd like us to participate in any customer conversations, please let us know.
+```
+
+## Template 7: Customer refund notification
+
+This template is provided to your customer for them to send to their buyers when tax was over-collected.
+
+### Subject line (for customer to use)
+
+```
+Sales tax refund due on your recent purchase
+```
+
+### Letter body (for customer to use)
+
+```
+Dear [Buyer name],
+
+We're writing to inform you that we over-collected sales tax on your recent purchase(s) from [Customer name].
+
+What happened:
+
+Due to an issue with our tax calculation system, we over-collected sales tax on the following transaction(s):
+
+[Transaction details - invoice number, date, amount]
+
+Total refund due to you: $[amount]
+
+Your refund:
+
+[Option 1 - Credit:]
+We've applied a credit of $[amount] to your account, which will be reflected on your next invoice.
+
+[Option 2 - Direct refund:]
+We're processing a refund of $[amount] to [payment method]. Please allow [timeframe] for the refund to appear.
+
+[Option 3 - Choice:]
+Please let us know your preference:
+• Credit on your next invoice, or
+• Direct refund to [payment method]
+
+No action is required on your part [or: Please respond by [date] with your refund preference].
+
+We apologize for this error. This was an isolated issue that has been fully resolved. If you have any questions, please contact [contact name] at [contact email/phone].
+
+Sincerely,
+[Customer name]
+```
+
+### Customization notes for your customer
+
+```
+Customization notes:
+
+• Replace [Buyer name] with your customer's name
+• Insert specific transaction details
+• Choose the appropriate refund option (credit, direct refund, or choice)
+• Provide timeline for refund processing
+• Include your contact information
+
+We recommend:
+
+• Processing refunds promptly (within 30 days)
+• Keeping detailed records of all refunds issued
+• Providing us with confirmation of refunds completed
+
+If you need assistance with the refund process or have questions about the best approach for your business, please let us know.
+```
+
+## Template 8: XYZ letter / Use tax affidavit
+
+This template is used to request confirmation from buyers that they've paid use tax directly.
+
+### Subject line
+
+```
+Request for use tax payment confirmation
+```
+
+### Letter body
+
+```
+Dear [Buyer name],
+
+We're writing regarding sales tax on your purchase(s) from [Customer name]:
+
+[Transaction details - invoice number, date, amount]
+
+Our records indicate that sales tax was not collected on this transaction at the time of sale. Under [State] law, if sales tax was not collected, the buyer is responsible for self-assessing and paying use tax directly to the state.
+
+Please complete and return this affidavit:
+
+---
+
+USE TAX AFFIDAVIT
+
+I, [Buyer name], hereby certify under penalty of perjury that with respect to the purchase(s) described above:
+
+☐ I have self-assessed and paid use tax to [State] on this purchase
+ Date paid: _______________
+ Amount paid: $_______________
+
+☐ I am exempt from sales/use tax on this purchase
+ Exemption certificate number: _______________
+ Exemption certificate attached: ☐ Yes
+
+☐ The property was resold and sales tax was collected from my customer
+
+☐ Other (please explain): _________________________________
+
+Signature: _____________________
+Name: _____________________
+Title: _____________________
+Date: _____________________
+
+---
+
+Please return this completed affidavit to [contact email] by [date - typically 30 days].
+
+If you have not paid use tax and are not exempt, you may:
+• Pay the use tax directly to [State], or
+• Pay the tax to [Customer name] and we will remit it on your behalf
+
+If you have any questions, please contact [contact name] at [contact email/phone].
+
+Sincerely,
+[Customer name]
+```
+
+### Usage notes
+
+This template is particularly useful in California (where it's called an "XYZ letter") but can be adapted for any state. It provides a formal mechanism for buyers to confirm they've handled their tax obligations.
+
+## Template 9: Executive escalation notification
+
+Use this template when escalating to executive team for high-value or complex incidents.
+
+### Subject line
+
+```
+URGENT: Sales tax incident requiring executive attention
+```
+
+### Email body
+
+```
+[Executive name],
+
+I'm escalating a sales tax incident that requires executive attention and decision-making.
+
+Situation summary:
+
+• Issue: [Brief description]
+• Root cause: [Brief description]
+• Affected customers: [Number and names of key accounts]
+• Financial exposure: $[amount]
+• Time period: [Start date] to [end date]
+• Filings impacted: [Yes/No and details]
+
+Customer impact:
+
+• [Customer name]: $[amount] exposure, [specific concerns]
+• [Additional customers as needed]
+
+Current status:
+
+• Issue resolved: [Yes/No and when]
+• Customer(s) notified: [Yes/No]
+• Remediation plan: [Brief description]
+
+Decisions needed:
+
+1. [Specific decision point]
+2. [Specific decision point]
+3. [Specific decision point]
+
+Recommended approach:
+
+[Your recommendation with rationale]
+
+Risks:
+
+• [Key risk 1]
+• [Key risk 2]
+• [Key risk 3]
+
+I'm available to discuss immediately. Please advise on how you'd like to proceed.
+
+[Your name]
+```
+
+### Attachments to include
+
+1. **Detailed incident report**
+2. **Financial impact analysis**
+3. **Customer communication history**
+4. **Proposed remediation plan**
+
+## Best practices for customer communications
+
+### Timing
+
+- **Notify promptly**: Don't delay notification while gathering every detail
+- **Follow up regularly**: Keep customers updated on progress
+- **Set expectations**: Provide realistic timelines for resolution
+
+### Tone
+
+- **Be professional**: Maintain composure even if customer is upset
+- **Be empathetic**: Acknowledge the inconvenience
+- **Be confident**: Project competence in handling the situation
+
+### Documentation
+
+- **Keep records**: Save all customer communications
+- **Track responses**: Document customer reactions and decisions
+- **Confirm understanding**: Summarize agreements in writing
+
+### Escalation signals
+
+Watch for these signals that indicate need for escalation:
+
+- Customer threatens legal action
+- Customer demands Commenda pay the tax
+- Customer refuses to follow recommended approach
+- Customer is unresponsive after multiple attempts
+- Media or regulatory attention
+- Situation is deteriorating despite your efforts
diff --git a/quickstart.mdx b/quickstart.mdx
deleted file mode 100644
index c711458ba..000000000
--- a/quickstart.mdx
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: "Quickstart"
-description: "Start building awesome documentation in minutes"
----
-
-## Get started in three steps
-
-Get your documentation site running locally and make your first customization.
-
-### Step 1: Set up your local environment
-
-
-
- During the onboarding process, you created a GitHub repository with your docs content if you didn't already have one. You can find a link to this repository in your [dashboard](https://dashboard.mintlify.com).
-
- To clone the repository locally so that you can make and preview changes to your docs, follow the [Cloning a repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository) guide in the GitHub docs.
-
-
- 1. Install the Mintlify CLI: `npm i -g mint`
- 2. Navigate to your docs directory and run: `mint dev`
- 3. Open `http://localhost:3000` to see your docs live!
-
- Your preview updates automatically as you edit files.
-
-
-
-### Step 2: Deploy your changes
-
-
-
- Install the Mintlify GitHub app from your [dashboard](https://dashboard.mintlify.com/settings/organization/github-app).
-
- Our GitHub app automatically deploys your changes to your docs site, so you don't need to manage deployments yourself.
-
-
- For a first change, let's update the name and colors of your docs site.
-
- 1. Open `docs.json` in your editor.
- 2. Change the `"name"` field to your project name.
- 3. Update the `"colors"` to match your brand.
- 4. Save and see your changes instantly at `http://localhost:3000`.
-
- Try changing the primary color to see an immediate difference!
-
-
-
-### Step 3: Go live
-
-
- 1. Commit and push your changes.
- 2. Your docs will update and be live in moments!
-
-
-## Next steps
-
-Now that you have your docs running, explore these key features:
-
-
-
-
- Learn MDX syntax and start writing your documentation.
-
-
-
- Make your docs match your brand perfectly.
-
-
-
- Include syntax-highlighted code blocks.
-
-
-
- Auto-generate API docs from OpenAPI specs.
-
-
-
-
-
- **Need help?** See our [full documentation](https://mintlify.com/docs) or join our [community](https://mintlify.com/community).
-