# Teaching Script — Module FT02: The Open Spectrum

**Course**: Course 3 — LLM Fine-Tuning Masterclass
**Module**: FT02 — The Open Spectrum: Weights, Data, and Trust
**Duration**: ~40 minutes (spoken at ~140 wpm)
**Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes.

---

[SLIDE 1 — Title]

Welcome back. This is module FT zero-two, The Open Spectrum: Weights, Data, and Trust. In module FT zero-zero we built the Steering Stack and I said that the defining property of Layer one — the base model — is its openness. This module is what that sentence means, and why it is load-bearing the moment you deploy in a regulated domain.

If you never touch HIPAA, FedRAMP, IL5, or an air-gap, you can treat openness as a preference. The moment you do, openness becomes a procurement requirement, and the tier you choose decides whether you pass the audit before you write a line of code.

[SLIDE 2 — The three tiers]

When a lab releases what they call a "model," what you actually receive varies enormously. Three tiers matter.

Tier one, open-weights-only. You get the weights — the trained tensors. You do not get the training data. The canonical example is Meta's Llama three family. The weights ship under the Llama Community License, the pretraining corpus is described only in aggregate — roughly fifteen trillion tokens, multilingual, code, reasoning — and the post-training recipe is summarized, not reproducible. You can run it. You can fine-tune it. You cannot audit what it saw, and you cannot reproduce it.

Tier two, open-data. You get the weights and the training corpus — or, when the corpus is too large to ship verbatim, a documented, reproducible pipeline that names the exact source datasets, their proportions, and the filtering applied. OpenBMB's MiniCPM family, Allen Institute's OLMo two and Tulu three, and HuggingFace's SmolLM three occupy this tier. The defining property: you can prove what the model saw. That is the auditability predicate.

Tier three, open-recipe. The strictest tier. Weights, plus data, plus the complete training code and configuration — optimizer state, hyperparameter schedules, the data-curation pipeline, eval harness, and in the best cases intermediate checkpoints. OLMo, Tulu three, and SmolLM three all ship this. The defining property: a skilled person can rebuild the model from scratch, and a security team can prove no training-time exfiltration occurred. This is what IL five, IL six, and air-gapped environments increasingly require.

Here is the one-sentence summary. Open-weights lets you use the model. Open-data lets you audit what it saw. Open-recipe lets you reproduce and prove the whole thing. Each tier adds a trust property the one below lacks.

[SLIDE 3 — The OSAID gap]

Now the thing everyone gets wrong. On October twenty-eighth, twenty twenty-four, the Open Source Initiative released version one point zero of the Open Source AI Definition — OSAID — at the All Things Open conference. It is the first industry-standardized definition of "open source" for AI.

Read the data clause carefully. OSAID requires, for a system to be called open source AI, "sufficiently detailed information about the data used to train the system so that a skilled person can build a substantially equivalent system." Notice what it does not require. It does not require the data itself. It does not require that the data be openly licensed.

This is deliberate. The OSI concluded that requiring full corpus release was impractical — much training data is private, licensed under terms that forbid redistribution, or contains personal information that cannot legally be republished. So the definition permits a model trained on undisclosed data to call itself open source, as long as enough metadata about the data is published.

That is the OSAID gap, and it is the most important thing to understand about the definition. A Llama-style release — weights, code, and a high-level data description, but no actual corpus — can claim OSAID compliance without being reproducible in any rigorous sense. "Substantially equivalent" is not "identical," and nobody has defined the tolerance band. And OSAID compliance is not the same as auditability. If a regulator asks you to prove that a specific document was not in the training set, "we published a sufficiently detailed description of our data sources" is not a satisfying answer.

Here is the practical takeaway, fixed. OSAID compliance tells you the release is inspectable. It does not tell you the release is reproducible or auditable end to end. Treat "OSAID-compliant" and "open-data" or "open-recipe" as different claims, and never conflate them. If a vendor points at OSAID compliance as proof of auditability, they are conflating two different things. Ask for the data and the recipe. If they cannot provide it, the auditability claim does not survive.

[SLIDE 4 — The NTIA argument]

Now the single best government citation for the sensitive-data argument. Memorize the source.

In July twenty twenty-four, the U.S. National Telecommunications and Information Administration published "Dual-Use Foundation Models with Widely Available Model Weights" — mandated under Executive Order fourteen-one-one-zero. Among its findings, the NTIA states plainly that open-weight models, and I am quoting, "provide security benefits by allowing firms, researchers, and users to use potentially sensitive data" locally and on-premises.

That sentence is load-bearing. It is a federal agency, in an official report, endorsing the on-premises and air-gapped deployment pattern as a security benefit of openness — not merely an economic or convenience benefit. The reasoning is mechanical. If the weights are available, the model can run inside your trust boundary. If they are not, every inference request leaves your boundary, traverses a vendor's infrastructure, and depends on that vendor's data-handling and retention commitments.

This is why IL five and IL six, HIPAA-covered workloads, and air-gapped environments increasingly require an open-weight base. You cannot put a proprietary API-only model inside a SCIF. You can put an open-weights model there — and if it is also open-data or open-recipe, you can additionally answer the procurement officer's question: where did these weights come from, and what did they see? The NTIA report does not claim open weights are risk-free. Its claim is narrower and stronger: the set of environments that can use a model at all expands when the weights are available, and the sensitive ones are gated on openness. Module FT twenty-two develops the air-gapped deployment fully.

[SLIDE 5 — The FMTI]

Now let us turn openness from a slogan into a number. The Stanford CRFM's Foundation Model Transparency Index — the FMTI — scores developers on one hundred indicators across data, labor, hardware, usage, and downstream monitoring. The May twenty twenty-four results: the mean score was fifty-eight out of one hundred, the top was eighty-five, and the gap was structural. Fully-open developers — OLMo, Ai2, IBM Granite — cluster at the top. Closed developers like OpenAI, then around forty-nine, and Anthropic, around fifty-one, sit below the mean.

Two readings matter. First, transparency is measurable and tiered, not a binary. The FMTI gives you a defensible, citable metric when a procurement RFP asks you to justify model choice on transparency grounds. Second, the index tracks the openness tier cleanly. Open-recipe developers score highest because they publish data composition, processing code, and evals. Weights-only score lower. Closed score lowest of all. The tier you choose is, roughly, the score you can defend. The FMTI is the bridge from "openness is nice" to "openness is a procurement criterion."

[SLIDE 6 — The model family comparison]

Here are eight releases mapped to their tier. This is the table to memorize.

Open-recipe, auditable: OLMo two from Ai2 — Apache-two-point-zero, data, code, eval, and checkpoints. Tulu three, also Ai2 — full post-training recipe. SmolLM three from HuggingFace — pre, mid, post, and synthetic data documented. MiniCPM from OpenBMB — Apache-two-point-zero, with the Ultra datasets. DCLM — the data pipeline is the point of the project.

Open-weights or partial: NVIDIA's Nemotron — post-training data documented, pretraining opaque, under the NVIDIA Open Model License. Partial.

Open-weights-only: Llama three point one, including the four-oh-five-billion — Llama Community License, data described in aggregate only, recipe summarized. Not auditable.

Closed: GPT-four-o — proprietary, API-only, weights withheld. Not auditable.

Read the right-hand column — auditable. That is the question this course cares about, because it is the question a HIPAA security officer, a FedRAMP assessor, or an IL six authorizing official will eventually ask. The answer divides cleanly. Open-recipe and open-data families are auditable; weights-only and closed are not. Capability does not appear in this table on purpose — capability is FT zero-three's concern. This module is about whether you can trust the provenance.

[SLIDE 7 — OpenBMB and MiniCPM]

Let me say a word about OpenBMB, because this course uses MiniCPM as its on-ramp hero. OpenBMB — the "Open Lab for Big Model Base" — is a collaboration between Tsinghua University and the company ModelBest. Its MiniCPM family includes MiniCPM five dash one B, the roughly one-billion dense base we load in the FT zero-zero lab; MiniCPM three dash four B, a denser mid-size base; MiniCPM-V four point six, a vision-language variant; and MiniCPM-o four point five, an omni-modal variant. All Apache-two-point-zero.

OpenBMB also ships the open datasets this course returns to: UltraChat for dialogue, UltraFeedback for preference data, and Ultra-FineWeb for a curated web pretraining mix. When this course says "load an open-data base," MiniCPM is the default. When it says "fine-tune on an open preference dataset," UltraFeedback is the default. The MiniCPM stack is the course's worked example of an auditable base — you can point at every byte the model saw.

[SLIDE 8 — Why open-data wins for sensitive domains]

Three properties that only open-data and open-recipe releases give you, each of which becomes a compliance requirement in regulated deployment.

First, auditability — you can prove what the model saw. A HIPAA security officer conducting a risk analysis must be able to identify the sources of the model's knowledge. With an open-data base, you produce the corpus manifest. With a weights-only base, you produce the publisher's marketing description and a shrug.

Second, reproducibility — you can rebuild years later and prove no drift. A model deployed in a clinical system may run for years. If the vendor silently updates a closed model, behavior changes underneath your validated pipeline — silent drift — and your validation no longer holds. With an open-recipe base, you pin the exact commit of data, code, and weights and rebuild on demand. You can demonstrate to an auditor that the model you validated is the model you are running. You cannot do this with a closed API.

Third, supply-chain trust — you can rule out hidden training-time exfiltration. A weights-only or closed base is a black box at the moment that matters most: training time. You cannot prove the publisher did not fold sensitive or malicious data into the corpus. With an open-recipe release, the data lineage is auditable end to end — a security team can inspect the pipeline and, in the air-gapped case, rebuild the model from audited inputs inside the trust boundary. This is the property IL five, IL six, and air-gapped environments actually require.

Here is the thread, stated as one claim. Open-data and open-recipe releases are a compliance asset in sensitive domains, not merely an ideological preference. Auditability, reproducibility, and supply-chain trust each map to a requirement a regulator can name — and each is satisfiable only when you can see the data and the recipe.

[SLIDE 9 — Anti-patterns]

Three anti-patterns to leave with.

First, trusting a community merge with no provenance. The Hugging Face Hub is full of merged models — A merged with B, quantized, re-uploaded — with no documented data lineage, no evals, and a license they probably do not have the rights to grant. A model card that says "merge of X and Y, works great" is not an audit. In any sensitive deployment, trace the provenance back to the original bases and the original data. If you cannot, treat it as unauditable — because it is.

Second, treating OSAID compliance as equivalent to reproducibility. OSAID compliance is a real and useful signal. It means the release is inspectable and the publisher made a good-faith effort. It does not mean the release is reproducible, because the data requirement is "sufficiently detailed information," not "the data." A vendor that points at OSAID compliance as proof of auditability is conflating two different things. Ask for the data and the recipe.

Third, assuming "open" means "safe." Open data is auditable, not safe. An open corpus can still contain PII, copyrighted text, poisoned examples, or material that creates its own liability. Openness gives you the ability to vet. It does not do the vetting for you. In a sensitive deployment, the open-data base still needs a data audit, a PII sweep, a licensing review, and the same red-teaming you would apply to any other base. "It's open, so it's fine" is the open-source version of the cardinal error.

[SLIDE 10 — What you can now do]

You can now distinguish the three openness tiers and classify any release into the correct one. You can explain what OSAID requires and what it deliberately does not, and why compliance is not reproducibility. You can cite the NTIA report as the government authority for the on-premises sensitive-data argument. You can use the FMTI to quantify the transparency gap. And for any model, you can write the one-paragraph "can I audit this for a HIPAA deployment?" verdict.

The lab for this module asks you to do exactly that — audit five real releases, including MiniCPM, OLMo two, Llama three point one, SmolLM three, and GPT-four-o. No GPU required. It is a research and classification lab, because the skill it builds is reading a release for what it actually gives you.

Next, module FT zero-three: base model selection. Now that you know what openness means and why it matters, we choose the base — and we put capability and openness on the same axes for the first time.

---

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