The Model-Lineage Delta

Before the detail — Artifact: the ML-BOM plus a verification log, accepted when it validates and every digest is real. Status of what follows: guidance (G7 / CISA minimum elements); binding only where a contract says so.

Prompt first: draft the component list, compute nothing

Here is the inventory entry for MU-AI-004 [paste] and the corpus
manifest [paste scripts/t6-corpus/manifest.lock.json].

Draft the ML-BOM COMPONENT LIST for MU-AI-004 as CycloneDX 1.6
(the version the substrate's generator library emits; the 1.7
model-card block is identical)
components:
  - the application: name, version, inventory id as a property
  - the served model: type machine-learning-model; name,
    identifier, version, timestamp, producer, hash, training
    properties, license - values only where the text states them
  - the CPU fallback weights file: the same fields
  - the corpus and the sealed evaluation set: type data
  - a modelCard block: modelParameters, quantitativeAnalysis,
    considerations present, sub-fields EMPTY

Do NOT compute, recall, or guess any hash, digest, timestamp, or
license. Every hash is NEEDS-OWNER until computed on the build host.

The hash is the field an agent most fluently invents — sixty-four hexadecimal characters look like a hash whether or not any file produced them. Every hash stays NEEDS-OWNER until P. Delgado, who owns MU-AI-004, computes it on the host that will load the file.

Five deltas, and the pointers

Every mechanism here is a pointer. DevSecOps 5.1 (a separate training in this series): hash it, verify it, promote it. DevSecOps 5.2: provenance and SBOM. Federal Delivery 3.2: the evidence store you can defend. Federal Delivery 4.2: SBOM as evidence. Those own hashing, signing mechanics, SBOM (the list of what software a build contains) generation, and the store the lineage line lands in. What is new about weights is five things.

The ML-BOM and its model card

The ML-BOM (a bill of materials listing models and datasets) is an SBOM with model and dataset components and a model-card block. CycloneDX 1.7, published October 2025, is the current specification; its model card has three parts — model parameters, quantitative analysis, considerations — unchanged from 1.6, so the same model-card block is valid inside a 1.6 or a 1.7 document — though each document validates only against its own version’s schema. A buyer records per model: name, identifier, version, timestamp, producer, hash, training properties, license.

The substrate wart, declared: the generator script in scripts/t7-substrate/bom/ uses the bill-of-materials generator library, which ships the schema with modelCard but exposes no model-card class. The script therefore merges the model-card block into the JSON after serialization and validates the file a second time, strictly, against the 1.6 schema. The script says so in its own docstring, and so does this lesson: a hidden hand-merge teaches that the generator produced the card. A person did; the second validation proves the file’s shape, not its truth — the digests inside it are what a reviewer checks, and a digest the generator could not read from the fetch manifest is written as NEEDS-OWNER, never invented.

The artifact no scanner reads

A vulnerability scanner matches package names and versions against a published database; a weights file has neither, so the scanner passes it. A swapped file never shows in a scan; a reference digest taken at acquisition and verified before load catches substitution. Nothing in a hash or a signature detects poisoning — that is Modules 3 and 4’s work.

Some weight formats execute code when a library opens them. Prefer the safe tensor format, which stores nothing that executes; where a file arrives in an unsafe format, a scanner pass is not a safety claim — the bypasses published against a widely used serialization scanner in September 2025, since patched, are the evidence.

Some open-weights licenses carry use restrictions that must flow down to anything built on the weights. The license is a recorded field with its source; one the reviewer cannot read is NEEDS-OWNER for counsel.

The risk is contract risk: a license that forbids Meridian’s use, discovered after release, is an exit on the licensor’s terms.

What a signature proves

A model signing tool signs the weights file; verification, run before load, checks the file is the one signed. A verified signature proves origin — the named key signed this file — and integrity — the bytes are unchanged. It proves nothing about fitness: a signed model can be poisoned, biased, or under a license Meridian cannot accept. And key-based signing — a key Meridian or the producer holds — is not transparency-log-backed (a public, append-only record an outsider can check); the record names which it has.

A verification log per load turns “we believe it is the right file” into a checkable line.

Commercial SBOM, federal minimum elements

The commercial starting practice is the SBOM every build produces and stores with the release. The federal delta is minimum elements for AI: the G7 cyber agencies’ “Software Bill of Materials for Artificial Intelligence — Minimum Elements” (May 2026, published by seven G7 cyber agencies including Germany’s BSI and CISA), which name the buyer’s fields above; CISA’s (the federal cyber agency’s) “2026 Minimum Elements for a Software Bill of Materials (SBOM)” (published July 29 2026), which defer AI to that G7 document; and the explanatory statement accompanying the FY2026 defense authorization act (signed December 18 2025), which says the department’s SBOM policy should apply to AI where feasible — all three published guidance, none a contract clause — under the frame Lesson 1.4 declared, the task order for the one federal use case is where any of that arrives. The handoff artifact is the ML-BOM JSON plus the signature verification log. Not equivalent: the minimum elements are guidance, not a procurement clause; and the model card inside a bill of materials is not the vendor transparency packet of Lesson 2.1 — a buyer’s fields versus a vendor’s claims.

Stop and escalate when a weights file arrives in an unsafe format from a source that cannot supply a safe one, or under a license the reviewer cannot read — do not load it into anything holding credentials or Meridian data; record both as findings for the risk acceptor and counsel.

Practice status — among organizations running open-weights models, commercial and federal

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

Weights change five things about a practice you already run: the bill of materials gains a model card, with the hand-merge declared; the weights are an artifact no scanner reads; unsafe formats run code on load, and a scanner pass is not a safety claim; the license is a recorded field whose restrictions flow down; and a verified signature proves origin and integrity, never fitness. The minimum elements are guidance, not a clause. Module 3 turns to evaluation on Meridian’s own terms.

LEADERSHIP DECISION   fund one validated bill of materials per
                      open-weights system and a verify-before-load
                      step; refuse a second supply-chain program
PRACTITIONER ACTION   list components, compute hashes on the host,
                      record format and license, merge the model
                      card and re-validate
SUCCESS MEASURE       audit finding avoided - every model in production
                      has a recorded hash, license, format, and a
                      signature verify log that resolves