El cumplimiento no es un anexo del producto
Cuando la misma regla de cumplimiento está escrita en varios lugares, divergen. Dónde vive el dueño de las nuestras, dónde todavía quedan copias, y por qué no publicamos el umbral.
Agricultura Evolutiva
En casi todos los sistemas de gestión que hemos visto, el cumplimiento llegó después. Primero se construyó lo que había que hacer —inscribir, entregar, cobrar— y más adelante alguien pidió un semáforo, una alerta o un reporte. Ese orden deja una marca: las reglas quedan repartidas.
El resultado típico es que el mismo criterio está escrito en cuatro lugares. En el backend, que decide si deja pasar una operación. En la interfaz, que pinta un aviso. En la planilla que alguien mantiene aparte para la reunión mensual. Y a veces también en el sitio web de la empresa que vendió el software.
Cuatro enunciaciones de la misma regla es lo mismo que no tener regla. En cuanto una cambia, las otras tres quedan viejas y nadie sabe cuál es la buena.
Un dueño en la interfaz, y el resto son consumidores
En nuestro producto los criterios de cumplimiento viven en un módulo propio. Ese módulo define los umbrales, los plazos y las precedencias con que se avisa, y es el único lugar de la interfaz donde están escritos: ninguna pantalla decide por su cuenta cuándo advertir. Es autocontenido a propósito —funciones puras, sin dependencias de la interfaz—, de modo que no se pueda «arreglar» un criterio adentro de un componente.
El color y la etiqueta son otra cosa: son presentación, y por eso viven fuera de ese módulo. Pero acá la propiedad es más floja, y en un artículo sobre dueños únicos corresponde decirlo. La traducción de nivel a color no tiene un dueño único: está repartida en dos módulos de presentación —uno traduce los niveles del cupo, el otro los de las vigencias—, y en el segundo la misma correspondencia entre nivel y color aparece escrita dos veces, en dos funciones hermanas. Hoy coinciden. Lo único que impide que mañana no coincidan es que alguien lo note al revisar.
Esa primera copia es barata: si dos módulos se desalinean, un nivel se ve de dos colores distintos y se nota mirando. La segunda es la incómoda, y es la que le da valor al resto. Uno de esos umbrales está escrito dos veces: una en el módulo de criterios y otra, con el mismo valor, en el servicio del backend que valida lo mismo. Están alineadas a mano, y el propio módulo lo dice en un comentario. Ahí no hay nada que se vea: la interfaz avisa una cosa, el backend decide otra, y el día que alguien cambie una sola de las dos nadie se entera hasta que un socio queda del lado equivocado. Lo contamos porque un artículo sobre dueños únicos que se presentara a sí mismo como resuelto sería otra enunciación del problema, no su solución.
Hay un detalle que nos gusta especialmente. Cuando no hay dato suficiente para determinar un nivel —falta una fecha, no hay un tope calculable—, el módulo devuelve «sin nivel», y la interfaz muestra el dato crudo sin barra y sin advertencia. Nunca inventa un nivel intermedio para que la pantalla se vea completa. Un semáforo que se pone en verde porque le falta información es peor que no tener semáforo.
Una regla enunciada en dos lugares son dos reglas. Una de las dos va a quedar vieja, y nadie va a saber cuál.
Por qué este artículo no trae los umbrales
Podríamos escribir acá cuántos días antes se avisa, o a partir de qué porcentaje del cupo aparece la advertencia. Sería buen material de marketing y sería exactamente el error que acabamos de describir: una quinta enunciación de la regla, en una página que nadie va a actualizar cuando el criterio cambie.
Así que no. Los umbrales viven en el código que los aplica, que es donde se pueden cambiar y donde se ven las consecuencias de cambiarlos. Lo que sí podemos contarte de este lado es cómo está construido, que es lo que estás leyendo.
El cupo, y un control que falla abierto
El caso más interesante es el del cupo del período, porque tiene una condición. El tope se deriva de la receta del socio: sin ese dato, no hay tope que calcular. Y cuando no hay tope, el sistema no inventa uno: deja pasar la operación y el control sigue siendo el operador.
Es un control que falla abierto. Se puede discutir si esa es la decisión correcta —nosotros creemos que sí, porque un tope inventado sobre datos incompletos es peor que ninguno—, pero lo que no se puede es esconderlo. Un cliente que compra pensando que el techo se aplica siempre va a descubrir el matiz en el peor momento posible.
Por eso lo decimos en la página de plataforma, lo decimos acá y lo decimos en una demo: hay controles que bloquean y hay controles que informan, y cuál es cuál lo define ese módulo. No prometemos cumplimiento automático. El sistema deja el registro y avisa; la decisión, y la responsabilidad, siguen siendo de la organización.
Lo que gana la operación
Cuando el cumplimiento es parte del producto y no un anexo, pasan dos cosas concretas. La primera es que el equipo deja de mantener una planilla paralela, que era donde de verdad vivía el criterio. La segunda, menos obvia: las conversaciones cambian. En vez de discutir si el aviso está bien pintado, se discute si el criterio es el correcto —y esa sí es una conversación que vale la pena tener, porque se resuelve en un solo lugar.
Escribimos como equipo y firmamos como Agricultura Evolutiva: lo que se publica acá es la posición de la empresa sobre cómo construimos, no una columna de opinión. Si algo de lo que leíste no calza con tu operación, escríbenos y lo conversamos.
