Checking a data model’s documentation against the data

From my résumé Figures from my résumé; examples are made up

Verified the documentation of an interaction model of about 400 million rows from about 25 platforms against the data itself, with SQL profiling and a Snowflake Cortex agent for the open questions.

Status: My job at EDF · no employer data shown
Relevant to: Data engineering, AI and automation

Results · Figures from my résumé; examples are made up

rows, roughly, in the model checkedFrom my résumé
source platforms, roughly, feeding itFrom my résumé

The problem

The model’s documentation described keys, columns, dates and metric meanings that didn’t always match the data. Every report built on the model inherits those mistakes.

My role

I combined the model’s documentation with SQL profiling, tested each documented assumption, and used a Snowflake Cortex agent to work through the questions that were still open.

How it works

1.Read the docs
Turn each documented column, key and metric definition into a claim that can be tested.
2.Profile
Run SQL checks for each claim: uniqueness, date ranges, null rates, values by source platform.
3.Compare
Flag every place the data disagrees with the documentation.
4.Ask
Use a Cortex agent to work through open questions against the model.
5.Fix the docs
Update the documentation and raise the data issues with the owners.

What I built

Documentation (YAML) combined with SQL profiling, so each documented assumption had a check.
Composite-key uniqueness tests.
Checks that found unexpected dates and inconsistencies between source platforms.
Findings of metrics whose meaning differed from their documentation, and of documented columns that don’t exist.
A Snowflake Cortex agent used to work through the remaining questions.

Example

Documented claim	Check	Kind of finding
(platform, event_id) is unique	Count rows per key above one	Duplicate keys from one source
event_date is the action date	Compare with load dates and ranges	Dates in the future or before the platform existed
column “channel” exists	Look it up in the schema	Documented column that doesn’t exist
“actions” counts actions	Compare definitions across sources	Same name, different meaning

Made-up checks showing the method. Not the real model, columns or findings.

In code

-- Is the documented key really unique?
select source_platform, event_id, count(*) as rows_per_key
from interactions
group by source_platform, event_id
having count(*) > 1
order by rows_per_key desc
limit 50;

A reconstructed example of one check, not the real query. Names are made up.

Decisions and tradeoffs

Treat documentation as testable claims: Reading docs and data side by side misses things. Turning each statement into a query makes every mismatch visible.
Use the AI agent for questions, not for answers: The Cortex agent sped up working through open questions, and its answers were checked with SQL before anything changed in the docs.

Limitations

Described without employer data: no schemas, model names or queries. Examples are made up.

Why it matters for the job

Analytics engineering and data governance roles need someone who doesn’t trust a model just because it’s documented, and who can check it at scale.

Stack

Snowflake, SQL, Snowflake Cortex, YAML

Finding 44K members missing from the CRM
My job at EDF · no employer data shown
Revenue numbers everyone agrees on
Code on GitHub