# AI Executive Office — CXO Assistant Platform **Solution Architecture v1.0 · Azure-native, multi-tenant, sovereign-capable · Data & AI Global Practice · 2026-09 · 30 views · 32 architecture decision records** A multi-tenant AI Executive Office on Azure, architected as a **decision intelligence platform rather than a chatbot with company data**: a governed conversational layer over enterprise systems, specialist agents, decision intelligence and controlled execution, built for a sovereign public-sector scenario and for the commercial tenants that come after it. Seven decisions carry the design: - The **decision record** — situation, evidence, options, approval, action, outcome — is the system of record. The conversation is a rendering of it. - The model **never touches data**. Every read goes through a typed tool plane carrying the caller's on-behalf-of assertion, so the orchestrator holds no credential for any store. - **Deterministic before generative.** KPIs come from DAX measures in one governed semantic model, forecasts from registered ML endpoints. The model classifies, plans and narrates; it never produces a figure. - **Abstention is a first-class outcome.** Claims are bound to evidence identifiers and checked mechanically; unsupported claims are removed and the gap is stated. - **Isolation is a purchased tier.** Pooled and siloed deploy from one codebase, with sovereign tenants siloed by default. - **Execution is a proposal, never a write.** One execution plane holds every write credential in the estate, one connector identity per target system, after a human approval. - **Sovereignty is enforced, not asserted** — Azure Policy denies out-of-region creation, the firewall denies unlisted egress, and the customer holds the key. Thirty-two decision records carry the reasoning for every component and technology choice on these views. Each gives the forcing question, the concrete Azure mechanism, the alternatives that lost (including those that are right for a different organisation), what the choice costs, when to choose differently, and the transferable lesson. They are rendered on the landing page of the diagram set, directly below the index and below the architecture one-pager, and again as two markdown documents the site renders in its own reading layout: [docs/architecture-one-pager.md](docs/architecture-one-pager.md) (~10 min) and [docs/decision-record.md](docs/decision-record.md) (~83 min). --- ## What is here | Path | Contents | |---|---| | `diagrams/index.html` | The landing page: 30 views in seven acts, every format linked, then the **architecture one-pager** and the **full decision record** below the index | | `diagrams/*.html` | One self-contained page per view: the inlined diagram plus the reasoning it leaves out, with copy / PNG / PDF export | | `diagrams/svg/*.svg` | The same 30 views as SVG with the diagram XML embedded; they re-open in diagrams.net fully editable | | `diagrams/drawio/*.drawio` | draw.io native source | | `docs/architecture-one-pager.md` | The one-pager as markdown — the short executive read, and the first document the site links | | `docs/decision-record.md` | The 32 decision records as markdown | | `specs/part-a..d.json` | Diagram specifications, the source of truth for every view | | `specs/manifest-a..b.json` | Acts, page titles, subtitles and the decision / assumption / risk cards | | `specs/adr.json` | The one-pager, the 32 decision records, the capability-to-technology table and the Azure service table | | `scripts/build.sh` | Rebuilds every deliverable from the specs | | `scripts/pin-icons.mjs` | Pins one mark per component, and stops the resolver putting a rival cloud's logo on an Azure diagram | | `scripts/render-adr.mjs` | Validates `adr.json` and renders it into `diagrams/index.html` and the two `docs/*.md` | | `ask.md` | The original requirement | To rebuild after editing a spec: ```bash bash scripts/build.sh # requires Node 20+ and nothing else ``` Edit `specs/part-*.json` and `specs/manifest-*.json`, never the assembled `views.json` / `manifest.json`. --- ## The seven acts | Act | What it lands | Views | |---|---|---| | 1 · Context and scope | The boundary, who touches it, and the shape of the platform in one picture | 01–02 | | 2 · People and journeys | The executive office, the people who run it and the machines that act unasked, plus the three journeys whose worst moments the rest of the set answers | 03–06 | | 3 · Structure | The layering rule, the deployable units in one tenant, every interface, and how one codebase serves many organisations | 07–10 | | 4 · Data | Zones by rebuildability, source-to-answer flow, the canonical model, and how a document becomes a citation | 11–14 | | 5 · Runtime | One question end to end, agent orchestration, who computes what, proactive detection, the closed loop, and governed execution | 15–20 | | 6 · Operations | Regions and failure domains, delivery, observability, the evaluation loop, and the degradation contract | 21–25 | | 7 · Assurance | Trust zones, the identity chain, sovereignty, AI guardrails, and reconstructing a decision months later | 26–30 | --- ## Verification Every deliverable is machine-checked before hand-over: | Gate | Result | |---|---| | `validate.mjs --strict` (geometry, labels, page bounds) | 30 files, **0 errors, 0 warnings** | | `route-check.mjs` (arrows over boxes, labels on boxes) | 237 edges, **0 errors**, 9 clutter warnings | | `icons.mjs check` | 618 nodes, **0 unresolved, 0 weak matches** | | `check-links.mjs` | 31 pages, 238 relative links, **all resolve** | | `render-adr.mjs` | Every ADR cross-reference to a view, area and record validated before writing | The nine remaining route-check warnings are label density on two views — the system context (01), where four populated sides converge on one centre, and the integration catalogue (09), where fourteen interfaces are listed deliberately. Both are the clutter class the skill prints and does not fail on; the alternative is removing interfaces the view exists to enumerate. --- ## Honest limits - **This is a design, not a post-mortem.** No figure in it is a measured production number. Targets are engineering commitments to be tested; volumes are assumptions drawn from the requirement. - **Regional AI service availability is the binding external constraint** and it moves. ADR-29 carries it as a named risk with three pre-agreed fallbacks, to be verified against the target region's current service list before contract rather than assumed from these diagrams. - **Entity resolution across ERP, procurement and projects is the hardest item in the programme** and the one most often underestimated. ADR-16 treats it as a workstream with a human review queue, not a pipeline step. - **The jurisdiction is anonymised.** `Meridia` / `Meridia Central` are placeholder names for the customer's country and Azure region, and `NISA` for its national information-security authority. There is no Azure region called Meridia Central; substitute the real names before use. - **Ten-year audit retention is assumed** from public-sector norms and must be confirmed per contract; it is the dominant driver of long-term storage cost.