During a recent conversation with The Executive Outlook, Justin Heller described a data quality problem that many organizations may not realize they have. Imagine a CEO opening the company’s new AI assistant and asking about the strategy behind a current growth initiative.
The answer arrives in seconds. It sounds polished, confident, and completely reasonable. There is only one problem. The AI built its answer from a strategy document written twenty years ago. The information may be complete. The document may be authentic. Every number may match the original source. Yet the answer can still be wrong for the business today.
For Justin, this is why traditional data quality dimensions are no longer enough on their own. He has spent nearly thirty-five years working where data, technology, process, and business meet. His career includes almost eleven years as Chief Data Officer of Synchrony Financial, where he developed large-scale data quality and data-sharing programs, including patented approaches in data quality and data sharing.
Today, Justin works as an advisor and fractional CDO, teaches AI governance and ethics, and previously served as Chief Data Officer of Synchrony Financial.
His argument is straightforward. Accuracy, validity, and data completeness still matter. But AI introduces another question leaders cannot afford to ignore it. Is the information still relevant? That question changes how organizations need to think about data quality.
Justin’s path into data did not begin with technology. His undergraduate background was in political science and game theory, where he became interested in empirical study and the process of forming a hypothesis, gathering evidence, and testing whether the facts supported it.
He describes the world as operating through facts and beliefs. In society, beliefs become social contracts and laws. Inside organizations, they often become policies. Data provides the facts that help determine whether those beliefs are still held. He later studied interactive telecommunications, which focuses on how people interact with information and technology. That naturally moved him toward work at the intersection of people, processes, and technology.
That intersection has remained central throughout his career. It is also where many of today’s biggest data management challenges appear.
He makes an important distinction when he talks about data quality checks. A data quality rule is detective control. It does not necessarily prevent bad information from entering a system. Instead, it detects whether the information meets the requirement that has been defined for it.
That difference matters. Take a Social Security number. There are clear validity rules. Certain patterns are invalid, and some number combinations should not be accepted. But before an organization can test those rules, it needs to know where the Social Security number appears across its systems.
It may exist in one column, twenty columns, or hundreds. That is why data catalogs have become so important. The catalog connects a business concept, such as a Social Security number, with the actual locations where that information exists.
Once those connections are known, the organization can apply the appropriate rules wherever they belong. Without that foundation, a data quality check may tell you something about one location while leaving dozens of others untouched.
At Synchrony, he turned this idea into what he describes as a supply chain for data quality. The process is connected to business terminology, metadata, system locations, data rules, workflows, and automation. A person could define what needs to be tested and identify where the rule should apply. Natural language processing could help identify other columns that appear to contain the same type of information. A human then confirmed the relationship.
If a rule had been assigned manually to three columns and the catalog identified five more columns holding the same information, the workflow could surface those additional locations and ask whether the rule should apply there as well. The scale eventually became significant.
After the first year, the program had around 200 automated data quality rules operating across four platforms. By around year eleven, it had approximately 10,000 rules running across roughly 45 platforms, supported by a team of about eight people. For executives, the lesson is important.
One of the common assumptions around data quality is that more control requires more people. Justin’s experience points to another approach. Build the metadata and orchestration foundation correctly, then let automation carry up much of the volume.
Traditional data quality dimensions commonly focus on areas such as validity, accuracy, and data completeness. AI introduces another dimension that he believes deserves far more attention. Relevance. The question is no longer only whether the information is correct. It is whether the information is still appropriate for the decision being made. When was it created? How long has it been retained? Who can access it? When was it last used? Does it still reflect how the business operates?
These questions become especially important when generative AI can search across documents, spreadsheets, PDFs, shared drives, and collaboration environments.
A twenty-year-old strategy document may still be accurate as a historical record. That does not make it useful for answering a question about the company’s current strategy. Without appropriate metadata, retrieval logic, lifecycle controls, and context, an AI system may retrieve or use information that is technically accurate but no longer relevant to the question being asked.
If the information remains available, the model may use it. That is why relevance belongs to modern conversation about data quality.
For years, organizations often treated structured and unstructured information as two different worlds. Traditional data management focused heavily on structured systems, tables, fields, and columns. Records management focused more on documents, retention, lifecycle management, and other forms of unstructured information. AI is forcing those worlds together.
Justin’s view is that a company cannot be genuinely AI ready if it manages only its structured repositories well. Its documents matter too.
So do spreadsheets, PDFs, collaboration files, records, and other sources that an AI system may be allowed to access.
This is why unstructured data management now needs many of the same capability organizations to have built around structured information.
Cataloging, discovery, observability, classification, retention, and context all become part of the same conversation. The objective is not to keep everything forever. In fact, keeping too much can create its own problem.
Privacy provides a useful example. If someone asks an organization what personal information it holds about them, the company needs to know what personal information exists and where it sits. If someone has the right to request deletion, the organization also needs to understand which records can legally be removed and which still need to be retained.
That requires connecting data definitions, repositories, records, retention periods, and legal obligations. Once those connections exist, organizations can begin disposing of information when there is no longer a valid reason to retain it.
That is good for privacy. It may also be good for AI. An AI system working across a repository full of outdated information has more opportunities to retrieve something that is technically available but no longer useful.
Removing unnecessary information can improve the relevance of what remains. The connection matters. Data minimization is not only a compliance exercise. It can become part of data quality for AI.
Another example from Justin’s experience involves third-party data sharing. When information leaves an organization, security is only one part of the issue. He separates the problem into obligations and risk. Obligations are the conditions the company must satisfy because failing to do so can create liability. Risk goes further.
Even if an action is technically permitted, does it create exposure beyond what the company is willing to tolerate? Contracts may specify which data can be shared, why they can be shared, who can receive them, and how they should be protected.
But contracts have changed. Data can be overshared. Information can be used for a purpose that was never agreed upon. An automated feed may continue sending information after the underlying contract has ended. He and his team built a workflow that assessed around sixty different dimensions of risk and routed requests through functions such as contract management, legal, information security, and procurement. The process included preventative controls. But preventative controls were not enough.
Organizations also need detective control. A contract may say that data should be shared with a particular party. But is that what is actually happening? Is the correct information being sent? Is it reaching the right recipient? Is the frequency appropriate? Has someone bypassed the approved process?
Has the agreement ended while the automated feed continues? These questions require monitoring. Justin connects this with a principle commonly used in information security. Trust but verify. The same principles can apply to data management. Organizations cannot inspect everything manually on a scale.
They need measurable indicators, defined thresholds, and clear procedures for what happens when something moves beyond the company’s risk tolerance. Monitoring identifies the exception. The operating process determines. What happens next?
One of his strongest warnings to data leaders is about perfection. Data professionals often want everything to be correct. Every field. Every control. Every process. Every piece of metadata. But businesses cannot always afford perfection. There is also a cost to moving too slowly. Justin’s alternative is risk-based. Understand what can go wrong. Understand how serious the impact would be. Define what level of imperfection the organization is willing to tolerate. Then build controls that prevent the business from moving beyond that tolerance and detect when something goes wrong.
This creates a more practical approach to governance. The goal is not to eliminate every possible problem, but to understand which problems matter enough to act on.
He is equally clear about what governance should not look like. It should not operate like a police state. When governance becomes primarily about stopping people, checking boxes, or enforcing rules without context, employees begin to see it as an obstacle. That makes adoption harder.
For him, governance is better understood through oversight, engagement and adoption. Its role is to oversee the processes that evaluate risk. When a problem exceeds the agreed tolerance, governance should make sure it reaches the right person. Sometimes that person sits in data management. Sometimes in technology. Sometimes in security, legal, procurement, privacy, or another part of the organization. Governance does not need to own every problem. It needs to make sure the problem does not disappear between organizational boundaries.
Justin’s closing advice for CDOs begins with language. Do not think of data management as an initiative. An initiative usually has a beginning and an end. It behaves like a project. Data management does not work that way. It is a collection of processes that help operate the company. Those processes continue for as long as they create value. This distinction matters because treating data management like a temporary project can lead organizations to fund a capability, launch it, declare completion and then move on.
But data keeps changing. Systems change. Regulations change. Business priorities change. AI changes how information is used. The processes therefore, they have to keep operating.
Justin’s second lesson is about organizational design. There is no single data operating model that works for every company. Accountability and responsibilities need to fit the way the organization actually works. A highly centralized company may require one model. A federated enterprise may need another. Culture matters too. So is the reason the data office exists in the first place.
The operating model should support the business rather than force the business to work around the data function. That is especially important for CDOs trying to build long-term credibility.
Justin’s third lesson may be the most important thing. Do not begin with a capability simply because the capability exists. Organizations often start with technology. They decide they need a catalog, a governance platform, an AI tool, or a new architecture. Then they search for the problem that justifies it. He argues for the opposite direction. Start with a business problem. Define the outcome. Then decide what process, capability, or technology is actually required. Sometimes the answer may involve new technology. Sometimes it may simply require redesigning how people work. That distinction matters because much data management is ultimately about changing behavior. Technology supports that change. It does not automatically create it.
The conversation around data quality dimensions is changing because the way organizations use information is changing. Accuracy still matters. Validity still matters. Data completeness still matters. But AI adds questions about context, retention, access, lineage and especially relevance. A document can be perfectly accurate and still be the wrong document for the decision being made. That is the shift leaders need to understand. The challenge is no longer simply determining whether the data is correct. It is determining whether the right information is reaching the right process, person, or AI system at the right moment.
Doing that requires more than another data quality tool. It requires connected metadata, structured and unstructured data management, clear risk tolerances, automation, governance and processes that continue operating as a business change.
Justin’s broader point is ultimately about business value. Data management should help protect the business. It should help run the business. And it should help grow the business.
When those outcomes guide the work, data quality stops being a reporting exercise. It becomes part of how the organization operates.
Are you a CIO, CDO, data leader, or AI executive or technology founder with a perspective that can help global leaders make better decisions?
Share your experience, leadership lessons and industry insights with an executive audience. Get featured in The Executive Outlook and join the conversations shaping the future of data, AI and digital transformation.
Listen in for business strategies and interviews with business experts to help you build a business and a life that you love.
About Us
