OpsML & Scouter

Build it, then watch it

OpsML and Scouter are the two halves of how teams ship models. OpsML owns the lifecycle: a versioned registry for models, data, and prompts, reproducible down to the artifact, with client-side AES-256 encryption so the server coordinates uploads but never sees raw bytes. Scouter owns everything after deploy: monitoring, tracing, and evaluation for data, models, and GenAI. Both are Rust-cored with Python bindings, and I own and harden the internal builds the platform runs on.

What I work on

• Stood up Scouter end to end: shipped our internal build of the open-source project into production on Kubernetes, the HTTP and gRPC servers, the Kafka event pipeline that carries monitoring traffic, and the storage behind it.
• Tuned that storage for the read pattern: hot windows live in Postgres with daily partitioning and retention, then age into Parquet on object storage, so recent data queries fast and history stays cheap.
• Keep both internal builds current and wired into the platform: SSO, cloud storage, and the service mesh, so it feels the same from laptop to prod.
• Build out and harden the internal fork as the platform’s supported version, fixing issues and adding features our teams need.

Why it matters

Good tooling is quiet leverage. A governed, encrypted model registry becomes a single import instead of a project, and Scouter means nobody ships a model they can’t see after launch. When the lifecycle and monitoring layers are solid, every team ships faster and with fewer surprises.