SR 11-7 Validation Artifacts Under SR 26-2

What the guidance text supports

The Federal Reserve issued SR 26-2, "Revised Guidance on Model Risk Management," on April 17, 2026. The OCC issued parallel guidance as Bulletin 2026-13 the same day. The Federal Reserve describes the revised guidance as highlighting sound principles for effective model risk management while recognizing that practices appropriately vary among banking organizations based on risk profile and model usage. The OCC bulletin covers model development and use, validation and monitoring, governance and controls, and vendor and third-party products, and it names validating conceptual soundness and outcomes analyses as features of effective validation and monitoring.

The Federal Reserve's model risk guidance says the nature and rigor of validation generally align with a model's approach, use, and materiality. The SR 11-7 attachment adds that validation should continue on an ongoing basis after a model goes into use, to track known limitations and identify new ones. A footnote in the OCC bulletin cites OCC Bulletin 2025-26, which says OCC guidance does not, and should not be interpreted to, require community banks to perform annual model validation.

This page does not state which artifacts are retained, revised, or removed, and it does not describe how SR 26-2 relates to SR 11-7 for any particular institution. As of November 2026, confirm that relationship with supervisors or counsel. Everything labeled interpretation below is a working judgement that your team should document and own.

Artifact-by-artifact sorting (interpretation)

The table sorts six common SR 11-7 artifacts by how well they fit an AI system whose production behavior depends on runtime policy, tool calls, and human approvals. The sorting is not drawn from SR 26-2 text. Depth should still scale to each model's approach, use, and materiality.

• Conceptual soundness documentation: carry forward: Still describes whether the design and approach are appropriate for the intended use. It does not show what happened in production.
• Developmental evidence: carry forward: Remains the record of how the model was built and tested. Keep it current when the model or its version changes.
• Validation findings and issue tracking: carry forward: The Federal Reserve page describes tracking recommendations, responses, and exceptions, and managing remediation. That applies regardless of model type.
• Model inventory: update: The SR 11-7 text calls for an inventory of models in use. For AI systems, consider recording the model version in use, third-party components, and the tools the system can call.
• Outcomes analysis: update: Guidance says it can identify material errors or persistent deviations outside performance thresholds. For AI systems, outcomes may depend on runtime policy and approvals, so scope the analysis to production conditions.
• Ongoing monitoring reports: evidence gap: Aggregate performance reports may not show what a system was permitted to do in a specific interaction or tool call. This is where operational records are most likely to be needed.

Why pre-deployment artifacts fit AI systems less well

Most SR 11-7 artifacts were designed around statistical models: a fixed specification, a development sample, and validation before use. The behavior of such a model in production is largely determined by what was validated. An AI system that calls tools, applies runtime policy, and routes some actions to a human approver behaves according to more than the model. The same model can act differently under different policy versions, tool permissions, or approval outcomes.

That difference does not make conceptual soundness or developmental evidence obsolete. It means those artifacts answer a narrower question: was the model appropriate and well built? They do not answer: what did the system do on a given day, under which policy, and who approved it? The supplied guidance text does not address runtime policy, tool calls, or human approvals directly, so any expectation that examiners will ask for such records is an inference from the ongoing validation language, not a stated requirement.

The practical consequence is a scoping decision. For lower-materiality uses, existing artifacts may be enough. For consequential uses, validators should decide in advance what operational evidence would let them confirm that production behavior stayed within the validated envelope.

How runtime evidence supplements validation

Runtime enforcement records capture a decision per interaction or tool call: allowed, redacted, blocked, or escalated for human approval. They are operational evidence. They supplement conceptual soundness, developmental evidence, and outcomes analysis, and they do not replace them. No supplied guidance says examiners accept such records as validation evidence, so treat them as supporting material that your validators evaluate on their merits.

The SR 11-7 requirement that validation continue after deployment is the documented hook. Per-interaction records can give ongoing monitoring a factual basis: how often policy blocked or escalated an action, which approvals were granted, and whether behavior drifted from what validation assumed. Scope matters. These records describe individual interactions and tool calls. They do not by themselves establish model lineage, dataset provenance, or a full trace of a multi-step workflow, and a validation file should not imply that they do.

One public commenter on a Federal Reserve proposal argued that exact model versions should be governed artifacts, with version changes triggering testing, documentation, and approval. That is one commenter's view, not a requirement. The idea is still practical: if a runtime record names the model and policy version in force, a validator can connect it to the right validation package.

Where Trussed fits, and a practical sequence

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, applying allow, redact, block, rate limit, or escalate decisions to individual interactions and tool calls. That enforcement produces audit-ready evidence, mapped to frameworks including NIST, and it is enforced at runtime, not reviewed after the fact. Deployment is self-managed in the customer cloud with configurable retention and data residency. Trussed does not provide model lineage, dataset provenance, or end-to-end tracing of agentic workflows. Its production record comes from a regulated enterprise running continuously for more than 18 months, and insurance is where it is deepest.

Whatever tooling you choose, the sequence is the same. List your current artifacts, sort each as carry forward, update, or gap, and record the guidance text relied on for each call. Set thresholds that trigger expanded validation, and document the approvals that follow. Then decide which consequential AI uses need runtime evidence, and test any candidate tool against the criteria above.