1. Promise
One-sentence promise
After this lecture, you can document model risks clearly, escalate issues without drama, and align accuracy improvements with business safety so sign-off is defensible.
End tag line
A model is approved when it is safe, not when it is clever.
2. Learning objectives
After reading this lecture, you will be able to:
- Produce a “sign-off pack” that stakeholders can approve without chasing you.
- Document risks as a structured register: risk → evidence → control → owner → action.
- Escalate issues with clear triggers and options (restrict, rollback, retrain).
- Translate technical metrics into safety outcomes (loss, drawdown, capital, client harm).
- Separate “accuracy wins” from “safe deployment”.
3. Conceptual core
3.1 How you document risks
Risk documentation must be:
- explicit,
- evidence-based,
- actionable.
Risk register format (minimum viable)
Each risk entry contains:
- Risk statement
- “Model may underperform in high-vol regimes, causing oversized positions.”
- Impact
- what goes wrong in business terms (loss, client harm, capital breach).
- Likelihood
- qualitative is fine (low/med/high) with reasoning.
- Evidence
- robustness results, worst-window metrics, stress tests.
- Controls
- monitoring metric, threshold, action.
- Residual risk
- what remains even with controls.
- Owner
- who is accountable for monitoring and action.
Validator sentence
If you cannot name the risk, you cannot control the risk.
3.2 How you escalate issues
Escalation is a protocol, not emotion.
Escalation triggers (examples)
- data integrity hard fail (duplicates, missing blocks) → stop line.
- drift red for windows → restrict/disable.
- performance red in stress bucket → disable for that bucket.
- repeated tail events beyond expectation → governance review.
Escalation message content (always the same skeleton)
- What happened (facts, timestamp, run ID).
- What it means (risk).
- What you did immediately (containment).
- Options (A/B/C) and recommendation.
- What you need from stakeholder (decision/approval).
Engineering rule
Escalate early with options. Do not “wait for one more day”.
Validator sentence
A model incident is handled like an operational incident: detect, contain, decide.
3.3 Aligning “model accuracy” with “business safety”
Accuracy is not the objective. Accuracy is a proxy.
Business safety asks:
- What is the worst-case behaviour?
- What happens under stress?
- How does error translate into loss?
A clean mapping:
- Prediction metric
- RMSE/MAE/AUC (model-level)
- Decision metric
- P&L, Sharpe-like, drawdown, breach rate (decision-level)
- Safety constraints
- risk limits, capital usage, client fairness, latency, auditability
Core rule
A model is acceptable if: - it improves or preserves decision-level outcomes, - and it respects safety constraints, - and it has monitoring + fallback.
A model is not acceptable if: - it improves RMSE but worsens tail loss, - or it cannot be monitored, - or it cannot be explained in safe-usage language.
Slide-ready sentence
A small accuracy gain is irrelevant if it increases tail risk.
4. The “sign-off pack” (what you deliver)
A sign-off pack should include:
- Model card
- intended use, limitations, monitoring.
- Assumptions page
- operating envelope.
- Validation report
- protocol, fold stability, worst-window, leakage checks.
- Robustness report
- sensitivity grid, subperiod metrics, stress table.
- Monitoring spec
- drift metrics, thresholds, actions, owners.
- Risk register
- top risks with controls and residual risk.
- Handover note
- run IDs, artefact paths, who supports what.
If stakeholders have these, sign-off becomes easy.
5. Control lens
Sign-off is acceptance of an operating envelope. In control, you do not approve a controller because it tracks well in one scenario. You approve it because: - it respects constraints, - it behaves under disturbances, - it has fallback modes.
Same in finance.
6. Python lab (generate a risk register + sign-off pack stubs from run artefacts)
This lab creates a minimal sign-off pack directory:
MODEL_CARD.mdASSUMPTIONS.mdRISK_REGISTER.csvMONITORING_SPEC.mdHANDOVER.md
It is deliberately simple. It shows how you automate credibility.
import os
import pandas as pd
from datetime import datetime
run_id = "2026-02-09_174500_demo"
run_dir = os.path.join("signoff_pack", run_id)
os.makedirs(run_dir, exist_ok=True)
# Example artefacts (normally read from your actual run outputs)
metrics = {
"rmse_mean": 1.10,
"rmse_worst_fold": 1.85,
"stress_rmse_vol_x2": 2.70,
}
assumptions = [
"Timestamps are monotonic and unique.",
"Missingness per key feature < 1% per day.",
"Model is used only for horizon h=1 day.",
"Disable in extreme volatility regimes (vol proxy above threshold).",
]
# 1) Model card
model_card = f"""# Model card — Demo forecasting model
- **Run ID:** {run_id}
- **Date:** {datetime.now().strftime("%Y-%m-%d")}
- **Intended use:** 1-day forecasting support; baseline decision aid.
- **Primary metric:** RMSE (rolling), worst-fold RMSE.
- **Performance:** RMSE mean={metrics["rmse_mean"]}, worst fold={metrics["rmse_worst_fold"]}
- **Limitations:** Degrades under volatility shocks (stress RMSE x2={metrics["stress_rmse_vol_x2"]})
- **Monitoring:** data drift (feature z), performance drift (rolling RMSE), volatility regime.
- **Fallback:** revert to baseline or disable when red.
"""
with open(os.path.join(run_dir, "MODEL_CARD.md"), "w", encoding="utf-8") as f:
f.write(model_card)
# 2) Assumptions page
assump_md = "# Assumptions\n\n" + "\n".join([f"- {a}" for a in assumptions]) + "\n"
with open(os.path.join(run_dir, "ASSUMPTIONS.md"), "w", encoding="utf-8") as f:
f.write(assump_md)
# 3) Monitoring spec
monitoring_md = """# Monitoring spec (minimal)
## Data integrity (hard fail)
- duplicates, non-monotonic timestamps, missing blocks
## Data drift (amber/red)
- rolling mean z-score of key features (amber > 2, red > 3)
## Performance drift (amber/red)
- rolling RMSE vs training baseline (amber > +1σ, red > +2σ for 3 windows)
## Actions
- Amber: restrict usage + review.
- Red: disable + incident ticket + retraining decision.
"""
with open(os.path.join(run_dir, "MONITORING_SPEC.md"), "w", encoding="utf-8") as f:
f.write(monitoring_md)
# 4) Risk register
risk_rows = [
{
"risk_id": "R1",
"risk": "Regime shift increases error and causes bad decisions.",
"impact": "Loss increase, limit breaches, client harm if automated.",
"evidence": "Worst-fold RMSE elevated; rolling RMSE spikes in stress.",
"control": "Vol regime monitor; disable when vol proxy above threshold.",
"owner": "Model owner",
"residual_risk": "Medium",
},
{
"risk_id": "R2",
"risk": "Missing/stale data creates misleading predictions.",
"impact": "Incorrect signals; hidden overconfidence.",
"evidence": "Pipeline sensitive to missing blocks.",
"control": "Hard-fail data integrity checks; fallback data source.",
"owner": "Data engineering",
"residual_risk": "Low",
},
{
"risk_id": "R3",
"risk": "Accuracy gain does not translate to decision safety.",
"impact": "Tail losses increase despite RMSE improvement.",
"evidence": "Stress RMSE x2 worsens materially.",
"control": "Decision-level backtest metrics + stress scenarios required for approval.",
"owner": "Risk control",
"residual_risk": "Medium",
},
]
risk_df = pd.DataFrame(risk_rows)
risk_df.to_csv(os.path.join(run_dir, "RISK_REGISTER.csv"), index=False)
# 5) Handover note
handover = f"""# Handover
- **Run ID:** {run_id}
- **Artefacts:** MODEL_CARD.md, ASSUMPTIONS.md, MONITORING_SPEC.md, RISK_REGISTER.csv
- **Next actions:** implement monitors + alert routing; define disable/fallback hooks.
- **Support:** model owner owns performance monitoring; data engineering owns data integrity.
"""
with open(os.path.join(run_dir, "HANDOVER.md"), "w", encoding="utf-8") as f:
f.write(handover)
print("Wrote sign-off pack to:", run_dir)
print("Files:", os.listdir(run_dir))7. What to say in sign-off meetings (short scripts)
When someone asks “Is it accurate?”
- “Accuracy is one input. We also show worst-window and stress behaviour.”
- “We approve only if decision-level safety metrics improve or stay within limits.”
When someone asks “What could go wrong?”
- “Here are the top three risks with evidence and controls.”
- “Here is the residual risk after controls.”
When someone pushes “Ship it, we can monitor later”
- “Monitoring is part of the safety case. Without it, usage is uncontrolled.”
- “We can ship in restricted mode with fallback, but not unmonitored.”
8. Summary
- Sign-off requires a safety case: assumptions, risks, controls, monitoring, fallback.
- Escalation is a protocol with triggers and options.
- Accuracy must map to decision safety and tail outcomes.
- A sign-off pack turns modelling into a controlled deployment.