The question changed and the answer did not
For years the data-provenance section of a procurement questionnaire was one line and one checkbox. Do you have the rights to the data used in this product. Yes. Signed by counsel, filed, done. That answer still gets written, and it now fails, because the person reading it has been told to ask a follow-up: show me. What arrives in response is usually a folder of PDF contracts and a spreadsheet somebody maintained until 2023. The distance between a signed license and a record of which rows in the shipped product came from that license is where deals stall for six weeks.
This is not a compliance fashion. Three forces converged. Model training put a spotlight on data origin, and buyers now assume any product with a model in it was trained on something they should ask about. Litigation over scraped and licensed corpora made general counsel nervous about indemnity language they signed without a supporting record. And the frameworks buyers cite in contracts became specific: the NIST AI Risk Management Framework 1.0 places data provenance under its Map function, ISO/IEC 42001 requires documented data sourcing as part of an AI management system, and any bank buying your product runs it through SR 11-7 model risk governance, which has asked about input data quality and origin since 2011.
If you sell into government, add another layer. A federal buyer will fold the same questions into a security package under NIST SP 800-53 controls in the SA and SR families, and if you handle controlled unclassified information the flow-down under 800-171 reaches your suppliers too. The point is not which framework applies. It is that four different reviewers now ask the same question from four directions, and one honest artifact answers all of them.
Where provenance records break, in the order we usually find them
Ranked by how often we encounter each one when tracing a shipped dataset back to its paperwork. Practitioner judgment, not a survey.
What a buyer is actually trying to decide
It helps to know what the reviewer on the other side is worried about, because it is narrower than the questionnaire suggests. They have four risks and each one has a different owner inside their company.
Legal risk is the obvious one. If a supplier three steps up your chain scraped a source they had no right to, and your product carries that data, the buyer inherits exposure and their indemnity from you is only as good as your balance sheet. Regulatory risk is next: a health-tech buyer needs to know whether patient-derived records passed through a de-identification step that meets the HIPAA Expert Determination or Safe Harbor bar, and a buyer in a consumer market needs to know whether a deletion request reaching you actually reaches every copy. Operational risk is quieter. If a supplier terminates and you must purge their contribution, can you find it, or does the product degrade in a way nobody can predict. And model risk, for anyone in financial services, is the SR 11-7 question about whether the inputs to a model are appropriate, documented, and monitored.
None of these is answered by a contract. All four are answered by a record that connects a row in production to the agreement that permits it being there. That record is the deliverable, and almost nobody has one until they build it on purpose.
The record has six fields and that is the whole trick
A provenance record that survives a real review is not elaborate. For every dataset that reaches production, six things must be true and findable.
Source identity. Which supplier, which specific product or feed from that supplier, which version or delivery date. Not "market data from a data provider" but the feed name and the delivery identifier, because suppliers sell multiple products under different terms and the terms are what matter.
Instrument. The executed agreement, the effective date, the term, the amendments. A link to the document, not a summary of it. Summaries drift from the contract they summarize within a year.
Permitted uses, encoded. This is the field everyone skips and it is the one that does the work. Internal analysis only, or redistribution permitted. Model training permitted, or not. Derived works permitted, and are they encumbered. Geographic restrictions. Named-affiliate restrictions. Written as structured values a system can check, not as a paragraph in a folder.
Upstream chain. What the supplier represented about where they got it. You will not get full visibility here and you should not pretend to. What you can do is record the representation, its date, and its form, so a reviewer sees the boundary of your knowledge clearly instead of discovering it themselves.
Transformations applied. What you did to the data between receipt and shipment. Joins, enrichment, de-identification, aggregation, filtering. Each transformation either preserves the original obligation or creates a derived artifact whose status has to be decided.
Obligations with dates. Deletion deadlines, expiry, audit rights, notice requirements, attribution requirements. Each one attached to a date, on a calendar something watches.
Encode permitted uses as data, or you will not enforce them
Here is the mechanism that separates a real provenance program from a documentation exercise. Take the permitted-use terms out of prose and put them in a table with one row per dataset and one column per right. Redistribution: yes, no, or conditional with the condition named. Model training: yes, no, or yes-with-notice. Derived works: unencumbered, encumbered, prohibited. Retention limit in days. Geography. Then make the table load-bearing.
Load-bearing means the pipeline reads it. When a job assembles a training corpus, it queries the table and refuses to include any dataset whose training flag is false. When an export job builds a customer deliverable, it checks the redistribution flag on every contributing source and fails the build if one is false. This is a few hundred lines of work in most stacks, and it converts a policy that people remember into a control that a reviewer can test. That difference is worth more in a diligence conversation than any amount of written assurance, because you can demonstrate it in ten minutes on a call.
The common objection is that terms are too nuanced for a table. Some are. The answer is a conditional value with a pointer to the clause and a named human owner, plus a rule that conditional means the job stops and asks. A pipeline that halts on twelve ambiguous datasets and runs clean on four hundred is a functioning control. A pipeline with no check at all is a hope.
Derived data is where the chain quietly breaks
The hardest problem in practice is not licensed raw data. It is the third-generation artifact. You buy a firmographic file. You join it to your own transaction records. You compute a score. You train a model on the score. You ship the model. Four steps from the license, and the question of whether the supplier's terms reach the model weights is now a legal question that nobody asked at the time and everybody asks during diligence.
The engineering answer is to carry provenance through the transformation rather than reconstructing it later. Every derived table records the identifiers of its contributing sources in its own metadata. Every model artifact records the datasets in its training set by identifier and version. This costs almost nothing when a pipeline is being written and is brutally expensive to reconstruct three years afterward, which is the reason so many firms are in the expensive version of this project.
The policy answer is to decide, per supplier, what the contract says about derived works, and to record that decision with a date and an owner before the derived artifact ships. Many agreements are silent, which is not the same as permissive. Silence is a risk you can choose to accept knowingly, and a buyer respects a documented accepted risk far more than a discovered unexamined one.
Reconstructing provenance for data you already shipped
Most of this work happens in the wrong order. The data is already in production, the deal is already in diligence, and the record has to be built backward. It is doable and the sequence matters.
Start from production, not from the contracts folder. Enumerate the datasets that actually reach a customer or feed a model. This list is always shorter than the list of datasets you own and always contains two or three surprises. Then work outward: for each one, find the delivery mechanism, find the supplier, find the agreement. The ones you cannot resolve are your real inventory of risk, and there are usually between three and a dozen.
For each unresolved item there are four honest outcomes and you should choose deliberately among them. Find the paperwork. Get a fresh attestation from the supplier covering the historical period. Quarantine and remove the data. Or accept a documented risk with a named owner and a date. Every one of those is defensible in front of a buyer. What is not defensible is an inventory with blank cells and no decision beside them.
How much weight a reviewer puts on each artifact — our rating
Relative weight we would expect a diligence reviewer to assign. Judgment from doing this work, not a published standard.
What to ask your own suppliers, and what you will get
Your provenance record depends on representations from people upstream, and the quality of those representations varies enormously by supplier type. Ask four questions in writing and read the shape of the answer as carefully as the content.
What are the ultimate sources of this feed. A supplier who names them is licensing data they aggregate under agreements they can describe. A supplier who says the sourcing is proprietary is telling you the chain stops there, and you should record that as the boundary rather than assume what lies beyond it.
May we use this for model training, and may we ship derived works. Ask separately. Many agreements written before 2022 do not contemplate training at all, and the supplier's current position on an old contract is worth having in email even where it is not yet an amendment.
What is your deletion and correction process, and how fast does it propagate. This is the question that reveals whether a supplier can support your own obligations to your customers. If they cannot delete a record within your committed window, your commitment is fiction.
Will you attest, annually, that you hold the rights you represented. A short annual attestation costs the supplier little and is the single most useful piece of paper in your file, because it is dated and it is theirs.
What this costs and how long it takes
Real numbers, because the vague version of this advice is useless for planning. A firm with twenty to fifty third-party datasets in production and a normal amount of undocumented history is looking at three phases.
The inventory and reconciliation phase runs four to eight weeks with one senior data engineer and part of a counsel's time. Output is the joined table of datasets to agreements with every cell either filled or explicitly flagged. Cost typically lands between forty and ninety thousand dollars depending on how much of the history is retrievable and how many suppliers need to be contacted.
The instrumentation phase runs six to twelve weeks. This is the permitted-use table, the pipeline checks that read it, provenance metadata carried through transformations, and training-set manifests captured per model version. One to two engineers. Typically eighty to two hundred thousand dollars, and the range is driven almost entirely by how many distinct pipelines have to be touched rather than by the difficulty of any one of them.
The ongoing phase is small if the first two were done properly. An obligation calendar, an annual supplier attestation cycle, and a quarterly reconciliation that catches new datasets before they become old undocumented ones. A few days a quarter. Firms that skip this phase are back in the expensive version of phase one within about two years, because datasets arrive continuously and nothing catches them.
The failure mode that actually kills deals
In our experience the deal-breaker is rarely a bad answer. It is an inconsistent one. The security questionnaire says data is retained for two years. The privacy policy says three. The engineer on the technical call says nothing is ever deleted because storage is cheap. Nobody lied. Three people described three different parts of a system nobody had mapped, and the buyer now has to assume the worst reading of all three.
This is why the inventory is worth building even if the answers it produces are imperfect. A single source of truth that says retention is two years for these eleven datasets, indefinite for these four, and under review for these two, is stronger than a clean policy nobody can substantiate. It also means the person on the technical call has something to read from instead of improvising, which is where most of the damage happens.
The second failure mode is scope creep in the answer. A reviewer asks about one product line and receives a company-wide document that raises questions about six other things. Scope the record to what is being bought, keep the wider inventory internal, and answer the question asked.
Bottom line
Provenance has moved from a legal filing question to an engineering one. The artifact that satisfies a buyer is not a contract folder. It is a dataset inventory joined to executed agreements, permitted uses encoded as structured values, a pipeline control that enforces them at build time, provenance carried through derived tables and model manifests, and an obligation calendar something actually watches. Built in advance it is a few months of focused work and a small ongoing habit. Built under deal pressure it costs several times as much and produces a worse artifact while a deal waits. Every firm that sells data-derived products will build this record eventually. The only real decision is whether it gets built on your schedule or a buyer's.
Frequently asked questions
No. The license proves you had the right to acquire the data. Buyers now ask which records in the shipped product came from that license, under what permitted uses, and what happens when the agreement ends. That requires an inventory joining datasets to agreements, not a contract folder.
Most commonly the NIST AI Risk Management Framework 1.0 Map function, ISO/IEC 42001 for AI management systems, and SR 11-7 for anyone selling into banking. Federal buyers fold the same questions into NIST SP 800-53 SA and SR control families, with 800-171 flow-down where controlled unclassified information is involved.
Record the refusal as the documented boundary of your knowledge, with the date and the form of the supplier's representation, and ask for a dated annual attestation that they hold the rights they claim. A clearly marked boundary is far stronger than an implied claim to visibility you do not have.
It depends on the agreement, and many written before 2022 are silent on training and derived works. Silence is not permission. The workable practice is to decide per supplier, record the decision with an owner and a date, and capture a training-set manifest per model version so the question can be answered later without archaeology.
For twenty to fifty production datasets, four to eight weeks for inventory and reconciliation, then six to twelve weeks to instrument pipelines with permitted-use checks and provenance metadata. The variable that drives cost is the number of distinct pipelines to be touched, not the difficulty of any single one.