An unused attachment invites cleanup. But an older document or recovery copy may still need its original. Which evidence should be checked first?
The earlier package correction removed public review from an unreferenced object and retained it. I now make that reasoning more explicit with separate current, history and backup relationships.
Not visible now does not mean unused everywhere
Removing a current reference leaves history and backup relationships intact. The example counts them separately. Two remaining historical and backup references classify the resource as retain even after it leaves the current document. A hidden item must not become a cleanup target solely because the latest screen omits it.
The model only knows tracked references. Another system or an exported document may still need the file. Zero known references is not proof of zero uses anywhere. An operational policy must define which storage and access paths the reference inventory covers and where unknown uses could remain.
Removing public review differs from deletion
In the earlier site correction, the previous unpublished package lost review approval and public access was checked, but its original bytes were retained. That preserved evidence for reconsidering a reference or reviewing the work. No client material was involved, and this article does not expose raw internal sources or credentials.
The new synthetic model rejects removing review from a resource that still has a current reference. That small policy protects current documents from becoming unexpectedly unusable. Another service may implement withdrawal differently. I explain the particular protection rather than claiming the new model exactly reproduces the existing site’s behaviour.
Return a review list instead of a deletion command
resource_preview returns manual_review_only for resources without known references. Every result has deleted:false and there is no resource-deletion API. Receiving a candidate identifier does not trigger storage removal. The output is a list an operator can inspect, including what remains uncertain.
Automatic cleanup would need separate policy for retention, old revisions, failed uploads, recovery copies and applicable business obligations. The article prescribes no retention duration or actual deletion rule. It separates the potential benefit of cleanup from the loss of evidence and recovery options.
Keep company boundaries in reference accounting
Identical content in another company has separate metadata. Cleanup queries are scoped to one company rather than revealing that another company uses the same bytes. The example assumes trusted synthetic company context; real identity and administrator permissions remain server responsibilities.
Link creation requires a reviewed resource, and repeating the same document and purpose does not create another relationship. These conditions keep a count meaningful. The model neither checks original object existence nor verifies physical deletion. Metadata candidates must not be described as completed storage validation.
Test the resources that must remain protected
The tests remove a current link while retaining history and backup links and require protection. With every reference removed, the resource remains a manual-review candidate without deletion. Separate checks cover repeated links and review removal blocked by a current reference. Useful cleanup begins by preserving reasons to keep something.
The viewer compares protected and unreferenced results from actual local synthetic runs. It is neither a production file deletion nor a rendered-browser check. I share a stage for understanding what a mistaken cleanup could lose before adding a company-specific retention policy.