9 min read - Open-Weight AI Provenance: Track Ancestry and Runtime Separately

An open-weight model can arrive with a model card, a familiar family name and a licence declaration. Those details still do not tell an operator exactly what ran in production, under which policy, or which tools it called. The reverse is also true. A signed execution record says little about the datasets, base models and modifications behind the weights.

Two announcements published within a day of each other make that distinction useful now. On 26 August 2026, the CNIL released an updated Genmod demonstrator for exploring ancestors and descendants of open-weight models on Hugging Face. The new version automates weekly data refreshes, improves graph searches and adds an English interface. On 25 August, the Linux Foundation announced that it had accepted TRACE, an open specification for hardware-attested records of AI workloads.

These projects address different questions. Genmod explores where a model may have come from and what may have descended from it. TRACE describes evidence about a particular run. Treating both as one generic "AI provenance" field creates a record that sounds complete while answering neither question well.

One word hides two evidence problems

Model provenance is often reduced to a vendor name and model identifier. That may be enough for an early prototype. It becomes fragile when a team downloads weights, changes a tokenizer, applies an adapter, merges checkpoints, converts the quantisation format or republishes the result under an internal name.

The first evidence problem is ancestry. Which exact artefact did the team receive? What declared base model, datasets and modifications sit behind it? Which licence and usage conditions applied to the retrieved revision? If a source artefact changes, which internal derivatives need review?

The second problem is execution. Which model digest actually ran? Where did it run, which policy version applied, what class of data entered the workload and which external tools were called? A deployment can keep the same model name while changing any of those facts.

The owners and change events differ. Model teams curate ancestry; platform and security teams produce execution evidence. Reviewers may need both records, without having to reconstruct them from a slide deck.

Record model ancestry before approval

The CNIL describes open-weight models as artefacts that people can download, modify, fine-tune, combine and release again. Its Genmod demonstrator uses public Hugging Face data to explore a model's ancestors and descendants. The live CNIL space labels the project as a beta and an experiment in mediation and transparency.

That is a useful discovery aid, not a substitute for an organisation's own inventory. Public metadata can change, links can disappear and an internal fine-tune may never be published. Capture the record when the artefact enters the delivery process.

Do not fill an unknown field with an assumption. "Not declared by publisher" is more useful than a plausible guess because it tells the reviewer what still needs investigation. Keep copies or durable references where licence and contract terms permit it.

The record makes a replaced checkpoint, retrained adapter or changed data source visible. Our guide to production dependency upgrade gates applies the same principle to software packages: the version change starts a review; it does not finish one.

Record what happened during execution

TRACE takes a different route. Its current documentation defines a Trust Record that can bind a model identifier and weight digest to a runtime measurement, policy hash, data class and tool-call transcript. Higher trust levels use hardware attestation so a verifier does not have to accept an operator-written log at face value.

The specification is a developer preview at version 0.2. That status matters. It is a useful design reference and an option for controlled evaluation, not a reason to declare an existing system compliant or ready for sensitive work.

A small team can start with a vendor-neutral execution schema before choosing any attestation technology:

This record should avoid becoming a second store of prompts, personal data or secrets. Store identifiers, classifications, hashes and carefully scoped event details. Link to protected evidence only when an investigation or audit needs it, with access and retention defined for that system.

Four changes that reopen the decision

Separate records make reassessment more precise. A new model revision reopens the ancestry review and requires a new runtime binding. Moving an unchanged model to another runtime primarily reopens execution controls, although data location and contractual questions may also change. A new fine-tune creates a new artefact with its own ancestry and evaluation. Adding a tool to an agent changes the possible actions, so policy and runtime evidence need review even if the model digest stays fixed.

Use an event table instead of an annual questionnaire:

"Check impact" is intentional. It means that a named owner decides whether the record changes and leaves the reason behind. It is not an automatic exemption.

Start with one use case, not a provenance platform

For an SME or a product team, the practical first move is modest. Pick one open-weight workload that matters, such as document classification or an internal retrieval assistant. Give the model artefact an owner and record its exact revision, digests, declared ancestry, licence source and evaluation decision. Then bind the deployed digest to the release, policy, data class and allowed tools.

Ask a reviewer who did not build the system to answer two questions within a fixed time: where did these weights come from, and what ran for this production release? Missing links and confusing names become the backlog. Compare specialist products or attestation methods only after that exercise. A large platform cannot repair unclear ownership or an unpinned model. For broader architecture, policy and operating-model work, connect the review to the organisation's AI integration and Custom Engineering decisions.

Where the current tools stop

The CNIL tool explores public Hugging Face metadata. It does not prove that a publisher's declarations are complete, that personal data exists in a model, or that a particular organisation has met its legal duties. The CNIL presents the project as an experiment intended to study traceability and the possible exercise of data rights.

TRACE documents equally important boundaries. Its known-limitations page says that a policy hash proves which policy was in force, not whether the policy was good. A tool transcript does not reveal internal model reasoning or prove exact data flow between calls. Software-only Level 0 records can be forged by a privileged operator, while hardware attestation still does not remove side-channel, key-revocation or replay concerns.

The honest conclusion is less dramatic than a compliance badge. Ancestry metadata, signed runtime records, evaluations and human approvals are separate pieces of evidence. Each can reduce uncertainty within its scope. None should borrow certainty from the others.

Questions for the next model review

1. Can you identify the exact weights in production without relying on the model's display name?
2. Which ancestry fields come from the publisher, and which have you verified?
3. What event forces the review to reopen after a fine-tune or model swap?
4. Can an independent reviewer match a production run to its model, policy and permitted tools?
5. Which evidence contains personal data or secrets, and what governs its access and deletion?
6. Where does the record state uncertainty instead of hiding it?

If the answers live in several people's memories, start with the register.

Sources and limitations

• The CNIL's 26 August 2026 Genmod update describes the demonstrator's ancestry graph, weekly public-data refresh, search changes and experimental purpose.
• The CNIL Hugging Face organisation page identifies the live beta, its public metadata fields and its intended use.
• The Linux Foundation's 25 August 2026 announcement records the contribution and stated scope of TRACE.
• The TRACE v0.2 documentation supplies the claim fields, developer-preview status and verification model discussed here.
• The project's known limitations define what its records do not establish and where other controls remain necessary.

Both projects are moving. Genmod depends on public Hugging Face data, while TRACE v0.2 is a developer preview. Verify current documentation before using either in a production decision. This article offers an operating model, not a legal opinion, privacy assessment, certification or product endorsement.

Keep provenance and runtime records separate

The CNIL update makes model family trees easier to inspect. TRACE proposes a way to make facts about a specific run independently checkable. That is useful because the two records should never have been collapsed.

Track where the artefact came from and what the deployed system did. Join the records with digests and owners, then keep their claims and limits separate.