Cryptographic Provenance for Adapters
The report corpus repeatedly points to adapters as small, portable, high-leverage artifacts. Cryptographic provenance does not prove safety, but it makes identity, lineage, and unauthorized alteration observable.
Required records
Each adapter should have a content hash, signature, base-family compatibility record, tensor schema, tokenizer compatibility, training recipe summary, source registry, license status, safety-evaluation record, and known composition restrictions.
Allowed-list governance
Routers and merge tools should only load adapters whose identities are on an explicit allowed list for that deployment context. The allowed list is a policy artifact and must itself be versioned, signed, and reviewed.
Limit
Provenance is not behavioral inheritance. A signed unsafe adapter is still unsafe. A signed component can still become unsafe in an untested stack. Provenance tells us what we loaded; it does not tell us everything the composition can do.