Model versioning and rollback

Plain language meaning

Model versioning and rollback explain how banks track approved model versions, training data, feature definitions, thresholds, serving endpoints, monitoring results and emergency recovery paths so production AI can be controlled when performance, fairness, resilience or compliance fails.

This topic is about production governance of model change in banking. It is not about saving model files with informal names or relying on developers to remember which model is live.

In a real bank, this topic cannot be handled as a loose data-science or technology idea. It affects customer outcomes, fraud and AML control, operational queues, service continuity, privacy, security, model governance, audit replay, management reporting and regulatory confidence. AI should improve speed and quality, but the bank must still prove source data, permitted use, approved logic, human accountability, fallback handling and retained evidence.

Where it sits in the banking AI journey

This card belongs to AI Data and Model Operations. The working flow is Approved version, Controlled deployment, Production monitoring, Issue detected, and Rollback and evidence.

Read the flow as a bank operating model. Each stage needs a source system, a data owner, a timing rule, a quality gate, a model or rule boundary, an exception path, a customer-impact view, a fallback option, a monitoring requirement and a retained record. That is what separates useful AI adoption from uncontrolled automation.

Banking data and evidence

The important data points are model version, feature version, threshold version, deployment ID, traffic split, performance metric, incident ID, and rollback timestamp. These items matter because they can influence risk scoring, operational repair, fraud action, AML triage, customer treatment, reporting, model monitoring and management decisions.

The evidence pack should include inventory entry, release note, deployment log, monitoring dashboard, incident ticket, rollback record, and post-implementation review. A strong bank can replay the journey from source data to transformed input, AI output, rule result, human action, system outcome and monitoring result. A weak bank only knows that a process ran and hopes the process was right.

Controls that make AI adoption safe

The core controls are model inventory, release approval, version pinning, champion challenger control, kill switch, rollback playbook, and post-release review. These controls keep the topic anchored to banking purpose, approved policy, data governance, model-risk expectations, operational resilience, customer fairness, privacy, security and auditability.

The practical design should define what AI may recommend, what it must never decide alone, which deterministic rule remains authoritative, who owns thresholds and overrides, how degraded service is handled, how customer harm is detected and what evidence is retained. Without that control design, faster AI can simply make weak processes fail faster.

Architecture and data-operation lens

Banking AI depends on the architecture around it. Storage, streams, feature definitions, training sets, model versions, thresholds, feedback labels and rollback paths must be governed before the bank relies on AI output. The model is only one part of the control chain.

A bank-grade design connects channels, source systems, core records, payment hubs where relevant, fraud systems, AML platforms, case tools, data platforms, feature stores, model-serving endpoints, policy engines, audit logs and management dashboards. It also records degraded operation, recovery actions and lessons learned.

Regulatory and governance lens

Federal Reserve SR 26-2, dated 17 April 2026, gives revised model-risk guidance for traditional models and non-generative AI models used by banking organisations, including development, validation, monitoring, change control and governance.

The Federal Reserve's 2026 model-risk guidance states that generative and agentic AI are outside that guidance, while broader bank risk-management and governance practices still need to control tools and processes not covered by the guidance.

NIST AI RMF 1.0 uses Govern, Map, Measure and Manage functions for AI risk management, and NIST AI 600-1 adds generative-AI risk actions for source grounding, content provenance, data protection, cybersecurity and human oversight.

FFIEC Architecture, Infrastructure and Operations guidance expects financial-institution technology environments to be governed, resilient, secure, monitored, documented and aligned to business risk, including emerging technologies such as artificial intelligence and machine learning.

BCBS 239 remains current for effective risk data aggregation and risk reporting, and the Basel Committee's January 2026 newsletter reiterates the importance of accurate, comprehensive and timely data capabilities in banks.

FFIEC BSA/AML examination guidance expects suspicious activity monitoring systems and supporting technology to be risk-based, explainable by management, independently tested where appropriate and aligned to the bank's risk profile.

FinCEN's 12 June 2026 Section 314(b) materials clarify information sharing for possible terrorist activity, money laundering and fraud-related specified unlawful activity within the statutory safe-harbor framework for participating financial institutions.

OFAC's Framework for Compliance Commitments describes sanctions compliance programme components including management commitment, risk assessment, internal controls, testing and auditing, and training.

Diagram walkthrough

Read the diagram from left to right as Approved version, Controlled deployment, Production monitoring, Issue detected, and Rollback and evidence. It is a banking control map. The point is to show how data, AI or ML output, rules, human action, operational routing and audit evidence should connect.

Use it as a 30-minute study method. For each box, ask which system creates the data, which definition is used, which model or rule acts, what can go wrong, who can override it, how a fallback works, which customer or regulatory impact exists and what record proves the final state.

Most important mistake to avoid

The common failure is treating rollback as a technical redeploy. In a bank, rollback must also restore approved thresholds, feature versions, decision traces, customer treatment, monitoring evidence and management communication.

The correction is disciplined scope. Keep the chapter anchored to banking purpose, prove the data path, make ownership visible, test failure behaviour, record the evidence and make the final outcome explainable without relying on memory, assumptions or developer-only knowledge.

A reversible release with preserved decisions

A bank promotes a new fraud model after validation. The release package should identify model artifact, feature transformation, policy thresholds, configuration, approval, test evidence and effective time. Merely tagging the model binary is insufficient: a changed feature lookup can alter predictions while the binary remains identical. Route a controlled share of traffic or run a shadow comparison only under the approved change plan, with clear separation between observed challenger scores and actual customer actions.

A rollback trigger might be severe input missingness, service failure, unexpected score distribution or customer-impact evidence. The bank must know whether the old model can still consume current features and whether its dependencies remain deployed. A rollback of the score service does not necessarily undo policy or reference-data changes. The operations playbook names who can activate rollback, how affected decisions are counted and whether cases require follow-up.

Test deployment and rollback on a dated request set, including a late response and retry. Preserve which version made each original decision; do not overwrite logs with the restored version's counterfactual score. Reconcile requests, scores, policy actions and customer outcomes across the transition. A retrospective evaluation may compare versions, but it must not claim the new model actually decided cases assigned to the old one. The NIST AI RMF is a voluntary framework for lifecycle risk management; the bank's release controls and applicable supervision determine approval and evidence requirements.

A model release is a combination of versions

Rolling back banking AI is not merely replacing one model file. A live decision depends on source schema, customer mapping, feature definitions, model artifact, calibration, threshold policy, serving configuration and sometimes a retrieval corpus or prompt. If an old model expects an old feature meaning, deploying its binary against new inputs can make decisions worse. Version the combination approved for use and record what each actual decision consumed.

An artifact registry should identify training dataset snapshot, code, parameters, validation evidence, owner and approval status. A feature registry should identify source lineage, transformations, units, freshness and missingness behavior. The policy repository should version threshold, rule precedence and fallback. A deployment record should identify traffic routing and service configuration. A business decision journal ties all of them to final actions. Without that link, an incident team cannot reliably identify which customers were affected by a release.

Rollback is one response to a material problem. Sometimes the defect is a source feed and reverting the model will not help. Sometimes a threshold change caused a queue surge while scores remain sound. Sometimes a retrieval index contains obsolete policy and rebuilding the index is the right fix. Diagnose the failing component and use the approved limited mode while deciding the durable repair.

Define version boundaries

A semantic model version changes when trained weights, calibration or intended use changes. A feature version changes when eligible source events, aggregation, reference mapping or null behavior changes. A policy version changes when score-to-action mapping or rule precedence changes. A serving version can change serialization, latency or routing without changing the model. Record these separately. A single deployment timestamp cannot explain their relationships.

Minor code refactoring can still affect outputs. Verify a representative vector set before declaring a change behavior preserving. Conversely, a source team can change business meaning without a code deploy. Compare category distributions and sampled decisions around source migrations. Versioned contracts should include effective dates and owners, not just hashes.

For an assistant, record base model, prompt template, tool configuration, retrieval index, corpus document versions and output review policy. Reverting the base model while retaining a contaminated index will not correct unsupported answers. Reverting the index may restore old documents that are no longer current. The rollback unit must be the tested combination of components.

Release candidate evidence

Before promotion, build a release manifest listing artifact IDs, feature versions, source compatibility, policy version, validation report, expected population, fallback and rollback plan. Test ordinary and exceptional paths: valid inputs, missing or stale features, malformed responses, model timeout, deterministic hold, human override and final system state. Preserve sample request and action records.

Compare candidate with current production under representative traffic. Shadow scoring can reveal score and latency differences without affecting actions, but should also compute hypothetical policy outcomes and workload. Inspect divergences by product, channel, value and relevant segment. The shadow path must not open real cases or execute payments. Its data access and retention still require governance.

Staged rollout limits exposure. Route a defined subset to the candidate and keep a stable comparison group where appropriate. Monitor feature validity, score distribution, fallback, action changes, queue capacity and customer effects. Later outcomes may be immature, so use leading indicators and a scheduled follow-up. Set stop and rollback triggers before launch to avoid improvising after an incident.

Compatibility matrix

Document which model versions can consume which feature versions and which policies can interpret their scores. A model trained on amount in major units cannot safely consume minor units. A new encoder can change embedding vectors even if dimension stays constant. A recalibrated model can shift score scale, making an old threshold inappropriate. Test incompatible combinations fail closed or route to an approved fallback.

Online and offline feature definitions must match under point-in-time semantics. A rollback to an old model may require an old feature service or a validated adapter. Retaining an old container image is insufficient if its data source has moved. A dual-running transition may keep both feature versions available for a limited period; measure storage and operational cost. Define when the old path can be retired.

For batch models, a prior approved score file may be usable within a defined age window, but not indefinitely. A new product or account can lack a prior score. A corrected source snapshot may make the old file inappropriate. The policy owner should state which population can continue under the last good run and when manual review or pause is required.

Rollback trigger and authority

Triggers can include material increase in false holds, unexpected credit referral disparity, high invalid-input rate, source staleness, severe latency, case backlog or evidence gaps. Thresholds should be defined with business and risk owners, with a monitoring window and escalation. A small statistical fluctuation may not justify a disruptive rollback; a single critical control failure may. Name who can restrict traffic, activate fallback and approve restoration.

An emergency change record should state incident, affected use, active versions, decision, scope, timestamp, owner and expected duration. Operators need a runbook that works under partial outage. If the model endpoint is healthy but input data is wrong, routing to an earlier artifact may still produce wrong decisions. A rule-only or manual fallback can be safer while the source is repaired.

Rollback itself can create risk. Switching versions during a payment burst can cause retry storms or inconsistent actions. A case opened by one policy version should not be silently closed by another. A late response from the candidate should not overwrite a fallback action. Use stable business IDs and idempotent orchestration; verify final states in authoritative systems.

Preserve historical decisions

Every scored decision should link to actual artifact, feature validity, policy version, response, final action and later outcome. Traffic splitting can route requests between models; record route at request level. A deployment log saying "10 percent candidate" does not identify a specific payment. A batch file should carry its run ID and publication version into downstream actions.

If a model is rolled back, do not rewrite candidate decisions as though the old version made them. Keep both original and corrected analyses under access controls. Reverse lineage can enumerate decisions that used the faulty artifact or feature version. Business owners can then review actual holds, approvals, declines or communications. A changed score is not automatically a changed customer outcome.

Retain artifacts and compatible readers for the required review period. A historic score may be difficult to reproduce exactly under a nondeterministic service or retired vendor, so preserve actual response and sufficient input evidence. Reproducibility limits should be documented. A model inventory without decision-level linkage is too coarse for precise remediation.

Payment fraud incident

A new model version produces more high scores for first-time beneficiaries. Referrals rise, but the increase may be legitimate if a fraud campaign is underway. Investigate source freshness, feature mappings, candidate calibration, threshold compatibility and actual case outcomes. Compare candidate and prior model on the same input vectors where appropriate. Review queue capacity and customer delays.

Suppose the cause is a feature schema mismatch: the new model expects beneficiary age in days, but serving supplies hours. Rolling back to the old model can help only if the old model's feature contract remains available and correct. Activate the approved limited mode for affected traffic during the switch. Identify every payment scored with the mismatched version and review final actions. Repair the schema contract and add an incompatibility test before redeployment.

Suppose instead the threshold was copied unchanged after recalibration. The feature and model outputs are valid, but the action policy is wrong for the new scale. The response may be to restore the prior policy-model pair, then evaluate a suitable new threshold. Keep model and policy changes distinct in the incident record. Otherwise a later report may blame the model for a policy error.

Credit incident

A monthly credit model refresh uses a product mapping that omits accounts migrated from another system. The batch job completes with fewer scored facilities. A quality gate should block publication based on population reconciliation. If the file was published, identify downstream decisions using it, preserve the original run and compute a corrected rerun with a new ID. An old approved file may cover some accounts within its age limit, while migrated accounts need review.

Reverting the model weights cannot restore missing accounts. The repair is to fix the mapping, validate the affected population and review customer decisions. Model governance still records whether validation assumptions were breached. The final outcome analysis distinguishes applicants exposed to wrong data from those whose final decision changed.

Assistant incident

A retrieval assistant begins citing a superseded policy after an index update. The base model and prompt are unchanged. Freeze or disable affected answers, restore an approved corpus version or rebuild with correct effective-date filters, and identify drafts that used the wrong passages. Review whether any final communication was sent. Rolling back the model weights would not repair the retrieval defect.

Test an old policy, a future-effective policy and an unanswerable question before restoring use. Record corpus, index, prompt and model versions for each answer. Human reviewers should know when a draft came from a suspect index. A corrected answer does not erase a prior unsupported communication.

Roll forward versus roll back

A rollback returns to a previously approved compatible combination. A roll-forward applies a validated repair to the current path. A fallback keeps the business process operating in a limited mode. Choose based on evidence, speed and risk. A known defective old model should not be restored just because it is technically available; a rushed forward patch should not bypass testing of affected decisions.

Have a decision matrix in the incident runbook. Is the defect in data, feature, model, policy, service or evidence? Is an old compatible combination available? What is the scope and customer consequence? How long can the fallback operate? Who approves the route and verifies recovery? These questions prevent a container rollback from becoming the default response to every AI incident.

Monitoring after change

After rollback or repair, check input validity, scores, policy actions, downstream case and payment states, and affected-customer remediation. The model API turning green does not close the incident. Queued requests may be processed under mixed versions; caches may retain stale features; delayed responses may arrive. Reconcile request IDs and terminal business states.

Compare live metrics with a predeclared baseline and allow for changed traffic. Schedule mature-outcome analysis after enough time has passed. Keep heightened monitoring for a defined period and assign owners to open exceptions. Archive incident evidence, tests and approvals with the model inventory.

Release and recovery drill

Deploy a candidate to shadow traffic. Inject an incompatible feature schema, a model timeout and a policy threshold mismatch in a safe test environment. Verify detection, stop criteria, approved fallback, version-specific decision logs and restoration to a compatible combination. Then query all simulated decisions that used the candidate and reconcile them to final actions.

Repeat with a partial rollout where some requests use the new model and some use the old one. A reviewer should identify the exact version path for a sampled payment and credit application, including a late response and human override. If the team relies on approximate deployment times, improve request-level capture. The bank is ready to roll back only when it can change the path safely and account for every decision made before, during and after the change.

Artifact integrity and promotion

The registry should prevent an unapproved artifact from being substituted under an approved version label. Store a content digest, build provenance and approval record. Promotion from development to test to production should identify the exact artifact, rather than rebuilding the model with potentially different data or dependencies at each stage. If a service downloads artifacts at runtime, verify identity and fail under an approved mode when the artifact cannot be trusted.

Record environment and configuration. Preprocessing libraries, tokenizers, calibration tables and inference settings can alter outputs even with unchanged weights. A generative service may change behavior with temperature, tool permissions or context limits. For a banking decision, those parameters belong in the release manifest and, where material, the decision trace. Test a fixed set of requests across environments and investigate differences.

Access to promote or roll back should be restricted and logged. A model developer may prepare a candidate but should not automatically deploy it to consequential production decisions. Separation of duties and independent review should match the use case and bank policy. Emergency access should expire and be reviewed afterward. A model registry is useful only if the operational route actually enforces its approvals.

Routing and mixed-version periods

A staged rollout may use customer ID, channel, product or random assignment to route traffic. Record the rule and actual route. A customer with repeated applications could see inconsistent versions if assignment changes per request; that may complicate fairness and evaluation. A payment retry should not switch policy in mid-instruction. Use stable routing at the appropriate business unit and test duplicate requests.

When traffic is split, dashboards must distinguish versions. An aggregate score distribution can appear stable while one candidate shifts sharply. Compare eligible populations, feature validity, latency, fallbacks, action rates and mature outcomes by route. A candidate group with different customer mix cannot be compared as if it were identical to the baseline. State the assignment method and exclusions.

Partial rollback requires identifying in-flight requests. A request sent to the candidate before the switch may return afterward. The orchestrator should apply the policy and deadline tied to the original decision context, or follow a documented supersession rule. It should not opportunistically use whichever score arrives last. Preserve attempts and the final action. Test this path under network delay.

Stateful feature compatibility

Some features depend on streaming state. A new version might count distinct beneficiaries while an old version counted account aliases. Rolling back model code without rebuilding or retaining the old state changes feature semantics. Run parallel state only when capacity and privacy controls support it, and define a sunset. If old state has been retired, the appropriate response may be a limited fallback rather than an unsafe model rollback.

An online feature store may have cached values produced by both versions during migration. Include semantic version and computation time in each response. Reject an incompatible vector before inference. A model service that accepts the right field names but wrong units can make plausible scores that are hard to detect. Use contract tests with hand-calculated business examples and live sampled parity checks.

For batch scoring, save the input manifest and published output version. A rerun after a source correction is not a replacement of the earlier record. Downstream consumers should know whether they use the approved old output, a blocked candidate or a corrected publication. A rolling rollback of a file pointer should be atomic and accompanied by population reconciliation.

Threshold and calibration compatibility

A model's scores may be recalibrated even if ranking hardly changes. If the old fraud threshold is reused, many more or fewer payments may be held. Test action bands and capacity under candidate scores. Store calibration and policy versions separately. A rollback of only calibration can require revalidation of probability interpretation and thresholds.

For credit, a probability estimate used in pricing or referral may have a different scale after retraining. A simple score correlation plot does not establish that the same decision policy works. Evaluate calibration, boundaries, final approvals and segment effects. Check deterministic affordability and eligibility rules independently. A model rollback should not undo a mandatory policy update that became effective in the meantime.

For an AML rank, relative ordering may matter more than absolute score. A policy that selects the top 500 cases each day behaves differently from a fixed threshold. Changes in alert volume, case mix and investigation capacity can affect its outcome. Version the selection rule and test backlog under candidate and rollback states.

Data source rollback limitations

A source migration can be hard to reverse. Once a customer-master system merges identities, an old feature transformation may not reconstruct prior separate keys. Retain compatible mappings and snapshot evidence during transition. A model might need to operate in a limited mode until mapping quality is restored. Do not assume a container rollback can reverse a changed data universe.

If the source sends wrong values for an hour, a model rollback does not repair decisions already made. Identify those decisions by source and feature version, reconstruct actual inputs and review final outcomes. A corrected replay can help prioritize remediation but does not change the historical decision record. Business owners handle customers, cases and reports affected.

For a retrieval corpus, a withdrawn document may need immediate removal from live search. Reverting to an earlier index could reintroduce it. The safe action may be to disable the topic, rebuild and test a new index, then resume. Store the corpus approval and effective-date filter with the assistant release.

Evidence during emergency response

The incident commander should know the current model-policy-feature combination and its owners. A dashboard should expose active routes, invalid inputs, fallbacks and business actions. The emergency record states when the limited mode began, which population it covered and what evidence justified ending it. Use an affected-decision query keyed by version, source and time window.

Preserve logs before making changes, subject to privacy controls. A rushed deployment can erase in-memory state or rotate an index that is needed to explain earlier output. Retain actual model responses and final actions even when deterministic reproduction is difficult. Avoid broad raw-data exports; an authorized evidence pack can use protected references and controlled samples.

Communication to operations should be precise. A reviewer needs to know whether a score is absent, from the prior model, from a candidate or invalid due to stale data. A customer-facing status should reflect the actual payment or application action without exposing confidential detection details. An incident banner that says "model restored" is insufficient if case backlog and customer corrections remain.

Rollback quality gates

Before activating an old version, verify artifact integrity, feature compatibility, source mappings, policy thresholds, service health and necessary capacity. Run synthetic requests representing ordinary and edge cases. Confirm the route actually reaches the old version and the decision journal records it. Switch traffic gradually if the incident permits; if immediate change is required, monitor intensely and reconcile requests.

After activation, verify no customer instruction executed twice, no case vanished and no pending request received conflicting actions. Compare counts of eligible, scored, fallback and terminal records. A 100 percent successful deployment command does not prove business reconciliation. Keep an explicit owner for unresolved in-flight cases.

End the limited mode only after source freshness, feature validity, model behavior, policy actions and downstream systems have been checked. Schedule later mature-outcome analysis. A rollback can reduce immediate risk without proving that all affected customers were made whole.

Retirement and reproducibility

Retiring a model involves more than removing live traffic. Preserve the artifact, validation evidence, relevant dependencies and decision linkage for the required period under access controls. Retire unused credentials, feature jobs and vendor data flows. A stale secondary endpoint can continue receiving sensitive inputs after the main route changes if it is not inventoried.

Test historic replay before deleting old components. An auditor may need to interpret a score from a retired model and an old policy code. Exact numerical reproduction might not always be feasible, but the actual response and sources used should remain intelligible. Document any limitations. A current dashboard that reinterprets historic status codes under new semantics is not faithful evidence.

Versioned documentation should show intended uses and prohibited uses. A model approved for card fraud should not quietly be reused for account-to-account payments. A prompt or retrieval configuration approved for internal drafting should not automatically power customer-facing answers. Scope expansion is a new release decision requiring evidence.

Review checklist

Can the bank list every decision using a specific model, feature and policy combination? Can it safely restore an older approved combination under current source semantics? Does a late candidate response leave a completed business action unchanged? Can a batch publication be withdrawn without losing its historical evidence? Does an assistant rollback avoid reviving obsolete documents? Are access and retention maintained during emergency operations?

Answer with drills and sampled records, not assurances. If the rollback cannot be tested against the full decision path, the bank should define a limited operating mode that can be controlled while it repairs the fault. Reliable versioning makes that choice informed, reversible and auditable.

Worked version inventory

Imagine a payment decision that used source schema S4, customer mapping C9, velocity feature V6, fraud model M12, calibration K3 and policy P8. Its decision journal should contain those identifiers, a feature timestamp, model response and final payment action. If V6 is found defective, a reverse query enumerates every request that actually consumed V6 during the defect window. It should distinguish payments that used a fallback and never invoked M12. A deployment dashboard saying that V6 was active does not prove each individual request used it.

Now consider restoring M11. Its compatibility record says it expects V5 and calibration K2, while policy P8 was validated only with M12. The bank cannot safely switch M11 into the current path without checking feature availability and selecting an approved compatible policy. If V5 state has been retired, the immediate safe route may be a bounded rule and human review mode. The rollback decision is a business risk choice informed by a version matrix, not a one-click code operation.

After the feature repair, the team compares original and corrected scores for affected payments, then reviews actual holds and releases. Some score changes may leave the policy outcome unchanged. Some holds may have caused customer delay; some releases may require fraud investigation. The bank records each category and retains the original decision trace. A final corrected counter does not rewrite what the model saw.

Change window exercise

Plan a release window with a representative burst of requests. Before activation, record expected route, feature and policy versions. During rollout, sample an ordinary payment, a duplicate retry, a missing feature, a model timeout and a mandatory screening hold. Trigger rollback while several requests are in flight. Verify one business action per instruction, correct version attribution and a complete case queue. Reconcile all requests after the switch.

The exercise should also test staff handoff. An operations analyst should know which version is active and which customer actions require review. A model owner should locate validation and compatibility evidence. A business owner should approve the limited mode and restoration. If any role depends on an engineer's memory of a deployment, update the runbook and evidence system before the next release.

Batch and real-time rollback differences

Real-time rollback changes routing for future requests while old in-flight requests still need an action. The team should account for both populations and reconcile their business IDs. A batch rollback can withdraw a proposed publication and leave the last approved file visible, but downstream users may already have acted on the bad file. Identify those actions; changing a file pointer does not retract a credit decision or management report.

For a batch credit score, preserve the defective run manifest and the corrected rerun as separate evidence. Compare input population, feature values, scores and final actions. A prior file may have become too old for some new accounts, so its approved age and scope matter. For a streaming fraud model, old state may be incompatible with a reverted transformation. A bounded fallback may be the only controlled route during state rebuild.

For an assistant, restoration includes access and corpus approval. A previous index can contain a document withdrawn since its creation. Test effective dates, user permissions and unsupported-answer behavior before routing users back. A rollback should restore a valid decision context, not merely an earlier technical artifact.

These distinctions belong in release planning. The rollback test should identify what can be restored quickly, which evidence remains accessible, which decisions require human review and when normal operation can resume. If the old combination cannot be validated against current inputs, the bank should say so in the runbook and rely on its approved limited mode.