Contenido base y variaciones

Hay dos maneras de dar a cada cliente lo que necesita. Una es copiar la regla para cada uno y editarla: es rápido al principio, pero cada mejora al contenido común hay que repetirla en cada copia, y con el tiempo las copias se parecen cada vez menos entre sí. La otra es una sola regla base con parámetros, como el umbral o una lista de exclusiones, y una variación registrada por cliente. Entonces la mejora de la lógica se hace una vez y los valores de cada cliente se conservan.

Una variación es normal. Muchas variaciones sobre la misma regla son una señal sobre la regla, no sobre los clientes. Abre variaciones y cuenta cuántas variaciones hay por regla, con cada fila como una variación distinta.

Cada variación quita o suaviza una detección para un cliente. Por eso necesita quién la aprobó y cuándo: si mañana ocurre algo que esa regla habría visto, hay que poder explicar por qué estaba apagada o relajada. Una desactivación sin aprobación es la más delicada, porque es la que más reduce lo que se ve. Mira la columna aprobada_por de variaciones.

Cuando el catálogo base mejora, cada cliente debería recibir la versión nueva. Si un cliente se queda en una versión vieja, tiene una lógica que el resto ya no usa, y las mejoras o correcciones que se hicieron no lo cubren. Compara la versión base de la regla con lo que corre en cada cliente: catalogo_base dice cuál es la vigente y versiones_desplegadas dice cuál se ejecuta.

Cuando la mayoría de los clientes cambia el mismo parámetro, a veces el valor base no representa a ninguno. En ese caso, en lugar de aceptar un umbral que casi todos reescriben, se revisa la regla: quizás el umbral debe depender del tamaño del servidor o del plan, o la regla debe medir otra cosa. Esa decisión la toma quien mantiene el catálogo, con los valores de los clientes a la vista.