Diagrams — Module FT02: The Open Spectrum

Module: FT02 — The Open Spectrum: Weights, Data, and Trust Diagram count: 5 Tool: Mermaid (primary). Each diagram validated in Mermaid Live Editor.

Diagram 1 — The Openness Spectrum (the module's central axis)

Type: Horizontal spectrum Purpose: The single diagram that defines the module. Three tiers, left to right, with representative families placed on the spectrum. Each step right adds a trust property. Reading the diagram: Left = you can only use it. Middle = you can audit what it saw. Right = you can reproduce and prove the whole thing. The arrow under each tier names the property that tier adds.

flowchart LR
  W["WEIGHTS-ONLY\nweights, no data\nLlama 3.1 · GPT-4o"]
  D["OPEN-DATA\nweights + corpus\nMiniCPM · OLMo · DCLM"]
  R["OPEN-RECIPE\nweights + data + code\nOLMo · Tulu 3 · SmolLM3"]

  W -->|"adds: auditability"| D
  D -->|"adds: reproducibility"| R

  style W fill:#14141f,stroke:rgba(255,255,255,0.12),color:#9494a0
  style D fill:#14141f,stroke:rgba(94,234,212,0.5),color:#e4e4e8
  style R fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8

Diagram 2 — The OSAID Gap (what it requires vs what reproducibility needs)

Type: Comparison with explicit gap Purpose: Show the deliberate distance between OSAID v1.0 compliance and actual reproducibility. This is the diagram that prevents the cardinal conflation ("OSAID-compliant = reproducible"). Reading the diagram: Left column = what OSAID requires. Right column = what reproducibility/auditability requires. The hatched middle region is the gap — the space where a Llama-style release can claim openness without being reproducible.

flowchart LR
  subgraph OSAID["OSAID v1.0 REQUIRES (2024-10-28)"]
    O1["Complete training/run code"]
    O2["'Sufficiently detailed information'\nABOUT the data\n(not the data itself)"]
    O3["Use / modify / redistribute rights"]
  end
  subgraph Gap["THE GAP"]
    G1["No data required\nNo license on data required\n'Substantially equivalent' undefined"]
  end
  subgraph REPRO["REPRODUCIBILITY / AUDITABILITY NEEDS"]
    R1["The actual training corpus\nor a reproducible pipeline"]
    R2["Hyperparameters, seeds,\noptimizer state, checkpoints"]
    R3["A determinable answer to:\n'was document X in the data?'"]
  end

  OSAID -.->|"compliant ≠ reproducible"| REPRO

  style OSAID fill:#14141f,stroke:rgba(94,234,212,0.5),color:#e4e4e8
  style Gap fill:#08080c,stroke:rgba(240,168,104,0.4),stroke-dasharray: 4 2,color:#f0a868
  style REPRO fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8

Diagram 3 — The Auditability Chain (open data → can audit → can prove to regulator)

Type: Linear causal chain Purpose: The three-link chain that justifies why open-data is a compliance asset in sensitive domains. Each link is a prerequisite for the next. Reading the diagram: Read left to right. Open-data is the input; the regulator's satisfied question is the output. Drop the left link and the whole chain fails — which is why weights-only/closed bases cannot satisfy the audit.

flowchart LR
  A["Open-data / open-recipe release\n(weights + corpus + code)"]
  B["You can AUDIT\nwhat the model saw"]
  C["You can REPRODUCE\n(pinned commit, rebuild on demand)"]
  D["You can PROVE to a regulator:\ndata lineage, no hidden inputs,\nno silent drift"]

  A --> B --> C --> D

  style A fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style B fill:#14141f,stroke:rgba(94,234,212,0.6),color:#e4e4e8
  style C fill:#14141f,stroke:rgba(94,234,212,0.6),color:#e4e4e8
  style D fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#5eead4

Diagram 4 — The Model Family Comparison (table-as-diagram)

Type: Tiered comparison table Purpose: The eight releases mapped to their tier, with the auditability verdict in the rightmost column. This is the reference table for the lab and the exam. Reading the diagram: Top = open-recipe (auditable). Middle = open-data / partial. Bottom = weights-only / closed (not auditable). The right column is the question a HIPAA/IL6 assessor asks.

flowchart TB
  subgraph R["OPEN-RECIPE — auditable: YES"]
    R1["OLMo 2 (Ai2) · Apache-2.0 · data+code+checkpoints"]
    R2["Tulu 3 (Ai2) · Apache-2.0 · full post-train recipe"]
    R3["SmolLM3 (HF) · Apache-2.0 · pre/mid/post + synth"]
    R4["MiniCPM (OpenBMB) · Apache-2.0 · Ultra* datasets"]
    R5["DCLM · open · data pipeline released"]
  end
  subgraph P["OPEN-WEIGHTS / PARTIAL — auditable: PARTIAL"]
    P1["Nemotron (NVIDIA) · NVIDIA OML · post-train data documented"]
  end
  subgraph W["WEIGHTS-ONLY — auditable: NO"]
    W1["Llama 3.1 incl. 405B (Meta) · Llama Community Lic. · data described only"]
  end
  subgraph C["CLOSED — auditable: NO"]
    C1["GPT-4o (OpenAI) · proprietary · API only, weights withheld"]
  end

  R --> P --> W --> C

  style R fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style P fill:#14141f,stroke:rgba(240,168,104,0.5),color:#e4e4e8
  style W fill:#14141f,stroke:rgba(255,255,255,0.12),color:#9494a0
  style C fill:#14141f,stroke:rgba(255,255,255,0.12),color:#9494a0

Diagram 5 — Why Open-Data Wins for Sensitive Domains (the NTIA argument)

Type: Two-track comparison (closed API vs open-weight on-prem) Purpose: Visualize the NTIA report's core security-benefit claim: open weights let sensitive data stay inside your trust boundary; closed APIs force it to leave. This is the diagram to put in a procurement document. Reading the diagram: Top track = closed API. Sensitive data leaves the boundary at every inference. Bottom track = open-weight (and ideally open-data) on-prem. Sensitive data never leaves. The annotation is the NTIA citation.

flowchart TB
  subgraph Closed["CLOSED API TRACK (e.g. GPT-4o)"]
    direction LR
    U1["Sensitive data\n(PHI / IL5 / classified)"]
    N1["Leaves trust boundary\nevery inference"]
    V1["Vendor infra:\ndata-handling, logging,\nretention = vendor's word"]
    U1 --> N1 --> V1
  end
  subgraph Open["OPEN-WEIGHT ON-PREM TRACK (e.g. MiniCPM, OLMo)"]
    direction LR
    U2["Sensitive data\n(PHI / IL5 / classified)"]
    B2["Stays inside trust boundary\n(SCIF / air-gap / on-prem)"]
    M2["Model + open recipe:\ndata lineage auditable,\nno hidden inputs"]
    U2 --> B2 --> M2
  end

  NTIA["NTIA 2024: open weights 'provide security benefits\nby allowing firms, researchers, and users to use\npotentially sensitive data' locally / on-premises"]
  Open --> NTIA

  style Closed fill:#14141f,stroke:rgba(240,128,128,0.4),color:#9494a0
  style Open fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8
  style NTIA fill:#08080c,stroke:rgba(94,234,212,0.4),stroke-dasharray: 4 2,color:#5eead4
  style N1 fill:#08080c,stroke:rgba(240,128,128,0.5),color:#f08080
  style B2 fill:#08080c,stroke:rgba(94,234,212,0.5),color:#5eead4

Validation notes

All five diagrams use the course design system colors: #14141f panel fill, #5eead4 accent for primary, rgba(255,255,255,0.12) for secondary borders, #e4e4e8 / #9494a0 for text. The warn/danger tones (#f0a868 / #f08080) are used deliberately to mark the OSAID gap and the closed-API data-egress node.
Paste each into Mermaid Live Editor to render. All use stable Mermaid syntax (flowchart LR/TB, subgraph) supported in current Mermaid (v10.4+).
For the slide deck (artifact 03), these are rendered as static SVG/PNG captures from Mermaid Live, inlined into reveal.js.

# Diagrams — Module FT02: The Open Spectrum **Module**: FT02 — The Open Spectrum: Weights, Data, and Trust **Diagram count**: 5 **Tool**: Mermaid (primary). Each diagram validated in [Mermaid Live Editor](https://mermaid.live). --- ## Diagram 1 — The Openness Spectrum (the module's central axis) **Type**: Horizontal spectrum **Purpose**: The single diagram that defines the module. Three tiers, left to right, with representative families placed on the spectrum. Each step right adds a trust property. **Reading the diagram**: Left = you can only *use* it. Middle = you can *audit* what it saw. Right = you can *reproduce and prove* the whole thing. The arrow under each tier names the property that tier adds. ```mermaid flowchart LR W["WEIGHTS-ONLY\nweights, no data\nLlama 3.1 · GPT-4o"] D["OPEN-DATA\nweights + corpus\nMiniCPM · OLMo · DCLM"] R["OPEN-RECIPE\nweights + data + code\nOLMo · Tulu 3 · SmolLM3"] W -->|"adds: auditability"| D D -->|"adds: reproducibility"| R style W fill:#14141f,stroke:rgba(255,255,255,0.12),color:#9494a0 style D fill:#14141f,stroke:rgba(94,234,212,0.5),color:#e4e4e8 style R fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8 ``` --- ## Diagram 2 — The OSAID Gap (what it requires vs what reproducibility needs) **Type**: Comparison with explicit gap **Purpose**: Show the deliberate distance between OSAID v1.0 compliance and actual reproducibility. This is the diagram that prevents the cardinal conflation ("OSAID-compliant = reproducible"). **Reading the diagram**: Left column = what OSAID requires. Right column = what reproducibility/auditability requires. The hatched middle region is the gap — the space where a Llama-style release can claim openness without being reproducible. ```mermaid flowchart LR subgraph OSAID["OSAID v1.0 REQUIRES (2024-10-28)"] O1["Complete training/run code"] O2["'Sufficiently detailed information'\nABOUT the data\n(not the data itself)"] O3["Use / modify / redistribute rights"] end subgraph Gap["THE GAP"] G1["No data required\nNo license on data required\n'Substantially equivalent' undefined"] end subgraph REPRO["REPRODUCIBILITY / AUDITABILITY NEEDS"] R1["The actual training corpus\nor a reproducible pipeline"] R2["Hyperparameters, seeds,\noptimizer state, checkpoints"] R3["A determinable answer to:\n'was document X in the data?'"] end OSAID -.->|"compliant ≠ reproducible"| REPRO style OSAID fill:#14141f,stroke:rgba(94,234,212,0.5),color:#e4e4e8 style Gap fill:#08080c,stroke:rgba(240,168,104,0.4),stroke-dasharray: 4 2,color:#f0a868 style REPRO fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8 ``` --- ## Diagram 3 — The Auditability Chain (open data → can audit → can prove to regulator) **Type**: Linear causal chain **Purpose**: The three-link chain that justifies why open-data is a *compliance asset* in sensitive domains. Each link is a prerequisite for the next. **Reading the diagram**: Read left to right. Open-data is the input; the regulator's satisfied question is the output. Drop the left link and the whole chain fails — which is why weights-only/closed bases cannot satisfy the audit. ```mermaid flowchart LR A["Open-data / open-recipe release\n(weights + corpus + code)"] B["You can AUDIT\nwhat the model saw"] C["You can REPRODUCE\n(pinned commit, rebuild on demand)"] D["You can PROVE to a regulator:\ndata lineage, no hidden inputs,\nno silent drift"] A --> B --> C --> D style A fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8 style B fill:#14141f,stroke:rgba(94,234,212,0.6),color:#e4e4e8 style C fill:#14141f,stroke:rgba(94,234,212,0.6),color:#e4e4e8 style D fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#5eead4 ``` --- ## Diagram 4 — The Model Family Comparison (table-as-diagram) **Type**: Tiered comparison table **Purpose**: The eight releases mapped to their tier, with the auditability verdict in the rightmost column. This is the reference table for the lab and the exam. **Reading the diagram**: Top = open-recipe (auditable). Middle = open-data / partial. Bottom = weights-only / closed (not auditable). The right column is the question a HIPAA/IL6 assessor asks. ```mermaid flowchart TB subgraph R["OPEN-RECIPE — auditable: YES"] R1["OLMo 2 (Ai2) · Apache-2.0 · data+code+checkpoints"] R2["Tulu 3 (Ai2) · Apache-2.0 · full post-train recipe"] R3["SmolLM3 (HF) · Apache-2.0 · pre/mid/post + synth"] R4["MiniCPM (OpenBMB) · Apache-2.0 · Ultra* datasets"] R5["DCLM · open · data pipeline released"] end subgraph P["OPEN-WEIGHTS / PARTIAL — auditable: PARTIAL"] P1["Nemotron (NVIDIA) · NVIDIA OML · post-train data documented"] end subgraph W["WEIGHTS-ONLY — auditable: NO"] W1["Llama 3.1 incl. 405B (Meta) · Llama Community Lic. · data described only"] end subgraph C["CLOSED — auditable: NO"] C1["GPT-4o (OpenAI) · proprietary · API only, weights withheld"] end R --> P --> W --> C style R fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8 style P fill:#14141f,stroke:rgba(240,168,104,0.5),color:#e4e4e8 style W fill:#14141f,stroke:rgba(255,255,255,0.12),color:#9494a0 style C fill:#14141f,stroke:rgba(255,255,255,0.12),color:#9494a0 ``` --- ## Diagram 5 — Why Open-Data Wins for Sensitive Domains (the NTIA argument) **Type**: Two-track comparison (closed API vs open-weight on-prem) **Purpose**: Visualize the NTIA report's core security-benefit claim: open weights let sensitive data stay inside your trust boundary; closed APIs force it to leave. This is the diagram to put in a procurement document. **Reading the diagram**: Top track = closed API. Sensitive data leaves the boundary at every inference. Bottom track = open-weight (and ideally open-data) on-prem. Sensitive data never leaves. The annotation is the NTIA citation. ```mermaid flowchart TB subgraph Closed["CLOSED API TRACK (e.g. GPT-4o)"] direction LR U1["Sensitive data\n(PHI / IL5 / classified)"] N1["Leaves trust boundary\nevery inference"] V1["Vendor infra:\ndata-handling, logging,\nretention = vendor's word"] U1 --> N1 --> V1 end subgraph Open["OPEN-WEIGHT ON-PREM TRACK (e.g. MiniCPM, OLMo)"] direction LR U2["Sensitive data\n(PHI / IL5 / classified)"] B2["Stays inside trust boundary\n(SCIF / air-gap / on-prem)"] M2["Model + open recipe:\ndata lineage auditable,\nno hidden inputs"] U2 --> B2 --> M2 end NTIA["NTIA 2024: open weights 'provide security benefits\nby allowing firms, researchers, and users to use\npotentially sensitive data' locally / on-premises"] Open --> NTIA style Closed fill:#14141f,stroke:rgba(240,128,128,0.4),color:#9494a0 style Open fill:#14141f,stroke:#5eead4,stroke-width:1.5px,color:#e4e4e8 style NTIA fill:#08080c,stroke:rgba(94,234,212,0.4),stroke-dasharray: 4 2,color:#5eead4 style N1 fill:#08080c,stroke:rgba(240,128,128,0.5),color:#f08080 style B2 fill:#08080c,stroke:rgba(94,234,212,0.5),color:#5eead4 ``` --- ## Validation notes - All five diagrams use the course design system colors: `#14141f` panel fill, `#5eead4` accent for primary, `rgba(255,255,255,0.12)` for secondary borders, `#e4e4e8` / `#9494a0` for text. The warn/danger tones (`#f0a868` / `#f08080`) are used deliberately to mark the OSAID gap and the closed-API data-egress node. - Paste each into [Mermaid Live Editor](https://mermaid.live) to render. All use stable Mermaid syntax (`flowchart LR/TB`, `subgraph`) supported in current Mermaid (v10.4+). - For the slide deck (artifact 03), these are rendered as static SVG/PNG captures from Mermaid Live, inlined into reveal.js.