Your concerns are accurate; I know that this is a little wishy-washy at the moment.  But this is kind of a foundational part of the idea of the framework, IMO, so I do think it's important that we put this info in front of users right now so that they can take the intentions of the framework into account.

For example, the reason that I renamed the jetty service to `webserver-service` is specifically to try to begin to address this.  Right now, there is nothing that a service developer has to put *in code* that ties them to the specific jetty-based implementation of the webserver service; the word `jetty` only appears in the bootstrap config file.

Also, when you say "I don't think trapperkeeper currently supports any of it", I might contest the use of the word "supports".  It absolutely "supports" it, assuming that the user understands that the contracts are currently implicit.  For example, there is nothing that would prevent a user from eschewing our built-in jetty service and writing their own implementation of a `webserver-service` today, other than the fact that they have to understand the implicit contract.

So... do we need some better capabilities for being explicit about contracts/interfaces in order to fully realize this goal?  Absolutely.  Does that mean that it's not possible to use the system in this way today?  No.  In fact, I wrote multiple implementations of an RBAC service during my POC work with Max, and have working examples of swapping them out without modifying anything other than the bootstrap config file.

I have some of my own doubts / concerns about the best way to express this goal of the framework given that we haven't fully fleshed out all of the long-term implementation details yet, so I appreciate the feedback and am definitely willing to tweak some things about how I have these docs organized right now, but I do think that this goal is central enough to the ideas behind the framework that I don't really want to *entirely* banish the documentation to the "hopes and dreams" section.