Provenance Starts Before The Review Screen
Document provenance is easy to postpone. The first version of a workflow only needs to read a PDF, pull out a few fields, and send them somewhere useful. The team can add review screens, audit dashboards, and source inspection later.
Then the workflow works. Customers depend on it. A field is wrong. A generated report contains an unexpected value. Someone asks which document produced it, which extraction schema was used, whether a human changed it, and whether the corrected value was sent downstream.
If the answer is hidden in logs, webhook payloads, and old model responses, provenance has become a cleanup project.
The mistake is treating provenance as a feature that only exists when there is a polished reviewer interface. Interfaces are useful. They are not the foundation. For API-first workflows, provenance starts with records: what file produced which value, which schema asked for it, what citation supported it, what confidence came back, whether a human approved it, and which generated artifact used it later.
You do not need a full review product on day one. You do need to avoid losing the chain between source documents, extracted values, approved values, and outputs.
That chain is also the foundation for audit trails in AI document workflows.
The Smallest Useful Provenance Record
The minimum provenance record is not complicated. It is just easy to skip.
For every extracted value that can affect a workflow, store the context needed to answer where it came from and why the system trusted it. That usually means a workflow run ID, source document ID, source filename or URL, schema name and version, field name, extracted value, confidence score, source citation, review status, approved value, and processing timestamp.
Some teams resist this because it feels like too much database design for an early workflow. But the alternative is usually worse: a JSON response gets copied into a job payload, transformed into a CRM update, partially logged, and then forgotten. When the value is questioned, nobody knows which part of the chain changed it.
Consider an invoice approval workflow. The system extracts supplier name, IBAN, invoice number, total, currency, due date, and line items. The total is high enough to require review. A reviewer corrects the due date and approves the total. A spreadsheet row is generated for finance.
The provenance record is what lets support answer a simple question later: “Why did this spreadsheet say the invoice was due on June 2?” The answer should not be “because the automation said so.” It should be: this source file was processed at this time, using this schema version, the model extracted this date with this citation and confidence, the reviewer changed it to this approved value, and the spreadsheet was generated from that approved value.
That is provenance. Not a grand compliance platform. Just the chain of custody for a value.
Extracted Value And Approved Value Are Different Facts
Review should not erase the original extraction.
If a reviewer changes 2026-06-02 to 2026-02-06, both values matter. The extracted value tells you what the system read. The approved value tells downstream systems what they may use.
Teams often overwrite the extracted value because it makes the next step easier. The database has one due_date column. The workflow wants one answer. The export needs one value. But collapsing those facts too early removes the evidence you need when the workflow misbehaves.
Keeping both values has practical benefits.
It helps support explain what happened. It helps engineering tune schemas when reviewers repeatedly correct the same field. It helps operations distinguish extraction errors from human corrections. It lets downstream systems choose the right value based on state: extracted values for drafts, approved values for customer-facing outputs.
There is a tradeoff. Storing both values means more schema design and more discipline in downstream code. A developer has to decide whether a step reads the raw extraction, the approved value, or a fallback. That is a real cost. But it is much smaller than trying to reconstruct the difference after the original extraction has been overwritten.
Citations Are Operational Metadata
Source citations are often treated as UI details. They are more than that.
A citation tells a reviewer, support agent, or downstream process where the value came from. In a simple workflow, that might be a page reference or a text span. In a document-to-markdown workflow, it might be a section or heading. The exact citation format depends on the processor and the document type, but the role is the same: it ties the value back to source evidence.
This matters even if review happens in a plain internal tool. A support view can show the citation next to the extracted value. An audit export can include enough context for a customer to understand the origin of a value.
Document Extraction returns typed values with confidence scores and citations. The important design choice is to persist that metadata with the workflow state instead of treating it as temporary response decoration.
Do not overstate what citations can do. They do not prove the value is correct. A model can point at the right area and still interpret it incorrectly. But citations make the interpretation inspectable.
Schema Versions Are Part Of Provenance
Document workflows change. A field gets renamed. A description becomes stricter. A new enum value is added. The workflow starts extracting line items instead of only totals.
When that happens, old extraction results need to remain understandable. If a result says payment_terms: "30 days", support should be able to know whether the schema expected free text at the time or whether it should have returned a constrained enum. If a field is missing, engineering should know whether the field existed in the schema version that produced the result.
Store the schema name and version with every extraction run. For high-impact workflows, also store a snapshot of the schema or a reference to an immutable schema definition. The goal is not to make schemas bureaucratic. The goal is to make old results explainable after the workflow evolves.
Generated Artifacts Need Lineage Too
Provenance should not stop at extraction.
Once approved data becomes a PDF, spreadsheet, image, or report, the output becomes part of the chain. Generated artifacts often look more authoritative than raw JSON. A polished PDF report can travel to a customer, an XLSX workbook can be imported into finance software, and a generated image can appear in a marketing workflow.
If an artifact contains a disputed value, the system should be able to trace it backward. Which extraction result produced the approved value? Which reviewer approved it? Which template or generation definition was used? When was the artifact created? Where was it delivered?
For generated outputs, useful lineage usually includes artifact ID, artifact type, output format, generation API used, template or definition version, source extraction result ID, approved values snapshot, generation timestamp, and delivery status.
That snapshot matters. If the approved value changes later, an old PDF does not change with it. The artifact should be traceable to the values that existed when it was generated.
Document Generation, Sheet Generation, and Image Generation can handle output creation. Your application should keep the artifact lineage because it owns the product state around those outputs.
Provenance Makes Deletion Less Painful
Provenance is not only for audits. It is also for cleanup.
When a customer deletes a source document, your system needs to know what derived records exist. There may be markdown chunks, extracted fields, review records, generated summaries, generated files, exported spreadsheet rows, notifications, and downstream updates.
Without provenance, deletion becomes a search project. Engineers grep logs, query by filename, inspect vector metadata, and hope no generated artifact kept a copy of the value. With provenance, deletion can follow references.
This does not mean every derived object must always be deleted. Some products have legitimate retention requirements for invoices, audit records, or customer-visible outputs. The point is that retention should be deliberate. Provenance gives the product a map of what exists so policy can be applied consistently.
For EU-facing workflows, the distinction matters. Iteration Layer processes files without retaining them after processing, but your application still owns the records it stores: extracted fields, generated outputs, logs, and review state.
What Lightweight Provenance Does Not Replace
Lightweight provenance records do not replace a full review UI, e-discovery system, regulated records-management platform, or legal analysis. They also do not guarantee that an extracted value is correct.
They solve a narrower engineering problem: keeping the relationship between source, extraction, review, and output intact while the workflow grows. The first version can be simple: source documents, extraction runs, field results, review decisions, generated artifacts, and delivery events.
The tradeoff is that you are choosing a record model before every product requirement is known. That can feel premature. But the alternative is letting every integration invent its own hidden provenance model in payloads and logs. A small explicit model is usually easier to evolve than a large accidental one.
Where Iteration Layer Fits
Iteration Layer is the processing layer for workflows like this.
Document Extraction turns documents into typed values with confidence scores and citations. Document to Markdown creates text that can feed retrieval or agent context. Document Generation, Sheet Generation, and Image Generation turn approved data into output artifacts.
The product boundary is important: Iteration Layer returns processing results, but your application should store provenance records because your application owns customers, permissions, review policy, retention, and downstream side effects.
That split keeps the workflow flexible. You can start with one API call and a small provenance table. As the product matures, you can add review queues, audit exports, deletion workflows, and generated-output lineage without changing the basic mental model.
Start With One Field
If the whole provenance model feels too large, start with one field that matters.
Pick a value that updates a database, triggers a workflow branch, or appears in a generated output. Trace it backward and forward. Can you identify the source file, schema version, extracted value, confidence, citation, review decision, approved value, and artifacts that used it?
If not, add the missing record before the workflow gets harder to unwind.
Provenance is not paperwork for its own sake. It is how a document workflow earns the right to affect real systems.