Engineering journal
Why Is This Asset Still Stored?
Omniweft's read-only retention inspector separates asset identity, shared bytes and explicit roots, so collection can be explained before it changes state.
Source: https://louijiecompo.com/writing/why-is-this-asset-still-stored/
About 3 min read
Deleting one asset does not necessarily release its bytes. Two assets can refer to the same content while carrying different provenance, and more than one root can retain either asset. A useful inspector must explain those relationships before a caller decides what to remove.
Omniweft's FP-008 retention inspector (opens in a new tab), merged in PR #30, makes that explanation a read-only query over a bounded native catalog.
Three identities to keep distinct
The content hash identifies the bytes. A manifest carries an asset's source and license metadata as part of its identity. Explicit current and history roots describe why an asset remains retained. These fields preserve provenance; they do not authenticate a license claim.
Consider the seed-7 fixture (opens in a new tab). It contains two provenance-distinct assets sharing one blob, plus an independent third asset. Current roots, multiple history sets and an empty history set exercise the inspector.
| Question | What the inspector explains |
|---|---|
| Why does this manifest remain? | Every current and history root reason. |
| Why do the bytes remain? | Other retained manifests sharing the blob. |
| What could ordinary collection remove? | Sorted manifest and blob candidate sets at this revision. |
Removing one root can change a manifest's eligibility without making the shared blob collectible. An explanation that reports only a byte count would hide the dependency responsible for that result.
An explanation belongs to a revision
The query requires an expected Catalog revision. A stale request rejects without a report or mutation. A fresh query after a root change produces a new explanation. The returned metadata is detached, so editing a report cannot edit the catalog it describes.
This is useful for both people and agent-operated software. A caller can inspect a consequence before proposing a state change, while the operation that changes state retains its own authority and revision checks. Read access does not become permission to collect.
Test the prediction against the operation
The fixture reconstructs a private Catalog using ordinary import and root commands, then compares predicted IDs against actual collection. It also checks that inspection and detached-report edits preserve the original full snapshot and exported bytes. That tests the explanation against the existing operation rather than merely comparing two report strings.
The implementation adds no remote endpoint, durable asset store or inferred World/undo references. The evidence is CPU-only and establishes no new rendering or physics behavior. Other adopted feature proposals still need their own implementation and review. The example's historical draft wording is superseded by the merge record (opens in a new tab).
The broader design lesson is to expose ownership and retention reasons at the same boundary where a caller evaluates an action. The Omniweft case study connects that contract with existing asset import and worker recovery. Continue with retrying workers without duplicating actions for another example of keeping observation and mutation authority separate.