A company record can contain useful values and unresolved fields at the same time. Treating the entire row as “verified” hides that difference. Field provenance means keeping the evidence and review context close to the particular value it supports.
This exercise uses Forma Labs, forma.example, and its fictional VP Sales, Maya Chen. The local company sample supplies industry SaaS, location San Francisco, US, and an employee band of 51–200. It supplies no external source or production verification date. The goal is a review ledger, not a claim that these facts have been checked against a real company.
1. Identify the destination and the field
Start with the record you intend to update. Confirm the entity before deciding whether any value belongs there. A plausible company name does not resolve a subsidiary, parent or product-brand ambiguity.
Then name the field precisely. The working company CSV exports Company, Domain, Industry, Location and Employees. Its Employees column contains a band, not an exact headcount. The data model documents how those columns map to the local fields; its additional relationship JSON is a proposed design, not an expanded export or live API response.
For this exercise, the destination is a research ledger you control. No CRM writes or external enrichment occur. Keeping the destination explicit prevents “available in the sample” from becoming “approved for a production update.”
2. Record the observation before the interpretation
Create one row for each field or claim. Keep the supplied value, evidence kind, source reference, relevant dates, current destination value and review decision separate.
For Forma Labs, the supplied industry value is SaaS and the evidence kind is fictional preview. A possible interpretation is that it fits a broad SaaS research cohort. That interpretation does not prove the company sells a particular product, uses a particular tool, or is ready to buy.
The same discipline applies to people. Maya’s VP Sales title is supplied in the fictional fixture. Her manager is not. The evidence for the role cannot be reused as evidence for a reporting edge.
An attributable production source would need to let an entitled reviewer understand where a value came from. A source link alone still needs the context of what it supports; it should not be attached to unrelated fields as a blanket quality badge.
3. Preserve uncertainty in values and time
The worked ledger distinguishes these cases:
| Field or claim | Supplied context | Review decision |
|---|---|---|
| Company industry | SaaS | Retain as fictional sample context; production verification absent. |
| Employee count | Band 51–200 | Keep the band; do not invent a midpoint or exact count. |
| Company headquarters | Only a display location is supplied | Leave headquarters unknown. |
| Maya’s current role | VP Sales | Preserve the fictional role label and its scope. |
| Maya’s manager | Not supplied | Do not create a reporting relationship. |
| Installed CRM product | Only the CRM category is supplied | Leave the product and installation status unknown. |
Dates need equal care. An event’s effective time, a system’s observation time and a reviewer’s verification time are different. The worksheets leave all three blank because the fixtures supply none. A blank date is not evidence of freshness, and a recent retrieval would not make a source’s underlying claim recent.
In a proposed JSON model, an explicit null represents a value not supplied here. It must not silently become zero, false, an empty string or a verified negative. A production contract would need more precise unavailable/restricted/not-applicable semantics before consumers depended on them.
4. Decide on a field-level update
Suppose your target record already has an industry value. The fictional sample returns SaaS, but you have no comparative source or date. Preserve the existing value and the proposed value for review. Choosing whichever makes a research cohort look more attractive is not conflict resolution.
Use a small set of actions that a reviewer can explain:
| Situation | Action | Reason to record |
|---|---|---|
| Target field is empty and the sample supplies a value | Stage an illustrative proposal | The value is fictional, not a production fill. |
| Existing and proposed values disagree | Hold both for review | No evidence establishes which is applicable or current. |
| Source field is absent | Retain the target value | Absence does not authorize clearing a known value. |
| Format differs, such as band versus number | Keep the original meaning | A conversion must not invent precision. |
| Identity is unresolved | Stop the update | Correct-looking fields can belong to the wrong entity. |
The action belongs to the field and the task, rather than to the record as a whole. Keep who will review it and what evidence is needed next.
5. Work locally with the ledger
Download the field-provenance worksheet. It contains the five company export fields, Maya’s supplied role, and unresolved reporting/technology questions. The target-value and owner columns are intentionally blank so you can conduct your own review.
Read the evidence kind before copying a row. The authored fixture rows are not a primary-source dataset. Add your own permitted reference only when it supports the particular field; leave observation, event and verification dates blank if unknown. Record conflicts as separate observations rather than erasing the earlier value.
This static download does not upload your changes. Keep your real worksheet in an appropriate workspace and apply your organization’s access and retention practices. No person or company information is submitted through this guide.
6. Make the handoff traceable
The next reviewer should be able to answer: which entity is this, what value was supplied, what evidence supports it, what remains unknown, and what action was approved? If a statement in a brief cannot be traced back to a field-level observation, qualify it or remove it.
Try the local enrichment preview and RevOps field-review workflow to inspect the fictional handoff. Continue with account/org mapping for relationship claims and role-change interpretation for event chronology. Production field provenance, external enrichment and API/MCP delivery remain in development.