Data Quality
Business users say what good data looks like, data stewards turn it into checks that run on the right columns, and Alex shows whether each rule is meeting its target.
Where it fits first
Put a clear, owned rule on every CDE your reports and regulators rely on, and see the result next to it.
Attach rules to the definitions people already use, so a quality result reads like the business question it answers.
One rule, written once, checked across every column that carries that concept, on any relational database or cloud platform.
The problem
In most teams, data quality checks live in a file the business never sees, and the same check gets rebuilt for every request. Alex puts the people who define good data and the people who check it on the same page.
How it works
Step 01 · Detect
Step 02 · Understand
Step 03 · Act
Step 04 · Govern
Your stewards build the check once. Each team sets its own target.
Built for
Write the rule in your own words, on the data you own, and see whether it’s being met without learning a scanner’s language.
One workbench for every request, with reuse built in, so you implement each check once instead of rebuilding it.
See which critical data has an active rule, which doesn’t, and how each rule is performing against its target.
A plain-English statement of what must be true about your data, such as “a customer’s email must be a real, deliverable address”. It’s attached to the critical data elements, business terms or metrics it applies to, and a data steward turns it into one or more executable checks.
No. Business users choose from a list of check types and set a target. The checks reach the right columns through the links your business definitions already have to them.
The steward decides how each requested check runs. They can reuse an existing check, build a new one, adjust it for a specific platform, or ask the requester a question. Stewards can also check technical columns, such as load timestamps or staging tables, directly.
Every check has a unique signature. When an identical one exists, Alex offers it for reuse, and building a second copy needs a written reason.
Per rule and per column, with a red, amber or green sign against the rule’s target. Columns that were scanned are counted apart from columns that were actually measured, so a failed query or empty table isn’t reported as checked.
Snowflake, Databricks and SQL Server today. Because checks are built for relational databases, adding others such as Oracle or MySQL takes very little effort, so we can extend to whatever your estate runs on.
Yes. Alex logs every action by every user: who wrote or edited a rule, who approved a check, and when. That log gives you a full audit trail for regulators and internal audit, and lets you monitor activity across your data quality work. Any change can be undone, and checks are never deleted. Unused checks are retired and can be switched back on later.
Yes. Alex runs the full data quality cycle in one place: business users write the rules, stewards build the checks, Alex scans your data and reports every result against its target. Because it sits alongside your catalogue, lineage and audit trail, there’s one less tool to license, integrate and maintain. If you’re thinking about retiring your current data quality tool, we’ll help you move your existing rules across.
Straight away. If you have a business glossary, whatever you call its entries, you can start writing rules on day one. Alex links each rule to the data it describes for you.
We’ll walk a rule through the full cycle, from a business user writing it to a steward implementing it and the result coming back against its target.
