Dormant Entity Registry¶
Registry — instantiates Entity Persistence Across Observation Gaps
Keeps an entity's identity and last-known facts in a bounded, tiered, privacy-limited dormant record when detailed prediction isn't warranted — marking it unobserved rather than deleting it, so continuity survives a long gap without inventing a current state.
Some gaps are too long, or the entity too free, for any honest prediction of a current state. Dormant Entity Registry is the answer for those: instead of propagating a fictional present, it retains the identity and the last-known facts and marks the entity dormant — a record that says "this existed, here is what we last knew, and we are no longer claiming to know its present." Its defining move is a deliberate refusal to predict. Where a filter would emit a widening estimate, the registry emits a static, timestamped, provenance-labeled record and lets uncertainty about the present sit honestly as unknown. Because that record could otherwise live forever, the registry bounds it — a storage tier chosen for its dormancy, retention and minimization limits enforced independently of any matching accuracy — so continuity is preserved without becoming permanent surveillance or an unbounded hoard.
Example¶
A company's IT asset system tracks 12,000 laptops by network check-in. When an employee goes on a six-month sabbatical, their laptop stops phoning home. Deleting the asset would be wrong — it still exists, it still carries a serial number, an owner, an encryption key, and a last-known OS patch level — but predicting its state is pointless: it might be in a drawer, in for repair, or reflashed. The Dormant Entity Registry marks the asset dormant: visible-flag off, existence-belief intact, current-state fields explicitly stale rather than freshly guessed.
The record is demoted to a cheap storage tier and stripped to what continuity actually requires — identity, last check-in, owner, provenance of each field — while location history that served no retention purpose is minimized away under policy. Six months later the laptop checks in again; because the registry kept the record alive, the returning device still has an identity to be reassociated with — no duplicate is minted from scratch — even though the actual same-asset match is adjudicated elsewhere. Meanwhile a laptop dormant for three years, past its lease and retention limit, is surfaced for a retirement decision — the registry doesn't decide that itself, it just refuses to hide the staleness. Every field is labeled observed, inferred, or administratively set, so an auditor can see exactly what was known and when.
How it works¶
- Split visibility from existence in the schema. Separate fields for is it currently observed, do we believe it exists, what lifecycle state is it in — never one present/absent flag.
- Keep an identity-bearing record, not a prediction. Persist identity, last confirmed facts, provenance, and lifecycle status; leave current-state fields explicitly stale rather than propagated.
- Tier and bound the storage. Move dormant records to a cost-appropriate tier and cap what is kept, so cheap dormancy doesn't become an expensive or exposed hoard.
- Minimize and expire under policy. Strip fields past their purpose, enforce retention and unlinkability limits, and surface over-age records for a retirement decision made elsewhere.
Tuning parameters¶
- Dormancy trigger — how long unobserved before an entity is demoted from active to dormant. Early demotion saves resources but risks flapping for entities that check in irregularly.
- Storage-tier mapping — how aggressively dormant records are compressed and cold-tiered. Colder tiers cost less but slow the reattach on reappearance; hot dormancy is quick but expensive at fleet scale.
- Retention / minimization horizon — how long, and how much, is kept before fields are stripped or the record is flagged for retirement. Tight horizons limit exposure and clutter; loose ones preserve continuity but accumulate risk.
- Field-level provenance granularity — whether every value or only key ones is labeled observed/inferred/assigned. Fine granularity aids audit and reattach but bloats the record.
When it helps, and when it misleads¶
Its strength is long, unpredictable dormancy — offline devices, asset registries, longitudinal case files — where the right answer is a cheap, honest "we last knew X" rather than a confident fiction. It is the mechanism that lets a system bridge months of silence while keeping identity, history, and provenance intact and its storage and privacy footprint bounded.
Its failure modes are the ones the archetype names for dormant records: stale factual claims read as current (a three-year-old patch level treated as today's), indefinite retention that quietly becomes a surveillance archive, and privacy overreach when identity features outlive their purpose. The classic misuse is letting the registry become a place records go to never leave — dormancy without an eventual retirement pathway is just a slower hoard, the pattern warns against turning caution into clutter. This mirrors the soft state discipline of long-lived distributed records that must be periodically refreshed or expired rather than trusted forever.[n1] The guard is to keep current-state values visibly stale, enforce minimization independently of whether matching ever needs the data, and always leave a retirement path open even though the trigger is pulled elsewhere.
How it implements the components¶
visibility_existence_separation— its schema keeps observed, exists, and lifecycle state as distinct fields, so a dormant entity is unobserved without being nonexistent.persistent_entity_state_record— it is the record: identity, last confirmed facts, provenance, and lifecycle status, with each value labeled observed, inferred, or assigned.resource_budget_and_storage_tier— it tiers and compresses dormant records to a bounded budget so retained continuity doesn't become an unbounded cost.privacy_and_data_minimization_rule— it strips fields past their purpose and enforces retention and unlinkability limits regardless of matching utility.
It deliberately does not predict a current state — the propagated observation_gap_state_model is Predictive State Filter — and it does not itself decide when an entity is truly gone: the calibrated absence_evidence_calibration and the retirement_rule trigger are Absence-Evidence Calibration Test, and the return-match reappearance_association_gate is Reappearance Association Protocol. The registry holds the dormant record; it neither forecasts, retires, nor matches.
Related¶
- Instantiates: Entity Persistence Across Observation Gaps — supplies the bounded, honest dormant record for gaps too long or free to predict.
- Sibling mechanisms: Predictive State Filter · Absence-Evidence Calibration Test · Reappearance Association Protocol · Multi-Observer Sighting Reconciliation · Persistent Identifier Resolver · Tombstone or Deletion Marker
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Dormant Entity Registry operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it keeps an entity's identity and last-known facts in a bounded, tiered, privacy-limited dormant record when detailed prediction isn't warranted — marking it unobserved rather than deleting it, so continuity survives a long gap without inventing a current state.
Independent corroboration: The frozen evidence defines Dormant Entity Registry as 'Keeps an entity's identity and last-known facts in a bounded, tiered, privacy-limited dormant record when detailed prediction isn't warranted — marking it unobserved rather than deleting it, so continuity survives a long gap without inventing a current state', 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: Distributed-systems and configuration practice cohered soft state whose authority decays without refresh, preserving identity while marking current status unknown.
Related originating lineages:
- Library & Information Science — Archival and authority-control practice supplied persistent identifiers, last-known records, retention limits, and provenance.
Review resolution: Distributed-system soft state and archival identity preservation clearly combine in the tiered dormant record; the reviewers' agreement on that synthesis supports high confidence.
Attribution caveat: The dormant tier combines computational soft state with archival identity preservation.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The registry is where the persistent identity supplied by a Persistent Identifier Resolver actually lives out its dormancy, and where a Tombstone or Deletion Marker eventually lands once retirement fires. Keeping the store (this registry) separate from the retire trigger (Absence-Evidence Calibration Test) is what lets a system tune retention pressure without ever silently deleting an entity that was merely unseen.
[n1] In network and distributed-systems practice, soft state is information a system holds only provisionally — it must be periodically refreshed by evidence or it expires, rather than being trusted indefinitely. Configuration-management databases (CMDBs) and device inventories face the same discipline: an unrefreshed record is a claim about the past, not the present. Used here as an established design idea, not a cited source. ↩