# 01 — Target Operating and Technology Architecture

| | |
|---|---|
| **Version** | v1.0 (Final) |
| **Date** | 2026-08-10 |
| **Target** | Governed, measured and orchestrated human+AI operations |
| **Companion docs** | 00 Overview · 02 Implementation Plan · 03 Data, Security & AI Governance · 04 Benefits Realisation |

---

## 1. Purpose and scope

This document defines the target-state architecture for a predominantly SaaS-based organisation with 1–500 employees that buys and integrates AI capabilities rather than training frontier models.

It defines:

- the operating and technical principles;
- a six-plane reference model;
- execution modes for AI-enabled action classes;
- capability depth by size band;
- reference deployment patterns for Google- and Microsoft-anchored estates;
- integration, identity, action-control and observability patterns;
- non-functional requirements;
- the target operating model and maturity model; and
- the architecture decisions each adopting organisation must record.

The normal Month-24 ambition is maturity **L4 — Orchestrated**, with selective L5 characteristics. “Full AI-native transformation in 24 months” is not a required claim and should not be used as a program success measure.

Out of scope: frontier-model training, safety-critical control, physical/OT systems, unrestricted autonomous agents, and regulated-sector overlays that materially alter the reference design.

## 2. Current-state archetype

A typical starting estate has:

- 20–120 SaaS applications, with a smaller set carrying most operational work;
- central identity on major products but password-based or shared access on the long tail;
- years of accumulated Drive, SharePoint, group and external-sharing permission debt;
- personal or consumer AI use without consistent contractual protection, inventory or monitoring;
- duplicated employee assistants and embedded AI features purchased without a portfolio decision;
- brittle point-to-point automations owned by individuals;
- operational data trapped in systems of record and knowledge dispersed across documents, tickets, email and people; and
- benefits claims based on anecdotes, adoption or “minutes saved”, without local baselines or financial conversion.

The target state does not replace every core SaaS product. It creates a governed execution fabric around authoritative applications, improves permission and data discipline, introduces a deterministic boundary between model reasoning and business transactions, and operates AI systems as measured services.

## 3. Architecture principles

| # | Principle | Architectural implication |
|---|---|---|
| P1 | **Outcome before technology** | Every production capability starts with a workflow, owner, baseline, quality requirement and economic hypothesis. |
| P2 | **Eliminate → simplify → standardise → automate → add AI** | Agentic technology is not used to preserve a broken or unnecessary process. |
| P3 | **Deterministic where possible; probabilistic where valuable** | Rules perform calculations, validations, routing and authorisation. Models interpret ambiguity, language and unstructured content. |
| P4 | **Models propose; controlled services transact** | A typed action proposal passes through deterministic policy, approval and transaction controls before any material side effect. |
| P5 | **Minimum sufficient autonomy** | Each action class receives the lowest execution mode that produces the required business value. T3 is exceptional. |
| P6 | **Identity and authority are explicit** | Logical agent, workload principal, delegating user and approver are separately attributable. No ambient or shared authority. |
| P7 | **Authoritative sources stay authoritative** | RAG, caches and model memory do not become systems of record. Writes occur only through governed application interfaces. |
| P8 | **Permission-correct, purpose-limited context** | Retrieval applies effective user/workload permissions, source curation, trust labels, minimisation, provenance, freshness and deletion. |
| P9 | **Open interfaces, controlled boundaries** | Native APIs/events first; iPaaS for deterministic workflows; MCP for approved agent-tool interfaces; browser/computer use only by exception. |
| P10 | **Evidence before promotion** | Offline evaluation, shadow operation, production SLOs and incident history gate T2/T3 promotion and model changes. |
| P11 | **Observability without uncontrolled data replication** | Audit metadata, governed references and business records are separated from short-lived diagnostic traces. |
| P12 | **Graceful degradation** | Every material workflow has timeouts, retries, idempotency, manual fallback and a tested pause or rollback path. |
| P13 | **Buy capability; build thin control and differentiation** | Custom development concentrates on proprietary workflow logic, policy and integration—not generic chat, vector databases or model hosting. |
| P14 | **Cost per accepted outcome** | Architecture captures model, platform, human-review, rework and support cost at workflow level. |
| P15 | **Exit is designed, not assumed** | Data, prompts, evaluations, action schemas, policies and runbooks are portable; model/provider switches are regression-tested. |

## 4. Six-plane reference model

```text
┌─────────────────────────────────────────────────────────────────────┐
│ P1  EXPERIENCE & COLLABORATION                                      │
│     Employee assistants · Embedded AI · Workflow inboxes ·          │
│     Authenticated approval and exception surfaces                   │
├─────────────────────────────────────────────────────────────────────┤
│ P2  WORKFLOWS, AGENTS & ACTION CONTROL                              │
│     Durable workflow engine · Agent runtime · Context assembler ·   │
│     Typed action broker · Policy decision point · Tool interfaces · │
│     Approvals · Queues · Schedulers · Registry · Pause controls     │
├─────────────────────────────────────────────────────────────────────┤
│ P3  MODELS, CONTEXT & EVALUATION                                    │
│     Approved model catalogue · API/gateway · Routing · Prompt and   │
│     context assets · Evaluation · Red-team tests · Caching          │
├─────────────────────────────────────────────────────────────────────┤
│ P4  DATA, KNOWLEDGE & INTEGRATION                                   │
│     Systems of record · APIs/events/iPaaS · Warehouse when needed · │
│     ACL-correct knowledge · Metadata · Metrics · Governed memory    │
├─────────────────────────────────────────────────────────────────────┤
│ P5  IDENTITY, SECURITY & TRUST                         cross-cutting │
│     IdP · User delegation · Workload identity · Authorisation ·     │
│     Secrets · DLP · Egress · Endpoint and supply-chain security     │
├─────────────────────────────────────────────────────────────────────┤
│ P6  GOVERNANCE, OBSERVABILITY & OPERATIONS              cross-cutting│
│     AI system register · Policies · Audit · Traces · SLOs · FinOps ·│
│     Incidents · Assurance · Continuity · Benefits telemetry         │
└─────────────────────────────────────────────────────────────────────┘
```

P5 and P6 apply to every capability in P1–P4. P2 is the critical safety boundary: model output is not a transaction until deterministic controls authorise and execute it.

### 4.1 P1 — Experience and collaboration

**Purpose:** give people a coherent, secure way to use AI and supervise workflows without creating a new interface for every use case.

| Capability | Requirement | S1 | S2 | S3 |
|---|---|---|---|---|
| Primary employee assistant | One primary sanctioned pattern per user cohort, under business terms and admin control | One product for eligible staff | One primary product; specialists by evidence | Cohort-based portfolio; duplication reviewed quarterly |
| Suite-native AI | AI embedded in Workspace/M365 for mail, documents, meetings and search | Use where licence value is clear | Target eligible roles | Broad where measured; not automatic for every role |
| Embedded SaaS AI | CRM, support, finance, design, engineering and HR features | Review before enablement | Inventory and approve | Portfolio-managed; embedded agents in AI register |
| Workflow inbox | Queue for proposals, exceptions and failed cases | Existing task/chat surface | Authenticated central queue | SLA-tracked queue with routing and cover |
| Approval surface | Shows source evidence, proposed change, policy result, materiality, reversibility and alternatives | Authenticated link/card | Integrated with workflow engine | Step-up authentication and separation-of-duties where required |
| Custom UI | Thin interface over a proprietary workflow | Avoid | Rare | Selective; do not rebuild general chat |

**Positions**

- Do not automatically buy both a suite assistant and a general enterprise assistant for every employee. Run a cohort-level value and TCO decision.
- Personal or consumer accounts MUST NOT process non-public company data.
- Customer-facing AI MUST disclose that it is AI where required by law, policy or reasonable user expectation, and MUST provide a route to a person for material issues.
- Approval by email reply is not sufficient for material transactions unless the approval mechanism cryptographically binds the authenticated approver, proposal and decision.

### 4.2 P2 — Workflows, agents and action control

**Purpose:** execute repeatable business work safely and reliably.

| Capability | Description | S1 | S2 | S3 |
|---|---|---|---|---|
| Deterministic workflow engine | Triggers, states, rules, retries, timeouts and exception routing | Native SaaS/iPaaS | Managed iPaaS or durable workflow service | Standard durable workflow runtime for material paths |
| Agent runtime | Runs bounded model-assisted steps | Vendor-managed | Vendor-managed plus first code-first agents | Standard managed runtime; isolated environments by trust domain |
| Context assembler | Selects minimum authorised instructions and data, with trust and classification metadata | Product-native | Reusable component for custom workflows | Standard service/pattern |
| **Typed action broker** | Accepts declared action schema; validates, authorises, executes, verifies and records side effects | Vendor controls or no custom writes | Required for custom T2/T3 writes | Standard control boundary |
| Policy decision point | Deterministic rules on principal, action, data, value, customer, time, risk and approval authority | Simple allowlists/thresholds | Central rules per workflow | Policy-as-code or equivalent, versioned and tested |
| Tool interfaces | Native API, event, iPaaS action or MCP tool; no direct credential exposure to model | Curated vendor connectors | Registered tools and actions | Versioned tool catalogue with trust-domain boundaries |
| Durable execution | Checkpoints, idempotency, retry policy, dead-letter handling and compensation | For material flows | Required for T2 | Required for all material T2/T3 |
| Human oversight | Approval, exception review, sampling and intervention | Existing authorised role | Tooled queue and cover | SLA, workload, quality and separation-of-duties controls |
| Registry and deployment | Owner, purpose, versions, identities, tools, data, mode, tests, limits, runbook | Register in sheet/tool | Authoritative register | Register integrated with CI/change workflow |
| Pause controls | Per-workflow/action pause, credential revocation and global emergency controls | Documented/tested | Automated where possible | Automated anomaly pause plus tested recovery |

#### 4.2.1 Execution modes

Execution modes describe **what an action class may do**, not its overall legal, privacy or human-impact risk. A single workflow can contain different modes.

| Mode | Name | Permitted behaviour | Minimum controls |
|---|---|---|---|
| **T0** | Retrieve / analyse | Read permitted sources; search, classify, summarise or calculate; no external or SoR write | Effective permissions; source provenance; output labelled; logging |
| **T1** | Draft / recommend | Produce a draft, recommendation or typed proposal; an authorised person independently commits or sends it | T0 controls; representative evaluation; clear human accountability |
| **T2** | Act after approval | Execute the exact typed action approved by an authorised person | Dedicated/delegated identity; policy checks; authenticated approval; idempotent executor; verification; exception path; full action audit |
| **T3** | Autonomous within bounded policy | Execute a declared low-impact action class without per-action approval | Sustained T2/shadow evidence; hard scope/value/rate/time limits; continuous monitoring and sampling; auto-pause; reversible/compensatable action; named owner and fallback |

**T4 open-ended autonomy**—self-defined goals, unrestricted tool discovery, dynamic privilege expansion, unsupervised sub-agent creation or broad administrative access—is outside this model and prohibited by default.

#### 4.2.2 T3 ceiling

T3 SHOULD be limited to action classes that are:

- low-impact and normally non-sensitive;
- narrow and objectively testable;
- reversible or automatically compensatable;
- bounded by deterministic rules, rate and value limits;
- observable before harmful scale can accumulate; and
- operationally unnecessary to route through a person each time.

Examples: applying an internal support tag, updating a non-material CRM note field, or sending an internal reminder. Releasing payments, changing bank details, final employment decisions, legal commitments and privileged infrastructure changes are not T3 targets in this reference model.

### 4.3 P3 — Models, context and evaluation

**Purpose:** provide controlled access to models and the assets needed to assess their behaviour.

| Capability | Requirement | S1 | S2 | S3 |
|---|---|---|---|---|
| Approved model catalogue | Approved products/models, permitted data, regions, retention, use cases and owner | Tool register | Central catalogue | Version policy and deployment aliases |
| Model/API access | Enterprise terms; central ownership of API accounts and keys | Direct vendor products/API | Managed project and quotas | Gateway when trigger criteria are met |
| Gateway | Credentials, quotas, version routing, traces and cost allocation—not a false promise of model interchangeability | Usually no | Optional | Normally yes for multi-workflow/multi-provider API use |
| Task routing | Model selected by evaluated task class, latency, data and cost | Manual/product default | Workflow configuration | Policy-driven with fallback and regression evidence |
| Prompt and context assets | Versioned system instructions, schemas, examples, policy references and context rules | Controlled templates | Git or managed registry | CI/change-controlled deployment artefacts |
| Evaluation harness | Offline test sets, adversarial cases, shadow comparisons and production sampling | Manual/managed | Repeatable harness | CI-integrated plus production evaluation pipeline |
| Model-change management | Pin where possible; detect vendor updates; regression, canary and rollback | Vendor monitoring | Change calendar | Controlled aliases, canary and fallback |
| Caching | Only for semantically safe, permission-compatible and non-volatile requests | Product-native | Selective | Policy-aware; no cross-principal leakage |
| Fine-tuning | Exception only after retrieval, prompt, tool and process limits are demonstrated | No | Rare | Business case, data rights and lifecycle controls required |

**Gateway trigger criteria:** consider a gateway when at least two of the following apply: multiple production API workflows; more than one model provider; material usage spend; required central traces/quotas; data-residency routing; or frequent controlled model switching. A self-hosted gateway adds operational and security burden and MUST have an owner, SLO, patching and recovery plan.

#### 4.3.1 Evaluation dimensions

A production evaluation is multi-dimensional. Depending on the workflow it covers:

- task correctness and completeness;
- groundedness, source attribution and citation correctness;
- extraction or classification precision/recall;
- policy compliance and refusal behaviour;
- tool selection, argument validity and action success;
- prompt-injection and data-exfiltration resistance;
- fairness or differential performance where people may be affected;
- human-review acceptance, override and rework;
- latency, availability and cost per accepted outcome; and
- recovery from tool, model and data-source failure.

Twenty to fifty cases are a useful seed set, not universal production evidence. Sample size and observed runtime volume MUST match risk, variability and the tolerated error rate. Doc 02 Appendix C defines the evidence pattern.

### 4.4 P4 — Data, knowledge and integration

**Purpose:** provide authoritative, permission-correct and operationally reliable information to humans and AI systems.

| Capability | Requirement | S1 | S2 | S3 |
|---|---|---|---|---|
| Authoritative source map | System/field/document class, owner, quality, retention and permitted use | Lightweight register | Domain map | Stewarded metadata and data contracts for critical domains |
| Operational integration | Native APIs/events and deterministic workflows; writes only through supported interfaces | Native/iPaaS | Managed connectors/API | Durable services/events for material paths |
| Analytical data | Central store only where cross-system analytics, history or measurement require it | Usually native reports | Use-case-led starter warehouse | Modelled warehouse/lakehouse where justified |
| Metrics layer | Agreed definitions for business and workflow KPIs | Finance-owned sheet/model | Reusable definitions | Semantic/metrics layer for critical KPIs |
| Knowledge retrieval | Curated sources, security trimming, provenance, freshness and citations | Suite-native search/grounding | Curated assistant sources | Enterprise search/RAG only where incremental value is proven |
| Index lifecycle | Permission changes and deletions propagate; stale sources expire; index access is tested | Vendor assurance | Tested controls | Automated reconciliation and leak tests |
| Retrieval trust | Retrieved content labelled by source/trust; embedded instructions treated as untrusted data | Product controls | Workflow rules | Standard context-isolation pattern |
| Model memory | Off by default; if used, purpose, owner, ACL, retention, correction and deletion are explicit | Avoid shared memory | User/workflow-scoped | Governed store; no unbounded self-written memory |
| Data quality | Freshness, validity, reconciliation and exception checks on data used for decisions | Source controls | Checks on used datasets | Automated tests, ownership and alerting |

**Positions**

- “One system of record per entity” is a useful simplification but not always accurate. Record authority at the domain or field level where lifecycle systems differ.
- A warehouse is not an AI prerequisite. Build it when analytics, cross-system truth or measurement requires it.
- A vector index is a derived data store. It inherits privacy, residency, retention, access, deletion and incident obligations from its source content.
- Security trimming at query time is preferred. Cached ACL snapshots MUST have bounded staleness and reconciliation.
- Retrieved documents, web pages, tickets, emails and tool descriptions are data, not instructions. They cannot override system policy.
- AI-generated summaries MUST link back to authoritative sources when they may inform a material decision.

### 4.5 P5 — Identity, security and trust

| Capability | Target requirement |
|---|---|
| Human identity | Google Workspace or Entra ID as primary IdP; SSO for material systems; universal MFA; phishing-resistant authentication for privileged and financial roles; tested joiner/mover/leaver process |
| Logical AI identity | Stable `system_id`, `workflow_id` and `agent_id` in the register and every event, independent of runtime implementation |
| Delegated user access | Interactive assistants and tools preserve the requesting user’s effective downstream permissions; no service-account elevation hidden behind a user interface |
| Workload identity | Background workflows use narrowly scoped, short-lived workload credentials; static keys are avoided; production and non-production identities are separated |
| Approval identity | The approver’s authenticated identity and business authority are verified; approval does not transfer the approver’s reusable credential to the agent |
| Authorisation | Action- and resource-specific scopes; deny by default; no token passthrough; audience/issuer validation; step-up authentication for material actions |
| Secrets | Managed secrets service; no credentials in prompts, traces, source code or tool descriptions; rotation and emergency revocation |
| Network/egress | Code-first runtimes restrict outbound destinations; tools are allowlisted; web access, code execution and file handling are isolated by risk |
| DLP and minimisation | Context and output scanning where proportionate; C4 data redacted or field-minimised; no general assistant access by default |
| Supply chain | Models, frameworks, MCP servers, plugins, packages and images inventoried, reviewed, pinned where possible and monitored for change |
| Endpoint/SaaS posture | Managed devices/browsers for C3+ work; third-party OAuth grants and admin roles reviewed; risky sharing defaults disabled |

#### 4.5.1 MCP security profile

Where MCP is used for remote enterprise tools, the implementation SHOULD conform to the 2026-07-28 specification and MUST:

- require authorisation for non-public HTTP resources and tools;
- follow current OAuth security best practice, including issuer, audience and redirect validation;
- avoid passing upstream tokens through to downstream services;
- bind scopes to declared resources and actions rather than a broad “all tools” grant;
- validate and constrain every tool input, rate limit calls and sanitise outputs;
- display and approve material tool inputs before execution at T2;
- pin server/tool versions or otherwise detect material schema/description changes;
- treat tool metadata and results as untrusted content; and
- emit action events to the organisation’s audit path.

MCP does not replace application authorisation, the policy decision point or the action broker.

### 4.6 P6 — Governance, observability and operations

| Capability | Target requirement |
|---|---|
| AI system register | Covers procured, embedded and built systems; owner, supplier, purpose, data, users, action classes, risk, impact assessment, tests, versions, controls and lifecycle status |
| Policy implementation | Acceptable use, tool tiers, data rules, action limits, approvals, disclosure and retention mapped to configuration or a logged process |
| Audit events | Immutable or tamper-evident metadata sufficient to attribute and reconstruct material T2/T3 decisions and transactions |
| Diagnostic traces | Separate, access-controlled and short-lived; raw prompts/outputs retained only where necessary and redacted where possible |
| Business records | Approved outputs, sent communications and executed transactions retained under the applicable business record schedule |
| Operational SLOs | Accuracy/quality, action success, policy violations, latency, queue age, availability, cost and human-review load per workflow |
| FinOps | Seat utilisation, model/platform usage, human-review and rework cost allocated to workflows; budgets and anomaly alerts |
| Incident response | AI-specific detection and playbooks integrated with normal cyber, privacy and business incident management |
| Continuity | Manual fallback, queued-work handling, provider outage procedures, restore tests and decommissioning path |
| Assurance | Risk-based self-assessment, action reconstruction, access review, red-team testing and independent review for higher-impact systems |
| Benefits telemetry | Accepted outcomes, unit cost, capacity, quality and financial conversion evidence feed Doc 04 |

#### 4.6.1 Three different records

Do not collapse the following into one observability store:

1. **Audit event:** who/what acted, authority, policy decision, action, result, references and cost.
2. **Diagnostic trace:** detailed model/tool interaction used to debug or evaluate, with short retention and restricted access.
3. **Business record:** the communication, document, approval or transaction that the organisation must retain under normal records rules.

This separation reduces privacy and breach impact while preserving accountability.

### 4.7 Canonical T2 runtime sequence

The AP invoice example demonstrates the target pattern. Every production workflow follows the same control shape, even when the business tools differ.

```text
 1. Trigger          The AP mailbox/API creates a workflow instance and idempotency key.
 2. Authenticate     Runtime obtains the approved workload identity; the logical workflow
                     and agent IDs are attached to the trace.
 3. Classify         Input is malware-scanned and classified; sender/source trust and data
                     classes are recorded. Document content is treated as untrusted data.
 4. Retrieve         Context assembler fetches only the invoice, approved vendor/PO fields
                     and applicable policy/version through read-scoped interfaces.
 5. Interpret        Model extracts fields and proposes a typed action. It does not post.
 6. Validate         Deterministic code validates schema, arithmetic, tax rules, duplicate
                     status, vendor bank-detail status and three-way match.
 7. Decide policy    Policy service returns allow-with-approval, reject or exception based on
                     amount, match status, vendor state, authority and risk.
 8. Approve          An authorised AP approver sees source, proposed record diff, policy result,
                     exceptions and reversibility in an authenticated surface.
 9. Execute          Action broker uses a write-scoped credential to post the exact approved
                     transaction, with idempotency and timeout/retry controls.
10. Verify           Result is read back from the finance SoR; failure routes to exception and
                     any partial effect is compensated or clearly flagged.
11. Record           Audit event captures identities, versions, input/output references,
                     policy and approval decision, action/result and cost. The invoice and
                     finance record remain the business records.
12. Learn            Accepted/rejected cases, overrides, failures, review effort and unit cost
                     feed monitoring, evaluations and the benefits register.
```

At T1, steps 7–9 end with a human manually committing the draft. At T3, step 8 is omitted only for a bounded action class whose policy, evidence and limits have been approved. All other controls remain.

### 4.8 Control plane and execution plane

**Control plane:** system and agent registers; approved model/tool catalogue; identities and scopes; prompt/policy/evaluation versions; deployments; budgets; approvals; kill/pause controls; and audit configuration.

**Execution plane:** workflow instances; model calls; retrieval; tool invocations; transactions; queues; exceptions and results.

Administrative access to the control plane MUST be more restricted than ordinary workflow operation. A compromised model or workflow MUST NOT be able to modify its own policy, tools, scopes, tests, budgets or audit configuration.

## 5. Reference deployment patterns by size

### 5.1 S1 — Micro / very small

Minimum viable architecture:

- one primary sanctioned employee assistant or suite-native AI pattern;
- business accounts, MFA, central billing and an acceptable-use policy;
- native SaaS automation or managed iPaaS for deterministic flows;
- no custom agent with write access unless a specific, measured workflow justifies support and control overhead;
- lightweight AI system/source/benefit registers;
- password manager/secrets service and documented joiner/leaver process;
- vendor-managed retrieval over carefully selected sources; and
- manual fallback for every automation.

Avoid a warehouse, self-hosted gateway, self-hosted vector stack or multi-agent framework unless a clear workload pays for it.

### 5.2 S2 — Small

Add when justified:

- a managed workflow/agent runtime and reusable action-control pattern;
- first read-only and T1 agents, then T2 action classes after evidence;
- central log destination and repeatable evaluation harness;
- dedicated workload identities and managed secrets;
- curated knowledge sources with tested security trimming;
- starter analytical store only for cross-system reporting/measurement use cases;
- a partner or fractional engineer who owns runbooks and support; and
- formal monthly portfolio, risk and benefit review.

### 5.3 S3 — Medium / lower mid-market

Add:

- standard durable workflow runtime, action broker and policy pattern;
- versioned tool catalogue and bounded MCP estate where useful;
- model gateway when the trigger criteria in §4.3 are met;
- central model, prompt, policy and evaluation release process;
- broader analytical/metrics layer where business use requires it;
- structured SLOs, on-call/escalation and incident exercises;
- automated access, permission, registry and spend checks; and
- independent review for higher-impact workflows.

## 6. Vendor-aligned examples

These are coherent examples, not mandatory stacks. Features and commercial terms MUST be revalidated at procurement.

### 6.1 Google-anchored estate

| Capability | S1 | S2 | S3 |
|---|---|---|---|
| Identity/collaboration | Google Workspace | Workspace + automated lifecycle to major SaaS | Workspace + formal access reviews and central log export |
| Employee AI | Workspace with Gemini **or** selected business assistant as primary | Primary cohort pattern; ChatGPT Business/Enterprise or Claude Team/Enterprise only where incremental | Cohort portfolio; suite and specialist assistants rationalised quarterly |
| Automation/workflows | Native SaaS, Apps Script where supportable, managed iPaaS | Managed iPaaS / Cloud Run or equivalent for bounded code | Durable workflow service + Cloud Run/container runtime or equivalent |
| Agent building | Vendor-managed builders only | Managed builders + first code-first workflow | Code-first standard for material workflows; builders for low-risk citizen use |
| Model APIs | Direct managed project | Central project, quotas and logging | Gateway/API management where trigger criteria apply |
| Data/analytics | Native reports | BigQuery or equivalent only when use cases require | BigQuery + tested transformations/metrics where justified |
| Knowledge | Workspace-native grounding on curated sources | Curated enterprise assistant sources | Enterprise search/RAG only if native capability is insufficient and ACL controls are proven |
| Secrets/logging | Business password manager; admin logs | Secret Manager + Cloud Logging or equivalent | Central security/observability projects, retention tiers and dashboards |

### 6.2 Microsoft-anchored estate

| Capability | S1 | S2 | S3 |
|---|---|---|---|
| Identity/collaboration | Microsoft 365 + Entra ID | Entra lifecycle to major SaaS | Entra access reviews/entitlement controls and central log export |
| Employee AI | Microsoft 365 Copilot **or** selected business assistant as primary | Primary cohort pattern; alternate assistant only where incremental | Cohort portfolio; duplication and agent proliferation reviewed quarterly |
| Automation/workflows | Power Automate/native SaaS | Power Automate/Copilot Studio plus bounded Azure runtime as needed | Durable workflow/runtime on managed Azure services; Copilot Studio for appropriate low-code cases |
| Agent building | Vendor-managed builders | Managed builders + first code-first workflow | Code-first standard for material workflows; low-code under environment and DLP controls |
| Model APIs | Direct managed project | Central subscription/project, quotas and logging | Gateway/API management where trigger criteria apply |
| Data/analytics | Native reports/Power BI | Fabric or equivalent only when use cases require | Modelled Fabric/lakehouse and governed metrics where justified |
| Knowledge | M365/Graph grounding on curated sources | Curated SharePoint/enterprise sources | Enterprise search/RAG only if incremental value and security trimming are proven |
| Secrets/logging | Business password manager; audit logs | Key Vault + Log Analytics or equivalent | Central security/observability workspaces, retention tiers and dashboards |

### 6.3 Neutral assets to own

Regardless of vendor, the organisation SHOULD own or be able to export:

- workflow definitions and typed action schemas;
- prompt, policy and context templates;
- evaluation cases, rubrics and results;
- source and authority maps;
- AI system/agent registry records;
- benefits baselines and outcome telemetry;
- architecture decisions and runbooks; and
- business data in supported, documented formats.

## 7. Integration decision hierarchy

For each integration or workflow need, use this sequence:

1. **Eliminate or simplify the process.**
2. **Use a native capability** in the authoritative application where it meets the control and economic need.
3. **Use a supported API and event/webhook** for deterministic application behaviour.
4. **Use iPaaS or a durable workflow service** for cross-application rules and state.
5. **Expose a bounded tool interface, including MCP where appropriate,** when a model-assisted host needs to select or use a tool.
6. **Use controlled computer/browser automation** only when no supported interface exists, for a time-limited exception with strong isolation and monitoring.
7. **Write custom point-to-point code** only with a named owner, tests, SLO, runbook and exit plan.

**Prohibited anti-patterns:** human credential reuse; agent-admin accounts; raw model output into SQL/shell/HTML or transactions; runtime discovery of unapproved tools; unsupervised browser automation for sensitive work; mega-tools exposing an entire SaaS API; indexing without effective ACLs; and approvals that do not bind the exact proposed action.

## 8. Build versus buy

Build a custom production component only when all of the following are true:

1. the workflow is strategically differentiating or commercially material;
2. the business volume or risk justifies engineering ownership;
3. configurable products cannot meet the control and outcome requirements at acceptable TCO;
4. the process and authoritative data are sufficiently stable;
5. an accountable business owner and technical owner exist;
6. the organisation can test, secure, monitor, support and retire the component; and
7. the risk-adjusted business case beats buying, simplifying or not doing it.

Even then, build the thinnest differentiating layer. Prefer managed models, identity, queues, secrets, databases and observability.

Record significant decisions as ADRs. A “proof of concept” is not exempt from data, security or contractual controls if it uses real C3/C4 data or can cause a real side effect.

## 9. Non-functional requirements

Targets are set **per workflow**, based on impact and business criticality.

| Area | Baseline requirement |
|---|---|
| Correctness/quality | Acceptance criteria and error budget; objective checks where possible; model output alone is not evidence |
| Safety/policy | Zero tolerance for unauthorised action classes; policy violations auto-pause material workflows |
| Availability | SLO, business hours/24×7 need, provider dependency and degraded/manual path documented |
| Recovery | RTO/RPO where relevant; retry, dead-letter, compensation and restoration tested |
| Auditability | 100% of T2/T3 actions attributable to logical system, runtime principal, policy version and approver/authority |
| Privacy | Purpose limitation, minimum context, data rights, retention, deletion and residency appropriate to the use |
| Security | Threat model; least privilege; isolated untrusted content; egress/tool restrictions; secure software and supply-chain practices |
| Performance | Latency and queue-age targets; slow model paths do not block critical operations without fallback |
| Cost | Maximum cost per accepted outcome; seat and usage budgets; anomaly alerting; human-review/rework included |
| Accessibility | Human-facing AI and approval surfaces meet applicable accessibility requirements |
| Explainability/evidence | Sources, material factors and policy results available at the level appropriate to impact; no uncalibrated confidence score presented as assurance |
| Maintainability | Owner, versions, test suite, deployment/rollback, runbook and decommissioning path |
| Portability | Data and control assets exportable; provider changes subject to regression rather than assumed compatibility |

## 10. Maturity model

Maturity measures controlled business operation, not the number or autonomy of agents.

| Level | Name | Characteristics |
|---|---|---|
| **L1** | Ad hoc | Shadow or individual AI use; no reliable inventory, policy or outcome evidence |
| **L2** | Sanctioned | Approved employee tools, basic policy, ownership, AI literacy and initial data controls |
| **L3** | Measured | Curated knowledge; several T0/T1 workflows with baselines, evaluations, unit costs and monitoring |
| **L4** | Orchestrated | Production T2 workflows across functions; standard action boundary; reliable operations, assurance, portfolio and benefit conversion; selective bounded T3 |
| **L5** | Adaptive operating model | Functions are deliberately designed around human+AI workflows; closed-loop process improvement, role/capacity planning and investment decisions use production evidence; autonomy remains risk-bounded |

**Month-24 target:** L4 for S2/S3, with L5 characteristics in selected functions. S1 targets the economically appropriate subset of L3/L4 controls, not a miniature enterprise platform.

## 11. Target operating model

### 11.1 Accountabilities

| Role/duty | Accountability |
|---|---|
| Executive Sponsor | Strategy, risk appetite, funding, workforce principles and material exceptions |
| AI/Automation Lead | Portfolio, reference architecture, operating cadence and cross-functional capability |
| AI System Owner | End-to-end accountability for a deployed AI system, including supplier, controls, tests, monitoring and retirement |
| Workflow Owner | Business outcome, process design, backlog, acceptance criteria, unit cost and benefit evidence |
| Technical Owner | Runtime, integrations, action controls, deployment, SLOs, incidents and runbook |
| Data/Knowledge Owner | Authority, classification, access, quality, source curation, retention and correction |
| Risk/Privacy/Security Owner | Proportionate risk/impact assessment, control review, legal/privacy coordination and incident oversight |
| Authorised Approver | Makes a specific business decision at T2 within delegated authority; not merely an “AI supervisor” |
| Review/Sampling Duty | Reviews production samples and exceptions; separate from approval where independence is required |
| Finance Partner | Baselines, TCO, financial conversion and sign-off of banked benefits |

S1/S2 may combine duties, but accountability remains explicit. Suppliers can perform work; they do not absorb the organisation’s accountability.

### 11.2 Human+AI team design

Humans concentrate on judgment, relationships, exceptions, accountability and process improvement. AI systems perform retrieval, interpretation, drafting and bounded execution where evidence supports it.

Do not set supervision capacity by “number of agents”. Size it using:

- approval and exception volume;
- minutes and cognitive effort per decision;
- queue-age and service-level requirements;
- sampling burden and error rate;
- materiality and separation-of-duties needs; and
- cover for leave and incidents.

A queue that forces cursory approvals is a failed control. Sustained very-fast approvals, high approval rates without variation, backlog growth, low override rates inconsistent with known model error, or missed evidence review trigger redesign or demotion.

### 11.3 Managerial changes

Managers:

- own workflow output and exception quality rather than monitoring “AI usage” in isolation;
- decide where released capacity is explicitly redeployed;
- maintain human expertise and fallback capability for material work;
- ensure affected employees receive training and role-change clarity; and
- treat AI systems as governed production capacity with owners, budgets, SLOs and performance history.

## 12. Month-24 outcome statement

A successful S3 implementation should normally demonstrate:

- one primary sanctioned employee-assistant pattern per relevant cohort, with licence value and use measured;
- an organisation-wide AI system register including embedded and supplier-provided AI;
- curated, permission-correct knowledge sources with provenance, freshness and deletion controls;
- 5–15 production AI-enabled workflows across at least three functions, scaled down by band and business need;
- a majority of material write actions at T2, with T3 confined to approved bounded action classes;
- a standard deterministic action-control pattern for custom T2/T3 workflows;
- every production workflow owned, versioned, evaluated, monitored, budgeted, supportable and pausable;
- outcome quality, unit cost, human-review effort and total cost reported monthly;
- capacity and financial benefits reported separately and finance-validated; and
- at least two functions redesigned around human+AI workflows rather than merely automating legacy steps.

The target is not “the majority of all work is autonomous”. It is that AI-enabled work is commercially useful, technically supportable and governed as normal operations.

## 13. Sector and jurisdiction overlays

The six-plane model remains useful in regulated contexts, but additional obligations can materially change implementation, including:

- deployment location and supplier eligibility;
- segregation and key management;
- validation depth and independence;
- audit and records retention;
- human decision requirements and contestability;
- model explainability and transparency;
- incident notification; and
- prohibited or high-risk uses.

Do not describe these as governance-only “bolt-ons”. For health, finance, public sector, defence, critical infrastructure, children’s data or safety-relevant use, commission a dedicated architecture and legal/control overlay before selecting products or autonomy ceilings.

## 14. Architecture decisions to record

| ADR | Decision |
|---|---|
| ADR-1 | Identity and collaboration estate; SSO and lifecycle exceptions |
| ADR-2 | Primary employee-assistant pattern by cohort; specialist-product criteria |
| ADR-3 | AI system register and ownership model |
| ADR-4 | Action-control pattern: proposal schema, policy decision point, broker/executor and approval surface |
| ADR-5 | Delegated-user versus workload-identity patterns; credential lifetime and scope |
| ADR-6 | Model providers, approved versions, contractual posture and change-notification approach |
| ADR-7 | Gateway trigger and product/operating model |
| ADR-8 | Workflow/agent runtime and durable execution standard |
| ADR-9 | Integration hierarchy and MCP security/profile/version policy |
| ADR-10 | Authoritative source map, analytical platform trigger and metrics layer |
| ADR-11 | Knowledge/RAG sources, security trimming, freshness, deletion and provenance approach |
| ADR-12 | Model memory policy |
| ADR-13 | Evaluation framework, sample/evidence rules and production SLOs |
| ADR-14 | Execution-mode ceilings and prohibited action classes |
| ADR-15 | Audit, trace and business-record destinations and retention |
| ADR-16 | Privacy, residency, disclosure, affected-person and legal obligations |
| ADR-17 | Business continuity, provider fallback and manual operating paths |
| ADR-18 | Build/buy and exit strategy for custom components |

### 14.1 ADR template

```text
ADR-<n>: <title>
Status:       Proposed | Accepted | Superseded-by-<n>
Date:         <yyyy-mm-dd>
Owner:        <accountable role>
Review:       <date and event-based triggers>

Context:
  What outcome, constraints, risks, volumes and obligations drive the decision?

Options:
  2–4 credible options, including “do nothing/simplify”, with TCO and control trade-offs.

Decision:
  The selected option and its scope, stated unambiguously.

Controls and evidence:
  Required tests, limits, approvals, monitoring, fallback and acceptance criteria.

Consequences:
  Commitments, residual risks, lock-in and operating ownership.

Revisit triggers:
  Headcount/volume threshold, supplier or law change, incident, failed SLO, economics,
  material model/tool change or new capability.
```

ADRs, prompts, policies, action schemas, evaluations and runbooks SHOULD be versioned together. They are the operational memory of the architecture.