Aspect Lifecycle Register¶
State registry — instantiates Aspect-Scoped Identity Projection
Tracks each aspect's state through time — proposed, active, suspended, superseded, retired — with the persistence rules that decide every transition and the evidence that triggered it.
An Aspect Lifecycle Register is a dated ledger that records, for every aspect-scoped identity, which state it currently occupies and every transition it has already passed through — and, for each transition, the rule that allowed it and the evidence that fired it. Its defining idea is that it governs the aspect in time, not in structure. It says nothing about what an aspect may do, how it is named, or which of its properties come from the underlying bearer; it answers only one family of questions: Is this aspect in force right now? When did it start? What changes did it survive, and what retired or superseded it? Where other siblings freeze a single snapshot of an aspect, the register is the mechanism that keeps the snapshot honest as the world moves.
Example¶
A university registrar treats a person's student identity as an aspect distinct from the person. The register opens a row the moment an applicant is admitted, and thereafter moves that aspect through a defined sequence of states: admitted → enrolled → on-leave → graduated → alumnus, with side-branches for withdrawn and dismissed. Each move carries its trigger: an enrollment confirmation flips admitted to enrolled; an approved leave request suspends it; a conferral of degree supersedes enrolled and opens a successor alumnus aspect linked to the same person.
Crucially, the register also encodes what each state survives. The student aspect persists through a legal name change, a new address, and a switched major — none of those retire it. But a formal withdrawal does retire it, and graduation supersedes rather than deletes it, so the transcript of a graduated student remains answerable as "an aspect that has ended," not a live enrollment. When a bursar asks "is this person an enrolled student as of March 1?" the register answers as of that date — not as of today — because it stores the whole history, not just the latest value.
How it works¶
The register is built from three moving parts working together:
- A state model. A small, explicit set of legal states and the transitions permitted between them (a directed graph, not a free-text status field). Illegal jumps — alumnus back to applicant — are simply not edges.
- Persistence criteria per transition. For each edge, a rule naming what triggers it and, just as importantly, what does not. This is where "survives a name change, retired by withdrawal, superseded by graduation" lives.
- Creation and transition evidence. Every row and every move carries a pointer to the artifact that justified it (the admission decision, the leave form, the conferral record), so the state is always traceable to a cause rather than asserted.
The register is append-oriented: transitions add dated entries rather than overwriting, so any past state is reconstructable. The current state is a derived read over that history.
Tuning parameters¶
- State granularity — how many distinct states the model admits. More states capture finer distinctions (probation, deferred, dormant) but multiply the transition rules that must be defined and maintained.
- Transition strictness — whether only enumerated transitions are allowed or ad-hoc corrections are permitted. Strict models catch bad data; permissive ones survive messy real-world exceptions but erode the guarantee.
- Evidence bar — how strong the artifact behind a transition must be, from a logged actor-and-timestamp to a countersigned document. Higher bars raise trust and cost.
- Supersession vs. retirement policy — whether an ending aspect is closed and forgotten or closed and linked to a successor. Successor-linking preserves continuity across phases at the cost of a longer chain to walk.
- Temporal resolution — whether the register answers only "now" or "as of any past date." Full valid-time history is powerful for audits but heavier to store and query.
When it helps, and when it misleads¶
Its strength is that it makes the time dimension of an aspect first-class. Any question of the form "was this aspect active then, and by what warrant?" becomes answerable, and the archetype's classic failure — a change to the underlying bearer wrongly retiring every aspect, or an aspect change wrongly minting a new whole entity — is prevented by transition rules that name exactly what each state survives. Modeled well, it behaves like a Type 2 slowly-changing dimension: each change is a new dated version, and no history is silently lost.[1]
It misleads when the state model drifts from reality. The classic misuse is a status field that is set but never retired — aspects pile up in a stale "active" that nobody transitions out of, and the register quietly becomes a graveyard that reports the past as the present. It can also over-fragment: modeling every minor context change as a new lifecycle state produces a combinatorial mess of transitions nobody maintains. The guarding discipline is to keep the state set small and audited, require a dated evidence pointer for every transition (so an unretired aspect stands out as an assertion without a cause), and reconcile the register against ground truth on a fixed cadence.
How it implements the components¶
aspect_lifecycle_state— its core artifact: the current state plus the full dated sequence of states each aspect has occupied.aspect_persistence_criteria— the per-transition rules encoding what a state survives, what retires it, and what supersedes it with a successor.aspect_creation_evidence— the mandatory pointer, on the opening row and every transition, to the artifact that justified it.
It does not implement authority_and_review_rule or aspect_or_role_selector — the register records that a state changed and on what evidence, but the standing authority that makes a status legitimate belongs to its nearest twin, Legal Capacity or Status Record; the reusable typed bond that links one aspect to the next is cross_aspect_linkage, owned by Typed Identity-Relation Edge.
Related¶
- Instantiates: Aspect-Scoped Identity Projection — supplies the time-and-state governance the projection needs to stay accountable and reversible.
- Sibling mechanisms: Legal Capacity or Status Record · Database View or Entity Projection · Role-Based Access Profile · Role-Scoped Record Type · Scoped Namespace Suffix · Typed Identity-Relation Edge · Work / Expression / Manifestation / Item Model
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Tracks each aspect's state through time — proposed, active, suspended, superseded, retired — with the persistence rules that decide every transition and the evidence that triggered it, 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 Aspect Lifecycle Register as 'Tracks each aspect's state through time — proposed, active, suspended, superseded, retired — with the persistence rules that decide every transition and the evidence that triggered 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: Temporal databases and Type-2 slowly changing dimensions provide dated, append-and-version state histories answering as-of questions.
Related originating lineages:
- Library & Information Science — Authority records preserve identity changes and supersession.
- Organizational & Management Science — Lifecycle governance supplies named transition rules and evidence.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
The register is deliberately only a timeline — it stores no local aspect data and grants no rights. That thinness is the point: a hospital, a registrar, and a licensing board can each attach their own record types, access profiles, and authorities to an aspect while sharing one honest account of when that aspect was in force. Fuse the timeline into any single one of those systems and the history stops being reusable.
References¶
[1] Kimball, R., & Ross, M. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling. 3rd ed. Wiley (2013). Describes Type 2 slowly changing dimensions as adding a dated row for each change so prior history remains available. registry ↩