# Teaching Script — Capstone CAP1: The Air-Gapped Domain Model

**Course**: Course 3 — LLM Fine-Tuning Masterclass
**Module**: CAP1 — The Air-Gapped Domain Model
**Duration**: ~120 minutes (the build itself; this script frames it, ~25 min spoken at ~140 wpm)
**Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes.

---

[SLIDE 1 — Title]

Welcome to Capstone one of the LLM Fine-Tuning Masterclass — The Air-Gapped Domain Model. This is the integration capstone for Pillars P zero zero through P zero six. Everything you learned — base selection, data discipline, QLoRA, eval, quantization, serving — you now chain into one pipeline that produces a usable, local, auditable model.

The deliverable is not a notebook. It is a reproducible pipeline, shipped as a GitHub README asset, that someone else can clone and run. A hundred and twenty minutes of build. Let me frame it.

[SLIDE 2 — The deliverable]

Here is what you build. A pipeline: open-data base, HIPAA-safe data prep, QLoRA fine-tune, eval, GGUF export, local serve. Six steps chained, plus a seventh — the reproducibility package that wraps them all.

The domain is yours to choose — medical, legal, or security. But the constraints are fixed. You start from an open-data base — MiniCPM, OLMo, Tulu, or SmolLM3 — because you must be able to audit what the model saw. That is non-negotiable for sensitive domains. You use HIPAA-safe data — open datasets or synthetic — never real PHI. And the whole thing runs end to end on a single consumer GPU or Apple Silicon, with zero telemetry.

If you cannot run it locally, you have not completed the capstone. That is the bar.

[SLIDE 3 — What this proves]

What does this capstone prove that no individual module could? One property: reproducibility under air-gap.

A model you fine-tuned on a cloud GPU and serve through a vendor API is a model someone else controls. The vendor can observe it, throttle it, revoke it. A model you fine-tuned on your hardware and serve through Ollama, from a pipeline you can hand to a clinician, a lawyer, or an analyst — that is a model you own. That is what Pillar seven, sensitive domains, is about. And this capstone is where it stops being theory and becomes a thing you built.

The air-gap is not a feature you add at the end. It is a property of the whole pipeline. Every phase — data prep, training, eval, export, serve — must be local. If any phase touches the network, the claim is false.

[SLIDE 4 — The three success criteria]

A capstone without measurable success criteria is a hackathon project. Three criteria, each falsifiable.

Criterion one: domain lift. Your fine-tuned model must measurably outperform the base on a held-out domain evaluation. A number, with a methodology. The lift is fine-tuned minus base. A positive, non-trivial lift — typically plus three to plus fifteen points depending on the task. A lift of zero is a failed fine-tune.

Criterion two: successful local serve. The GGUF you exported must run through Ollama or llama.cpp on your hardware at a usable latency. It loads. It generates. It exhibits the fine-tuned behavior, not the base's default. And no telemetry — you confirm it with the network off or with tcpdump.

Criterion three: reproducibility. Someone else clones your repo, runs one command, and reproduces your numbers within a tolerance. Pinned dependencies. Set seeds. Numbers in the README. A README without numbers is a README without proof.

[SLIDE 5 — Lift versus forgetting]

Here is a discipline that separates a real fine-tuner from a desperate one. You run two evaluations, both required.

The lift — the gain — is the domain held-out score, fine-tuned minus base. That proves steering worked. The forgetting — the cost — is the general benchmark score, base minus fine-tuned. That proves the fine-tune was disciplined.

Why is forgetting required? Because a plus-fifteen lift with minus-ten on GSM8K is a fine-tune that broke the model's reasoning to get domain style. It steered so hard toward the domain it steered away from everything else. The forgetting number is the discipline check. Without it, the lift is uninterpretable. A submission with only the domain lift is incomplete — full stop.

[SLIDE 6 — The seven-phase pipeline]

Now the architecture. Seven phases, bottom-up. Each produces a deliverable that feeds the next.

Phase one: choose your domain and your open-data base. The domain must be one where the base already has the capability but not the behavior — that's the three-outcome test from FT zero zero, outcome one. Phase two: HIPAA-safe data prep — open datasets plus synthetic generation, deduped and decontaminated. Phase three: QLoRA fine-tune and merge — four-bit base, LoRA on the attention projections, then merge the adapter in. Phase four: eval — domain held-out plus general benchmark. Phase five: GGUF export. Phase six: local serve. Phase seven: the reproducibility package.

Read it bottom-up and you are climbing the steering stack. Each phase is a layer. A mistake in data prep propagates to a failed lift in eval, which no amount of export polish can fix.

[SLIDE 7 — The air-gap is a property, not a feature]

I want to dwell on this because it is the most misunderstood part of the capstone. The air-gap is not something you bolt on at deployment. It is a property of the whole pipeline.

Design for it from phase one. Your data prep uses local open datasets and local synthetic generation. Your training runs on a local GPU or Apple Silicon with the model cached locally. Your eval runs locally. Your GGUF conversion is local. Your serve is Ollama or llama.cpp — and you confirm, with the network off or with a packet capture, that there are no outbound calls.

If you skip this check, you do not have an air-gapped model. You have a model that you hope is air-gapped. The proof is the verification. Run it with the network off. If it still serves, you have the property. If it doesn't, find the call.

[SLIDE 8 — The evaluation rubric]

Here is how a reviewer — or you, self-assessing — scores the submission. Five dimensions, each scored one to three. Domain lift. Forgetting control. Local serve. Reproducibility. And HIPAA-safety.

Passing is twelve out of fifteen, with no dimension below two. And HIPAA-safety is a gate. A one in HIPAA-safety fails the submission regardless of the total. That is intentional. A model with a spectacular lift whose data provenance is unclear is not a capstone deliverable — it is a result. The deliverable is the pipeline that produced it, and a pipeline with unclear data provenance is not safe to hand to a clinician.

[SLIDE 9 — What a passing submission looks like]

Concretely, a passing submission is a GitHub repo with a README that reads like a short technical report. A domain rationale. A base choice, justified in one paragraph — why this base, why this size, what its training corpus covers. A results table: base, fine-tuned, lift, forgetting, latency. A one-command run — make pipeline — that chains all seven phases. And a data-safety note documenting the provenance and de-identification, publishable.

Example numbers — illustrative, yours will differ — base MMLU medical forty-two point one, fine-tuned fifty-one point three, lift plus nine point two. GSM8K thirty-eight point five to thirty-seven point nine, forgetting minus zero point six. Q4 K M, fourteen tokens per second on an M two Pro. A reviewer who clones your repo, runs your pipeline, and gets those numbers within tolerance passes you. That is the bar.

[SLIDE 10 — What fails]

Four ways to fail.

A notebook only. No pipeline, no pinned deps, no README with numbers. That is a result, not a deliverable.

Lift without forgetting. Plus twelve domain but no general benchmark. The reviewer cannot tell if you traded away half the model's reasoning. Incomplete.

Serve that needs the network. The GGUF loads but Ollama phones home for something. The air-gap claim is false. You fail the HIPAA gate.

And an unjustified closed base. You used Llama three "because it's better" without addressing the auditability requirement. The base choice is the foundation of the sensitive-domain argument. An unjustified closed base undermines it.

[SLIDE 11 — Why this capstone matters]

This capstone is the proof that the course's thesis works end to end. Fine-tuning steers behavior; it does not teach knowledge — and here you demonstrate that steering on a real domain, measure the lift and the cost, and ship the result to a place where it runs without anyone else's infrastructure.

The three success criteria are the three claims of the course, operationalized. Domain-lift proves steering works. Local serve proves the export layer. Reproducibility proves you understood the whole pipeline, not just one phase of it.

And the air-gap is the point. A model that belongs to its domain — not to a vendor, not to a cloud, not to an API. That is what you build in the next hundred and twenty minutes.

[SLIDE 12 — What you can now do]

When you finish, you can assemble a reproducible end-to-end fine-tuning pipeline that runs on consumer hardware. You can defend the three success criteria with numbers. You can distinguish steering gains from memorization using a held-out set. And you can ship a GitHub README asset that a reviewer can clone, run, and reproduce.

That is the integration capstone. The next one, Capstone two, is the synthesis: the same pipeline skills, applied to an uncensored model wrapped in an eval'd harness. That is the bridge to the Harness Engineering courses. But first, build this one. Open the lab spec and begin.

---

*End of capstone CAP1 framing. The build itself runs ~120 minutes following the seven phases in `07-lab-spec.md`.*