Architecture One-Pager

AI Executive Office — CXO Assistant Platform · Solution Architecture v1.0 · Azure-native, 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 Azure-native product 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 model 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. 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 model 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 by policy, network and key custody — not sovereign by contractual assurance

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 typed tool plane that carries the caller's on-behalf-of assertion. 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 DAX measures in a governed semantic model; forecasts and anomaly scores from registered ML endpoints. The language model classifies, plans and narrates. It never produces a figure. This is both the trust control and the largest cost 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 compute with per-tenant indexes, row-level security and per-tenant keys. Siloed tenants get a dedicated subscription from the same Bicep. 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 enforced, not asserted (ADR-27) — Azure Policy denies resource creation outside the permitted region, the firewall denies unlisted egress, and the customer holds the encryption key in a managed 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 Teams, 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 model, 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. Power BI reads the same semantic model 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.

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 model 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 Teams
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: 32 records across 9 areas, each with the alternatives that lost and what the choice costs.