Refresh and maintenance terms for a dataset you will keep using

Three operations hide behind the word refresh

Vendors and buyers both say refresh and mean different things, and the difference is where the cost sits. Separate the three before the first request goes out, because a vendor quoting an extend will be surprised by a revise.

An extend adds material under the same recipe: new speakers, new sessions, same guideline, same equipment. It is usually the cheapest and the fastest, because nothing is redesigned. An update records the same population again to reduce drift — new devices, new environments, new vocabulary that has entered the language since the first batch — and its value depends on how fast your deployment conditions move. A revise re-annotates the existing audio under a new guideline, typically because the first one turned out to be ambiguous on a category that matters. It is the most expensive of the three and the one most often quoted as if it were an extend.

Define a version by its inputs, and keep the old ones usable

Two datasets with the same name and the same hour count can be different products, and the difference only shows up in a model's error rate. A version is defined by its inputs, and those belong in the delivery manifest: the specification revision, the guideline revision, the speaker roster, the equipment and recording conditions, the annotation tooling, and the collection window.

The reason to insist on this is reproducibility. When a model trained on edition two behaves worse than one trained on edition one, the manifest is the only way to find out what changed. Without it the comparison is guesswork, and the fix is a full re-collection.

Buyers assume older editions stay usable. Sometimes the licence says otherwise: rights are granted to the current edition, or the term runs from the latest delivery, or a new delivery terminates the previous grant. Each of those turns a routine refresh into a decision about whether the model in production has to be retrained.

Write three things. The licence to a delivered edition is perpetual and independent, so a later delivery does not revoke it. Versions can be pinned, meaning you may keep training on a named edition indefinitely and the vendor must retain its manifest and checksums. And no silent replacement: a new edition is a new item, not an update that overwrites the previous one.

Trigger the refresh on events, not on the calendar

A schedule written as quarterly produces deliveries that arrive when nothing has changed and gaps when something has. Tie the obligation to triggers instead, and list them in the agreement: a model release cycle that needs fresh evaluation material, an error analysis that identifies a slice the current data does not cover, a change in the deployment environment such as a new device or a new market, and the expiry of speaker consents granted for a fixed term.

Two of those deserve their own clause. Consent expiry is a legal trigger — when the term on a set of speaker grants ends, that material has to leave the training pool, and the clause should say who notices and by when. The evaluation trigger is a quality one: evaluation material ages faster than training material, because a benchmark that has been in use for a year is no longer measuring what it measured on day one.

Continuity of the recipe is part of the deal

A refresh is only a refresh if it is built the same way, and that requires the vendor to keep the capability alive between deliveries: the guideline under version control, the screening criteria, the recruitment channel that reaches the same population, and annotators trained on the same conventions. A vendor who dismantled the team after the first batch can deliver new hours, but they will not be the same product.

Name those four things as a maintenance obligation, and give it a review point — an annual written confirmation that the guideline, the roster criteria and the recruitment channel are still in place. Ask for the current guideline revision with each refresh, and compare it against the last one.

Terms to attach to the refresh clause

The clause is only as good as the schedule behind it. These items are what make a refresh request routine instead of a renegotiation.

• A rate card for each of the three operations, attached as a schedule rather than agreed per request.
• A notice period for a refresh request, and a delivery window the vendor commits to.
• Acceptance criteria that reuse the original ones, so a refresh is not judged by a looser standard.
• The version manifest and checksums as a delivery item for every edition.
• A perpetual licence per edition, with a right to pin a version.
• Deprecation notice: how long the vendor will keep supporting, storing and re-issuing an edition it has stopped selling.
• The four continuity items above, with an annual confirmation.
• A final archive of everything delivered, available if the relationship ends.

Why this is worth the drafting time

Refresh terms are the least glamorous part of a data agreement and the part that decides whether the dataset is an asset or a one-off purchase. A corpus that can be extended, versioned and audited across editions behaves like infrastructure. One that cannot is a delivery you will eventually have to replace from scratch.

This is an operational outline rather than legal advice. Refresh and versioning terms interact with the licence grant itself, so have counsel review the two together.