SR 11-7 and the Verified-Model Stack: A Mapping for Model-Risk Teams

SR 11-7 asks whether a model is understood, validated, documented, and controlled. Worthune's artifacts were built to make those questions answerable — not to answer them on a supervised firm's behalf.

Supervisory Guidance on Model Risk Management — SR 11-7, issued by the Federal Reserve and OCC in 2011 — is the document a supervised firm's model-risk function reasons from when a calculator shows a customer a number. It defines a model broadly (a quantitative method applying theories and assumptions to produce estimates), and it asks for a familiar set of disciplines: a model inventory, development documentation, independent validation, ongoing monitoring, and change control. This piece maps that vocabulary onto the artifacts Worthune publishes, one term at a time. The mapping's purpose is candid: it makes a model-risk team's work faster, and it does not make any of it optional.

The mapping, term by term

Two rows deserve expansion. The validation row is deliberately labeled an analog: SR 11-7's effective challenge means validation by parties independent of the model's development, with the authority and incentives to find problems. Worthune's second implementation is exactly that in engineering form — written from the published spec, not from the engine — and its release-gated agreement is standing evidence of implementation soundness. But a firm's validation obligation covers more than implementation: conceptual soundness for the firm's use, outcomes analysis against the firm's population, and the judgment that the model fits the purpose the firm deploys it for. The artifacts feed that work; they are inputs to effective challenge, not a substitute for it.

The change-control row is the quiet differentiator. SR 11-7-era change control usually means internal tickets and approval workflows a vendor summarizes on request. Here the change record is public and self-verifying: behavior changes only with a spec-version bump, the changelog entry states what moved and why, and a caller's own CI fixture detects any version drift mechanically. A model-risk team can reconstruct the full behavioral history of a dependency without asking the vendor for anything — which is a sentence worth testing against any vendor questionnaire you have ever sent.

The vendor-model expectations, operationalized

For third-party models, the guidance expects firms to understand what the vendor did and to fill the gaps with their own compensating processes. In practice that becomes a due-diligence file. The artifacts slot into it directly: the spec is the development documentation; the eval dataset plus the harness description is the validation evidence — and uniquely, it is re-runnable by the firm itself, so validation evidence can be regenerated rather than trusted; the changelog is the change log; the facts registry with its verifiedOn dates is the data-lineage record for every regulatory constant. The reproduction guide (/writing/reproducing-a-spec-evals) walks the strongest version of this: a firm that reimplements even one model from spec and matches the vectors has produced first-party validation evidence about its vendor.

• ✓Inventory: record each model used, with its spec version, from the catalog endpoints.
• ✓Documentation: file the spec per model — it is the development document.
• ✓Validation: file the eval dataset and, for material models, re-run it against the live API on your own schedule.
• ✓Monitoring: put the changelog and the registry's verification dates on a review cadence.
• ✓Change control: pin versions in CI so no change reaches production unreviewed.
• ✓Effective challenge: keep it in-house — the artifacts inform it, your team performs it.

Why an engineering platform speaks MRM at all

The candid answer is that customer-facing math at a supervised firm lives under this guidance whether or not anyone involved read it, and the classic calculator failure modes are exactly the gaps SR 11-7 names: undocumented assumptions, unvalidated implementations, silent changes. Building the artifacts the guidance asks about — publicly, mechanically, per model — is what a computation vendor can contribute to model risk management. The rest of the discipline belongs to the firm, and the best evidence this piece can offer is that every artifact it names can be checked without believing a word of it. This is a mapping between an engineering practice and a supervisory vocabulary, written by engineers; it is not legal or regulatory advice, and a firm's compliance function owns the application.