I certainly don’t have any disagreements with those precise goals! I am particularly relieved to hear about the agreement of different goals between the different projects.
That said I personally think that much of the confusion has arisen from the fact that these precise goals have been been consistently held throughout the entire thread (perhaps just due to miscommunication, perhaps due to more recent meetings ). Perhaps more importantly in my opinion the current design of posteriordb is not yet completely aligned with these goals.
For example the simplest ways to achieve these goals is a schema where every entry in the database contains a model name, unstructured model metadata (say a description of the model, references, etc), and then a list of expectands and validated expectation values (for example this is the structure of stat_comp_benchmark). Provided that the expectation values for every entry are always validated by either analytic results or Stan then the database will always be compatible with Stan no matter how it is used (moreover other communities could fork the database and add their own entries with their own validation without compromising the original Stan-centered database). In this case I would be very excited to support the inclusion into Stan as I hope I have expressed in previous threads.
Part of the problem with the current posteriordb schema is its use of the posterior package which doesn’t adhere to this particular structure, focusing more on the behavior of the pushforward distribution of each expectand instead of just the expectation value. Much of this information can be broken up into multiple expectands and included in the scheme above, but it would require not using posteriordb directly.
I think that part of the issue here arises from the dual need of communicating the final results while also storing/communicating the validation for reproducibility and transparency. In my opinion the current posteriordb implementation intertwines these two steps too much so that the user-facing schema is too influenced by how the validation is performed. One quick resolution would be to decouple these, agreeing on a common, fixed user-facing schema and then working on the implementation details (unifying the validation to the base C++ instead of using interface-specific code, defining schema for sharing samples or other intermediate results, etc) moving forwards (for example moving forward with posteriordb as a Stan project where the scope of the implementation details can be well-defined).
Thoughts?