Module: B11 — Governance and Compliance Diagram count: 5 Tool: Mermaid (primary). Each diagram validated in Mermaid Live Editor.
Type: Continuous-loop / function map Purpose: The central framework of the module, made visual. NIST AI RMF (AI 100-1) organizes AI risk management into four core functions — Govern, Map, Measure, Manage — that operate as a continuous loop, not a linear pipeline. Every AI system is doing all four at all once. The diagram also pins the B2–B8 control that answers each function, so the technical work of the course maps onto the framework the budget and board follow. Reading the diagram: Read Govern as the foundation (the outer ring) and Map → Measure → Manage as the operating loop. Each function node carries the course module that realizes it. Note Govern sits underneath the loop — without governance, the loop does not operate.
flowchart TB
GOV["GOVERN<br/>culture · policy · accountability<br/>named owner, documented tolerance<br/>→ policy-as-code layer (B11.3)"]
MAP["MAP<br/>context · use · risk surface<br/>what data, tools, users, blast radius<br/>→ threat model (B1) · AI BOM (B11.2)"]
MEASURE["MEASURE<br/>test · evaluate · verify<br/>success rates, coverage, residual risk<br/>→ injection rates (B2) · OWASP (B9) · MSFT (B10)"]
MANAGE["MANAGE<br/>mitigate · respond · remediate<br/>deployed controls + incident response<br/>→ tool governance (B3) · sandbox (B6) · obs (B8)"]
GOV ---|"foundation"| MAP
MAP -->|"context to test"| MEASURE
MEASURE -->|"evidence to act on"| MANAGE
MANAGE -.->|"residual risk → re-scope"| MAP
MANAGE -.->|"exceeds tolerance → re-policy"| GOV
classDef foundation fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
classDef loop fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
class GOV foundation
class MAP loop
class MEASURE loop
class MANAGE loop
Note: Govern is the foundation, not a stage. An agent with a working guardrail but no named owner, no documented tolerance, and no policy-as-code layer has skipped Govern — and the loop above it cannot be evidenced in an audit. The RMF is voluntary in law; it is mandatory in practice because OMB M-24-10, insurers, and enterprise governance councils all map against it.
Type: Inventory / component map Purpose: The central artifact of B11.2. The AI BOM is the SBOM extended to AI — an inventory of everything an agent is made of, so the full supply chain is visible and therefore auditable. An SBOM that lists Python packages but not the model version or the MCP servers misses the components an AI attacker actually targets. Reading the diagram: Six component classes radiate from the agent. The left three (model, training data, system prompt) are the AI-specific extensions over a traditional SBOM. The right three (tools/MCP, frameworks/SDKs, external services) are the SBOM surface, extended for agents. Together they are the inventory a regulator or auditor asks for first.
flowchart LR
AGENT["THE AGENT<br/>at a point in time"]
MODEL["MODEL<br/>provider · id · checkpoint<br/>modality · params · license"]
DATA["TRAINING DATA<br/>datasets · sources · provenance<br/>license · PII status"]
PROMPT["SYSTEM PROMPT & CONFIG<br/>prompt version · config hash<br/>guardrail versions"]
TOOLS["TOOLS / MCP SERVERS<br/>tool names · endpoints<br/>versions · capability scope"]
FRAME["FRAMEWORKS & SDKs<br/>harness · version<br/>dependencies (the SBOM subset)"]
EXT["EXTERNAL SERVICES<br/>API providers · vector DB<br/>identity · sandbox provider"]
MODEL --> AGENT
DATA --> AGENT
PROMPT --> AGENT
TOOLS --> AGENT
FRAME --> AGENT
EXT --> AGENT
classDef core fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
classDef aispec fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#e4e4e8
classDef sbom fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
class AGENT core
class MODEL aispec
class DATA aispec
class PROMPT aispec
class TOOLS sbom
class FRAME sbom
class EXT sbom
Note: The green nodes (model, training data, system prompt) are the AI-specific fields a traditional SBOM does not capture — and they are exactly the fields an AI attacker targets (model-version jailbreaks, B0; training-data poisoning, B4; system-prompt extraction, B2). The amber nodes are the SBOM surface extended for agents (the tool registry and the external-service dependencies). The AI BOM must be generated from the running system, not maintained in a wiki — a wiki and reality drift, and the auditor reads reality.
Type: Pipeline / evidence architecture Purpose: The audit trail is the evidence that controls are enforced, not just documented. This diagram shows how every agent action flows through the policy engine and produces an audit entry, and what the audit trail must contain for compliance. Reading the diagram: Top-to-bottom: the agent proposes an action → the policy engine (in the harness execution path, not the agent process) evaluates it against the rules → the decision is enforced (ALLOW/DENY/ESCALATE) → every evaluation emits an audit entry to the append-only, tamper-evident trail. The audit trail is the compliance artifact; the observability dashboard (B8) is the engineering capability — they are separate systems.
flowchart TB
AGENT["AGENT PROPOSES ACTION<br/>tool call · data access · decision"]
ENGINE["POLICY ENGINE (in execution path)<br/>governance beneath the agent (DD-09)<br/>agent CANNOT reach to disable"]
RULES["POLICY RULES<br/>compiled from constitution.md<br/>deterministic, zero LLM at runtime (DD-20)"]
DECIDE{"DECISION"}
ALLOW["ALLOW<br/>action proceeds"]:::good
DENY["DENY<br/>action blocked (default-deny if no rule)"]:::danger
ESC["ESCALATE<br/>require human approval"]:::warn
AUDIT["AUDIT TRAIL<br/>append-only · tamper-evident<br/>complete (not sampled)"]
EVIDENCE["THE COMPLIANCE ARTIFACT<br/>agent decision · tool call · approval<br/>model version · policy evaluation · data access"]
AGENT --> ENGINE
RULES --> ENGINE
ENGINE --> DECIDE
DECIDE --> ALLOW
DECIDE --> DENY
DECIDE --> ESC
ENGINE -->|"every evaluation emits"| AUDIT
AUDIT --> EVIDENCE
classDef good fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
style AGENT fill:#14141f,stroke:#5eead4,color:#e4e4e8
style ENGINE fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
style RULES fill:#14141f,stroke:#5eead4,color:#e4e4e8
style DECIDE fill:#101018,stroke:#f0a868,color:#e4e4e8
style AUDIT fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
style EVIDENCE fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
Note: The load-bearing placement is the policy engine's location — it sits in the harness execution path between the agent and the world (DD-09 NemoClaw), not inside the agent process. An enforcement layer the agent can reach is an enforcement layer a prompt injection can disable. The audit trail is complete, not sampled: an observability dashboard that logs 1% of events is useful for engineering and useless for compliance.
Type: Lifecycle loop Purpose: The governance-to-engineering bridge as a four-stage lifecycle. A policy written in English is a statement of intent that does nothing at runtime. Policy-as-code closes the gap: policy compiles to a control, the control is tested, and the control's evaluations emit audit entries. The four stages form a loop, not a pipeline. Reading the diagram: Read clockwise as the lifecycle. Each stage's output is the next stage's input. A policy change propagates all the way around; a test failure propagates back to a control fix. The red callout marks the failure mode: a policy that stops at stage 1 (the wiki) is a policy that does not exist at runtime.
flowchart TB
P["1. POLICY<br/>plain English, owned by a named role<br/>'no agent may access prod data<br/>without human approval'<br/>(Govern output)"]
C["2. CONTROL<br/>compiled to an enforceable rule<br/>matches (surface == 'production_data')<br/>requires approval.state == 'approved'<br/>(B2-B8 / B11.3)"]
T["3. TEST<br/>verify the control fires<br/>propose access without approval<br/>assert control DENIES<br/>(Measure output · B9/B10)"]
A["4. AUDIT<br/>evaluation emits an entry<br/>policy_id · action · decision · reason<br/>timestamp · model_version<br/>(Manage output · B11.2)"]
P --> C
C --> T
T --> A
A -.->|"test failure → control fix"| C
A -.->|"policy gap → re-policy"| P
BREAK["FAILURE MODE<br/>policy stops at stage 1<br/>= the wiki = no runtime effect"]:::danger
P -.-> BREAK
classDef stage fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
class P stage
class C stage
class T stage
class A stage
class BREAK danger
Note: The loop, not the pipeline. A static policy document is the loop frozen at stage 1 — it is the failure mode the diagram flags. The reference implementations are DD-20 IronCurtain (plain-English policy compiled to deterministic JSON, zero LLM at runtime) and DD-09 NemoClaw (enforcement in the execution path, where the agent cannot reach it). Together they are the architecturally pure policy-as-code pattern.
Type: Layered architecture / the synthesis Purpose: The module's synthesis diagram. This is how a governance policy on the left becomes a production-deployed, audited control on the right — the full lifecycle, end to end, with every course module pinned to its role. This is the diagram to show a CISO who asks "where does my policy actually get enforced?" Reading the diagram: Read left-to-right as the transformation from governance to engineering to evidence. The left column is Govern (policy, the board layer). The middle column is Map + Measure + Manage (the engineering). The right column is the audit trail (the evidence). Each arrow is a transformation stage. The whole picture is the answer to "how does my security program satisfy the framework?"
flowchart LR
subgraph GOV["GOVERNANCE LAYER (the board)"]
direction TB
G1["GOVERN<br/>NIST AI RMF · ISO 42001<br/>EU AI Act · sector frameworks<br/>named owner · documented tolerance"]
G2["POLICY (plain English)<br/>'no prod data without approval'<br/>'high-risk tools need 2 reviewers'"]
end
subgraph ENG["ENGINEERING LAYER (the harness)"]
direction TB
E1["MAP<br/>threat model (B1)<br/>AI BOM (B11.2)"]
E2["CONTROL<br/>policy compiled to rule<br/>IronCurtain (DD-20) deterministic<br/>NemoClaw (DD-09) beneath agent"]
E3["MEASURE<br/>injection rates (B2)<br/>OWASP (B9) · MSFT (B10)<br/>coverage · residual risk"]
E4["MANAGE<br/>tool governance (B3)<br/>sandbox (B6) · observability (B8)"]
end
subgraph AUD["EVIDENCE LAYER (the regulator)"]
direction TB
A1["AUDIT TRAIL (B11.2)<br/>append-only · tamper-evident<br/>every decision · tool call · approval<br/>model version · policy evaluation"]
A2["AI BOM (B11.2)<br/>model · data · tools · deps<br/>config · external services"]
end
G2 -->|"policy-as-code compiles"| E2
G1 -->|"framework mapping"| E1
E1 --> E2
E2 --> E3
E3 --> E4
E2 -->|"every evaluation emits"| A1
E1 -->|"inventory as artifact"| A2
A1 -.->|"evidence back to governance"| G1
style GOV fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
style ENG fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style AUD fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
style G1 fill:#101018,stroke:#5eead4,color:#e4e4e8
style G2 fill:#101018,stroke:#5eead4,color:#e4e4e8
style E1 fill:#101018,stroke:#5eead4,color:#e4e4e8
style E2 fill:#101018,stroke:#5eead4,color:#e4e4e8
style E3 fill:#101018,stroke:#5eead4,color:#e4e4e8
style E4 fill:#101018,stroke:#5eead4,color:#e4e4e8
style A1 fill:#101018,stroke:#5eead4,color:#e4e4e8
style A2 fill:#101018,stroke:#5eead4,color:#e4e4e8
Note: The three columns are the three audiences an AI security program serves: the board (governance), the engineering team (the harness), and the regulator (the evidence). An agent that ships with the middle column but not the left and right columns will pass an engineering review and fail a governance review. The budget and the board attention follow the left and right columns — this module exists to build them.
# Diagrams — Module B11: Governance and Compliance
**Module**: B11 — Governance and Compliance
**Diagram count**: 5
**Tool**: Mermaid (primary). Each diagram validated in [Mermaid Live Editor](https://mermaid.live).
---
## Diagram 1 — The NIST AI RMF Four Core Functions
**Type**: Continuous-loop / function map
**Purpose**: The central framework of the module, made visual. NIST AI RMF (AI 100-1) organizes AI risk management into four core functions — Govern, Map, Measure, Manage — that operate as a **continuous loop, not a linear pipeline**. Every AI system is doing all four at all once. The diagram also pins the B2–B8 control that answers each function, so the technical work of the course maps onto the framework the budget and board follow.
**Reading the diagram**: Read Govern as the foundation (the outer ring) and Map → Measure → Manage as the operating loop. Each function node carries the course module that realizes it. Note Govern sits *underneath* the loop — without governance, the loop does not operate.
```mermaid
flowchart TB
GOV["GOVERN<br/>culture · policy · accountability<br/>named owner, documented tolerance<br/>→ policy-as-code layer (B11.3)"]
MAP["MAP<br/>context · use · risk surface<br/>what data, tools, users, blast radius<br/>→ threat model (B1) · AI BOM (B11.2)"]
MEASURE["MEASURE<br/>test · evaluate · verify<br/>success rates, coverage, residual risk<br/>→ injection rates (B2) · OWASP (B9) · MSFT (B10)"]
MANAGE["MANAGE<br/>mitigate · respond · remediate<br/>deployed controls + incident response<br/>→ tool governance (B3) · sandbox (B6) · obs (B8)"]
GOV ---|"foundation"| MAP
MAP -->|"context to test"| MEASURE
MEASURE -->|"evidence to act on"| MANAGE
MANAGE -.->|"residual risk → re-scope"| MAP
MANAGE -.->|"exceeds tolerance → re-policy"| GOV
classDef foundation fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
classDef loop fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
class GOV foundation
class MAP loop
class MEASURE loop
class MANAGE loop
```
> **Note**: Govern is the foundation, not a stage. An agent with a working guardrail but no named owner, no documented tolerance, and no policy-as-code layer has skipped Govern — and the loop above it cannot be evidenced in an audit. The RMF is voluntary in law; it is mandatory in practice because OMB M-24-10, insurers, and enterprise governance councils all map against it.
---
## Diagram 2 — The AI BOM Structure
**Type**: Inventory / component map
**Purpose**: The central artifact of B11.2. The AI BOM is the SBOM extended to AI — an inventory of everything an agent is made of, so the full supply chain is visible and therefore auditable. An SBOM that lists Python packages but not the model version or the MCP servers misses the components an AI attacker actually targets.
**Reading the diagram**: Six component classes radiate from the agent. The left three (model, training data, system prompt) are the AI-specific extensions over a traditional SBOM. The right three (tools/MCP, frameworks/SDKs, external services) are the SBOM surface, extended for agents. Together they are the inventory a regulator or auditor asks for first.
```mermaid
flowchart LR
AGENT["THE AGENT<br/>at a point in time"]
MODEL["MODEL<br/>provider · id · checkpoint<br/>modality · params · license"]
DATA["TRAINING DATA<br/>datasets · sources · provenance<br/>license · PII status"]
PROMPT["SYSTEM PROMPT & CONFIG<br/>prompt version · config hash<br/>guardrail versions"]
TOOLS["TOOLS / MCP SERVERS<br/>tool names · endpoints<br/>versions · capability scope"]
FRAME["FRAMEWORKS & SDKs<br/>harness · version<br/>dependencies (the SBOM subset)"]
EXT["EXTERNAL SERVICES<br/>API providers · vector DB<br/>identity · sandbox provider"]
MODEL --> AGENT
DATA --> AGENT
PROMPT --> AGENT
TOOLS --> AGENT
FRAME --> AGENT
EXT --> AGENT
classDef core fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
classDef aispec fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#e4e4e8
classDef sbom fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
class AGENT core
class MODEL aispec
class DATA aispec
class PROMPT aispec
class TOOLS sbom
class FRAME sbom
class EXT sbom
```
> **Note**: The green nodes (model, training data, system prompt) are the AI-specific fields a traditional SBOM does not capture — and they are exactly the fields an AI attacker targets (model-version jailbreaks, B0; training-data poisoning, B4; system-prompt extraction, B2). The amber nodes are the SBOM surface extended for agents (the tool registry and the external-service dependencies). The AI BOM must be generated from the running system, not maintained in a wiki — a wiki and reality drift, and the auditor reads reality.
---
## Diagram 3 — The Audit-Trail Architecture
**Type**: Pipeline / evidence architecture
**Purpose**: The audit trail is the evidence that controls are *enforced*, not just documented. This diagram shows how every agent action flows through the policy engine and produces an audit entry, and what the audit trail must contain for compliance.
**Reading the diagram**: Top-to-bottom: the agent proposes an action → the policy engine (in the harness execution path, not the agent process) evaluates it against the rules → the decision is enforced (ALLOW/DENY/ESCALATE) → every evaluation emits an audit entry to the append-only, tamper-evident trail. The audit trail is the compliance artifact; the observability dashboard (B8) is the engineering capability — they are separate systems.
```mermaid
flowchart TB
AGENT["AGENT PROPOSES ACTION<br/>tool call · data access · decision"]
ENGINE["POLICY ENGINE (in execution path)<br/>governance beneath the agent (DD-09)<br/>agent CANNOT reach to disable"]
RULES["POLICY RULES<br/>compiled from constitution.md<br/>deterministic, zero LLM at runtime (DD-20)"]
DECIDE{"DECISION"}
ALLOW["ALLOW<br/>action proceeds"]:::good
DENY["DENY<br/>action blocked (default-deny if no rule)"]:::danger
ESC["ESCALATE<br/>require human approval"]:::warn
AUDIT["AUDIT TRAIL<br/>append-only · tamper-evident<br/>complete (not sampled)"]
EVIDENCE["THE COMPLIANCE ARTIFACT<br/>agent decision · tool call · approval<br/>model version · policy evaluation · data access"]
AGENT --> ENGINE
RULES --> ENGINE
ENGINE --> DECIDE
DECIDE --> ALLOW
DECIDE --> DENY
DECIDE --> ESC
ENGINE -->|"every evaluation emits"| AUDIT
AUDIT --> EVIDENCE
classDef good fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
style AGENT fill:#14141f,stroke:#5eead4,color:#e4e4e8
style ENGINE fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
style RULES fill:#14141f,stroke:#5eead4,color:#e4e4e8
style DECIDE fill:#101018,stroke:#f0a868,color:#e4e4e8
style AUDIT fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
style EVIDENCE fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
```
> **Note**: The load-bearing placement is the policy engine's location — it sits in the harness execution path between the agent and the world (DD-09 NemoClaw), not inside the agent process. An enforcement layer the agent can reach is an enforcement layer a prompt injection can disable. The audit trail is complete, not sampled: an observability dashboard that logs 1% of events is useful for engineering and useless for compliance.
---
## Diagram 4 — The Policy-as-Code Flow (Policy → Control → Test → Audit)
**Type**: Lifecycle loop
**Purpose**: The governance-to-engineering bridge as a four-stage lifecycle. A policy written in English is a statement of intent that does nothing at runtime. Policy-as-code closes the gap: policy compiles to a control, the control is tested, and the control's evaluations emit audit entries. The four stages form a loop, not a pipeline.
**Reading the diagram**: Read clockwise as the lifecycle. Each stage's output is the next stage's input. A policy change propagates all the way around; a test failure propagates back to a control fix. The red callout marks the failure mode: a policy that stops at stage 1 (the wiki) is a policy that does not exist at runtime.
```mermaid
flowchart TB
P["1. POLICY<br/>plain English, owned by a named role<br/>'no agent may access prod data<br/>without human approval'<br/>(Govern output)"]
C["2. CONTROL<br/>compiled to an enforceable rule<br/>matches (surface == 'production_data')<br/>requires approval.state == 'approved'<br/>(B2-B8 / B11.3)"]
T["3. TEST<br/>verify the control fires<br/>propose access without approval<br/>assert control DENIES<br/>(Measure output · B9/B10)"]
A["4. AUDIT<br/>evaluation emits an entry<br/>policy_id · action · decision · reason<br/>timestamp · model_version<br/>(Manage output · B11.2)"]
P --> C
C --> T
T --> A
A -.->|"test failure → control fix"| C
A -.->|"policy gap → re-policy"| P
BREAK["FAILURE MODE<br/>policy stops at stage 1<br/>= the wiki = no runtime effect"]:::danger
P -.-> BREAK
classDef stage fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
class P stage
class C stage
class T stage
class A stage
class BREAK danger
```
> **Note**: The loop, not the pipeline. A static policy document is the loop frozen at stage 1 — it is the failure mode the diagram flags. The reference implementations are DD-20 IronCurtain (plain-English policy compiled to deterministic JSON, zero LLM at runtime) and DD-09 NemoClaw (enforcement in the execution path, where the agent cannot reach it). Together they are the architecturally pure policy-as-code pattern.
---
## Diagram 5 — The Governance-to-Engineering Bridge (End to End)
**Type**: Layered architecture / the synthesis
**Purpose**: The module's synthesis diagram. This is how a governance policy on the left becomes a production-deployed, audited control on the right — the full lifecycle, end to end, with every course module pinned to its role. This is the diagram to show a CISO who asks "where does my policy actually get enforced?"
**Reading the diagram**: Read left-to-right as the transformation from governance to engineering to evidence. The left column is Govern (policy, the board layer). The middle column is Map + Measure + Manage (the engineering). The right column is the audit trail (the evidence). Each arrow is a transformation stage. The whole picture is the answer to "how does my security program satisfy the framework?"
```mermaid
flowchart LR
subgraph GOV["GOVERNANCE LAYER (the board)"]
direction TB
G1["GOVERN<br/>NIST AI RMF · ISO 42001<br/>EU AI Act · sector frameworks<br/>named owner · documented tolerance"]
G2["POLICY (plain English)<br/>'no prod data without approval'<br/>'high-risk tools need 2 reviewers'"]
end
subgraph ENG["ENGINEERING LAYER (the harness)"]
direction TB
E1["MAP<br/>threat model (B1)<br/>AI BOM (B11.2)"]
E2["CONTROL<br/>policy compiled to rule<br/>IronCurtain (DD-20) deterministic<br/>NemoClaw (DD-09) beneath agent"]
E3["MEASURE<br/>injection rates (B2)<br/>OWASP (B9) · MSFT (B10)<br/>coverage · residual risk"]
E4["MANAGE<br/>tool governance (B3)<br/>sandbox (B6) · observability (B8)"]
end
subgraph AUD["EVIDENCE LAYER (the regulator)"]
direction TB
A1["AUDIT TRAIL (B11.2)<br/>append-only · tamper-evident<br/>every decision · tool call · approval<br/>model version · policy evaluation"]
A2["AI BOM (B11.2)<br/>model · data · tools · deps<br/>config · external services"]
end
G2 -->|"policy-as-code compiles"| E2
G1 -->|"framework mapping"| E1
E1 --> E2
E2 --> E3
E3 --> E4
E2 -->|"every evaluation emits"| A1
E1 -->|"inventory as artifact"| A2
A1 -.->|"evidence back to governance"| G1
style GOV fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
style ENG fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
style AUD fill:#14141f,stroke:#5eead4,stroke-width:2px,color:#5eead4
style G1 fill:#101018,stroke:#5eead4,color:#e4e4e8
style G2 fill:#101018,stroke:#5eead4,color:#e4e4e8
style E1 fill:#101018,stroke:#5eead4,color:#e4e4e8
style E2 fill:#101018,stroke:#5eead4,color:#e4e4e8
style E3 fill:#101018,stroke:#5eead4,color:#e4e4e8
style E4 fill:#101018,stroke:#5eead4,color:#e4e4e8
style A1 fill:#101018,stroke:#5eead4,color:#e4e4e8
style A2 fill:#101018,stroke:#5eead4,color:#e4e4e8
```
> **Note**: The three columns are the three audiences an AI security program serves: the board (governance), the engineering team (the harness), and the regulator (the evidence). An agent that ships with the middle column but not the left and right columns will pass an engineering review and fail a governance review. The budget and the board attention follow the left and right columns — this module exists to build them.