BI · ANALYTICS ENGINEERING · DATA ENGINEERING — OPEN ACROSS CANADA

Every number on a dashboard should be able to prove itself.

For four years I've been the analyst people call when the numbers disagree.

Finance, when the P&L didn't tie. Sales Ops, when a rep's quota attainment looked wrong. The warehouse, when the WMS and the ledger disagreed about what was actually on the shelf. Usually all three were right — they'd just never agreed what the number meant.

I came to analytics from a computer science degree, so the fix I reached for was an engineering one: agree the definition, build it once, write the test that fails when it drifts. A Master's in Analytics filled in the statistics. The conviction came from the phone — a dashboard nobody trusts is worse than no dashboard at all.

Everything below is the receipt. Repos that rebuild themselves from a fixed seed and re-run their own proofs on every push: no claim without a number, no number without a test that fails the build the moment it stops being true. Each one documents what it still gets wrong, which is usually the more interesting half.

Open to remote and relocation across Canada · Legally eligible to work in Canada · Available immediately

ask-your-data · app/cli.py

> how many migration artifacts passed parallel-run validation?

107 artifacts have a GO verdict.

SELECT COUNT(*) FROM migration_parallel_run_results
WHERE verdict = 'GO'

> delete all denied claims

I can't do that — this is a read-only interface.

Not a screenshot — the question, the SQL and the answer are all pinned by golden-question tests in CI.

12
public repos
2109
CI-verified tests
12
domains I report on
4+
years in BI & analytics

01 — WHAT I ACTUALLY GET ASKED

I'm not a finance analyst who wandered into ops. I've owned the whole reporting surface.

Twelve domains, and the same discipline under all of them: one definition per metric, written down, tested, and labelled with its basis — so the meeting argues about the business instead of about whose number is right. Each tile is a question I've actually been handed, and the model I built so nobody had to ask twice. Every tile links to the project that demonstrates it.

01

Sales Operations & Rep Performance

“Why did we miss the number — and who's actually performing?”

Pipeline-to-invoice reporting with governed quota, attainment and mix logic, so the variance conversation starts from an agreed baseline instead of three competing extracts — and rep scorecards normalised for territory potential and account mix, with the definitions locked so nobody can re-cut them mid-quarter.

02

Customer Analytics

“Which customers are quietly leaving?”

Cohort retention, RFM segmentation, order-frequency decay and margin-by-customer — with retention and churn reported as rates rather than counts, revenue-weighted alongside logo, and net revenue retention decomposed into new, expansion, contraction and churned. Plus the recommender that proves a simple model can beat a clever one.

03

Product & Assortment

“Which SKUs earn their shelf space?”

SKU-level velocity, contribution margin, cannibalisation and long-tail analysis; assortment views that separate products that sell from products that merely move.

04

Vendor Performance

“Which suppliers are costing us more than they invoice?”

Vendor scorecards on fill rate, lead-time variance, price adherence and quality claims — landed-cost impact quantified rather than argued.

05

Supply Chain Planning

“How much should we be holding, and where?”

Demand forecasting, inventory turns, days-on-hand and safety-stock coverage across a perishable network — and a forecast that is scored against actuals rather than published and forgotten, reporting variance, MAPE, signed bias and hit rate. Plus the medallion pipeline and control tower that make the whole chain observable in one place.

06

Warehouse & Logistics

“Does the system match the shelf — and did it arrive on time?”

Cycle-count accuracy, bin utilisation, pick/pack throughput and FEFO expiry-risk for perishables, with lot traceability that answers a recall question in minutes — then OTIF decomposed by lane, carrier and failure reason, with freight cost per case and the difference between a late truck and a late promise.

07

AP & AR

“What do we owe, and what will we actually collect?”

Aging, DPO/DSO, invoice-match exceptions and credit exposure — receivable turnover on an average balance, an aging book that reconciles to the receivable it ages, and payables overdue as a share of total. On the AR side, an NRV model that prices open receivables at what they'll realistically bank.

08

GL / P&L Reconciliation

“Why doesn't the subledger tie to the GL?”

Automated ERP-vs-subledger controls that classify discrepancies, trace every dollar of variance to source, and make month-end an audit instead of a hunt — alongside a full statement layer: an income statement, a balance sheet, and a gross-to-net bridge that answers “is this gross or net?” in one line.

09

Data Engineering & BI Platform

“Can we trust the pipeline this all sits on?”

Bronze→Silver→Gold pipelines in Fabric/ADF/Synapse and dbt, star-schema models, semantic layers, RLS/OLS, and CI that breaks the build when the data drifts.

10

AI & Machine Learning

“Is there a model here, or just a metric?”

Forecasting, churn and flight-risk classification, recommenders, survival analysis and grounded LLM/text-to-SQL work — held to honest holdouts, fairness gates and a baseline it has to beat before it ships.

11

HR & People Analytics

“What is labour actually costing us, and who is about to leave?”

Time-and-attendance integration and punch-to-payroll reconciliation, labour cost per unit produced, overtime exposure and schedule-vs-actual variance — plus headcount, turnover and flight-risk modelling held to a fairness gate before anyone sees a name.

12

Marketing & Growth Analytics

“Which channel actually earned that sale?”

Funnel and cohort reporting, LTV against acquisition cost, and multi-touch attribution graded against a known answer rather than argued about — with a geo holdout and a power calculation for the questions attribution genuinely cannot settle.

02 — THE WORK

Twelve projects. Every one started with a question somebody actually asked me at work.

Each repo rebuilds itself from seeded synthetic data on every push — no PHI, no real customers, no real employees. If a sentence in a README stops being true, the build goes red and I find out before you do. A green badge means it runs today, not that it worked once on my laptop.

START HERE

FILTER
SHOWING 12 / 12 REPOS

FLAGSHIP · BI PLATFORM & METRIC GOVERNANCE

Retail Analytics Platform

Sixteen pages, forty-two metrics, one definition each — and the basis printed next to the number.

It started as a failure. The demo printed three different HHI values on three pages at once, an empty “Active customers” count beside a card reading 80, and three answers to “what revenue is at risk” in a single viewport. None were arithmetic mistakes — every page had written its own version of the same idea. So the fix wasn’t a formula, it was a layer: each metric now lives once in metrics.py, and a published catalogue gives every one a formula, a grain, a source table, an owner page and a gross-or-net basis — each pinned by a test with a hand-computed expected value.

The demand planner produced a forecast nobody scored. It now reports −18.9% variance, +$881k bias and a 50% hit rate within ±10%, and publishes a 209% MAPE rather than hiding it — the number is inflated by small SKU-month denominators, which is exactly why hit rate and variance sit beside it. A Finance page adds an income statement and balance sheet whose revenue, discounts and COGS are read from the sales fact, so its top line matches the Overview instead of describing a second company. A Marketing page adds acquisition economics, with campaign spend reconciled to the Finance page’s marketing expense line.

Two numbers are deliberately left unflattering. Inventory turnover appears twice — 8.1× cost-basis on Finance, usage-based on Inventory — because they are different measures that will not agree, so each states its basis instead of quietly picking one. And ROMI reads −758%, because the standard formula credits marketing with every dollar of company sales movement and revenue fell for reasons campaigns don’t drive. Metrics needing a source system this business doesn’t have — MRR, NPS, web funnel, HRIS, market share — are catalogued as not implemented, with the system each would require.

The site is prerendered: Playwright walks the real Flask app, freezes 100 charts to SVG, strips every <script>, and a checker then loads each page with networking blocked to prove it needs no server. That is why it opens instantly while the interactive Flask tier sleeps on a free instance.

Commercial

  • Revenue / profit$51.0M · $11.7M
  • Gross margin23.0%
  • Net revenue retention104.4%
  • Retention · logo churn94.3% · 5.7%
  • ARPA · AOV$92,259 · $2,097

Finance

  • Net margin4.6%
  • Current ratio2.23×
  • Working capital$7.46M
  • AR turnover · ROA9.7× · 11.8%

Acquisition & forecast

  • CAC · payback$17,655 · 9.1 mo
  • CLV:CAC (12-mo basis)1.32×
  • Forecast variance · bias−18.9% · +$881k
  • ConcentrationHHI 30 (customers)
  • Python
  • Flask
  • DuckDB
  • Plotly
  • Playwright
  • Docker
  • 1194 tests ✓
42
GOVERNED METRICS
16
PAGES PRERENDERED
100
CHARTS FROZEN TO SVG
7
NOT IMPLEMENTED, DECLARED
0
REQUESTS ON LOAD

CAPSTONE · LLM ENGINEERING

Ask Your Data

Anyone can ask 36 tables a plain-English question and audit the SQL behind the answer.

Ask a question in plain English across all 36 tables of this portfolio — six business domains — and get an answer you can audit. The model never answers from memory: it writes SQL, the SQL runs behind a read-only guard, and the query sits next to the answer so you can disagree with it. Ask it to delete something and it refuses. Its self-correction loop is bounded and proven in CI with a scripted fake model, so the tests pass without calling a paid API.

  • Python
  • DuckDB
  • Claude API
  • 99 tests ✓

36 tables · 6 domains · 0 answers from memory

▶ TRY IT LIVE OPEN REPO

DATA PLATFORM · FABRIC PATTERNS

Supply Chain Control Tower

Bad data gets caught at the boundary instead of on an executive's screenshot.

Bad data doesn't announce itself; it quietly changes a number an executive already screenshotted. So this pipeline defends in three layers — schema contracts stop drift before Bronze, poisoned rows quarantine with replay, a quality gate guards Gold — and CI proves each layer by injecting the exact failure it exists to catch. Benchmarked at 10M rows in Delta, with row- and column-level security verified by impersonated DAX.

  • PySpark
  • Delta Lake
  • Power BI
  • 49 tests ✓

10M-row Delta benchmark · 3 defence tiers, each proven by an injected failure · 4-page control tower

OPEN REPO

ANOMALY DETECTION · FINANCIAL CRIME

154 tests ✓

Transaction Monitoring

Every planted case found, on a third fewer alerts than a flat $10,000 threshold.

A $10,000 reporting threshold catches 38 of 60 cases and raises 555 alerts doing it — and it cannot see structuring at all, because structuring is under $10,000 by definition. Five explainable rules over an unsupervised model find all 60 on 366 alerts. The honest half is in the README: ablation shows the anomaly model lifts ranking 49% but saves 1.8% at the operating point, so it earns its place on triage order, not on the accept/reject decision.

60/60
CASES FOUND
0.774
PR-AUC
−90%
EXPECTED COST

17 SQL features proven equal to their Python twins on all 100,299 rows; precision, recall and cost floors gate every push.

  • Python
  • SQLite
  • scikit-learn
  • Streamlit
▶ OPEN LIVE APP OPEN REPO

ATTRIBUTION · SAAS GTM · CAUSAL INFERENCE

90 tests ✓

Marketing Attribution & Incrementality

I built a dataset where the right answer is known — then watched every attribution model fail to find it.

Attribution is the one analytics discipline where everybody argues and nobody can check, because the counterfactual isn't in the data. So this generates one: each user carries a fixed random draw, and a channel's true contribution is measured by re-running that same draw with its touches deleted. Six models compete. The exact Shapley value and a Markov chain both lose to a 40/20/40 heuristic — because every model that reads only a journey log sees how often a channel was present, never whether it caused anything. Last-touch hands direct a quarter of all conversions against a true share of 1.9%. A second act asks the same questions of a B2B SaaS motion — CRM pipeline, an ARR waterfall, NRR versus GRR, quota and capacity — and finds the segment with the fastest cycle and the best coverage is the one that loses money.

13×
LAST-TOUCH OVERCREDIT
5.76
BEST MODEL ERROR (PTS)
0.84
LTV:CAC OF THE BEST-RUN SEGMENT

A geo holdout settles what the models argue about: naive pre/post reads 11.0%, difference-in-differences returns an interval that covers the planted truth — and the power calculation says out loud which channel this traffic cannot test at all. 90 tests, and a LookML semantic layer parsed against the schema it claims to describe.

  • Python
  • SQL
  • Causal inference
  • LookML
  • Streamlit
▶ OPEN LIVE APP OPEN REPO

DECISION SUPPORT · HEALTH SYSTEM

116 tests ✓

Health System Decision Support

The same evidence recommends funding the programme — and refuses to — depending on how you count a bed day.

Two health systems, one standard. A Canadian authority asks what a weighted case costs, how many beds hold people who no longer need acute care, and whether this month's readmission rate is signal or noise — so the SPC uses Laney's correction, because the metric everyone reports is 4.6× overdispersed and a naive chart fires 41 false signals across 19 of 24 months. The economic evaluation comes out dominant on one costing perspective and $192k/QALY on the other, and the business case says both. The US side prices $3.6M of open AR at the ~$1.7M it will actually collect.

39,567
DISCHARGES MODELLED
56.9
ALC BED EQUIVALENTS
116
CI TESTS

Every figure rebuilds from the command line in about five seconds on the standard library alone — Power BI is a presentation layer, with no control limits or yield maths in DAX.

  • Python
  • Power BI
  • SPC
  • Health economics
OPEN REPO

REGULATED DATA · FHIR · T-SQL

224 tests ✓

Clinical Evidence Console + FHIR Warehouse

Two regulated-data systems, one rule: every claim needs ground truth and a test that can fail.

A live Streamlit evidence console now connects both halves. One cohort definition drives enrollment, query operations, SDTM safety, coding and vital-sign review; fixed FHIR views trace a deterministic 10,000-patient Synthea run through validation, raw SQL Server JSON, 3NF and a Kimball star with SCD Type 2 history. The interface keeps every claim attached to its denominator, source artifact and limitation.

49/49
DEFECTS RECOVERED
1.66M
FHIR RESOURCES
10
T-SQL DQ GATES

CI starts SQL Server 2022, builds the sample warehouse, plants a DQ failure to prove the gate closes, measures real execution plans, regenerates the documentation, and runs all 224 invariants.

  • Python
  • HL7 FHIR R4
  • SQL Server / T-SQL
  • CDISC / SDTM
  • Streamlit
▶ LAUNCH LIVE CONSOLE OPEN REPO

ML SERVING · A/B

38 tests ✓

Customer Recommendation Engine

The simpler recommender ships because it wins — and CI fails if it ever stops winning.

I built the impressive thing first: two-stage retrieval with a gradient-boosted ranker, 80.0% hit-rate@10. Plain collaborative filtering got 84.9%. So the simple one ships, the fancy one stays in the repo as evidence, and a CI test fails if the winner ever stops winning. Served with FastAPI + Docker, read in a 7-page Power BI app.

84.9%
HIT-RATE@10 SHIPPED
80.0%
RANKER THAT LOST
38
CI TESTS

A CI test fails the build if the shipped baseline ever stops beating the challenger.

  • scikit-learn
  • FastAPI
  • MLflow
▶ OPEN LIVE APP OPEN REPO

PEOPLE ANALYTICS · GOVERNANCE

52 tests ✓

HR Attrition Analytics

Flight-risk scoring HR can defend, built without a single protected attribute.

People data raises the stakes, so the guardrails came before the model: k-anonymity masking, a disparate-impact gate in CI (four-fifths rule plus Fisher's exact), survival analysis that's honest about censoring. The flight-risk model uses zero protected attributes — and turned out to score better without them.

0
PROTECTED ATTRS USED
4/5
RULE GATE IN CI
52
CI TESTS

k-anonymity masking and a disparate-impact gate run on every push, with Fisher's exact behind the alarm.

  • T-SQL
  • lifelines
  • Power BI
OPEN REPO

TRANSFORMATION · SEMANTIC LAYER

32 dbt tests ✓

Supply Chain Analytics — dbt

Finance and Ops stop arguing about revenue because there is one versioned definition.

The answer to “why does Finance's revenue number differ from Ops'?” is usually that there are two definitions. This is one definition, versioned: dbt Core from staging to marts on dual DuckDB/Snowflake profiles, incremental models, SCD2 snapshots, a MetricFlow semantic layer, and an Airflow DAG that CI actually runs.

2
WAREHOUSE PROFILES
SCD2
SNAPSHOT HISTORY
32
DBT TESTS

One definition per metric in MetricFlow, and the Airflow DAG is executed in CI rather than described.

  • dbt
  • MetricFlow
  • Airflow
OPEN REPO

FINANCE-GRADE · CONTROLS

33 tests ✓

GL / P&L Reconciliation

Month-end becomes an audit trail instead of a manual variance hunt.

Month-end used to mean hunting a variance by hand. This engine finds four classes of discrepancy between ERP and subledger and proves every dollar traces back to source. Then, unmodified, I pointed it at a FOCUS-format cloud bill for FinOps chargeback — because a reconciliation is a reconciliation.

4
DISCREPANCY CLASSES
100%
VARIANCE TRACED
33
CI TESTS

The same engine, unmodified, reconciles a FOCUS-format cloud bill — the logic is portable, not bespoke.

  • T-SQL
  • SQLite
  • Power BI
  • Tableau
OPEN REPO

MIGRATION · CUTOVER GATE

28 tests ✓

Legacy-to-Fabric Migration

A cutover nobody has to take on faith — old and new run side by side until a gate decides.

Nobody signs off on a migration because the new pipeline looks nicer. So old and new run side by side, row for row, and a GO/NO-GO gate makes the call. The negative tests are the real deliverable: I break the data on purpose to prove the validator catches dropped rows, offsetting errors, and phantom keys.

107
ARTIFACTS VALIDATED
GO/NO-GO
CUTOVER GATE
11
CI TESTS

Negative tests break the data on purpose to prove the validator catches what a cutover can't afford to miss.

  • SSIS
  • SSRS
  • PySpark
OPEN REPO
…and the profile that ties it together Where to start, what each project is actually proving, and the losses I keep on purpose. github.com/KushPatel29 ↗

03 — SKILLS INDEX

The scannable answer to “does he know X?”

Nothing here is a self-assessment score out of five. Every item below appears somewhere above it — in a role I held or a repo you can open — and the last row is the list of things I've built with but never run in production, because that distinction matters more than the length of the list.

01 BI & semantic modelling

  • Power BI
  • DAX
  • Star-schema design
  • Semantic layers
  • MetricFlow
  • Incremental refresh
  • SSRS
  • Paginated & operational reporting
  • KPI definition governance
  • Excel

02 Pipelines & orchestration

  • Azure Data Factory
  • dbt Core
  • Airflow
  • SSIS
  • PySpark
  • Medallion (Bronze→Silver→Gold)
  • Incremental models
  • SCD2 snapshots
  • Parallel-run cutover validation

03 Cloud platforms

  • Microsoft Fabric
  • Azure Synapse Analytics
  • Azure
  • Delta Lake
  • Lakehouse patterns
  • Snowflake
  • DuckDB
  • SQL Server
  • SQLite
  • FinOps / FOCUS-format cost data

04 Programming & ML

  • SQL
  • T-SQL
  • Python
  • scikit-learn
  • Time-series forecasting
  • Recommender systems
  • Survival analysis (lifelines)
  • Churn & flight-risk models
  • LLM / text-to-SQL
  • Claude API
  • MLflow
  • Baseline-first model selection

05 Governance & data quality

  • Row-level security (RLS)
  • Object-level security (OLS)
  • RBAC
  • Column masking
  • k-anonymity
  • Schema contracts
  • Quarantine & replay
  • Quality gates in CI
  • dbt tests
  • Control totals & reconciliation checks
  • Disparate-impact / fairness gates
  • Negative & injected-failure testing

06 Integration & ops

  • Synerion API integration
  • ERP / WMS data extraction
  • Punch-to-payroll reconciliation
  • GitHub Actions CI
  • FastAPI
  • Docker
  • Streamlit
  • Git / code review for analytics
  • Legacy estate migration

USED, NOT YET SHIPPED TO PRODUCTION

These are built and tested in my own repos against seeded synthetic data — not run against a live production workload with real users behind them. I'd rather you knew which half of the list is which:

  • dbt Core
  • MetricFlow
  • Airflow
  • Snowflake
  • DuckDB
  • Delta Lake
  • FastAPI
  • Docker
  • MLflow
  • Streamlit
  • Claude API
  • lifelines

Everything not in this row was used in a paid role, on data other people made decisions with.

04 — THE METHOD

My favourite results are the ones where I lost.

Anyone can show you the model that won. I'd rather show you the one I killed and the boring baseline that beat it, because choosing what not to ship is most of this job.

84.9% > 80.0%

The ranker lost

Two-stage retrieval with a gradient-boosted ranker, beaten by plain collaborative filtering on a customer-disjoint holdout. Simplicity shipped, and a test now guards the result.

18.5% < 19.6%

The forecaster lost

A gradient-boosted multi-step forecaster lost to a moving average on WAPE. The moving average ships; the challenger's defeat is written into the README rather than quietly deleted.

p ≈ 0.23

The alarm that didn't cry wolf

A fairness screen fired on the attrition model. Fisher's exact test showed small-sample noise rather than real bias — so I kept it as a monitored gate instead of pretending the alarm never happened.

HOW A NUMBER GETS ONTO A DASHBOARD

STEP 01

Agree the grain

Before a single measure, the business and I settle what one row means. Most reporting disputes are definition disputes wearing a costume.

STEP 02

Contract the source

Schema contracts at the boundary, so upstream drift fails loudly at ingestion instead of silently in a Gold table.

STEP 03

Model it once

Star schema, one semantic layer, measures reviewed like code — so there's exactly one place a KPI can be wrong, and one place to fix it.

STEP 04

Test the claim

Every headline number gets a test: control totals, ceilings, negative cases. If a claim stops being true, CI goes red.

STEP 05

Ship it auditable

The number arrives with its lineage, its SQL and its access rules attached, so anyone can check my work without asking me.

Beat the baseline or don't ship

Every model is measured against the dumbest thing that could work. If the moving average wins, the moving average ships.

Governance before dashboards

RLS, masking and k-anonymity go in before the first visual, because retrofitting access control is how sensitive data leaks into a screenshot.

Prove the failure path

It isn't enough that the happy path works. I break the data on purpose in CI and prove the guard catches it.

Every repo has a short section on what I deliberately didn't build: no vector database where a SQL join was the right answer, no deep learning on 38 SKUs, no cloud architecture I couldn't defend in a budget meeting. Restraint is harder to demo than complexity, so I write it down.

05 — WHERE THE HABITS CAME FROM

The repos are the clean version. These were the messy originals.

Every technique in the repos above was learned somewhere with a deadline attached.

 · 2 yrs 7 mos

Two Rivers Specialty Meats

Data Analyst — Operations, Logistics & Enterprise Reporting

PERMANENT FULL-TIME · NORTH VANCOUVER, BC · ON-SITE

SALES OPS · WMS · LOGISTICS · VENDOR · PRODUCT · AP/AR · GL/P&L · PLATFORM

I was the only analyst across a perishable-goods supply chain, so “my domain” meant whatever number the business needed to defend that week — from a rep's attainment to a lot recall to the month-end close.

  • Power BI
  • DAX
  • T-SQL
  • PySpark
  • Microsoft Fabric
  • ADF
  • Synapse
  • SSIS/SSRS
  • Python

SALES OPS & REP PERFORMANCE

  • Built the sales operations reporting layer — pipeline to invoice — with governed quota, attainment and product-mix logic, so monthly variance reviews argued about causes instead of whose extract was right.
  • Built rep and territory scorecards normalised for account mix and territory potential: attainment, coverage, win rate and margin per rep, with definitions locked in the model so they couldn't be re-cut mid-quarter.

CUSTOMER, PRODUCT & VENDOR

  • Delivered customer analytics for a churn-sensitive book of trade accounts — cohort retention, order-frequency decay, RFM segmentation and margin by customer — which surfaced quiet attrition long before the rep noticed.
  • Ran SKU and assortment analysis on velocity, contribution margin and cannibalisation, which fed real decisions about which products kept their slot.
  • Built vendor scorecards on fill rate, lead-time variance, price adherence and quality claims, and translated them into landed-cost impact so procurement negotiated with numbers instead of impressions.

WMS, INVENTORY & LOGISTICS

  • Built WMS reporting for warehouse operations — cycle-count accuracy, bin utilisation and pick/pack throughput — reconciling what the system claimed against what was actually on the shelf.
  • Developed FEFO and expiry-risk analytics plus lot traceability for perishable inventory, designed so a recall question could be answered in minutes rather than a day of spreadsheets.
  • Decomposed OTIF by lane, carrier and failure reason alongside freight cost per case and dock-to-stock timing, separating late trucks from over-promised delivery dates.

FINANCE — GL/P&L, AP & AR

  • Sat with Sales, Finance and Supply Chain until we agreed on single definitions for P&L/GL and operations KPIs — OTIF, inventory turns, days on hand — then built the Power BI star schemas and DAX that made those definitions the only ones available.
  • Built AP and AR reporting on aging, DPO/DSO, invoice-match exceptions and credit exposure, which gave Finance a working view of cash instead of a month-old snapshot.
  • Moved staffing decisions off gut feel with labour cost per case, overtime exposure and schedule-vs-actual variance — fed by a Synerion time-and-attendance API integration into the analytics warehouse, with punch-to-payroll reconciled so billed hours matched worked hours.
  • Automated the reconciliation controls we used to run by hand: recurring discrepancies down ~45%, reporting errors down ~30%.

DATA ENGINEERING & GOVERNANCE

  • Built Bronze→Silver→Gold pipelines in Fabric / ADF / Synapse with SQL and PySpark while keeping the legacy SSIS/SSRS estate alive — the migration repo is that experience, minus the 6am pages.
  • Owned the semantic layer: star-schema models, incremental refresh, and DAX measures reviewed like code rather than accumulated like sediment.
  • Implemented RLS/RBAC and column masking so cost, margin and people data only reached the people entitled to it, and documented it well enough to survive an audit.

 · 1 yr 8 mos

Shivam Investments

Financial Analyst — Data & Reporting

PERMANENT FULL-TIME

GL/P&L · AP/AR · RECONCILIATION · AUTOMATION

Where the reconciliation habit started: close cycles tight enough that a manual mistake showed up as a real number in front of real people.

  • SQL
  • Python
  • Power BI
  • Excel

CLOSE & CONTROLS

  • Reconciled GL/P&L across sources every month and chased variances to source — the discipline the reconciliation repo later turned into a tested engine.
  • Worked AP and AR aging and exception reporting, tightening the follow-up loop on the accounts that were actually at risk.

AUTOMATION

  • Replaced recurring manual analysis with Python + SQL feeding Power BI, cutting the effort around ~40% and freeing the month for questions worth asking.
  • Standardised the recurring reporting pack so each cycle started from the previous one's logic instead of a fresh workbook.

A note on the percentages above: the ~45%, ~30% and ~40% improvements are internal estimates drawn from company reporting at the time. Unlike the figures in the projects section, they aren't reproducible from a public repo, and I'd treat them as directional rather than audited.

06 — EDUCATION & CREDENTIALS

Formally trained in machine intelligence.

MASTER'S DEGREE

GPA3.76

MPS, Analytics — Applied Machine Intelligence

Northeastern University · Vancouver, BC

The degree is where the AI/ML half of this portfolio comes from — and where I learned to distrust a model that hasn't been tested against a boring baseline. Capstone: the grounded text-to-SQL assistant above.

  • Machine Learning
  • Deep Learning
  • NLP / LLMs
  • Time-Series Forecasting
  • Statistical Inference
  • Data Mining
  • Cloud Data Platforms

BACHELOR'S

B.Eng., Computer Science

Gujarat Technological University

Engineering fundamentals — which is why the analytics work ends up in a repo with tests instead of a workbook on a shared drive.

AWARD

First prize — wildfire-prediction hackathon

Python + Azure against live sensor feeds, under a clock. Won on a model that was defensible, not the one with the most moving parts.

Microsoft DP-600

Certification in progress

Lakehouse and semantic-model work in Fabric, which is the platform most of my recent pipelines and control-tower reporting run on.

Google Data Analytics Professional Certificate

GOOGLE · OCT 2023 · XZRHJQKA8B3M

The full eight-course track plus the capstone case study — the end-to-end habit of ask, prepare, process, analyse, share, act.

SQL for Data Science

UC DAVIS · JAN 2025 · 02MQDX1MTDNZ

Window functions, CTEs and query profiling — the SQL that the HR and GL repos are actually written in.

Python for Data Science, AI & Development

IBM · NOV 2023

Python, pandas and data preparation — the layer every pipeline and model in this portfolio sits on.

Databricks Fundamentals

DATABRICKS · ACCREDITATION

Lakehouse architecture and the Databricks platform — the same medallion pattern the control-tower and migration repos implement in Fabric.

Data Visualization & Storytelling Basics

NORTHEASTERN · APR 2023

Power BI and the part that matters more than the chart type: making a number land with the person who has to act on it.

Introduction to Analytics

NORTHEASTERN · DEC 2022

The foundation course from the first term of the master's.

If your reporting layer has a trust problem, that's my favourite kind of work.

I'm looking for a Data Analyst, BI Analyst or Analytics Engineer role anywhere in Canada. Tell me which number your leadership team argues about most and I'll tell you how I'd go about ending the argument.

Open to remote and relocation across Canada · Legally eligible to work in Canada · Available immediately

MPS ANALYTICS (APPLIED ML), NORTHEASTERN — GPA 3.76 MICROSOFT DP-600 — IN PROGRESS

Résumé Email