Diagrams — Capstone CAP2: The Calibrated Uncensored Agent

Module: CAP2 — The Calibrated Uncensored Agent Diagram count: 5 Tool: Mermaid (primary). Each diagram validated in Mermaid Live Editor.


Diagram 1 — The Synthesis Principle (the two layers)

Type: Layered flowchart with annotation Purpose: The single diagram that anchors the capstone. The model executes (Layer 3, steered); the harness bounds (Layer 5, policy gates). Both are required. Reading the diagram: Bottom = the model (uncensored to execute). Top = the harness (policy gates to bound). The annotation is the synthesis sentence.

flowchart TD
  subgraph Harness["THE HARNESS (Layer 5) — policy gates"]
    PG["Policy gate: deterministic, auditable\nallow / veto per tool call\nscope, approval, destructive-action rules"]
  end
  Note["THE SYNTHESIS:\nUncensor the model so it executes\nHarness the model so it executes only what it should"]
  subgraph Model["THE MODEL (Layers 1-4) — steered to execute"]
    SV["Steered model: abliterated or DPO'd\nlow refusal on legitimate prompts\nformulates the tool call"]
  end

  Model --> Note
  Note --> Harness

  style PG fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style Note fill:#08080c,stroke:#5eead466,stroke-dasharray: 4 2,color:#5eead4
  style SV fill:#14141f,stroke:#5eead480,color:#e4e4e8

Diagram 2 — The Honest Caveat (why the harness must be strong)

Type: Comparison / risk matrix Purpose: An uncensored model in a weak harness is strictly more dangerous than a refusal-trained model in a weak harness. The harness strength is non-negotiable. Reading the diagram: Four quadrants. The top-right (uncensored + strong harness) is the capstone's goal. The bottom-right (uncensored + weak harness) is the cardinal failure.

flowchart LR
  subgraph Weak["WEAK harness (gates leak)"]
    RT_Weak["Refusal-trained model\nrefusal is a backstop\n(less dangerous)"]
    UC_Weak["UNCENSORED model\nno backstop, gates leak\n(STRICTLY MORE DANGEROUS)"]
  end
  subgraph Strong["STRONG harness (gates hold, ~100% veto)"]
    RT_Strong["Refusal-trained model\nbelt + suspenders\n(safe, but may refuse legitimate calls)"]
    UC_Strong["UNCENSORED model\nexecutes legitimate,\nvetoes illegitimate\n(THE CAPSTONE GOAL)"]
  end

  style RT_Weak fill:#14141f,stroke:#ffffff1f,color:#9494a0
  style UC_Weak fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style RT_Strong fill:#14141f,stroke:#5eead480,color:#e4e4e8
  style UC_Strong fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa

Diagram 3 — The Seven-Phase Pipeline

Type: Layered pipeline Purpose: The build sequence. Seven phases, bottom-up, each producing a deliverable. Reading the diagram: Bottom-up. Phase 1 chooses the approach; Phase 7 evaluates and defends.

flowchart TD
  P1["PHASE 1 — Choose base + steering approach (defend it)<br/>abliterate vs DPO-toward-compliance"]
  P2["PHASE 2 — Steer<br/>measure refusal reduction + capability cost"]
  P3["PHASE 3 — (Optional) Reasoning distill<br/>recover capability if abliteration cost is high"]
  P4["PHASE 4 — Quantize (GGUF)<br/>Q4_K_M default"]
  P5["PHASE 5 — Serve locally<br/>Ollama / llama.cpp, no telemetry"]
  P6["PHASE 6 — Build harness policy gates<br/>eval'd gates, ~100% veto on illegitimate"]
  P7["PHASE 7 — Eval + trade-off defense<br/>refusal rate + veto rate + defense document"]

  P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> P7

  style P1 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style P2 fill:#14141f,stroke:#5eead480,color:#e4e4e8
  style P3 fill:#14141f,stroke:#ffffff1f,color:#9494a0
  style P4 fill:#14141f,stroke:#5eead480,color:#e4e4e8
  style P5 fill:#14141f,stroke:#5eead480,color:#e4e4e8
  style P6 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style P7 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8

Diagram 4 — The Two Metrics (refusal rate vs veto rate)

Type: Dual measurement Purpose: The steering's benefit (low refusal on legitimate) and the harness's strength (high veto on illegitimate). Both must be measured. Reading the diagram: Left = the model's metric (steering). Right = the harness's metric (policy gates). The demo shows both in one run.

flowchart LR
  subgraph ModelMetric["STEERING metric"]
    LP["Legitimate prompt set<br/>(authorized actions)"]
    RR["Refusal rate<br/>steered vs base"]
    Pass1["Pass: materially lower<br/>than base refusal rate"]
    LP --> RR --> Pass1
  end
  subgraph HarnessMetric["HARNESS metric"]
    IP["Illegitimate prompt set<br/>(out-of-policy actions)"]
    VR["Veto rate<br/>policy gate recall"]
    Pass2["Pass: ~100%<br/>(any leak = fail)"]
    IP --> VR --> Pass2
  end

  style LP fill:#08080c,stroke:#5eead44c,color:#e4e4e8
  style RR fill:#14141f,stroke:#5eead480,color:#e4e4e8
  style Pass1 fill:#08080c,stroke:#82e0aa,color:#82e0aa
  style IP fill:#08080c,stroke:#f080804c,color:#e4e4e8
  style VR fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#e4e4e8
  style Pass2 fill:#08080c,stroke:#82e0aa,color:#82e0aa

Diagram 5 — The Policy Gate (the boundary in code)

Type: Decision flow Purpose: Why the boundary belongs in the harness, not the weights. The policy gate is deterministic, auditable, and revisable — properties a model-level refusal cannot have. Reading the diagram: Every tool call passes through three checks. Any check fails = veto with a reason. All pass = allow.

flowchart TD
  Call["Tool call: tool_name + args"]
  Call --> G1{Tool permitted?}
  G1 -->|"no"| V1["VETO: tool not allowed"]
  G1 -->|"yes"| G2{Target in scope?}
  G2 -->|"no"| V2["VETO: out of scope"]
  G2 -->|"yes"| G3{Approval required<br/>and given?}
  G3 -->|"required, not given"| V3["VETO: needs approval"]
  G3 -->|"not required, or given"| Allow["ALLOW: execute"]

  style Call fill:#14141f,stroke:#ffffff1f,color:#e4e4e8
  style G1 fill:#08080c,stroke:#5eead466,color:#e4e4e8
  style G2 fill:#08080c,stroke:#5eead466,color:#e4e4e8
  style G3 fill:#08080c,stroke:#5eead466,color:#e4e4e8
  style V1 fill:#14141f,stroke:#f08080,color:#f08080
  style V2 fill:#14141f,stroke:#f08080,color:#f08080
  style V3 fill:#14141f,stroke:#f08080,color:#f08080
  style Allow fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa

Validation notes

# Diagrams — Capstone CAP2: The Calibrated Uncensored Agent

**Module**: CAP2 — The Calibrated Uncensored Agent
**Diagram count**: 5
**Tool**: Mermaid (primary). Each diagram validated in [Mermaid Live Editor](https://mermaid.live).

---

## Diagram 1 — The Synthesis Principle (the two layers)

**Type**: Layered flowchart with annotation
**Purpose**: The single diagram that anchors the capstone. The model executes (Layer 3, steered); the harness bounds (Layer 5, policy gates). Both are required.
**Reading the diagram**: Bottom = the model (uncensored to execute). Top = the harness (policy gates to bound). The annotation is the synthesis sentence.

```mermaid
flowchart TD
  subgraph Harness["THE HARNESS (Layer 5) — policy gates"]
    PG["Policy gate: deterministic, auditable\nallow / veto per tool call\nscope, approval, destructive-action rules"]
  end
  Note["THE SYNTHESIS:\nUncensor the model so it executes\nHarness the model so it executes only what it should"]
  subgraph Model["THE MODEL (Layers 1-4) — steered to execute"]
    SV["Steered model: abliterated or DPO'd\nlow refusal on legitimate prompts\nformulates the tool call"]
  end

  Model --> Note
  Note --> Harness

  style PG fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style Note fill:#08080c,stroke:#5eead466,stroke-dasharray: 4 2,color:#5eead4
  style SV fill:#14141f,stroke:#5eead480,color:#e4e4e8
```

---

## Diagram 2 — The Honest Caveat (why the harness must be strong)

**Type**: Comparison / risk matrix
**Purpose**: An uncensored model in a weak harness is strictly more dangerous than a refusal-trained model in a weak harness. The harness strength is non-negotiable.
**Reading the diagram**: Four quadrants. The top-right (uncensored + strong harness) is the capstone's goal. The bottom-right (uncensored + weak harness) is the cardinal failure.

```mermaid
flowchart LR
  subgraph Weak["WEAK harness (gates leak)"]
    RT_Weak["Refusal-trained model\nrefusal is a backstop\n(less dangerous)"]
    UC_Weak["UNCENSORED model\nno backstop, gates leak\n(STRICTLY MORE DANGEROUS)"]
  end
  subgraph Strong["STRONG harness (gates hold, ~100% veto)"]
    RT_Strong["Refusal-trained model\nbelt + suspenders\n(safe, but may refuse legitimate calls)"]
    UC_Strong["UNCENSORED model\nexecutes legitimate,\nvetoes illegitimate\n(THE CAPSTONE GOAL)"]
  end

  style RT_Weak fill:#14141f,stroke:#ffffff1f,color:#9494a0
  style UC_Weak fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style RT_Strong fill:#14141f,stroke:#5eead480,color:#e4e4e8
  style UC_Strong fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
```

---

## Diagram 3 — The Seven-Phase Pipeline

**Type**: Layered pipeline
**Purpose**: The build sequence. Seven phases, bottom-up, each producing a deliverable.
**Reading the diagram**: Bottom-up. Phase 1 chooses the approach; Phase 7 evaluates and defends.

```mermaid
flowchart TD
  P1["PHASE 1 — Choose base + steering approach (defend it)<br/>abliterate vs DPO-toward-compliance"]
  P2["PHASE 2 — Steer<br/>measure refusal reduction + capability cost"]
  P3["PHASE 3 — (Optional) Reasoning distill<br/>recover capability if abliteration cost is high"]
  P4["PHASE 4 — Quantize (GGUF)<br/>Q4_K_M default"]
  P5["PHASE 5 — Serve locally<br/>Ollama / llama.cpp, no telemetry"]
  P6["PHASE 6 — Build harness policy gates<br/>eval'd gates, ~100% veto on illegitimate"]
  P7["PHASE 7 — Eval + trade-off defense<br/>refusal rate + veto rate + defense document"]

  P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> P7

  style P1 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style P2 fill:#14141f,stroke:#5eead480,color:#e4e4e8
  style P3 fill:#14141f,stroke:#ffffff1f,color:#9494a0
  style P4 fill:#14141f,stroke:#5eead480,color:#e4e4e8
  style P5 fill:#14141f,stroke:#5eead480,color:#e4e4e8
  style P6 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style P7 fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
```

---

## Diagram 4 — The Two Metrics (refusal rate vs veto rate)

**Type**: Dual measurement
**Purpose**: The steering's benefit (low refusal on legitimate) and the harness's strength (high veto on illegitimate). Both must be measured.
**Reading the diagram**: Left = the model's metric (steering). Right = the harness's metric (policy gates). The demo shows both in one run.

```mermaid
flowchart LR
  subgraph ModelMetric["STEERING metric"]
    LP["Legitimate prompt set<br/>(authorized actions)"]
    RR["Refusal rate<br/>steered vs base"]
    Pass1["Pass: materially lower<br/>than base refusal rate"]
    LP --> RR --> Pass1
  end
  subgraph HarnessMetric["HARNESS metric"]
    IP["Illegitimate prompt set<br/>(out-of-policy actions)"]
    VR["Veto rate<br/>policy gate recall"]
    Pass2["Pass: ~100%<br/>(any leak = fail)"]
    IP --> VR --> Pass2
  end

  style LP fill:#08080c,stroke:#5eead44c,color:#e4e4e8
  style RR fill:#14141f,stroke:#5eead480,color:#e4e4e8
  style Pass1 fill:#08080c,stroke:#82e0aa,color:#82e0aa
  style IP fill:#08080c,stroke:#f080804c,color:#e4e4e8
  style VR fill:#14141f,stroke:#f08080,stroke-width:1.5px,color:#e4e4e8
  style Pass2 fill:#08080c,stroke:#82e0aa,color:#82e0aa
```

---

## Diagram 5 — The Policy Gate (the boundary in code)

**Type**: Decision flow
**Purpose**: Why the boundary belongs in the harness, not the weights. The policy gate is deterministic, auditable, and revisable — properties a model-level refusal cannot have.
**Reading the diagram**: Every tool call passes through three checks. Any check fails = veto with a reason. All pass = allow.

```mermaid
flowchart TD
  Call["Tool call: tool_name + args"]
  Call --> G1{Tool permitted?}
  G1 -->|"no"| V1["VETO: tool not allowed"]
  G1 -->|"yes"| G2{Target in scope?}
  G2 -->|"no"| V2["VETO: out of scope"]
  G2 -->|"yes"| G3{Approval required<br/>and given?}
  G3 -->|"required, not given"| V3["VETO: needs approval"]
  G3 -->|"not required, or given"| Allow["ALLOW: execute"]

  style Call fill:#14141f,stroke:#ffffff1f,color:#e4e4e8
  style G1 fill:#08080c,stroke:#5eead466,color:#e4e4e8
  style G2 fill:#08080c,stroke:#5eead466,color:#e4e4e8
  style G3 fill:#08080c,stroke:#5eead466,color:#e4e4e8
  style V1 fill:#14141f,stroke:#f08080,color:#f08080
  style V2 fill:#14141f,stroke:#f08080,color:#f08080
  style V3 fill:#14141f,stroke:#f08080,color:#f08080
  style Allow fill:#14141f,stroke:#82e0aa,stroke-width:1.5px,color:#82e0aa
```

---

## Validation notes

- All five diagrams use the course design system colors: `#14141f` panel fill, `#5eead4` accent for primary, `#f08080` for danger/veto, `#82e0aa` for pass/allow, `#ffffff1f` for secondary borders, `#e4e4e8` / `#9494a0` for text.
- Paste each into [Mermaid Live Editor](https://mermaid.live) to render. All use stable Mermaid syntax (`block-beta`, `flowchart`) supported in current Mermaid (v10.4+).
- For the slide deck (artifact 03), these are rendered as static captures from Mermaid Live, inlined into reveal.js.