Key takeaways
- Store provenance and freshness with the value rather than treating the vendor name as sufficient context.
- Keep observed, provided, derived, and predicted attributes distinguishable in the CRM.
- Use confidence to route review—not to make uncertain data look precise.
- Verify consequential attributes before they drive exclusion, prioritization, personalization, or outreach.
01
One field can hide four different kinds of knowledge
A company size may come from a filing, a company form, a vendor’s model, or a salesperson’s estimate. Those values are not interchangeable even when they share the same integer. Without provenance, the most recent API write wins and the user sees certainty the system never earned.
Classify critical values as declared by the person, observed from an event, obtained from an external source, or inferred. Keep the original value when normalization is applied. This lets a reviewer understand both the input and the transformation.
Swipe to compare every column
| Metadata | Why it matters | Example |
|---|---|---|
| Source | Shows where the claim originated | Customer form, registry, vendor model |
| Observed at | Makes staleness visible | Fetched 2026-08-18 |
| Method | Separates fact from transformation | Reported, matched, normalized, inferred |
| Confidence and use | Limits consequential automation | Medium; review before routing |
02
Design for accuracy as an ongoing duty
The UK ICO’s accuracy principle says personal data should be accurate and, where necessary, kept up to date; reasonable steps should correct or erase inaccurate data. Enrichment therefore needs a correction path, a refresh policy, and a way to challenge a match—not just a procurement review.
W3C PROV provides a general model for describing entities, activities, and agents involved in producing data. A CRM does not need an ontology project to benefit from the principle: retain enough lineage to explain how a value arrived.
03
Do not let a match score become a fact score
A vendor’s confidence may describe identity matching, model output, source agreement, or something proprietary. Document what the number means and what threshold was validated on your records. Avoid copying “92 percent” into the CRM when nobody can explain its denominator.
Use confidence bands to decide whether to accept, verify, or reject a value. Require human review before sensitive or commercially consequential attributes change eligibility, territory, price, or message. Never infer protected or intimate traits simply because a provider makes them available.
04
Measure correction, not just fill rate
Coverage is easy to celebrate and weak as a quality measure. Sample records against authoritative evidence, track overrides and disputed matches, compare sources, watch age by attribute, and record which fields actually improve qualification or routing.
Retire enrichment that adds cost or risk without changing a useful decision. The best-governed data product is often smaller: a few attributes with known lineage, appropriate use, and a visible correction mechanism.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
- ICO: Principle (d) — Accuracy
- W3C Recommendation: PROV-O
- FTC: Data Brokers — A Call for Transparency and Accountability
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem
