Another day, another risk report held together by a quant, a prayer, and a notebook nobody else can run.
If the risk numbers depend on one person’s laptop, congratulations: the laptop is now critical infrastructure. And yes, the morning risk deadline is remarkably indifferent to annual leave.
“Just run the notebook” is not an operating procedure. Neither is “the quant checks the output.” If one person’s package installs determine today’s risk numbers, you have a dependency problem. Literally.
A notebook can calculate risk. That does not mean it can operate a risk process. The distinction is not notebook versus application. Notebooks are fine for exploration, and they can stay useful in a controlled workflow. The problem is pretending a recurring business output doesn’t need an owner, a reproducible calculation, and a way to detect and recover from failure.
Here’s the short list of things that turn a fragile experiment into something that belongs in production:
- Put the code and configuration under version control. A green cell is not a control framework.
- Pin dependencies and record the inputs used for each run. Installing whatever package version is available today is an exciting way to introduce variability.
- Test key calculations and flag missing or stale data. If the recovery plan starts with “find the quant,” keep writing.
- Schedule, monitor, and document the run so someone else can operate it. The morning risk deadline does not pause for heroics.
Version control records what changed, but it doesn’t prove what ran. The run also needs known inputs, dependency versions, configuration, and a record of the output. Automating the button press helps, but only if there’s still a person responsible when it fails.
Call it research all you like. The report still has a deadline.