Baseline Version Register¶
Governance register — instantiates Reference-Baseline Deviation Flagging
Records baseline definitions, thresholds, reference windows, model versions, and change rationales so past deviations stay reconstructable.
A Baseline Version Register is the archetype's memory for the reference side of the comparison. It is a governed catalog of every baseline the system has ever used — its definition, threshold, reference window, model version, effective dates, and the documented reason it was set or changed. Its defining idea is that a baseline is a versioned, justified artifact with an identity, not an anonymous number buried in a dashboard. When someone asks a year later "what were we comparing against back then, and why," the register answers without anyone reconstructing it from memory. It records what the reference was; it says nothing about any individual observation's departure — that is the other half of the archetype.
Example¶
A retail bank runs a credit-scoring model whose "expected default rate" is the baseline every portfolio deviation is measured against. In March, model risk raises the expected-loss baseline for one segment after a policy change. Without a register, next quarter's audit would find deviations computed against a baseline nobody can name. With one, the entry is explicit: baseline v4.2, expected default 3.1% for the near-prime segment, effective 2026-03-01, superseding v4.1 (2.6%), rationale "affordability rule tightened; back-test attached," approver logged. When a regulator later asks why a January flag and an April flag used different references, the bank pulls the as-of baseline for each date and shows both were correct under their own version — no silent relabeling, no rewritten history.[n1]
How it works¶
The register treats each baseline as an immutable, dated record. A new baseline never overwrites the old one; it is appended with a new version identifier and effective window, and the prior version is retired rather than deleted. Every version carries three things: the definition (the reference value, band, or model and the scope it applies to), the justification (why this baseline, what evidence, who approved), and the lineage (which version it supersedes). Downstream mechanisms stamp their outputs with the version identifier so any past deviation can be re-evaluated against the exact reference that was live at the time.
Tuning parameters¶
- Versioning granularity — whether a tiny threshold tweak spawns a new version or amends the current one. Fine granularity preserves perfect reconstructability but clutters the history; coarse granularity is tidy but can blur when a break really occurred.
- Justification depth — a one-line rationale versus an attached back-test and approval chain. Deeper records are audit-proof but slow the cadence of legitimate rebaselining.
- Approval gate — who may register a new baseline, and how many sign-offs. Tighter gates prevent comparator-shopping; looser gates keep the reference current.
- Retention horizon — how far back retired versions are kept queryable. Longer retention supports long-horizon audits at storage and complexity cost.
- Effective-dating rule — whether versions are dated by valid time, transaction time, or both, which governs how cleanly "as-of" queries resolve.
When it helps, and when it misleads¶
Its strength is accountability: it makes rebaselining a deliberate, attributable act instead of a quiet edit, and it lets historical deviations be re-read against the reference that was actually in force. This is the single defense against the archetype's nastiest failure — a new baseline silently changing which past observations count as deviations.
Its failure mode is that a register documents that a baseline changed, not whether the change was wise; a well-governed log of bad rebaselining decisions is still a log of bad decisions. It can also invite comparator-shopping dressed in process — teams cycling baselines until the deviations look favorable, each change dutifully justified. The guarding discipline is to require the justification to precede the change and to review the rate and pattern of rebaselining, not just each entry in isolation; a baseline that moves whenever it is about to be embarrassing is a smell no amount of documentation cures.
How it implements the components¶
baseline_version_control— its core function: every baseline is an appended, dated, superseding version, never an overwrite, so history stays reconstructable.baseline_justification_record— each version binds the reason, evidence, and approver, turning a reference into a defensible artifact.declared_reference_baseline— the register is where the reference is formally declared and stored: the value, band, or model and the scope it governs.
It does NOT implement deviation_fact_record — recording individual departures is the Deviation Event Log's job, the observation-side twin of this reference-side register — nor comparison_metric_rule, the arithmetic of comparison owned by the Baseline Delta Table.
Related¶
- Instantiates: Reference-Baseline Deviation Flagging — the register governs the baseline identity every deviation must point back to.
- Sibling mechanisms: Baseline Delta Table · Control Chart or Run Chart · Deviation Event Log · Deviation Review Queue · Exception Flag Rules Engine · Null-Model Residual Report · Reference Range Flag · Rolling Baseline Comparison · Standardized Residual Score
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Records baseline definitions, thresholds, reference windows, model versions, and change rationales so past deviations stay reconstructable, making its operative form a durable account of actual events, decisions, or transitions whose value depends on history or provenance.
Independent corroboration: The frozen evidence defines Baseline Version Register as 'Records baseline definitions, thresholds, reference windows, model versions, and change rationales so past deviations stay reconstructable', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Database and configuration management developed versioned, bitemporal records of definitions, effective dates, and change histories.
Related originating lineages:
- Accounting & Auditing — Audit practice requires reconstruction of which reference and threshold governed a past decision.
- Data Science & Analytics — Model and analytics governance applies versioned baselines, windows, and thresholds to reproducible evaluation.
- Library & Information Science — Records management supplies durable cataloging, identity, and provenance of reference artifacts.
Review resolution: The defining capabilities—immutable versions, effective periods, lineage, and as-of reconstruction—come from database and configuration management, making computer science primary. Microsoft documents system-versioned temporal tables for full change history and point-in-time reconstruction, while W3C PROV formalizes revisions; audit, data governance, and records management shape the Encyclopedia's baseline-specific register.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
The register and the Deviation Event Log are the archetype's two record-keepers and are easily conflated. Keep them separate: the register versions the reference (few entries, changed deliberately), the log accumulates facts (many entries, appended constantly). A deviation fact in the log is only reconstructable because it carries a version pointer into the register.
[n1] Bitemporal modeling — recording data along two time axes, valid time (when a fact was true in the world) and transaction time (when the system recorded it). It is what lets a register answer "which baseline was in force as of that date" correctly even after later revisions, without rewriting the earlier record. ↩