Skip to content

Dependency-Safe Delete Check

A pre-deletion verification gate — instantiates Layer Decay and Expiration Management

A pre-deletion gate that traces every live inbound reference to a layer and refuses removal until the layer is proven an orphan nothing still depends on.

Deciding a layer is worthless is not the same as proving it is safe to remove. Dependency-Safe Delete Check is the gate that stands between the two. Its single job is to answer one question before any deletion proceeds: does anything still point at this layer? — an active workflow, a downstream artifact, an audit trail, a reconstruction path. It walks the reference graph inbound to the candidate layer and blocks removal unless the layer comes back clean, an orphan with no live dependents. It says nothing about whether the layer is valuable or old; it only certifies that cutting it will not sever something still in use. It is the safety interlock that turns a triage decision into a defensible action.

Example

A team wants to drop a legacy_customer_region column that a scoring model was retired last year. Before the DROP, the Dependency-Safe Delete Check runs: it queries the data-lineage graph for every job, view, dashboard, and export that reads the column. Most references are dead — but two surface that nobody remembered: a monthly regulatory extract still selects it, and a materialised view three hops downstream silently depends on it. The check returns not an orphan — 2 live dependents and blocks the drop. The team migrates the extract and rebuilds the view first; a re-run then reports orphan, safe to delete, and only now does removal proceed. The layer's value never changed — what changed is that its dependents were proven gone.

How it works

The check's substance is the inbound reference trace, run before deletion rather than after:

  • Enumerate every kind of dependency that could break — direct reads, foreign keys, cached copies, scheduled jobs, audit/reconstruction paths, external links — as a checklist or an automated graph query.
  • Resolve them against the live system, not documentation, since the dangerous dependents are the undocumented ones.
  • Declare the layer an orphan only when the inbound set is empty; any live reference is a hard block, not a warning.
  • Emit a clear verdict — safe / blocked-by-X — that a deletion mechanism can gate on.

Tuning parameters

  • Dependency scope — how many reference types the check covers (just DB refs, or also jobs, exports, external URLs, human runbooks). Wider scope catches more, but each added edge type is real integration work.
  • Live vs. static resolution — query the running system versus a static manifest. Live is truer but heavier; static is fast but misses dynamic references.
  • Transitive depth — how many hops of indirect dependency to follow. Deeper finds hidden chains; too deep and everything looks entangled.
  • Grace / soak window — whether to watch for newly appearing references over a period before declaring orphan, catching intermittent monthly or quarterly jobs.
  • Block vs. warn — whether a detected dependency hard-stops deletion or merely flags it for human sign-off.

When it helps, and when it misleads

Its strength is that it prevents the worst failure in the whole archetype: deleting something that is still load-bearing. It converts "we think nothing uses this" into "we traced it, and nothing does," and it specifically surfaces the forgotten consumer — the quarterly job, the buried view — that intuition always misses.

Its limits are the limits of the graph it can see. A dependency it doesn't know to look for — an external partner's saved report, a reference resolved by string at runtime, a dependency that fires only once a year — passes as an orphan and gets deleted anyway; the check is only as safe as its coverage is complete. Its classic misuse is being run for show after the decision to delete is made, with the scope quietly narrowed until the layer looks like an orphan — dependency-checking used to bless a deletion rather than to test it. The discipline is to widen scope toward the references you'd most regret missing, add a soak window for intermittent dependents, and pair the check with a recoverable-deletion path so a missed edge is survivable.

How it implements the components

Dependency-Safe Delete Check realises the safety-interlock side of the archetype — proving removal won't break anything live:

  • dependency_and_reconstruction_check — its core: the inbound trace of every artifact, workflow, and reconstruction path that relies on the layer.
  • orphan_layer_detection — the verdict it produces is precisely orphan-status: a layer with zero live dependents, cleared for removal.

It does not judge a layer's worth (that's Age-Weighted Value Score) or estimate the blast radius and hold a recovery window (Soft-Delete Quarantine Window); this gate only certifies that nothing still points at the layer.