I have been working on how internal documents are kept for a product team.
The problem sounds ordinary until several people and tools are producing reports, procedures and briefs at the same time. Storage can keep the bytes. It does not answer which document is the official one, what kind of document it is, or whether an unknown upload should be trusted.
Identity is separate from storage
The idea I settled on is that a document's identity is its own thing. A reference and a name are issued by one place, so two producers cannot both decide they own the same one. A reference is never reused for a different file, so an old citation cannot quietly point somewhere new.
Where the bytes live is a different question, and it can change without the identity changing.
Reserve, then write
For documents produced by tools, a useful pattern is to ask for an identity first and produce the file second. Automation then uses the same naming as people do, instead of inventing its own filenames.
Unknown does not mean accepted
A file that cannot be recognised, or that is not what it claims to be, should not vanish and should not become trusted material either. It can wait in review until a person decides. That gives a useful middle state between accepted and rejected.
A file system is a history
The part I find most interesting is that this is less like a folder and more like a small system with its own rules. A document has an identity, a type, a state and a history. Renaming, sharing and reclassifying are events, not edits to a string.
That is a stronger foundation than treating a storage path as the source of truth.