Resources
Short practical notes from the work of getting a register accurate and keeping it that way.
Aster Vale Register onboarding
New customers usually ask how long onboarding takes. The honest answer is that importing data takes an afternoon and agreeing what the data means takes a fortnight.
The Aster Vale Register onboarding sequence is deliberately short. Import an existing asset list, confirm ownership against your directory, mark the systems that would genuinely hurt if unavailable, then record dependencies for that subset only. Teams that try to map everything before recording anything tend to stall at the mapping stage and produce nothing usable.
Start narrow. A register covering twenty critical systems accurately is worth considerably more than one covering four hundred approximately.
Ownership is a person, not a team
Team-level ownership reads as tidy and behaves badly. When a system is owned by a team, an overdue review belongs to nobody in particular, and the question "who decides whether this can be decommissioned" has no answer until somebody escalates.
Named ownership creates an obvious failure mode — people leave — but it is a failure mode you can detect. Validating owners against your identity provider turns departures into a visible list rather than a silent gap.
Recovery objectives that were never agreed
Most recovery time objectives are inherited rather than decided. They appear in a document, get copied into the next document, and are never tested against what the business would actually tolerate or what the infrastructure could actually deliver.
A useful exercise: take your Tier 1 systems and ask two questions separately. What does the business believe the recovery time is, and what has recovery actually taken the last three times it was tested? Where those numbers disagree, one of them is fiction, and it is worth knowing which.
The dependency nobody records
Shared components several tiers down are the most consistent gap we see. Each individual team's exposure looks minor, so nobody rates it critical — and then it turns out that eleven services rely on the same certificate authority, message broker or identity provider.
Recording dependencies in both directions surfaces these without anyone needing to have the insight. A component with eleven consumers is visible as soon as consumers are recorded, whether or not anyone thought to look.
Evidence ages faster than you think
Continuity documentation is accurate on the day it is written. The rate of decay after that is a function of how quickly your environment changes, and most teams underestimate it substantially. Reviewing a tenth of the register every month keeps the whole thing within a year of reality, which is usually enough.