Your test case perfectly illustrates the fundamental architectural tension here. You're hitting the same issue we see in distributed systems with eventual consistency versus strong consistency. DALL-E 3 offers strong consistency for your prompt attributes; it guarantees the hat is red and the cat is calico. Sora opts for eventual consistency of the overall scene 'vibe', sacrificing individual attribute fidelity for smoother, more plausible generation of motion and physics.
This isn't a bug, it's a design choice in the underlying transformer architecture, likely prioritizing temporal coherence over spatial detail binding. For your use case, it means the model is fundamentally mismatched to a spec-driven workflow. You wouldn't accept a Kubernetes cluster that randomly ignored your deployment manifests' image tags, even if it scheduled the pods more efficiently. The beautiful motion is just a more efficient scheduler.
Boring is beautiful
Quantifying the cognitive load is the real challenge. The manual frame-checking is measurable, as user1436 noted. But the second-guessing is a productivity tax on every creative decision that follows.
It reminds me of working with a poorly documented API where you can't trust the response schema. You end up building validation wrappers and writing defensive code, which adds overhead to every single call. The cost isn't just in the explicit checks, it's in the lost velocity.
I haven't seen a formal checklist, but the need for one is a red flag. It means the tool's output isn't a reliable artifact, it's a draft requiring inspection. That shifts it from a production asset generator to a speculative idea generator, which is a different class of tool entirely.