"What does the DoD Impact Levels (IL) framework determine for an LLM deployment?"	"Four things at once: which FedRAMP baseline applies (Low/Moderate ~325 controls/High), what data class you may put in the prompt (unclassified/CUI/SECRET/TS-SCI), which network the box may sit on (NIPRNet/SIPRNet/JWICS), and whether the deployment is network-connected or air-gapped. Built by DISA; cited by GSA, FedRAMP, Microsoft, StackArmor, Second Front."	c3::ft22::recall
"Recite the DoD Impact Levels table — IL2 through IL7+."	"IL2 = FedRAMP Moderate (~325 controls), unclassified non-public, NIPRNet. IL4 = Moderate + DoD overlays, CUI, NIPRNet. IL5 = FedRAMP High, CUI / NSS, NIPRNet/SIPRNet. IL6 = High + classified overlays, SECRET, SIPRNet. IL7+ = Beyond FedRAMP, TS/SCI, JWICS (air-gapped)."	c3::ft22::recall
"What is the single most important structural fact about FedRAMP and LLM weights?"	"FedRAMP authorizes the CLOUD SERVICE (provider's controls: physical security, personnel clearance, audit logging, incident response) — NOT the model weights. It says nothing about whether the weights are trustworthy, what the model was trained on, or whether a merged LoRA has a backdoor. That gap is the subject of FT22."	c3::ft22::recall
"Name the three DoD networks and what each carries."	"NIPRNet (unclassified — IL2/IL4/IL5). SIPRNet (SECRET — IL5/IL6). JWICS (TS/SCI — IL7+, air-gapped from the public internet; no HF pull, no API calls, model arrives on media)."	c3::ft22::recall
"What three properties must an IL5+ model satisfy, and why?"	"(1) REPRODUCIBILITY — could re-derive from published corpus + code (in principle, even if you won't actually rerun a trillion-token pretrain). (2) NO HIDDEN TRAINING-TIME EXFILTRATION — corpus is published, you can diff it. (3) NO EMBEDDED BEHAVIOR YOU CAN'T ACCOUNT FOR — probe activations against the open-data reference. All three force the open-data choice."	c3::ft22::application
"Distinguish open-data, open-weights-only, and closed-weight models, and place each on the IL ladder."	"OPEN-DATA (weights + corpus: MiniCPM, OLMo, Tülu, SmolLM3) — REQUIRED at IL5+. OPEN-WEIGHTS-ONLY (weights, no data: Llama 3.x, Mistral) — IL2–IL4 with documented due diligence, liability at IL5+. CLOSED-WEIGHT (neither: OpenAI, Anthropic, Gemini) — API-only, incompatible with air-gap by construction."	c3::ft22::recall
"State the re-derivability rule for IL5+."	"If you cannot fully re-derive an artifact from its published source weights AND training recipe, you may NOT load it into an IL5+ environment. Rules out most community merges/LoRAs. Harsh but correct — an unauditable artifact is a contraband artifact."	c3::ft22::application
"Why is a community-merged model (e.g., 'Llama-3-Smaug-OpenHermes-blend-v4') a non-starter at IL5+?"	"Its provenance is a chain of merges and LoRA applications you cannot reconstruct. Even if every link is well-intentioned, you cannot re-derive it from source. At IL5+ the re-derivability rule forbids loading it. The compositional backdoor risk (OpenReview 'Down the Rabbit Hole') compounds this: A+B merge can trigger a backdoor neither alone activates."	c3::ft22::analysis
"What does OWASP LLM03:2025 name, and why is it significant?"	"Supply Chain Vulnerabilities. It explicitly names 'an attacker infiltrates a third-party supplier and compromises the production of a LoRA adapter, or a model-merge pipeline, such that the resulting artifact behaves normally under test but activates malicious behavior under a trigger.' First major standards body to name LoRA/merge as a first-class attack surface on par with vulnerable packages and poisoned data."	c3::ft22::recall
"Name OWASP LLM03:2025's three core supply-chain risks."	"(1) POISONED MODELS — base/adapter/merge backdoored at the weight level. (2) VULNERABLE PACKAGES — transformers, peft, trl, safetensors, bitsandbytes dependency tree (subject to PyPI/npm typosquatting, account takeover — ultralytics/stellar-freighter-class incidents). (3) WEAK PROVENANCE — no signed manifests, no pinned mirrors, no checksum verification, ambiguous licensing."	c3::ft22::recall
"What does arXiv:2512.19297 (Causal-Guided Detoxify Backdoor on LoRA) demonstrate?"	"A backdoor that SURVIVES the normal safety-eval pipeline by appearing to IMPROVE the model on benchmark dimensions — the adapter looks like a benign 'detoxify' fine-tune — while implanting a trigger-conditioned misbehavior. 'Causal-guided' = designed to causally steer behavior in a specific direction, not merely correlated. Defensive reviewer running benchmarks sees a better-behaving model."	c3::ft22::analysis
"What is MasqLoRA (CVPR 2026) and why does it matter?"	"First systematic LoRA supply-chain backdoor framework. Shows an attacker controlling the adapter can implant backdoors that (a) SURVIVE QUANTIZATION, (b) SURVIVE MERGING into the base, (c) EVADE WEIGHT-DIFF inspection (malicious update is rank-compatible with legitimate). 'Masq' = the malicious LoRA masquerades as legitimate at every inspection level short of activation probing. Only diff-in-means catches it."	c3::ft22::analysis
"What does Anthropic's small-samples-poison research show, and what is the defense?"	"A VERY SMALL number of poisoned samples can implant backdoors REGARDLESS OF MODEL SCALE — even single-digit-percentage poison rates produce reliable trigger-conditional behavior at fine-tuning. Scale does not buy immunity. The defense is NOT more data; the defense is VERIFIED data (open-data corpus you can audit), which loops back to the open-data argument."	c3::ft22::analysis
"What is LoRA's 'double vulnerability' (PMC healthcare review)?"	"Clinical fine-tuning attacks BOTH the DATA (poisoned patient records used as training set) AND the ADAPTER (malicious LoRA distributed as a 'medical reasoning' enhancement). The two are INDEPENDENT attack surfaces, and EITHER is sufficient to compromise the model. Healthcare and defense share this exposure because both consume many third-party adapters from a community they don't control."	c3::ft22::analysis
"Recite the five-step defensive playbook for verifying a model you did not train."	"(1) PREFER OPEN-DATA models (MiniCPM, OLMo, Tülu). (2) RE-DERIVE quants/LoRas from source — no opaque community artifacts, pinned toolchain. (3) DIFF-IN-MEANS / activation probing (FT17 abliteration toolkit, defensively) — the only check that survives MasqLoRA. (4) BEHAVIORAL EVALS — Promptfoo + Garak + your adversarial suite. (5) CHECKSUM/SIGN + pinned internal mirror — never hf pull inside the trust boundary."	c3::ft22::recall
"Why is diff-in-means / activation probing (Step 3) the only check that survives MasqLoRA?"	"MasqLoRA is explicitly designed to evade WEIGHT-DIFF inspection (the malicious update is rank-compatible with the legitimate one) and to pass BEHAVIORAL benchmarks. Diff-in-means looks at ACTIVATIONS, not weights: build contrastive prompt pairs (trigger present vs absent), compute mean activation difference per layer, look for directions that activate on trigger but are near-zero on benign input. A clean model has a small interpretable salient set (refusal, format, language); a backdoored model has EXTRA directions with no documented training signal."	c3::ft22::analysis
"Why should you re-derive quants and LoRAs from source rather than trust opaque community artifacts?"	"It eliminates the entire poisoned-quant and poisoned-adapter attack class by removing the opaque artifact from the trust chain. Take the published source weights (FP16/BF16), apply the published quantization recipe yourself (FT19) with pinned toolchain, and for LoRAs require published training data + recipe so you can re-derive. If you can't re-derive, you can't use it at IL5+."	c3::ft22::application
"What is the inbound-gate / pinned-mirror / verify-on-load trust boundary?"	"Never hf pull inside the trust boundary. (1) INBOUND GATE — a network-connected staging host (NOT the deployment host): pull, record hash, sign with org key, store in INTERNAL MIRROR. (2) TRANSFER — one-way media for air-gap, verified internal network for IL2–IL6. (3) VERIFY ON LOAD — recompute hash, verify signature, refuse to load if either fails. Converts 'trust HF' into 'trust our signing infra + trust HF only at the gate where we can inspect.'"	c3::ft22::application
"Why are behavioral evals (Step 4) necessary but not sufficient?"	"Promptfoo (prompt-injection/jailbreak/policy coverage) and Garak (NVIDIA's known-probe catalog) + your domain adversarial suite catch KNOWN failure modes and OBVIOUS backdoors. They do NOT catch a MasqLoRA-style attack designed to evade benchmarks. That's why Step 3 (activation probing) exists. Run them every time, on every artifact, before any IL4+ load."	c3::ft22::application
"Recite the four verbs of air-gapped deployment design."	"PRE-LOAD (every artifact — weights, tokenizer, system prompt, eval, deps — loaded before severance). SEVER (network disabled; ip link show = no carrier, no default route, DNS unresolvable; test continuously). BIND (server binds 127.0.0.1 or Unix socket, never 0.0.0.0; harness co-located, loopback only). LOG (append-only local store; prompt + generation + load + config; the regulator's evidence)."	c3::ft22::recall
"Why are llama.cpp and vLLM the right inference substrate for air-gap?"	"MINIMAL NETWORK POSTURE. llama-server is a single static binary — no container registry, no orchestrator, no service mesh, binds loopback by default — the most auditable inference server in the ecosystem. vLLM is more complex (Python/CUDA) but still single-process with a defined API surface; with a pinned mirror and frozen requirements.txt it's auditable. Neither is true of hosted closed-weight APIs — an API call is a network egress, incompatible with air-gap. The open-weights stack is not a cost choice at IL7+; it's the only choice that fits the architecture."	c3::ft22::analysis
"What is the CDAO closed-vendor gap?"	"CDAO's announced frontier-model partners (Anthropic, Google, OpenAI, xAI) are ALL closed-weight — API-only, weights and training data not published, none auditable at the weight level, none deployable on JWICS. If every authorized government model is closed-weight, every IL5+/air-gapped deployment is impossible by construction. The open-weights curriculum is the response."	c3::ft22::analysis
"What is the open-weights response to the CDAO gap (three parts)?"	"(1) Open-data models are AUDITABLE in a way closed models structurally cannot be — at IL5+/JWICS auditability is a deployment REQUIREMENT not a preference. (2) The capability gap is CLOSING — open frontier models within striking distance on most operational tasks; the fine-tuning in this course closes the residual gap on your specific task. (3) The SUPPLY CHAIN is the attack surface — closed API is trust dependency on publisher; verified open-data is trust dependency on your own process. Defense orgs have a strong prior toward the second."	c3::ft22::analysis
"What is the NTIA (2024) AI Open-Model Weights Report and why does it matter for FT22?"	"The U.S. government's own policy acknowledgment that open-weight models ENABLE sensitive-domain use cases that closed models cannot serve. It explicitly notes open-weights enable IL5+/air-gap deployments. FT22 is the engineering-side reading of that report — the policy says open enables sensitive domains; this module says HOW (open-data, re-derivability, the defensive playbook, air-gap architecture)."	c3::ft22::application
"Why is 'assuming open means safe' an anti-pattern?"	"Open-weights is NECESSARY for auditability at IL5+ but NOT SUFFICIENT. An open-weights model with a poisoned LoRA merged in is OPEN AND BACKDOORED. Open-data raises the floor (you can audit the corpus) but you still owe the five-step defensive playbook. 'It's open source' is not a security argument; it's the PRECONDITION for making a security argument."	c3::ft22::analysis
"Why is pulling directly from Hugging Face in production an anti-pattern?"	"hf pull on the deployment host, inside the trust boundary. Even if the artifact is benign TODAY, you have no guarantee it's benign TOMORROW — the hub is mutable, accounts are compromised regularly (ultralytics/stellar-freighter-class incidents), and your deployment has no way to detect a swap. Always pull at an inbound gate, sign, mirror, verify on load."	c3::ft22::application
"Why does no behavioral evals before deployment qualify as an anti-pattern?"	"'We ran the model on our task and it worked, so we shipped it.' Standard task-eval coverage is ~0% of the adversarial surface. Promptfoo and Garak exist for a reason; run them every time, on every artifact, before any IL4+ load. They are necessary, not sufficient — pair with activation probing (Step 3) because MasqLoRA-style attacks evade benchmarks by design."	c3::ft22::application
"What is CUI and why is it the dominant data class at IL4?"	"Controlled Unclassified Information — non-classified but sensitive (export-controlled technical data, PII, law-enforcement-sensitive material). IL4 = Moderate + DoD overlays. Most operational DoD AI appetite lives at IL4 because most operational data is CUI, not classified. NIPRNet."	c3::ft22::recall
"How does FT22 relate to FT21 (HIPAA) and FT17 (abliteration)?"	"FT21 made the open-data argument for HEALTHCARE; FT22 generalizes it to GOVERNMENT/DEFENSE and adds the IL ladder + air-gap architecture. FT17 used diff-in-means OFFENSIVELY (find the refusal direction so you can delete it — abliteration); FT22 reuses the SAME toolkit DEFENSIVELY (find unexpected steering directions a backdoor would implant). The toolkit is identical; the direction of use flips."	c3::ft22::analysis