Product: VedaCLOUD ATLAS
Publisher: VedaCLOUD.AI
Document type: Technical architecture overview
Version: Architecture overview — version to be assigned

1. Introduction#

VedaCLOUD ATLAS is a modular enterprise AI platform designed to connect organizational knowledge, AI models, intelligent agents, and enterprise workflows within a configurable deployment architecture.

Its architecture brings together document ingestion, information retrieval, knowledge graphs, model orchestration, agent execution, identity and access controls, and operational services. These capabilities are implemented through cooperating application services and dedicated infrastructure components.

ATLAS is designed to support local-model deployments, configured hybrid environments, and deployments with restricted or disabled external connectivity. The actual capabilities and security boundaries of an installation depend on its configuration, infrastructure, connected providers, and operational controls.

2. Architecture at a glance#

ATLAS can be understood as six cooperating layers:

1. Experience and access layer — user-facing applications, administrative capabilities, and API entry points.
2. Application services layer — authentication, user and administration functions, document management, search, connectors, and related platform services.
3. AI intelligence layer — retrieval-augmented generation (RAG), embedding, OCR, model routing, knowledge graphs, timeline capabilities, and other AI services.
4. Agent and workflow layer — workflow composition, model-assisted steps, retrieval and graph operations, and controlled tool execution.
5. Data and knowledge layer — relational records, object storage, vector and keyword retrieval, graph data, caching, and session-related state.
6. Infrastructure and operations layer — container orchestration, networking, monitoring, configuration, backup, and recovery.

Identity, authorization, privacy controls, and operational oversight apply across these layers rather than being confined to a single component.

3. Logical architecture diagram#

flowchart TB
    U["Users and Enterprise Applications"]
    E["Experience, Administration and API Access"]

    subgraph APP["Application Services"]
        G["API Gateway"]
        I["Identity, Authentication and RBAC"]
        D["Document and Ingestion Services"]
        S["Search and Knowledge Access"]
        C["Connectors and Platform Administration"]
    end

    subgraph AI["AI Intelligence Services"]
        R["RAG and Hybrid Retrieval"]
        O["OCR, Extraction and Embeddings"]
        L["LLM Router and Model Integrations"]
        K["Knowledge Graph and Timeline"]
    end

    subgraph AG["Agent and Workflow Services"]
        W["Agent Studio and Workflow Engine"]
        T["Configured Tools and Sandboxed Execution"]
        V["Evaluation and Feedback"]
    end

    subgraph DATA["Data and Knowledge Infrastructure"]
        P["PostgreSQL"]
        M["MinIO Object Storage"]
        X["Weaviate Vector and Keyword Search"]
        Q["Memgraph Knowledge Graph"]
        RED["Redis Cache, Sessions and Queues"]
    end

    subgraph OPS["Deployment and Operations"]
        DC["Containerized Services"]
        MON["Monitoring, Logs and Audit"]
        B["Backup and Recovery"]
    end

    U --> E
    E --> G
    G --> I
    G --> D
    G --> S
    G --> C

    D --> O
    D --> M
    D --> P
    S --> R
    R --> X
    R --> P
    R --> L
    O --> L
    K --> Q
    K --> P

    W --> R
    W --> K
    W --> L
    W --> T
    W --> V

    G --> RED
    W --> RED

    APP -.-> DC
    AI -.-> DC
    AG -.-> DC
    DATA -.-> DC
    DC --> MON
    DATA --> B

The diagram is a logical view of the documented architecture, not a deployment topology. It illustrates major component relationships; it does not imply that every optional service is enabled in every installation.

4. Experience and application services#

The application layer provides the entry points through which users and other applications interact with ATLAS.

API gateway#

The gateway provides a controlled entry point to application services. It supports request routing and participates in the platform’s authentication and authorization flow. The documented design removes untrusted client-supplied identity headers before establishing verified request context.

External exposure should be restricted through the deployment’s reverse proxy, network policies, and gateway configuration.

Identity and access#

Identity-related services support authentication, role-based access control, configurable multi-factor authentication policies, and options for single sign-on and directory synchronization.

Authorization is important throughout the platform, including when users search documents or execute agent workflows. The precise enforcement model depends on configured identity integrations, policies, and the permissions associated with each resource.

Document, search, user, and administration services#

Dedicated application services support document management, search, user and administrative functions, connectors, licensing, and related platform capabilities. This modular approach separates responsibilities and allows the deployment to manage these functions as cooperating services.

5. Data ingestion and enterprise knowledge#

ATLAS transforms source information into content that can be indexed, retrieved, and used in AI workflows.

A typical document-processing path includes:

1. Ingestion: Accept supported document and content formats.
2. Extraction: Extract text and relevant structure; apply OCR when required.
3. Normalization: Prepare content and metadata for downstream processing.
4. Segmentation: Split content into retrieval-oriented chunks.
5. Enrichment: Generate embeddings and, where configured, extract entities and relationships.
6. Indexing: Store source files, records, searchable content, and graph information in the relevant data services.
7. Retrieval: Use indexed content in search, knowledge access, and AI workflows.

Supported inputs include common office documents, PDFs, HTML, text, Markdown, CSV, images, and supported email formats. Exact extraction quality depends on file characteristics, OCR configuration, and processing settings.

Storage responsibilities#

Component	Architectural responsibility
PostgreSQL	Relational records and core system-of-record data
MinIO	Uploaded files and object storage
Weaviate	Vector and keyword-oriented retrieval
Memgraph	Graph-based knowledge operations
Redis	Caching, session-related functions, rate limiting, and queue-related operations

These components serve different purposes and are not interchangeable. Data consistency and recovery procedures must account for the relationship between source records, stored documents, indexes, and derived graph data.

6. Retrieval-augmented generation and model orchestration#

ATLAS combines enterprise knowledge retrieval with configurable model integrations to support grounded AI responses.

Retrieval and grounding#

A typical RAG request follows this sequence:

1. A user or workflow submits a question.
2. The application identifies the applicable request context and access permissions.
3. The retrieval layer searches indexed knowledge using configured semantic and keyword techniques.
4. Relevant content is assembled into context for the selected model.
5. The model generates a response.
6. Source references are returned where supported by the workflow and available source metadata.

Retrieval can include document, page, or paragraph references where available. Permission-aware retrieval is intended to restrict knowledge access according to applicable authorization rules; it should be validated with explicit negative-access tests.

Model router#

The model-routing layer provides an abstraction over configured model endpoints. Documented integration options include local serving environments such as Ollama, vLLM, and LM Studio, alongside configured external providers such as OpenAI, Azure OpenAI, Google, Anthropic, and Hugging Face.

Routing policies can consider configured priorities, latency, cost, quality, load, and failover behavior. Actual routing outcomes depend on the enabled providers, available models, credentials, policy settings, and runtime conditions.

The use of an external model provider can change where prompts and retrieved context are processed. Those data flows must be assessed as part of the deployment’s privacy and residency design.

7. Knowledge graph architecture#

The knowledge graph complements document search by representing entities and relationships that can be explored across connected information.

ATLAS supports configured entity and relationship extraction, provenance-aware knowledge representation, and graph traversal for relationship-oriented queries.

The architecture uses PostgreSQL for core records and Memgraph for graph operations. The documented design includes fallback behavior to PostgreSQL when the graph service is unavailable, where applicable.

The graph is a derived knowledge representation, not a substitute for the underlying source records. Extraction quality, relationship accuracy, provenance, and synchronization should be tested for the target data sources.

8. Agent and workflow architecture#

ATLAS Agent Studio supports the composition of workflows that combine AI reasoning, knowledge access, and configured tools.

A workflow may include:

• Model interaction and structured outputs.
• Enterprise search and RAG.
• Knowledge graph queries.
• Configured web research.
• HTTP API calls and MCP tools.
• Sandboxed Python execution.
• Conditional branches, variables, and templates.
• Child-agent workflows.
• Execution history, debugging, version history, and rollback capabilities.

Workflow execution model#

The workflow engine coordinates configured steps and passes relevant inputs and outputs between them. Access to documents and tools is designed to follow the calling user’s permissions, subject to the applicable implementation and configuration.

Execution limits, tool permissions, network restrictions, and sandbox behavior should be configured and tested before sensitive workloads are enabled. A workflow’s use of a tool or external service also introduces that service’s own authentication, data-handling, and availability considerations.

9. Security, privacy, and governance#

Security and privacy are cross-cutting architectural concerns. The platform documents several controls intended to support governed AI operation.

Identity and authorization#

• Authentication and role-based access control.
• Configurable MFA and supported identity-provider integrations.
• Permission-aware knowledge retrieval.
• Access scopes for configured agent workflows.

Secrets and data protection#

• Protected storage for provider credentials.
• Support for integration with a dedicated secrets-management system.
• Configurable PII masking for applicable model-request paths.
• Deployment-level controls for network exposure and outbound connectivity.

AI safety and tool controls#

• Configurable prompt-injection and jailbreak defenses.
• Output-safety and answer-verification controls.
• Restrictions on tool access and sandboxed execution paths.

These controls are not guarantees against every attack or information disclosure. Their effectiveness depends on implementation, configuration, and testing.

For sensitive deployments, review the full data path—including prompts, retrieved context, embeddings, indexes, logs, backups, model calls, and outputs—to establish where information is stored and processed.

10. Deployment architecture#

ATLAS uses a modular, containerized service architecture with a documented Docker Compose deployment approach.

The reference environment can be configured for CPU-based operation, with optional NVIDIA GPU acceleration for suitable workloads. Local models can be used where the required model-serving infrastructure is installed and configured. Hybrid deployments can connect to external providers when permitted.

An air-gapped configuration is documented, with external web research and outbound model-provider access disabled in that mode. Air-gapped operation must be validated against the actual deployment files, network rules, model assets, and enabled services.

The presence of containerization does not by itself establish high availability, production isolation, automatic scaling, or a particular disaster-recovery capability. Those characteristics depend on the infrastructure and operational design selected for deployment.

11. Observability and lifecycle operations#

Operational services support the administration and maintenance of the platform.

Documented functions include service health and monitoring capabilities, metrics, gateway audit logs, workflow execution history, troubleshooting guidance, and backup and restore procedures.

The recovery design includes restoring core records, uploaded files, and configuration, rebuilding vector indexes from source data, and resynchronizing graph data from the system of record where applicable.

Production operations should define and test:

• Monitoring coverage and alert thresholds.
• Log retention and access controls.
• Backup frequency and retention.
• Recovery time and recovery point objectives.
• Upgrade and rollback procedures.
• Incident handling and access reviews.
• Capacity, latency, and model-usage monitoring.

No specific uptime commitment or recovery objective is implied by this architecture overview.

12. Integration and extensibility#

ATLAS combines application services with configurable connectors, model integrations, and workflow tools. This allows enterprise systems to participate in knowledge ingestion and AI-assisted processes through the supported integration paths.

Connector availability and maturity vary. Each required integration should be tested for authentication, permissions, data mapping, error handling, rate limiting, logging, and recovery before production use.

13. Architecture principles#

The documented architecture reflects the following design principles:

• Modularity: Separate application and AI responsibilities into cooperating services.
• Composable intelligence: Combine retrieval, models, knowledge graphs, and tools in configurable workflows.
• Multiple model options: Integrate local and configured external model providers.
• Knowledge grounding: Connect AI responses to retrievable enterprise information and available source references.
• Permission awareness: Apply identity and authorization considerations to knowledge access and workflow execution.
• Operational recoverability: Maintain source records and documented procedures for restoring or rebuilding derived data.
• Deployment flexibility: Support different deployment configurations subject to infrastructure and network requirements.

14. Architecture scope and validation#

This overview describes the logical structure and documented capabilities of ATLAS. It should not be interpreted as proof that every feature is enabled, that every connector is production-ready, or that a specific security certification or deployment guarantee has been achieved.

Before using ATLAS for sensitive or business-critical workloads, validate the deployed configuration, service dependencies, data flows, authorization behavior, model-provider boundaries, network isolation, monitoring, and recovery procedures.

Conclusion#

VedaCLOUD ATLAS brings together enterprise application services, document intelligence, hybrid retrieval, knowledge graphs, model orchestration, and agentic workflows within a modular architecture.

Its value lies in connecting organizational knowledge with configurable AI capabilities while providing architectural points for identity, access control, operational oversight, and deployment-specific privacy measures. The final security, scalability, and resilience characteristics depend on how the platform is configured, deployed, and operated.

VedaCLOUD ATLAS — Enterprise knowledge. Governed AI. Intelligent automation.

For platform information, contact connect@vedacloud.ai.

---

Architecture documentation should be reviewed alongside the deployment configuration and current implementation before being used as a formal technical assurance document.