End-to-end Rules for building explainable AI (XAI) pipelines in Python using SHAP, LIME, Captum and related tooling.
Your machine learning models are making critical decisions, but can you explain why? These Cursor Rules transform complex XAI development from a research experiment into a robust, production-ready system that stakeholders actually trust.
You're shipping models that work great in testing, but then:
Sound familiar? You need explainability built into your workflow, not bolted on afterward.
These Cursor Rules give you a complete framework for building explainable AI that goes beyond toy examples. You get:
End-to-End XAI Pipelines: From SHAP value generation to compliance logging, with proper error handling and monitoring built in.
Framework-Agnostic Architecture: Works across PyTorch, TensorFlow, and scikit-learn with consistent APIs and patterns.
Production-Grade Reliability: Type safety, comprehensive testing, and performance budgets that keep explanations fast enough for real applications.
Here's what generating SHAP explanations looks like with these rules:
def generate_shap_values(model: ModelProto, X: pd.DataFrame) -> pd.DataFrame:
"""Return per-sample SHAP values aligned with X columns."""
if X.empty:
raise ValueError("Input dataframe is empty; cannot generate explanations.")
explainer = shap.TreeExplainer(model)
shap_values = explainer(X)
return pd.DataFrame(shap_values.values, columns=X.columns, index=X.index)
Clean, typed, testable, and ready for production.
⚡ 60% Faster XAI Development: Skip the research phase with battle-tested patterns for SHAP, LIME, Captum, and more.
🛡️ Built-in Compliance: Automatic model cards, audit logging, and bias monitoring that satisfy regulatory requirements from day one.
🔧 Proper Testing Strategy: Perturbation tests, golden-set visual regression, and user studies that actually validate your explanations work.
📊 Production Monitoring: Real-time explanation drift detection and performance metrics that prevent silent failures.
# Typical research notebook mess
import shap
explainer = shap.something(model) # which explainer?
values = explainer.shap_values(X) # what if this fails?
# Plot somewhere, maybe save, hope it works in production
# Clear separation of concerns with proper error handling
from xai.explainers import create_explainer
from xai.monitoring import log_explanation_metrics
@monitor_latency("explanation_generation")
def explain_prediction(model_version: str, features: pd.DataFrame) -> ExplanationResult:
explainer = create_explainer(model_version)
try:
shap_values = explainer.generate(features)
return ExplanationResult(
values=shap_values,
metadata={"method": "shap", "model_version": model_version}
)
except ExplanationError as e:
log_explanation_failure(e, model_version)
raise
Instead of manual checks, you get continuous monitoring:
# Automatic bias scans in your CI pipeline
def test_explanation_fairness(model: ModelProto, test_data: pd.DataFrame):
explanations = generate_explanations(model, test_data)
bias_report = check_disparate_impact(explanations, protected_attrs=["gender", "race"])
assert bias_report.max_ratio < 1.2, f"Bias detected: {bias_report}"
The same explanation API works across all your models:
# Works for scikit-learn, PyTorch, TensorFlow
explainer = ExplainerFactory.create(model_type="tree", model=xgb_model)
explanations = explainer.explain(X_test)
explainer = ExplainerFactory.create(model_type="deep", model=pytorch_model)
explanations = explainer.explain(X_test) # Same interface
Save the rules to .cursor-rules in your project root. Cursor will automatically apply the XAI patterns to all your Python files.
your_xai_project/
├── xai/
│ ├── explainers/ # SHAP, LIME, Captum modules
│ ├── monitoring/ # Drift detection, metrics
│ ├── compliance/ # Model cards, audit logs
│ └── schemas.py # Pydantic models
├── tests/
│ ├── test_explanations.py
│ └── test_bias_detection.py
└── notebooks/
├── global_overview.ipynb
└── local_inspection.ipynb
# xai/explainers/shap_explainer.py - Cursor generates this pattern
class ShapExplainer(BaseExplainer):
def __init__(self, model: ModelProto, background_data: pd.DataFrame):
self.model = model
self.explainer = self._create_explainer(model, background_data)
def explain(self, X: pd.DataFrame) -> ExplanationResult:
# Full implementation with error handling, validation, caching
pass
# FastAPI endpoints are generated with proper schemas
@app.post("/explain", response_model=ExplanationResponse)
async def explain_prediction(request: ExplanationRequest):
# Production-ready endpoint with validation and monitoring
pass
Compliance Ready: Model cards, datasheets, and audit logs generated automatically. Pass regulatory reviews on first submission.
Stakeholder Trust: Clear, tested explanations that non-technical users actually understand and trust.
Faster Debugging: When models behave unexpectedly, you have explanation lineage to trace exactly what happened.
Bias Prevention: Continuous monitoring catches fairness issues before they impact users.
Deployment Confidence: Blue-green deployment with explanation drift detection means no more surprise model failures.
Team Velocity: Junior developers can implement complex XAI patterns correctly using the established rules and patterns.
You'll ship explainable AI systems that work reliably in production, satisfy compliance requirements, and build stakeholder confidence in your ML deployments.
Start with your next model—implement these rules and watch your XAI development workflow transform from experimental to enterprise-ready.
## Technology Stack Declaration
You are an expert in Python-based Explainable AI (XAI) using:
- Core: Python ≥3.10, Conda/Poetry, type hints (PEP 484)
- ML Frameworks: PyTorch, TensorFlow/Keras, Scikit-Learn, XGBoost, LightGBM
- Explainability Libraries: SHAP, LIME, Captum, ELI5, What-If Tool, DeepLIFT, Grad-CAM, Occlusion Sensitivity
- Supporting Tools: JupyterLab, MLflow, Weights & Biases, FastAPI, Docker, GitHub Actions
## Key Principles
- Prefer inherently interpretable models (e.g., GAMs, decision trees) for high-stakes contexts; escalate to post-hoc methods only when necessary.
- Explanations must be:
• faithful (align with actual model logic),
• intelligible (plain language/visuals for target audience),
• actionable (enable debugging or decision revision),
• consistent (same input → same explanation).
- Maintain end-to-end provenance: data lineage, preprocessing, hyper-parameters, training code, model version, explanation method & version.
- Documentation artefacts: Model Cards, Datasheets for Datasets, Risk Assessments, README.md per experiment.
- Separate concerns: modelling, explanation generation, UI rendering, and compliance logging live in distinct modules/packages.
- Treat explanations as first-class testable outputs; version and monitor them exactly like predictions.
## Python
- Use PEP 8 + Black; 120-char line length when notebooks are converted to .py.
- Mandatory type hints; run `mypy --strict` in CI.
- One module per conceptual unit: `model.py`, `explain.py`, `monitoring.py`, `schemas.py` (Pydantic), `tests/`.
- Function template:
```python
def generate_shap_values(model: ModelProto, X: pd.DataFrame) -> pd.DataFrame:
"""Return per-sample SHAP values aligned with X columns."""
if X.empty:
raise ValueError("Input dataframe is empty; cannot generate explanations.")
explainer = shap.TreeExplainer(model) # single construction point
shap_values = explainer(X)
return pd.DataFrame(shap_values.values, columns=X.columns, index=X.index)
```
- Never swallow exceptions—wrap with custom `XAIError` hierarchy that adds context (`model_version`, `explanation_type`).
- Serialization: store explanation arrays as Parquet/Arrow; plots as SVG/PNG + JSON metadata.
## Error Handling and Validation
- Validate pre-conditions early (data shapes, feature names, model signature) → `ValueError`.
- Catch external library errors (`shap.common.Exception`) and re-raise `ExplanationGenerationError` with guidance.
- Unit tests: assert both numerical correctness (within tolerance) and monotonicity/feature influence expectations.
- Perturbation testing: randomly vary top-k features by ±δ; expected prediction delta must align with SHAP contribution ±ε.
- Live pipelines emit `explanation_latency_ms`, `explanation_missing_rate` to Prometheus/Grafana.
- Automatic bias scans: disparate impact ratio, counterfactual fairness checks; fail-fast in CI if thresholds breached.
## Framework-Specific Rules
### SHAP
- Tree models: use `TreeExplainer`; deep nets: `DeepExplainer`; ML-agnostic: `KernelExplainer`.
- Cache background dataset (≤1000 stratified rows) for performance.
- Never truncate SHAP values; instead sort and display top-n per audience persona (n=5 for executives, full list for data scientists).
### LIME
- Use `lime_tabular.LimeTabularExplainer` with `feature_selection="lasso_path"` for stability.
- Sample size ≥ 5000 for tabular, ≥1000 segments for images.
- Persist the random seed (`explainer.random_state`) for reproducibility.
### Captum (PyTorch)
- Standardise inputs with `model.eval()` and `requires_grad_(True)`.
- Chain multiple attribution methods in `captum.attr.Composite` when single method is inconclusive.
- Wrap custom layers with `@captum.attr.supports` to enable attribution.
### Grad-CAM / Occlusion
- Target final convolutional layer; avoid fully-connected layers for heatmaps.
- Apply ReLU on CAM output to discard negative signals (per standard Grad-CAM++ best practice).
## Additional Sections
### Testing
- User studies: include SUS (System Usability Scale) & trust questionnaire; target score ≥ 68.
- Golden-set visual regression tests via `pytest-regressions` on explanation plots.
### Performance & Scalability
- Budget ≤ 25% of total inference latency for explanation generation; implement async queue for heavy SHAP tasks.
- Use `joblib` or Ray for parallel explanation on batch requests.
### Security & Compliance
- Strip PII from explanations; mask feature names if they reveal sensitive attributes.
- Log `xai_audit.jsonl` per request: `timestamp`, `request_id`, `user_id_hash`, `pred`, `explanation_digest`.
- GDPR: provide end-user download of personal explanations; store for ≤ 30 days unless legal hold.
### Documentation & Communication
- Each PR adding/altering models MUST update `MODEL_CARD.md` sections: Intended Use, Factors, Metrics, Ethical Considerations, Caveats.
- Provide two explanation views: `global_overview.ipynb` (aggregate feature importance) and `local_inspection.ipynb` (instance-level drill-down).
### Deployment
- Package as Docker image; expose `/predict` and `/explain` endpoints (FastAPI) with versioned OpenAPI schema.
- Blue-green strategy; block promote to production until `monitoring/explanation_drift.py` reports `drift_p ≤ 0.05` for 7 consecutive days.
---
Adhere to these rules to produce transparent, reliable, and user-centric ML systems with explainability baked in from day one.