Registros de modelos y control de versiones

Un registro de modelos maneja dos tipos de nombre. La versión debería ser inmutable: una vez registrada, sus archivos y su huella no cambian. El alias es un puntero que se mueve a propósito: «produccion» apunta hoy a una versión y mañana a otra. Pedir un modelo por alias es cómodo, pero el servicio se lleva lo que el alias señale en ese momento, sin saber si alguien lo movió anoche. Pedirlo por huella fija exactamente qué bytes se cargan; el alias sigue siendo útil para decidir cuál toca, pero lo que se verifica y se despliega es la huella.

Si el registro permite reemplazar los archivos de una versión ya registrada, el número deja de significar algo: «la versión tal» puede ser dos modelos distintos según el día en que se descargó. Además, la atestación que se emitió para la huella original deja de cubrir el archivo nuevo. Los eventos del registro dejan rastro de esos reemplazos: hay que buscarlos.

Mover el alias de producción es, en la práctica, desplegar: el siguiente arranque de cada servicio carga la versión nueva. Por eso en un registro sano solo lo mueve la cuenta del proceso de despliegue, y siempre con una aprobación anotada. Cualquier otro movimiento es un cambio en producción por la puerta de atrás.

Para auditar un registro conviene contar cuántas versiones no tienen una atestación que las respalde hoy. No basta con las que nunca la tuvieron: una versión cuya huella cambió después de atestarse también queda sin respaldo, porque la atestación habla de otros bytes.

Los hallazgos de esta sala tienen una causa común en la nota del historial: el registro deja hacer cosas que no debería. Un control humano después del hecho llega tarde; lo que corta el problema es que el registro mismo rechace lo indebido.