Many private systems function through accumulated familiarity. One person knows why a server exists. Another remembers which adviser controls the domain. A third understands that a payment file passes through an old entity because changing it once caused trouble. Nothing is written because everything works.
Then the familiar people or systems disappear. Recovery becomes archaeology under pressure.
Documentation is not explanation
A thousand-page inventory can still fail to explain the institution. Recovery requires a compact causal model: which services create which outcomes, which identities and vendors they depend on, what authority is required and what minimum state must return first.
If a competent outsider cannot understand that model in an hour, the organisation is depending on tribal memory.
Legibility has four layers
- Purpose: the institutional outcome the system supports.
- Dependency: people, identities, data, vendors, keys and physical assets required.
- Authority: who can operate, alter, recover and retire it.
- Sequence: the safe order for stopping, restoring and reconnecting it.
Asset lists usually cover only fragments of dependency. Architecture diagrams often ignore authority. Business-continuity documents may describe sequence without the real technical prerequisites. Recovery needs all four.
The compression test
Ask the system owner to explain the service on one page to an experienced operator who has never seen it. The page should identify the first safe function, maximum tolerated interruption, authoritative data source, recovery credentials, external dependencies, emergency decision owner and evidence of successful return.
Then remove the owner from the test. If the operator cannot execute the first recovery step, the explanation is still personal knowledge disguised as documentation.
Complexity must earn its place
Every vendor, integration and exception adds recovery burden. Some complexity creates real capability. Some survives because nobody wants to confront it. The recovery model exposes the difference: if a component cannot be assigned a purpose, authority and return sequence, it is a candidate for removal.
The one-hour recovery map
Create one map per critical institutional outcome, not per technology. Use plain language, named owners and tested contact routes. Date it. Store a protected offline copy. Review it after every material transaction, personnel change or provider migration.
Recoverability is the final test of understanding. If the institution cannot explain how its system becomes itself again, it does not yet know what it owns.