In this article
The question
A correction should be easy to question, including one I agree with.
When a person changes a field, I want that correction protected from being silently overwritten. I also want the next person to see why it was made. Giving human input priority decides which value the system uses. It does not establish that the value is true.
That is the bar I want Mach’s account data to meet: a correction stays visible and challengeable, with enough context to revisit it.
First ask whether the readings describe the same thing
Consider a fictional account. A company page says 85 employees. A data provider says 250. The seller usually works with companies between 50 and 100 employees.
I would want to understand those numbers before using either to qualify the account. Choosing the convenient value could put the wrong company into the segment. A newer reading could still describe the wrong entity.
| Reading in this fictional example | Possible explanation | What I would check |
|---|---|---|
| 85 employees on a company page | A subsidiary or an older count | Which entity and point in time does the page describe? |
| 250 employees from a provider | The parent group or several locations | What is included, and when was it observed? |
If the UK subsidiary buys independently, its size may be relevant. If the parent chooses the system for every location, the group figure may be more useful. Both readings could answer legitimate but different questions.
My read is that the decision should determine what needs resolving. I would establish which entity buys before arguing over which headcount source wins.
Keep disagreement after import
In an r/SalesOperations discussion[1], u/Wahabkhalid245 described “Manually cross-referencing job titles against LinkedIn” and a CRM showing 200 employees for a company they said had 40. They attributed that mismatch to an 18-month-old source.
These are their reported examples. The underlying records have not been independently checked here.
u/Cautious_Pen_674[2] recommended treating “data quality like an intake control problem instead of a cleanup project.” I agree with checking consequential fields before they drive routing and reporting.
I would still keep a way to retain disagreement after import. A current company page and a current provider reading can use different scopes. A colleague can make a correction against the wrong account. An intake rule does not settle those questions.
A human correction needs a reason
A person who has spoken to the company may know more than the next automated import. I want that knowledge preserved. I also want to know what they confirmed, with whom, and when.
“Confirmed on the UK subsidiary’s team page” gives a colleague a basis to inspect. A bare number leaves them guessing. An estimate from a call should remain an estimate, with the scope and date of the conversation.
The same applies when the field is cleared. Clearing an incorrect value can be the right action. I would want the next person to understand whether the value was disproved, belonged to another entity, or remained unknown.
| What I would preserve | Why it helps the next decision |
|---|---|
| Both source readings | The earlier answer remains available to challenge |
| Entity and definition | A group count is kept distinct from a subsidiary count |
| Dates and their meaning | Receipt time is kept distinct from the age of the fact |
| Basis for the correction | A colleague can reconstruct why the value changed |
| Remaining uncertainty | The next verification has a clear purpose |
NIST’s information quality guidelines[3] require NIST to consider and disclose limitations and uncertainty in third-party information it uses. That guidance governs NIST’s own information products. I apply the same discipline to this sales example: make the basis and limits visible to the person using the answer.
What Mach’s priority rule establishes
In Mach’s field-reading system, a person’s correction takes priority over other readings for the fields handled by that rule. An explicit clearing can win too. Other ordering uses when the value was learned, when the reading was recorded and the reading sequence. Earlier readings are retained.
I support protecting a person’s correction from the next import. My concern is what happens after the correction wins. The team still needs to be able to ask whether it applies to the right entity and remains current.
The selection rule gives the application a current value. The evidence behind that value is what lets a seller decide how much to rely on it. I want both available when the value changes an account decision.
Method and scope: The field rule, its writer and its reader were checked against the November 5, 2026 source snapshot. These statements apply to fields handled by that system. No live screen workflow or individual correction was verified.
Resolve what could change the action
If the size threshold determines qualification and neither source explains its scope, I would hold that qualification decision. I would not average 85 and 250 into a new figure that neither source reported.
If the offer works at either size, the discrepancy may not block an initial conversation. I would preserve it and leave the disputed count out of the message.
The question may also belong with someone else. An internal account owner can help resolve territory responsibility. A buyer can explain who purchases for the group. Research should make that next check clear rather than hide the disagreement behind a single confident field.
Before acting, I would name the decision, open the sources, compare entity and date, and record the basis for any resolution. The separate problem of an unsupported interpretation needs its own check.
What evidence would make you revisit a correction your team currently trusts?
How this post was made: AI assisted the research and drafting from supplied product principles. Public quotations and handles were checked on November 5, 2026. Implementation details were checked against the dated source snapshot. The fictional examples are labeled.
Common questions
Does the newest source always win?
First check what its date means. A provider can deliver an old observation today, and a recent page can repeat an older figure. Compare the entity and definition as well as the date before deciding which reading serves the decision.
Can two different headcounts both be correct?
They can describe different scopes, such as a subsidiary and its parent group, or different points in time. Verify what each source counts and where the relevant purchasing decision sits. The number needed for qualification may depend on that scope.
Should we average conflicting numbers?
Averaging creates a new number that neither source reported. Retain both readings and resolve the definition or scope if the difference affects qualification. If it does not affect the next action, keep the uncertainty visible and move on.
Does a company website always beat a data provider?
Choose the source for the field. A current team page may help confirm a role; a filing may clarify a corporate entity. A website with no date or definition can still leave the question open.
What if a human correction is wrong?
Revisit the evidence behind it. Record who corrected the field, the basis, its scope and when it applied. Giving corrections priority prevents automated overwriting; it does not remove the need to correct an outdated or mistaken edit.
Must every mismatch be resolved before outreach?
Prioritize a mismatch if it changes whether you contact the account, whom you contact or what you say. Leave a disputed figure out of the message until you can support it. Other uncertainty can stay in the internal note for later review.
What should a conflict note preserve?
Include the affected decision, both source readings, links, relevant dates, scope and the next verification. When someone resolves the conflict, retain their reason alongside the earlier readings so a colleague can reconstruct the choice.
