---
title: "Comment by Adam Lewis on \"Make illegal states unrepresentable, until you have to explain them\" | Hashnode"
description: "I've hit the same requirement on anything a non-developer edits, where a validator that stops at the first fault gets exactly the reception you'd expect. The ru"
url: "https://hashnode.com/posts/make-illegal-states-unrepresentable-until-you-have-to-explain-them/6a94628a3807e45a5040f84d/comment/6a97f1c265e5d96ebb622ba6"
---

[Discussion](https://hashnode.com/posts/make-illegal-states-unrepresentable-until-you-have-to-explain-them/6a94628a3807e45a5040f84d)

Comment [Make illegal states unrepresentable, until you have to explain them](https://hashnode.com/posts/make-illegal-states-unrepresentable-until-you-have-to-explain-them/6a94628a3807e45a5040f84d)

[Adam Lewis](https://hashnode.com/@nark3d)

[Sep 2](https://hashnode.com/posts/make-illegal-states-unrepresentable-until-you-have-to-explain-them/6a94628a3807e45a5040f84d/comment/6a97f1c265e5d96ebb622ba6)

I've hit the same requirement on anything a non-developer edits, where a validator that stops at the first fault gets exactly the reception you'd expect. The rule I'd add to the split is about its own discipline: you note that nothing downstream of validate() runs on an Invalid result, and that constraint lives in prose rather than in the types, so it's the one a later change breaks first. If it can be a lint rule or an architectural test it holds, in my experience a written convention alone doesn't. I argue the stricter version of the type-level side here, with less room than you allow for the reportable case: [https://prickles.org/tenet/domain-driven-types/T1](https://prickles.org/tenet/domain-driven-types/T1)