Build an actionable dependency register

The register starts with the function the organisation refuses to lose. Every critical journey is connected to the data, models, infrastructure, identities, interfaces, rights and skills without which it cannot run on another target.

This avoids two false positives: assuming an exportable asset is sufficient when it relies on a non-portable service, or calling a dependency critical without showing which function it blocks.

A useful record must remain unambiguous months later and still point to the same asset.

• Identifier — stable across the file and related evidence
• Object — precisely named asset, service or know-how
• Version — state actually used by the observed service
• Owner — person able to provide or change the object
• Function — critical journey that depends on the object
• Evidence — item or test confirming the recorded state

Separation prevents a data export from being presented as reversibility of the whole service.

• Data — content, metadata, schemas, reference data and provenance
• Models — artefacts, APIs, parameters, prompts, routing and evaluations
• Infrastructure — compute, storage, network, orchestration and backups
• Identities — accounts, roles, secrets, certificates and federation
• Interfaces — APIs, events, formats, quotas and service contracts
• Rights — contracts, licences, intellectual property and erasure
• Skills — procedures and knowledge required to operate the service

An interface may be documented while relying on an identity controlled by the source. A model may be replaceable while its evaluation set is not. The register therefore retains upstream and downstream relations, flow direction and the consequence of a break.

Read the chain in both directions: from service to assets to find what is missing, then from each asset to journeys to measure what an outage interrupts.

A competing product does not prove that a component is substitutable within the required time.

The supplier, contract, model, export format and team change. The register carries an observation date, version, source and verification status. An old assertion is not automatically renewed.

The register is ready when it determines which assets to export, journeys to replay, rights to confirm, people to mobilise and dependencies whose presence after switching would make the exit unacceptable.