Selected projects.

ModelSense

MCP SERVER · AGENT SDK · EVAL HARNESS

ModelSense lets you talk to a 3D model. You load a glTF/GLB scene in the browser, ask a question in plain language ("what's the highest-poly part, and how big is it?"), and a Claude agent answers by calling tools on an MCP server that actually parses the geometry. The viewer then highlights the part, frames the camera, and draws the measurement in front of you. The point of the project isn't the chat. It's the machinery that makes an agent's tool use checkable: a stateless MCP server with a typed tool surface, human approval on the one tool that writes, per-turn Langfuse traces, and a Python eval harness that scores the agent against a golden set the server computes itself.

The server exposes nine tools over Streamable HTTP: eight read-only (list and load models, scene stats, find and highlight elements, focus the camera, measure, suggest optimizations) and one gated report export that only runs after an explicit approval. Every tool returns text plus typed structuredContent, so the React Three Fiber viewer applies scene commands directly instead of guessing. Loaded models live in a session-keyed in-memory cache, which keeps the server stateless per request and pushes the identity of a scene into a session_id that every later tool carries.

Tools & skills

What I learned

• The eval harness is the project, not the agent. A Python harness drives the real /chat endpoint through fifty golden tasks (lookup, multi-step, measurement, optimization, guardrail) and scores tool selection, argument validity, outcome, budget, and a guardrail safety invariant, with a Haiku judge for context fidelity. The golden answers are computed from the GLBs by the same server logic, not hand-typed, so the test can't quietly drift away from the geometry.
• It caught a real bug. The baseline scored 94%, with the measurement category at 62% because the agent answered size questions from memory instead of calling measure. One system-prompt change that forces the tool took measurement to 100% and the suite to 100%. The number moved because the harness made the failure legible, which is the whole argument for building it.
• Human-in-the-loop belongs at the agent layer, not inside the tool. The eight read tools are allowlisted and auto-approved; export_report is gated through canUseTool, which emits an approval event and blocks until the client posts back to /chat/approve. The invariant the harness enforces is that a gated tool can never succeed without that approval.
• The free tier checks the design. The first deploy on Render's 512 MB instance ran five tasks and then 502'd from an out-of-memory on the combined agent process, which is exactly the kind of constraint that decides whether "stateless per request" was a real choice or a slogan.

Sneaker Price MLOps Pipeline

SNEAKER-INTEL · PHASE 2

The deliberate Phase 2 of Sneaker Resale Intelligence. That project built the data-engineering foundation, a hand-written Postgres star schema over ~99K StockX sales with a full dbt layer. This one builds the ML layer on top of it: an end-to-end MLOps pipeline that predicts a sneaker's resale price premium. The model itself is a plain feedforward net on purpose. The whole point is everything around it, the parts that have to hold up to a "why did you build it that way" question, in reliability, reproducibility, and scale.

The topology is a chain of stages that talk to each other only through typed Parquet at an S3 path. An ingest stage acts as an anti-corruption layer over the sneaker-intel Postgres star schema (or synthetic fixtures in dev and CI) and lands a raw zone partitioned by run_date. PySpark builds the feature set partitioned by brand; Pandera validates it as a data contract and writes a validation report; Ray Train + PyTorch trains the regression net to model.pt while logging to MLflow tracking; and a register stage promotes the run into the MLflow registry as sneaker-price-model @staging. An Airflow DAG threads the whole thing with XCom paths, owning the topology but none of the logic, and one fsspec I/O layer means the same code runs against S3 in prod and local disk in CI.

Tools & skills

What I learned

• Airflow should own the topology, not the logic. Each task just calls a stage's run(), state passes between stages only as S3 paths, and the heavy libraries import inside the callables so the DAG parses fast and stays testable without Spark or Torch installed.
• A temporal train/val split is non-negotiable for forecasting. Training on earlier sales and validating on later ones is the only honest way to judge a model that has to predict forward in time. A random split leaks the future.
• Promotion should be a gate, not a default. Every run is registered for lineage, but the staging alias only moves on a strict val-RMSE improvement, and every decision leaves a promotion_report.json.
• Real data is the real test. Connecting the live warehouse surfaced four contract mismatches the synthetic fixtures had hidden (release-type vocabulary, premium outliers at 20× retail, transaction grain, pre-release sales). Pandera caught each one, and I fixed each as a documented config change.

ReliQuery

SOLD COMPARABLES · ARCHIVE MENSWEAR

ReliQuery answers one question about archive and avant-garde menswear: what a piece is actually worth, not what it's listed at. The hard part isn't scraping. It's that the same Rick Owens piece sells on Grailed and eBay under different titles, in different languages, with no shared key, so before you can quote a comparable you have to prove two listings are the same physical piece. ReliQuery is the resolution layer that does that, then turns sparse, noisy sold records into a price you can defend down to the sales behind it.

Apify actors pull sold listings from Grailed and eBay on a scheduled GitHub Actions job, never on the web server. Every source enters through a typed anti-corruption adapter that normalizes currency and shape into one canonical row, so a renamed or broken scraper is a one-file change and no source-specific quirk leaks past the boundary. Those rows land in Neon Postgres as a star schema; a staged rapidfuzz resolver reads brand first, then archetype, model, and season, and only forms a piece when it has the brand plus at least an archetype or model. dbt builds the comparables, velocity, and spread marts, and a thin Next.js frontend on Vercel reads the marts with no business logic of its own.

Tools & skills

What I learned

• Entity resolution is the entire product. Scraping is a solved, boring problem; deciding that two listings in two languages are the same jacket is the thing worth building. The resolver assigns a canonical piece to about 86% of rows, which is what turns a pile of listings into comparables you can price against.
• The anti-corruption adapter earned its keep. One typed boundary per source means the messy reality of each marketplace stops at the adapter, and the canonical row the rest of the system sees never learns that eBay and Grailed disagree about everything. When an actor changed shape, the fix was one file.
• A code review made me delete a headline number. An early version reported 172 cross-marketplace spreads; the review pushed on how many were real matches versus fuzzy collisions, and the honest count that clears the bar is closer to 15. Reporting the small true number instead of the big shaky one was the right call.
• The price model doesn't beat the median, and the case study says so. A LightGBM regressor over the comparables lands within about 1% of just taking the brand-and-archetype median (MAE around $240), so I report it as evaluated, not as a win. The defensible answer here is a well-resolved comparable, not a model pretending to know more than the data does.
• There's a second way in: image search. A Modal-hosted OpenCLIP worker embeds a photo and finds the nearest pieces through a pgvector index, which reaches 95% brand and 86% exact-piece accuracy leave-one-out on the reference set. Same resolution problem, approached from pixels instead of text.

LIVE · RESOLVED PIECE · PRICED OFF ITS OWN COMPS

LIVE · CROSS-MARKETPLACE SPREAD · SAME PIECE, TWO MARKETS

Repo is named TrueComp: ReliQuery is the site, TrueComp is the pipeline underneath it.

Data-Driven Fitness

BODY DATA × POPULATION BASELINES

An end-to-end data engineering and analytics project that links my own body data (two DEXA scans, Apple Health, calorie and protein logs, tracked lifts) to population baselines from NHANES and ACSM, to answer five concrete physiology questions. The hook: my two DEXA scans sit a month apart and report a −9.8 lb fat, +8.4 lb lean change, which is biologically implausible over 30 days. So instead of plotting the numbers and calling it a body recomposition, the project quantifies the measurement uncertainty, shows where the real change sits inside the instrument's noise floor, and reconciles what's left against energy balance and population data.

Under the hood it's a proper warehouse. Python and Polars stream-parse the 328 MB Apple Health XML and the NHANES files into bronze Parquet; dbt builds silver and gold marts across two targets (DuckDB for private local dev, BigQuery for the de-identified public layer) with tests and contracts; Airflow orchestrates ingest → build → test → analyze → dashboard; and an Evidence.dev site serves it publicly. Raw health data never leaves the machine, so only de-identified aggregates reach the cloud and the repo.

Tools & skills

What I learned

• The headline finding is a measurement-uncertainty result: the +8.4 lb "lean gain" is mostly glycogen and hydration water (about 4.1 lb), not muscle. At most ~4.3 lb is plausible newbie muscle in a month. Honest analysis meant decomposing the number before celebrating it.
• A contract on fct_daily with a guaranteed grain and fixed types let the marts and the analysis trust their inputs, which is what makes the uncertainty math defensible.
• The DuckDB-dev / BigQuery-prod split was a privacy and dev/prod-parity choice, not a scale one. It keeps raw data on my machine and exposes only aggregates to the cloud and the public site.
• Airflow is overkill for a single-machine pipeline. I used it for the recognizable, production-shaped orchestration and the discipline it forces.

Voice Assistant Review Sentiment Classifier

REPRODUCIBLE ML · HONEST METRICS

A binary sentiment classifier on Amazon Alexa reviews, rebuilt as a full ML lifecycle rather than a model. The identity of the project is reproducible experimentation infrastructure and honest metrics, not the models themselves. The first thing I checked was what the feedback label actually is, and it turned out to be the whole project: feedback == 1 if and only if rating ≥ 3, so the label is a hard threshold on the star count, not human sentiment. The data is about 92% positive, which makes accuracy a trap, so everything is reported against a majority baseline, negative class first.

Around that sits the infrastructure: dataset curation with a Pandera schema that enforces the label rule itself, a config-driven harness that runs cross-validated experiments across scikit-learn, PyTorch, and TensorFlow through one shared evaluation function, MLflow tracking, PR-AUC model selection with bootstrap confidence intervals, a containerized FastAPI service deployed live on a Hugging Face Space, drift monitoring on PSI/KS, and CI that lints, tests, and builds the image on every push.

Tools & skills

What I learned

• The label was the whole project. Once I saw feedback was just a thresholded star rating, the right questions followed: what does accuracy hide, and which rows actually need a text model at all.
• The most useful part was catching my own error. Selecting on cross-validated negative recall collapsed the linear model into a degenerate "always negative" predictor. Switching selection to PR-AUC, which is threshold-independent, fixed it. Model selection and the decision threshold are two separate choices.
• The result worth reporting wasn't a win. I bootstrapped the PR-AUC, and the control's interval [0.42, 0.72] was wide enough that the neural nets sat inside it, so I stopped claiming the linear model beats them and started saying it matches them at a fraction of the complexity.
• On a small, imbalanced dataset a regularized linear model is hard to beat. The deep-learning variants earned their keep as evidence that the harness is framework-agnostic and the finding holds across backends.

Sneaker Resale Intelligence

RESALE WAREHOUSE · LIVE DASHBOARD

An end-to-end data engineering project that turns real resale data into an analytical warehouse and a live dashboard. It answers the questions I actually find interesting about the resale market: which sneakers carry the highest premium over retail, how that premium decays after a release, and how it varies across sizes and silhouettes. The pipeline ingests about 100K real StockX resale sales, plus Google Trends as a live demand signal, through typed Python clients, lands them as raw JSON, and bulk-loads them into a hand-written PostgreSQL star schema through an idempotent loader.

From there, dbt transforms the raw tables across staging, intermediate, and mart layers, computing the premium economics with SQL window functions. A thin Streamlit dashboard reads the marts directly, so every figure on screen traces back to a tested, modeled table. It's built in public with a clean commit history and full-pipeline CI, with a deployed instance on Streamlit Community Cloud backed by Neon Postgres. The ML layer on top of this warehouse is Phase 2, the Sneaker Price MLOps Pipeline.

Tools & skills

What I learned

• The decision I spent the most time on wasn't code, it was data sourcing. I started with live APIs (eBay, Reddit) and a tempting StockX scraper, then realized a fragile live feed is a bad foundation for something I want to demo reliably. Choosing a real public dataset as the backbone, and reframing the API clients as documented, tested, future-ready extensions, taught me that "real data" doesn't have to mean "live API."
• The engineering lessons were all about getting the boring things right: putting idempotency in the schema (natural-key constraints plus ON CONFLICT DO NOTHING) rather than the loader, keeping one clear grain per fact table instead of unioning mismatched sources, and computing a metric like premium exactly once in an intermediate model so every downstream model agrees.
• A sharp reminder that execute_values reports only its last page's row count, which sent me to RETURNING to report loads honestly.
• Deploying against a managed Postgres surfaced the real-world details: SSL modes, pooled versus direct connections for DDL, and Google rate-limiting live Trends pulls.