About
I make data trustworthy, then make it easy to use.
I'm a data engineer on the path to AI engineering. My work spans BI, cloud warehouse engineering, pipeline orchestration, a Python backend service and, more recently, a governed layer that lets AI tools answer questions from vetted definitions instead of improvising.
The thread through all of it: data people don't trust is data they don't use. So I spend my time on the less glamorous parts, such as definitions, governance, verification and documentation. I've written 55 internal documentation pages because a system only one person understands isn't finished.
Outside work I run a small self-hosted homelab with production habits, and I'm building a personal-finance dashboard to the standard of the apps I use.
How I work
What shipping these taught me
Governance, not model wiring
Connecting an LLM to a warehouse is the easy part. Making sure it answers from definitions people already agreed on is the work, which is why the view layer underneath matters more than the model on top.
Governed LLM data layer →Turn "history can change" into a decision
If a report reads live rows, later edits rewrite the past. I didn’t pick a behaviour quietly. I laid out the options so the person who owns the number could choose.
Commission automation →Prove the document wrong with data
A definition that is written down feels settled. Measuring how the flag actually behaved, and finding it covered about 42% of prospects, turned an argument into a decision.
Sales data quality →Verify the cutover, don’t declare it
At 909 connections, “I think we got them all” isn’t good enough. A defined end state of zero left, plus a data-return check, is what makes a migration finished.
Connection migration →Use identity, not secrets in config
Getting a managed identity, its scopes and runtime secret retrieval right was harder than the application logic, and it is why the service has nothing sensitive in its repository.
Health monitoring →Reverse-engineer before you refactor
A long chain of stored procedures with hard-coded assumptions can’t be changed safely until someone has turned it into a model other people can read. Documenting the chain and making its parameters data-driven were both part of the work.
Margin forecast pipeline →
Skills
What I use, and how deeply
Sorted by evidence rather than aspiration. “Core” is daily, owned work; “evaluated” means I assessed it but built little.
- CoreDaily, owned work
- SQL (T-SQL)
- Python
- Tableau
- Azure SQL and warehouse design
- Git and GitHub
- Jira and Confluence
- WorkingBuilt real things with it
- Azure Data Factory
- FastAPI
- GitHub Actions (CI/CD)
- Managed identity and secret stores
- SSDT / DACPAC
- MCP and LLM APIs
- Cloud data transfer
- FamiliarUsed or maintained it
- Snowflake (SnowPro Associate, 2025)
- Airflow
- SSRS
- C# / ASP.NET
- EvaluatedAssessed it, limited build
- A managed ML platform
- An event-tracking platform