Ситуация с вводом данных пользователем. Допустим, обязательное поле заполнено. Вся заявка прошла проверку. Но означает ли это, что в ней появились нужные и корректные сведения?   Представим: разработанная форма требует код проекта. Часть обращений, составленных по этой форме, возникает ещё до его присвоения. Чтобы отправить заявку, сотрудник выбирает условный код, а настоящий контекст объясняет получателю в письме.   Система видит правильную заявку. Люди продолжают обрабатывать исключение - только теперь за пределами системы.   В такой ситуации легко потребовать строгого соблюдения правила. Но если реальную задачу нельзя описать без выдуманного значения, одной дисциплиной проблему не решить.   Мне кажется важным различать ошибку ввода и случай, для которого правило не предусмотрено. В первом случае нужно помочь человеку внести корректные сведения. Во втором - дать заявке допустимый путь дальше.   Практический пример такого подхода есть в GOV.UK Design System. Для поиска адреса по индексу предусмотрена рекомендация оставлять ручной ввод: адрес может быть иностранным, отсутствовать в справочнике или быть записанным неверно. Там также отмечено, что службе, регулярно работающей с международными адресами, поиск по британскому индексу может вообще не подходить.   Это описание практики проектирования, а не отчёт об измеренном эффекте внедрения. Но оно показывает полезное различие: отсутствие значения в справочнике ещё не означает, что пользователь сообщает неверные данные.   С заявкой я бы рассматривал несколько вариантов. Если код не нужен для первого шага, можно запросить его позже. Если без него нельзя принять решение, нужен отдельный маршрут ожидания или уточнения. Если допустимость случая зависит от обстоятельств, должно быть понятно, кто вправе их оценить.   Хорошее правило не обязано заранее описывать всю жизнь. Но оно должно позволять честно сообщить, где перестаёт работать.   Это не приглашение разрешить любой обход. Свободное поле «другое» без дальнейшей обработки тоже может спрятать проблему. Важно, чтобы исключение было видно, имело причину и попадало к человеку, который способен с ним разобраться.   При этом не каждую редкость стоит превращать в отдельную автоматизацию. Иногда понятный ручной маршрут дешевле сложной ветки в программе. А если один и тот же случай возникает регулярно, возможно, пора пересмотреть основное правило, а не бесконечно оформлять разрешения.   Я бы проверял не только долю успешно отправленных заявок. Ещё стоит посмотреть, сколько после них приходит поясняющих писем, сколько значений приходится исправлять и где сотрудники пользуются общим условным кодом.   Такие признаки сами по себе не доказывают плохую форму. Но дают повод спросить, какую реальную работу она не умеет описывать.   На мой взгляд, стандартизация помогает тогда, когда уменьшает неопределённость для участников. Если она лишь заставляет скрывать неопределённость ради прохождения проверки, порядок становится аккуратнее на экране, а не в работе.   А встречались ли вам формы, которые можно заполнить только с помощью условного значения? Что оказалось разумнее: исправить правило, выделить исключение или изменить сам процесс?