Data Modeling using Pods [Support for Subsidiary Ledgers and Business Documents]


This is partly a user experience issue/question dealing with the ability to project/support:

  • some sort of automatic decentralized registry where I can find all of my pods (something like this experience in Groove Workspace
  • pods being children of parent pods (ideally using the same registry mentioned above)

The specific use case I have in mind is being able to support Subsidiary Ledgers capable of storing/referencing billions of business documents like all of the invoices, purchase orders, waybills, delivery confirmations, etc. found in a large corporation (e.g. Microsoft, Apple, US Government, …) …in the “fullness of time”, every business documents on the WWW/Internet/in the universe.


  1. Suggestions for how to architect the Subsidiary Ledgers use case from a Solid pod data architecture perspective?
  2. Can individual items of content be stored in a signed, easily verifiable, and updatable manner?
  3. What is the physical scalability limits envisioned for a single pod?
  4. Can a single instance of an item appear to live in multiple folders and multiple folders across multiple pods? I understand the concept of linking …but digging deeper, should I consider creating a bottom level of physical content pods for storing the business documents as they arrive and as they are created within the organization? …and then one or more layers of “linking” pods above that (that instantiate the hierarchy of Subsidiary Ledger folders)?
  5. On the other end of the scale, is it conceivable that each and every business document (plus supporting documents and business process execution history) could live in its own pod? Is this a realistic architecture/design? …i.e. every large organization having billions and billons of business document pods?