Idea principal

Escribir "en caso de conflicto entre un cliente y un proveedor, damos prioridad al cliente" no describe ninguna funcionalidad, ninguna pantalla, ningún workflow. Es precisamente lo que le da alcance a la frase: influirá en las reglas de reembolso, las políticas de litigio, los mensajes de soporte, las prioridades de producto y la comunicación al cliente, porque no se ha comprometido con ninguno de ellos.

La altitud es, por tanto, una propiedad funcional, no una cuestión de estilo. Una regla formulada al nivel del caso — "en este recorrido, este botón hace esto" — ya no se traslada a otra parte; tiene la forma de una especificación y no tiene su precisión. Una regla formulada al nivel del tipo de situación — "en este tipo de situación, esto es lo que aplicamos" — se deja derivar por gente que no estaba en la discusión, sobre casos que nadie había previsto.

El control es fácil de aplicar: si el documento empieza a decir qué hay que construir, ha abandonado su nivel y se convierte en una especificación disfrazada, menos útil que una especificación de verdad.

Por qué es importante

Esto da una prueba de relectura para cualquier documento de decisión: buscar en él los verbos de fabricación. Su presencia indica que el nivel ha resbalado.

Protege también del error inverso, más raro pero real: una regla tan general que no relega nada — "buscamos el mejor equilibrio entre cliente y proveedor" — no ha cambiado de nivel, ha dejado de ser una regla.

Matices y límites

Algunas reglas solo existen encarnadas: una exigencia de cumplimiento normativo o una restricción regulatoria se formula al nivel del comportamiento esperado, y subirla a principio la vuelve inaplicable.

Y la altitud no garantiza nada por sí sola: una regla al nivel correcto pero desconocida por los equipos no es derivable, solo está bien redactada.

Preguntas abiertas

• ¿Cómo comprobar, si no es con el uso, que una regla escrita es efectivamente derivable sobre casos que sus autores no tenían en mente?