Predicate Version Registry¶
Version ledger — instantiates Predicate Criterion Formalization
Preserves each past version of a criterion so a decision made under an old rule can still be read against the rule that made it.
A Predicate Version Registry keeps the full succession of a criterion's definitions over time — each version dated, owned, and linked to the decisions made while it was in force — so a determination reached under an old rule can still be read against the rule that actually governed it. Its defining purpose is temporal integrity: predicates change as policy, evidence standards, and domains shift, and without a registry a later reader silently re-judges past cases by today's definition. The registry preserves not refutations but rule-states — what the criterion said, who owned it, why it changed, and which version stamped each historical decision.
Example¶
A sport's anti-doping code defines "prohibited substance" through a list revised every January. An athlete's 2021 sample is re-examined in 2024. Without a version registry a reviewer might check the 2024 list — but a compound that was permitted in 2021 and banned in 2023 must be judged by the 2021 definition, because that is the rule the athlete was bound by at the time.
The registry makes this correct by construction: each annual list is a version with an effective date, an owning committee, and a change rationale ("added on evidence of a performance benefit"), and every test result is stamped with the version that governed it. So the 2021 result resolves against Version 2021.1; the registry shows the substance was not prohibited then, and shows exactly when and why it became prohibited. Setup to outcome: a criterion that quietly mutates year to year becomes an auditable ledger in which no past decision is retroactively rewritten.
How it works¶
- Version, don't overwrite. Each change creates a new immutable version rather than editing the current definition in place.
- Stamp decisions with their governing version. Every determination records which predicate version produced it, so it can be re-read in its own terms.
- Record owner and rationale. Each version carries who owns it, its effective dates, and why it changed — the change log, not merely a diff.
- Preserve implementations alongside definitions. The code or query that enforced each version is kept with it, so historical behavior can be reproduced, not just the words re-read.
Tuning parameters¶
- Versioning granularity — every edit versus only semantically meaningful changes. Fine granularity is complete but noisy; semantic-only is readable but needs judgment about what counts.
- Effective-dating model — a single timeline versus support for retroactive or overlapping validity windows. Richer temporal models handle backdated changes but complicate lookups.
- Immutability strictness — append-only ledger versus editable history. Strict immutability protects auditability; editability eases correction of genuine mistakes.
- Retention horizon — how long old versions are kept; longer supports late audits at storage and governance cost.
When it helps, and when it misleads¶
Its strength is that it makes past decisions interpretable and defensible, answers "what rule applied when," and prevents the silent anachronism of judging old cases by new definitions — the temporal analogue of semantic versioning for a criterion.[n1]
Its failure mode is registry rot: versions recorded without the rationale or the implementation that made them meaningful, so the ledger says a rule changed but not what it then meant. The classic misuse is applying the current predicate version to historical cases because the registry exists but the decisions were never stamped with their governing version. The discipline that guards against this is to stamp every decision with its version at the moment it is made, and to store the rationale and implementation with each version rather than only the changed text.
How it implements the components¶
predicate_owner_and_change_log— the registry IS this component realized: an owned, dated, rationaled version history for the criterion, with a review cadence and revision record.implementation_trace— by keeping the enforcing code or query alongside each version, it ties each historical decision to the exact implementation that produced it, so past behavior can be reproduced.
It does NOT collect the cases that strain or falsify the criterion, nor route a refutation toward revision — the drift_monitor that reads accumulating failures and the appeal_or_override_path a counterexample triggers are Counterexample Register.
Related¶
- Instantiates: Predicate Criterion Formalization — the registry is the temporal-integrity instance, preserving the criterion across its revisions.
- Consumes: Counterexample Register — an accumulation of logged refutations is often what prompts authoring a new version to record here.
- Sibling mechanisms: Boolean Guard Clause · SQL WHERE Clause or Query Filter · Truth Table · Decision Table · Eligibility Criteria Checklist · Policy Definition of Terms · Test Case Matrix · Counterexample Register · Unknown-State Routing Rule
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Predicate Version Registry operates as a persistent ledger, log, register, or case record that preserves history and traceability because it preserves each past version of a criterion so a decision made under an old rule can still be read against the rule that made it.
Independent corroboration: The frozen evidence defines Predicate Version Registry as 'Preserves each past version of a criterion so a decision made under an old rule can still be read against the rule that made it', 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: Versioning executable criteria so old decisions remain reproducible is a software configuration-management practice.
Related originating lineages:
- Law & Governance — Law contributes the requirement that past decisions be interpretable under the rule then in force.
Review resolution: Both blind reviewers agree that computer science is the primary origin. Reconciliation resolves reported ambiguity. Formative alternate lineages are retained as law_governance; later breadth of use is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among origin lineages.
Attribution caveat: The mechanism deliberately fuses version control with legal temporal-rule interpretation.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] Semantic versioning (SemVer) tags each release of a component with a structured version number so consumers know what changed and can pin to a specific one. A predicate version registry applies the same instinct to a criterion: a decision "pins" to the version that governed it, so later changes to the rule cannot silently rewrite what an old decision meant. ↩