I like building things to understand how they work, and sometimes just because I'm curious.
Here are a few recent ones, with what they are and what they aren't.
pad-lab
July – September 2026
A small data platform lab built on real Federal Election Commission campaign-finance data.
Python loaders pull from the FEC's public API into a Cloud Storage landing bucket, then
BigQuery, where dbt models clean the data and build the tables behind a small public
dashboard. It runs once a day on its own.
It's modeled on Community Tech Alliance's Progressive Action Database (PAD), though it
isn't affiliated with CTA. I built it to learn PAD-style data platform architecture
hands-on. I wanted to walk each layer myself and work through observability, cost, and
data quality on a real dataset.
I wrote all the infrastructure in Terraform, including the scheduled job, alerts for a
failed run or stale data, and a billing budget.
Loads are incremental, picking up from the last date seen with a seven-day overlap, and
dbt tests on the data fail the job, so a bad load trips the same alert as a crash.
I learned the cost side of the choices: a managed Airflow environment costs hundreds a
month just sitting idle, so a scheduled serverless job taught me the same scheduling and
alerting patterns for a dollar or two.
intake-classification-eval
October 2026
A review of the answer key in the "User Intake Classification" dataset from the Stanford
Legal Design Lab's Legal Help Commons, and a first pass at scoring a model against it. The
dataset is thoughtfully built. Alongside ordinary cases it includes deliberate tests:
messages with crisis words that aren't emergencies, messages with no legal issue at all,
people caught between two jurisdictions, hostile or disorganized writers. That makes it a
far better test of a legal aid intake tool than a plain list of cases, and it's why I
wanted to work with it.
Before running any model, I checked the labels against the LIST code list and the Census
county file. That turned up proposed corrections, which I've shared with the Lab.
The biggest lesson was that the prompt is part of what gets measured. Most of the
model's issue-code misses were a more specific code on the same path in the taxonomy,
because my prompt asked for the most specific code. My definition of an emergency
("within days") was narrower than the key's, and for legal aid intake I think the key's
broader standard is the right one.
On the dataset's designed tests, the model flagged all 10 real emergencies and wasn't
fooled by any of the 10 messages with crisis words in a non-urgent context, though my
narrower emergency definition made the second easier. It's a first-pass baseline (one run,
180 synthetic messages), and the next run uses a prompt that follows the key's
conventions. The scripts were written with Claude Code, and I reviewed them and the
scoring choices; a second, independently written scorer checked the figures.
homelab
May – September 2026
A personal Google Cloud lab. I wrote the Terraform for a small environment as reusable
modules (a network with Cloud NAT, a VM, BigQuery, IAM), with SSH only through IAP and OS
Login and no open SSH from the Internet.
At work I've run and operated Terraform; here I wrote it and the CI around it from
scratch. The CI uses no stored keys: GitHub Actions authenticates through Workload
Identity Federation, runs terraform plan on every pull request, applies on
merge to main, then configures the VM with Ansible.