Conflicting source data needs a resolution record, not an average
A company website says 85 employees. A data provider says 250. Your sales research agent has a qualification rule for companies with 50–100 employees. This is a fictional example. Choosing the newest number would be con
A company website says 85 employees. A data provider says 250. Your sales research agent has a qualification rule for companies with 50–100 employees.
This is a fictional example. Choosing the newest number would be convenient, but it could qualify the wrong entity. The website might describe a subsidiary; the provider might describe the whole group.
At MachGTM, our note on conflicting prospect data starts with that distinction: establish the entity and decision scope before deciding which reading to use.
Preserve observations separately
For a new research system, I would retain each observation with the entity it appears to describe, the value, the source URL, the source date when available, and the time we retrieved it. An unknown source date should remain unknown.
That record lets a reviewer distinguish a recent retrieval of old information from a genuinely new statement. It also preserves the original disagreement after the active value changes.
Do not average the two counts. A midpoint does not resolve whether the sources describe the same organization. It creates a third number that neither source supports.
Give the decision its own record
A resolution record can reference the observations considered, state the selected value or unresolved status, and explain the scope of the decision. It should also record who made it and why.
Those are proposed fields, not a claim about Mach's database schema. Their purpose is to keep a source statement separate from the decision to use it.
In the fictional example, the decision might be: “Use 85 for the subsidiary's local workforce; group purchasing scope remains unknown.” That is more precise than marking 250 incorrect everywhere.
Human priority does not prove truth
Mach's published source review, dated 5 November 2026, describes a field-reading system where human corrections have priority for supported fields. The note also records that older readings remain available. It does not establish that every company field uses this mechanism or that a live conflict was tested.
Protecting a correction from automatic overwrite is useful. The correction still needs a reason and supporting evidence. A mistaken manual entry should be visible and reversible without erasing what the system previously observed.
An explicit clearing of a field also deserves a reason: “Unable to establish the relevant entity” differs from “No employees.”
Let the decision determine the next action
If the unresolved count is essential to eligibility, hold that qualification decision and ask for the missing scope evidence. If the offer is relevant under either count, the seller may be able to continue without mentioning headcount at all.
That second path should preserve the disagreement. Omitting a number from a message does not resolve the underlying research question.
The companion note on observations and inferences in sales research explains the broader distinction. A useful research interface lets a reviewer trace a conclusion back to the observation—and see when the observation cannot carry the conclusion.
Adapted with AI from MachGTM's published notes. The headcounts are fictional. Proposed record fields are a design recommendation, not a verified implementation or a new live test.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.