yes! yes yes! yes please yes!
I feel like I'd need to talk it out to get to the exact detail of what that object is, but happy to do it. I think we can do a good job really, and already what's been written here is really smart starting point.
But yes, my vote is yes on that. We can use this really quickly in the coffee shop.
I wrote a long post... it got deleted... grf.
short... validation is the long term main benefit. Users want things to work first and not have to reinvent best practice wheels, and have flexibility second (important... but second). validation gets things to work and nicely. the structure should enable validation from day 1, and follow naming and structural norms in other places (like json schema or npm or whatever).
I agree with what Paul just said. Octavio could second, but imagine receiving a log and asking "what convention is this" with no reference... that's a LOT of validation queries. Sometimes you will have to do this, but it's time consuming.
Better to know what you SHOULD validate against by storing that in the log... then if you want to go on a wild goose chase after that, you can if needed.
I also think if we're being honest and thinking long term, the real value of conventions is in validation. As a user, do I want flexibility? Yes! But as a user do I want to know that 95% of what I need works out of the box, in a way appropriate to me, because as a farmer I don't want to also be a full time software designer but I do want to use best practices so we're not constantly reinventing the wheel? Double yes!
That requires real conventions that validate data structures and enforce (soft or hard) inside farmOS or whatever programs are being used.
Lastly... and I brought this up with Mike on the phone but I'll post here... this idea in OpenTEAM of an Ag Data Wallet is really just the registry of schemas (or little conventions, like "a tillage log"), and the ability to package schemas together with written descriptions into a convention (or big conventions, like "OpenTEAM follows all these rules together")). But in order to have this widely used, and to avoid forking unless necessary, I think we need to think up front about how a registry is assembled, where and how it's contributed to, and how to default to referencing existing schemas rather than copying them which would cause a mess.
I know that last part is a big ask and easier to talk about against an example, and we need to build out a convention for the coffee shop, so hoping to bring something to the table rather than just complaining there also :)