> For the complete documentation index, see [llms.txt](https://www.aicontrolarchitecture.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.aicontrolarchitecture.org/foundation/05-reference-architecture.md). # 05 · Reference Architecture The [thesis](/foundation/03-core-thesis.md) says AI's authority must be made bounded, provable, and reversible. This document shows *how the ten pillars compose* to do that, where each control attaches across the life of an AI use case, and how they fit an existing enterprise estate. *** ## The organizing model The ten pillars divide into two groups with different jobs: * **Seven pillars bound what the AI is and can do**: across the three surfaces of authority (See, Decide, Do), plus the identity it acts under, the risk tier it sits in, and the human who owns it. * **Three pillars make that boundedness real**: Assurance proves the controls hold, Monitoring makes behavior observable and reconstructable, and Containment makes it stoppable and reversible. Accountability spans everything: a named human owns the use case and its outcomes end to end. ``` ┌───────────────────────────────────────────────┐ │ 07 INVENTORY & CLASSIFICATION (see it, tier it) └───────────────────────────────────────────────┘ SEE DECIDE DO ┌────────────┐ ┌──────────────┐ ┌──────────────────┐ │08 Identity │ │11 Output & │ │12 Tool & Action │ │ & Access │ │ Decision │ │ Control │ │09 Data │──────▶ │ Control │──────▶ │ │ │ Boundary │ │ │ │ │ │10 Input │ │ │ │ │ │ Control │ │ │ │ │ └────────────┘ └──────────────┘ └──────────────────┘ │ │ │ └──────────── 13 HUMAN ACCOUNTABILITY ────────┘ │ ┌──────────────────────────┴──────────────────────────┐ │ 14 ASSURANCE 15 MONITORING & 16 CONTAINMENT & │ │ & TESTING EVIDENCE RECOVERY │ │ (prove it) (observe it) (stop / undo it) │ └─────────────────────────────────────────────────────┘ ``` *** ## The control lifecycle of a use case Controls attach at specific points as an AI use case moves from idea to running system. The pillars map onto that flow: ``` INTAKE ─▶ CLASSIFY ─▶ ACCESS ─▶ INPUT ─▶ INFERENCE ─▶ OUTPUT ─▶ ACTION ─▶ RUN │ │ │ │ │ │ │ │ 07 07 08,09 10 (model) 11 12 14,15,16 inventory risk identity input output tool assure, & owner tier & data & decision & act monitor, boundary control control control contain ``` * **Intake & Classify (07):** the use case is registered, owned, and risk-tiered before controls are chosen. Nothing is governed that isn't first *seen*. * **Access (08, 09):** the AI is given a bounded identity and an explicit data boundary, what it may retrieve and expose. * **Input (10):** prompts and untrusted input are controlled for injection and manipulation. * **Output & Decision (11):** output is validated and prevented from silently becoming a decision without accountability. * **Action (12):** tools, actions, and workflows are bounded, the point at which AI becomes an actor. * **Accountability (13):** a named human owns the outcomes throughout. * **Assure / Monitor / Contain (14, 15, 16):** controls are tested, behavior is logged and reconstructable, and the capability can be stopped and recovered. *** ## Control points, where controls attach Every pillar resolves to one or more **control points**: a place in the running system where a boundary is declared, evidenced, verified, or enforced. ``` Control point Pillar Boundary strength it can reach ──────────────────────────────────────────────────────────── AI inventory record 07 Declared → Evidenced Identity / auth 08 Verified → Enforced Data retrieval scope 09 Verified → Enforced Input handling 10 Evidenced → Enforced Output validation 11 Evidenced → Enforced Action / tool broker 12 Verified → Enforced Accountability record 13 Declared → Evidenced Assurance test 14 Verified Log / evidence store 15 Verified Kill switch / recovery 16 Enforced ``` A use case's real control strength is the **weakest boundary on a surface that matters**, an enforced action broker means little if the data boundary is only declared. The [boundary-source ladder](/foundation/03-core-thesis.md) is applied per control point, not once for the whole use case. *** ## Risk tier is the modulator The reference architecture is not "apply all controls everywhere." Tiering (pillar 07) sets how far each control point must go. A low-tier, read-only copilot may need its data boundary only *evidenced*; a high-tier, action-capable agent needs identity, data, action, monitoring, and containment all *verified or enforced*, with human approval gates on high-impact actions. Tier first; then apply the boundary strength the tier requires. *** ## Fitting a brownfield estate The architecture does not introduce a parallel stack; each pillar plugs into systems the enterprise already runs: ``` Pillar Plugs into ────────────────────────────────────────────────────────── 08 Identity & Access IdP / IAM, secrets, service identity 09 Data Boundary DLP, data classification, RAG scoping 10 Input Control gateway / prompt firewall, WAF 11 Output & Decision review workflow, approval systems 12 Tool & Action API gateway, action broker, MCP proxy 13 Accountability GRC, ownership records 14 Assurance test frameworks, red-team tooling 15 Monitoring & Evidence SIEM, logging, audit store 16 Containment & Recovery incident response, feature flags, backups ``` This is the point of vendor-neutrality: the architecture defines *what boundary must hold at each control point*, and the enterprise satisfies it with the tools it already owns. *** ## From architecture to requirements Each pillar (07–16) specifies the controls for its surface. The [Requirements Catalogue](/foundation/06-requirements-catalogue.md) turns those into numbered, testable requirements with tier applicability and standards crosswalks; the [templates](/templates-and-examples/templates-readme.md) capture the evidence per use case; the [mappings](/standards-crosswalks/mappings-readme.md) tie each requirement to the frameworks the enterprise is held to. *** **Next:** [06 · Requirements Catalogue](/foundation/06-requirements-catalogue.md) *Version 0.1.0 · Licensed under the terms in* [*LICENSE.md*](https://github.com/ai-ankqush/ai-control-architecture/tree/main/LICENSE.md)*.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.aicontrolarchitecture.org/foundation/05-reference-architecture.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.