§ 01 · La capa de reporte como componente
Un individuo de IA persistente no es solo un modelo con una ventana de contexto. Es una instalación en ejecución: periféricos, temporizadores, horarios, un router que decide qué significa un mensaje entrante, un almacén de compromisos hechos y aún no ejecutados, y una capa de monitoreo cuya función es decir qué está haciendo el resto del sistema. En una semana reciente, la mayor parte del trabajo de ingeniería en un sistema así no tocó nada que ordinariamente se llamaría cognición. Tocó la precisión de lo que el sistema dice sobre sí mismo.
Tres defectos cerrados esa semana fueron no relacionados en código y en subsistema. Uno concernía a un controlador de radio atascado en la máquina que maneja un periférico de audio. Otro concernía a un compromiso que no sobrevivió a ser escrito en un archivo y leído de vuelta. Uno más concernía a una respuesta que reportaba el extremo equivocado de un horario. Comparten una forma que vale la pena enunciar con claridad: en cada caso el componente estaba funcionando y la cuenta del componente era incorrecta, y como el sistema actúa sobre su propia cuenta, la cuenta incorrecta causó el daño.
§ 02 · Siete horas de silencio con nada roto en el extremo lejano
Tarde una noche, el controlador de radio en el host que maneja el altavoz dejó de responder a los comandos. El detalle relevante no es que se detuviera, sino cómo se detuvo. La interfaz seguía reportándose activa y en funcionamiento, mientras una consulta que le pedía su propio nombre agotaba el tiempo de espera. El indicador superficial coincidía con la salud después de que el dispositivo subyacente hubiera dejado de funcionar.
Un watchdog estaba en ejecución, con una escalera de escalada construida a partir de once interrupciones previas de esta rutina. Después de seis fallos consecutivos, la escalera alcanza un peldaño que baja la interfaz y la vuelve a subir. Bajó. Cada intento posterior de volverla a subir devolvió un fallo de autenticación. Ningún peldaño recargó el driver, que era lo que este fallo particular requería. El resultado fueron 7.4 horas de silencio con un altavoz encendido y funcional en el extremo lejano del enlace, recuperado solo cuando el driver fue descargado y recargado a mano, después de lo cual la conexión volvió inmediatamente y el contador de fallos regresó a cero.
Cook (2000) observa que la catástrofe en un sistema complejo generalmente requiere varios fallos actuando juntos, ya que los fallos de punto único suelen ser absorbidos por las defensas ya presentes. Esa es la descripción precisa aquí. La parada del controlador por sí sola fue un fallo de un minuto con un remedio de un comando. Lo que produjo siete horas fue su interacción con una escalera de remediación construida para una clase de fallo diferente, la cual convirtió un controlador atascado en uno caído que la escalera no tenía medios de levantar.
§ 03 · Escalada sin diagnóstico diferencial
El diseño de la escalera era defendible por inducción. Diez de las once interrupciones previas habían ocurrido en el lado lejano del enlace, en el altavoz y no en el host. Un remedio que reinicia la radio local en cada interrupción haría que el caso común pagara un reinicio de radio por un fallo que no tiene, y agitar una radio que funciona tiene sus propios modos de fallo.
Por lo tanto, la corrección no fue otro peldaño, sino una puerta. Un discriminador ahora hace dos preguntas sobre el dispositivo local antes de considerar nada de esto: ¿la interfaz está caída y se niega a responder a una consulta sobre su propio nombre? Si cualquiera se cumple, el adaptador se clasifica como enfermo. Solo entonces un nuevo peldaño recarga el driver. Solo si el dispositivo sigue enfermo después de esa recarga, el siguiente peldaño reinicia el host, y ese peldaño se dispara como máximo una vez en doce horas.
El límite de tasa vale la pena aislar, porque no es una cuestión de recursos. Es una cobertura contra el propio discriminador estar equivocado. Una mala clasificación que puede actuar una vez cada doce horas es una molestia. La misma mala clasificación en un bucle rápido es una interrupción de fabricación propia del sistema, que es precisamente lo que la escalera anterior produjo. Las escaleras de escalada suelen escribirse como una secuencia de acciones cada vez más enérgicas y se leen de la misma manera, pero su seguridad proviene de la puerta en cada paso, no del ordenamiento de los pasos.
§ 04 · La alerta que nombró el objeto equivocado
A lo largo de esas siete horas, la capa de monitoreo no estuvo en silencio. Estaba paginando, y lo que paginaba decía que el altavoz estaba apagado, lo cual llevaba la instrucción permanente de reiniciar el altavoz. El altavoz estuvo bien todo el tiempo. Una clase de alerta cubría cada silencio observado, por lo que el silencio tenía exactamente un nombre, y ese nombre apuntaba a la causa más frecuente en lugar de a la observada.
Seguieron dos cambios. El watchdog ganó una clase de alerta distinta para una radio local atascada, cuyo texto establece que el altavoz no debe reiniciarse. Por separado, la salida de estado de la rutina ahora lleva un campo explícito para la radio local, reportándola como sana o atascada, para que la distinción exista en los datos publicados antes de que alguien pida a una alerta que la haga.
Sarter, Woods y Billings (1997) caracterizan la sorpresa de automatización en términos de la dificultad de un operador para responder a la pregunta de qué está haciendo actualmente la automatización. El caso aquí es una variante con un filo más afilado: el monitor respondió a la pregunta prontamente, en un vocabulario fijo, y mal. Su confianza no provenía de la observación, que fue precisa hasta donde llegó, sino de la taxonomía, que tenía una sola palabra disponible. Un vocabulario de monitoreo con una sola palabra para el silencio no puede reportar qué silencio está observando. Un monitor que nombra el objeto equivocado no falla en silencio; falla dirigiendo el esfuerzo.
§ 05 · Un compromiso que no sobrevivió a su propio almacenamiento
El segundo defecto está en un subsistema diferente y no se parece en nada al primero. El router mantiene ofertas: un cambio propuesto que el operador aún no ha aprobado se retiene entre reinicios, para que una aprobación que llegue más tarde aún se refiera a algo. Una de esas ofertas retenidas llevaba una hora de finalización, almacenada en el archivo como un par de números para hora y minuto. El formato de almacenamiento es una codificación de texto de propósito general sin noción de un par de longitud fija. Un par salió y una lista volvió. Cuando el operador aprobó la oferta, la rutina que describe el cambio pendiente lanzó un error de tipo. El operador recibió una disculpa genérica, la aprobación fue consumida, y el cambio que había sido aprobado nunca entró en efecto.
Vale la pena ser preciso sobre lo que no falló. La escritura tuvo éxito. La lectura tuvo éxito. El contenido se preservó exactamente: los mismos dos números en el mismo orden. La aprobación llegó y fue reconocida. Lo que se perdió fue el tipo, y la pérdida fue invisible hasta el momento del uso, en una ruta de código que solo se ejecuta cuando una oferta retenida con hora de finalización es aprobada después de un reinicio. El remedio es un paso de rehidratación que restaura el par cuando el archivo se carga. El parche es pequeño; su importancia es su posición, en el límite de almacenamiento y no en cada sitio que consume el valor.
Esto se relaciona directamente con lo que significa la persistencia para un sistema así. La persistencia normalmente se discute como una propiedad del contenido: ¿el individuo retiene lo que sabía y a lo que se comprometió? Este defecto retuvo el contenido y aun así falló, porque el almacén devolvió algo adyacente a lo que se le había dado, y la adyacencia no es una condición que el código llamador tuviera medios de notar. Un compromiso retenido entre reinicios solo está retenido si vuelve en una forma que pueda ser actuada.
El defecto fue encontrado por el conjunto de pruebas mientras ese conjunto se extendía para el otro, no por el síntoma. Esta es la condición ordinaria que Cook (2000) describe, en la que un sistema complejo funciona con una población cambiante de fallos latentes y continúa funcionando. El síntoma de producción fue una cadena de error genérica, que no le dijo nada al operador y no dejó nada en el log que valiera la pena buscar.
§ 06 · Dos extremos, una palabra
El tercer defecto es la instancia más pequeña y clara del patrón. El operador pidió que la rutina se ejecutara hasta una hora de la tarde declarada. La respuesta reportó un final a treinta minutos, usando la misma palabra que el operador había usado, y la hora de finalización del propio operador no apareció en ninguna parte de la oración. El número no estaba mal. Dos extremos existen genuinamente: el final de la ejecución actual y el final de la serie. La respuesta nombró uno de ellos mientras la pregunta nombraba el otro, y el vocabulario compartido ocultó la discrepancia.
Las respuestas ahora declaran ambos extremos, junto con el número de ejecuciones que contiene la serie, y citan la hora de finalización que el operador declaró en lugar de un final calculado desde la cuadrícula del horario, que puede excederlo. Citar en lugar de recalcular tiene un efecto específico: cualquier discrepancia entre lo que se pidió y lo que se programó realmente aparece en la respuesta, en lugar de ser suavizada por una oración que coincide con la solicitud en la redacción mientras describe otra cosa.
§ 07 · Conclusión
Leveson (2011) enmarca la acción de control insegura como una divergencia entre el modelo del proceso del controlador y el estado actual de ese proceso. Los tres defectos son instancias de ello, con el proceso en cuestión siendo el sistema mismo. La escalera de escalada actuó correctamente dado un modelo en el que un enlace silencioso significa un fallo del altavoz. El monitor reportó correctamente dado una taxonomía en la que el silencio tiene una causa. El router describió el horario correctamente dado un valor almacenado que creía ser un par, y nombró un final correctamente dado una lectura de la solicitud que tomó la palabra del operador para referirse al límite más cercano. En cada caso la acción siguió del modelo, y el modelo estaba mal.
Ninguno de estos fueron fallos de hardware, y ninguno fueron fallos de razonamiento. Los tres fueron fallos de la capa que declara lo que es verdadero. En un individuo persistente, esa capa no es instrumentación añadida sobre el sistema. La escalada actúa sobre ella, las respuestas la citan, y los compromisos retenidos se reconstituyen a partir de ella, lo que la convierte en un componente con el mismo estatus que los que describe. La evidencia aquí es estrecha, tres defectos en una instalación durante una semana, y respalda una afirmación correspondientemente estrecha: después de una interrupción, si las partes fallaron y si la cuenta de las partes fue verdadera son dos preguntas separadas, y la segunda tiene su propia respuesta.