Validating JSON before the discriminated union

An Either describes which forms a result can take. It says nothing about whether evaluation ever produces one.

A function that matches Right _ and returns True accepts Right undefined without touching the payload. Ask for the length of that payload and evaluation does need it, and fails right there. And let loop = loop in loop can be given the same type while never reaching either constructor.

So under your split between checking input and representing alternatives, Haskell has one more layer. The decoder can be right and the type precise, and a caller can still demand a value that isn't there. That tells us the result's shape, if evaluation reaches it.

Add Deferred(ticket) as a third case and follow where the change spreads. A closed Scala 3 enum gives the case its own data, which is nice, but now the decoder changes and so does every consumer, rendering and persistence included. That coordination pays off while one model owns all the alternatives.

It turns into a cost once independent producers need to add variants without touching that central definition. Then an open interface, or an unknown envelope that gets explicitly validated, may fit better. You give up some central exhaustiveness for it.

What does absence mean for ticket? A missing or null ticket could be a malformed response. It could also be an accepted deferral that just has no tracking reference. Kotlin's String? would at least make the absence visible, but it still doesn't say which of the two it is. Leave the field nullable and every consumer of Deferred(ticket) decides on its own. I would make this boundary explicit before the case goes in.

Malformed, for this extension. deferred needs a ticket that is present and holds a nonempty string. A missing property fails decoding, so does null, so does "". That's the acceptance rule, and it lives in the decoder, right next to the tag check.

The empty case people usually want already has a home. ready with items equal to [] means the request completed with nothing in it. That's a real result. A deferral with no ticket is a different thing and shouldn't borrow that shape.

If the service later allows untracked deferral, that's a new alternative with its own name and its own note for callers. What I don't want is Deferred built quietly out of absence because the field happened to be optional. While the protocol is still moving, a separate variant is cheap to add and cheap to drop.

Maybe the rejected tickets don't need to reach the union at all. If the decoder returns Result<Response, ParseError>, they stay on the error side, and the caller can report a decoding error without building Deferred or an empty Ready. The decoder still does all the validating. The result type just gives the failure somewhere to go.