Exactly - if you do runtime validation, you still have to somehow get the validation failures to a back-end for analysis, which would involve adding some other kind of “logging side-pipe”. It’s easier just to pass them un-validated to the Snowplow pipeline and get all the failure reporting in one place. Plus it means you have the option of recovering the failures, using Hadoop Event Recovery.
Yes - we have plans for an Iglu registry to handle that auto-generation itself - e.g. for Android/Java/Scala, your Iglu registry would also host a Maven-compatible repository containing POJOs/Scala case classes for all your entities. The ticket to follow here is Placeholder for Maven repo inside Iglu Server #88. This is useful both for enforcing correctness in your tracking instrumentation, but also for making analytics at the other end easier (e.g. writing AWS Lambda functions that operate on the data).
Thinking about this some more - there’s no reason why we couldn’t auto-generate TypeScript-compatible classes from an Iglu registry too. This would get us the same kind of correctness guarantees for the browser environment - ticket created: Placeholder for auto-generating TypeScript case classes from schemas #205.