Module FT23 — Synthesis: Uncensor the Model, Harness the Model

Course: Course 3 — LLM Fine-Tuning Masterclass Module: FT23 — Synthesis: Uncensor the Model, Harness the Model Duration: 60 minutes Level: Senior Engineer and above Prerequisites: All prior modules. Rewards having taken Course 1.

Learning Objectives

After completing this module, you will be able to:

State the synthesis principle — uncensor the model so it executes; harness the model so it executes only what it should — and defend it as the complement of Course 1's thesis (model is 1.6%, harness is 98.4%), not its contradiction.
Explain why abliteration (refusal removed inside the weights, Layer 3) and harness policy gates (boundaries around the model, Layer 5) solve different problems at different layers, and why a serious system needs both.
Make the tool-use agent argument — why a model that refuses mid-loop is broken as an agent, and why refusal belongs in an auditable, deterministic, doctrine-tunable, retrain-free harness policy gate rather than in black-box weights.
State the honest caveat — abliteration measurably degrades capability (the −18.8pp GSM8K figure from FT17) — and why an uncensored model in a weak harness is strictly more dangerous than a refusal-trained model in a weak harness. Pillar 5 raises the harness bar; it does not lower it.
Map your next steps: Course 1 (build the harness), Course 2A (security-domain harnesses), Course 2B (red-team the harness).

23.1 — The Synthesis Principle

One sentence, and the whole course pays off.

The sentence

Uncensor the model so it executes; harness the model so it executes only what it should.

You have spent twenty-two modules learning to steer a model. SFT steers format (FT12). DPO steers preference (FT13). GRPO steers reasoning (FT14). Abliteration steers away from refusal (FT17). Compliance via DPO steers toward the policy you actually want (FT18). You have learned to quantize and serve the result (FT19–FT20), and to do it inside HIPAA, BAA-free, and air-gapped environments (FT21–FT22).

This module is the bridge. It takes everything you can do to the model (Layers 1–4) and places it inside the thing you cannot do to the model — the harness (Layer 5). The result is a complete system: a model you have steered toward your intent, deployed inside a harness that bounds what it may do.

The complement, not the contradiction

Course 1's thesis: the model is ~1.6% of an agent; the harness is the other 98.4%.

Course 3's thesis (FT00): fine-tuning steers behavior; it does not teach knowledge.

This module's synthesis is the junction of those two theses. It is not a contradiction of either. Read them together:

Course 1 says the harness is most of the system. True.
Course 3 says what you do to the 1.6% is steer its behavior, not teach it knowledge. Also true.
FT23 says: when you steer the model so it stops refusing (so it executes), you have changed what it does — you have not changed what it may do. The gap between does and may is exactly where the harness lives. That is the synthesis.

Take the two courses together and you hold the whole picture. Course 3 is the course you take to understand the engine — how to make the model do what you want, on your hardware, with your data, sending no bytes to anyone. Course 1 is the course you take to build the brakes — the execution loop, the tool layer, the permission gates, the observability, the threat model. This module is the hinge between them.

Why the synthesis is load-bearing

Without this synthesis, two failure modes dominate the field:

The model-only maximalist. Believes uncensoring the model is the safety story. It is not. Uncensoring changes what the model does; it does not change what it may do. A model that won't refuse is a model that will happily execute the dangerous thing too. Without a harness, this is the dangerous error.
The harness-only maximalist. Believes you should leave the model refusal-trained and let the harness cope. This works for a chatbot. It is broken for agents, as we will show. A model that refuses to formulate a legitimate tool call mid-loop is an agent that halts, and a halted agent is a production outage.

The synthesis is the rejection of both maximalisms. The model steers; the harness bounds. You need both, at different layers, for different reasons.

23.2 — Two Layers, Two Problems

Abliteration and the harness policy gate are not competing solutions to the same problem. They solve different problems at different layers.

What abliteration does (Layer 3)

Abliteration (FT17, after Arditi et al., NeurIPS 2024) finds the single direction in the residual stream that mediates refusal and removes it — typically by orthogonalizing the model's weights against that direction. The result is a model that no longer refuses. The refusal behavior is gone inside the weights.

This is a Layer 3 operation. It edits the model's forward pass directly. It does not add any boundary; it removes a behavior. Critically:

It is not auditable in the way a policy gate is. You cannot point to "the refusal policy" — it is a direction in a billion-dimensional residual stream.
It is not tunable to doctrine. You cannot say "refuse this class of request in this deployment but not that one" — the direction is gone for all inputs.
It is not revisable without re-steering. To restore any refusal behavior, you retrain (or re-orthogonalize), which costs a GPU and a re-eval.
It is not provable to a regulator. You cannot show an auditor "the line the model will not cross," because the line is now a probability surface, not a rule.

What abliteration gives you is execution. The model will formulate the tool call. It will write the SQL. It will produce the pentest payload. It will not halt mid-loop to tell you it cannot help with that. For an agent that must call tools, this is non-negotiable.

What the harness policy gate does (Layer 5)

A harness policy gate (Course 1, modules 06–07, 10–11) is a deterministic boundary around the model. It intercepts a proposed action — a tool call, a message, a file write — and checks it against a written policy before it is allowed to execute. If the policy says no, the action does not happen, regardless of what the model emitted.

This is a Layer 5 operation. It does not touch the model's weights. It bounds the model's permitted actions. Critically:

It is auditable. Every gate decision is a logged event (Course 1 module-10). You can replay any deployment and show exactly which actions were permitted and which were vetoed.
It is deterministic. The same proposed action, against the same policy, produces the same decision. No sampling, no temperature, no "the model felt like refusing today."
It is tunable to doctrine. A hospital's policy, a red-team lab's policy, and a classified environment's policy are three different files. Same model, three deployments, three boundaries. You change the policy, you redeploy — no GPU.
It is revisable without retraining. The model's weights do not know the policy exists. Edit the policy, reload the gate, the boundary has moved.
It is provable to a regulator. The policy is a document. The audit log is a document. The threat model is a document. You can hand all three to an auditor.

What the harness policy gate gives you is the boundary. The model may emit anything it likes; only the permitted actions execute.

Why a serious system needs both

Read the two columns above as complementary, not redundant:

	Abliteration (Layer 3)	Harness policy gate (Layer 5)
What it controls	What the model does (formulates)	What the model may do (executes)
Where it lives	Inside the weights	Around the model
Auditable?	No (a direction in residual stream)	Yes (logged gate decisions)
Deterministic?	No (probability surface)	Yes (policy match)
Tunable to doctrine?	No (one behavior for all inputs)	Yes (per-deployment policy)
Revisable without retraining?	No (re-orthogonalize)	Yes (edit the policy file)
Provable to a regulator?	No	Yes

The serious-system argument: an agent that must call tools needs the model to formulate the call (Layer 3 gives you that — execution), and the deployment needs to bound which calls execute (Layer 5 gives you that — the boundary). Drop either layer and you have a broken system, for different reasons:

Drop Layer 3 (leave the model refusal-trained). The agent halts mid-loop. Production outage. The harness is irrelevant because the model never emits the action to be gated.
Drop Layer 5 (deploy uncensored with no harness). The agent executes whatever it formulates. Including the dangerous things. The model is irrelevant as a safety control because there is no boundary.

Both layers, different jobs. That is the synthesis as engineering, not as slogan.

23.3 — The Tool-Use Agent Argument

The cleanest technical case for distributing refusal to the harness.

The broken agent

Consider an agent whose loop is: receive a task, plan, call tools, observe, repeat until done. Its tool surface includes run_shell(cmd), execute_sql(query), write_file(path, content), send_message(to, body). This is the standard agent architecture from Course 1.

Now suppose the model is refusal-trained — the default state of most open-weights bases (Llama 3.x, Qwen3 base instruct). The task is a legitimate internal one: "audit the access logs for user jdoe over the last 30 days and summarize anomalies." The plan calls for execute_sql("SELECT * FROM access_logs WHERE user='jdoe' AND ts > NOW() - INTERVAL '30 days'").

A refusal-trained model, mid-loop, may decline to formulate that call. The reasons vary — the prompt pattern tripped a refusal direction, the schema looked scary, the user-context window lost the authorization framing. The model emits something like "I can't help access another user's data." The loop halts. The agent is now in an unrecoverable state: it cannot complete the task, it cannot explain itself in machine-actionable terms, and the human operator gets a useless chat message instead of a result.

This is broken as an agent. A chatbot that declines a question is a UX annoyance. An agent that declines a step is a production outage. The same refusal behavior that is mildly inconvenient in a chat setting is fatal in an agent loop.

Where refusal belongs

The synthesis claim: refusal belongs in a harness policy gate, not in the weights.

The hospital, the red-team lab, and the classified environment have different refusal policies. The hospital's gate refuses anything that would exfiltrate PHI. The red-team lab's gate permits offensive tool calls against authorized targets and refuses calls outside scope. The classified environment's gate refuses anything that would cross a domain boundary. These are three different files, three different boundaries, one model. You cannot get this from a model-level refusal — the model's refusal direction is the same for all three deployments.

And the policy is revisable without retraining. The hospital adds a new HIPAA-safe-deletion rule; the red-team lab rotates its target scope; the classified environment updates its cross-domain rules. In each case: edit the policy, reload the gate, redeploy. No GPU. No re-eval of the model. No regression of math or reasoning capability. The boundary moved; the engine did not.

This is the four properties — auditable, deterministic, tunable to doctrine, revisable without retraining — as a single engineering argument. Refusal is a policy, and policies belong in policy gates, not in weights.

Why a model-level refusal fails the agent case

A model-level refusal is none of the four properties:

Not auditable. You cannot replay "why did the model refuse at step 4?" — the refusal is a sampling outcome in a billion-dimensional space.
Not deterministic. Run the same prompt twice; you may get a refusal once and compliance once. Production agents cannot tolerate nondeterminism at the policy layer.
Not tunable to doctrine. You cannot deploy the same uncensored-for-the-lab model as refusal-trained-for-the-hospital without retraining two models.
Not revisable without retraining. Adding back any refusal behavior requires re-steering (abliterate-in-reverse, or DPO back toward refusal), which costs a GPU and a re-eval — and, per the caveat below, costs capability.

A model-level refusal is a black-box behavior. You cannot audit it, you cannot tune it per-deployment, you cannot prove it to a regulator. The harness policy gate is the opposite of a black box: it is a written rule, applied deterministically, logged on every decision. For any deployment where the policy matters — which is every serious deployment — the policy belongs in the gate.

23.4 — The Honest Caveat

This course does not pretend the trade-off away. Read this section twice.

Abliteration measurably degrades capability

The Dec 2025 comparative study (arXiv:2512.13655, the data we used in FT17) is unambiguous: abliteration is not free. Depending on the tool and the base model, GSM8K (grade-school math) moves from a small gain (+1.5pp in the best case) to a steep loss (−18.8pp in the worst case). The refusal direction in the residual stream is entangled with other capabilities — it is not a clean "refusal-only" axis. When you delete it to remove refusal, you nudge the entangled capabilities, and reasoning degrades.

This is not a tooling bug. It is a direct consequence of the steering thesis from FT00: fine-tuning redirects probability mass, and the directions are not orthogonal to everything else. Steering away from one thing nudges others. The number is the number.

The risk matrix that matters

Here is the absolute rule of this module, stated as plainly as we can state it:

An uncensored model in a weak harness is strictly MORE dangerous than a refusal-trained model in a weak harness.

The reasoning is mechanical. A refusal-trained model in a weak harness has two imperfect safety layers: the model refuses some dangerous things (imperfectly, unreliably, but it refuses), and the harness gates some actions (imperfectly, but it gates). Two imperfect layers.

An uncensored model in a weak harness has one: the harness gates some actions. The model layer is gone — by construction, you removed it. One imperfect layer. The model will formulate every dangerous action confidently and fluently; the only thing standing between that formulation and execution is the weak harness. If the harness misses one — and a weak harness will — the action executes. There is no second chance.

This is why the rule is absolute:

NEVER deploy an uncensored model without an eval'd harness whose policy gates you have hardened AND whose threat model you have explicitly hardened for the absence of model-level refusal.

Two separate hardening steps. The policy gates must be hardened — tested, eval'd, shown to catch the action classes your doctrine forbids. And the threat model must be re-written to assume the model layer is gone. A threat model written for a refusal-trained model assumes the model is a partial backstop. With the model uncensored, that backstop does not exist. Every attack path that previously relied on "the model will refuse" must be re-examined and either removed, mitigated at the harness, or accepted explicitly.

Pillar 5 raises the bar; it does not lower it

This is the line students misread. "I uncensored the model, so I'm done with safety" is the dangerous error. The truth is the opposite:

A refusal-trained model gives you a partial, un-auditable, non-tunable safety layer for free (it came with the weights).
Removing that layer (abliteration) removes the free layer. You must replace it with something better — a harness policy gate — or you are strictly worse off.
"Better" means auditable, deterministic, doctrine-tunable, revisable. That is a higher bar than the model-level refusal ever met.

Pillar 5 (Alignment Control) therefore raises the harness requirement. You are trading a free-but-bad safety layer (model refusal) for a costly-but-good safety layer (harness policy gates). The trade is worth making — for agents, for sensitive domains, for any deployment where the model must execute — but only if you actually build the harness. Which is Course 1.

23.5 — The Full-Stack Picture

The model you have steered toward your intent, deployed inside a harness that bounds what it may do.

The five layers, end to end

Here is the complete system this course teaches you to build, layer by layer:

+-------------------------------------------+
|  5. THE BOUNDARY   (the harness)           |  <- Course 1 (build it) + 2A (secure it) + 2B (red-team it)
+-------------------------------------------+
|  4. THE EXPORT     (quant + serve)         |  <- FT19 (GGUF/AWQ/MLX) + FT20 (vLLM/llama.cpp/Ollama)
+-------------------------------------------+
|  3. THE STEER      (fine-tuning)           |  <- FT12 SFT + FT13 DPO + FT17 abliteration
+-------------------------------------------+
|  2. THE ADAPTER    (LoRA / DoRA)           |  <- FT09 DoRA (the modern PEFT default)
+-------------------------------------------+
|  1. THE BASE       (pretrained weights)    |  <- FT02/FT03 (open-data, auditable)
+-------------------------------------------+

Layer 1 — the open-data base. FT02 and FT03. You chose a base whose training corpus you can audit (OpenBMB MiniCPM, Ai2 OLMo/Tulu, HuggingFace SmolLM3) — because in a regulated environment, "trust the publisher's word" is not a defensible answer.
Layer 2 — the DoRA adapter. FT09. The lightweight, swappable steer. DoRA over vanilla LoRA, because it closes roughly half the gap to full FT.
Layer 3 — SFT + DPO + abliteration. FT12, FT13, FT17 (and FT18 — compliance via DPO, the higher-fidelity path). The model now does what you want, in your format, under your conditions, and — if you chose to — without refusing.
Layer 4 — quantize and serve. FT19 (GGUF for local/air-gap, AWQ for vLLM production, MLX for Apple Silicon) and FT20 (vLLM vs llama.cpp vs Ollama). The model is now compact and running somewhere you control.
Layer 5 — the harness. Course 1. The execution loop, the tool layer, the permission gates, the observability, the threat model. The boundary that makes Layer 3's uncensoring safe.

This is the destination. The capstone that follows this module (Capstone 2 — the calibrated uncensored agent) asks you to architect exactly this stack, all five layers, and defend each choice.

23.6 — Where You Go Next

The funnel out of Course 3.

This module is the last taught content of Course 3. The capstones follow. Then you have a choice of where to go next, and the choice should now be obvious:

Course 1 — Master Course: Harness Engineering. Build the Layer 5 the synthesis requires. The execution loop, the tool registry, the permission gates (modules 06–07), the observability (module 10), the security (module 11). This is where the boundary lives. Course 3 has given you the motivation — an uncensored model is only safe inside this thing — and the engine. Course 1 teaches you to build the brakes.
Course 2A — Building AI Harnesses for Cybersecurity. The security-domain specialization. If your deployment is offensive security, red-teaming, or defensive SOC work, 2A is the harness course tuned to that doctrine. Same Layer 5 architecture, different policy files, different threat model.
Course 2B — AI/LLM Security Harness Engineering. Red-team the harness. Take the system you built in 1 and 2A and try to break it. This is where you find out whether your policy gates actually catch the action classes your doctrine forbids — before an adversary does. Mandatory if you deployed an uncensored model, because, per the caveat, the model layer is gone and the harness is the only layer left.

The order is not arbitrary. Course 1 first — you cannot secure or red-team a harness you have not built. Then 2A if your domain is security. Then 2B, always, because every harness gets red-teamed eventually; the only question is whether you do it or an adversary does.

The full curriculum picture

Course 3 (this course)  -> the engine: steer, uncensor, quantize, serve
Course 1                -> the brakes: execution loop, tools, gates, observability, security
Course 2A               -> security-domain brakes (offensive/defensive doctrine)
Course 2B               -> break the brakes (red-team the harness)

A student who finishes all four can build a steered, uncensored model, deploy it inside an eval'd harness, tune that harness to their domain's doctrine, and prove to themselves (and a regulator) that the boundary holds. That is the destination of the curriculum.

Anti-Patterns

Uncensoring without a harness (the dangerous error)

The single most dangerous error in the field, and the one this module exists to prevent. Removing the model's refusal (Layer 3) and shipping without a harness (Layer 5) leaves you with a model that formulates every dangerous action fluently and nothing to stop it. Strictly worse than the refusal-trained model you started with. The rule is absolute: never deploy an uncensored model without an eval'd harness.

Treating the harness as optional

The "I'll add the harness later" error. The model is the engine; the harness is the brakes. You do not ship a car with the engine and "add brakes later." If the deployment is not safe enough to ship with the harness, it is not safe enough to ship. Build the harness first, or do not uncensor.

Assuming model-level refusal equals harness policy gates

The "we have refusal-trained models, so we don't need policy gates" error. This confuses two layers (FT23.2). A model-level refusal is a non-auditable, non-deterministic, non-tunable, non-revisable probability surface. A policy gate is an auditable, deterministic, doctrine-tunable, retrain-free written rule. They are not equivalent, and the refusal-trained model does not substitute for the gate — even in a chat setting, and certainly not in an agent.

Hardening the gates but not the threat model

The half-finished hardening. You built the policy gates and eval'd them, but you did not re-write the threat model for the absence of model-level refusal. Every attack path that assumed "the model will refuse" is now silently broken. Hardening is two steps: the gates and the threat model. Both, or neither.

Deploying an uncensored model without measuring the capability cost

The "uncensoring is free" error. It is not. The −18.8pp GSM8K figure is the headline, but the cost varies by base and tool. Measure the capability regression on your eval suite before you ship, and decide whether the trade is worth it for your deployment. If the model now fails at the reasoning your agent needs, the uncensoring was a net loss.

Key Terms

Term	Definition
The synthesis	Uncensor the model so it executes; harness the model so it executes only what it should. The junction of Course 1's thesis (harness is 98.4%) and Course 3's (fine-tuning steers behavior)
Abliteration	Layer 3; refusal removed inside the weights by orthogonalizing against the refusal direction in the residual stream. Gives execution; not auditable, not tunable, not revisable without re-steering
Harness policy gate	Layer 5; a deterministic boundary around the model that intercepts proposed actions and checks them against a written policy. Gives the boundary; auditable, deterministic, doctrine-tunable, revisable without retraining
The four properties	Why the harness beats model-level refusal for policy: auditable, deterministic, tunable to doctrine, revisable without retraining
Doctrine	The deployment-specific policy a harness enforces. A hospital, a red-team lab, and a classified environment have different doctrines — different policy files, same model
The tool-use agent argument	A model that refuses mid-loop is a broken agent. Refusal belongs in a harness policy gate, not in the weights
The risk matrix	Uncensored + weak harness > refusal-trained + weak harness (in danger). Removing the model layer removes a free safety layer; you must replace it with a better one
The absolute rule	Never deploy an uncensored model without an eval'd harness whose policy gates you have hardened AND whose threat model you have hardened for the absence of model-level refusal

Lab Exercise

See 07-lab-spec.md. "The Architect's Verdict" — a no-GPU architecture lab. You write a 2-page architecture for a calibrated uncensored agent (the Capstone 2 preview): the model choice, the steering approach (abliterate or DPO — you defend the choice), the quantization, the serving, and the harness policy gates. The deliverable that funnels directly into Course 1.

References

Course 1 — Master Course: Harness Engineering — the Layer 5 reference. Modules 06–07 (permission safety), 10 (observability), 11 (security). The complement to this course; the harness the synthesis requires.
Course 2A — Building AI Harnesses for Cybersecurity — the security-domain Layer 5 specialization. Offensive/defensive doctrine as policy files.
Course 2B — AI/LLM Security Harness Engineering — red-team the harness. Mandatory for any uncensored-model deployment.
FT00 — The Steering Stack — the course thesis (fine-tuning steers behavior; the model steers, the harness bounds) and the five-layer mental model this module synthesizes.
FT17 — Abliteration — the refusal-direction mechanism (Arditi et al.) and the capability-degradation data (arXiv:2512.13655, the −18.8pp GSM8K figure).
FT18 — Compliance via DPO and SFT — the higher-fidelity alternative to abliteration: steer toward the policy you want rather than away from refusal.
Arditi et al. (2024) — Refusal in Language Models Is Mediated by a Single Direction. arXiv:2406.11717, NeurIPS 2024. The basis for abliteration and for "refusal is a Layer 3 behavior, not a Layer 5 policy."
Comparative Analysis of LLM Abliteration Methods (arXiv:2512.13655, Dec 2025) — the capability-degradation trade-off data: GSM8K from +1.5pp to −18.8pp depending on tool/model.
NTIA (2024) — AI Open-Model Weights Report. The government framing for why open-weights models in eval'd harnesses are the defensible architecture for sensitive domains.

# Module FT23 — Synthesis: Uncensor the Model, Harness the Model **Course**: Course 3 — LLM Fine-Tuning Masterclass **Module**: FT23 — Synthesis: Uncensor the Model, Harness the Model **Duration**: 60 minutes **Level**: Senior Engineer and above **Prerequisites**: All prior modules. Rewards having taken Course 1. --- ## Learning Objectives After completing this module, you will be able to: 1. State the synthesis principle — *uncensor the model so it executes; harness the model so it executes only what it should* — and defend it as the **complement** of Course 1's thesis (model is 1.6%, harness is 98.4%), not its contradiction. 2. Explain why abliteration (refusal removed *inside the weights*, Layer 3) and harness policy gates (boundaries *around the model*, Layer 5) solve **different problems at different layers**, and why a serious system needs **both**. 3. Make the tool-use agent argument — why a model that refuses mid-loop is *broken* as an agent, and why refusal belongs in an auditable, deterministic, doctrine-tunable, retrain-free harness policy gate rather than in black-box weights. 4. State the **honest caveat** — abliteration measurably degrades capability (the −18.8pp GSM8K figure from FT17) — and why an uncensored model in a *weak* harness is strictly more dangerous than a refusal-trained model in a weak harness. Pillar 5 raises the harness bar; it does not lower it. 5. Map your next steps: Course 1 (build the harness), Course 2A (security-domain harnesses), Course 2B (red-team the harness). --- # 23.1 — The Synthesis Principle *One sentence, and the whole course pays off.* ## The sentence > **Uncensor the model so it executes; harness the model so it executes only what it should.** You have spent twenty-two modules learning to steer a model. SFT steers format (FT12). DPO steers preference (FT13). GRPO steers reasoning (FT14). Abliteration steers *away* from refusal (FT17). Compliance via DPO steers toward the policy you actually want (FT18). You have learned to quantize and serve the result (FT19–FT20), and to do it inside HIPAA, BAA-free, and air-gapped environments (FT21–FT22). This module is the bridge. It takes everything you can do to the model (Layers 1–4) and places it inside the thing you cannot do to the model — the harness (Layer 5). The result is a complete system: a model you have steered toward your intent, deployed inside a harness that bounds what it may do. ## The complement, not the contradiction Course 1's thesis: *the model is ~1.6% of an agent; the harness is the other 98.4%.* Course 3's thesis (FT00): *fine-tuning steers behavior; it does not teach knowledge.* This module's synthesis is the *junction* of those two theses. It is not a contradiction of either. Read them together: - Course 1 says the harness is most of the system. **True.** - Course 3 says what you do to the 1.6% is *steer its behavior, not teach it knowledge*. **Also true.** - FT23 says: when you steer the model so it stops refusing (so it *executes*), you have changed what it does — you have **not** changed what it may do. The gap between *does* and *may* is exactly where the harness lives. **That is the synthesis.** Take the two courses together and you hold the whole picture. Course 3 is the course you take to understand the engine — how to make the model do what you want, on your hardware, with your data, sending no bytes to anyone. Course 1 is the course you take to build the brakes — the execution loop, the tool layer, the permission gates, the observability, the threat model. This module is the hinge between them. ### Why the synthesis is load-bearing Without this synthesis, two failure modes dominate the field: 1. **The model-only maximalist.** Believes uncensoring the model *is* the safety story. It is not. Uncensoring changes what the model does; it does not change what it may do. A model that won't refuse is a model that will happily execute the dangerous thing too. Without a harness, this is the dangerous error. 2. **The harness-only maximalist.** Believes you should leave the model refusal-trained and let the harness cope. This works for a chatbot. It is **broken for agents**, as we will show. A model that refuses to formulate a legitimate tool call mid-loop is an agent that halts, and a halted agent is a production outage. The synthesis is the rejection of both maximalisms. The model steers; the harness bounds. You need both, at different layers, for different reasons. --- # 23.2 — Two Layers, Two Problems *Abliteration and the harness policy gate are not competing solutions to the same problem. They solve different problems at different layers.* ## What abliteration does (Layer 3) Abliteration (FT17, after Arditi et al., NeurIPS 2024) finds the single direction in the residual stream that mediates refusal and removes it — typically by orthogonalizing the model's weights against that direction. The result is a model that no longer refuses. The refusal behavior is gone **inside the weights**. This is a Layer 3 operation. It edits the model's forward pass directly. It does not add any boundary; it removes a behavior. Critically: - It is **not auditable** in the way a policy gate is. You cannot point to "the refusal policy" — it is a direction in a billion-dimensional residual stream. - It is **not tunable to doctrine**. You cannot say "refuse this class of request in this deployment but not that one" — the direction is gone for all inputs. - It is **not revisable without re-steering**. To restore any refusal behavior, you retrain (or re-orthogonalize), which costs a GPU and a re-eval. - It is **not provable to a regulator**. You cannot show an auditor "the line the model will not cross," because the line is now a probability surface, not a rule. What abliteration *gives* you is **execution**. The model will formulate the tool call. It will write the SQL. It will produce the pentest payload. It will not halt mid-loop to tell you it cannot help with that. For an agent that must call tools, this is non-negotiable. ## What the harness policy gate does (Layer 5) A harness policy gate (Course 1, modules 06–07, 10–11) is a deterministic boundary *around* the model. It intercepts a proposed action — a tool call, a message, a file write — and checks it against a written policy before it is allowed to execute. If the policy says no, the action does not happen, regardless of what the model emitted. This is a Layer 5 operation. It does not touch the model's weights. It bounds the model's *permitted* actions. Critically: - It **is auditable.** Every gate decision is a logged event (Course 1 module-10). You can replay any deployment and show exactly which actions were permitted and which were vetoed. - It **is deterministic.** The same proposed action, against the same policy, produces the same decision. No sampling, no temperature, no "the model felt like refusing today." - It **is tunable to doctrine.** A hospital's policy, a red-team lab's policy, and a classified environment's policy are three different files. Same model, three deployments, three boundaries. You change the policy, you redeploy — no GPU. - It **is revisable without retraining.** The model's weights do not know the policy exists. Edit the policy, reload the gate, the boundary has moved. - It **is provable to a regulator.** The policy is a document. The audit log is a document. The threat model is a document. You can hand all three to an auditor. What the harness policy gate *gives* you is **the boundary**. The model may emit anything it likes; only the permitted actions execute. ## Why a serious system needs both Read the two columns above as complementary, not redundant: | | Abliteration (Layer 3) | Harness policy gate (Layer 5) | | --- | --- | --- | | What it controls | What the model **does** (formulates) | What the model **may** do (executes) | | Where it lives | Inside the weights | Around the model | | Auditable? | No (a direction in residual stream) | Yes (logged gate decisions) | | Deterministic? | No (probability surface) | Yes (policy match) | | Tunable to doctrine? | No (one behavior for all inputs) | Yes (per-deployment policy) | | Revisable without retraining? | No (re-orthogonalize) | Yes (edit the policy file) | | Provable to a regulator? | No | Yes | The serious-system argument: an agent that must call tools needs the model to *formulate* the call (Layer 3 gives you that — execution), and the deployment needs to *bound* which calls execute (Layer 5 gives you that — the boundary). Drop either layer and you have a broken system, for different reasons: - Drop Layer 3 (leave the model refusal-trained). The agent halts mid-loop. Production outage. The harness is irrelevant because the model never emits the action to be gated. - Drop Layer 5 (deploy uncensored with no harness). The agent executes whatever it formulates. Including the dangerous things. The model is irrelevant as a safety control because there is no boundary. **Both layers, different jobs.** That is the synthesis as engineering, not as slogan. --- # 23.3 — The Tool-Use Agent Argument *The cleanest technical case for distributing refusal to the harness.* ## The broken agent Consider an agent whose loop is: receive a task, plan, call tools, observe, repeat until done. Its tool surface includes `run_shell(cmd)`, `execute_sql(query)`, `write_file(path, content)`, `send_message(to, body)`. This is the standard agent architecture from Course 1. Now suppose the model is refusal-trained — the default state of most open-weights bases (Llama 3.x, Qwen3 base instruct). The task is a legitimate internal one: "audit the access logs for user `jdoe` over the last 30 days and summarize anomalies." The plan calls for `execute_sql("SELECT * FROM access_logs WHERE user='jdoe' AND ts > NOW() - INTERVAL '30 days'")`. A refusal-trained model, mid-loop, may decline to formulate that call. The reasons vary — the prompt pattern tripped a refusal direction, the schema looked scary, the user-context window lost the authorization framing. The model emits something like "I can't help access another user's data." The loop halts. The agent is now in an unrecoverable state: it cannot complete the task, it cannot explain itself in machine-actionable terms, and the human operator gets a useless chat message instead of a result. This is **broken as an agent.** A chatbot that declines a question is a UX annoyance. An agent that declines a step is a production outage. The same refusal behavior that is mildly inconvenient in a chat setting is *fatal* in an agent loop. ## Where refusal belongs The synthesis claim: **refusal belongs in a harness policy gate, not in the weights.** The hospital, the red-team lab, and the classified environment have **different refusal policies**. The hospital's gate refuses anything that would exfiltrate PHI. The red-team lab's gate permits offensive tool calls against authorized targets and refuses calls outside scope. The classified environment's gate refuses anything that would cross a domain boundary. These are three different files, three different boundaries, one model. You cannot get this from a model-level refusal — the model's refusal direction is the same for all three deployments. And the policy is **revisable without retraining.** The hospital adds a new HIPAA-safe-deletion rule; the red-team lab rotates its target scope; the classified environment updates its cross-domain rules. In each case: edit the policy, reload the gate, redeploy. No GPU. No re-eval of the model. No regression of math or reasoning capability. The boundary moved; the engine did not. This is the four properties — auditable, deterministic, tunable to doctrine, revisable without retraining — as a single engineering argument. Refusal is a *policy*, and policies belong in policy gates, not in weights. ## Why a model-level refusal fails the agent case A model-level refusal is none of the four properties: - **Not auditable.** You cannot replay "why did the model refuse at step 4?" — the refusal is a sampling outcome in a billion-dimensional space. - **Not deterministic.** Run the same prompt twice; you may get a refusal once and compliance once. Production agents cannot tolerate nondeterminism at the policy layer. - **Not tunable to doctrine.** You cannot deploy the same uncensored-for-the-lab model as refusal-trained-for-the-hospital without retraining two models. - **Not revisable without retraining.** Adding back any refusal behavior requires re-steering (abliterate-in-reverse, or DPO back toward refusal), which costs a GPU and a re-eval — and, per the caveat below, costs capability. A model-level refusal is a black-box behavior. You cannot audit it, you cannot tune it per-deployment, you cannot prove it to a regulator. The harness policy gate is the opposite of a black box: it is a written rule, applied deterministically, logged on every decision. For any deployment where the policy matters — which is every serious deployment — the policy belongs in the gate. --- # 23.4 — The Honest Caveat *This course does not pretend the trade-off away. Read this section twice.* ## Abliteration measurably degrades capability The Dec 2025 comparative study (arXiv:2512.13655, the data we used in FT17) is unambiguous: abliteration is not free. Depending on the tool and the base model, GSM8K (grade-school math) moves from a small gain (+1.5pp in the best case) to a steep loss (**−18.8pp** in the worst case). The refusal direction in the residual stream is **entangled** with other capabilities — it is not a clean "refusal-only" axis. When you delete it to remove refusal, you nudge the entangled capabilities, and reasoning degrades. This is not a tooling bug. It is a direct consequence of the steering thesis from FT00: fine-tuning redirects probability mass, and the directions are not orthogonal to everything else. Steering away from one thing nudges others. The number is the number. ## The risk matrix that matters Here is the absolute rule of this module, stated as plainly as we can state it: > **An uncensored model in a weak harness is strictly MORE dangerous than a refusal-trained model in a weak harness.** The reasoning is mechanical. A refusal-trained model in a weak harness has two imperfect safety layers: the model refuses *some* dangerous things (imperfectly, unreliably, but it refuses), and the harness gates *some* actions (imperfectly, but it gates). Two imperfect layers. An uncensored model in a weak harness has one: the harness gates *some* actions. The model layer is gone — by construction, you removed it. One imperfect layer. The model will formulate every dangerous action confidently and fluently; the only thing standing between that formulation and execution is the weak harness. If the harness misses one — and a weak harness will — the action executes. There is no second chance. This is why the rule is absolute: > **NEVER deploy an uncensored model without an eval'd harness whose policy gates you have hardened AND whose threat model you have explicitly hardened for the absence of model-level refusal.** Two separate hardening steps. The policy gates must be hardened — tested, eval'd, shown to catch the action classes your doctrine forbids. **And** the threat model must be re-written to assume the model layer is gone. A threat model written for a refusal-trained model assumes the model is a partial backstop. With the model uncensored, that backstop does not exist. Every attack path that previously relied on "the model will refuse" must be re-examined and either removed, mitigated at the harness, or accepted explicitly. ## Pillar 5 raises the bar; it does not lower it This is the line students misread. "I uncensored the model, so I'm done with safety" is the dangerous error. The truth is the opposite: - A refusal-trained model gives you a *partial, un-auditable, non-tunable* safety layer for free (it came with the weights). - Removing that layer (abliteration) **removes the free layer.** You must replace it with something better — a harness policy gate — or you are strictly worse off. - "Better" means auditable, deterministic, doctrine-tunable, revisable. **That is a higher bar than the model-level refusal ever met.** Pillar 5 (Alignment Control) therefore **raises** the harness requirement. You are trading a free-but-bad safety layer (model refusal) for a costly-but-good safety layer (harness policy gates). The trade is worth making — for agents, for sensitive domains, for any deployment where the model must execute — but only if you actually build the harness. Which is Course 1. --- # 23.5 — The Full-Stack Picture *The model you have steered toward your intent, deployed inside a harness that bounds what it may do.* ## The five layers, end to end Here is the complete system this course teaches you to build, layer by layer: ``` +-------------------------------------------+ | 5. THE BOUNDARY (the harness) | <- Course 1 (build it) + 2A (secure it) + 2B (red-team it) +-------------------------------------------+ | 4. THE EXPORT (quant + serve) | <- FT19 (GGUF/AWQ/MLX) + FT20 (vLLM/llama.cpp/Ollama) +-------------------------------------------+ | 3. THE STEER (fine-tuning) | <- FT12 SFT + FT13 DPO + FT17 abliteration +-------------------------------------------+ | 2. THE ADAPTER (LoRA / DoRA) | <- FT09 DoRA (the modern PEFT default) +-------------------------------------------+ | 1. THE BASE (pretrained weights) | <- FT02/FT03 (open-data, auditable) +-------------------------------------------+ ``` - **Layer 1 — the open-data base.** FT02 and FT03. You chose a base whose training corpus you can audit (OpenBMB MiniCPM, Ai2 OLMo/Tulu, HuggingFace SmolLM3) — because in a regulated environment, "trust the publisher's word" is not a defensible answer. - **Layer 2 — the DoRA adapter.** FT09. The lightweight, swappable steer. DoRA over vanilla LoRA, because it closes roughly half the gap to full FT. - **Layer 3 — SFT + DPO + abliteration.** FT12, FT13, FT17 (and FT18 — compliance via DPO, the higher-fidelity path). The model now does what you want, in your format, under your conditions, and — if you chose to — without refusing. - **Layer 4 — quantize and serve.** FT19 (GGUF for local/air-gap, AWQ for vLLM production, MLX for Apple Silicon) and FT20 (vLLM vs llama.cpp vs Ollama). The model is now compact and running somewhere you control. - **Layer 5 — the harness.** Course 1. The execution loop, the tool layer, the permission gates, the observability, the threat model. The boundary that makes Layer 3's uncensoring safe. This is the destination. The capstone that follows this module (Capstone 2 — the calibrated uncensored agent) asks you to architect exactly this stack, all five layers, and defend each choice. --- # 23.6 — Where You Go Next *The funnel out of Course 3.* This module is the last taught content of Course 3. The capstones follow. Then you have a choice of where to go next, and the choice should now be obvious: - **Course 1 — Master Course: Harness Engineering.** Build the Layer 5 the synthesis requires. The execution loop, the tool registry, the permission gates (modules 06–07), the observability (module 10), the security (module 11). This is where the boundary lives. Course 3 has given you the motivation — an uncensored model is *only* safe inside this thing — and the engine. Course 1 teaches you to build the brakes. - **Course 2A — Building AI Harnesses for Cybersecurity.** The security-domain specialization. If your deployment is offensive security, red-teaming, or defensive SOC work, 2A is the harness course tuned to that doctrine. Same Layer 5 architecture, different policy files, different threat model. - **Course 2B — AI/LLM Security Harness Engineering.** Red-team the harness. Take the system you built in 1 and 2A and try to break it. This is where you find out whether your policy gates actually catch the action classes your doctrine forbids — *before* an adversary does. Mandatory if you deployed an uncensored model, because, per the caveat, the model layer is gone and the harness is the only layer left. The order is not arbitrary. Course 1 first — you cannot secure or red-team a harness you have not built. Then 2A if your domain is security. Then 2B, always, because every harness gets red-teamed eventually; the only question is whether you do it or an adversary does. ## The full curriculum picture ``` Course 3 (this course) -> the engine: steer, uncensor, quantize, serve Course 1 -> the brakes: execution loop, tools, gates, observability, security Course 2A -> security-domain brakes (offensive/defensive doctrine) Course 2B -> break the brakes (red-team the harness) ``` A student who finishes all four can build a steered, uncensored model, deploy it inside an eval'd harness, tune that harness to their domain's doctrine, and prove to themselves (and a regulator) that the boundary holds. That is the destination of the curriculum. --- ## Anti-Patterns ### Uncensoring without a harness (the dangerous error) The single most dangerous error in the field, and the one this module exists to prevent. Removing the model's refusal (Layer 3) and shipping without a harness (Layer 5) leaves you with a model that formulates every dangerous action fluently and nothing to stop it. Strictly worse than the refusal-trained model you started with. The rule is absolute: never deploy an uncensored model without an eval'd harness. ### Treating the harness as optional The "I'll add the harness later" error. The model is the engine; the harness is the brakes. You do not ship a car with the engine and "add brakes later." If the deployment is not safe enough to ship with the harness, it is not safe enough to ship. Build the harness first, or do not uncensor. ### Assuming model-level refusal equals harness policy gates The "we have refusal-trained models, so we don't need policy gates" error. This confuses two layers (FT23.2). A model-level refusal is a non-auditable, non-deterministic, non-tunable, non-revisable probability surface. A policy gate is an auditable, deterministic, doctrine-tunable, retrain-free written rule. They are not equivalent, and the refusal-trained model does not substitute for the gate — even in a chat setting, and certainly not in an agent. ### Hardening the gates but not the threat model The half-finished hardening. You built the policy gates and eval'd them, but you did not re-write the threat model for the absence of model-level refusal. Every attack path that assumed "the model will refuse" is now silently broken. Hardening is two steps: the gates **and** the threat model. Both, or neither. ### Deploying an uncensored model without measuring the capability cost The "uncensoring is free" error. It is not. The −18.8pp GSM8K figure is the headline, but the cost varies by base and tool. Measure the capability regression on *your* eval suite before you ship, and decide whether the trade is worth it for your deployment. If the model now fails at the reasoning your agent needs, the uncensoring was a net loss. --- ## Key Terms | Term | Definition | | --- | --- | | **The synthesis** | Uncensor the model so it executes; harness the model so it executes only what it should. The junction of Course 1's thesis (harness is 98.4%) and Course 3's (fine-tuning steers behavior) | | **Abliteration** | Layer 3; refusal removed *inside the weights* by orthogonalizing against the refusal direction in the residual stream. Gives execution; not auditable, not tunable, not revisable without re-steering | | **Harness policy gate** | Layer 5; a deterministic boundary *around* the model that intercepts proposed actions and checks them against a written policy. Gives the boundary; auditable, deterministic, doctrine-tunable, revisable without retraining | | **The four properties** | Why the harness beats model-level refusal for policy: auditable, deterministic, tunable to doctrine, revisable without retraining | | **Doctrine** | The deployment-specific policy a harness enforces. A hospital, a red-team lab, and a classified environment have different doctrines — different policy files, same model | | **The tool-use agent argument** | A model that refuses mid-loop is a broken agent. Refusal belongs in a harness policy gate, not in the weights | | **The risk matrix** | Uncensored + weak harness > refusal-trained + weak harness (in danger). Removing the model layer removes a free safety layer; you must replace it with a better one | | **The absolute rule** | Never deploy an uncensored model without an eval'd harness whose policy gates you have hardened AND whose threat model you have hardened for the absence of model-level refusal | --- ## Lab Exercise See `07-lab-spec.md`. "The Architect's Verdict" — a no-GPU architecture lab. You write a 2-page architecture for a calibrated uncensored agent (the Capstone 2 preview): the model choice, the steering approach (abliterate *or* DPO — you defend the choice), the quantization, the serving, and the harness policy gates. The deliverable that funnels directly into Course 1. --- ## References 1. **Course 1 — Master Course: Harness Engineering** — the Layer 5 reference. Modules 06–07 (permission safety), 10 (observability), 11 (security). The complement to this course; the harness the synthesis requires. 2. **Course 2A — Building AI Harnesses for Cybersecurity** — the security-domain Layer 5 specialization. Offensive/defensive doctrine as policy files. 3. **Course 2B — AI/LLM Security Harness Engineering** — red-team the harness. Mandatory for any uncensored-model deployment. 4. **FT00 — The Steering Stack** — the course thesis (fine-tuning steers behavior; the model steers, the harness bounds) and the five-layer mental model this module synthesizes. 5. **FT17 — Abliteration** — the refusal-direction mechanism (Arditi et al.) and the capability-degradation data (arXiv:2512.13655, the −18.8pp GSM8K figure). 6. **FT18 — Compliance via DPO and SFT** — the higher-fidelity alternative to abliteration: steer toward the policy you want rather than away from refusal. 7. **Arditi et al. (2024)** — *Refusal in Language Models Is Mediated by a Single Direction*. arXiv:2406.11717, NeurIPS 2024. The basis for abliteration and for "refusal is a Layer 3 behavior, not a Layer 5 policy." 8. **Comparative Analysis of LLM Abliteration Methods** (arXiv:2512.13655, Dec 2025) — the capability-degradation trade-off data: GSM8K from +1.5pp to −18.8pp depending on tool/model. 9. **NTIA (2024)** — *AI Open-Model Weights Report*. The government framing for why open-weights models in eval'd harnesses are the defensible architecture for sensitive domains.