The core distinction
Data quality and data visibility are not the same problem.
Data quality is about whether the information in the system is accurate. Data visibility is about whether the right people can see the right information at the right moment to make a good decision. Both matter, but they have different failure modes and different fixes.
Where trust breaks
Data becomes untrustworthy at specific, findable moments. These are the four most common.
Data trust often breaks at predictable points in the data lifecycle: when data enters a system, changes hands, crosses into another tool, or becomes a report. Finding the break in your own process is the first step to fixing it.
Break 1
At intake - when the rules for entering data are unclear
Data problems usually begin at the moment data enters the system. If the field definitions are unclear, if the same field is used differently by different people, or if there is no enforcement at intake, the data arrives already inconsistent.
Common examples: the "source" field means different things to sales and marketing. The "status" field has twelve values but the workflow only uses four of them clearly. The "owner" field is filled in by whoever created the record, not by whoever is actually responsible. Each of these ambiguities compounds over time as more records are created and the inconsistency becomes structural.
The fix is not a training session about how to fill in fields correctly. It is making the field definitions explicit, reducing optionality where consistency matters, and enforcing the rules at the point of entry rather than trying to clean up afterward.
Break 2
During transitions - when records change hands without transferring context
When a lead converts to a customer, when an account moves from one team to another, when a project transitions from sales to delivery - these handoff moments are where data often breaks. The old owner had context that was never captured. The new owner inherits a record with missing or ambiguous information and fills in the gaps from their own assumptions.
The result is records that look complete but are not internally consistent. The status says one thing, the notes say another, and the last activity was recorded differently by two different people. A report built on these records will produce numbers that cannot be explained, because the underlying data contains contradictions.
Transition points need explicit data contracts: which fields must be complete before a record can be handed over, what information the receiving party needs to act correctly, and who is responsible for ensuring the handover data is accurate.
Break 3
In exceptions - when unusual situations are handled outside the system
Every workflow has exceptions. The renewal that was negotiated differently. The client who has a special arrangement. The deal that was closed under unusual conditions. When these exceptions are handled via email, Slack, or verbal agreement rather than being recorded in the system, they create invisible data - information that exists somewhere but is not in the place where decisions get made.
Invisible exception data does worse than go missing from reports. It opens a silent gap between what the system shows and what is actually true. Reports become unreliable not because the normal records are wrong but because the exceptional records are incomplete, and nobody knows which ones they are.
Exception handling needs a dedicated path: a way to record the exception in the system so it is visible, a field or flag that marks the record as non-standard, and a process for reviewing exceptions periodically to decide whether they should become rules.
Break 4
In reporting - when the dashboard layer adds interpretation that should be in the data
Some reporting problems are really data problems disguised as presentation problems. The dashboard looks complicated because the underlying data requires complicated logic to interpret. Fields that should be enumerations are free-text. Dates that should be calculated are manually entered. Statuses that should be mutually exclusive are combined in ways that require explanation.
When the report has to explain the data rather than present it, the explanation belongs in the data model, not in the report. The fix is upstream: clearer field definitions, enforced values, calculated fields built once rather than recalculated differently in every report. Reports should present data. They should not be doing the work of making data coherent.
Quality vs visibility
You can have clean data nobody trusts, or visible data that is wrong. Different problems, different fixes.
A team can have high-quality data that nobody trusts, because the reporting layer is poorly designed and the numbers always seem to require explanation before anyone acts on them. A team can have visible data that is wrong, because the underlying records have accumulated errors that nobody caught. The two problems usually arrive together, because systems with weak visibility also tend to have weak data quality, problems that cannot be seen cannot be fixed.
The diagnostic signal
A number that needs explaining before anyone acts on it is not a metric. It is a rumour.
This is the practical test for data visibility. Not whether the data is technically accurate, but whether it can be handed to someone unfamiliar with its quirks and acted on without a briefing. Data that requires explanation is data that depends on a specific person's knowledge to interpret correctly. That knowledge is invisible, unscalable, and will be lost when that person is unavailable.
The alternative to three versions of the same number, each defended by a different person.
What Is a Single Source of Truth? ->Finding it
Where someone has to explain a number, a break is hiding
The diagnostic process
How to find where your data trust is breaking.
Data visibility problems are diagnosable with a structured audit. This is not a technical process. It requires understanding how the data is supposed to work and comparing that to how it actually works in practice.
01
Map the data lifecycle
Trace the path a piece of information takes from when it first enters the system to when it appears in a decision. Write down every point where data is created, modified, transferred, or read. Include the informal steps: where does it get corrected in a spreadsheet before the report? Where does it get interpreted by a specific person before it is acted on? These informal steps reveal where the system is not trusted.
02
Find the explanation points
Ask the people who present reports or dashboards to the people who make decisions: what do you have to explain before anyone acts on these numbers? Every item on that explanation list is a visibility failure. Either the data is wrong, the definition is unclear, the reporting logic is inconsistent, or the context is missing. Each one has a specific fix, but only once it has been found.
03
Identify ownership gaps
For each data field that matters, ask: who is responsible for ensuring this is accurate? If the answer is unclear or disputed, the field will drift. Ownership of data does not happen automatically. It needs to be assigned explicitly, usually to the person or team whose workflow depends on it being correct. Data without a clear owner accumulates errors because no one has both the information and the incentive to fix it.
04
Fix at the source, not in the report
Once the audit identifies where trust is breaking, the fixes should happen as far upstream as possible. Clearer field definitions. Enforced values where consistency matters. Explicit ownership at handoff points. Exception handling paths that record the exception in the system. The goal is a data model where the report is the simple part - presenting information that is already coherent - rather than the part that has to compensate for incoherence in the data below it.
The operating view
A data visibility view should make a decision auditable, not just make a number available.
A useful visibility view is not necessarily a new dashboard. It is the smallest shared view that lets a person answer five practical questions without finding the person who built the report: what is this number, where did it come from, who owns it, when was it last reliable, and what known exceptions change how it should be read?
This turns visibility from a display problem into an operating rule. When a number cannot answer one of these questions, the missing answer identifies the next repair: define the metric, trace the source, name an owner, add a freshness signal, or record the exception in the system.
Five answers to preserve
What every decision-critical number needs
Meaning: a written definition of what the number includes, excludes, and is intended to help decide.
Source: the system, fields, and transformation that produce it, so a correction has somewhere to start.
Owner: one named person who can resolve a definition conflict or a data-quality break.
Freshness: a visible signal showing when the data was last updated or when its source last completed successfully.
Exceptions: a recorded path for non-standard cases, with a link to the record or queue rather than an informal explanation.
What visibility actually looks like
Trustworthy data has three visible properties. Most data systems have one or two.
Visibility is not whether the data can be seen. It is whether someone who was not there when it was created can understand it, act on it, and trust it enough to flag a real problem.
Most data systems achieve partial visibility. The records exist. The reports run. But the numbers require explanation, or the exceptions are handled differently by different people, or the ownership is unclear enough that nobody feels responsible for fixing errors when they are found.
Understandable without context
A person unfamiliar with the system can look at a record or a report and understand what it means without asking someone who was there when it was created.
Actionable without translation
The data can be handed directly from the system to the person who needs to act on it. No intermediate step of explaining what the numbers mean, correcting for known quirks, or reformatting for a different audience.
Correctable with clear ownership
When an error is found, it is obvious who is responsible for fixing it and how it should be fixed. Errors that nobody owns either stay wrong or get corrected differently by different people, which makes the data worse over time, not better.
The silent failures
Data visibility problems are usually invisible until they cause a decision failure.
The most damaging data problems are the ones that nobody notices until something goes wrong. These are the patterns to watch for in any operational data system.
Silent failure 1
The metric everyone tracks but nobody trusts
A key performance indicator is on every dashboard. Everyone looks at it in every meeting. Nobody acts on it directly, because everyone knows the number is wrong in ways they cannot quite articulate. The metric is measuring the right thing but from data that is inconsistently maintained, so the absolute number is not reliable. Teams use it as a directional indicator but never as the basis for a concrete decision.
This is one of the most expensive forms of invisible failure, because the team spends real effort maintaining a metric that is not actually driving decisions. The fix is either fixing the underlying data or acknowledging that the metric is not useful in its current form and stopping the effort of maintaining it.
Silent failure 2
The report that is corrected before it is presented
Someone runs the report. They notice the numbers look wrong in the usual ways. They correct it manually before presenting it to anyone. This happens every week. Nobody has formally acknowledged that the report requires manual correction, so the correction step has become invisible - part of the normal process, not a sign that something is broken.
The correction step is important data about where the system is failing. Each manual correction identifies a specific data quality problem that should be fixed at its source. Instead, the correction happens silently and the underlying problem persists. The fix starts with making the correction step visible and auditing what is being corrected and why.
Silent failure 3
The field that means different things to different teams
A shared field in the CRM is used by sales, marketing, and account management. Each team has a slightly different understanding of what the field means, based on their own context for why they use it. Reports built from this field produce numbers that are technically correct but interpret differently depending on who is reading them. Disagreements about what the numbers mean are actually disagreements about what the field means.
These field definition conflicts are among the most difficult data problems to fix because they are entangled with team processes and historical habits. The fix requires a cross-team conversation about the intended meaning of the field, a decision about which interpretation wins, and a cleanup of the records that used the old interpretation.
Silent failure 4
The data that exists only in email
Commitments made in email that were never recorded in the CRM. Exceptions discussed in Slack that were never documented as exceptions. Special arrangements that exist in the memory of one person but not anywhere in the operational system. When that person is unavailable or leaves, the information disappears.
This is a structural failure, not a human one. The system did not provide a clear and convenient path for recording this information, so it accumulated outside the system. The fix is identifying the categories of information that regularly end up in email and adding explicit paths for capturing them - fields, notes, structured handover steps - so they are available to anyone who needs them later.
Fix at the source, not in the report
Every data correction applied at the reporting layer fixes the symptom but leaves the cause. The intake form, the field definition, or the handoff step where the problem entered is where the fix belongs, even when the symptom shows up three steps later.
Ownership must be assigned, not assumed
Data without a named owner drifts. The person responsible for a field's accuracy needs to be the person whose workflow depends on it being correct, not an IT team or a shared admin role. Explicit ownership is what separates data that gets fixed from data that accumulates errors.
Exceptions that happen outside the system become invisible
Manual workarounds, corrections made in email, and decisions recorded only in someone's memory are not exceptions the system can learn from or maintain. Building a clear path for recording the exception in the system converts a structural gap into a visible data point.
Field definitions should be written before the data is collected
The most expensive data problems come from fields whose meaning drifted over time because it was never written down. A definition agreed at the start, even if imperfect, is far cheaper than a cross-team reconciliation two years later.
The advanced control
A quality check is useful only when its failure changes what happens next.
A dashboard that reports a failing value after the decision has been made is evidence, not protection. Decision-critical data needs an explicit response rule: tolerate and measure the condition, isolate it for review, or stop the downstream update until it is resolved.
The exact tool is optional. The operating rule is not. This is Mannvit's model for applying common quality dimensions, such as freshness, completeness, validity, consistency, accuracy, and uniqueness, to the consequences of a specific workflow.
Choose the response deliberately
Three ways a quality signal can behave
Warn and measure: retain a low-risk record, label the failed expectation, and monitor whether the failure rate or trend changes.
Quarantine for review: keep the record out of the decision flow while preserving its source, failure reason, and owner for correction or replay.
Block the update: stop a consequential change when the invalid state would make the next system or person act incorrectly.
Review the signal itself: a freshness, completeness, or uniqueness check needs an owner, a threshold rationale, and a review date as the process changes.
Test the decision
A data-quality signal matters only when it changes what the next person can safely do.
This Mannvit learning model uses a synthetic onboarding account. Change the evidence to see why a valid-looking record may still need a warning, review, or a hard stop.
The point is not a data score. It is a visible response policy that gives a later operator the definition, source, owner, and reason for the decision.
Mannvit decision record
Make the number answerable before asking anyone to act on it.
This completed example shows the smallest record a decision-critical metric needs. The blank column is deliberately copyable: use it in a report definition, CRM note, or shared operating document before adding another dashboard.
| Decision | Completed example: accounts ready to onboard | Copyable decision-critical data record |
|---|---|---|
| Decision supported | Which accounts can receive an onboarding task this week? | <state the decision a person will make> |
| Definition and source | CRM accounts with `status = ready_for_onboarding`; excludes records missing owner, start date, or scope. | <define inclusions, exclusions, system, fields, and transformation> |
| Owner and freshness | Revenue operations owns the metric. It is only reliable after the CRM handoff job completed today. | <name the owner and the freshness requirement> |
| Quality checks | Required fields complete; account ID unique; source run complete; status matches the documented values. | <list the checks that protect this decision> |
| Response policy | Missing scope is quarantined for review. A stale source run blocks new task assignment. A low-risk formatting issue warns and is measured. | <choose warn, quarantine, or block for each meaningful failure> |
| Evidence and review | The report links each exception to its record and reason; the owner reviews recurring exceptions when the process changes. | <state where evidence lives and when the rule is reviewed> |
The decision test
Visibility is not showing a number. It is letting a new operator understand, challenge, and act on it without hidden context.
A report that needs a disclaimer is not ready for the decision it claims to support. The missing disclaimer belongs in the definition, source record, exception path, or ownership rule where the next reader can inspect it.
A metric stays trustworthy only when a named person can resolve a definition conflict or recurring quality failure.
Define the data-owner role ->evaluate the record against the decision-critical rules
if the source is stale:
block the downstream decision and show the source status
if a required field is missing:
quarantine the record with its reason and owner
if a low-risk format rule fails:
retain the record, warn, and measure the trend
preserve the rule, result, source record, and review path
so a later reader can challenge the decisionThe quality policy is an operating decision. It describes what the system does when data is not good enough for a particular consequence.
function assessOnboardingAccount(account, sourceRun) {
if (!sourceRun.completedToday) {
return { action: 'block', reason: 'Source run is stale' };
}
if (!account.owner || !account.startDate || !account.scope) {
return { action: 'quarantine', reason: 'Missing decision-critical context' };
}
if (!isNormalised(account.phone)) {
return { action: 'warn', reason: 'Low-risk formatting issue' };
}
return { action: 'accept', reason: 'Ready for the documented decision' };
}Illustrative JavaScript, not a generic data-quality library. The useful part is the explicit consequence: block, quarantine, warn, or accept, plus evidence for the owner who reviews it.
Fixing it
Data visibility is a property you maintain, not a problem you solve
The important constraint
Fix data problems as far upstream as possible. A fix at the report treats the symptom. At intake, the cause.
Every data quality problem has a point where it entered the system and a point where it became visible as a problem. The further apart those two points are, the more data has accumulated the error in the meantime and the more effort the fix requires. A field definition that is wrong from day one contaminates every record created after it. Fixing it after two years means reviewing two years of records, not just changing the definition.
Building for the long term
Data visibility is not a project with an end state. It is a property that requires maintenance.
A one-time cleanup can make a report look fixed without changing the conditions that caused the data to drift. The old inconsistencies return when a new record enters without a clear rule, exception handling moves outside the system, or a new team member interprets a field differently.
Data visibility degrades because business conditions change. New processes generate new data requirements. New team members bring different habits. New tools add new integration points where data can drift. A data system that was well-designed for last year's workflow may be poorly suited to this year's.
Mannvit guidance: treat data visibility as an ongoing operational responsibility, not a project deliverable. Revisit field definitions when a process, source system, or decision changes. Review exception paths when their pattern or consequence changes. Give each data area a clear owner who can spot drift and correct it before it becomes structural. Good data is not a state you achieve once. It is a condition you maintain.
Ongoing maintenance
Five practices that keep data trustworthy over time
Review field definitions when processes change, not only when the data is already wrong.
Review exception records when their volume, pattern, or consequence changes: decide which ones should become rules and which ones should be removed.
Name a data owner for each area whose responsibility includes quality, not just usage.
When a new tool is added, define the data contract before the integration is built, not after.
During operating reviews and after process changes, ask: "is there a number in our reports that someone has to explain before anyone acts on it?" Each explanation is a repair waiting to happen.
Common questions
Questions about data visibility
The data exists but it requires explanation before anyone acts on it. That gap, between data being present and data being trustworthy, is the definition of a visibility failure. It usually comes from inconsistent field definitions, missing ownership, exceptions handled outside the system, or reporting logic that compensates for problems in the data below it instead of fixing them.
Data quality is about whether the data is correct. Data visibility is about whether the data can be understood, acted on, and trusted by the people who need it, including people who were not involved in creating it. You can have high-quality data that has low visibility (correct records nobody can interpret without context) or low-quality data with high visibility (clear records that are clearly wrong). Both need attention, but they require different fixes.
Ask the people who present reports what they have to explain before anyone acts on the numbers. Each explanation identifies a visibility failure. Then ask what gets manually corrected before being presented, each correction identifies a data quality failure. Those two questions usually surface the most important problems faster than a technical audit.
A named person, not a team, who is responsible for the accuracy of a specific data area and whose own workflow depends on that data being correct. They are the person who notices when the data starts drifting, not because they were asked to check it, but because they use it. That is the only ownership model that holds over time.
For every decision-critical number, show its definition, source, named owner, freshness signal, and known exceptions. The format can be a dashboard, a CRM report, or a simple operating sheet. The test is whether someone can understand and act on the number without asking the person who created it for a verbal explanation.
If your data requires explanation before anyone acts on it, the visibility work starts with an audit.
Bring the report that is most frequently questioned, the field that means different things to different teams, or the dashboard that everyone looks at but nobody acts on directly. That is usually enough to find where the trust is breaking, what is causing it, and what needs to be fixed first to make the data useful again.
Bring the page, report, or workflow as it is now.
We reply with the clearest next step, or an honest no.
