Senior Research Engineertrading-model platforms
Role ↔ artifacts.
The capabilities a senior research engineer at a systematic trading firm is hired to bring, mapped to concrete artifacts on this site. Where the artifact is here, the link goes here. Where it isn't, the evidence column says so plainly.
Day-to-day responsibilities
| Capability | Artifact | Why it answers |
|---|---|---|
| Lead the research framework for mid-term alpha models | alpha-bench | Declarative model spec, walk-forward by default, leakage-safe evaluation, benchmark grid — the everyday loop a quant lives in. |
| Integrate research with production for deploying / running models | signal-stream + model-registry | Same feature graph runs in research and online; registry-enforced schema check at load time means production cannot drift silently from training. |
| Build tools that let quants and traders test hypotheses | notebook-as-code | Quants stay in Jupyter; the framework reads tagged cells, registers the artifact, and re-runs the spec under the platform — promotion in minutes. |
| Iterate on design with quants and traders, in person | — working method — | Two-week pairing programs, watching quants push code instead of reading docs, then turning the friction points into the API. Documented on the about page. |
| Support local quants during platform usage | observability + writing | Three-dashboard pattern (freshness / calibration / PnL) so support questions land on a board that has an owner, not in a slack DM. |
| Make the platform AI-research-agent ready | /agents · ADR-0040..0044 | Typed operator kind, MCP tool surface (read + bounded discovery only, writes refused by construction), citation refusal at propose-time, eval harness with bytewise drift test. The agent gets the safety the platform already had. |
Capabilities I bring
| Capability | Artifact | Why it answers |
|---|---|---|
| MLOps + ML engineering: end-to-end pipelines | alpha-bench, signal-stream, model-registry | Three of the five project writeups are the end-to-end pipeline split into the parts that own different SLOs. |
| Data science / analytics, with research-engineering taste | feature-forge + walk-forward checklist | Feature engineering as a build system; the checklist post is the stance behind every evaluation I trust. |
| Strong Python; PyTorch / scikit-learn fluency | sandbox + project stacks | Sandbox runs a deterministic ML pipeline in the browser; project stacks list Python, PyTorch, sklearn for the framework, Polars/DuckDB for the data layer. |
| End-to-end ML pipelines: preprocess, train, deploy, monitor | four of five projects | feature-forge (preprocess) → alpha-bench (train) → signal-stream (deploy) → registry + observability (monitor). The arrows are the platform. |
| Data wrangling, feature engineering, EDA | feature-forge | DAG-based feature pipeline with point-in-time semantics, content-addressed caching, same graph at training and serving. |
| Databases and query languages | DuckDB + Postgres + Parquet/Arrow | DuckDB for ad-hoc analytical work over the feature lake; Postgres backs the registry; Arrow on the wire between research and online runtimes. |
| Modern dev practice: version control, automated testing, CI/CD, observability | this repo · 32 tests · GH Actions CI | This site itself is in git with logical commits, has 32 unit tests across three stacks (12 vitest + 7 + 13 Python), and a GitHub Actions workflow running typecheck + tests + build on every push. The observability writeup is the operating posture I bring to platform code. |
| Cloud, containers, Kubernetes | notebook-as-code (Argo + k8s) | Promotion runs as a containerised Argo workflow on Kubernetes; signal-stream sketches the streaming runtime that consumes manifests. |
| Communication with non-technical stakeholders | every writeup on this site | Plain prose for systems people, not framework prose for framework people. The MLOps-for-quant-research piece is the one I would hand to a trader. |
| Agent ops + LLM safety patterns (hallucination refusal, cost ceilings, self-consistency) | /agents posture | Five ADRs ratify the design (typed operator, MCP tool surface, eval harness, cost ceilings, self-consistency). Runnable example + drift-guarded sample fixture keep the rendered posture in sync with the Python code. |
| STEM background | /about | Background and approach summarised on the about page. |
A note on this page
The honest version: this map exists to make it obvious whether I have evidence for each capability, or whether I'm asking you to take a claim on faith. Every "artifact" link goes to something I'd happily walk through on a screen-share. Rows with no link are claims about working method, not delivered code, and they're labelled as such.