Keeping a provenance log that survives scrutiny
One row per file, recorded at capture, with fields that answer who, when, where and under what consent — years later.
A provenance log is the difference between "the consent covers this batch" and "here is the consent record for file 4,112." It has to be written during collection, because the facts it records — who recorded what, where, when, under which version of which form — stop being recoverable the moment the session ends.
The log is also the first thing dropped on a busy day, because it produces no data and adds minutes to every session. The cost of that decision shows up years later, at the worst possible time: during a withdrawal request, a delivery dispute, or an audit.
One row per file, not per batch
The unit of the log matters. Batch-level logs fail the first time anyone asks about a specific file, which is exactly what happens in every dispute. A row per file, with the batch ID as one field among others, gives both views and costs nothing extra to maintain. The fields to capture at the moment of recording, grouped:
- Identity: file ID, batch ID, capture timestamp, session date.
- People: collector ID, speaker code, consent record ID and consent version.
- Context: site or studio code, script or prompt set ID, language and variety as tagged at capture.
- File: duration, format, and a hash of the raw file.
- Status: quality control flag, storage location, transfer status.
Immutability is a practice, not a product
The goal is that corrections leave a trace instead of erasing one. Four mechanisms get most of the way there:
- Append-only storage: the collector role can add rows and cannot edit them.
- Corrections recorded as new rows that reference the original entry, never in-place edits.
- The log stored separately from the media, so losing a disk does not lose the record.
- A daily snapshot or signed hash of the log itself, so tampering after the fact is detectable.
The three-way match
A log that is never reconciled drifts. The check is a three-way match: the number of log rows should equal the number of files in storage, which should equal the number of files delivered plus documented exclusions. Run it at three moments — at the end of each collection day, before delivery, and at delivery acceptance.
Discrepancies are findings, not annoyances. A file with no row is unprovenanced and should be quarantined rather than shipped; a row with no file is a data loss that needs explaining before someone else notices it. Both are cheap to fix on the day and expensive to explain in a dispute.
Hashes, and why buyers notice them
Record a cryptographic hash — SHA-256 is the common choice — of each raw file at capture, before any processing. Deliver the hashes alongside the media, and the buyer can verify after transfer that the files are intact and that the delivered set matches the described set.
This serves three purposes at once: it catches transfer corruption, it settles any later disagreement about what was delivered, and it gives both sides one unambiguous way to refer to a specific file. Processed versions get their own hashes derived from the raw one, so the lineage of any delivered file can be walked back to capture.
What not to put in the log
The log is a record, not a dossier. It will be shared more widely than the consent file ever will — with buyers, auditors, sometimes regulators — so it should contain no personal data beyond the pseudonymous code and the consent reference. No addresses, no identity documents, no free-text notes about participants.
The discipline is simple and easy to violate under deadline: if a field would matter to the consent system, it belongs in the consent system, access-controlled, not in the file that travels.