A data quality and cataloging system inside the UnifyApps data suite, designed for the analysts, stewards, and compliance teams who own data but were never given tools they could actually read. Built to sell into tier-one banks and financial institutions with data estates too large to check by hand.
The people who carry that accountability, the analysts, stewards, and compliance teams, rarely write code. Yet the tools built to help them were built for engineers. The gap between who owns data quality and who can operate the tooling is the whole problem.
We designed two products inside the UnifyApps data suite to close it. A Data Catalog that answers what data exists and where it lives, and a Data Quality product that answers how good that data is, and what to do when it isn't.
This is mostly the story of the second one. Data Quality was the deep build. Data Catalog came earlier as a focused, one-week project, and it shares one idea with Quality that turns out to be the spine of everything here.
A client asked for data governance, but UnifyApps chose to build it into the platform as something any enterprise could buy. That raised the bar: it had to generalize, not just satisfy one team.
Before we could design a single screen, we had to understand a domain neither of us knew: connectors, sources, master data management, ETL pipelines, and the ontology that ties them together. We read the documentation for Ataccama, Informatica, and Reltio closely, and worked through how data actually moves through an enterprise.
Research and problem framing were led by the product team. Our job was to take a domain that resisted simplification and give it a shape.
The incumbents were not missing features. They were missing legibility. Three failures kept surfacing across all of them, and each one became something we set out to fix.
At enterprise scale that means thousands of columns and thousands of near-identical rules. The work was never finished, and it never could be.
Catalog, profiling, quality, and remediation lived as separate modules with separate mental models. Users hopped between disconnected tools and rebuilt their context every time.
Capability was exposed through dense, engineer-first interfaces. Where these tools added intelligence, it arrived as a black box that quietly made decisions for you.
Legacy tools expose hundreds of capabilities flat, with no narrative to hold them. We needed a structure simple enough that a steward could carry it in their head and have the rest of the product make sense. So we cut it to a sequence: define the language, attach the rules, run the loop.
Once a user understood "define the language, attach the rules, run the loop," the surface stopped feeling like a control panel and started feeling like a workflow. The next three sections walk down those layers, and the hardest design problem lives inside each one.
Quality rules applied per column do not scale. Define "valid email format" once and you would still have to re-apply it to every email column, in every source, forever. That is the trap every legacy tool fell into.
So we made Terms the unit of governance. You attach a quality rule to the Term "Email," not to a column. Detection rules map that Term onto every column that qualifies, and the rule cascades to all of them automatically. Define once, govern everywhere.
This matches how stewards already think. They reason about kinds of data, all our email fields, not individual columns. The product now reasons the same way they do.
We softened that with profiling and AI suggestions that build part of the glossary for you, but the cost is real, and it is the thing we would tackle first if we did it again.
Rule logic is genuinely technical: input attributes, datatypes, modifiers, conditions, scores. A business steward cannot read a raw expression. A power user needs real expressiveness. Designing for one group usually breaks the other.
We built a rule builder that reads as a sentence. The condition sits on the left, the result and its quality dimension on the right, and every rule is testable against live sample data before it is saved.
A power user can still reach the rule library and custom logic when the readable form runs out. We accepted that the readable abstraction cannot express every exotic condition, and kept an escape hatch for the few cases that need it, rather than punishing the majority with complexity they will never touch.
This was a legacy category, and we wanted intelligence to earn its place. But in governance and compliance work, an AI that silently changes rules or auto-classifies data destroys the one thing the product sells. So we drew a hard line: AI never acts on its own.
Profiling a source surfaces AI insights and suggested rules, which you review and approve before any of them become real. Term suggestions propose a classification you confirm. Anomaly detection flags unusual data, but it does not quarantine it. Intelligence accelerates the setup and watches for the unexpected. The human stays the authority on every governing decision.
In legacy tools, defining rules, running evaluation, reading results, and fixing data were four disconnected places. We collapsed them into a single container: the monitoring project.
It holds the whole lifecycle. Connect a source, attach rules, profile it, run a scan, read the dashboard, and route failures onward through threshold alerts and auto-created tickets, with re-evaluation after a fix closes the loop.
It maps to the actual job, which is not running a scan once but owning a dataset's quality over time. One object the user returns to, instead of four tools they have to reassemble in their head on every visit.
New users land on an empty monitoring project with no data yet. Most products leave that moment blank. We designed it to show exactly what happens next: three steps, three icons, one clear action to begin. The empty state is the onboarding.
Catalog was a focused, one-week build, so we treated it as the supporting story it is. It answers the question Data Quality assumes you have already solved: what data do we even have, and where does it live?
Every connector configures differently. Salesforce, Snowflake, and Kafka each need different inputs. Kafka needs schema setup; tables and views need an exclude pattern; some metadata should be skippable. A static form is wrong for all of them, and a hand-built form per connector is unmaintainable.
So we designed one creation flow with a form that generates itself from the chosen connection. You always see exactly the fields that connector needs, and nothing else.
The standout surface is lineage: a visual graph of data flowing from upstream sources, through a base object, out to the downstream views that depend on it. It turns an abstract dependency into something you can read in a second.
Catalog and Quality were separate products on separate surfaces. But they speak the same language, and that is what makes them feel like one platform rather than two tools sold together.
Terms defined and tagged in the catalog are the exact Terms that quality rules attach to. Catalog tells you what exists and where. Quality tells you how good it is. The shared vocabulary is the seam that disappears.
We took a domain built for engineers and gave it a shape that an analyst, a steward, or a compliance lead could actually navigate. The product was positioned for the institutions that need it most: large banks with data estates far too big to check by hand.
No fabricated metrics appear in this case study. Outcomes are described at the product level.
← Back to all work