Persistence Exception Register¶
Register — instantiates Change-Scoped Revalidation
Records each fact deliberately carried forward unchecked after a change — with its owner, its confidence, and the condition that would force a recheck — so the persistence presumption is explicit and accountable rather than silent.
After a change, most of what a system knows is simply kept — carried forward on the presumption that a local change did not touch it. That presumption is usually right and always convenient, but it is silent: nobody records which facts are being trusted, why, or who would notice if the trust were misplaced. Persistence Exception Register makes that silence explicit for the items where it is riskiest. It is the standing ledger of facts deliberately retained without re-derivation — each entry naming the item, the reason it is presumed still valid, an owner accountable for that call, a confidence tag, and the observation that would defeat it and force a recheck. Its defining move is that it inverts the archetype's other bookkeeping: where a worklist tracks what you will re-check, the register tracks what you are choosing not to — turning a blanket "everything else is fine" into a short list of named, owned, defeasible exceptions.
Example¶
An ISO 15189-accredited clinical laboratory swaps one reagent lot in an immunoassay. The change is small, but the lab's accreditation rests on a large body of prior method-validation evidence — precision studies, reference ranges, interference checks — most of which the lot change plausibly does not disturb. Re-running all of it would take the assay offline for weeks. So the quality manager opens the Persistence Exception Register. For each block of prior evidence the lab intends to keep relying on, an entry goes in: reference ranges — presumed unaffected because the lot change does not alter the assay's calibration; owner: the chemistry section head; confidence: high; defeat condition: any shift greater than ≈2 SD in daily QC. The interference study, by contrast, is not carried forward — the new lot's excipients differ enough that its persistence cannot be justified, so it moves to the revalidation worklist instead.
Months later, when an auditor asks why the interference study was repeated but the reference ranges were not, the answer is not "we judged it fine" — it is a dated register entry with a named owner and a stated defeat condition that the QC data has kept satisfied. The register did not decide what to keep; it made every keep decision visible, attributable, and revocable.
How it works¶
- Enroll only the risky retentions. Not every carried-forward fact needs an entry — only those close enough to the change, or consequential enough, that a silent wrong assumption would bite. The register is a short list of exceptions, not an inventory of everything untouched.
- Give each entry a defeat condition, not just a rationale. A retention is only defeasible if something concrete could overturn it — a QC threshold, an expiry date, a downstream alarm. The defeat condition is what makes the persistence presumption falsifiable rather than merely asserted.
- Assign a named owner. Each retention is somebody's accountable call, not the collective's. The owner is who revisits it when its defeat condition trips or its review date arrives.
- Tag confidence. Low-confidence retentions get shorter leashes, and the tag tells the boundary-escape test which retentions to probe hardest.
Tuning parameters¶
- Enrollment threshold — how close to the change, or how consequential, a retained fact must be before it earns an entry. Lower it and the register catches more silent assumptions but bloats toward an everything-inventory; raise it and it stays lean but may miss a near-boundary retention.
- Defeat-condition strictness — how sensitive the trip-wire is. Tight conditions catch drift early but raise false alarms and churn; loose ones let a retention ride until it clearly fails — sometimes too late.
- Owner granularity — one accountable individual per entry versus a team. Individual ownership sharpens accountability; team ownership survives turnover but diffuses it.
- Expiry / review cadence — how long an exception may stand before it must be re-justified or promoted to the worklist. Short expiries keep the ledger honest; long ones reduce overhead but let stale trust accumulate.
- Confidence resolution — a coarse high/medium/low flag versus a graded score that feeds the boundary-escape sampler's priority.
When it helps, and when it misleads¶
Its strength is that it converts silent trust into something attributable, dated, and revocable. It lets a team defend not re-checking as a reasoned call rather than an oversight, gives an auditor a target other than "explain everything you didn't test," and ensures that when a retention does go wrong there is a named owner and a stated trip-wire rather than a shrug.
Its central weakness is that the persistence presumption is defeasible[n1] — held by default until specifically defeated — so the register is only ever as safe as its defeat conditions. A retention whose defeat condition is vague, or concrete but unmonitored, is just an assumption in nicer clothing. Its classic misuse is to be run backwards: entries written to rationalize a decision already made to skip rechecking, defeat conditions set so loose they can never trip, so the ledger launders "we didn't want to redo the work" into "we justified keeping it." The discipline that guards against this is to require a concrete, monitored defeat condition and an expiry on every entry, and to periodically audit a sample of retentions by actually re-deriving them — letting the boundary-escape test, not the ledger's own say-so, confirm the presumption held.
How it implements the components¶
persistence_presumption— each entry is the presumption made explicit: a fact declared still-valid-by-default, with the reason the default is believed attached to it.exception_owner— every retention carries a named owner accountable for the call and for acting when its defeat condition trips.uncertainty_annotation— the confidence tag records how much trust each retention has actually earned, and drives how hard it should later be probed.
It does not select or sequence the re-derivation work — that is Selective Revalidation Worklist — nor compute the affected boundary it presupposes (Impact Analysis), nor automate invalidation and re-derivation (Truth-Maintenance System).
Related¶
- Instantiates: Change-Scoped Revalidation — the register holds the retain side of the archetype's boundary: the facts kept true by presumption.
- Consumes: Impact Analysis — the scope boundary tells the register which retained facts sit close enough to the change to deserve an explicit exception.
- Sibling mechanisms: Selective Revalidation Worklist · Truth-Maintenance System · Impact Analysis · Requirements Traceability Matrix · Dependency Graph · Regression Test Suite · Data Diff and Merge Tool · Cache Invalidation Review · Change Impact Report · Boundary Escape Sampling · Dependency Closure Traversal
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Persistence Exception Register operates as a persistent ledger, log, register, or case record that preserves history and traceability because it records each fact deliberately carried forward unchecked after a change — with its owner, its confidence, and the condition that would force a recheck — so the persistence presumption is explicit and accountable rather than silent.
Independent corroboration: The frozen evidence defines Persistence Exception Register as 'Records each fact deliberately carried forward unchecked after a change — with its owner, its confidence, and the condition that would force a recheck — so the persistence presumption is explicit and accountable rather than silent', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Explicitly recording unchanged assumptions after modifications descends from engineering change control and configuration management.
Related originating lineages:
- Accounting & Auditing — Exception registers and owner sign-off supplied the assurance and accountability form.
- Organizational & Management Science — Organizational and management science materially shaped Persistence Exception Register through coordination, organizational learning, performance, and change practice. Change-management practice supplied review triggers and responsibility assignment.
- Philosophy — Persistence Exception Register is rooted in philosophy: Defeasible and nonmonotonic reasoning supplies the logic of a presumption retained until named defeating evidence appears.
Review resolution: Light authoritative-source research resolves the primary-origin disagreement in favor of engineering design and systems assurance. NASA Systems Engineering Handbook directly documents the defining practice or theory described in the selected origin rationale. Other listed domains are retained only where the blind reviews identify material co-development or translation; broader adoption remains separate as domain_reach=multi_domain.
Attribution caveat: The persistence-presumption framing is an encyclopedia synthesis of established change-control practices.
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 is deliberately a ledger of exceptions, not a catalogue of everything untouched. If it grows to list every retained fact, the persistence presumption has collapsed back into "recheck everything," and the mechanism has defeated its own purpose — the whole point is to keep the enrolled set small enough that each entry gets a real owner and a real trip-wire. Its safety is also external: a defeat condition that nothing actually monitors is inert, so the register only works when its trip-wires are wired to something that observes them.
[n1] In logic, a defeasible inference is one accepted by default and withdrawn only if specific defeating evidence appears — reasoning that is non-monotonic. The persistence presumption is exactly this: a retained fact is treated as still valid until its defeat condition is met, which is why an exception without a monitored defeat condition is not a defeasible belief but an unfalsifiable one. ↩