mle-workflow skill

Machine Learning Engineering Workflow

Use this skill to turn model work into a production ML system with clear data contracts, repeatable training, measurable quality gates, deployable artifacts, and operational monitoring.

When to Activate

• Planning or reviewing a production ML feature, model refresh, ranking system, recommender, classifier, embedding workflow, or forecasting pipeline
• Converting notebook code into a reusable training, evaluation, batch inference, or online inference pipeline
• Designing model promotion criteria, offline/online evals, experiment tracking, or rollback paths
• Debugging failures caused by data drift, label leakage, stale features, artifact mismatch, or inconsistent training and serving logic
• Adding model monitoring, canary rollout, shadow traffic, or post-deploy quality checks

Scope Calibration

Use only the lanes that fit the system in front of you. This skill is useful for ranking, search, recommendations, classifiers, forecasting, embeddings, LLM workflows, anomaly detection, and batch analytics, but it should not force one architecture onto all of them.

• Do not assume every model has supervised labels, online serving, a feature store, PyTorch, GPUs, human review, A/B tests, or real-time feedback.
• Do not add heavyweight MLOps machinery when a data contract, baseline, eval script, and rollback note would make the change reviewable.
• Do make assumptions explicit when the project lacks labels, delayed outcomes, slice definitions, production traffic, or monitoring ownership.
• Treat examples as interchangeable scaffolds. Replace metrics, serving mode, data stores, and rollout mechanics with the project-native equivalents.

Related Skills

• python-patterns and python-testing for Python implementation and pytest coverage
• pytorch-patterns for deep learning models, data loaders, device handling, and training loops
• eval-harness and ai-regression-testing for promotion gates and agent-assisted regression checks
• database-migrations, postgres-patterns, and clickhouse-io for data storage and analytics surfaces
• deployment-patterns, docker-patterns, and security-review for serving, secrets, containers, and production hardening

Reuse the SWE Surface

Do not treat MLE as separate from software engineering. Most ECC SWE workflows apply directly to ML systems, often with stricter failure modes:

The recommended minimal --with capability:machine-learning install keeps the core agent surface available alongside this skill. For skill-only or agent-limited harnesses, pair skill:mle-workflow with agent:mle-reviewer where the target supports agents.

Ten MLE Task Simulations

Use these simulations as coverage checks when planning or reviewing MLE work. A strong MLE workflow should reduce each task to explicit contracts, reusable SWE surfaces, automated evidence, and a reviewable artifact.

Iteration Compact

Before touching model code, compress the work into one reviewable artifact. This should be short enough to fit in a PR description and precise enough that another engineer can challenge the tradeoffs.

Goal:
Who cares:
Decision owner:
User or system action changed by the model:
Success metric:
Guardrail metrics:
Mistake budget:
Unacceptable mistakes:
Acceptable mistakes:
Assumptions:
Constraints:
Labels and data snapshot:
Baseline:
Candidate signals:
Threshold or config plan:
Eval slices:
Known risks:
Next experiment:
Rollback or fallback:

This compact is the MLE equivalent of a strong SWE design note. It keeps the team from optimizing a metric no one trusts, adding features that do not address the real error mode, or shipping complexity without a rollback.

Decision Brain

Use this loop whenever the task is ambiguous, high-impact, or metric-heavy:

1. Start from the decision, not the model. Name the action that changes downstream behavior.
2. Name who cares and why. Different stakeholders pay different costs for false positives, false negatives, latency, compute spend, opacity, or missed opportunities.
3. Convert ambiguity into hypotheses. Ask what signal would separate outcomes, what evidence would disprove it, and what simple baseline should be hard to beat.
4. Research prior art or a nearby known problem before inventing a bespoke system.
5. Score choices with (probability, confidence) x (cost, severity, importance, impact).
6. Consider adversarial behavior, incentives, selective disclosure, distribution shift, and feedback loops.
7. Prefer the simplest change that reduces the most important mistake. Simplicity is not laziness; it is a way to minimize blunders while preserving iteration speed.
8. Capture the decision, evidence, counterargument, and next reversible step.

Metric and Mistake Economics

Choose metrics from failure costs, not habit:

• Use a confusion matrix early so the team can discuss concrete false positives and false negatives instead of abstract accuracy.
• Favor precision when the cost of an incorrect positive decision dominates.
• Favor recall when the cost of a missed positive dominates.
• Use F1 only when the precision/recall tradeoff is genuinely balanced and explainable.
• Use AUC or ranking metrics when ordering quality matters more than a single threshold.
• Track latency, throughput, memory, and cost as first-class metrics because they shape feasible model complexity.
• Compare against a baseline and the current production model before celebrating an offline gain.
• Treat real-world feedback signals as delayed labels with bias, lag, and coverage gaps; do not treat them as ground truth without analysis.

Every metric choice should state which mistake it makes cheaper, which mistake it makes more likely, and who absorbs that cost.

Data and Feature Hypotheses

Features should come from a theory of separation:

• Text, categorical fields, numeric histories, graph relationships, recency, frequency, and aggregates are candidate signal families, not automatic features.
• For every feature family, state why it should separate outcomes and how it could leak future information.
• For noisy labels, consider adjudication, label confidence, soft targets, or confidence weighting.
• For class imbalance, compare weighted loss, resampling, threshold movement, and calibrated decision rules.
• For missing values, decide whether absence is informative, imputable, or a reason to abstain.
• For outliers, decide whether to clip, bucket, investigate, or preserve them as rare but important signal.
• For correlated features, check whether they are redundant, unstable, or proxies for unavailable future state.

Do not add model complexity until error analysis shows that the baseline is failing for a reason additional signal or capacity can plausibly fix.

Error Analysis Loop

After each baseline, training run, threshold change, or config change:

1. Split mistakes into false positives, false negatives, abstentions, low-confidence cases, and system failures.
2. Cluster errors by shared traits: language, entity type, source, time, geography, device, sparsity, recency, feature freshness, label source, or model version.
3. Separate model mistakes from data bugs, label ambiguity, product ambiguity, instrumentation gaps, and serving mismatches.
4. Trace each major cluster to one of four moves: better labels, better features, better threshold/config, or better product fallback.
5. Preserve every important mistake as a regression test, eval slice, dashboard panel, or runbook entry.
6. Write the next iteration as a falsifiable experiment, not a vague "improve model" task.

The strongest MLE loop is not train -> metric -> ship. It is mistake -> cluster -> hypothesis -> experiment -> evidence -> simpler system.

Observation Ledger

Keep a compact decision and evidence trail beside the code, PR, experiment report, or runbook:

Iteration:
Change:
Why this mattered:
Metric movement:
Slice movement:
False positives:
False negatives:
Unexpected errors:
Decision:
Tradeoff accepted:
Lesson captured:
Regression added:
Debt created:
Next iteration:

Use the ledger to make model work cumulative. The goal is for each iteration to make the next decision easier, not merely to produce another artifact.

Core Workflow

1. Define the Prediction Contract

Capture the product-level contract before writing model code:

• Prediction target and decision owner
• Input entity, output schema, confidence/calibration fields, and allowed latency
• Batch, online, streaming, or hybrid serving mode
• Fallback behavior when the model, feature store, or dependency is unavailable
• Human review or override path for high-impact decisions
• Privacy, retention, and audit requirements for inputs, predictions, and labels

Do not accept "improve the model" as a requirement. Tie the model to an observable product behavior and a measurable acceptance gate.

2. Lock the Data Contract

Every ML task needs an explicit data contract:

• Entity grain and primary key
• Label definition, label timestamp, and label availability delay
• Feature timestamp, freshness SLA, and point-in-time join rules
• Train, validation, test, and backtest split policy
• Required columns, allowed nulls, ranges, categories, and units
• PII or sensitive fields that must not enter training artifacts or logs
• Dataset version or snapshot ID for reproducibility

Guard against leakage first. If a feature is not available at prediction time, or is joined using future information, remove it or move it to an analysis-only path.

3. Build a Reproducible Pipeline

Training code should be runnable by another engineer without hidden notebook state:

• Use typed config files or dataclasses for all hyperparameters and paths
• Pin package and model dependencies
• Set random seeds and document any nondeterministic GPU behavior
• Record dataset version, code SHA, config hash, metrics, and artifact URI
• Save preprocessing logic with the model artifact, not separately in a notebook
• Keep train, eval, and inference transformations shared or generated from one source
• Make every step idempotent so retries do not corrupt artifacts or metrics

Prefer immutable values and pure transformation functions. Avoid mutating shared data frames or global config during feature generation.

import hashlib
from dataclasses import dataclass
from pathlib import Path


@dataclass(frozen=True)
class TrainingConfig:
    dataset_uri: str
    model_dir: Path
    seed: int
    learning_rate: float
    batch_size: int


def artifact_name(config: TrainingConfig, code_sha: str) -> str:
    config_key = f"{config.dataset_uri}:{config.seed}:{config.learning_rate}:{config.batch_size}"
    config_hash = hashlib.sha256(config_key.encode("utf-8")).hexdigest()[:12]
    return f"{code_sha[:12]}-{config_hash}"

4. Evaluate Before Promotion

Promotion criteria should be declared before training finishes:

• Baseline model and current production model comparison
• Primary metric aligned to product behavior
• Guardrail metrics for latency, calibration, fairness slices, cost, and error concentration
• Slice metrics for important cohorts, geographies, devices, languages, or data sources
• Confidence intervals or repeated-run variance when metrics are noisy
• Failure examples reviewed by a human for high-impact models
• Explicit "do not ship" thresholds

PROMOTION_GATES = {
    "auc": ("min", 0.82),
    "calibration_error": ("max", 0.04),
    "p95_latency_ms": ("max", 80),
}


def assert_promotion_ready(metrics: dict[str, float]) -> None:
    missing = sorted(name for name in PROMOTION_GATES if name not in metrics)
    if missing:
        raise ValueError(f"Model promotion metrics missing required gates: {missing}")

    failures = {
        name: value
        for name, (direction, threshold) in PROMOTION_GATES.items()
        for value in [metrics[name]]
        if (direction == "min" and value < threshold)
        or (direction == "max" and value > threshold)
    }
    if failures:
        raise ValueError(f"Model failed promotion gates: {failures}")

Use offline metrics as gates, not guarantees. When the model changes product behavior, plan shadow evaluation, canary rollout, or A/B testing before full rollout.

5. Package for Serving

An ML artifact is production-ready only when the serving contract is testable:

• Model artifact includes version, training data reference, config, and preprocessing
• Input schema rejects invalid, stale, or out-of-range features
• Output schema includes model version and confidence or explanation fields when useful
• Serving path has timeout, batching, resource limits, and fallback behavior
• CPU/GPU requirements are explicit and tested
• Prediction logs avoid PII and include enough identifiers for debugging and label joins
• Integration tests cover missing features, stale features, bad types, empty batches, and fallback path

Never let training-only feature code diverge from serving feature code without a test that proves equivalence.