Data quality · Analytics · Fire service

Trustworthy data for decisions that matter.

I build Python frameworks that check, monitor and explain data, and I spent 28 years in the volunteer fire service, 11 of them as Fire Chief. I'd like to put both to work on the data and analysis behind wildland fire science and planning in Ontario.

Try the fire weather demos See project work
~20 yrsenterprise data work at OLG
28 yrsvolunteer fire service
11 yrsas Fire Chief, Searchmont VFD
B.Sc.Mathematics & Computer Science, cum laude
Why fire science and planning

Where my experience meets the work

Fire science and planning depends on large, long-running datasets: fire weather station observations, fire occurrence records, fuel and landscape data, and the indices and models built on them. These are the needs I see in that work, matched to what I have already done.

01Reliable fire weather and occurrence data

Missing observations, flat-lined sensors and drifting instruments flow straight into FWI codes and planning models. Catching them early is a data quality problem.

From: enterprise DQ framework, observability and drift detection

02Programming for analysis and models

Turning published equations and methods into tested, repeatable Python, then running them at scale on years of historical data.

From: config-driven Python frameworks, synthetic test data and seeded history

03Results people can act on

Planners, managers and field staff need clear summaries, not raw tables. One place to see data health and results, with the detail one click away.

From: central results database, Data Quality Portal

04Training and knowledge exchange

Methods only help when people understand and trust them. I have built training for data stewards and taught firefighters as a certified instructor.

From: DQ learning portal, NFPA 1041 instructor

05Field perspective

I held incident command at fire, rescue and hazmat incidents, communicated fire bans to residents, and coordinated with MNR fire staff, the OPP and mutual aid partners.

From: Fire Chief, Searchmont Community VFD

06Working inside a public agency

Nearly 20 years in an Ontario provincial agency: governance, standards, change management and delivering through business and IT teams.

From: Ontario Lottery and Gaming Corporation
Selected project work

Projects

Recent work from my role as Senior Data Quality Analyst at OLG. The code and data belong to OLG, so these are summaries of the design and results. The demos below show the same methods applied to fire weather data.

Python · Cloudera AI

Config-driven data quality framework

Checks across thousands of critical data elements, defined in configuration rather than hand-written code.

  • Python
  • YAML config
  • Impala
  • MS SQL Server
  • SQLite
  • CLI
Problem
OLG's primary data quality tool was unavailable during its migration to IBM watsonx, but thousands of critical data elements (CDEs) still needed checking.
Approach
Championed, designed and built a Python framework on Cloudera AI. A single YAML file is the source of truth for every CDE: its table and column, risk tier, owner, validity pattern and thresholds. Completeness thresholds default by tier (95%, 90% and 80%) and can be overridden per element. A command-line scheduler runs daily checks by mode, tier or element and returns a failing exit code so alerting pipelines can react.
Testing
It runs locally on SQLite and switches to Impala sources and an MS SQL Server results database by editing one environment file, with no code changes. Seed scripts create synthetic data with known, planted problems and the expected result for each check, so the framework is proven against a known answer before it touches production.
Result
Data quality coverage continued through the tool migration. Adding a CDE means adding a config entry, not writing a new script.
Statistics · Monitoring

Data observability and drift detection

A baseline layer that watches every column every day and flags what has changed.

  • Python
  • Time series
  • z-score detection
  • Data profiling
Problem
Hand-written rules only catch the problems someone thought of in advance.
Approach
Built daily column-level metrics (row counts, null rates, distinct counts, min and max) and used z-scores against a 30-day rolling baseline to flag drift from each column's own norm, at high, medium and low severity. A 7-day burn-in keeps new elements from raising alerts before a baseline exists. In testing it catches a null-rate spike, a row-count drop and a collapse in distinct values.
Result
Broad, low-effort monitoring across the data lake, so expert effort could go to the highest-risk data.
In fire science: the same technique catches a drifting temperature sensor or a stuck humidity probe at a fire weather station before it skews the FWI codes. See it working →
Architecture · Strategy

Enterprise DQ strategy and risk-tiered coverage

A 14-section strategy and a three-layer control model that puts effort where the risk is.

  • DAMA-DMBOK
  • COBIT
  • Risk tiering
  • Governance
Problem
Writing one rule for every element across thousands of CDEs does not scale, and spreads effort evenly regardless of risk.
Approach
Authored the enterprise data quality strategy (dimensions, controls, monitoring, issue management, tooling, regulatory alignment, change management and a maturity roadmap) and designed a three-layer control model:
Curated, governed rulesDeep, business-owned checks for Tier 1 critical data
Automated completeness rulesBaseline checks for every element in scope
Observability monitoringDaily metrics and drift detection across everything
Result
Business-led Tier 1 to 3 classification directs governed rules to the highest-risk elements and automation to the rest. An Authoritative Data Source principle means curated rules run once at the point of origin and downstream zones inherit the results.
Dashboards · SQL Server

Data Quality Portal and central results database

One view of data health, whichever tool ran the check.

  • Streamlit
  • Plotly
  • Pandas
  • Impala
  • MS SQL Server
Problem
Results were scattered across Python checks, Alteryx and watsonx, each in its own format, and data owners had no single place to see them.
Approach
Architected a central results database on MS SQL Server with a common schema tagged by source system. Built a multi-page Streamlit portal on top of it: dataset explorer, column profiling, rule results, drill-down to failed records, DQ trends, metadata, observability metrics and a cross-table alert feed. A shared query layer means every page works against the live Impala cluster or falls back automatically to realistic mock data.
Result
Data owners and stewards see what is checked, what passed and what is drifting in one place. Admins can switch pages on and off without a redeploy, and a focused observability-only build runs from the same code.
Training · Web

DQ learning portal (mini-LMS)

A complete curriculum, written and built by me, to train data stewards and data owners.

  • HTML / CSS / JavaScript
  • Docker
  • nginx
  • Instructional design
Problem
A data quality program only works if the people who own the data understand their role in it.
Approach
Designed the portal and all of its content: 3 modules and 17 lessons covering DQ principles, how data quality affects their work, their role in the process, the tooling, and how the enterprise strategy fits together. Lessons combine written guides, scenario-based quizzes and progress tracking, plus practice games such as Dirty Record Detective, Dimension Sorter, The Cascade Effect and Steward for a Day.
Result
A self-paced static site packaged in Docker with nginx. Learner progress, quiz results and feedback feed engagement, mastery and reach dashboards in the Data Quality Portal, so the program can see who is learning and where lessons need work.
Learning Hub lesson slide titled 'A coverage map, not a competition', a table showing which data quality issues each of the three tiers detects
Lesson 1.5 from the Learning Hub: how the three tiers of the coverage model work together.
Migration · Testing

Governance platform migration to IBM watsonx

Moving rules and catalogue content from on-premises IBM InfoSphere to SaaS.

  • IBM watsonx.data intelligence
  • InfoSphere IGC
  • Synthetic test data
Problem
Moving years of glossary content and DQ rules to a new platform without losing trust in the results.
Approach
Led the migration of IGC content and DQ rules, and designed a parallel test environment with synthetic source data and seeded history.
Result
Rules and alerts are validated before they reach production.
Built for this site

Fire analytics demos

Small, working examples of my approach applied to fire weather data. The FWI calculations follow Van Wagner (1987), the published equations for the Canadian Forest Fire Weather Index System. All weather data here is synthetic, generated in your browser.

Daily FWI calculator

Enter a noon weather observation and yesterday's moisture codes to get today's six FWI System components.

Noon observation
Yesterday's codes (spring start-up values shown)

The default inputs are day one of Van Wagner's published test data, so the output can be checked against the reference values.

A fire season, day by day

A synthetic April to September season run through the FWI System from spring start-up. Move the slider to make the season drier and watch the Drought Code build and danger classes shift. Hover over the chart for daily values.

Data quality checks on a fire weather station

Three weeks of hourly temperature and humidity from a synthetic station, with realistic faults mixed in: a data gap, a flat-lined humidity sensor, an impossible reading, a temperature spike and a slowly drifting sensor. The checks are the same kinds I run on enterprise data.

Flagged

Air temperature (°C)

Relative humidity (%)

DimensionCheckFailedStatus

Why this matters for FWI

The FWI moisture codes carry memory: the Duff Moisture Code and Drought Code build on every previous day. One bad noon humidity reading changes today's codes, and that error is carried into the codes for weeks afterwards. A flat-lined sensor or a slow drift is worse, because it looks normal. Checks like these, run before the codes are calculated, protect everything downstream: danger ratings, preparedness levels and the historical record used for planning and research.

Background

Experience

2013 – 2026

Senior Data Quality Analyst · OLG

Helped build Data Governance from the ground up, supported the move to IBM InfoSphere and a new Cloudera data lake, then authored the enterprise DQ strategy and built its Python technical core.

2011 – 2013

Environment Provisioning Analyst · OLG

Led a multi-environment model for the Customer Hub (Siebel) master data project, and enabled SIT and UAT for OLG's electronic bingo line of business.

2007 – 2011

Quality Assurance Analyst and Voice Network Analyst · OLG

Led an upgrade of defect management software for all testing teams, letting OLG retire a second vendor's tool.

1995 – 2023

Fire Chief (2012 – 2023) and Firefighter · Searchmont Community VFD

Led a 21-person volunteer department with incident command at fire, rescue, hazmat and medical calls. Coordinated with the Ministry of Natural Resources, the Office of the Fire Marshal, the OPP, paramedic services and mutual aid partners. Secretary of the Algoma Mutual Aid Association (26 departments).

2006 – 2009

B.Sc. Mathematics and Computer Science · Algoma University

Graduated cum laude, with the Graduating Class Award of Excellence in Mathematics.

Programming

  • Python: frameworks, statistical checks, pipelines
  • SQL: MS SQL Server, Sybase, DB2, Hive, Impala
  • Streamlit and Flask web apps, Plotly, Pandas

Analytics and statistics

  • Data profiling and time series metrics
  • z-score anomaly and drift detection
  • Root-cause analysis, fitness-for-purpose assessment

Data platforms and tools

  • Cloudera Data Platform, Hadoop, Parquet
  • IBM watsonx.data intelligence, InfoSphere, Informatica DQ
  • Power BI, Cognos BI, Alteryx

Fire service and training

  • IMS 100, NFPA 1021 Fire Officer I
  • NFPA 1041 Instructor, NFPA 1072 Hazmat
  • Ontario Fire College legislation courses

Let's talk

I'm interested in programming and analytics roles in fire science and planning, now or in the future. References are available from the Ministry of Natural Resources (Fire Science and Planning), paramedic services, the OPP and OLG.

Email me