Skip to content

Threshold Versioning Register

Audit artifact — instantiates Adaptive Threshold Recalibration

The system of record for every threshold in force — its value, rule, rationale, approval, scope, and rollback trigger — so a boundary is never a mystery number.

Threshold Versioning Register is not an act of changing a threshold — it is the ledger that makes every threshold and every past change accountable. Its defining role is to be the single source of truth: for each boundary in the system it holds the current value, the action rule it feeds, the rationale and evidence behind the last change, who approved it and when, the scope it applies to, and the rollback trigger. Every revision appends a new version rather than overwriting the old, so the history is reconstructible. Where its siblings decide and deploy thresholds, this mechanism records them — turning a set of scattered magic numbers into an auditable, reproducible, reversible catalog.

Example

A bank's model-risk function keeps a threshold register. An auditor asks why the transaction-fraud model's escalation cutoff is 0.82. The register answers without anyone reconstructing it from memory: entry shows the live value (0.82), the routing rule it drives, the champion/challenger evidence that justified the last change, the model-risk committee's approval date, the scope (retail cards, EU region), and the rollback trigger (revert to 0.88 if the false-positive rate exceeds a set limit for two weeks). The prior version (0.88) is still on record with its own rationale, so the full lineage of the boundary is visible. The register didn't choose or ship 0.82 — but it is why the choice is now defensible and, if it goes wrong, cleanly reversible.[1]

How it works

The distinctive artifact is one versioned entry per threshold, append-only: a change never edits history, it adds a new version linked to the review, test, and rollout that produced it. Each entry carries the fields that make a boundary accountable — value, rule, rationale, evidence, approver, scope, rollback — so the record answers "what is it, why, who said so, and how do we undo it?" without side channels. It is deliberately passive machinery: it produces no threshold and expresses no preference, but every other mechanism in the set writes its outcome here.

Tuning parameters

  • Granularity — one entry per threshold or per system; finer is more auditable but heavier to maintain.
  • Required fields — which metadata is mandatory (rationale, evidence link, rollback) before a change can be recorded.
  • Immutability policy — strictly append-only versus editable; append-only preserves lineage but grows.
  • Change-control workflow — who may write an entry, and what approval a new version requires.
  • Linkage — how tightly entries link to the review, test, and rollout artifacts that produced them.

When it helps, and when it misleads

Its strength is accountability made structural: it lets anyone reconstruct why a boundary sits where it does, reproduce a past state, and reverse a change cleanly — indispensable when thresholds govern consequential decisions. Its classic misuses are two. A write-only register nobody consults gives the appearance of governance with none of the substance. And a register of backfilled rationales — entries written after the fact to launder a decision already made — is worse than none, because it dresses a fait accompli as due diligence. The discipline is to require the rationale and evidence at change time, and to make the register something people actually read before touching a boundary.

How it implements the components

  • threshold_version_registry — it is the versioned catalog of active and historical thresholds; the mechanism's core.
  • audit_trail_and_rationale — each entry records why a change was made, the evidence, the alternatives, and the approver.
  • current_threshold_rule — it holds the live boundary and the action rule attached to it as the authoritative statement of what is in force.

It does not diagnose drift or choose a new value (recalibration_rule) — Champion / Challenger Threshold Test, Risk Score Threshold Recalibration, and the review siblings do — nor does it deploy a change (rollout_and_guardrail_plan), which Staged Threshold Rollout owns.

Notes

The register is the substrate the rest of the archetype writes to: reviews, tests, and rollouts all deposit their result here. That makes it low-glamour but load-bearing — its value is realized only if entries are written at decision time and consulted before the next change, not reconstructed for an audit after the fact.

References

[1] Model-risk management guidance (for example the U.S. interagency guidance known as SR 11-7) emphasizes documentation, versioning, and clear ownership of model components so decisions can be reviewed and reproduced. A threshold register applies that documentation principle to decision boundaries specifically. ↩