Changing a threshold does not resolve a finding

Separate an observed value from the rule applied to it

Load the drift preset and retain its original full report. It has twenty unique expected periods, complete return pairs and a declared delivery age of twenty-four hours. PSI is 0.2024989980. With review at 0.10 and escalation at 0.25, that value produces a review alert. The observation and the classification are separate objects: the feature records and metric define what was measured; the selected policy determines its treatment.

Create a local comparison by changing only psi_review to 0.21. Leave psi_escalate at 0.25, the baseline and current sample unchanged, and preserve bins, smoothing and return settings. The result becomes within_example_bounds because 0.202499 is below the new review level and no other alert applies. No feature improved and no evidence about the original change appeared. This illustrates why a cleared status is insufficient as an approval rationale.

Validate the proposed rule before comparing statuses

The policy contract requires a nonnegative review threshold strictly below escalation. Setting both to 0.25 would fail validation rather than produce a permissible alternative report. Keep this distinction visible in a change record: a rejected input is not a valid replay with a different decision. Equality between an observed PSI and a valid threshold does trigger its corresponding alert. Boundary conventions must remain documented when evaluating a proposed revision.

The fictional policy-approver role therefore requests the original and proposed values, identical input identity, unchanged metric result and every status difference. A broader rationale would address the intended population, consequences of missed changes, review workload and independent evaluation. One inconvenient observation cannot calibrate an acceptable threshold. The example does not fabricate such evaluation, committee approval or a historical operational decision; it demonstrates the evidence that would still be needed.

Record a decision without inventing an operating history

The change register keeps this exercise as EXAMPLE-POLICY-03 with an explicit fictional flag and revision one. Its decision is to reject the unsupported relaxation, retain the original review finding and investigate the cause. The owner role is hypothetical. Scope, reason, validation, decision, rollback and evidence make the record useful without suggesting a real incident, named employee, regulated approval process or existing production service behind the publication.

Two other fictional records address different changes. A defective quality batch is escalated while ambiguous metrics are withheld; correcting it requires authoritative source evidence. A proposed baseline replacement is deferred because comparing current data with itself would mechanically erase PSI. Neither action is equivalent to a policy edit. Keep data corrections, reference replacements and decision-rule revisions distinguishable so a later reviewer can identify exactly which interpretation changed and why.

Make replay and rollback evidence explicit

Retain the original input, exported report, proposed input, comparison result and rationale. A rollback here means restoring the recorded example policy and replaying preserved inputs; the browser has no authority to reverse a production deployment or stop trading. If an unapproved edit were found in the fictional workflow, preserve the evidence of its effect as well as restoring the prior value. Do not erase the attempted change from the record.

The register separately lists publication version 1.0.0, dated October 16, 2026, as the initial edition. It invents no earlier releases. Federal Reserve model risk guidance supplies banking-specific governance context, and NIST's voluntary framework concerns AI systems; neither prescribes this threshold. Actual production approval would require separately established responsibilities, execution controls and durable evidence. This exercise ends with an inspectable educational comparison and an explicitly fictional decision, not a claim that those controls exist.

Keep in the decision record

• A valid policy change can alter status without changing the observation.
• Rejected inputs must not be reported as valid comparison runs.
• Preserve fictional labels, evidence and rollback intent alongside decisions.

Source notes

1. Federal Reserve SR 26-2, April 17, 2026
2. Federal Reserve: revised model risk guidance
3. NIST AI RMF: voluntary scope and revision status

Sources inform the stated methods and governance context. All example monitoring observations are synthetic. No regulatory approval or production monitoring certification is implied.

Continue the analysis