Fail closed no es ser torpe
Cuando una acción tiene consecuencias importantes, continuar con datos incompletos puede ser peor que detenerse. El sistema necesita distinguir degradación tolerable de una condición que invalida la operación.
Bloquear con explicación
Un buen bloqueo dice qué condición faltó, qué evidencia se esperaba y qué persona puede resolverla. “No puedo” sin contexto es frustrante; “falta aprobación X sobre evidencia Y” es operacional.
La negativa también es una salida válida
Diseñar sólo el camino exitoso obliga al sistema a improvisar cuando algo se rompe. Incluir estados de bloqueo desde el contrato convierte incertidumbre y fallos en comportamiento previsto.
Bloquear debe ser un estado explícito
Un error genérico no distingue una falla técnica de una decisión deliberada de no continuar. Estados como evidencia insuficiente, autoridad requerida o dependencia no disponible permiten que operadores y automatizaciones sepan qué tipo de intervención corresponde.
No completar huecos con imaginación
Cuando falta un dato crítico, un modelo puede producir una respuesta plausible de todos modos. La arquitectura necesita reconocer qué campos o fuentes son obligatorios para una conclusión y evitar que fluidez lingüística sustituya el requisito.
Escalar con contexto útil
Un bloqueo productivo explica qué condición falta, qué se intentó y qué evidencia permitiría continuar. La persona que recibe el caso no debería empezar de cero ni tener que interpretar un “no puedo” opaco.
La presión operacional no cambia autoridad
Que un caso sea urgente no crea mágicamente permisos ni evidencia. Puede activar una ruta de emergencia previamente definida, pero esa ruta necesita su propia autoridad y registro. De lo contrario, cada urgencia erosiona la frontera hasta volverla irrelevante.
Medir bloqueos mejora el sistema
Una gran cantidad de bloqueos correctos puede indicar una fuente inestable o un proceso que pide demasiada intervención. Registrarlos permite mejorar arquitectura sin eliminar la capacidad de detenerse. El objetivo es reducir bloqueos innecesarios, no forzar terminación.
Una prueba útil
Una forma concreta de someter esta idea a presión es construir casos donde falte deliberadamente una fuente, permiso o aprobación y comprobar que el sistema se detenga con una explicación accionable en vez de completar la tarea por otra ruta. La prueba no debería evaluar sólo si aparece una respuesta, sino qué estado queda, qué evidencia se conserva y si otro operador puede entender por qué el sistema actuó así. Ese tipo de ensayo transforma un principio editorial en una propiedad observable y permite descubrir dónde la arquitectura todavía depende de supuestos invisibles.
Lo que esta nota no afirma
Bloquear no debe convertirse en una excusa para fragilidad o mala experiencia; los bloqueos deben ser específicos, medibles y reducirse cuando el proceso puede hacerse seguro sin perder la frontera. Esta distinción importa porque una buena práctica deja de ser útil cuando se convierte en promesa universal. El objetivo es hacer explícita una frontera de diseño que pueda discutirse, probarse y adaptarse al dominio, manteniendo separados hechos, inferencias, permisos y decisiones.