Reglas como datos

COADF P-8, tal como se publica: las reglas contra las que se mide una decisión son datos, el motor que las evalúa no cambia cuando cambia una regla, y un registro de decisión queda atado a la versión del conjunto de reglas que lo produjo, lo que extiende la traza de P-4 hasta la procedencia de las reglas. COADF nombra él mismo el estado de la técnica: ya existen conjuntos de reglas que pueden recargarse, con registros de decisión vinculados a su versión, y Open Policy Agent es el ejemplo evidente.

COADF retiene una parte de P-8, y lo dice en su página de principios. Nada en esta página describe esa parte. Los ejemplos usan un tema deliberadamente genérico: qué funcionalidades puede activar un entorno de despliegue.

Las reglas cambian más a menudo que el código, y por razones distintas: la orientación de un regulador, un contrato, un mercado nuevo. Cuando una regla vive en el código, cada cambio es una entrega, varios servicios se van separando y nadie puede decir qué versión de una regla produjo una decisión tomada el trimestre pasado.

El último problema es el caro. Una decisión que no puede reconstruirse no puede explicarse, y una decisión que no puede explicarse no puede defenderse.

La forma es pequeña: la aplicación pregunta a través de una interfaz que le pertenece, la interfaz consulta material de políticas versionado, y la decisión que vuelve lleva la versión de ese material.

• Una interfaz de políticas que pertenece a la aplicación. La aplicación hace una pregunta en sus propios términos, y el motor queda detrás de un adaptador.
• Material de políticas versionado. Las reglas y sus datos son artefactos con un identificador por versión, desplegados con independencia de la aplicación.
• La versión en cada decisión. El registro de decisión lleva la respuesta, la versión y lo suficiente de la entrada para reproducirla.
• Las versiones antiguas, recuperables. Una reproducción necesita el material tal como era, no tal como es.
• Evaluación reproducible. Una política que obtiene datos o lee el reloj mientras se evalúa no puede reproducirse solo a partir de su entrada y su versión. Esos hechos se pasan como entrada, y se registran.
• También el motor versionado. Una actualización del motor puede cambiar el significado: OPA 1.0 hizo obligatorias las palabras clave if y contains, por ejemplo. Se registra la versión del motor allí donde importe la reproducción.
• Fallo controlado. Una versión desconocida, una versión ausente, una respuesta mal formada o un motor inalcanzable producen un resultado que quien es responsable de la regla eligió de antemano, nunca un valor por defecto sin registrar. No hay una respuesta correcta universal: rechazar la acción es lo correcto para una regla de acceso a funcionalidades como la del ejemplo del perfil de Python; para otra decisión, quien es responsable de ella define qué significa el fallo, y registra la elección.

Opciones tecnológicas

• Open Policy Agent. Un motor de políticas de propósito general que desacopla las decisiones de política de su aplicación, con políticas escritas en Rego. Un bundle puede llevar un manifiesto con una versión, y los logs de decisiones de OPA registran la versión del bundle usada en cada decisión. Su API REST devuelve un decision_id cuando el registro de decisiones está activado.
• Tablas de reglas que pertenecen a la aplicación. Filas con una versión y un periodo de vigencia, evaluadas por código que no cambia cuando cambian las filas.
• Tablas de decisión y DMN, donde quienes son responsables de las reglas son analistas y no desarrolladores.
• Otros lenguajes y motores de políticas. OPA es aquí un ejemplo. COADF no lo exige.

• Reglas en el código, con la versión de compilación registrada en cada decisión. Viable para un sistema pequeño. Cada cambio de regla es entonces una entrega, y el motor cambia cada vez que cambia una regla, algo que P-8 excluye.
• Servicios de feature flags. Parecidos a las políticas, y a menudo sin procedencia de las decisiones: con frecuencia no se registra qué configuración de flags respondió a una petición concreta.
• Un servicio de decisiones de otro equipo, consumido a través de la misma interfaz, con la versión en su respuesta.

• El patrón da procedencia, no corrección. Una regla errónea bien versionada sigue siendo errónea.
• No cubre las partes de P-8 que COADF no publica, ni cómo una decisión de política se encuentra con cualquier otro control.
• Open Policy Agent es un motor de ejemplo. Nada de lo que aquí figura lo convierte en requisito.