Provenance survives automation when every normalized value retains a source locator, transformation record, review state, and destination receipt instead of becoming an untraceable field in a payload.
Treat provenance as part of the data model
A person copying a value can usually answer where it came from, at least while the source file remains open. An automated handoff loses that context unless the workflow stores it deliberately. Each extracted value should travel with the source document identifier, page or row locator, observed text, extraction time, and the version of the rule or model that produced the candidate value.
The W3C provenance model distinguishes entities, activities, and agents, which is a useful practical division here. The source passage and normalized value are entities, extraction and validation are activities, and the system or reviewer is the agent responsible for each action. A small implementation does not need the full standard, but it should preserve those relationships in a queryable form.
Preserve transformations and review decisions
Normalization must remain visible because a correct destination value can differ from the source representation. A date may change format, a company name may map to a canonical identifier, and a currency amount may be converted from text. The workflow should store the original observation, the normalized value, the rule applied, and any reviewer correction as separate facts.
Human review adds another provenance event. The record should identify what the reviewer saw, which fields changed, the reason supplied for the change, and the approved payload. The system should avoid attributing an extraction decision to the reviewer when the reviewer only approved a batch, because that ambiguity becomes expensive during a later dispute.
Carry the record through posting and reconciliation
Posting creates a new boundary. The adapter should retain an idempotency key or equivalent request identifier, the destination object identifier, the response status, and a safe representation of the submitted fields. A read-after-write check then compares the destination state with the approved payload and records any mismatch for reconciliation.
The buyer owns the source systems, access policy, and meaning of the business fields. Reality Contact, LLC implements the technical record and tests the agreed cases, but the buyer decides which provenance details may be retained and which require redaction. That decision should be made before production data moves through the workflow.
Where the service stops
Reality Contact, LLC implements and tests the technical workflow using buyer-authorized systems, but does not choose business policy, approve consequential decisions, supply production credentials, or authorize writes on the buyer's behalf. The buyer approves the mappings, review rules, access, retention terms, and test results, then processes a bounded live batch through the supervised workflow. This is technical implementation based on buyer-supplied rules and authorized access, and it does not replace legal, financial, security, privacy, or professional advice. The buyer controls credentials, source rights, business rules, retention decisions, reviewer authority, and every production release.
Sources: W3C PROV overview.