Telar y reglamentos que operan en el proceso
El libro de reglas no debería ser un oráculo remoto
Las reglas de negocio suelen presentarse como algo sencillo. Un cliente es elegible o no lo es. Una transacción pasa o falla. Una cotización recibe un descuento. Un usuario puede acceder a un recurso. Luego las reglas crecen, llegan las excepciones, el cumplimiento pide evidencia y, de repente, la comprobación simple se ha convertido en un servicio de políticas, un intérprete, una caché, un trabajo de conciliación y una reunión con el proveedor. Maravilloso. Hemos reinventado un semáforo con plan de suscripción.
Lattice parte de una idea menos teatral: el libro de reglas debería ejecutarse donde se toma la decisión. La página actual de Lattice describe un componente de Rust con licencia Apache 2.0 que compila las reglas por adelantado en un artefacto binario asignable a memoria. La evaluación es un recorrido por un árbol empaquetado dentro del proceso. El artefacto lleva sumas de comprobación. Las mismas reglas y los mismos datos se describen como productores de la misma respuesta en los objetivos compatibles. No hace falta ningún servicio adicional en el camino de una decisión. Esa es la forma útil.
Esto no es ir en contra de la gobernanza. Es lo contrario. La gobernanza se debilita cuando las reglas viven lejos de los sistemas que las usan y las explicaciones tienen que reconstruirse después. Un libro de reglas versionado, compilado, con suma de comprobación, cargado en el proceso y reproducible da a los auditores algo más concreto que «le preguntamos al servicio de políticas y dijo que no». Esa frase puede ser cierta. No es suficiente.
Compila una vez, deja de interpretar para siempre
La canalización de la página es clara: redactar, compilar, empaquetar, evaluar. Las reglas y las restricciones viven junto al código fuente y al historial de versiones. La compilación clasifica las restricciones y fija el backend del solucionador. El empaquetado produce un artefacto binario con sumas de comprobación XXH3-64 sobre la cabecera, el contenido y el archivo. La carga es una llamada al sistema, no un análisis sintáctico. La evaluación recorre el árbol empaquetado dentro del proceso. Esa secuencia importa porque convierte trabajo de ejecución en trabajo de compilación.
Los intérpretes son cómodos hasta que se interponen en cada petición. Un servicio de políticas remoto es cómodo hasta que el salto de red pasa a formar parte del presupuesto de latencia y el servicio se convierte en otra cosa que puede caerse. Un JIT es cómodo hasta que distintos hosts, versiones u optimizadores pasan a formar parte de la explicación. Lattice es deliberadamente menos dramático. Dice que el libro de reglas debería convertirse en un archivo que la aplicación pueda asignar y ejecutar de forma determinista. La ruta de la petición no debería redescubrir las reglas cada vez.
La página informa de cifras de referencia para la ruta actual del artefacto, incluida una cifra de evaluación en caliente, una búsqueda en frío después de mmap y cifras de rendimiento. Esas cifras pertenecen a la página y a su contexto de referencia, no a un mito que deba copiarse en cada versión futura. El punto de ingeniería duradero es el diseño: un artefacto empaquetado, evaluación local a la caché, sin analizador sintáctico en la ruta crítica, sin asignador de memoria en la ruta crítica y sin salto de red por decisión.
Una única API de reglas no debería ocultar la realidad del solucionador
Las reglas no son todas iguales. Algunas son comprobaciones booleanas puras. Algunas combinan lógica con aritmética. Algunas son programas lineales. Algunas necesitan decisiones con números enteros. Algunas son restricciones de dominio finito. Algunas son problemas de rutas o restricciones flexibles. Un motor de reglas serio no debería forzar cada caso a pasar por un único ojo de cerradura con forma de solucionador. Debería clasificar la regla y enrutarla al backend adecuado.
La página de Lattice agrupa SAT, SMT, LP, MIP, CP, A* y MaxSAT bajo una única API de reglas. SAT cubre reglas booleanas puras y puertas de características. SMT gestiona teorías mixtas como lógica, aritmética, arrays y vectores de bits. LP cubre optimización continua. MIP o ILP gestiona decisiones con enteros. CP gestiona dominios finitos y restricciones no lineales. A* y MaxSAT cubren problemas de rutas y de restricciones blandas. La frase de producto importante es que quien llama escribe reglas, no llamadas al solver.
Eso importa para el mantenimiento. Si cada equipo de producto escribe código de integración específico del solver, la capa de políticas se convierte en una colección de trucos locales ingeniosos. Los trucos locales ingeniosos son caros en las auditorías porque nadie recuerda qué truco era ingenioso y cuál era solo de un viernes. Una superficie de reglas clasificada da a los equipos un único lugar para inspeccionar la regla, su clase de backend, el artefacto compilado y la respuesta que produjo.
La latencia también es una regla de negocio
A los sistemas de decisión les encanta fingir que la latencia es una consideración técnica secundaria. No lo es. Si una comprobación de cumplimiento está en cada transacción, la latencia es parte del producto. Si el control de acceso está en una puerta de enlace, la latencia es parte de la seguridad. Si la fijación de precios se ejecuta en el momento de la cotización, la latencia es parte de los ingresos. Si el filtrado de fraude se ejecuta antes de la liquidación, la latencia es parte del riesgo. Una regla lenta puede ser correcta y aun así ser operativamente incorrecta.
Por eso importa la evaluación en proceso. La página actual de Lattice contrasta las comprobaciones interpretadas o remotas en escala de milisegundos con la ruta del artefacto empaquetado, y señala el coste de los saltos de red, los servicios sidecar y las brechas de auditoría. El número exacto de un benchmark es menos importante que la forma del coste. Si una petición necesita diez comprobaciones, quizá la ruta antigua sobreviva. Si una petición necesita diez mil comprobaciones, la ruta antigua empieza a ocupar espacio en el presupuesto de la petición. En ese punto, el motor de reglas ya no es un componente. Es lo que los usuarios esperan.
El beneficio operativo no es solo la velocidad. Son menos piezas móviles. Sin servicio de políticas adicional. Sin ruta de red que mantener sana. Sin proceso de parser separado. Sin caché separada que explicar. El libro de reglas está con la aplicación, dentro de la jurisdicción y el límite operativo que ya controlas. Eso es menos glamuroso que un panel de control. También es menos probable que despierte a alguien.
La respuesta de auditoría es la reproducción
Cuando un auditor pregunta por qué se denegó una decisión, la peor respuesta es un párrafo reconstruido de memoria. La segunda peor respuesta es una captura de pantalla. La respuesta útil es: esta versión del libro de reglas se ejecutó con esta entrada y produjo esta salida, aquí está el checksum del artefacto, aquí está la regla, aquí está la reproducción. Lattice está construido para hacer posible esa respuesta.
La página vincula Lattice con las decisiones automatizadas del RGPD, la transparencia de la Ley de IA de la UE, la resiliencia operativa de DORA y la garantía de la cadena de suministro de NIS2. Esas etiquetas pueden convertirse en polvo de folleto si el sistema no puede mostrar nada concreto. Lo concreto es el artefacto. Un libro de reglas compilado puede nombrarse. Un checksum puede rechazar manipulaciones. Las entradas registradas pueden reproducir la decisión. Una salida bit a bit exacta significa que la conmutación por error no debería cambiar silenciosamente una respuesta. Ejecutarse en proceso dentro de sistemas controlados ayuda a evitar el problema del servicio externo en la ruta de decisión.
Dónde encaja primero
Lattice tiene más sentido en puntos de decisión que ocurren con frecuencia y necesitan evidencia después. Comprobaciones de cumplimiento en transacciones. Precios y elegibilidad en el momento de la cotización. Decisiones de acceso en pasarelas. Detección de fraude antes de la liquidación. Comprobaciones de elegibilidad en el sector público. Puertas de suscripción en seguros. Permisos de flujos de trabajo internos. Son lugares donde un sí o un no no es suficiente. El sistema tiene que saber qué versión del sí o del no ocurrió.
También encaja en lugares donde la misma decisión debe mantenerse igual entre servidores. Una conmutación por error no debería cambiar un resultado de cumplimiento. Un despliegue regional no debería interpretar una regla de manera diferente porque una versión de biblioteca se desvió. Una reproducción de auditoría no debería necesitar que el mismo servicio alojado del proveedor siga existiendo. El libro de reglas debería ser lo bastante portable para ejecutarse donde la organización lo controle, y lo bastante explícito para que los costes de cambio sigan siendo bajos.
Por eso el código abierto también importa aquí. Un motor de reglas que participa en cumplimiento, acceso, precios o fraude no es una dependencia decorativa. Es parte del plano de control. Si nadie dentro de la organización puede inspeccionarlo, fijarlo, probarlo y mantenerlo, entonces el libro de reglas no es realmente suyo. Es autoridad alquilada.
Qué revisar antes de adoptarlo
Primero, identifique los puntos de decisión. No empiece con una migración de plataforma. Empiece con un libro de reglas que duela hoy. ¿Con qué frecuencia se ejecuta? ¿Qué protege? ¿Quién pregunta por qué? ¿Qué ocurre si el servicio está caído? ¿Qué evidencia está disponible seis meses después?
Segundo, revise la forma de las reglas. ¿Las restricciones son booleanas, aritméticas, lineales, enteras, de dominio finito, similares a rutas o blandas? ¿Qué clase de backend debería gestionarlas? Si la regla no puede explicar por qué se enruta a una familia de solucionadores, la abstracción es demasiado mágica.
Tercero, revise la disciplina del artefacto. ¿Dónde se almacena la regla fuente? ¿Qué compilación produjo el artefacto? ¿Qué checksum se cargó? ¿Qué versión de la aplicación lo usó? ¿Qué entradas se registraron? ¿Qué ruta de reproducción demuestra la respuesta? Si la respuesta está repartida entre tres sistemas y una persona llamada Jan, el libro de reglas aún no es un objeto de auditoría. Es una tradición.
La lección
Lattice es una historia de motor de reglas, pero en realidad es una historia de control. Compile el libro de reglas antes de la solicitud. Empaquételo en un artefacto que la aplicación pueda mapear en memoria. Verifique el artefacto antes de cargarlo. Enrute las restricciones a la familia de solucionadores correcta. Evalúe en proceso. Reproduzca después con la misma entrada y la misma versión del libro de reglas.
Eso no es glamuroso. Bien. Las reglas de negocio no deberían ser glamurosas. Deberían ser aburridas, rápidas, explícitas y revisables. Los sistemas de decisión importantes de una empresa no deberían depender de oráculos remotos, bucles de analizadores y arqueología de auditoría. Deberían llevar sus libros de reglas como infraestructura.
El libro de reglas no debería ser un oráculo remoto. Debería ser algo que el sistema pueda ejecutar, nombrar y reproducir.