DATA LINEAGE
Data provenance for company facts needs more than a source link
Data provenance for company facts should show the entity match, source record, retrieval time and change trigger behind each value.
Why data provenance is becoming a company-fact control
Data provenance is now a practical control for company facts, not a documentation afterthought. If an AI answer says a supplier is active, incorporated in England and controlled by a named parent, a reviewer needs to know which entity was resolved, which source value supported each claim and when the check happened.
Recent public guidance on AI materials sharpens the point. Inputs, outputs, data and audit trails may matter when they are captured, used in business, circulated or relied on in a decision. For company data, that turns provenance into the record that explains why a fact was allowed into a workflow.
Start with the exact legal entity
The first provenance failure is usually entity resolution. A source link to a registry search page does not prove that the system selected the correct company. The receipt should preserve the legal name, registration number, jurisdiction and the match rule that connected the user’s phrase to the registered entity.
For example, “Acme Holdings” may refer to a live UK company, a dissolved entity, a U.S. LLC or a trading name. If the answer only stores a name string, later reviewers cannot tell whether the status, director or ownership value belonged to the right business. A company data API should therefore make the resolved identifier durable.
Keep a field-level receipt, not a bookmark
A useful receipt is narrower than a file dump and richer than a citation. It records the field being asserted, the observed value, the source record or document, the retrieval time, and any source update or filing date supplied. Those dates should not be collapsed into one vague “last checked” stamp.
It should also show the activity that produced the published value. If software normalized an address, mapped a local status code to “active”, or chose one value over another, that transformation belongs in the provenance record. Without it, data lineage stops just before the decision a reviewer needs to inspect.
- Preserve the resolved company identifier and jurisdiction beside every material fact.
- Store source, record identifier, retrieval time and source-supplied dates separately.
- Record the rule, parser or reviewer action that transformed evidence into the published value.
Separate provenance from accuracy
Provenance does not prove that a value is true. It proves where the value came from and how it reached the system. A wrong registry entry, stale filing or mistaken mapping can still have complete provenance, which is why the receipt should carry a verdict or confidence state rather than pretending source lineage is enough.
That distinction matters for ownership, directors and financials. A filed shareholder record may support a direct holding but not a calculated ultimate beneficial owner. A financial statement can support revenue for one period, currency and consolidation scope but not a current trading estimate. Good provenance keeps those limits visible.
Make freshness part of the lineage
Company facts age at different speeds. Status can change after a dissolution filing, directors can resign, ownership can cross a review threshold and financial statements can be superseded. If the receipt has no monitoring state, the system cannot distinguish a fact that was wrong when published from one that became stale later.
This is where CompanyProof’s claim-level framing is useful: treat the statement as the unit to evidence, preserve and recheck, rather than treating the whole answer as one blob. The implementation question is not “do we have a source?” It is “can this specific company fact be reopened when the source changes?”
- Recheck high-impact facts when the source publishes a relevant filing or update.
- Flag missing source fields separately from negative findings or empty results.
- Keep the old supported value so a reviewer can see what changed and when.
The unanswered enterprise question
Current competing pages explain provenance, agent loops and provider sourcing, but they often stop before the operational acceptance test. For enterprise company data, the test is whether a reviewer can reproduce the fact without guessing the entity, source version, transformation or decision rule.
A clean implementation starts with one receipt schema for material company facts. Apply it first to identity and status, then extend it to directors, ownership and filed financials where source coverage allows. The payoff is modest but important: fewer unverifiable assertions moving through onboarding, credit review and AI grounding workflows.
A company-fact provenance receipt
A practical sequence for preserving the evidence behind a company fact from lookup to monitoring.
Capture the registered name, jurisdiction, registration number and internal company identifier before using any field.
Store the source record, field, observed value, retrieval time and any source-supplied update or filing date.
Document normalization, mapping, parser version or reviewer action that changed evidence into a usable value.
Separate supported, contradicted, unverified and unavailable states so provenance is not mistaken for accuracy.
Connect the receipt to a source-change trigger or review interval appropriate to the fact’s business impact.
FREQUENTLY ASKED QUESTIONS
data provenance FAQs
What does data provenance mean for company data?
It is the record of where a company fact came from, which legal entity it describes, when it was retrieved, and how it was transformed before use. It should be attached to the field, not buried in a general research note.
Is data provenance the same as data lineage?
They overlap, but they answer different review questions. Provenance explains origin and supporting evidence. Data lineage also follows movement and transformation through systems, including parsers, enrichment steps, rules, approvals and downstream publication.
Why is a source link not enough for company verification?
A link may show a source exists, but not the resolved company, selected field, retrieval time, source update date or transformation rule. Company verification needs those details so a reviewer can reproduce the decision and find mismatches.
Which company identifiers should a provenance record keep?
Keep the registered name, registration number, jurisdiction, source record identifier and any internal company ID used by the application. For cross-border work, never treat a name alone as the stable key because names collide and change.
How should AI grounding use company-fact provenance?
AI grounding should connect each material company claim to an evidence receipt. The answer can then show whether a claim was supported, contradicted or unverified, while the stored record preserves source context for audit and later recheck.
Can provenance show that a company ownership claim is complete?
Not by itself. Provenance can show which ownership evidence was used and what it supports. Completeness depends on the jurisdiction, disclosure rules, entity type, chain depth and whether indirect ownership or control was calculated separately.
What should happen when a source field is missing?
Record the field as unavailable or not returned, rather than converting it into a negative finding. A missing director, shareholder or financial field may mean the source does not disclose it, the module lacks access or the entity was mismatched.
How often should company facts be rechecked?
Use a risk-based freshness rule. Identity and low-impact enrichment can tolerate longer intervals, while status, directors, ownership and filed financials should be rechecked when a source update, filing event or decision review depends on them.
What is the minimum receipt for a company monitoring workflow?
Store the claim, resolved entity, supporting value, source record, retrieval time, source-supplied date, verdict and monitoring trigger. That lets the system mark the claim stale when the supporting value changes or disappears.
Where should teams start if they already use a company data API?
Start by inspecting response fields for identifiers, source context, retrieval timestamps, module availability and errors. Then map which downstream decisions need preserved evidence, which facts need monitoring and which unsupported facts require manual review.