A buyer bookmarks a product catalogue. Later, the address still works but the document describes another product or a revised specification. One possible cause is simple: the publishing system used the original filename as the storage key, and another upload with the same name replaced the content. A stable link does not establish a stable document if the object behind it can change without an explicit release decision.

For an international content team, the useful distinction is between the name a buyer sees, the object that stores the bytes and the business version approved for publication. They can be connected, but they should not be treated as the same identity. A file called catalogue.pdf is readable and convenient; it is not necessarily unique across products, languages or contributors.

A working upload example leaves a business decision open

AWS's 14 October announcement of S3 integration with Vercel and v0 includes a concise upload example that uses the incoming file's name as the object key. It demonstrates how to send a file to storage. It does not establish a production document-release model for a manufacturer's product library.

The S3 PutObject reference explains that writes to the same object can overwrite the current content. This is expected storage behaviour, not evidence of a platform defect. If the application maps unrelated uploads to the same bucket and key, the business ambiguity began in the application's choice of identity.

A library can instead allocate an independent object identifier and retain the original filename as display metadata. Product association, language and document revision can be recorded separately. This allows two contributors to upload files with familiar names without making their content compete for one location.

The business action should also be explicit. Adding a separate document, saving a new draft of an existing document and replacing its published edition are different operations. If all three become an unrestricted write to one key, an upload button has quietly acquired the power to change buyer-facing information. Asking every contributor to invent a unique filename is a fragile substitute for defining those operations.

Retaining an old version does not approve a new one

S3's reference describes versioning as retaining distinct version IDs for writes to the same key when the feature is enabled. That can support recovery and version-specific retrieval. If a page still asks for the current object at that key rather than a fixed version ID, a later upload can change what it receives. Retaining the old bytes does not make the old public link version-specific.

Storage versioning also has no inherent knowledge of an editorial state such as technical review complete or English copy awaiting correction. A retained version answers which stored object can be retrieved. A release decision answers which document buyers should receive. The team needs both answers when a revised specification is still being checked.

If an operation is intended only to create a new object, PutObject provides the If-None-Match: * condition to reject an existing key rather than silently overwrite it. The application should expose and handle that conflict as a conflict. Bucket type and API support must be checked for the implementation in use; this is not a claim that every storage product accepts the same option.

For a Chinese exporter with several language editions, an approved English catalogue may legitimately remain public while another language draft is being revised. Automatically moving all page links when any file is uploaded can destroy that distinction. Publication references should change through the intended release operation, not as an accidental side effect of storing a draft.

Test the public reference as well as the upload

Use clearly marked test files to check the workflow without handling real customer material. Two uploads with the same display name should behave according to the stated design. A deliberately conflicting create-only operation should produce a visible conflict. Saving a draft should not silently replace the document referenced by the public page.

Then test an approved replacement. Check which product and language pages change, and whether a historical version can still be identified where the business requires that capability. A long-lived “current catalogue” address and a reference to a particular historical edition serve different needs. Their meaning should be apparent to the people using them.

This is separate from moving an existing product library into newly connected storage. Migration verifies where the current files and references go. Upload identity determines what later contributions are allowed to change. A one-time migration check cannot establish that subsequent uploads remain distinct.

Keep the filename useful for people, but give the content an explicit identity. Before an upload changes anything buyer-facing, the system should know whether the user is adding another document, revising a draft or releasing a replacement.

Sources