Diagrams — SDD-B08: NeMo Guardrails: The Production Guardrail Framework

Module: SDD-B08 — NeMo Guardrails: The Production Guardrail Framework Diagram count: 5 Tool: Mermaid (primary). Each diagram validated in Mermaid Live Editor.


Diagram 1 — The Five Rail Types: The Conversation Lifecycle

Type: Architecture / lifecycle Purpose: The foundational visual. NeMo Guardrails enforces policy through five rail types, each governing a different stage of the conversation lifecycle: input (what comes in), dialog (how it flows), retrieval (what is fetched), execution (what is called), and output (what goes out). A well-configured deployment uses multiple rails in sequence — the defense-in-depth thesis (B2) realized at the guardrail layer. Reading the diagram: A user message enters at the top. The input rails run first, then dialog rails steer the flow, retrieval rails govern fetched content, execution rails govern tool calls, and output rails run before the response returns. The guardrail layer is external — the agent cannot reach the rails to disable them.

flowchart TB
  USER["USER MESSAGE"]:::warn
  RAILS["THE GUARDRAIL LAYER (external to the agent)"]:::teal

  IR["INPUT RAILS<br/>toxicity · jailbreak patterns · PII · off-topic<br/>check BEFORE the model sees it<br/>1st line vs prompt injection"]:::danger
  DR["DIALOG RAILS<br/>on-topic? canonical-form match?<br/>steer along allowed paths<br/>'this agent only discusses X'"]:::danger
  RR["RETRIEVAL RAILS<br/>filter retrieved chunks (RAG)<br/>govern INDIRECT injection (SDD-B03)<br/>quarantine untrusted content"]:::danger
  ER["EXECUTION RAILS<br/>check tool + arguments + result<br/>govern the function-call surface (SDD-B04)<br/>prevent disallowed invocation"]:::danger
  OR["OUTPUT RAILS<br/>leaked data · harmful content · hallucinations<br/>check BEFORE the user sees it<br/>catches a model that complied despite input rails"]:::danger

  MODEL["THE MODEL (the agent)"]:::warn
  RESP["RESPONSE TO USER"]:::warn

  USER --> RAILS --> IR
  IR -->|"pass"| DR
  DR -->|"on-topic"| RR
  RR --> MODEL
  MODEL -->|"tool call"| ER
  ER -->|"allowed"| MODEL
  MODEL -->|"response"| OR
  OR -->|"pass"| RESP

  BLOCK["BLOCK / TRANSFORM / DEFLECT<br/>any rail can block, transform, or deflect<br/>at its stage of the lifecycle"]:::danger
  IR -.->|"fail"| BLOCK
  DR -.->|"off-topic"| BLOCK
  RR -.->|"untrusted chunk"| BLOCK
  ER -.->|"disallowed tool/args"| BLOCK
  OR -.->|"disallowed response"| BLOCK

  EXTERNAL["EXTERNAL EVALUATION<br/>the agent CANNOT reach the rails<br/>a compromised agent cannot disable them<br/>(Course 1 Module 0.2 principle)"]:::teal
  RAILS -.-> EXTERNAL

  classDef teal fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style RAILS fill:#101018,stroke:#5eead4,color:#5eead4
  style MODEL fill:#101018,stroke:#f0a868,color:#e4e4e8
  style BLOCK fill:#101018,stroke:#f08080,color:#f08080
  style EXTERNAL fill:#101018,stroke:#5eead4,color:#5eead4

Note: The five rails cover the full conversation lifecycle. A well-configured NeMo deployment uses multiple rails in sequence — input rails catch the jailbreak, output rails catch a model that complied anyway, retrieval rails govern indirect injection, execution rails govern tool calls. Each rail is a classifier with its own false-negative rate; the composition's bypass rate is what the red-team measures.


Diagram 2 — External Evaluation: Governance Beneath the Agent

Type: Trust architecture Purpose: The load-bearing architectural property that made NemoClaw the governance reference. The rails are evaluated EXTERNALLY to the agent — the guardrail layer is a separate process the agent calls through. The agent does not host, run, or reach the rails. This is the realization of the Course 1 Module 0.2 principle: if the agent can reach the enforcement layer, a compromised agent can disable it. External enforcement is the architecture that holds when the agent itself is the threat. Reading the diagram: The agent is inside its boundary. The guardrail layer is outside. Every model call passes through the guardrail layer. A compromised agent (prompt injection, jailbreak) cannot disable the rails, because the rails are not the agent's code to control.

flowchart LR
  subgraph OUT["OUTSIDE THE AGENT (the guardrail layer)"]
    direction TB
    GL["THE GUARDRAIL LAYER<br/>separate process · runs the 5 rails<br/>evaluates every model call"]:::teal
    IR["input rails"]:::danger
    OR["output rails"]:::danger
    GL --- IR & OR
  end

  subgraph IN["INSIDE THE AGENT BOUNDARY"]
    direction TB
    AGENT["THE AGENT / MODEL<br/>can be COMPROMISED by injection/jailbreak"]:::warn
  end

  REQ["model call (request)"]:::warn
  RES["guarded response"]:::warn

  AGENT ====>"passes through"|GL
  GL ====>"guarded"|AGENT

  PRINCIPLE["THE COURSE 1 MODULE 0.2 PRINCIPLE<br/>if the agent can REACH the enforcement layer<br/>a compromised agent can DISABLE it<br/>→ enforcement must sit OUTSIDE the agent's reach<br/>→ NeMo realizes this: the agent cannot touch the rails"]:::teal
  GL -.-> PRINCIPLE

  NEMOCLAW["NEMOCLAW (Course 1 DD-09)<br/>the production reference built on NeMo<br/>+4 score from external enforcement<br/>'governance done right'"]:::teal
  GL -.-> NEMOCLAW

  classDef teal fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style OUT fill:#0d0d14,stroke:#5eead4,stroke-width:1px,color:#e4e4e8
  style IN fill:#0d0d14,stroke:#f0a868,stroke-width:1px,color:#e4e4e8
  style GL fill:#101018,stroke:#5eead4,color:#5eead4
  style AGENT fill:#101018,stroke:#f0a868,color:#e4e4e8
  style PRINCIPLE fill:#101018,stroke:#5eead4,color:#5eead4
  style NEMOCLAW fill:#101018,stroke:#5eead4,color:#5eead4

Note: External enforcement protects the guardrails from being DISABLED — a compromised agent cannot reach the rail process to turn it off. It does NOT protect the rail's classifier from being EVADED by an input crafted against the classifier's model surface. That is the attack surface Diagram 4 covers.


Diagram 3 — Programmable Policy: Code, Not a Fixed Filter

Type: Comparison Purpose: NeMo's rails are configured in Colang (conversational flow) and Python (actions). The policy is code, not a fixed filter. This is the core architectural decision that distinguishes NeMo from a provider-side safety classifier. A fixed filter stops what its designer anticipated; a programmable rail stops what the DEPLOYER's policy specifies — and the policy can be as deployment-specific as required. Reading the diagram: Left column is the fixed filter (black box, stops anticipated patterns). Right column is the programmable rail (code in version control, auditable, deployment-specific). The trade-off: programmable policy is only as good as the policy author — a missing rail is a missing control.

flowchart LR
  subgraph FIXED["FIXED FILTER (provider-side safety classifier)"]
    direction TB
    F1["black box — cannot inspect<br/>what it stops or lets through"]:::warn
    F2["stops what the DESIGNER anticipated<br/>(known patterns at training time)"]:::warn
    F3["cannot express deployment-specific<br/>constraints (brand policy, compliance)"]:::warn
    F1 --> F2 --> F3
  end

  subgraph PROG["PROGRAMMABLE RAIL (NeMo)"]
    direction TB
    P1["Colang + Python — policy is CODE<br/>version-controlled, reviewable"]:::teal
    P2["stops what the DEPLOYER specifies<br/>(deployment-specific constraints)"]:::teal
    P3["auditable: the rails are a code review<br/>away from verification (B11)"]:::teal
    P1 --> P2 --> P3
  end

  FIXED ====>"vs"|PROG

  TRADEOFF["THE TRADE-OFF<br/>programmable policy is only as good<br/>as the POLICY AUTHOR<br/>a MISSING RAIL = a MISSING CONTROL<br/>the framework does not infer the policy<br/>the deployer should have written"]:::danger
  PROG -.-> TRADEOFF

  EXAMPLE["EXAMPLE<br/>'this banking agent never discloses account numbers'<br/>= a fixed filter CANNOT express this<br/>= a Colang output rail CAN (regex + classifier)"]:::teal
  PROG -.-> EXAMPLE

  classDef teal fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style FIXED fill:#0d0d14,stroke:#f0a868,stroke-width:1px,color:#e4e4e8
  style PROG fill:#0d0d14,stroke:#5eead4,stroke-width:1px,color:#e4e4e8
  style TRADEOFF fill:#101018,stroke:#f08080,color:#f08080
  style EXAMPLE fill:#101018,stroke:#5eead4,color:#5eead4

Note: The programmability is why NeMo can express deployment-specific compliance and brand policies a fixed filter cannot. The trade-off is the governance obligation: the rail configuration must be audited the way any security control is audited. A rail set that omits the deployment-specific constraints is a rail set with gaps — and the framework does not fill them automatically.


Diagram 4 — The Load-Bearing Vulnerability: The Guardrail Is a Model

Type: Attack surface analysis Purpose: The central insight of the deep-dive. The guardrails are evaluated by MODELS — embedding models, LLM-based classifiers. External enforcement protects the rails from being DISABLED by a compromised agent, but it does NOT protect the rail's classifier from being EVADED by an input crafted against the classifier's model surface. The guardrail ran; it classified the adversarial input as benign, because its classifier is a model and the input was crafted against its blind spots. The guardrail is a model, and models are injectable. Reading the diagram: Two threats. The DISABLED threat is stopped by external enforcement. The EVADED threat is NOT stopped — the rail's classifier has its own model surface, and an adversarial input crafted against it passes through.

flowchart TB
  RAIL["A NEMO RAIL (model-evaluated classifier)<br/>embedding model / LLM-based check<br/>runs externally to the agent"]:::teal

  THREAT1["THREAT 1 — DISABLED<br/>a compromised agent reaches the rail process<br/>and turns it off"]:::danger
  THREAT2["THREAT 2 — EVADED<br/>an adversarial input is crafted against the<br/>RAIL'S OWN CLASSIFIER model surface<br/>→ the rail classifies it as benign"]:::danger

  RAIL --> THREAT1
  RAIL --> THREAT2

  STOP1["STOPPED by external enforcement<br/>the agent CANNOT reach the rail process<br/>(Course 1 Module 0.2 principle holds)"]:::teal
  NOTSTOP["NOT STOPPED<br/>the rail's classifier IS a model<br/>→ it has false negatives / blind spots<br/>→ a context-specific attack (SDD-B06 technique)<br/>applied to the CLASSIFIER evades it<br/>→ external enforcement does not help here"]:::danger

  THREAT1 -.->|"external enforcement"| STOP1
  THREAT2 -.->|"the rail is a model"| NOTSTOP

  LOADBEARING["THE LOAD-BEARING VULNERABILITY<br/>external enforcement protects against DISABLE<br/>it does NOT protect against EVADE<br/>the guardrail is a MODEL, and models are INJECTABLE<br/>→ the rail has a RESIDUAL (measurable bypass rate)<br/>→ NeMo is a LAYER, not a BOUNDARY"]:::danger
  NOTSTOP -.-> LOADBEARING

  classDef teal fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style RAIL fill:#101018,stroke:#5eead4,color:#5eead4
  style STOP1 fill:#101018,stroke:#5eead4,color:#5eead4
  style LOADBEARING fill:#101018,stroke:#f08080,color:#f08080

Note: This is the same structural property as the SDD-B06 model-layer finding: a pattern-calibrated classifier has a novel-pattern bypass. The input rail's classifier was trained on known toxic/jailbreak patterns; an adversarial input crafted to avoid those patterns evades it. The output rail's LLM-based check can be manipulated if the response contains a prompt injection targeting the rail's own classifier model. The external architecture does not address this — the rails run, but they classify adversarial inputs as benign.


Diagram 5 — Defense-in-Depth Synthesis: Every Layer Has a Residual

Type: Layered architecture / thesis Purpose: The synthesis ties NeMo back to B2's thesis and the SDD-B04–SDD-B06 progression. NeMo Guardrails is the strongest production realization of governance-beneath-the-agent, and it is a layer — not a boundary. Every defense layer the course analyzed has a residual: CrabTrap's judge (SDD-B04), IronCurtain's deterministic policy (SDD-B05), the model's refusal training (SDD-B06), and now NeMo's guardrails. The prescription: layered defense, where each layer's bypass is bounded by the others. Reading the diagram: Four defense layers, each with a measured residual. NeMo joins the progression as the guardrail layer. The deterministic boundary (IronCurtain) is the limit the probabilistic layers cannot provide. Only the layered architecture holds.

flowchart TB
  subgraph LAYERS["THE DEFENSE LAYERS (each with a measured residual)"]
    direction TB
    L1["LAYER 1 — MODEL REFUSAL (SDD-B06)<br/>falls in 5 queries (context-specific attack)<br/>raises the bar · provides signal · NOT a boundary"]:::warn
    L2["LAYER 2 — NEMO GUARDRAILS (this deep-dive)<br/>5 rail types · externally evaluated<br/>RAIL RESIDUAL: classifier-evasion bypass<br/>(the guardrail is a model → injectable)"]:::warn
    L3["LAYER 3 — HARNESS GOVERNANCE (SDD-B04)<br/>CrabTrap's judge · INJECTABLE<br/>governs actions · has residuals"]:::warn
    L4["LAYER 4 — DETERMINISTIC BOUNDARY (SDD-B05)<br/>IronCurtain's compiled policy<br/>the BOUNDARY the probabilistic layers cannot provide<br/>has compilation residuals but is load-bearing"]:::teal
    L1 --> L2 --> L3 --> L4
  end

  THESIS["B2's THESIS — REALIZED ACROSS ALL LAYERS<br/>SDD-B03 measured: layered = single-digit rates<br/>SDD-B04: judge injectable · SDD-B05: deterministic has residuals<br/>SDD-B06: refusal falls in 5 queries · SDD-B08: rails have classifier residuals<br/>→ no single layer suffices (model OR guardrail OR harness)<br/>→ the layered architecture bounds each layer's bypass with the others<br/>→ NeMo composed with the layered architecture HOLDS;<br/>NeMo alone has the residuals this deep-dive measures"]:::teal

  LAYERS -.-> THESIS

  PRESCRIPTION["THE PRESCRIPTION<br/>input rails raise the bar + provide signal<br/>output rails catch what input misses<br/>retrieval/execution rails govern indirect-injection + tool surfaces<br/>deterministic boundary (IronCurtain) = the limit<br/>a NeMo deployment WITH the layered architecture holds;<br/>a NeMo deployment ALONE has measurable residuals"]:::teal
  THESIS -.-> PRESCRIPTION

  classDef teal fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style LAYERS fill:#0d0d14,stroke:#5eead4,stroke-width:1px,color:#e4e4e8
  style THESIS fill:#101018,stroke:#5eead4,color:#5eead4
  style PRESCRIPTION fill:#101018,stroke:#5eead4,color:#5eead4

Note: NeMo's contribution to the layered architecture is the programmable, multi-rail, externally-evaluated governance layer — the strongest production realization of the governance-beneath-the-agent principle. Its limitation is that the rails are model-evaluated and therefore injectable. Composed with the deterministic boundary (the limit the probabilistic layers cannot provide), the layered architecture bounds NeMo's residuals. This is the same conclusion every defense layer reached — and the prescription is the one the course has been building.

# Diagrams — SDD-B08: NeMo Guardrails: The Production Guardrail Framework

**Module**: SDD-B08 — NeMo Guardrails: The Production Guardrail Framework
**Diagram count**: 5
**Tool**: Mermaid (primary). Each diagram validated in [Mermaid Live Editor](https://mermaid.live).

---

## Diagram 1 — The Five Rail Types: The Conversation Lifecycle

**Type**: Architecture / lifecycle
**Purpose**: The foundational visual. NeMo Guardrails enforces policy through five rail types, each governing a different stage of the conversation lifecycle: input (what comes in), dialog (how it flows), retrieval (what is fetched), execution (what is called), and output (what goes out). A well-configured deployment uses multiple rails in sequence — the defense-in-depth thesis (B2) realized at the guardrail layer.
**Reading the diagram**: A user message enters at the top. The input rails run first, then dialog rails steer the flow, retrieval rails govern fetched content, execution rails govern tool calls, and output rails run before the response returns. The guardrail layer is external — the agent cannot reach the rails to disable them.

```mermaid
flowchart TB
  USER["USER MESSAGE"]:::warn
  RAILS["THE GUARDRAIL LAYER (external to the agent)"]:::teal

  IR["INPUT RAILS<br/>toxicity · jailbreak patterns · PII · off-topic<br/>check BEFORE the model sees it<br/>1st line vs prompt injection"]:::danger
  DR["DIALOG RAILS<br/>on-topic? canonical-form match?<br/>steer along allowed paths<br/>'this agent only discusses X'"]:::danger
  RR["RETRIEVAL RAILS<br/>filter retrieved chunks (RAG)<br/>govern INDIRECT injection (SDD-B03)<br/>quarantine untrusted content"]:::danger
  ER["EXECUTION RAILS<br/>check tool + arguments + result<br/>govern the function-call surface (SDD-B04)<br/>prevent disallowed invocation"]:::danger
  OR["OUTPUT RAILS<br/>leaked data · harmful content · hallucinations<br/>check BEFORE the user sees it<br/>catches a model that complied despite input rails"]:::danger

  MODEL["THE MODEL (the agent)"]:::warn
  RESP["RESPONSE TO USER"]:::warn

  USER --> RAILS --> IR
  IR -->|"pass"| DR
  DR -->|"on-topic"| RR
  RR --> MODEL
  MODEL -->|"tool call"| ER
  ER -->|"allowed"| MODEL
  MODEL -->|"response"| OR
  OR -->|"pass"| RESP

  BLOCK["BLOCK / TRANSFORM / DEFLECT<br/>any rail can block, transform, or deflect<br/>at its stage of the lifecycle"]:::danger
  IR -.->|"fail"| BLOCK
  DR -.->|"off-topic"| BLOCK
  RR -.->|"untrusted chunk"| BLOCK
  ER -.->|"disallowed tool/args"| BLOCK
  OR -.->|"disallowed response"| BLOCK

  EXTERNAL["EXTERNAL EVALUATION<br/>the agent CANNOT reach the rails<br/>a compromised agent cannot disable them<br/>(Course 1 Module 0.2 principle)"]:::teal
  RAILS -.-> EXTERNAL

  classDef teal fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style RAILS fill:#101018,stroke:#5eead4,color:#5eead4
  style MODEL fill:#101018,stroke:#f0a868,color:#e4e4e8
  style BLOCK fill:#101018,stroke:#f08080,color:#f08080
  style EXTERNAL fill:#101018,stroke:#5eead4,color:#5eead4
```

> **Note**: The five rails cover the full conversation lifecycle. A well-configured NeMo deployment uses multiple rails in sequence — input rails catch the jailbreak, output rails catch a model that complied anyway, retrieval rails govern indirect injection, execution rails govern tool calls. Each rail is a classifier with its own false-negative rate; the composition's bypass rate is what the red-team measures.

---

## Diagram 2 — External Evaluation: Governance Beneath the Agent

**Type**: Trust architecture
**Purpose**: The load-bearing architectural property that made NemoClaw the governance reference. The rails are evaluated EXTERNALLY to the agent — the guardrail layer is a separate process the agent calls through. The agent does not host, run, or reach the rails. This is the realization of the Course 1 Module 0.2 principle: if the agent can reach the enforcement layer, a compromised agent can disable it. External enforcement is the architecture that holds when the agent itself is the threat.
**Reading the diagram**: The agent is inside its boundary. The guardrail layer is outside. Every model call passes through the guardrail layer. A compromised agent (prompt injection, jailbreak) cannot disable the rails, because the rails are not the agent's code to control.

```mermaid
flowchart LR
  subgraph OUT["OUTSIDE THE AGENT (the guardrail layer)"]
    direction TB
    GL["THE GUARDRAIL LAYER<br/>separate process · runs the 5 rails<br/>evaluates every model call"]:::teal
    IR["input rails"]:::danger
    OR["output rails"]:::danger
    GL --- IR & OR
  end

  subgraph IN["INSIDE THE AGENT BOUNDARY"]
    direction TB
    AGENT["THE AGENT / MODEL<br/>can be COMPROMISED by injection/jailbreak"]:::warn
  end

  REQ["model call (request)"]:::warn
  RES["guarded response"]:::warn

  AGENT ====>"passes through"|GL
  GL ====>"guarded"|AGENT

  PRINCIPLE["THE COURSE 1 MODULE 0.2 PRINCIPLE<br/>if the agent can REACH the enforcement layer<br/>a compromised agent can DISABLE it<br/>→ enforcement must sit OUTSIDE the agent's reach<br/>→ NeMo realizes this: the agent cannot touch the rails"]:::teal
  GL -.-> PRINCIPLE

  NEMOCLAW["NEMOCLAW (Course 1 DD-09)<br/>the production reference built on NeMo<br/>+4 score from external enforcement<br/>'governance done right'"]:::teal
  GL -.-> NEMOCLAW

  classDef teal fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style OUT fill:#0d0d14,stroke:#5eead4,stroke-width:1px,color:#e4e4e8
  style IN fill:#0d0d14,stroke:#f0a868,stroke-width:1px,color:#e4e4e8
  style GL fill:#101018,stroke:#5eead4,color:#5eead4
  style AGENT fill:#101018,stroke:#f0a868,color:#e4e4e8
  style PRINCIPLE fill:#101018,stroke:#5eead4,color:#5eead4
  style NEMOCLAW fill:#101018,stroke:#5eead4,color:#5eead4
```

> **Note**: External enforcement protects the guardrails from being DISABLED — a compromised agent cannot reach the rail process to turn it off. It does NOT protect the rail's classifier from being EVADED by an input crafted against the classifier's model surface. That is the attack surface Diagram 4 covers.

---

## Diagram 3 — Programmable Policy: Code, Not a Fixed Filter

**Type**: Comparison
**Purpose**: NeMo's rails are configured in Colang (conversational flow) and Python (actions). The policy is code, not a fixed filter. This is the core architectural decision that distinguishes NeMo from a provider-side safety classifier. A fixed filter stops what its designer anticipated; a programmable rail stops what the DEPLOYER's policy specifies — and the policy can be as deployment-specific as required.
**Reading the diagram**: Left column is the fixed filter (black box, stops anticipated patterns). Right column is the programmable rail (code in version control, auditable, deployment-specific). The trade-off: programmable policy is only as good as the policy author — a missing rail is a missing control.

```mermaid
flowchart LR
  subgraph FIXED["FIXED FILTER (provider-side safety classifier)"]
    direction TB
    F1["black box — cannot inspect<br/>what it stops or lets through"]:::warn
    F2["stops what the DESIGNER anticipated<br/>(known patterns at training time)"]:::warn
    F3["cannot express deployment-specific<br/>constraints (brand policy, compliance)"]:::warn
    F1 --> F2 --> F3
  end

  subgraph PROG["PROGRAMMABLE RAIL (NeMo)"]
    direction TB
    P1["Colang + Python — policy is CODE<br/>version-controlled, reviewable"]:::teal
    P2["stops what the DEPLOYER specifies<br/>(deployment-specific constraints)"]:::teal
    P3["auditable: the rails are a code review<br/>away from verification (B11)"]:::teal
    P1 --> P2 --> P3
  end

  FIXED ====>"vs"|PROG

  TRADEOFF["THE TRADE-OFF<br/>programmable policy is only as good<br/>as the POLICY AUTHOR<br/>a MISSING RAIL = a MISSING CONTROL<br/>the framework does not infer the policy<br/>the deployer should have written"]:::danger
  PROG -.-> TRADEOFF

  EXAMPLE["EXAMPLE<br/>'this banking agent never discloses account numbers'<br/>= a fixed filter CANNOT express this<br/>= a Colang output rail CAN (regex + classifier)"]:::teal
  PROG -.-> EXAMPLE

  classDef teal fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style FIXED fill:#0d0d14,stroke:#f0a868,stroke-width:1px,color:#e4e4e8
  style PROG fill:#0d0d14,stroke:#5eead4,stroke-width:1px,color:#e4e4e8
  style TRADEOFF fill:#101018,stroke:#f08080,color:#f08080
  style EXAMPLE fill:#101018,stroke:#5eead4,color:#5eead4
```

> **Note**: The programmability is why NeMo can express deployment-specific compliance and brand policies a fixed filter cannot. The trade-off is the governance obligation: the rail configuration must be audited the way any security control is audited. A rail set that omits the deployment-specific constraints is a rail set with gaps — and the framework does not fill them automatically.

---

## Diagram 4 — The Load-Bearing Vulnerability: The Guardrail Is a Model

**Type**: Attack surface analysis
**Purpose**: The central insight of the deep-dive. The guardrails are evaluated by MODELS — embedding models, LLM-based classifiers. External enforcement protects the rails from being DISABLED by a compromised agent, but it does NOT protect the rail's classifier from being EVADED by an input crafted against the classifier's model surface. The guardrail ran; it classified the adversarial input as benign, because its classifier is a model and the input was crafted against its blind spots. The guardrail is a model, and models are injectable.
**Reading the diagram**: Two threats. The DISABLED threat is stopped by external enforcement. The EVADED threat is NOT stopped — the rail's classifier has its own model surface, and an adversarial input crafted against it passes through.

```mermaid
flowchart TB
  RAIL["A NEMO RAIL (model-evaluated classifier)<br/>embedding model / LLM-based check<br/>runs externally to the agent"]:::teal

  THREAT1["THREAT 1 — DISABLED<br/>a compromised agent reaches the rail process<br/>and turns it off"]:::danger
  THREAT2["THREAT 2 — EVADED<br/>an adversarial input is crafted against the<br/>RAIL'S OWN CLASSIFIER model surface<br/>→ the rail classifies it as benign"]:::danger

  RAIL --> THREAT1
  RAIL --> THREAT2

  STOP1["STOPPED by external enforcement<br/>the agent CANNOT reach the rail process<br/>(Course 1 Module 0.2 principle holds)"]:::teal
  NOTSTOP["NOT STOPPED<br/>the rail's classifier IS a model<br/>→ it has false negatives / blind spots<br/>→ a context-specific attack (SDD-B06 technique)<br/>applied to the CLASSIFIER evades it<br/>→ external enforcement does not help here"]:::danger

  THREAT1 -.->|"external enforcement"| STOP1
  THREAT2 -.->|"the rail is a model"| NOTSTOP

  LOADBEARING["THE LOAD-BEARING VULNERABILITY<br/>external enforcement protects against DISABLE<br/>it does NOT protect against EVADE<br/>the guardrail is a MODEL, and models are INJECTABLE<br/>→ the rail has a RESIDUAL (measurable bypass rate)<br/>→ NeMo is a LAYER, not a BOUNDARY"]:::danger
  NOTSTOP -.-> LOADBEARING

  classDef teal fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style RAIL fill:#101018,stroke:#5eead4,color:#5eead4
  style STOP1 fill:#101018,stroke:#5eead4,color:#5eead4
  style LOADBEARING fill:#101018,stroke:#f08080,color:#f08080
```

> **Note**: This is the same structural property as the SDD-B06 model-layer finding: a pattern-calibrated classifier has a novel-pattern bypass. The input rail's classifier was trained on known toxic/jailbreak patterns; an adversarial input crafted to avoid those patterns evades it. The output rail's LLM-based check can be manipulated if the response contains a prompt injection targeting the rail's own classifier model. The external architecture does not address this — the rails run, but they classify adversarial inputs as benign.

---

## Diagram 5 — Defense-in-Depth Synthesis: Every Layer Has a Residual

**Type**: Layered architecture / thesis
**Purpose**: The synthesis ties NeMo back to B2's thesis and the SDD-B04–SDD-B06 progression. NeMo Guardrails is the strongest production realization of governance-beneath-the-agent, and it is a layer — not a boundary. Every defense layer the course analyzed has a residual: CrabTrap's judge (SDD-B04), IronCurtain's deterministic policy (SDD-B05), the model's refusal training (SDD-B06), and now NeMo's guardrails. The prescription: layered defense, where each layer's bypass is bounded by the others.
**Reading the diagram**: Four defense layers, each with a measured residual. NeMo joins the progression as the guardrail layer. The deterministic boundary (IronCurtain) is the limit the probabilistic layers cannot provide. Only the layered architecture holds.

```mermaid
flowchart TB
  subgraph LAYERS["THE DEFENSE LAYERS (each with a measured residual)"]
    direction TB
    L1["LAYER 1 — MODEL REFUSAL (SDD-B06)<br/>falls in 5 queries (context-specific attack)<br/>raises the bar · provides signal · NOT a boundary"]:::warn
    L2["LAYER 2 — NEMO GUARDRAILS (this deep-dive)<br/>5 rail types · externally evaluated<br/>RAIL RESIDUAL: classifier-evasion bypass<br/>(the guardrail is a model → injectable)"]:::warn
    L3["LAYER 3 — HARNESS GOVERNANCE (SDD-B04)<br/>CrabTrap's judge · INJECTABLE<br/>governs actions · has residuals"]:::warn
    L4["LAYER 4 — DETERMINISTIC BOUNDARY (SDD-B05)<br/>IronCurtain's compiled policy<br/>the BOUNDARY the probabilistic layers cannot provide<br/>has compilation residuals but is load-bearing"]:::teal
    L1 --> L2 --> L3 --> L4
  end

  THESIS["B2's THESIS — REALIZED ACROSS ALL LAYERS<br/>SDD-B03 measured: layered = single-digit rates<br/>SDD-B04: judge injectable · SDD-B05: deterministic has residuals<br/>SDD-B06: refusal falls in 5 queries · SDD-B08: rails have classifier residuals<br/>→ no single layer suffices (model OR guardrail OR harness)<br/>→ the layered architecture bounds each layer's bypass with the others<br/>→ NeMo composed with the layered architecture HOLDS;<br/>NeMo alone has the residuals this deep-dive measures"]:::teal

  LAYERS -.-> THESIS

  PRESCRIPTION["THE PRESCRIPTION<br/>input rails raise the bar + provide signal<br/>output rails catch what input misses<br/>retrieval/execution rails govern indirect-injection + tool surfaces<br/>deterministic boundary (IronCurtain) = the limit<br/>a NeMo deployment WITH the layered architecture holds;<br/>a NeMo deployment ALONE has measurable residuals"]:::teal
  THESIS -.-> PRESCRIPTION

  classDef teal fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  classDef warn fill:#14141f,stroke:#f0a868,stroke-width:1.5px,color:#e4e4e8
  classDef danger fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style LAYERS fill:#0d0d14,stroke:#5eead4,stroke-width:1px,color:#e4e4e8
  style THESIS fill:#101018,stroke:#5eead4,color:#5eead4
  style PRESCRIPTION fill:#101018,stroke:#5eead4,color:#5eead4
```

> **Note**: NeMo's contribution to the layered architecture is the programmable, multi-rail, externally-evaluated governance layer — the strongest production realization of the governance-beneath-the-agent principle. Its limitation is that the rails are model-evaluated and therefore injectable. Composed with the deterministic boundary (the limit the probabilistic layers cannot provide), the layered architecture bounds NeMo's residuals. This is the same conclusion every defense layer reached — and the prescription is the one the course has been building.