most use cases can be effectively handled with less exotic tooling, like a document management system (database in front of the information / documents) or a NoSQL front.
There are plenty of DMSes, none of them do the job well enough at this point.
Blockchains strengths lie in being trustless. For information or document retrieval, it may work at small volumes, but not when it reaches any significant level, even for a small business - compared to a Doc management system or key-value store (NoSQL).
This is why I mentioned "pseudo" blockchain. It doesn't have to be a blockchain, just resemble components of it. No company wants their data immutable.
So, why can't people find "stuff"? They simply don't use a tool and insist they should just be able to throw information any dam where they please.
I don't think you understand the complexity of the problem at scale. We are talking about globally distributed organizations, handling hundreds of millions of documents yearly, localized legal models, external collaboration, multiple repositories, complex user access models and then, automation based on the changing information within the documentation. It isn't simple storage and retrieval.
However, what does work is using a database or key value store similar to what you are using (based on your screenshots) as the "blockchain" of references. Then it doesn't matter where the information is actually stored, as they are all linked to the timeline backbone, including the versions, which at an interface level can appear as a single document.
This allows people to throw information wherever they want and as long as it is appropriately labelled at that point (done automatically or user-defined), it will be allowed to join into the stream.
One place to store and look for any and all types of info, like this showing some of my crypto notes
"One place" just doesn't work at enterprise level for so many reasons. One of them is of course that human data hygiene is terrible. One of the others is just the practicality across quite different tech stack needs based on department usecases.
Enjoying the solution ideas. And if you don't mind me with additional foods for thought...
References are fine within an entity, as there's control and knowledge over it's availability and existence. But linking in any other case, I'm gunna balk.
It's all good and fine when all linked systems are up and behaving, but one broken or unavailable reference can degrade validity quick. If every document or info isn't available 100% perfectly all the time 24x7x365, else there's that inevitable finger pointing shootout scene, when there's data that needs to be produced and it's either incomplete or late. Other people's / department's / company's systems ALWAYS go down when you need them most - that I learned from trading... nah, it's always been true.
However, federate it into "one place" and you have reproducable results and control over the data, even if transient. 100 million documents.. decent sized, doable.
I prolly sound jaded, but having been called into meetings and seeing Bob blaming remote Jane blaming remote Sally, ad infinitum, gets old fast. I've personally witnessed it in airlines, electrical grid systems, all the way down to daycare, schooling, local govts...
None of the DMs do the job well enough? At 100 million documents I wouldn't suggest a third party solution - coder up.. way cheaper, faster and functionality out the wazoo.
One place just doesn't work for a global corporation, as there are localized laws that prevent it.
I am sure it does. I have gone into these companies too, and trained them on solutions that do work at scale :)