Are we documenting the design of the selected DID Method itself? ...or a specific underlying implementation(s) of a selected DID Method?

I'm listening to this week's recording's (https://us02web.zoom.us/rec/play/HQ-lMzg4AhtbLO-kif4ZQ-l86GiaDLy_7ZBE-kJtvuOpkNqknXoP-CijjQPURjAmcXx2DshA3lfnJJvz.9Xbds6-QhlEcjo3A?canPlayFromShare=true&from=share_recording_detail&continueMode=true&componentName=rec-play&originRequestUrl=https%3A%2F%2Fus02web.zoom.us%2Frec%2Fshare%2FtRAGb7hDogbBuBjKg2VUPvOZHBnTS0sPdQumHN1_GPtKCZjqqc-PJGj2jqhhnFEq.5tZGLEEh3x33J-4c) discussion about scalabilty and performance and this is only relevant if we are evaluating specific in-place production deployments of the underlying infrastructure for a particular DID Method. ...for example, I can implment did:foo based on linear text search of a JSON flat file containing 100 DID Documents vs. an Internet-scale DNS Server like Google DNS (htps://8.8.8.8) supporting hundreds of millions of DID Documents with thousands of orders of magnitude difference in scalability and performance.

What are we actually trying to evaluate? If implemented the "right way", every DID Method is scalable to hundreds of milions and potentially billions of subjects.*

The root cause is we haven't defined our North Star for this project - we haven't defined what we're actually trying to do.
What are we really trying to accomplish? I/we keep coming back to that.
@peacekeeper

p.s. For a different project, I've started developing the ID Stack Architecture Reference Model (IDSTACK-ARM).
Here's a copy of the most recent version...

*As a baseline, there are approximately 650 million registered domain names in the world - when subdomains are included, "there are potentially billions" of domain and subdomain names.