sota-ml-engineeringlisted

State-of-the-art ML engineering / MLOps rules (2026) for BUILDING and AUDITING production machine-learning systems — the training→serving→monitoring lifecycle of classical/predictive ML. Distinct from LLM apps (prompts/RAG/agents → sota-llm-engineering). Covers ML system architecture (feature stores, model registry, reproducibility), data & features (leakage, train/serve skew, versioning), training & experiment tracking, evaluation (ML Test Score, slices, regression gates), deployment/serving (canary/shadow, rollback), monitoring & drift (PSI/KS, retraining), and ML security & governance (poisoning, model extraction, unsafe pickle, MITRE ATLAS, NIST AI RMF, EU AI Act). Trigger keywords - MLOps, machine learning, ML pipeline, model training, feature store, model registry, experiment tracking, MLflow, model serving, data drift, concept drift, train/serve skew, data leakage, model monitoring, retraining, ML Test Score, model card, MITRE ATLAS. Use for BOTH building and auditing ML systems.
martinholovsky/SOTA-skills · ★ 8 · AI & Automation · score 75

Install: claude install-skill martinholovsky/SOTA-skills

# SOTA ML Engineering / MLOps (2026) Expert rules for building and auditing **production machine-learning systems** — the lifecycle that turns a model into a reliable, monitored, governed service. This is **classical/predictive ML** (tabular, ranking, vision, forecasting, recommendation): training pipelines, feature stores, model registries, serving, and drift monitoring. It is **not** LLM-application engineering — prompts, RAG, agents, and LLM evals live in `sota-llm-engineering`; data pipelines/warehouses live in `sota-data-engineering`. Grounded in Google's [Rules of ML](https://developers.google.com/machine-learning/guides/rules-of-ml), the [ML Test Score](https://research.google/pubs/the-ml-test-score-a-rubric-for-ml-production-readiness-and-technical-debt-reduction/) rubric, and [Hidden Technical Debt in ML Systems](https://research.google/pubs/hidden-technical-debt-in-machine-learning-systems/). Every rule states the *why*; every rules file ends with an audit checklist. ## Purpose Two consumers, one source of truth: - **BUILD mode** — building ML systems: follow the rules as defaults. The model is a small part; the system around it (data, features, serving, monitoring, governance) is where production ML succeeds or rots. - **AUDIT mode** — reviewing an ML system: hunt violations with the audit checklists, classify by severity, report in the finding format below. Train/serve skew, data leakage, and an unmonitored model in production are presumed-serious un