Data
AI
The Stack Underneath
Hello, we are BRILLIAN’S. Trying to make an effort to put the right people for you to get the best results. Just insight !
Most data quality frameworks look fine on the day they're presented. Someone maps the dimensions, picks a scoring model, names a few owners. Everyone agrees it matters. Then the pipelines get rewritten, nobody goes back to update the rules, and a few months later you've got a green dashboard sitting on top of numbers that stopped being right a while ago.
We inherit stacks like that fairly often. The framework was real. It just quietly stopped doing anything.
A data quality framework is the set of rules, checks, and ownership that keeps your data trustworthy as it moves between systems. The definition is the easy part. Keeping it alive once the data and the team and the requirements all start changing underneath it is where most of them fail, and that's the part this guide spends the most time on.
A data quality framework is the set of standards, rules, and ownership your organization uses to keep data accurate and usable as it moves through your systems. It defines what "good" data means for you, how you measure it, who fixes it when it slips, and how you keep checking over time. Think of it as the agreed-upon system that turns "we hope this data is right" into "we know it is, and here's how."
That last part depends on one thing people skip past: data quality isn't an absolute score you stamp on a table. It's how well the data fits the job you need it to do. A customer list with 90% accurate emails is fine for a rough headcount and a disaster for a billing run. Same data, different verdict. That's why a good framework starts from what your business actually decides with the data, not from a generic checklist someone found online.
So the definition is easy. What the framework does day to day is where it gets real.
A framework's real job is to catch problems before they reach the people making decisions. It sets the rules for what counts as acceptable, runs checks against those rules automatically, flags what fails, and routes it to whoever owns the fix. Without one, you find out your data was wrong the way most teams do: a number looks off in a board deck, someone traces it back through four systems, and three weeks later you learn a schema changed in March. A working framework moves that discovery from "after the damage" to "before anyone saw it."
If you strip it all the way down, a DQ framework is a repeatable way to define, measure, and defend the quality of your data. The word that matters most there is repeatable. A one-time cleanup is a project. A framework is the thing that keeps data clean after the consultants leave and the pipelines change, which is exactly where most of them quietly stop working.
The seven components of data quality are accuracy, completeness, consistency, timeliness, validity, uniqueness, and reliability. Together they decide whether a dataset is trustworthy enough for the job in front of it. You'll see these called components in some places, dimensions or pillars in others. Same properties, different labels. Each measures something different, and each fails in its own way, so it's worth knowing where they break, not just what they mean.
Does the data match the real world? An address is accurate when mail arrives there, not when it passes a format check, and that gap is where teams get burned. Data can be perfectly typed, fully populated, valid on every rule you throw at it, and still be wrong. We've audited stacks where every field looked clean and a third of the phone numbers were years out of date. Nothing caught it, because being out of date isn't a formatting error. Accuracy is the hardest one here to measure automatically, and the most expensive when it slips.
Completeness isn't about how many rows you have. It's whether the fields your decision leans on are filled in. A user record with no signup date works fine for logging someone in and falls apart the moment you build a cohort analysis. And the gap hides where you won't look. Ninety-five percent of records having an email seems healthy until the missing five percent turn out to be every enterprise account you own.
Store one fact in three systems and, sooner or later, the three disagree. Your CRM says the customer churned; billing is still charging them. Which one is right? Consistency forces that question early, before it becomes two teams in a room with two numbers. It breaks hardest in companies that grew by bolting on tools, because each new tool brings its own version of the truth and nothing decides which one wins.
Data has a shelf life, and the decision using it sets the expiry. Twelve-hour-old numbers are fine for a Monday review and dangerous for a fraud check. Almost nobody writes down how fresh the data has to be, so a lagging pipeline breaks no rule until someone acts on stale numbers and finds out the hard way.
Validity asks one narrow question. Does the data follow its own rules? Future birth dates, impossible country codes, a negative order quantity. Most teams catch these, because they're the easiest checks to automate. The catch is false comfort. Data can pass every validity rule and still be wrong about the world.
You think you have 50,000 customers. Eight thousand are the same people entered twice, and now every count sits on an inflated base. Uniqueness keeps each real thing appearing once. It gets filed under cleanup and postponed, which is how it turns permanent. Duplicates don't sit still. They multiply through every report downstream.
Reliability is whether you can trust the data to behave the same way every time you pull it. The other six can each look fine in a single snapshot; reliability is about consistency over time and across sources, so the same query run on Tuesday and Friday tells the same story. When a number moves and nobody changed the underlying facts, reliability is what broke. It's the component people notice last, usually right after they've staked a decision on a figure that quietly shifted underneath them.
You don't have to invent a framework from scratch. Several established ones already exist, built by standards bodies and researchers, and they're worth knowing before you build your own. The catch is that most were designed for large, regulated institutions, so treating them as rigid systems to adopt wholesale is usually a mistake for a normal engineering team. Read them as references to borrow from. Here are the four you'll actually run into.
Developed at MIT, TDQM applies the logic of total quality management to data through a repeating loop of define, measure, analyze, and improve. Its strength is the hands-on, iterative approach to finding the root cause of data issues and fixing them. Of the four, it maps most closely to how a working team actually operates, which is why the implementation approach earlier in this guide echoes its four stages.
This is the formal international standard for data quality management, aimed at organizations that need rigorous standardization, think manufacturing, aerospace, healthcare. It runs on a Plan-Do-Check-Act cycle and folds the TDQM methodology into its core. One useful idea it carries is treating data quality as context-dependent rather than absolute, the same dataset can be right for one purpose and wrong for another. If you're in a regulated industry, this is the one auditors will ask about.
Built by the International Monetary Fund, the DQAF was designed to assess statistical systems, not typical business databases. It tracks quality across dimensions like integrity, methodological soundness, accuracy and reliability, serviceability, and accessibility, and it's used mainly by governmental and international bodies. Unless you're doing policy analysis or official statistical reporting, this is more reference than roadmap.
The Data Management Body of Knowledge is less a single framework than the field's reference encyclopedia, covering data quality as one piece of a much wider governance picture. Teams reach for it when they want the vocabulary and the standard definitions rather than a step-by-step method. It's thorough, and it's a lot, so most teams use it as a lookup, not a plan.
Before you build a framework, you need to know how bad things actually are. A data quality assessment is the audit that tells you, measuring your current data against the seven components so you're working from a real baseline instead of a hunch. Skip it and you end up writing rules for problems you imagine while the real ones keep shipping.
Most teams think their data is in worse shape than it is in a few places and far better than it is everywhere else. The assessment is what corrects that instinct. Here's the shape of one that works.
Start by looking at what you actually have, table by table. Profiling means running the numbers on your data itself: how many nulls in each column, how many duplicates, what the value ranges look like, where the formats break. This is the step that surfaces the surprises, the "why are there negative ages in this table" moments. You can do a first pass with SQL and a few queries. If you want a faster read on where a dataset stands, our data quality assessment tool runs the profiling for you and scores the result.
Profiling tells you what's in the data. Scoring tells you whether it's good enough. Take each component that matters for a given dataset and put a number on it: what percentage of records are complete, how many fail validation, how stale is the freshest table. The point isn't a perfect grade. It's a baseline you can measure against later, so when someone asks whether data quality improved this quarter, you have an answer that isn't a shrug.
Not every gap is worth fixing. A 3% duplication rate in a table nobody queries is noise. The same rate in the customer table your revenue reporting runs on is a real problem. This step is ranking the gaps by what they actually cost, which decisions they corrupt, how much money or trust rides on those decisions, and starting there. A good assessment doesn't hand you a list of 40 things to fix. It hands you the three that matter and the reason they're first.
Most framework rollouts fail the same way. The team tries to fix everything at once, the effort sprawls, momentum dies, and six months later there's a half-built system nobody trusts. A framework that works gets built in a specific order, and it starts far smaller than people expect. You're not boiling the ocean. You're picking one dataset that matters and proving the loop works before you scale it.
Here's the order we'd actually build it in.
Start with one dataset, not the whole warehouse. Pick the one feeding your most important decision, the revenue table, the customer master, whatever a wrong number would hurt most. Getting the full loop working on a single high-stakes dataset teaches you more than a shallow pass across fifty tables ever will. Scope creep is what kills these projects, so the discipline here is saying no to everything that isn't the first dataset.
For that dataset, decide which of the seven components actually matter and write the specific rules that enforce them. Not "data should be accurate," but "every order must have a valid customer ID that exists in the customer table." Rules have to be concrete enough to run as code. This is also where a broader data governance framework earns its keep, because the standards you set here should line up with how the rest of the organization defines and governs its data, not contradict it.
Every rule needs a name attached, a person accountable when it fails. This is the step teams skip, and it's the reason most frameworks quietly die. A check that fails into a shared inbox is a check nobody owns. Ownership is also where data quality starts touching data stewardship, the wider practice of making specific people responsible for specific data over its whole life. Without that layer, your rules run and their alerts pile up unread.
Now turn the rules into automated checks that run where the data moves, in your pipelines, not in a spreadsheet someone updates by hand. The check should run every time the data does, catch failures at the point they enter, and log what it found. Manual quality checks don't survive contact with a busy quarter. If a human has to remember to run it, assume it won't get run.
A framework is not a launch, it's a habit. Once the checks are live, watch them, and expect the first weeks to be noisy. Some rules will be too strict and cry wolf; others will miss things you thought they'd catch. Tune them. Then, once the loop is solid on the first dataset, extend it to the next one. The framework grows dataset by dataset, and each one is faster than the last because the pattern is already built.
Every framework looks healthy on launch day. The interesting question is what it looks like in month eight, because that's when the ways they fail start to show. We see the same four failure modes over and over when a client hands us a framework that stopped working, and none of them are about the technology. They're about what happens after the setup, once attention moves on.
The rules you wrote were correct for the data as it existed the day you wrote them. Then the data changed. A new field got added, a source system got swapped, a pipeline got rebuilt, and nobody went back to update the checks. Now half your rules are testing for conditions that no longer apply, and the ones that still run are quietly missing the new failure modes. Decay is slow and invisible, which is what makes it dangerous. The framework doesn't announce that it's out of date. It just protects you less each month until a bad number gets through and you realize the checks haven't meant anything since spring.
A check that fails to nobody gets fixed by nobody. This is the failure we see most, and it almost always traces back to ownership that was assigned to a team instead of a person, or never assigned at all. Alerts fire into a shared channel, everyone assumes someone else is handling it, and the failures pile up until the channel becomes noise people mute. The technology worked perfectly here. It caught every problem. There was just no human on the other end whose job it was to care.
Some rules look great in the design doc and fall apart the moment they meet real data. A completeness rule that demands every field be populated sounds rigorous until it starts blocking legitimate records that were always allowed to have nulls. A strict validity check flags so many false positives that the team starts ignoring it, which means it's now worse than no check at all. The pattern is always the same. A rule written in theory meets the mess of production, generates noise instead of signal, and gets switched off. Rules have to survive contact with real data, and the only way to know if they do is to watch them run and tune them, not to write them once and walk away.
The opposite problem, and just as common. Over time the team keeps adding checks, nobody ever removes one, and eventually there are four hundred rules, half of them redundant, a quarter of them broken, and no one who understands the whole set. Sprawl makes the framework impossible to reason about. When everything is monitored, nothing is prioritized, and a genuinely important failure gets buried under fifty trivial ones. More rules is not more quality. Past a point, it's less.
Notice that none of these are tooling problems. You can run the best data quality software on the market and still hit all four, because the failure is in the operating discipline, not the platform. This is also why quality tends to unravel right after a big migration. When teams move onto a platform like Snowflake or Databricks, the pipelines get rebuilt, the old checks don't come along, and the framework silently resets to zero while everyone assumes the shiny new stack handles quality on its own. It doesn't. A platform moves your data faster. Whether that data is right is still on you.
If there's one thing to take from all of this, it's that a data quality framework succeeds or fails on operating discipline, not on the tool you buy or the standard you cite. The teams that get this right start small, put a real person's name against every rule, and treat the framework as something they maintain rather than something they launch. The ones that struggle do the opposite, roll out everything at once, assign ownership to a team instead of a person, and walk away expecting it to hold. It never does.
So before you spend a quarter building one, get honest about where your data actually stands today. Run a real assessment on your single most important dataset, the one a wrong number would hurt most, and score it against the components in this guide. If you'd rather see a baseline in minutes than build the profiling yourself, our data quality assessment tool will give you one to start from.
And if your data quality problem is really a data engineering problem underneath, broken pipelines, a stack that lost its checks after a migration, sources that don't agree, that's the work we do. We've spent a lot of time inside stacks where the framework existed on paper and stopped meaning anything in practice. If that sounds like yours, a short conversation will tell you whether it's a framework fix or something deeper. Either way, you'll leave knowing which.
Dimensions are the properties you measure, like accuracy and completeness. A framework is the wider system of rules, checks, and ownership that uses those dimensions to keep data trustworthy over time. Put simply, dimensions tell you what to measure, and the framework is how you act on what you find.
Getting a working loop running on your first dataset takes weeks, not months, if you keep the scope tight. The mistake that stretches it into a quarter or more is trying to cover every table at once. Start with one high-stakes dataset, prove the cycle of rules, checks, ownership, and monitoring works there, then extend it. Each dataset after the first goes faster because the pattern already exists.
You can start without a dedicated tool. A first framework can run on SQL checks inside your existing pipelines, and plenty of teams begin exactly there. A tool earns its place once the number of rules and datasets grows past what's easy to manage by hand. The framework is the discipline. The tool just makes running it at scale less painful, and buying one without the discipline in place solves nothing.
Review the rules any time the data or the pipelines change, and on a regular cadence even when they don't. Frameworks fail quietly through decay, where rules written for old data keep passing while missing new problems. A monthly check on which rules are firing, which are noisy, and which have gone stale is enough for most teams to catch drift before it costs them a bad number.
Run an assessment before you build anything. Profile your most important dataset, score it against the components, and rank the gaps by what they actually cost you. Most teams are wrong about where their data is weakest, and the assessment corrects that instinct so you spend effort on the problems that matter instead of the ones you assumed were there.
You might also like
