Have guidance for when to use unschematized models, and what patterns we have available for unschematized models

This came up in a conversation with an API producer recently. I am familiar with several approaches for unschematized models, but I'm not aware of them being written down. These are what I mentioned to the API producer:

1. If your plan is that everything be self-service in the future, your API is pretty close to correct, but we would change the open types to use Edm.Untyped instead.
2. If your plan is that security providers are self-service in the future, but we may have first party support for some (even first party support for some of the bigger third party security providers), then we would probably want to schematize the ones with first party support. We wouldn't have to do this upfront, we could have a derived type for externalSecurityProvider that uses Edm.Untyped and is unschematized, and then we could have derived types for all of the first party supported ones (and these derived types can be backfilled at a future time).
3. If your plan was for there to always be a manual process, then we would want to go ahead and start schematizing the known security providers.
4. If your plan was for there to always be a manual process, but we know that the schemas are so disparate that they can't be accommodated (for example, some will use JSON, some will use XML, some will use binary blobs, and/or some we just don't know format will be used) then we actually need a slightly different approach that probably uses media entities to handle the different formats that we may receive the payloads in.

It would be good to flesh out each of these patterns as individual documents, and also have a general statement somewhere about when unschematized models are allowable.

I also want to note that none of the above patterns would work for this API producer because they have no control over the third party providers, who may introduce breaking changes at any time, so we should also have a pattern to demonstrate what versioning may look like in these cases.

Start by organizing the four unschematized-model patterns described in the issue, then address the separate case where third-party providers can introduce breaking changes. Done means documenting each pattern, when unschematized models are allowable, and a versioning approach for that case.