I build ML systems that survive production.
Three services deployed on GKE and EKS, three incidents measured and root-caused,
and two open-source templates built from what they taught — one for classical ML,
one for deep learning, LLM and agents.
Fourteen years of operations leadership before the first model.
81% error rate under load → uvicorn --workers is an anti-pattern under K8s
(shared CPU budget = thrashing, not parallelism)
Fixed: asyncio + ThreadPoolExecutor, GIL analysis
Result: 81% errors → 0%, 2000m CPU → 1000m
SHAP returning all zeros → TreeExplainer incompatible with StackingClassifier
Fixed: KernelExplainer in original feature space
Evaluated 4 alternatives before deciding
HPA never scales down → Memory-based HPA + fixed ML footprint
= mathematically impossible to scale down
Fixed: CPU-only HPA, 3→1 pods in 8 minutes
Each one is written up with the measurement that found it and the alternatives rejected.
Read the incident write-ups →
The evidence — ML-MLOps-Portfolio
Three end-to-end ML services: trained, served, containerised, deployed, monitored.
| Project | What it demonstrates | Result |
|---|---|---|
| BankChurn Predictor | Classification API, SHAP explanations, threshold tuning | AUC 0.87 · 90% coverage |
| NLPInsight Analyzer | Financial sentiment API, honest dataset selection, CPU-friendly serving | 80.6% accuracy · 98% coverage |
| ChicagoTaxi Pipeline | PySpark ETL, demand forecasting, data-leakage correction | R² 0.96 · 6.3M rows |
GKE + EKS · 395+ tests · 18 ADRs · load tests, drift detection and runbooks
The portfolio taught the lessons. These encode them — and the interesting part is that there are two.
ml-service-template governs classical ML — scikit-learn,
XGBoost, LightGBM, single team, 1–5 models — and then refuses to grow. That limit is an ADR, not an omission: LLM/GenAI,
feature stores and data contracts are each deferred there with a revisit trigger, because widening it would destroy
the property that makes it recommendable — it is small enough to read in an afternoon.
ml-platform is what those deferrals made necessary: the enterprise
substrate for the problem shapes the first one declines — deep learning, LLM/RAG and agents, alongside tabular. It
consumes the first through copier rather than replacing it.
ml-service-template |
ml-platform |
|
|---|---|---|
| Answers | "I need governed classical ML in production" | "I need a substrate spanning tabular, DL, LLM and agents" |
| Model kinds | scikit-learn · XGBoost · LightGBM — a stated limit, 1–5 models | + time series, deep learning, LLM/RAG, agents |
| Data | In-memory DataFrames, Pandera | Iceberg lakehouse, point-in-time joins with leakage detection, dbt |
| Ship it | CronJob + GitHub Actions, governed kubectl apply |
Airflow 3 + KFP → Vertex AI / SageMaker, ArgoCD GitOps |
| Governance | 38 anti-patterns (D-01→D-38) + 8 audit-standard · 52 ADRs | Tooling triage: core / demonstrated / studied / rejected · 11 ADRs |
| Honesty gate | Self-auditing docs-coherence CI gate | Status derived from the filesystem · L4 printed at zero |
| Read it in | An afternoon | Not in an afternoon, and that is the trade |
If your models are classical ML, the first is the right answer and the second is over-engineering. Knowing which problems a tool should not absorb is the judgment this pair is evidence for.
Template · classical ML → · Platform · DL, LLM & agents → · Side by side →
The platform's LLM plane comes from agent-local —
a business-agnostic agent core with a deterministic policy gate, vendored in with its full history and still standalone.
Write-up →
ML & data Python · scikit-learn · XGBoost · LightGBM · PySpark · Polars · DuckDB · Iceberg · dbt · SHAP
Serving FastAPI · Docker · Kubernetes (GKE + EKS) · Terraform · ArgoCD · Argo Rollouts · Kyverno
Lifecycle MLflow · DVC · Airflow 3 · Kubeflow / Vertex AI / SageMaker Pipelines · GitHub Actions · Copier
Observability Prometheus · Grafana · OpenTelemetry · Loki · Tempo · Mimir · Evidently
GenAI LiteLLM · pgvector · RAG · Langfuse · promptfoo · LoRA / PEFT · AUTO·CONSULT·STOP governance
I spent 14 years running business operations — teams, vendors, budgets and customer-facing processes — before moving into ML engineering. That background is why my work looks the way it does: a model is useful only once it can be deployed, monitored, explained, improved and operated with cost discipline. I document root causes instead of only showing final demos, and I connect engineering decisions to cost, risk and maintainability.
Seeking my first formal ML/MLOps role — experienced in ownership, pressure, and making systems easier for the next person to operate.
On AI-assisted development: I use it, and I engineer the workflow instead of hiding it. Both templates encode the
governance layer — behavior protocols, path-scoped rules, an append-only audit trail, eval gates. ml-platform adds
the rule I care most about: a document asserting something false is itself a defect, even when the code is correct,
enforced by gates that derive status from the filesystem rather than trusting prose. Architecture, trade-off analysis
and incident diagnosis are mine; the tooling accelerates the rest.
Open to MLOps, Production ML, Applied AI and ML Platform roles — evaluated on evidence, not tenure.
Remote preferred · Mexico City (CST) · TripleTen Data Science · GCP ACE and AWS ML Associate in progress