Should Machine Learning Projects Create Dated Evidence?

Should Machine Learning Projects Create Dated Evidence?

Short answer: often yes, but in proportion to the risk. If your project could face questions about what data you trained on, what your model looked like at a given point, or who had what first, then a small, cheap habit of recording tamper-evident, dated fingerprints of key artifacts is worth it. If you're running throwaway experiments on public benchmarks, it's probably overkill.

"Dated evidence" here means a record showing that a specific file, dataset snapshot, model checkpoint or results report existed in exactly that form at or before a particular moment, in a way that someone other than you can check. It doesn't show that the model is good, that you own it, or that you built it. We'll come back to that, because it's where most confusion sits.

Why ML projects are unusually exposed?

Software teams have long lived with version control and build logs. ML projects have a messier problem. The thing you ship is a product of code, data, configuration, random seeds and compute, and any of those can change quietly. Datasets get cleaned and re-cleaned. Checkpoints get overwritten. Someone retrains on a new scrape and the old one is deleted to save disk space.

Then, months later, somebody asks a question:

* A customer or regulator asks what data a deployed model was trained on.

* A rights holder claims their material was in your corpus.

* A research collaborator disputes which results came first.

* An auditor wants to see the state of the system when a decision was made.

* Your own team can't reproduce last quarter's numbers.

In all of these, "we're pretty sure" is a weak answer. A record made at the time is a much better one.

The regulatory pull, with the right caveats

The EU AI Act is the clearest example of the direction of travel. For providers of high-risk AI systems, Article 11 requires technical documentation (with minimum content set out in Annex IV), Article 12 requires systems to support automatic event logging, and Article 18 requires the technical documentation to be kept available to national authorities for ten years after the system is placed on the market or put into service.

What's actually worth dating?

You don't need to timestamp everything. Think about which artifacts would be hardest to reconstruct and most awkward to be unable to show.

* Dataset snapshots or manifests. The exact set of files, or records, used for a training run.

* Training configuration. Hyperparameters, seeds, preprocessing settings, the commit of the training code.

* Model checkpoints and final weights. Particularly the version you deployed or published.

* Evaluation results. The report, including the test set version and the date of the run.

* Data licensing or consent records. The terms you were relying on when you collected the data.

* Model cards and documentation. What you said about the system at release time.

A reasonable rule of thumb: date the things you'd be asked about in a dispute or an audit, at the moments they become final.

Why Git history alone isn't enough?

Many teams assume their repository is the evidence. It's useful, but it has limits that are easy to overlook.

Git commits are content-addressed, which means a commit hash changes if the content or history changes. That's a real integrity property. But the date attached to a commit is metadata that the committer sets, and it can be set to almost anything, including by rewriting history before pushing. A hosting platform's own records can help, but then you're trusting that platform, and the platform's logs are not something you control or can hand to a third party as independent proof.

There's also the practical gap: large datasets and model weights usually don't live in Git at all. They sit in object storage or in a tool like DVC or MLflow, where "last modified" timestamps can change when files are copied, restored or migrated.

So your internal records tell you what you believe happened. An external timestamp lets someone else check one narrow fact without taking your word for it: that a specific fingerprint existed by a specific time.

How to do it without building a bureaucracy?

The trick is to avoid hashing everything individually. Instead:

1- Create a manifest. At a milestone, generate a plain text file listing each important artifact, its SHA-256 hash, its size and its path or version. For a dataset, that might be a list of file hashes. For a training run, it might include the dataset manifest's hash, the code commit, the config file's hash and the checkpoint's hash.

2- Hash the manifest. Because the manifest includes the hashes of everything it references, changing any underlying file changes the manifest's hash.

3- Timestamp the manifest's hash. One record now covers the whole set.

4- Store the manifest and the proof together. Keep them with the run's metadata, and keep the original files in your normal storage.

This works with any tool that can anchor a single hash. It also keeps the work proportionate: one extra step at each milestone rather than a new process for every file.

One caution on privacy. A hash isn't the file, but if your files contain personal data, speak to your data protection lead before deciding what goes into manifests and where they're kept. Hashing is a good way to avoid sharing the underlying data, but it isn't a substitute for a privacy assessment.

What a timestamp can't tell you

This is the part that gets skipped in most writing on the subject, so it's worth being blunt.

A timestamp record shows that a particular digital fingerprint existed at or before a recorded time. It does not show:

* who created the file or trained the model

* that you own the data or the weights

* that the data was lawfully collected

* that the model is accurate, fair or safe

* that the manifest was an honest description of the files it lists

* that a court in any given jurisdiction will accept it

That last point deserves a note. Under the EU's eIDAS Regulation, Article 41 says an electronic time stamp can't be denied legal effect solely because it's electronic or doesn't meet the requirements of a qualified electronic time stamp, while qualified time stamps benefit from a presumption of accuracy of the date and time. A blockchain-anchored timestamp is not automatically a qualified time stamp. How much weight any record carries depends on the jurisdiction, the type of proceeding and the surrounding evidence.

A timestamp is one piece of a record. It gets stronger when it sits alongside version control history, access logs, signed commits and written documentation.

When it isn't worth it?

Be honest about the cost. If you're experimenting on public datasets with published licences, in a project with no commercial or regulatory exposure, the main benefit is tidy reproducibility, and your existing tooling probably covers that. The same goes for early prototypes you expect to discard.

The case gets stronger when any of these apply: you're training on data you license or scrape under specific terms, you're deploying into regulated settings, you collaborate across organizations where credit matters, or you may someday need to show a customer or auditor what a past version looked like.

A hypothetical example

This is an illustration, not a real case.

A small team fine-tunes a classification model on a licensed corpus. At the end of each training run, a script writes a manifest containing the hash of the corpus snapshot, the config file, the code commit and the final checkpoint. The hash of that manifest is anchored, and the proof is saved in the run's metadata folder.

Fourteen months later, a licensor asks whether a particular batch of documents was part of the version of the corpus used for the production model. The team produces the manifest, shows that its hash matches the anchored record, and shows that the corpus snapshot listed in it matches the files they retained. They haven't proven the licence terms were respected. But they've shown, with evidence they didn't create after the fact, what the training set looked like at that time. That's a much better position than reconstructing it from memory.

How Certelo approaches this?

Certelo calculates the SHA-256 hash locally, in your browser, so the original file stays on your device and isn't uploaded just to create the record. The hash is then anchored to the Electra Protocol blockchain, which gives you a record that can be checked independently of Certelo's own database.

For ML work, the local hashing matters because the artifacts are often sensitive or large: proprietary training data, unreleased weights, internal evaluation sets. With the manifest approach above, the only thing you need to handle in the tool is one small text file.

EDITOR: add verified details on supported file sizes and hashing performance in the browser, and a real screenshot of the verification result, before publishing. Do not state limits that haven't been tested.

Certelo isn't an ML experiment tracker and doesn't replace MLflow, DVC, model cards or a proper governance process. It handles one narrow job in that stack: giving you a dated fingerprint that doesn't depend on you or your infrastructure.

How to verify a record later?

When someone needs to check, the process is simple in principle. Take the manifest and recompute its SHA-256 hash. Confirm it matches the hash in the blockchain record. Then recompute the hashes of the files the manifest lists and confirm they match. If the files were changed in any way, even by a single byte, the hashes won't match. If the manifest's hash matches the anchored record, the manifest existed in that form by the recorded time.

Frequently Asked Questions

Does the EU AI Act require me to timestamp my training data?

Not in so many words. For high-risk systems, it requires technical documentation, event logging and long retention of documentation. Whether and how to use timestamps to support those records is a design decision, and whether the Act applies to you at all is something to confirm with legal counsel.

Is Git history good enough to show when a model existed?

It's useful but limited. Commit dates can be set by the committer, and large datasets and weights usually sit outside the repository. An independent timestamp adds a check that doesn't rely on your own systems.

Do I need to timestamp every checkpoint?

No. Timestamp milestone artifacts: the dataset snapshot used for a release, the final or deployed weights, and the evaluation report. Intermediate checkpoints rarely need it.

Can I timestamp a dataset without uploading it?

Yes, if the tool hashes locally. With Certelo, the SHA-256 hash is generated in the browser, and the original file isn't uploaded to create the record.

Does a timestamp prove I own the model or the data?

No. It shows a fingerprint existed by a certain time. Ownership, authorship and licensing are separate questions.

What happens if I change one file in the dataset afterwards?

The file's hash changes, so it no longer matches the manifest, and the manifest's own hash would change too if you updated it. That's the point: the original record continues to describe the original state.

Is this the same as C2PA or content credentials?

No. C2PA is focused on provenance information attached to media content. A hash timestamp is a lower-level record of existence at a time, and the two can be complementary.

The practical takeaway

Make dated evidence a small, boring habit at the milestones that matter: a manifest, a hash, a record. Don't oversell what it proves. Done that way, it costs almost nothing and gives you something that your own logs can't: a record other people can check without trusting you.

Two clarifications matter here. First, these obligations apply to specific categories of AI systems and roles, so whether they apply to your project is a legal question, not something a blog post can settle. Second, none of these articles say "use a blockchain timestamp." They require documentation and logs. A trusted timestamp is one way of making some of that documentation more credible, not a compliance checkbox.

If the regulatory angle is relevant to you, talk to a lawyer who works on AI regulation. Treat anything in this article as background, not advice.