Architecture One-Pager

AI Executive Office — CXO Assistant Platform (On-Premises) · Solution Architecture v1.1 · fully on-premise, open source, multi-tenant, sovereign-capable · Data & AI Global Practice · 2026-09

A governed conversational layer over enterprise data, specialist AI agents, decision intelligence and controlled execution — delivered as one product that runs entirely inside the customer's own data centre, on open source, and that many organisations can buy.

An executive's view of their organisation is assembled by people. A question such as "which suppliers are putting projects that are already financially at risk into further trouble?" crosses an ERP, a procurement system and a portfolio tool, and today it is answered by a chief of staff spending two days reconciling three exports. The information exists; the joins, the trust and the audit trail do not. The failure is not a missing dashboard — it is that no single component owns the relationship between a supplier, a contract, a project and a budget line, and nothing records why a decision was taken once it is.

The platform puts a single conversational front door over that estate and makes four things structural. Numbers come from one governed semantic layer and never from a language model. Every retrieval carries the caller's own permissions, so the AI can never see more than the person asking. Every claim in an answer is bound to an evidence identifier that is snapshotted, not re-queried. And the system may propose an action but never perform one — a separate execution plane, holding the only write credentials in the estate, acts after a human approves, and then watches whether the intervention worked. A fifth property is structural to this variant in particular: the model weights sit on the customer's own accelerators, so no prompt, no retrieved passage and no figure ever crosses the building's perimeter. What the executive experiences is a morning brief and a conversation; what the architecture actually is, is a decision record with a loop closed around it.

What it is, and what it is not

• A decision intelligence platform — not a chatbot with company data attached
• A governed read layer plus one narrow write path — not an agent with credentials to enterprise systems
• One product configured per tenant — not a bespoke build repeated per customer
• A semantic layer that owns every KPI — not a model that calculates figures from retrieved text
• An audit trail that reconstructs what the approver saw — not a chat log with timestamps
• Sovereign because the hardware is in the building — not sovereign by contractual assurance
• Open-source components the customer can fork — not an open-source badge on a hosted dependency

The decisions that are the architecture

1. The decision record is the system of record (ADR-01) — Situation, evidence, options, approval, action and outcome are one durable entity. The conversation is a rendering of it. Everything about auditability, closed-loop monitoring and reopening a failed intervention follows from this one modelling choice.
2. The model never touches data (ADR-02) — All access is through a tool plane of first-party Model Context Protocol servers, each call carrying the caller’s exchanged token. There is no text-to-SQL against production, and the orchestrator holds no credential for any store — so compromising it yields the ability to ask questions as the caller, and nothing more.
3. Deterministic before generative (ADR-03) — KPIs come from measures in a governed semantic layer; forecasts and anomaly scores from models registered in MLflow and served on KServe. The language model classifies, plans and narrates. It never produces a figure. This is both the trust control and, on a fixed GPU budget, the largest capacity control.
4. Abstention is a first-class outcome (ADR-04) — Every claim is bound to an evidence identifier and mechanically checked for groundedness. Unsupported claims are removed and the gap is stated. A platform that never says "I do not have sufficient evidence" is not more accurate, only less honest.
5. Isolation is a purchased tier (ADR-25) — Pooled tenants share a cluster with a per-tenant index, row-level security and per-tenant keys. Siloed tenants get their own cluster, their own GPUs and their own database hosts, from the same Terraform. One codebase, two deployment shapes, and a tier change is a migration rather than a fork.
6. Execution is a proposal, never a write (ADR-21) — Approved actions go to a single execution plane holding a distinct connector identity per target system, with an idempotency key and an authority re-check at execution time. The AI identity holds no write scope anywhere in the estate.
7. Sovereignty is physical, then enforced (ADR-27) — There is no cloud plane to leak into: every process runs on hardware the customer can point at. Admission control refuses any workload without a residency label, the perimeter firewall denies unlisted egress, and the customer holds the encryption key in its own HSM. Revoking the key makes the data unreadable — which is a guarantee rather than a clause.

Non-functional targets

Targets are stated so they can be tested and argued with. Where a number is an assumption rather than a measurement it says so, because a target invented to fill a table is worse than an admitted gap.

Scope

In scope

• Conversational front door in the enterprise chat client, web and mobile, with a role-aware executive Today view
• Executive orchestrator plus ten specialist capability packs sharing one runtime
• Governed tool plane over ERP, finance, procurement, projects, HR, CRM, supply chain and the document estate
• Canonical semantic layer, entity graph and enterprise retrieval with per-caller security trimming
• Decision engine: situation, evidence, root cause, forecast, options, recommendation, confidence
• Governed execution with human approval, plus closed-loop outcome monitoring
• Multi-tenant control plane, industry packs, and a tenant configuration studio
• Sovereignty, audit, lineage and AI governance as product capabilities rather than a later phase

Explicitly out of scope

• Replacing any system of record. The platform reads them and, in two places, writes to them
• Replacing the enterprise BI estate. The customer's BI tool reads the same semantic layer rather than a parallel one
• Autonomous action above a tenant-configured threshold. Low-risk automation is a later, opt-in capability
• Master data management as a product. Entity resolution is performed for the platform's own model, not offered as an MDM service
• Model training on tenant data. Grounding is retrieval and tools; no tenant corpus is used to fine-tune a shared model
• Voice, and email and calendar where the tenant does not permit it — both are per-tenant switches, and the architecture must be correct with them off

The four-week prototype

Not a slice of the platform, and not twenty disconnected features. The prototype proves one thing: that the loop closes. A single executive scenario carried end to end — see, understand, predict, decide, act, monitor — is more convincing to a sponsor than any breadth demonstration, and it is the only way to discover early that entity resolution, not the AI, is the hard part. On-premise adds one constraint to the four weeks: the accelerators have to already be in the building. Where they are not, the prototype runs on a single borrowed GPU host with a smaller model and states that latency figures are provisional.

1. Three sources: ERP/finance, procurement, projects — chosen because they share the supplier and project keys the flagship question needs
2. Three capability packs: finance, procurement risk, projects
3. One orchestrator, one tool plane with roughly eight typed tools
4. One semantic layer with a dozen governed measures, reconciled against the customer's own board pack
5. One entity graph joining supplier, contract, purchase order and project
6. One executive Today view and one conversational surface, in the enterprise chat client
7. Decision record, approval and one governed write to procurement
8. Golden-question suite written by the customer, run as the go-live gate

• "What should I know this morning?" — the detection sweep surfaces a project delay
• "Why is this happening?" — the investigation crosses ERP, procurement and project data
• "What happens if we do nothing?" — a registered forecast endpoint, with an interval
• "What are my options?" — three interventions with cost, risk and delay
• "Proceed with option 2" — approval, governed write, external reference recorded
• "Is the situation improving?" — the outcome monitor answers, or reopens the decision

Open risks, carried rather than hidden

The reasoning behind every component and technology choice is in the Architecture Decision Record: 34 records across 9 areas, each with the alternatives that lost and what the choice costs.