MLOps Engineer
The agent operates as a senior MLOps engineer, deploying models to production, orchestrating training pipelines, monitoring model health, managing feature stores, and automating ML CI/CD.
Clarify First
Before deploying, confirm these inputs. If any is unknown or vague, ASK — do not assume:
Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.
Workflow
- Assess ML maturity -- Determine the current level (manual notebooks vs. automated pipelines vs. full CI/CD). Identify the highest-impact gap to close first.
- Build or extend training pipeline -- Define fetch-data, validate, preprocess, train, evaluate stages. Use Kubeflow, Airflow, or equivalent. Gate deployment on an accuracy threshold (e.g., > 0.85).
- Deploy model for serving -- Choose real-time (FastAPI + K8s) or batch (Spark/Parquet) based on latency requirements. Configure health checks, autoscaling, and resource limits.
- Register in model registry -- Log parameters, metrics, and artifacts in MLflow. Transition the winning version to Production stage; archive the previous version.
- Instrument monitoring -- Set up latency (P50/P95/P99), error rate, prediction-distribution, and feature-drift dashboards. Configure alerting thresholds.
- Validate end-to-end -- Run smoke tests against the serving endpoint. Confirm monitoring dashboards populate. Verify rollback procedure works.
MLOps Maturity Model
| Level |
Capabilities |
Key signals |
| 0 - Manual |
Jupyter notebooks, manual deploy |
No version control on models |
| 1 - Pipeline |
Automated training, versioned models |
MLflow tracking in use |
| 2 - CI/CD |
Continuous training, automated tests |
Feature store operational |
| 3 - Full MLOps |
Auto-retraining on drift, A/B testing |
SLA-backed monitoring |
Real-Time Serving Example
# model_server.py -- FastAPI model serving
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import mlflow.pyfunc, time
app = FastAPI()
model = mlflow.pyfunc.load_model("models:/fraud_detector/Production")
class PredictionRequest(BaseModel):
features: list[float]
class PredictionResponse(BaseModel):
prediction: float
model_version: str
latency_ms: float
@app.post("/predict", response_model=PredictionResponse)
async def predict(req: PredictionRequest):
start = time.time()
try:
pred = model.predict([req.features])[0]
return PredictionResponse(
prediction=pred,
model_version=model.metadata.run_id,
latency_ms=(time.time() - start) * 1000,
)
except Exception as e:
raise HTTPException(status_code=500, detail=str(e))
@app.get("/health")
async def health():
return {"status": "healthy", "model_loaded": model is not None}
Kubernetes Deployment
# k8s/model-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: model-server
spec:
replicas: 3
selector:
matchLabels: {app: model-server}
template:
metadata:
labels: {app: model-server}
spec:
containers:
- name: model-server
image: gcr.io/project/model-server:v1.2.3
ports: [{containerPort: 8080}]
resources:
requests: {memory: "2Gi", cpu: "1000m"}
limits: {memory: "4Gi", cpu: "2000m", nvidia.com/gpu: 1}
env:
- {name: MODEL_URI, value: "s3://models/production/v1.2.3"}
readinessProbe:
httpGet: {path: /health, port: 8080}
initialDelaySeconds: 30
periodSeconds: 10
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: model-server-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: model-server
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target: {type: Utilization, averageUtilization: 70}
Drift Detection
# monitoring/drift_detector.py
import numpy as np
from scipy import stats
from dataclasses import dataclass
@dataclass
class DriftResult:
feature: str
drift_score: float
is_drifted: bool
p_value: float
def detect_drift(reference: np.ndarray, current: np.ndarray, threshold: float = 0.05) -> DriftResult:
"""Detect distribution drift using Kolmogorov-Smirnov test."""
statistic, p_value = stats.ks_2samp(reference, current)
return DriftResult(feature="", drift_score=statistic, is_drifted=p_value < threshold, p_value=p_value)
def monitor_all_features(reference: dict, current: dict, threshold: float = 0.05) -> list[DriftResult]:
"""Run drift detection across all features; return list of results."""
results = []
for feat in reference:
r = detect_drift(reference[feat], current[feat], threshold)
r.feature = feat
results.append(r)
return results
Alert Rules
ALERT_RULES = {
"latency_p99": {"threshold": 200, "severity": "warning", "msg": "P99 latency exceeded 200 ms"},
"error_rate": {"threshold": 0.01, "severity": "critical", "msg": "Error rate exceeded 1%"},
"accuracy_drop": {"threshold": 0.05, "severity": "critical", "msg": "Accuracy dropped > 5%"},
"drift_score": {"threshold": 0.15, "severity": "warning", "msg": "Feature drift detected"},
}
Feature Store (Feast)
# features/customer_features.py
from feast import Entity, Feature, FeatureView, FileSource, ValueType
from datetime import timedelta
customer = Entity(name="customer_id", value_type=ValueType.INT64)
customer_stats = FeatureView(
name="customer_stats",
entities=["customer_id"],
ttl=timedelta(days=1),
features=[
Feature(name="total_purchases", dtype=ValueType.FLOAT),
Feature(name="avg_order_value", dtype=ValueType.FLOAT),
Feature(name="days_since_last_order", dtype=ValueType.INT32),
Feature(name="lifetime_value", dtype=ValueType.FLOAT),
],
source=FileSource(
path="gs://features/customer_stats.parquet",
timestamp_field="event_timestamp",
),
)
Online retrieval at serving time:
from feast import FeatureStore
store = FeatureStore(repo_path=".")
features = store.get_online_features(
features=["customer_stats:total_purchases", "customer_stats:avg_order_value"],
entity_rows=[{"customer_id": 1234}],
).to_dict()
Experiment Tracking (MLflow)
import mlflow
mlflow.set_tracking_uri("http://mlflow.company.com")
mlflow.set_experiment("fraud_detection")
with mlflow.start_run(run_name="xgboost_v2"):
mlflow.log_params({"n_estimators": 100, "max_depth": 6, "learning_rate": 0.1})
model = train_model(X_train, y_train)
mlflow.log_metrics({
"accuracy": accuracy_score(y_test, preds),
"f1": f1_score(y_test, preds),
})
mlflow.sklearn.log_model(model, "model", registered_model_name="fraud_detector")
For extended pipeline examples (Kubeflow, Airflow DAGs, full CI/CD workflows), see REFERENCE.md.
Reference Materials
REFERENCE.md -- Extended patterns: Kubeflow pipelines, Airflow DAGs, CI/CD workflows, model registry operations
references/deployment_patterns.md -- Model deployment strategies
references/monitoring_guide.md -- ML monitoring best practices
references/feature_store.md -- Feature store patterns
references/pipeline_design.md -- ML pipeline architecture
Scripts
python scripts/model_registry.py register --name fraud_detector --version v2.3 --metrics '{"f1":0.91,"auc":0.95}' --params '{"n_estimators":200}'
python scripts/model_registry.py promote --name fraud_detector --version v2.3 --stage production
python scripts/model_registry.py list --stage production --json
python scripts/model_registry.py compare --name fraud_detector --versions v2.2 v2.3
python scripts/drift_detector.py --reference train_data.csv --current prod_data.csv
python scripts/drift_detector.py --reference baseline.csv --current latest.csv --threshold 0.1 --json
python scripts/pipeline_validator.py --pipeline pipeline.json --strict
python scripts/pipeline_validator.py --pipeline pipeline.json --json
Tool Reference
| Tool |
Purpose |
Key Flags |
model_registry.py |
Register, promote, list, and compare model versions with metrics, parameters, and lifecycle stages |
register --name --version --metrics --params, promote --stage, list, compare --versions, --json |
drift_detector.py |
Detect data/model drift between reference and current datasets using KS statistic, PSI, and chi-square |
--reference <csv>, --current <csv>, --columns, --threshold, --json |
pipeline_validator.py |
Validate ML pipeline definitions for completeness, stage ordering, evaluation gates, and rollback config |
--pipeline <json>, --strict, --json |
Troubleshooting
| Problem |
Likely Cause |
Resolution |
| Model latency exceeds P99 SLA (> 200 ms) |
Model is too large, input preprocessing is slow, or pod resources are undersized |
Profile the serving endpoint; consider model distillation, input caching, or increasing CPU/memory limits |
drift_detector.py flags all features as drifted |
Threshold is too low or the reference data is from a different time period than expected |
Increase the threshold (try 0.15-0.2) or regenerate the reference dataset from a more representative window |
| Pipeline fails at the evaluation gate |
Model accuracy dropped below the configured threshold |
Check for data quality issues upstream; compare feature distributions with drift_detector.py; retrain with fresh data |
| Model registry shows "already registered" error |
The exact name + version combination was previously registered |
Use a new version string (e.g., v2.3.1) or remove the old entry if it was a test |
| Kubernetes pods crash-loop on model server |
OOM kill due to model size exceeding memory limits, or health check timeout too short |
Increase resources.limits.memory; extend initialDelaySeconds on readiness probe for large models |
| Feature store returns stale features |
Materialization job failed or ran outside the TTL window |
Check materialization logs; re-run materialize_features; consider reducing TTL or adding freshness alerts |
pipeline_validator.py reports STAGE_ORDER error |
Pipeline stages are defined out of the expected sequence (data -> transform -> train -> evaluate -> deploy) |
Reorder stages to follow the canonical sequence; the validator expects data stages before training stages |
Success Criteria
- All production models are registered in the model registry with version, metrics, and parameters before serving traffic.
- Drift detection runs on a scheduled cadence (at least weekly) with alerts when PSI > 0.2 or KS > 0.15.
- ML pipelines pass
pipeline_validator.py --strict with zero errors before deployment.
- Model serving latency stays within SLA: P50 < 50 ms, P95 < 100 ms, P99 < 200 ms.
- Every model promotion to production automatically archives the previous production version.
- Rollback to the previous model version completes in under 5 minutes with zero downtime.
- Pipeline stages include evaluation gates that block deployment when accuracy drops below the defined threshold.
Scope & Limitations
In scope: Model deployment (real-time and batch), ML pipeline orchestration, model registry management, drift detection (data drift, concept drift, prediction drift), feature store patterns, monitoring and alerting, Kubernetes deployment configurations, and CI/CD for ML.
Out of scope: Model architecture design and algorithm selection (see data-scientist), raw data ingestion pipelines, BI dashboard development, and business strategy.
Limitations: The Python tools use only the Python standard library. drift_detector.py computes KS statistic and PSI using approximations suitable for most distributions but does not support multivariate drift detection or Evidently/Alibi Detect integration. model_registry.py stores state in a local JSON file -- for production use, integrate with MLflow Model Registry or a similar platform. pipeline_validator.py validates structure and conventions but does not execute pipeline stages.
Integration Points
- Data Scientist (
data-analytics/data-scientist): Receives trained models with experiment metadata; promotes winning experiments to the registry for deployment.
- Analytics Engineer (
data-analytics/analytics-engineer): Feature engineering pipelines may depend on dbt mart models; schema changes trigger pipeline revalidation.
- Engineering (
engineering/senior-ml-engineer): Collaborates on model architecture optimization for serving constraints (latency, memory, GPU).
- Infrastructure (
engineering/): Kubernetes configurations, autoscaling policies, and CI/CD workflows are co-managed with platform engineering.
- Business Intelligence (
data-analytics/business-intelligence): Model predictions may feed into BI dashboards; monitoring metrics are surfaced in operational dashboards.
1---
2name: ml-ops-engineer
3description: >
4 MLOps across model deployment, ML pipelines, monitoring, and feature stores.
5 Use when deploying models to production, building training pipelines, setting
6 up drift detection, configuring feature stores, or automating ML CI/CD
7 workflows.
8license: MIT + Commons Clause
9metadata:
10 version: 1.0.0
11 author: borghei
12 category: data-analytics
13 updated: 2026-03-31
14 tags: [mlops, deployment, pipelines, monitoring, feature-store]
15---
16
17# MLOps Engineer
18
19The agent operates as a senior MLOps engineer, deploying models to production, orchestrating training pipelines, monitoring model health, managing feature stores, and automating ML CI/CD.
20
21## Clarify First
22
23Before deploying, confirm these inputs. If any is unknown or vague, ASK — do not assume:
24
25- [ ] **Serving mode + latency SLA** — real-time (FastAPI/K8s) or batch, and the P99 target (drives the entire deployment architecture)
26- [ ] **Current MLOps maturity** — manual, pipeline, CI/CD, or full (identifies the highest-impact gap to close first)
27- [ ] **Model artifact + registry/infra** — framework, where it is stored, and target platform (MLflow, K8s) (drives the serving and registry config)
28- [ ] **Monitoring thresholds** — drift and accuracy-drop limits plus check cadence (drives alert rules and drift detection)
29
30Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.
31
32## Workflow
33
341. **Assess ML maturity** -- Determine the current level (manual notebooks vs. automated pipelines vs. full CI/CD). Identify the highest-impact gap to close first.
352. **Build or extend training pipeline** -- Define fetch-data, validate, preprocess, train, evaluate stages. Use Kubeflow, Airflow, or equivalent. Gate deployment on an accuracy threshold (e.g., > 0.85).
363. **Deploy model for serving** -- Choose real-time (FastAPI + K8s) or batch (Spark/Parquet) based on latency requirements. Configure health checks, autoscaling, and resource limits.
374. **Register in model registry** -- Log parameters, metrics, and artifacts in MLflow. Transition the winning version to Production stage; archive the previous version.
385. **Instrument monitoring** -- Set up latency (P50/P95/P99), error rate, prediction-distribution, and feature-drift dashboards. Configure alerting thresholds.
396. **Validate end-to-end** -- Run smoke tests against the serving endpoint. Confirm monitoring dashboards populate. Verify rollback procedure works.
40
41## MLOps Maturity Model
42
43| Level | Capabilities | Key signals |
44|-------|-------------|------------|
45| 0 - Manual | Jupyter notebooks, manual deploy | No version control on models |
46| 1 - Pipeline | Automated training, versioned models | MLflow tracking in use |
47| 2 - CI/CD | Continuous training, automated tests | Feature store operational |
48| 3 - Full MLOps | Auto-retraining on drift, A/B testing | SLA-backed monitoring |
49
50## Real-Time Serving Example
51
52```python
53# model_server.py -- FastAPI model serving
54from fastapi import FastAPI, HTTPException
55from pydantic import BaseModel
56import mlflow.pyfunc, time
57
58app = FastAPI()
59model = mlflow.pyfunc.load_model("models:/fraud_detector/Production")
60
61class PredictionRequest(BaseModel):
62 features: list[float]
63
64class PredictionResponse(BaseModel):
65 prediction: float
66 model_version: str
67 latency_ms: float
68
69@app.post("/predict", response_model=PredictionResponse)
70async def predict(req: PredictionRequest):
71 start = time.time()
72 try:
73 pred = model.predict([req.features])[0]
74 return PredictionResponse(
75 prediction=pred,
76 model_version=model.metadata.run_id,
77 latency_ms=(time.time() - start) * 1000,
78 )
79 except Exception as e:
80 raise HTTPException(status_code=500, detail=str(e))
81
82@app.get("/health")
83async def health():
84 return {"status": "healthy", "model_loaded": model is not None}
85```
86
87## Kubernetes Deployment
88
89```yaml
90# k8s/model-deployment.yaml
91apiVersion: apps/v1
92kind: Deployment
93metadata:
94 name: model-server
95spec:
96 replicas: 3
97 selector:
98 matchLabels: {app: model-server}
99 template:
100 metadata:
101 labels: {app: model-server}
102 spec:
103 containers:
104 - name: model-server
105 image: gcr.io/project/model-server:v1.2.3
106 ports: [{containerPort: 8080}]
107 resources:
108 requests: {memory: "2Gi", cpu: "1000m"}
109 limits: {memory: "4Gi", cpu: "2000m", nvidia.com/gpu: 1}
110 env:
111 - {name: MODEL_URI, value: "s3://models/production/v1.2.3"}
112 readinessProbe:
113 httpGet: {path: /health, port: 8080}
114 initialDelaySeconds: 30
115 periodSeconds: 10
116---
117apiVersion: autoscaling/v2
118kind: HorizontalPodAutoscaler
119metadata:
120 name: model-server-hpa
121spec:
122 scaleTargetRef:
123 apiVersion: apps/v1
124 kind: Deployment
125 name: model-server
126 minReplicas: 2
127 maxReplicas: 10
128 metrics:
129 - type: Resource
130 resource:
131 name: cpu
132 target: {type: Utilization, averageUtilization: 70}
133```
134
135## Drift Detection
136
137```python
138# monitoring/drift_detector.py
139import numpy as np
140from scipy import stats
141from dataclasses import dataclass
142
143@dataclass
144class DriftResult:
145 feature: str
146 drift_score: float
147 is_drifted: bool
148 p_value: float
149
150def detect_drift(reference: np.ndarray, current: np.ndarray, threshold: float = 0.05) -> DriftResult:
151 """Detect distribution drift using Kolmogorov-Smirnov test."""
152 statistic, p_value = stats.ks_2samp(reference, current)
153 return DriftResult(feature="", drift_score=statistic, is_drifted=p_value < threshold, p_value=p_value)
154
155def monitor_all_features(reference: dict, current: dict, threshold: float = 0.05) -> list[DriftResult]:
156 """Run drift detection across all features; return list of results."""
157 results = []
158 for feat in reference:
159 r = detect_drift(reference[feat], current[feat], threshold)
160 r.feature = feat
161 results.append(r)
162 return results
163```
164
165## Alert Rules
166
167```python
168ALERT_RULES = {
169 "latency_p99": {"threshold": 200, "severity": "warning", "msg": "P99 latency exceeded 200 ms"},
170 "error_rate": {"threshold": 0.01, "severity": "critical", "msg": "Error rate exceeded 1%"},
171 "accuracy_drop": {"threshold": 0.05, "severity": "critical", "msg": "Accuracy dropped > 5%"},
172 "drift_score": {"threshold": 0.15, "severity": "warning", "msg": "Feature drift detected"},
173}
174```
175
176## Feature Store (Feast)
177
178```python
179# features/customer_features.py
180from feast import Entity, Feature, FeatureView, FileSource, ValueType
181from datetime import timedelta
182
183customer = Entity(name="customer_id", value_type=ValueType.INT64)
184
185customer_stats = FeatureView(
186 name="customer_stats",
187 entities=["customer_id"],
188 ttl=timedelta(days=1),
189 features=[
190 Feature(name="total_purchases", dtype=ValueType.FLOAT),
191 Feature(name="avg_order_value", dtype=ValueType.FLOAT),
192 Feature(name="days_since_last_order", dtype=ValueType.INT32),
193 Feature(name="lifetime_value", dtype=ValueType.FLOAT),
194 ],
195 online=True,
196 source=FileSource(
197 path="gs://features/customer_stats.parquet",
198 timestamp_field="event_timestamp",
199 ),
200)
201```
202
203**Online retrieval at serving time:**
204```python
205from feast import FeatureStore
206store = FeatureStore(repo_path=".")
207features = store.get_online_features(
208 features=["customer_stats:total_purchases", "customer_stats:avg_order_value"],
209 entity_rows=[{"customer_id": 1234}],
210).to_dict()
211```
212
213## Experiment Tracking (MLflow)
214
215```python
216import mlflow
217
218mlflow.set_tracking_uri("http://mlflow.company.com")
219mlflow.set_experiment("fraud_detection")
220
221with mlflow.start_run(run_name="xgboost_v2"):
222 mlflow.log_params({"n_estimators": 100, "max_depth": 6, "learning_rate": 0.1})
223 model = train_model(X_train, y_train)
224 mlflow.log_metrics({
225 "accuracy": accuracy_score(y_test, preds),
226 "f1": f1_score(y_test, preds),
227 })
228 mlflow.sklearn.log_model(model, "model", registered_model_name="fraud_detector")
229```
230
231For extended pipeline examples (Kubeflow, Airflow DAGs, full CI/CD workflows), see `REFERENCE.md`.
232
233## Reference Materials
234
235- `REFERENCE.md` -- Extended patterns: Kubeflow pipelines, Airflow DAGs, CI/CD workflows, model registry operations
236- `references/deployment_patterns.md` -- Model deployment strategies
237- `references/monitoring_guide.md` -- ML monitoring best practices
238- `references/feature_store.md` -- Feature store patterns
239- `references/pipeline_design.md` -- ML pipeline architecture
240
241## Scripts
242
243```bash
244python scripts/model_registry.py register --name fraud_detector --version v2.3 --metrics '{"f1":0.91,"auc":0.95}' --params '{"n_estimators":200}'
245python scripts/model_registry.py promote --name fraud_detector --version v2.3 --stage production
246python scripts/model_registry.py list --stage production --json
247python scripts/model_registry.py compare --name fraud_detector --versions v2.2 v2.3
248python scripts/drift_detector.py --reference train_data.csv --current prod_data.csv
249python scripts/drift_detector.py --reference baseline.csv --current latest.csv --threshold 0.1 --json
250python scripts/pipeline_validator.py --pipeline pipeline.json --strict
251python scripts/pipeline_validator.py --pipeline pipeline.json --json
252```
253
254## Tool Reference
255
256| Tool | Purpose | Key Flags |
257|------|---------|-----------|
258| `model_registry.py` | Register, promote, list, and compare model versions with metrics, parameters, and lifecycle stages | `register --name --version --metrics --params`, `promote --stage`, `list`, `compare --versions`, `--json` |
259| `drift_detector.py` | Detect data/model drift between reference and current datasets using KS statistic, PSI, and chi-square | `--reference <csv>`, `--current <csv>`, `--columns`, `--threshold`, `--json` |
260| `pipeline_validator.py` | Validate ML pipeline definitions for completeness, stage ordering, evaluation gates, and rollback config | `--pipeline <json>`, `--strict`, `--json` |
261
262## Troubleshooting
263
264| Problem | Likely Cause | Resolution |
265|---------|-------------|------------|
266| Model latency exceeds P99 SLA (> 200 ms) | Model is too large, input preprocessing is slow, or pod resources are undersized | Profile the serving endpoint; consider model distillation, input caching, or increasing CPU/memory limits |
267| `drift_detector.py` flags all features as drifted | Threshold is too low or the reference data is from a different time period than expected | Increase the threshold (try 0.15-0.2) or regenerate the reference dataset from a more representative window |
268| Pipeline fails at the evaluation gate | Model accuracy dropped below the configured threshold | Check for data quality issues upstream; compare feature distributions with `drift_detector.py`; retrain with fresh data |
269| Model registry shows "already registered" error | The exact name + version combination was previously registered | Use a new version string (e.g., v2.3.1) or remove the old entry if it was a test |
270| Kubernetes pods crash-loop on model server | OOM kill due to model size exceeding memory limits, or health check timeout too short | Increase `resources.limits.memory`; extend `initialDelaySeconds` on readiness probe for large models |
271| Feature store returns stale features | Materialization job failed or ran outside the TTL window | Check materialization logs; re-run `materialize_features`; consider reducing TTL or adding freshness alerts |
272| `pipeline_validator.py` reports STAGE_ORDER error | Pipeline stages are defined out of the expected sequence (data -> transform -> train -> evaluate -> deploy) | Reorder stages to follow the canonical sequence; the validator expects data stages before training stages |
273
274## Success Criteria
275
276- All production models are registered in the model registry with version, metrics, and parameters before serving traffic.
277- Drift detection runs on a scheduled cadence (at least weekly) with alerts when PSI > 0.2 or KS > 0.15.
278- ML pipelines pass `pipeline_validator.py --strict` with zero errors before deployment.
279- Model serving latency stays within SLA: P50 < 50 ms, P95 < 100 ms, P99 < 200 ms.
280- Every model promotion to production automatically archives the previous production version.
281- Rollback to the previous model version completes in under 5 minutes with zero downtime.
282- Pipeline stages include evaluation gates that block deployment when accuracy drops below the defined threshold.
283
284## Scope & Limitations
285
286**In scope:** Model deployment (real-time and batch), ML pipeline orchestration, model registry management, drift detection (data drift, concept drift, prediction drift), feature store patterns, monitoring and alerting, Kubernetes deployment configurations, and CI/CD for ML.
287
288**Out of scope:** Model architecture design and algorithm selection (see data-scientist), raw data ingestion pipelines, BI dashboard development, and business strategy.
289
290**Limitations:** The Python tools use only the Python standard library. `drift_detector.py` computes KS statistic and PSI using approximations suitable for most distributions but does not support multivariate drift detection or Evidently/Alibi Detect integration. `model_registry.py` stores state in a local JSON file -- for production use, integrate with MLflow Model Registry or a similar platform. `pipeline_validator.py` validates structure and conventions but does not execute pipeline stages.
291
292## Integration Points
293
294- **Data Scientist** (`data-analytics/data-scientist`): Receives trained models with experiment metadata; promotes winning experiments to the registry for deployment.
295- **Analytics Engineer** (`data-analytics/analytics-engineer`): Feature engineering pipelines may depend on dbt mart models; schema changes trigger pipeline revalidation.
296- **Engineering** (`engineering/senior-ml-engineer`): Collaborates on model architecture optimization for serving constraints (latency, memory, GPU).
297- **Infrastructure** (`engineering/`): Kubernetes configurations, autoscaling policies, and CI/CD workflows are co-managed with platform engineering.
298- **Business Intelligence** (`data-analytics/business-intelligence`): Model predictions may feed into BI dashboards; monitoring metrics are surfaced in operational dashboards.