ModelOps

WHAT IT IS ModelOps is the governance discipline for an organisation's portfolio of models: knowing which models exist, what decisions they influence, who approved them, on what evidence, when they were last validated, and when they must be retired. Its scope deliberately includes models that are not machine learning — pricing rules, credit scorecards, actuarial and spreadsheet models all carry the same exposure. **Not this:** ModelOps is not MLOps: it owns the inventory, validation and approval of every model the organisation relies on, including models that involve no machine learning at all. WHY IT EXISTS Model risk is portfolio risk, and no individual team can see it. An organisation typically discovers the shape of its model estate during an audit or after a loss, at which point it learns that a consequential decision has been made for years by a spreadsheet with no owner. Regulated industries formalised this first — supervisory guidance on model risk management is the origin of the discipline — but the exposure is not limited to regulated firms. ModelOps exists because "who approved this and on what evidence" must have an answer before the question is asked adversarially. WHEN TO USE IT Adopt it when models influence decisions with financial, safety, legal or customer-fairness consequences; when a regulator or auditor has asked for a model inventory; or when more than a handful of models exist across more than one team. A research group experimenting with no production exposure does not need it yet. WHO OWNS IT A risk, governance or model-risk function owns the framework, the inventory and the approval gate — and must be independent of the teams that build the models, because self-validation is the failure this discipline exists to prevent. Each model has a named business owner accountable for its use and a named developer accountable for its construction. This mirrors the three-lines structure in /grcops and typically reports through the same committee. WHAT GOOD LOOKS LIKE A single inventory lists every model in use, tiered by consequence, with an owner, a purpose, a validation date and an expiry. High-tier models are validated by someone who did not build them, against written criteria, before approval and periodically after. Approval is recorded with the evidence it rested on. Models in production are monitored against the performance assumptions their approval relied on, and breaching them triggers review rather than a note. Retirement is an actual process, so decommissioned models stop influencing decisions. HOW TO IMPLEMENT Build the inventory first, and accept that the first pass will be incomplete — finding the unregistered spreadsheet is a result, not a failure. Tier the inventory by consequence so effort is proportionate; validating everything to the same standard is how a framework collapses under its own weight. Write the validation standard for the top tier and apply it to one model end to end before scaling. Add the approval record and the expiry date. Connect monitoring to the assumptions in the approval, which is the step most programmes skip and the one that makes the framework live rather than documentary. The evidence discipline in /complianceops applies directly. HOW TO ASSESS YOURSELF Ask for the model inventory and count how many models you find that are not on it. Pick a consequential model and ask who validated it, when, and against what criteria. Ask what would happen if its performance degraded — who is told, and what are they empowered to do. Take the scored self-assessment at /assess and sequence the gaps with /roadmaps.