Should the same attachment be copied for every document? Conversely, identical bytes should not erase company ownership or public-access boundaries.
I built a small model separating content identity and business references. It hashes synthetic bytes and stores metadata, without uploading or retaining object bytes.
Identical content does not remove company scope
register_resource computes a SHA-256 digest and byte count. Repeated content within one company returns its existing metadata identifier. Another company gets a separate identity rather than information about the first company’s file. Content equality is not permission to collapse ownership boundaries.
This is not upload completion. The model stores digest and size, not original bytes. A real object-store integration still needs completed storage, server-side integrity evidence and an access policy. Finding matching metadata must not be described as proof that a downloadable original exists.
Keep one resource and multiple relationships separate
Resource metadata identifies content; refs names the document and purpose of a relationship. Connecting two documents creates separate relationships without duplicating the resource identity. Actual download access still needs a server check of document and company rights. This synthetic model assumes trusted context for the supplied document identifiers.
The earlier article explained one original connected to multiple purchase orders and sites. Here I separately test digest identity, company scope and review state with explicit database constraints. Readers can inspect which fields are unique and which relationships may legitimately occur more than once.
Reused does not mean reviewed
New metadata begins unreviewed and cannot be linked as current, history or backup before review. Registering matching content again does not silently turn review on. Duplicate detection and permission to use or expose a file answer different questions.
This site likewise distinguishes completed uploads, manuscript references and public review. The new lab is a small independent contract, not a replica of that entire service. It performs no malware, ownership or sensitive-content inspection. An organization must define the evidence behind its review flag instead of calling one boolean a completed examination of everything.
Removing one relationship does not remove every use
The model separates current, history and backup references. An attachment removed from the current screen may still be needed by a historical document or recovery copy. Unlinking one relationship therefore does not delete its resource. A uniqueness check also prevents repeated linkage of the same document and purpose from inflating the count.
This does not replace an object-storage lifecycle policy. Unknown references outside the tracked database may exist. The preview describes the model’s known relationships rather than claiming complete knowledge of every use. A digest also does not establish origin or authorship, consistent with the earlier integrity boundary.
Expose what the reuse result actually establishes
Recorded runs compare two registrations returning one identity within a company with a separate identity in another company. Tests check rejection before review, cross-company linkage and repeated-reference counts. Fixed synthetic bytes contain no client filenames or domains.
Production adoption must connect object storage, authenticated ownership, document access, downloads and historical records. The package is a metadata experiment that keeps content and relationships distinct. I explain what can be reused and which relationships and reviews still need to be established, rather than presenting deduplication as a complete file-management service.