# Teaching Script — 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**: ~40 minutes (spoken at ~140 wpm)
**Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes.

---

[SLIDE 1 — Title]

This is module FT twenty-three — the last taught module of Course three. It is the bridge module. Everything you have learned for twenty-two modules lands here, and everything you will learn in the next three courses starts here. If there is one module in this course that earns its full duration, it is this one.

The title is the synthesis: uncensor the model so it executes; harness the model so it executes only what it should. Let's get to it.

[SLIDE 2 — The synthesis, one sentence]

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

Read it as two operations on one action. The model formulates the action — it writes the SQL, the shell command, the tool call. That is execution. The harness checks the proposed action against a written policy and decides whether it may run. That is the boundary. Drop either operation and the system is broken, for different reasons, which we will get to.

[SLIDE 3 — The complement, not the contradiction]

This synthesis is the complement — not the contradiction — of Course one. Course one said the model is about one-point-six percent of an agent, and the harness is the other ninety-eight-point-four. Course three, in module zero, zoomed into that one-point-six and said: fine-tuning steers behavior; it does not teach knowledge. This module joins them. When you steer the model to stop refusing, you changed what it does — you did not change what it may do. The gap between does and may is exactly where the harness lives. Take both courses together and you hold the whole picture: a model you have steered toward your intent, deployed inside a harness that bounds what it may do.

[SLIDE 4 — The two failure modes]

Without this synthesis, two failure modes dominate the field, and I want you to recognize both.

The first is the model-only maximalist. This person 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 will not refuse is a model that will happily execute the dangerous thing too. Without a harness, this is the dangerous error.

The second is the harness-only maximalist. This person believes you should leave the model refusal-trained and let the harness cope. That works for a chatbot. It is broken for agents. 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.

[SLIDE 5 — Two layers, two problems]

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

Abliteration is Layer three. It finds the single direction in the residual stream that mediates refusal and removes it. The refusal behavior is gone, inside the weights. This is not auditable — you cannot point to the refusal policy, it is a direction in a billion-dimensional space. It is not tunable to doctrine — you cannot have one behavior for the hospital and another for the lab; the direction is gone for all inputs. It is not revisable without retraining — to restore any refusal, you re-steer, which costs a GPU and a re-eval. What abliteration gives you is execution. The model formulates the action. For an agent that must call tools, this is non-negotiable.

The harness policy gate is Layer five. It is a deterministic boundary around the model. It intercepts a proposed action and checks it against a written policy before it executes. This is auditable — every gate decision is a logged event. It is deterministic — the same action against the same policy gives the same decision, no sampling. It is tunable to doctrine — the hospital, the red-team lab, and the classified environment have three different policy files, same model, three deployments. It is revisable without retraining — edit the policy, reload the gate, no GPU. What the gate gives you is the boundary. The model may emit anything; only the permitted actions execute.

[SLIDE 6 — A serious system needs both]

A serious system needs both. Read those two columns as complementary, not redundant. The agent needs the model to formulate the call — Layer three gives you that. The deployment needs to bound which calls execute — Layer five gives you that. Drop Layer three, leave the model refusal-trained: the agent halts mid-loop, the harness is irrelevant because the model never emits the action to be gated. Drop Layer five, deploy uncensored with no harness: the agent executes whatever it formulates, including the dangerous things. Both layers, different jobs. That is the synthesis as engineering, not as slogan.

[SLIDE 7 — The tool-use agent argument]

Now the cleanest technical case for moving refusal to the harness. The tool-use agent argument.

Consider an agent whose loop is receive a task, plan, call tools, observe, repeat. Its tool surface includes run shell, execute SQL, write file, send message. This is the standard agent architecture from Course one. Now suppose the model is refusal-trained — the default state of most open-weights bases. The task is legitimate and internal: audit the access logs for a user and summarize anomalies. The plan calls for an SQL select against the access-logs table. A refusal-trained model, mid-loop, may decline to formulate that call. The loop halts. The agent is in an unrecoverable state — it cannot complete the task, it cannot explain itself in machine-actionable terms, and the 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 chat is fatal in an agent loop.

[SLIDE 8 — Where refusal belongs]

So where does refusal belong? In a harness policy gate, not in the weights. The hospital, the red-team lab, and the classified environment have different refusal policies — three different files, three different boundaries, one model. You cannot get that 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 lab rotates its target scope; the classified environment updates its cross-domain rules. Edit the file, reload the gate, redeploy. No GPU, no re-eval, no capability regression.

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

[SLIDE 9 — The honest caveat]

Now the honest caveat, and I want you to hear this clearly. This course does not pretend the trade-off away. Abliteration measurably degrades capability. The December twenty-twenty-five comparative study — the data we used in module seventeen — is unambiguous. Depending on the tool and the base model, GSM eight-K, grade-school math, moves from a small gain in the best case — plus one-point-five points — to a steep loss in the worst case: minus eighteen-point-eight points. The refusal direction in the residual stream is entangled with other capabilities. It is not a clean refusal-only axis. When you delete it, you nudge the entangled capabilities, and reasoning degrades. The number is the number.

[SLIDE 10 — The risk matrix]

Here is the absolute rule of this module, stated as plainly as I 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 model layer is gone — by construction, you removed it. The model formulates every dangerous action confidently and fluently, and the only thing standing between that formulation and execution is the weak harness. When the weak harness misses one — and it will — the action executes. There is no second chance.

So 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 gates must be eval'd — tested, shown to catch the action classes your doctrine forbids. And the threat model must be re-written to assume the model layer is gone. Every attack path that previously relied on the model will refuse must be re-examined — removed, mitigated at the harness, or accepted explicitly. Both steps, or neither.

[SLIDE 11 — Pillar five raises the bar]

This is the line students misread. I uncensored the model, so I am done with safety. That 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 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 five — alignment control — therefore raises the harness requirement. It does not lower it. You are trading a free-but-bad safety layer for a costly-but-good one. 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 one.

[SLIDE 12 — The full-stack picture]

Here is the complete system this course teaches you to build, layer by layer. Layer one, the open-data base — modules two and three. You chose a base whose training corpus you can audit, because in a regulated environment, trust the publisher is not a defensible answer. Layer two, the adapter — module nine, DoRA, the modern PEFT default. Layer three, the steer — modules twelve, thirteen, seventeen, and eighteen. SFT, DPO, abliteration, and compliance via DPO. The model now does what you want, in your format, under your conditions, and, if you chose to, without refusing. Layer four, the export — modules nineteen and twenty. Quantize and serve, on hardware you control. Layer five, the boundary — Course one. The execution loop, the tool registry, the permission gates, the observability, the threat model.

That is the destination. The capstone that follows this module asks you to architect exactly this stack, all five layers, and defend each choice.

[SLIDE 13 — Where you go next]

This module is the last taught content of Course three. The capstones follow. Then you have a choice, and the choice should now be obvious. Course one — build the harness. The Layer five the synthesis requires. The execution loop, the tools, the gates, the observability, the security. Course three gave you the motivation and the engine; Course one teaches you to build the brakes. Course two-A — security-domain harnesses. If your deployment is offensive or defensive security, two-A is the harness course tuned to that doctrine. Course two-B — red-team the harness. Take the system you built in one and two-A and try to break it. This is mandatory if you deployed an uncensored model, because the model layer is gone and the harness is the only layer left.

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

[SLIDE 14 — Anti-patterns]

Three anti-patterns to leave with.

First, uncensoring without a harness. The single most dangerous error in the field, and the one this module exists to prevent. Never deploy an uncensored model without an eval'd harness.

Second, treating the harness as optional. The I will 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.

Third, assuming model-level refusal equals harness policy gates. This confuses two layers. A refusal-trained model does not substitute for the gate — not in chat, and certainly not in an agent.

And a fourth, the half-finished hardening: you hardened the gates but not the threat model. Every attack path that assumed the model will refuse is now silently broken. Both, or neither.

[SLIDE 15 — What you can now do]

You can now state the synthesis and defend it as the complement of Course one. You can explain why abliteration and the harness policy gate solve different problems at different layers, and why a serious system needs both. You can make the tool-use agent argument — why refusal belongs in a policy gate, not in the weights. You can state the honest caveat and the absolute rule. And you can map your next steps into Courses one, two-A, and two-B.

The lab that follows — the Architect's Verdict — asks you to write the two-page architecture for a calibrated uncensored agent. All five layers, the steering choice defended, the policy gates specified, the threat model re-written. It is the Capstone two preview. Do it well and the capstone is half-done.

That is module FT twenty-three. The synthesis. The bridge. Course three is complete. Go build the harness.

---

*End of module FT23. Duration: approximately thirty-eight minutes at one-hundred-forty words per minute.*