# PowerOn Platform - Big Picture | PowerON
PowerON Platform Architecture - Big Picture for External Developers
Author: PowerON

# PowerOn Platform - Big Picture

Enterprise AI Workflow Platform with Integrated Data Privacy Neutralizer

This document provides an overview of the PowerOn platform architecture, building blocks, and capabilities for external software developers who want to contribute to or integrate with the platform.

## Platform Overview

### Core Concept

PowerOn is a Multi-Agent AI Platform for Enterprise Workflows with an integrated data privacy neutralizer. The platform enables companies to accelerate their AI transformation without data privacy risks.

#### Key Value Propositions

- Data Privacy First: Integrated privacy neutralizer enables safe use of ChatGPT/Copilot without privacy risks
- Unlimited Processing: No token limits - process documents of any size through intelligent chunking
- Universal Integration: Seamless integration of all enterprise data sources
- Workflow Automation: Configure workflows per customer journey with standard automation elements and AI components
- Future-Proof Architecture: Automatically improves with better AI models and larger token limits
- Plug & Play Architecture: Renderers and dynamic AI selection per intention (analyze, generate, web, plan, etc.)

### Architecture Layers

#### UI Layer (Playground)

React-based playground UI as entry point. Additional UIs (chatbots, customer UIs) can be easily integrated via REST API in React, JavaScript, or other languages.

#### API Layer

RESTful API providing full access to platform capabilities. Open API design allows external UIs and integrations.

#### Workflow Engine

Core orchestration engine managing tasks, actions, and state. Supports multiple execution modes (Learning, Actionplan, Automation).

#### Microservices Layer

Modular service architecture with specialized services for AI, data processing, security, and integrations.

#### Data Layer

Multi-tenant database with RBAC-based access control. Mandate isolation ensures secure data separation.

### Customer Journey → Workflow

For each customer journey, a workflow can be configured in the workflow editor where:

- Customers integrate their data sources
- Standard automation elements are available
- AI components can be used
- Workflows can be executed manually or automated (hourly/daily/weekly)

### Plug & Play Architecture

#### Dynamic Renderers

Plug & play architecture for document renderers. Support for multiple formats (PDF, DOCX, XLSX, PPTX, HTML, Markdown, JSON, CSV, etc.) with easy extension capabilities.

#### Dynamic AI Selection

Intelligent AI model selection per intention type. The system automatically selects the best AI model based on the task: analysis, generation, web research, planning, etc.

### System Architecture Diagram

## Customer Story

### The Journey from Application-Centric to Data-Centric Work

PowerOn enables customers to transition from application-centric to data-centric work. This is a key differentiator that transforms how businesses operate.

### Step 1: Customer Journey Identification

1

#### Identify Business Processes

Work with customers to identify their key customer journeys and business processes that can benefit from automation and AI.

- Document analysis workflows
- Email processing and routing
- Data extraction and transformation
- Report generation
- Customer communication workflows

### Step 2: MVP Integration with Focus on Data Privacy & Compliance

2

#### Simple MVP Integration

Start with a simple MVP that integrates customer data sources with strong focus on data privacy and compliance:

- Data Privacy Neutralizer: Automatic anonymization of sensitive data before AI processing
- Compliance First: DSGVO/GDPR compliant processing from day one
- Secure Connections: Encrypted connections to customer data sources (SharePoint, Google Drive, Outlook, etc.)
- Mandate Isolation: Complete data separation between tenants
- Audit Logging: Full traceability of all data access and processing

This step builds trust and demonstrates the platform's commitment to data security.

### Step 3: Pre-Processing Engine Deployment

3

#### Standard API Pre-Processing

Deploy a pre-processing engine at the customer's location using a standard API:

- On-Premise/Edge Processing: Data processing happens at the customer's location
- Standard API: Consistent interface for all customers
- Data Minimization: Only necessary data is sent to the platform
- Local Neutralization: Privacy neutralization can happen before data leaves customer premises
- Reduced Latency: Faster processing for large documents

This step further enhances data privacy and gives customers full control over their data processing.

### Step 4: Gradual Component Integration - The Transformation

4

#### From Application-Centric to Data-Centric

Gradually integrate additional components until the customer works data-centrically instead of application-centrically:

##### ❌ Application-Centric (Old Way)

- Work within individual applications (Word, Excel, SharePoint, Outlook)
- Manual data transfer between applications
- Data silos in different systems
- Workflows are application-bound
- Difficult to automate across applications

##### ✅ Data-Centric (PowerOn Way)

- Work with data directly, regardless of source application
- Automatic data integration across all sources
- Unified data view across all systems
- Workflows span multiple applications seamlessly
- Easy automation across entire data ecosystem

This transformation is a KEY DIFFERENTIATOR! Customers no longer think in terms of applications, but in terms of their data and business processes.

### Customer Journey Diagram

## Workflow System

### Core Concept: Tasks with Actions

The core building block is workflow elements: tasks with actions. Each workflow consists of tasks, and each task contains one or more actions that execute specific operations.

#### Workflow

Definition: Top-level container representing a complete customer journey or business process.

Purpose: Orchestrates multiple tasks to achieve a business goal.

#### Task

Definition: A logical step in the workflow.

Purpose: Groups related actions that work together to complete a sub-goal.

#### Action

Definition: Executable unit that performs a specific operation.

Purpose: Actions belong to methods (microservices) and are the atomic units of work.

### Execution Modes

PowerOn supports three execution modes, each optimized for different use cases:

#### Learning Mode

Best for: Exploratory tasks with up to 5 steps

Approach: Iterative Plan-Act-Observe-Refine loop

Use Case: When the solution path is not fully known in advance

#### Actionplan Mode

Best for: Structured, sequential processes

Approach: Batch planning with sequential execution

Use Case: When the workflow steps are well-defined

#### Automation Mode

Best for: Repetitive, predefined workflows

Approach: Automated execution (scheduled or event-triggered)

Use Case: Production workflows that run automatically

### Available Workflow Methods

Workflow methods provide actions that can be executed within workflows. Each method exposes multiple actions accessible via `self.services.<method>.<action>`:

- ai.* - AI operations (process, analyze, generate)
- sharepoint.* - SharePoint integration (search, read, upload)
- outlook.* - Outlook integration (read emails, send emails)
- context.* - Context management (get context, set context)

### Workflow System Diagram

## Microservices Architecture

### Service Access Pattern

All microservices are accessible via `self.services.<serviceName>`. Services follow a consistent access pattern and are organized into logical categories.

### Services Structure Tree

Complete overview of all available microservices:

#### Core Services

- `self.services.chat` - Chat and conversation management
  - Progress logging
  - Document management
  - Connection handling
- `self.services.workflow` - Workflow state and management
- `self.services.utils` - Utility functions (timestamps, formatting, etc.)

#### AI & Processing Services

- `self.services.ai` - AI model management and operations
  - Model selection
  - Prompt processing
  - Response handling
- `self.services.generation` - Document generation
  - Multiple formats (PDF, DOCX, XLSX, PPTX, HTML, Markdown, etc.)
  - Template-based rendering
  - JSON schema support
- `self.services.extraction` - Document extraction and processing
  - Multiple extractors (PDF, DOCX, XLSX, PPTX, CSV, HTML, XML, JSON, Images, etc.)
  - Intelligent chunking
  - Merging strategies
- `self.services.neutralization` - Data privacy neutralization
  - PII detection and anonymization
  - Pattern-based neutralization
  - Binary and text processing

#### Integration Services

- `self.services.sharepoint` - SharePoint integration
  - Site discovery
  - File operations (read, upload, search)
  - Path resolution
- `self.services.web` - Web operations
  - HTTP requests
  - Web scraping
  - API integration
- `self.services.ticket` - Ticket system integration
  - Jira integration
  - ClickUp integration
  - Generic ticket operations

#### Security & Infrastructure

- `self.services.security` - Security operations
  - Authentication
  - Authorization
  - Token management

### Code Examples

Examples of how to use services in workflow actions or methods:

    # In workflow actions or methods
    result = await self.services.<service>.<method>(parameters)

    # Example: Using AI service
    response = await self.services.ai.process(prompt="Analyze this document", documents=[...])

    # Example: Using SharePoint service
    files = await self.services.sharepoint.searchFiles(pathQuery="sites/my-site/documents")

    # Example: Using generation service
    document = self.services.generation.createDocument(format="pdf", content={...})

### Microservices Architecture Diagram

## RBAC System

### Overview

The Role-Based Access Control (RBAC) system provides complete UI configuration per tenant and user. It enables fine-grained control over data access, UI visibility, and resource availability.

#### Data Access

Table and field-level permissions for database operations. Control who can read, create, update, or delete specific data.

#### UI Access

Component and feature visibility management. Configure exactly which UI elements each user or role can see.

#### Resource Access

System resource availability control. Manage access to AI models, actions, and other platform resources.

### Access Levels: Opening Logic

For DATA context, the system uses opening rights with four access levels. These levels determine what data a user can access:

#### none (n)

No access - item is completely hidden/disabled

#### my (m)

My records - only records created by the current user

#### group (g)

Group records - records within the same mandate (group context)

#### all (a)

All records - full access to all records in the mandate

### View Logic: Open + Close

The `view` attribute controls visibility and enablement. This is the fundamental on/off switch for all RBAC contexts:

- view: true - Item is visible/enabled
- view: false - Item is hidden/disabled (regardless of other permissions)

Key Rule: Only objects with `view: true` are shown. This applies to:

- DATA Context: Controls whether tables/fields are accessible
- UI Context: Controls whether UI elements are visible
- RESOURCE Context: Controls whether resources are available

### Rule Specificity & Hierarchy

The RBAC system uses a cascading hierarchy where more specific rules override generic ones:

1. Generic Rules (`item = null`) - Apply to all items in context
2. Specific Rules (`item = "table.field"` or `item = "ui.component.feature"`) - Override generic rules

Resolution Logic: Within a single role, the most specific rule wins. Across multiple roles, opening (union) logic applies - if ANY role enables something, it is enabled.

### Opening Rights Principle

For DATA context, read permission (R) is a prerequisite for create/update/delete operations (CUD). This ensures data integrity and proper access control:

- If Read = "n": No CUD operations allowed
- If Read = "m": CUD operations limited to "m" or "n"
- If Read = "g": CUD operations limited to "g", "m", or "n"
- If Read = "a": CUD operations can be "a", "g", "m", or "n"

Key Rule: You can ONLY create/update/delete if you have read right.

### Context Types

RBAC rules apply to three different context types, each serving a specific purpose:

#### DATA

Database tables and fields. Controls read/create/update/delete permissions.

Example: `item: "UserInDB.email"`

#### UI

UI elements and features. Controls component visibility.

Example: `item: "playground.voice.settings"`

#### RESOURCE

System resources (AI models, actions, etc.). Controls resource availability.

Example: `item: "ai.model.anthropic"`

### RBAC System Diagram

## UI Architecture

### Playground UI

The Playground serves as the main entry point and demonstration UI. It's built with React and provides a comprehensive interface for workflow interaction:

- Chat interface for workflow interaction
- Workflow editor for configuration
- Document management
- Connection management
- Voice input/output capabilities

### RBAC-Driven UI Configuration

The UI is completely configurable via RBAC rules. This allows customers to configure exactly the UI they need for their use case:

- Per tenant configuration
- Per user configuration
- Component-level visibility control
- Feature-level access control

This allows customers to configure exactly the UI they need for their use case.

### External UI Integration

Additional UIs can be easily integrated via the REST API. All UI components communicate with the platform through the standardized REST API, ensuring consistent behavior and security:

- Chatbots: Build custom chatbots using the workflow API
- Customer UIs: Create customer-specific interfaces in React, JavaScript, or other languages
- Mobile Apps: Integrate via REST API from mobile applications
- Third-Party Tools: Connect existing tools via webhooks and API

All UI components communicate with the platform through the standardized REST API, ensuring consistent behavior and security.

### Available UI Components

The platform provides reusable UI components that can be configured via RBAC:

- Chat interface
- Document viewer/editor
- Workflow editor
- Connection manager
- Settings panels
- Dashboard widgets

### UI Architecture Diagram

## Big Picture & Future Vision

### Vendor-Independent Platform

#### AI Model Independence

PowerOn is designed as a vendor-independent platform regarding AI models:

- Support for multiple AI providers (OpenAI, Anthropic, Google, Azure, etc.)
- Dynamic model selection based on task requirements
- Easy addition of new AI providers
- No vendor lock-in - customers can switch providers seamlessly

#### Connector Independence

Universal connector architecture supporting all major platforms:

- Microsoft: SharePoint, Outlook, Teams, OneDrive, Azure
- Google: Drive, Gmail, Workspace, Cloud
- Amazon: AWS services, S3, etc.
- Other: Jira, Slack, Salesforce, and many more

Customers are not locked into a single vendor ecosystem.

### Graphical Workflow Modeling

#### Visual Customer Journey Design

Future capability to graphically model workflows for customer journeys:

- Drag-and-drop workflow editor
- Visual representation of customer journeys
- Easy workflow modification without coding
- Template library for common workflows
- Workflow versioning and testing

This makes workflow creation accessible to business users, not just developers.

### MCP Integration in Customer Copilot

#### Microsoft Copilot Plugin Architecture

Integration of PowerOn actions as MCP (Model Context Protocol) plugins in the customer's Copilot:

- Native Copilot Integration: PowerOn workflows accessible directly from Microsoft Copilot
- Action Library: All PowerOn actions available as Copilot plugins
- Seamless Experience: Customers use PowerOn capabilities without leaving Copilot
- Enterprise Workflows: Complex workflows triggered from simple Copilot conversations
- Data Privacy: All PowerOn privacy features work seamlessly in Copilot context

This enables customers to leverage PowerOn's powerful workflow capabilities directly from their familiar Copilot interface.

### Platform Evolution

#### Today

- REST API-based workflows
- Playground UI
- Multiple AI providers
- Standard connectors

#### Near Future

- Graphical workflow editor
- MCP Copilot integration
- Enhanced pre-processing
- Advanced AI selection

#### Future

- AI-powered workflow generation
- Multi-platform Copilot support
- Edge computing expansion
- Federated learning

### Big Picture & Future Vision Diagram

## Integration Guide

### REST API

The platform exposes a comprehensive REST API for all operations. This API serves as the primary integration point for external developers:

- Workflow API: Create, execute, and manage workflows
- Document API: Upload, download, and process documents
- Connection API: Manage external connections (SharePoint, Outlook, etc.)
- RBAC API: Manage roles and permissions
- Options API: Dynamic options for UI components

### Building Blocks for Developers

Developers can extend the platform by creating custom components in these areas:

#### Workflow Methods

Create custom workflow methods by extending `MethodBase` and registering actions.

#### Services

Extend the services layer by creating new service modules following the existing pattern.

#### Connectors

Build connectors for external systems (databases, APIs, services) using the connector interface.

#### UI Components

Create React components that integrate with the REST API and respect RBAC rules.

### Development Workflow

Follow these steps to get started with platform development:

1. Understand the Architecture: Review this document and codebase structure
2. Set Up Development Environment: Clone repository and configure local environment
3. Choose Integration Point: Decide whether to extend workflows, services, or UI
4. Follow Patterns: Use existing code as reference for consistent implementation
5. Test with RBAC: Ensure your changes respect RBAC rules
6. Document: Update documentation for your changes

### Key Integration Points

Main directories where developers can add new functionality:

- `gateway/modules/workflows/methods/` - Add new workflow methods
- `gateway/modules/services/` - Add new microservices
- `gateway/modules/connectors/` - Add new connectors
- `gateway/modules/routes/` - Add new API endpoints
- `gateway/modules/features/` - Add new features