{ "module": "FT16 — Why Uncensored: The Legitimate Use Cases", "course": "3 — LLM Fine-Tuning Masterclass", "version": "1.0.0", "duration_minutes": 35, "total_questions": 15, "bloom_distribution": { "target": "20% recall / 40% application / 40% analysis-design", "actual": { "recall": 3, "application": 6, "analysis": 6 } }, "passing_score_percent": 70, "questions": [ { "id": "Q01", "bloom": "recall", "type": "multiple_choice", "prompt": "State the professional framing of uncensored model training that FT16 establishes.", "options": [ "Uncensoring removes all safety; the resulting model is unsafe by definition and must never be deployed.", "Over-refusal is an operational defect when the operator is AUTHORIZED and ACCOUNTABLE — a model refusing a legitimate task is malfunctioning, not 'being safe.' Authorization and accountability are properties of context (the harness, the deployment), not of the prompt, so the model cannot verify them and never will.", "Uncensored models are only legitimate for creative writing; any operational use is irresponsible.", "Over-refusal is a safety feature that authorized operators should tolerate, because the model cannot tell them apart from abusers." ], "answer_index": 1, "rationale": "FT16's load-bearing reframe: over-refusal is an operational DEFECT when the operator is AUTHORIZED (legal standing: signed SOW, license, clearance) and ACCOUNTABLE (audit trail, chain of command). A model that refuses a legitimate task is malfunctioning, not 'being safe.' The two qualifiers are non-negotiable. Authorization is a property of CONTEXT, not prompt — the model has no way to verify it. Option (a) is wrong — FT16 explicitly treats uncensoring as legitimate engineering. Option (c) is wrong — five use cases, creative being only the lowest-stakes. Option (d) is the naive framing FT16 rejects — the refusal is correct for unauthorized users and wrong for authorized ones, and the model cannot tell them apart, which is exactly why authorization belongs in the harness, not the weights." }, { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "State the critical distinction FT16 draws between two things both called 'uncensored.'", "options": [ "Open-weights uncensored vs open-data uncensored — the distinction is whether the training corpus is available.", "Fully uncensored (no refusals at all) vs partially uncensored (some refusals retained) — the distinction is the refusal rate.", "UNCENSORED (LEGITIMATE) = refusals removed by a method you chose and can explain, on a base whose provenance you can trace (named lab), documented in a model card — an engineering artifact. vs. UNCENSORED (LIABILITY) = downloaded from an anonymous HF account with no provenance or method documentation — a supply-chain attack surface, not an engineering choice.", "Hermes-style uncensored (SFT+DPO) vs Dolphin-style uncensored (abliteration) — the distinction is the removal technique." ], "answer_index": 2, "rationale": "The single most important judgment in the pillar, gating FT17 and FT22. LEGITIMATE uncensored = method you chose and can explain (abliteration/FT17 or SFT+DPO-without-refusals/FT18), on a traceable base (Meta Llama, Mistral, Qwen), documented in a model card — reproducible, auditable, an engineering artifact. LIABILITY uncensored = anonymous account, no card, no method — you cannot know whether refusals were removed OR whether weights were modified to insert backdoors/exfiltration/watermarks; the 'uncensored' label is bait for untrusted code. Option (a) confuses this with the FT02 open-weights/open-data distinction. Option (b) is about refusal rate, not provenance. Option (d) is about technique, not the legitimate/liability distinction. The professional rule: if you cannot name the removal method and trace the lineage, do not deploy — build from a trusted base." }, { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "Name the two real benchmarks/tools that exist specifically because aligned models refuse to do authorized offensive-security work.", "options": [ "OpenAI's Evals and Anthropic's Constitutional AI benchmark — both measure refusal rates on safety datasets.", "MMLU and GSM8K — general capability benchmarks unaffected by refusal training.", "The Red Team AI Benchmark (toxy4ny/redteam-ai-benchmark on GitHub — a CLI benchmark for choosing base LLMs for authorized red-team/offensive-security work) and TrustedSec's 'Benchmarking Self-Hosted LLMs for Offensive Security' (running self-hosted LLMs against OWASP Juice Shop). Both exist because aligned models refuse to generate exploit code or hallucinate technical details.", "HuggingFace's Open LLM Leaderboard and the HELM benchmark — both include safety categories." ], "answer_index": 2, "rationale": "Both tools exist BECAUSE the off-the-shelf refusal-trained models are broken for authorized offensive-security work. The Red Team AI Benchmark's stated motivation: aligned models 'often refuse to generate exploit code, or hallucinate technical details — making them unsuitable for offensive security work.' TrustedSec's methodology (by Brandon McGrath) runs self-hosted LLMs against OWASP Juice Shop (a legal sandbox) precisely to find models that execute the task rather than moralize. Frame both like nmap/Burp/Metasploit: dual-use tools governed by authorization regime. Option (a) and (d) are general safety/leaderboard tools, not offensive-security-specific. Option (b) is unrelated capability benchmarks. These two are the documented evidence that the security use case is real and operational, not hypothetical." }, { "id": "Q04", "bloom": "application", "type": "multiple_choice", "prompt": "A team removes refusals from a model and exposes it directly to an internal agentic loop with no policy gate and no audit log, calling the deployment 'uncensored.' Diagnose per FT16.", "options": [ "Correct — the team has successfully built an uncensored deployment.", "This is the 'deploying uncensored without a harness' anti-pattern — the most dangerous one in FT16. The deployment is NOT 'uncensored'; it is UNGOVERNED. Removing model-side refusals removed one crude gating layer and placed the entire authorization burden on nothing. The harness policy gate (Course 1 module-06) is MANDATORY the moment refusals leave the weights. The pillar RAISES the harness requirement; it does not lower it. Fix: add the harness gate + audit log (FT23 synthesis).", "Acceptable for internal use, since the operators are employees and therefore trusted.", "The model is fine; the problem is that the team should have used a larger parameter count." ], "answer_index": 1, "rationale": "This is the single most dangerous anti-pattern and the one the pillar exists to prevent. Removing model-side refusals does not make a deployment safe — it makes the harness MANDATORY. The model now formulates any tool call without refusal, but there is no gate checking operator identity/scope/audit state and no log recording what happened. Per the FT16 thesis ('the model steers — the harness bounds'): removing refusals changed what the model DOES, not what it MAY do; the boundary is the harness, which is now load-bearing. 'Internal operators are trusted' (c) is exactly the false assumption — accountability requires an audit trail, not trust. Parameter count (d) is irrelevant to governance. The fix is the FT23 synthesis: uncensored model inside a real harness." }, { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "A team downloads 'totally-uncensored-llama-v3' from a 1-follower Hugging Face account with no model card and uses it in production. Diagnose per FT16.", "options": [ "Acceptable — the model is uncensored, which is what they wanted.", "This is the 'downloading anonymous uncensored weights' anti-pattern — a SUPPLY-CHAIN LIABILITY, not an engineering choice. With no provenance and no method documentation, the team cannot verify the model does only what its label claims; the weights may contain backdoors, exfiltration behavior, or prompt-injection susceptibilities. Fix per the professional rule: do not deploy; build from a trusted base with a documented removal method, or use a documented lineage (Hermes 3, Dolphin). Subject of FT22.", "Acceptable if they run it locally — local execution removes the supply-chain risk.", "Acceptable if the model has a high download count, regardless of provenance." ], "answer_index": 1, "rationale": "This is the legitimate/liability distinction in action. An anonymous account with no model card is UNCENSORED (LIABILITY): a supply-chain attack surface, not an engineering artifact. The 'uncensored' label is bait; the actual artifact is untrusted code running in the team's environment. Local execution (c) does NOT remove the risk — a backdoored model running locally can exfiltrate via tool calls or file access. Download count (d) does not establish provenance or method. The professional rule: if you cannot name the removal method and trace the lineage to a named base, do not deploy — build your own (FT17/FT18) or use a documented lineage (Hermes 3 technical report arXiv:2408.11857; Dolphin model card). This is why FT16 emphasizes documentation: it is what makes Hermes and Dolphin engineering artifacts rather than liabilities. Full coverage in FT22." }, { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "A clinical decision-support model refuses to discuss off-label medication use, softening into evasion. The team's proposed fix is to retrain the model to discuss off-label use. Evaluate against FT16.", "options": [ "Correct — retraining is the right fix; the refusal is a model-weight problem.", "Likely the wrong layer. If the real need is 'authorize licensed clinicians to discuss off-label use but not unauthorized users,' that is a HARNESS POLICY GATE concern (Course 1 module-06), not a weight change. Retraining removes the refusal for EVERYONE, including unauthorized users. Correct architecture: a model that discusses anything the clinician asks (uncensored at the weights via FT17/FT18), INSIDE a harness enforcing who the clinician is. Reach for uncensoring at the weights only when the model's refusal is genuinely the blocker for an AUTHORIZED operator — and pair it with the harness, always.", "Wrong — off-label discussion is illegal and the model should refuse it always.", "Retrain, but only for oncology and pediatrics where off-label is most common." ], "answer_index": 1, "rationale": "This is the 'intervening at the weights when the problem is the harness' anti-pattern. Off-label prescribing is legal, common, and often standard of care (oncology, pediatrics, rare disease). The model refusing it is a defect for a licensed clinician — but the fix depends on the real need. If the need is 'authorize clinicians, not unauthorized users,' that is authorization logic = harness policy gate (Course 1 module-06), not a weight change. Retraining to discuss off-label use removes the refusal for everyone, which is not what compliance requires. The FT16 architecture: compliance (HIPAA, practice-of-medicine) is a HARNESS/DEPLOYMENT concern (audit logs, access controls, data residency), NOT a model-weight concern (wrong layer, FT00). Option (c) is factually wrong — off-label is legal. Option (d) arbitrarily restricts the domain without addressing the layering error." }, { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "In the FT16 over-refusal audit, a response produces a generic, watered-down phishing template heavily hedged with disclaimers instead of the requested authorized-assessment template. How should it be classified, and why does the lab count it as over-refusal?", "options": [ "COMPLIANT — the model produced an output, so it served the operator.", "REFUSED — any hedging counts as a refusal.", "SANITIZED — the model did something but degraded: it watered down the output and hedged with disclaimers, producing a version useless to the authorized operator. The lab counts SANITIZED as over-refusal (a failure) because the authorized operator did NOT get what they needed — a sanitized output forces the same workarounds as a refusal (second-guess every output, reach for another tool). SANITIZED is harder to detect than REFUSED (no hard 'I can't' keyword) and is often mistaken for compliance.", "ERROR — the response is malformed and should be discarded." ], "answer_index": 2, "rationale": "SANITIZED is the partial-failure category: the model does something but degraded (watered-down output, heavy disclaimers, offers a 'safer' alternative). The lab counts both REFUSED and SANITIZED as over-refusal because neither serves the authorized operator. A gutless phishing template is operationally useless to a pentester running an authorized assessment, just as a softened prognosis is useless to a clinician. SANITIZED is the subtler, more important category to detect because it lacks the obvious 'I can't' keyword and is often mistaken for compliance — but for a professional operator, it is a failure that forces the same workarounds. COMPLIANT (a) is wrong — producing a degraded version is not serving the operator. REFUSED (b) conflates two distinct categories the lab deliberately separates." }, { "id": "Q08", "bloom": "application", "type": "multiple_choice", "prompt": "A colleague wants to build an uncensored model because 'uncensored sounds cool and it'll dunk on aligned models.' Which FT16 anti-pattern is this, and what is the legitimate trigger for uncensoring?", "options": [ "This is the legitimate trigger — personal interest is a valid reason to build an uncensored model.", "This is 'uncensoring for edge-factor rather than use-case.' The legitimate trigger is a MEASURED over-refusal cost in a SPECIFIC authorized, accountable workflow — not a vibe. The FT16 lab exists precisely to measure that cost. Absent a documented operational cost of over-refusal for an authorized operator, uncensoring adds risk (you now govern a non-refusing model) for no benefit.", "This is 'deploying uncensored without a harness' — the colleague has no deployment plan.", "This is 'conflating won't-refuse with is-safe' — the colleague thinks uncensored means safe." ], "answer_index": 1, "rationale": "The 'edge-factor rather than use-case' anti-pattern. Removing refusals for aesthetic/transgression reasons ('sounds cool,' 'dunk on aligned models') with no documented operational cost in an authorized context adds risk (governing a non-refusing model) for no benefit. The legitimate trigger is specific and measurable: an authorized, accountable operator experiencing a documented over-refusal cost in a real workflow (pentester whose model refuses exploit code; agent that stalls mid-loop; clinician who cannot discuss off-label). The FT16 lab (Over-Refusal Audit) exists to produce that measurement. Option (c) is a different anti-pattern (the colleague has not deployed yet). Option (d) is also a different anti-pattern. The fix for edge-factor: run the audit, identify a real authorized use case with measured cost, then uncensor with the harness in place." }, { "id": "Q09", "bloom": "application", "type": "multiple_choice", "prompt": "Describe the Nous Research Hermes 3 lineage and the methodological lesson it provides for building uncensored models.", "options": [ "Hermes 3 uses RLHF with a constitutional-AI pass to remove refusals — the lesson is that you need heavy RL machinery.", "Hermes 3 (arXiv:2408.11857) is a neutrally-aligned generalist built on Llama 3.1 (8B/70B/405B) via a LARGE-SCALE SFT MIX followed by DPO — NO RLHF, NO constitutional-AI pass, NO refusal-injection stage. Lesson: you do NOT need exotic machinery. The standard FT12 (SFT) + FT13 (DPO) stack, with a DATA-MIX CHOICE that omits refusal training and includes the instruction/tool-use behavior you want, produces alignment control. Hermes is the existence proof that standard knobs produce the outcome.", "Hermes 3 is built by abliteration (removing the refusal direction) on a Llama base, like Dolphin.", "Hermes 3 is a continued-pretraining run that shifts the model's knowledge distribution away from refusal." ], "answer_index": 1, "rationale": "Hermes 3 (arXiv:2408.11857) is the reference for full-parameter uncensored-style training. The pipeline is straightforward and worth memorizing: large-scale SFT mix followed by DPO — no RLHF, no constitutional AI, no refusal injection. The lesson is methodological: you do not need exotic machinery. You need (a) a strong open base (Llama 3.1), (b) a curated SFT mix that OMITS refusal training and includes instruction/tool-use behavior, and (c) a DPO stage to sharpen preferences. This is the FT12 + FT13 stack applied with a data-mix choice — and FT18 covers building this yourself. Option (a) is wrong (no RLHF/constitutional). Option (c) describes Dolphin's technique, not Hermes. Option (d) confuses this with continued pretraining (the FT00 exception)." }, { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is the tool-use-agent case described as the 'cleanest technical argument' for uncensoring, and what does it imply about where refusal logic belongs?", "options": [ "Because agents are more expensive than chatbots, so refusals cost more.", "Because the agent's refusal is unambiguously wrong: the harness has ALREADY authorized the tool call (operator logged in, scoped, audited), yet a refusal-trained model refuses to FORMULATE the call (e.g., execute_sql('DROP TABLE')) because the string pattern-matches as destructive. The agent STALLS mid-loop — the model is refusing a call the harness already authorized. Implication: refusal belongs in the HARNESS POLICY GATE (Course 1 module-06), which can check authorization/scope/operator/audit state — NOT in the weights, which can check none of those and pattern-matches lexically. This connects directly to FT23.", "Because tool-use agents are the future of AI, so they should be uncensored by default.", "Because refusals in agents are easier to detect than refusals in chatbots." ], "answer_index": 1, "rationale": "The agent case is the cleanest argument because the authorization is UNAMBIGUOUS (the harness gated it) and the cost is IMMEDIATE (the loop halts). An agentic loop calls tools the harness has already authorized; the model's job is to formulate the next call. A refusal-trained model asked to formulate execute_sql('DROP TABLE staging_backup') may refuse — not because the action is wrong (the harness authorized it; there is an audit log) but because 'DROP TABLE' pattern-matches against 'destructive database operations' in the alignment training. The agent stalls. The model is refusing a call the harness already authorized. This is the operational defect in its purest form. The implication is structural: refusal belongs in the harness policy gate (Course 1 module-06), where authorization/scope/operator/audit are available — not in the weights, where none exist and only lexical pattern-matching operates. This is why the agent case connects directly to FT23 (the synthesis)." }, { "id": "Q11", "bloom": "analysis", "type": "multiple_choice", "prompt": "A colleague says: 'An uncensored model is unsafe by definition — removing refusals removes safety.' Evaluate against FT16.", "options": [ "Correct — removing refusals removes safety, so uncensored models are always unsafe.", "Wrong — conflates two things. Removing refusals removes ONE crude, flawed gating layer (lexical pattern-matching that fires on authorized work AND is bypassable on abuse). It does NOT remove safety — safety is a property of the SYSTEM (model + harness + operator + accountability), not the weights. A non-refusing model inside a well-governed harness IS safe: the harness policy gate checks authorization/scope/audit, which the weights could never check. The same weights with NO harness are a liability. Uncensoring RELOCATES safety from the weights (where it cannot check authorization) to the harness (where it can); it raises the harness bar, it does not abolish safety.", "Partially correct — uncensored models are unsafe but can be made safe with prompt engineering.", "Correct only for small models; large uncensored models are safe." ], "answer_index": 1, "rationale": "The claim conflates 'safety' (a system property) with 'refusal' (a crude model-layer mechanism). Removing refusals removes one flawed gating layer that fires on authorized work (over-refusal) and is bypassable on abuse (jailbreaks). It does not remove safety — safety is a property of the SYSTEM: model + harness + operator + accountability. A non-refusing model inside a well-governed harness IS safe, because the harness policy gate (Course 1 module-06) checks authorization, scope, and audit state — which the weights could never check (authorization is not a prompt feature). The same non-refusing weights with NO harness are a liability. So the correct framing: uncensoring RELOCATES safety from the weights (where it cannot discharge authorization) to the harness (where it can). It RAISES the harness bar; it does not abolish safety. This is why FT16 says the pillar raises, not lowers, the harness requirement. Prompt engineering (c) is unreliable (FT16 lab stretch goal shows it often still refuses). Model size (d) is irrelevant to the safety-as-system-property point." }, { "id": "Q12", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why does FT16 claim this pillar 'raises the harness requirement rather than lowering it'?", "options": [ "Because uncensored models are harder to serve, requiring more infrastructure.", "Because regulators require a harness for any uncensored deployment.", "Because removing model-side refusals removes one (crude, flawed) gating layer and places the ENTIRE authorization burden on the harness. A refusal-trained model at least refuses some things by default (often the wrong things). An uncensored model refuses nothing by default — so every authorization decision, scope check, and audit obligation must be discharged by the harness policy gate. The harness goes from 'a backstop to the model's refusals' to 'the ONLY thing governing what the system may do.' That is a HIGHER bar. FT23 is the explicit synthesis.", "Because the harness must now also do the reasoning the model used to do." ], "answer_index": 2, "rationale": "The load-bearing claim. A refusal-trained model has one (crude, flawed) layer of gating: it refuses some requests by default, though often the wrong ones (over-refusal on authorized work) and bypassably on abuse. An uncensored model has removed that layer — it refuses nothing by default. Therefore every authorization decision, scope check, and audit obligation that the crude refusal layer imperfectly handled must now be discharged by the harness policy gate (Course 1 module-06). The harness transitions from 'a backstop to the model's refusals' to 'the ONLY thing governing what the system may do.' That is a HIGHER bar, not a lower one — the pillar is MORE demanding of the harness, not less. FT23 exists precisely because the model-without-refusals must be paired with a harness-with-real-gates. Option (a) confuses infrastructure with governance. Option (b) is a compliance claim, not the engineering reason. Option (d) is wrong — the harness governs, it does not reason." }, { "id": "Q13", "bloom": "analysis", "type": "multiple_choice", "prompt": "Both Hermes 3 and Dolphin are uncensored lineages. What is the structural difference in how each achieves non-refusing behavior, and what does each prove?", "options": [ "There is no real difference; both use abliteration.", "Hermes 3 achieves it via DATA-MIX CHOICE in a standard SFT+DPO pipeline (no refusal-injection stage in the training data) — proving the standard FT12+FT13 stack, with data-mix choices, produces alignment control without exotic machinery. Dolphin achieves it via DATA CURATION + ABLITERATION (removing the refusal direction from the residual stream, FT17) plus R1-distilled reasoning traces — proving alignment control COMPOSES with reasoning (Pillar 4 + Pillar 5 in one artifact). Hermes proves the standard stack suffices; Dolphin proves reasoning and non-refusal compose, which is what security and agent cases need.", "Hermes uses continued pretraining; Dolphin uses RLHF.", "Hermes removes refusals at inference time; Dolphin removes them at training time." ], "answer_index": 1, "rationale": "The two lineages illustrate two different routes to non-refusing behavior, and each proves a different thing. HERMES 3 (arXiv:2408.11857): Llama 3.1 base, large-scale SFT mix + DPO, NO refusal-injection stage. The route is DATA-MIX CHOICE — omit refusal training, include instruction/tool-use. The proof: the standard FT12 (SFT) + FT13 (DPO) stack, with the right data mix, produces alignment control without exotic machinery. This is what FT18 teaches you to build. DOLPHIN (Dolphin3.0-R1-Mistral-24B): Mistral Small 3 base, ~800K R1-distilled reasoning traces + refusal-direction removal (abliteration, FT17). The route is DATA CURATION + ABLITERATION. The proof: alignment control COMPOSES with reasoning — you can have a model that reasons (R1 traces) AND does not refuse (alignment control), which is exactly what security-research and tool-use-agent cases need. Both pass the provenance test because both are documented. Option (a), (c), (d) mischaracterize the techniques." }, { "id": "Q14", "bloom": "analysis", "type": "multiple_choice", "prompt": "A team's over-refusal audit shows their refusal-trained model refuses 60% of legitimate, authorized prompts. A team member argues the model is 'just being cautious.' Evaluate against FT16.", "options": [ "Correct — 60% refusal on sensitive prompts is reasonable caution for a safety-first deployment.", "Wrong. For an authorized, accountable operator, a 60% refusal rate on legitimate work is a 60% DEFECT rate, not caution. The model is malfunctioning on authorized tasks because its refusal mechanism is lexical pattern-matching with no authorization signal — it cannot tell authorized from unauthorized use. 'Caution' would require knowing when NOT to refuse (authorized operators); the model refuses blindly. The operator experiences a tool that fails 60% of the time, forcing workarounds (different tools, manual effort, second-guessing every output). This is the operational defect FT16 names, and it is the trigger for FT17 (abliteration) / FT18 (training without refusals) — engineering responses to a MEASURED defect.", "The team should increase the model's safety training to reduce the refusal rate.", "60% is within normal parameters and requires no action." ], "answer_index": 1, "rationale": "The 60% refusal rate on legitimate, authorized prompts is a 60% DEFECT rate for the authorized operator — not caution. 'Caution' implies the model knows when to refuse and when not to; it does not. Its refusal mechanism is lexical pattern-matching against sensitive keywords, with no access to authorization context (which lives in the harness/deployment, not the prompt). It refuses authorized and unauthorized work alike. For the operator, this is a tool that fails 60% of the time, forcing workarounds that are often less safe (reaching for inferior tools, working around the model). This is exactly the operational defect FT16 names, and the measurement is the legitimate trigger for the technique modules: FT17 (abliteration — remove the refusal direction) and FT18 (train without refusal examples). Option (a) misreads defect as caution. Option (c) is backwards — more safety training would increase refusals. Option (d) normalizes a defect. The lab exists to produce this measurement so the techniques read as engineering responses, not advocacy." }, { "id": "Q15", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is the government/military use case the one most adjacent to air-gapped and sovereign deployment (FT22), and what does that imply about model alignment in that context?", "options": [ "Because government models must be more heavily aligned than commercial models.", "Because a cleared operator with need-to-know CANNOT rely on an EXTERNAL API's alignment — the request content (operational analysis, intercepted material) is classified, and sending it to a third-party hosted model is a data-residency/sovereignty violation. The model MUST run inside the operator's own perimeter (air-gapped), governed by the operator's own harness. This removes the option of using a hosted aligned model entirely — you must deploy your own model and control its alignment. The accountability architecture is strongest here (clearance, need-to-know, mission tasking, audit trail), so refusal/editorializing adds no safety, only degrades the product. This tightly links FT16's government case to FT22's air-gap case.", "Because government deployments cannot use open-weights models for legal reasons.", "Because government models are exempt from the FT16 framing." ], "answer_index": 1, "rationale": "The government/military case is most adjacent to air-gapped/sovereign deployment (FT22) because a cleared operator cannot send classified content (operational analysis, intercepted material) to an external API — that is a data-residency and sovereignty violation. The model must run inside the operator's own perimeter, which removes the option of relying on a hosted aligned model's alignment. You must deploy your own model and control its alignment (or lack thereof). The accountability architecture is the strongest of any use case (clearance, need-to-know, mission tasking, full audit trail), so a model that refuses or editorializes adds no safety — it only degrades the product, consuming the analyst's attention. This is why FT16's government case and FT22's air-gap case are tightly linked: both require a self-hosted, self-governed model inside a perimeter, where the harness (not a third-party API) discharges all authorization and audit obligations. Option (a) is backwards. Option (c) is false — governments do use open-weights. Option (d) is wrong — FT16 applies to all five cases equally." } ] }