1. Promise
One-sentence promise
After this lecture, you can write an assumptions page and a model-card style summary that makes intended use, limitations, and monitoring explicit.
End tag line
If it is not documented, it is not controlled.
2. Learning objectives
After reading this lecture, you will be able to:
- Create a one-page assumptions document for a model and pipeline.
- Write a model card that covers intended use, limitations, and monitoring.
- Connect documentation to validation and governance language.
- Produce documentation artefacts automatically as part of a run.
3. Conceptual core
3.1 The assumptions page
An assumptions page is the minimum “truth statement” for your system.
It answers:
- What data is assumed correct and complete?
- What time horizon and decision context does the model assume?
- What transformations and labels are assumed causal?
- What regimes are assumed (volatility, liquidity, market microstructure)?
- What constraints are assumed (latency, interpretability, cost)?
Recommended structure (one page)
- Scope
- What is the model for and what is it not for?
- Data assumptions
- Source, as-of policy, missing data policy, corporate action policy.
- Target and horizon assumptions
- Explicit definition of and horizon .
- Stationarity / regime assumptions
- “Model expects similar distribution to training within these bounds.”
- Operational assumptions
- Latency budget, refresh cadence, fallback behaviour.
- Risk and control assumptions
- What controls exist and what they catch.
Validator sentence
Assumptions are inputs. They must be stated and monitored.
3.2 Model card style summary
A model card is a short standardised summary that enables:
- fast review,
- safe use,
- safe handover.
Model card sections
- Model name and version
- version, run ID, date.
- Intended use
- what decision it supports, where it is deployed.
- Not intended use
- explicit misuse warnings.
- Data
- dataset ID, key features, coverage.
- Method
- model class, baseline comparison, evaluation protocol.
- Performance
- key metrics, stability, worst-window.
- Limitations
- known failure regimes, known blind spots.
- Monitoring
- what is monitored and thresholds:
- data drift,
- prediction drift,
- realised error,
- regime indicators,
- latency and failure rates.
- Human oversight
- who reviews, when, and what triggers intervention.
Validator sentence
A model card is a safety label. It reduces misuse.
4. Practical templates (copy-paste)
4.1 Assumptions page template
Model scope - Purpose: - Decision: - Horizon: - Users:
Data assumptions - Sources: - As-of policy: - Missing data policy: - Timestamp policy: - Corporate actions / restatements:
Feature / target assumptions - Transformations: - Leakage prevention: - Label definition:
Regime assumptions - Volatility: - Liquidity: - Market microstructure (if relevant):
Operational assumptions - Latency budget: - Refresh cadence: - Fallback rules:
Controls - Invariants: - Alerts: - Manual checks:
4.2 Model card template
Model name / version - Run ID: - Date: - Owner:
Intended use - Decision supported: - Deployment context:
Not intended use - Explicit exclusions:
Data - Dataset ID: - Coverage: - Key features:
Method - Model class: - Baselines: - Validation protocol:
Performance - Primary metric: - Stability: - Worst-window:
Limitations - Failure regimes: - Known blind spots:
Monitoring - Data drift: - Performance drift: - Latency/availability:
Human oversight - Review cadence: - Intervention triggers:
5. Control lens
In control, you ship: - operating envelope, - assumptions about sensors and noise, - failure modes and fallback modes.
A model card is the operating envelope for a quantitative model.
6. Python lab (auto-generate assumptions + model card from config + run artefacts)
This lab shows how documentation becomes part of the run artefact folder. It generates:
ASSUMPTIONS.mdMODEL_CARD.md
from a config and a small metrics dictionary.
import os
from datetime import datetime
# -----------------------------
# Inputs (normally from run artefacts)
# -----------------------------
cfg = {
"run_id": "2026-02-09_170000_ab12cd34",
"model_name": "OLS baseline",
"owner": "Quant team",
"target": {"name": "y", "horizon": 1, "unit": "arbitrary"},
"data": {"dataset_id": "sha256:...abc123", "coverage": "synthetic demo"},
"features": {"cols": ["lag1", "lag2", "lag3", "lag5"]},
"validation": {"scheme": "rolling", "train_len": 240, "test_len": 60},
"constraints": {"latency_ms": 200, "interpretability": "high"},
}
metrics = {
"rmse_mean": 1.23,
"rmse_worst_fold": 1.95,
"mae_mean": 0.97,
}
run_dir = os.path.join("runs", cfg["run_id"])
os.makedirs(run_dir, exist_ok=True)
# -----------------------------
# Assumptions page (markdown)
# -----------------------------
assumptions_md = f"""# Assumptions — {cfg["model_name"]}
## Scope
- **Purpose:** Forecast {cfg["target"]["name"]} at horizon h={cfg["target"]["horizon"]}.
- **Decision:** Inform downstream decision logic (definition external to this document).
- **Not for:** Use outside the validated horizon or outside the documented data coverage.
## Data assumptions
- **Dataset ID:** {cfg["data"]["dataset_id"]}
- **Coverage:** {cfg["data"]["coverage"]}
- **Timestamp policy:** Index must be monotonic and unique.
- **Missing data policy:** Missing timestamps are not treated as zeros. Gaps are handled explicitly.
## Feature and target assumptions
- **Features:** {cfg["features"]["cols"]}
- **Causality:** Features at time t use only information available at or before t.
- **Target:** y_target = y shifted by -h (future), never used as a feature.
## Regime assumptions
- Performance may degrade under distribution shifts (volatility, liquidity, behaviour changes).
- Use rolling validation and monitor drift signals.
## Operational assumptions
- **Latency budget:** <= {cfg["constraints"]["latency_ms"]} ms per scoring call (target).
- **Refresh cadence:** Assumed consistent with horizon h.
## Controls
- Invariants: monotonic timestamps, no duplicates, train end < test start.
- Smoke test: pipeline runs on a small sample before full runs.
"""
with open(os.path.join(run_dir, "ASSUMPTIONS.md"), "w", encoding="utf-8") as f:
f.write(assumptions_md)
# -----------------------------
# Model card (markdown)
# -----------------------------
model_card_md = f"""# Model card — {cfg["model_name"]}
## Model name / version
- **Run ID:** {cfg["run_id"]}
- **Date:** {datetime.now().strftime("%Y-%m-%d")}
- **Owner:** {cfg["owner"]}
## Intended use
- Forecast **{cfg["target"]["name"]}** at horizon **h={cfg["target"]["horizon"]}**.
- Used for time-consistent forecasting experiments and baseline comparisons.
## Not intended use
- Not intended for horizons other than h={cfg["target"]["horizon"]}.
- Not intended for use without monitoring or outside the dataset coverage.
## Data
- **Dataset ID:** {cfg["data"]["dataset_id"]}
- **Coverage:** {cfg["data"]["coverage"]}
- **Key features:** {cfg["features"]["cols"]}
## Method
- **Model class:** {cfg["model_name"]}
- **Baselines:** last-value, seasonal naive (recommended comparisons)
- **Validation:** {cfg["validation"]["scheme"]} CV (train_len={cfg["validation"]["train_len"]}, test_len={cfg["validation"]["test_len"]})
## Performance (summary)
- **RMSE mean:** {metrics["rmse_mean"]}
- **RMSE worst fold:** {metrics["rmse_worst_fold"]}
- **MAE mean:** {metrics["mae_mean"]}
## Limitations
- Sensitive to regime shifts and drift in feature distributions.
- May underperform in extreme volatility regimes.
## Monitoring
- Data integrity: missing timestamps, duplicates, monotonicity.
- Drift: rolling feature distribution drift (mean/std), error drift by fold/window.
- Runtime: latency, failure rate, artefact completeness.
## Human oversight
- Review cadence: weekly during development, monthly in production.
- Intervention triggers: drift alarms, repeated worst-window failures, latency breach.
"""
with open(os.path.join(run_dir, "MODEL_CARD.md"), "w", encoding="utf-8") as f:
f.write(model_card_md)
print("Wrote documentation to:", run_dir)
print(" - ASSUMPTIONS.md")
print(" - MODEL_CARD.md")7. Summary
- An assumptions page defines the operating envelope and data contract.
- A model card standardises safe use: intended use, limitations, monitoring.
- Documentation should be generated as artefacts, not written once and forgotten.
- In quant engineering, documentation is part of the control system.