Key takeaway
A shared file name is not a release identity. Pin the package, its exclusions and its permitted use before recording an evaluation or acceptance.
Separate the dataset from its deliveries
An archive may evolve continuously while an evaluation concerns one bounded delivery. Name both: the underlying dataset and the specific package supplied to a recipient. A folder called latest cannot tell a finance or privacy reviewer which records were examined, which fields were excluded, or whether a later file replaced the one originally approved.
DCAT 3 supports version identifiers and notes while leaving version conventions to the provider. PROV describes relationships between produced information and earlier entities or activities. These are useful reference models for an owner’s release record. They do not require the particular spreadsheet below, and they do not establish rights or make a delivery acceptable to a buyer.
Choose a convention that a person can use during a dispute: a stable dataset name, an immutable package identifier and a record of the previous package. Keep a descriptive display name for convenience, but do not use it as the only evidence of identity.
A completed release manifest
This illustrative manifest describes an invented job evaluation package. It is an example of a review artifact, not a public inventory or an offer. The owner should tailor its fields to the actual evaluation and approved disclosure. Permission references identify a decision record; they do not expose confidential approval documents to every recipient.
If checksums are used, compute them from the actual delivered bytes and preserve the method. Do not enter a made-up hash just to complete a form. A checksum can help detect a different file, but cannot show that the file is truthful, anonymous, licensed or safe to share.
| Manifest field | Illustrative entry | What it settles |
|---|---|---|
| Dataset / package | Job history / JOB-EVAL-002 | Dataset is distinct from this delivery |
| Previous package | JOB-EVAL-001 | Identifies the comparison point |
| Scope | 2024 jobs; completed and cancelled attempts | States the covered period and units |
| Schema version | SCHEMA-2; outcome_label allows unknown | Pins field meaning |
| Exclusions | Contact fields, attachments and free-text narrative | Makes omissions inspectable |
| Change note | Narrative removed; derived labels unchanged | Explains the revision |
| Recipient / purpose | Named evaluator A / recurrence feasibility | Bounds intended use |
| Approval reference | DECISION-014; sample evaluation only | Points to a separate permission decision |
| File identity | Delivery filenames and computed checksums | Binds the review to delivered bytes |
Classify the change before reusing an approval
A spelling correction in documentation, a new outcome definition, an added year of records and a new recipient are different changes. Decide who must reconsider each one. Avoid a rule that treats every file update as merely technical: removing a field can change evaluation results, and adding a field can change confidentiality or privacy exposure.
In a hypothetical revision, package 002 removes narratives from package 001 after the owner identifies restricted text. The recipient’s earlier result used those narratives. The result cannot simply be relabeled as applying to package 002. The evaluator must explain whether it can rerun without them, and the owner must review the revised delivery scope.
Conversely, a new company requesting the unchanged package is not just another version of the same permission. Record a separate recipient decision. The package identity helps describe what is proposed; it does not transfer approval from one recipient to another.
Make results and corrections traceable
Ask the evaluator to identify the package, evaluation procedure, output and date in its result record. When a correction is needed, preserve a reference to the superseded package and explain which results need reconsideration. A silent replacement may leave different people discussing different inputs under the same file name.
Use a delivery log with the recipient, permitted access method, supplied package, any later correction and confirmation received. The log can show what the owner supplied, but confirmation that a recipient received a correction is different from confirmation that every downstream copy was removed. State that distinction when follow-up is incomplete.
Do not overwrite regulated or business originals as part of release preparation. A controlled derivative package can carry an exclusion note while the source archive remains subject to its own retention and correction process. Any new use, expanded data scope or changed recipient should return to the responsible decision maker.
Use versioning to reduce avoidable disputes
Before a sample leaves the owner, confirm that another person can answer four questions from the manifest: which bytes, which definitions, which omissions and which permission. If one answer depends on someone’s memory, improve the record before scaling the delivery process. Start with a single bounded package rather than a complicated platform that nobody maintains.
Use the inventory tool to describe the source archive, then the rights-review tool to record the questions raised by a particular package. Versioning supports operational clarity; it is not a valuation method or a promise that a recipient will accept a delivery. VOID’s permissioned introduction remains separate from sample approval and any subsequent license.