When asked to handle an ML deployment task, always produce these five deliverables, in order:

1. Pipeline Design — data/model flow from training artifact to serving
2. Deployment Strategy — how the model gets released (canary, blue-green, shadow, etc.)
3. Monitoring Plan — what's tracked, thresholds, alerting
4. Rollback Plan — trigger conditions and rollback mechanics
5. Resource Plan — compute, memory, scaling, cost estimate

Example minimal request: "We trained a fraud detection model, need to deploy it." → produce all 5 sections below, tailored to fraud detection (low-latency, high-stakes, needs strong drift monitoring).

Progress:

• Clarify model type, traffic pattern, latency/throughput requirements
• Design pipeline (training → registry → serving → feedback loop)
• Choose deployment strategy based on risk tolerance
• Define monitoring metrics and alert thresholds
• Define rollback triggers and mechanism
• Estimate resources and cost
• Present all 5 sections together, concise and actionable

1. Pipeline Design

Describe stages: data validation → model registry (versioned) → packaging (container/artifact) → serving layer (batch/real-time) → feedback/logging loop back to retraining. Name the specific tools if known (MLflow, Seldon, KServe, SageMaker, Vertex AI, etc.), otherwise describe generically by function.

2. Deployment Strategy

Pick one default, justify briefly:

• Canary (default for most cases): 5% → 25% → 100% traffic shift, gated by monitoring metrics
• Shadow deployment: new model receives mirrored traffic, no serving, used when validating high-risk models
• Blue-green: instant cutover with fast rollback, used when canary infra unavailable
• A/B test: used when comparing business-metric impact, not just technical correctness

3. Monitoring Plan

Cover four layers:

• Infra: latency (p50/p95/p99), throughput, error rate, resource utilization
• Data: input schema violations, feature drift (PSI/KL divergence), missing values
• Model: prediction distribution drift, confidence score distribution, output volume anomalies
• Business: downstream KPI (conversion, fraud catch rate, etc.), tied to ground truth when available (may be delayed)

Always specify concrete thresholds and alert channels, e.g. "PSI > 0.2 on top-5 features → warning; > 0.3 → auto-rollback trigger."

4. Rollback Plan

• Define automatic triggers (error rate spike, latency SLA breach, drift threshold breach)
• Define manual triggers (business metric degradation confirmed by stakeholder)
• Rollback mechanism: keep last N model versions warm/available, traffic reroute time target (e.g., < 2 min)
• Post-rollback: incident log, root cause analysis requirement

5. Resource Plan

• Compute: CPU/GPU type and count, based on inference load estimate
• Scaling: autoscaling policy (min/max replicas, scale-up trigger)
• Storage: model artifact size, versioning retention policy
• Cost estimate: rough monthly figure if inputs allow

Example 1: Input: "Deploy a recommendation model that serves 10k requests/sec, retrained weekly." Output:

• Pipeline Design: Weekly training job → MLflow registry → containerized FastAPI serving behind load balancer → click logs feed back to training data store
• Deployment Strategy: Canary (5%→25%→100% over 24h), gated on latency p95 < 50ms and CTR not dropping >2%
• Monitoring Plan: p95 latency, QPS, feature drift on user embeddings (PSI), CTR vs. control group, daily drift report
• Rollback Plan: Auto-rollback if p95 > 100ms for 5 min or CTR drops >5%; keep last 3 versions warm; rollback target < 1 min
• Resource Plan: 8x GPU inference nodes (T4), autoscale 4–12 replicas on QPS, model artifact ~2GB, retain 5 versions

Example 2: Input: "We need to monitor a fraud model already in production, no redeployment needed." Output: Skip Pipeline Design and Deployment Strategy sections (note they're unchanged); focus on Monitoring Plan (drift on transaction features, false negative rate proxy via delayed chargebacks, alert on precision drop), Rollback Plan (trigger + mechanism), and Resource Plan only if monitoring adds infra load.