AI Containers¶
Executive Summary¶
AI Containers defines the logical AI architecture containers in the Algosure C4 Level 2 architecture: AI orchestration service, AI provider gateway, vector store / semantic memory store, and their relationship with the Spring Boot Modulith backend and Digital Professionals.
Why This Exists¶
Algosure is AI-native, but AI must remain governed by AIOS, source-domain ownership, tenant isolation, explainability, human approval, and security. The AI container view prevents AI capabilities from bypassing DDD boundaries or creating untraceable business behavior.
Owner¶
The owner is the Chief Product Officer and Enterprise Architect.
Business Value¶
Clear AI container boundaries support safe AI execution, evidence-backed recommendations, reusable Digital Professional workflows, provider flexibility, and auditable AI outcomes.
AI Container View¶
flowchart TB
Backend[Spring Boot Modulith Backend]
AIOS[AI Orchestration Service]
Professionals[Digital Professionals]
Gateway[AI Provider Gateway]
Providers[External AI Providers]
Vector[(Vector Store / Semantic Memory Store)]
Documents[(Object / Document Storage)]
Audit[Audit and Explainability Evidence]
Approver[Human Approver]
Backend --> AIOS
AIOS --> Professionals
Professionals --> AIOS
AIOS --> Gateway
Gateway --> Providers
AIOS --> Vector
AIOS --> Documents
AIOS --> Audit
AIOS --> Backend
Backend --> Approver
Approver --> Backend
AI Container Responsibilities¶
| Container | Logical Responsibility |
|---|---|
| AI orchestration service | Coordinates AIOS work packets, context assembly, Digital Professional delegation, reasoning steps, memory access, tool use policy, confidence capture, approvals, and output return. |
| AI provider gateway | Mediates calls to external AI providers, preserving provider abstraction, tenant context, safety policy, usage governance, request tracing, and response handling. |
| Vector store / semantic memory store | Supports retrieval-augmented context, semantic search, memory projections, embeddings, and AIOS-approved memory under tenant and source governance. |
| Object / document storage | Provides governed access to documents and evidence used by AI workflows, subject to tenant authorization and source-domain rules. |
| Spring Boot Modulith backend | Owns domain facts, workflow state, approval policy, authoritative commands, and acceptance or rejection of AI outputs. |
| Digital Professionals | Represent scoped AI worker roles inside Algosure, operating under AIOS orchestration and approved guardrails. |
AIOS Flow¶
sequenceDiagram
participant Backend as Spring Boot Modulith Backend
participant AIOS as AI Orchestration Service
participant Memory as Vector Store / Semantic Memory Store
participant Docs as Object / Document Storage
participant Gateway as AI Provider Gateway
participant Provider as External AI Provider
participant Human as Human Approver
Backend->>AIOS: Request governed AI work with tenant and domain context
AIOS->>Memory: Retrieve approved semantic context
AIOS->>Docs: Retrieve authorized document evidence
AIOS->>Gateway: Request model work under policy
Gateway->>Provider: Submit provider request
Provider-->>Gateway: Return provider response
Gateway-->>AIOS: Return normalized AI response
AIOS-->>Backend: Return recommendation, evidence, confidence, assumptions
Backend->>Human: Request approval when required
Human-->>Backend: Approve, reject, or request revision
AI Boundary Rules¶
| Rule | Meaning |
|---|---|
| AIOS does not own source facts | Source facts remain in Domains or external authorities; AIOS assembles authorized context and returns governed outputs. |
| Digital Professionals are internal | Digital Professionals are not external actors or independent systems; they operate inside Algosure under AIOS control. |
| Provider access is mediated | AI provider usage must go through a gateway so tenant context, policy, usage controls, safety, and audit are consistent. |
| Memory is not unrestricted knowledge | Semantic memory requires source attribution, tenant scope, retention policy, approval where required, and explainability support. |
| Human approval remains explicit | AI-generated submissions, commercial actions, payment actions, funding decisions, and high-impact recommendations require approval where policy requires it. |
| Outputs return through backend workflows | AI outputs must be accepted, rejected, revised, or stored through domain and workflow-owned paths. |
Security and Governance Alignment¶
| Concern | AI Container Requirement |
|---|---|
| Tenant isolation | AI requests, memory retrieval, documents, prompts, outputs, usage records, and audit evidence must remain tenant-scoped. |
| Explainability | AI outputs must capture evidence, assumptions, confidence, source references, and decision path where material. |
| Auditability | Material AI actions must be traceable to tenant, user, workflow, Domain, Digital Professional, provider request, and approval status. |
| Provider abstraction | The architecture must allow provider changes without changing Domain ownership or workflow semantics. |
| Data minimization | AI containers should receive only the context required for the approved task. |
Non-Implementation Boundary¶
This document does not define:
- AI model provider selection.
- Prompt templates.
- Agent runtime code.
- Tool execution implementation.
- Embedding model.
- Vector database product.
- Token limits.
- Safety classifier implementation.
- Provider-specific API calls.