Data quality & governance
You find out data is wrong when an executive asks why the numbers changed.
We put contracts, tests, lineage and access policies in code, so problems are caught upstream and audits take days, not months.
The problem
What we usually find
Upstream changes break downstream reports
A source team renames a column and three dashboards and a model feature silently start returning nulls.
Nobody can answer where a number came from
Auditors and regulators ask for lineage of a reported figure and the answer takes weeks of manual tracing.
Access is granted by ticket and never removed
Permissions accumulate. Sensitive columns are visible to far more people than policy allows.
Our approach
Four steps, each with a deliverable
- 01
Critical data elements
We agree with the business which tables and fields matter most and who owns each one.
- 02
Contracts and tests
Producers publish schema and quality contracts. Automated tests check freshness, volume, nulls and business rules on every load.
- 03
Lineage and catalog
Column-level lineage and ownership are captured automatically in Unity Catalog, Horizon or Purview.
- 04
Policy as code
Access, masking and retention policies are defined in code, reviewed like code and applied the same way everywhere.
Reference architecture
Deliverables
What you receive
- Register of critical data elements with named owners
- Data contracts and automated quality tests with alerting
- Column-level lineage in your catalog
- Access, masking and retention policies as code
- Audit evidence pack template
Typical timeline
How the work runs
Discover2 weeks
Critical data elements, owners and current controls.
Implement4–8 weeks
Contracts, tests, lineage and policies for priority domains.
Embed2–4 weeks
Alert routing, ownership rituals and audit evidence.
ExtendPer domain
Further domains onboarded with the same pattern.
Frequently asked questions
Which governance tools do you work with?
Databricks Unity Catalog, Snowflake Horizon, Microsoft Purview, plus open tools such as dbt tests, Great Expectations and Soda where they fit.
Is this a policy-writing exercise?
No. We write the controls as code that runs on every pipeline. Policy documents reference the implemented controls rather than the other way around.
How do you decide what to test first?
We start from the reports, regulatory submissions and models that would cause the most damage if wrong, and work back to their sources.
Can this help with regulatory audits?
Yes. Lineage, test history and access logs form an evidence pack for auditors and regulators such as those under SOX, HIPAA or DORA.
Who owns data quality after you leave?
Named business and technical owners for each critical data element, with alerts routed to them. We set up the ownership model, not just the tooling.
Have 30 minutes? Get a senior architect’s view of your data platform.
No sales deck. You talk to the engineer who would lead the work.
Book an architecture review