AI Executive Office — CXO Assistant Platform (On-Premises)  ·  View 08 of 30  ·  3 · Structure

Container Architecture

The deployable units inside one tenant, the technology behind each, and which of them holds a credential.

Editable source SVG draw.io All views
Primary data centre — one tenant runtime, in country Edge HAProxy + WAF active / active Kong Gateway internal only Mattermost bot webhook service Application plane — Kubernetes namespace per tenant Experience API FastAPI · 3–30 pods Orchestrator host LangGraph MCP tool servers one per domain Decision service option sets Investigation runner Temporal worker Config service tenant packs Governance API audit export AI plane — GPU node pool, no egress vLLM inference Llama 3.3 70B Agent runtime LangGraph + MCP OpenSearch 3 data nodes Guardrail service Llama Guard 3 KServe endpoints forecast · anomaly Data plane Trino + Spark MinIO + Iceberg Semantic model Cube · row policies Neo4j causal cluster PostgreSQL decision store Redis state · semantic cache Evidence store MinIO · object lock Integration and execution Airflow pipelines Kafka ingest Temporal action sagas Camunda 8 execution plane Edge collector DMZ reach Platform services Keycloak token exchange Vault + HSM tenant key OpenMetadata lineage Prometheus Grafana · Loki · Tempo OpenSearch SIEM SIEM ERP and finance Procurement Projects Document estate Mail and calendar mTLS in-cluster mTLS approved write CDC pull as the caller Container Architecture — Deployable Units in One Tenant Interface / broker Application we own Data store Security / platform Queue / topic External / third party synchronous batch Pooled-tier tenants share the AI and data planes with a per-tenant index, schema and row policy. The siloed tier deploys this whole picture on its own cluster — view 10. v 1.0 · owner Data & AI Global Practice · date 2026-09

Decisions and rationale

  • Kubernetes is the substrate for everything except the databases: one cluster per site, a namespace per tenant in the pooled tier, a whole cluster per tenant in the siloed one. PostgreSQL, Neo4j and the object store run outside it on dedicated hardware, because a stateful rebuild during an incident is not a place to discover the storage driver
  • Temporal for investigations because an investigation is a long-running, resumable orchestration with checkpoints — not a long HTTP request. Workflow state survives a pod restart, which is what makes the asynchronous experience honest rather than a spinner
  • Every service authenticates with a mesh-issued workload identity (SPIFFE), and every secret it still needs is leased from Vault with a short time to live. There are no connection strings in configuration anywhere in this diagram
  • MCP tool servers are their own deployable, one container per domain, so a finance tool change ships without redeploying the orchestrator and a misbehaving server is restarted alone

Assumptions

  • Eight H100-class GPUs per site are assumed for the 07:10 brief spike: a 70B reasoning model held resident, a 7B router and the embedding and reranking models sharing a MIG-partitioned card. GPU lead times are months, so this is sized and ordered before contract, not after
  • Twelve worker cores and 500 GB of usable object storage is the starting analytical footprint for a mid-size tenant. Sizing is a per-tenant exercise driven by refresh frequency, not user count

Deliberate omissions

  • Every service-to-service hop runs over mutual TLS inside the mesh, but that is drawn only in views 21 and 26, where it is the subject rather than clutter
  • The self-hosted integration runtime is drawn once; in practice one runs per on-premises network the tenant exposes
◀  Layered Architecture All views Integration Catalogue  ▶
Solution Architecture v1.1 · fully on-premise, open source, multi-tenant, sovereign-capable · Data & AI Global Practice · 2026-0908-container-architecture