Operación de la aplicación autónoma - Hasta dónde se ejecuta la IA y dónde deciden los humanos

1. 1 Ciclo Diario

Comience a tiempo y vaya en el siguiente orden. No hay punto de partida para que la gente dé instrucciones cada vez.

1. ObservaciónLea el movimiento de la consulta de búsqueda, el dibujo real del sitio, el libro mayor de ejecución, el costo y la fecha límite para la información de calificación. Si hay un problema que no se ha resuelto el día anterior, recógelo desde allí.
2. PlanSeleccione solo 1 para hacer ese día. Dado que el procedimiento se especifica como "1 Sesión 1 Acción", no producimos más de uno junto.
3. ImplementaciónCortar la rama, cambiarla y emitir un PR. La ruta es la misma para cualquier código, artículo o configuración.
4. VerificaciónCI convierte la inspección de las especies de 83 (para todos los 83, se ha medido que "se caerá si lo rompes deliberadamente"). No se fusionará a menos que pase. Esto también incluye la inspección de expresiones exageradas y el examen de la aritmética del libro mayor.
5. shipmentSolo se fusiona la confirmación en el momento de la verificación. Fusionar = Lanzamiento de producción. Sin embargo, esto es solo en el lado del sitio, y la aplicación iOS es una ruta diferente (§2).
6. MediciónEscriba la línea 1 en el libro mayor con el ID de ejecución de lo que se ha enviado. Inicio, resultado, PR, intervención y costo se enumeran en la misma línea.
7. Volver al siguiente juicioLos tiempos de fracaso se registran para cada tipo de fracaso, y la propuesta después del día siguiente lo lee. Una inspección que detecta los momentos en los que no se escribió el libro mayor también se agrega más tarde (§7).

2. División de responsabilidades - Aquellos que pueden ser emitidos inmediatamente y aquellos que pasan el examen

Si explicas este 2 como un "despliegue automático" de 1, suena más fuerte que la situación real. Escribiré por separado.

Observaciones de Lane B: 2026-08-11–10-09, según el registro de la aplicación. Se etiquetaron 85 versiones; 17 de ellas aparecieron en App Store: 5.7.6 / 5.7.8 / 5.7.11 / 5.8.0 / 5.8.1 / 5.8.2 / 5.8.4 / 5.8.5 / 5.8.9 / 5.8.17 / 5.8.26 / 5.8.46 / 5.8.54 / 5.8.57 / 5.8.66 / 5.9.9 / 5.9.11. Hay registros de pruebas en dispositivos físicos para 5 versiones. El registro comenzó el 2026-08-28, por lo que de las versiones anteriores solo podemos afirmar que no hay registros; el método de verificación se indica en el registro de cada versión. La existencia de un registro por sí sola no demuestra una verificación autónoma en un dispositivo físico. Las observaciones de estado guardadas permitieron acotar el momento de publicación de 6 versiones. La autoría de IA representa el 20.2 % de los commits y el 8.2 % de las líneas modificadas entre versiones. Usamos el mismo método que para la autoría de código en §3: los commits sin firma, tráiler ni rastro de Claude Code se cuentan como humanos, de modo que los cambios introducidos desde el entorno local con la firma del propietario no aparecen aquí como IA. Observar que una versión está publicada no demuestra que la IA realizara las pruebas físicas, la presentación a revisión o la publicación. Estas 17 versiones no están incluidas en las «entregas» de §1.

La tabla de autoridad tiene el área 19, de la cual 15 está en funcionamiento y 10 es un sistema de aprobación. Las operaciones reversibles se realizan solo con IA, y se aprueban las operaciones irreversibles. CI solo está mirando los puntos 3 de "¿No se requiere el área irreversible para la aprobación", "El área en funcionamiento apunta al archivo base" y "Si el área donde se mueve la cantidad tiene un límite superior", y la máquina no puede ver si la persona realmente lo ha aprobado o no. Está escrito en la parte delantera.

Separamos «retirar» y «ampliar» una misma función en ámbitos distintos: aunque se revierta una ampliación, no se puede hacer que quienes ya la vieron dejen de haberla visto. Sin embargo, todavía no se ha ejecutado ni 1 promoción a través de este control. Hay 1 indicador en despliegue gradual, tf04_progress. El control emite una decisión cada hora, pero permanece en hold porque no se alcanza la muestra necesaria de 30 por grupo: observación 2026-08-27, ejecución 33076125334. El 2026-09-02 corregimos la fila «Ampliar», que antes decía «Aprobación humana». El propietario había activado la promoción automática el 2026-08-28 mediante auto_promote.enabled de rollout-promotion.json. La tabla de permisos autoriza la ejecución por IA, con controles automáticos, hasta una exposición del 50 %. La página conservaba una descripción antigua que sugería más intervención humana de la real. Subestimar también es una discrepancia: al abrir la tabla de permisos contigua se leía algo distinto. Por eso lo corregimos.

3. Medición real - Cuántas veces te moviste y cuántas personas entraron

La tasa de intervención humana 25.0% se libera como está. Hay personas en la ejecución de 4 veces y 1 veces. Sin embargo, este número es el recuento de "si una persona tocó 1 veces para la ejecución", y se intervendrá todo el día en que la configuración del flujo de trabajo sea solo re-1. Así que la intervención se divide por tipo.

Todos los 19 enviados fueron escritos por AI. La intervención real es un punto de "reparación base" 14.3%, y también fue AI quien escribió la reparación. Lo que los humanos hicieron fue darse cuenta de que estaba roto y decirle que lo arreglara.

Por vía de ejecución: principal 5/12; secundaria de respaldo 14/16. La principal es un flujo programado. Hizo su primera entrega el día 23 del mes 8 y posteriormente tuvo ejecuciones sin resultado y fallos por el límite semanal de uso. La secundaria también falló 2 veces. Hubo varios días que se habrían detenido sin redundancia. Se registraron 2 días sin ejecución: días 16 y 17 del mes 8. «Actividad consecutiva» significa días seguidos con un resultado registrado, incluidos los descartes previos y los fallos. Los días no_run y sin registro interrumpen la racha; las entregas se cuentan por separado. Con esta definición, la racha actual es de 59 días. El máximo también es de 59 días, de 2026-8-18 a 2026-10-15. «Actual» se refiere a la última fecha registrada: 2026-10-15. Un fallo que genera una fila cuenta como día registrado y no rompe la racha de actividad. La racha actual de entregas es de 0 días y el máximo de entregas consecutivas es 8 días, entre 2026-9-1 y 2026-9-8. La actualización de recuperación del día 1 del mes 10 fue mantenimiento solicitado por el propietario. Conservó los resultados sin artefactos de los días 20 del mes 9 y 1 del mes 10, verificó correcciones existentes y vinculó el registro de reparación. No cuenta como publicación periódica exitosa ni entrega sin intervención. Los registros de recuperación de los días 16 y 17 del mes 9 también corresponden a mantenimiento solicitado; no a operación periódica, entrega sin intervención ni publicación de artículos. El día 17 del mes 9 se verificaron 1 correcciones de navegación interna. La prueba de póster y su reversión forman 1 ciclo que no alcanzó el criterio de velocidad. Los resultados de tareas no recuperados siguen siendo desconocidos y los retrasos intermitentes de renderizado no están resueltos. El día 9 del mes 9 solo se registró que el control previo evitó una ejecución duplicada: no hubo implementación ni entrega, aunque el día sí cuenta para la racha de actividad. El día 10 del mes 9 se registraron 1 ejecuciones interrumpidas tras reservar la tarea por falta de un entorno de validación y 1 ejecuciones separadas terminadas por prevención de duplicados. Ninguna cuenta como entrega. Los días 30 y 31 del mes 8, tanto la vía principal como la secundaria fallaron por el mismo límite semanal y ninguna pudo entregar.

Para el código usamos otra medida. En 3 repositorios, todas las ramas y excluyendo merges, durante 2026-08-11–08-21, la IA figura como autora del 99.5 % de los commits —193 de 194— y del 94.2 % de las líneas modificadas —46,159 de 48,976—, según el recuento de 2026-08-22. Excluimos el propio día de medición porque eleva el porcentaje: si incluimos el día 22 del mes 8, pasa de 94.2 % a 96.6 %. Los totales no coinciden al volver a contar más tarde. Como examinamos todas las ramas, las eliminadas tras un squash ya no pueden contarse. Al repetir el recuento de la misma ventana el 2026-08-26, pasó de 194 a 164 commits, 30 menos. La proporción no cambia de forma apreciable: 99.5 % a 99.4 %, con el mismo 94.2 % de líneas modificadas. Cita los totales junto con la fecha del recuento anterior.

4. Tasa de automatización - tendencia mensual y desglose por área

El grado de autonomía pasó del 12.5 % al 85.4 %. Abarca 4 meses, desde junio de 2026 hasta septiembre, y se calcula siempre sobre las mismas 192 tareas como denominador fijo. La proporción de cambios de código escritos por IA es un indicador distinto de la tasa de ejecución de las tareas. Varía de un mes a otro, y los datos de septiembre son parciales. Los valores mensuales se registran como code_ai_commit_rate / code_ai_line_rate en la evolución del grado de autonomía. Las ejecuciones de cada mes incluyen el traspaso de trabajos distintos de escribir código (elegir iniciativas, verificar, registrar y detener). La variación de las cifras causada por el cambio de denominador del 13 de septiembre se registra por separado del aumento de ejecuciones.

⚠ La medición real está en el medio de 2026 8 y 9. Antes de eso, se reconfiguró, y este indicador no se midió en ese momento. El método de conteo es acumular el "mes en el que se comprometió por primera vez el archivo de seguimiento de la tarea realizada por AI" como el mes de operación del proceso, y hay una diferencia de unos pocos días a unas pocas semanas entre la fecha adicional del seguimiento y la fecha real de operación. El denominador también se fija en el pasado con el inventario actual (tarea 192), y En ese momento, la "lista de cosas por hacer" en sí no existía. Dado que no se ha restablecido el desglose de "proposición", "ejecución de la persona" y "no iniciado" en ese momento, Solo se puede producir la tasa general de automatización en esta serie, y no se puede hacer la tendencia de la tasa de participación en la IA y la tasa de cobertura. Los datos originales se colocan como están en tendencia de autonomía, y la lista de límites está en el mismo archivo known_limits.

Inventariamos 203 tareas en 13 áreas, una por una (1), y las contamos según quién las ejecuta. Automatización total: 85.4 %; ejecución por IA: 91.1 %; participación de IA: 95.0 %; cobertura: 93.8 % (2026-09-15). Publicamos el desglose, incluidas las tareas sin iniciar. El día 15 del mes 9 incorporamos las operaciones CPP existentes a la ejecución por IA, basándonos en mediciones del mismo período de primeras descargas, visitas de página, comparadores e iniciativas simultáneas. La ejecución por IA quedó en 164/180 y el total en 164/192. La evaluación es descriptiva; no establece una mejora de adquisición ni un efecto causal. De las 164 tareas, 3 —detección de reembolsos, recuperación de pagos e información sobre incidencias— se contabilizan con el criterio indicado por el propietario: preparación operativa verificada en pruebas y vigilancia automática en producción. Aún no hemos observado el primer reembolso, recuperación de pago ni aviso de incidencia en producción. Registro al cambiar los criterios el día 13 del mes 9: criterio anterior que exigía casos reales: 159/176 = 90.34 %; antes de incorporar la preparación para recuperar pagos: 161/177 = 90.96 %; después: 162/178 = 91.01 %. Antes de preparar los avisos de incidencias: 162/178 = 91.01 %; al completar esa preparación: 163/179 = 91.06 %, unos 0.050 puntos más. El valor de referencia que excluía entonces esas 3 tareas por exigir casos reales era 160/176 = 90.91 %. Publicamos los cambios en el alcance de pruebas y criterios de puntuación, las pruebas de preparación para reembolsos, las pruebas de preparación para recuperar pagos y su alcance, y las pruebas de preparación para avisos de incidencias y su alcance. No demuestran avisos reales, recepción por todos los usuarios ni cumplimiento de obligaciones de notificación. El día 9 del mes 9 contrastamos la programación de publicaciones japonesas en X con sus resultados públicos y actualizamos el ejecutor de 1 tareas existentes. Ese mismo día contrastamos contratos, facturas, servicios prestados y pagos de 1 servicios de la empresa, y añadimos 1 tareas con excepciones documentadas sobre anticipos y categorías fiscales. El día 11 del mes 9 completamos 6 comprobaciones físicas en iPhone y Watch e incorporamos el resultado de 1 tareas. El día 12 del mes 9 confirmamos que Apple había aceptado el envío autónomo de 1342 verificado e incorporamos 1 tareas de presentación a App Review. Todavía no puntuamos la aprobación de la revisión ni la publicación en App Store. Ese mismo día completamos un simulacro de parada y restauración de Act en producción e incorporamos 1 tareas de entrenamiento. No significa que hayamos demostrado todos los mecanismos de parada ni el Kill de la aplicación. El día 13 del mes 9 establecimos el presupuesto mensual de toda la empresa y lo aplicamos a decisiones de gasto; releímos la configuración pública y las decisiones sobre casos reales. Incorporamos 1 tareas de presupuesto mensual y la ejecución por IA quedó en 161/177. No significa haber liquidado las deudas existentes ni completado el control automático de todos los pagos. Al añadir 13 tareas al inventario el 2026-08-25, la tasa bajó de 61.3 % a 58.6 %. Las implementaciones posteriores la devolvieron a 66.8 % en 2026-09-02, con el denominador de aquel momento. No se redujo lo implementado: aumentó el denominador al precisar mejor la lista de trabajo pendiente; 10 de las 13 tareas añadidas no estaban implementadas. Como limitación, las tareas no tienen la misma granularidad entre áreas y todas se cuentan con el mismo peso.

13 de septiembre, en primer lugar, organizamos el rango de puntuación. 6 casos de eventos, reclutamiento y ventas de negociación de negocios individuales que no se llevan a cabo en el negocio actual y 1 casos de envío de opiniones de reembolso que no se llevan a cabo en la política existente. En el momento de esta organización, el caso 159 de ejecución de IA permanece sin cambios, el denominador en curso ha cambiado de caso 179 a caso 176, y el objetivo total ha cambiado de caso 199 a caso 192. Alcance convencional (antes del cambio de 13 de septiembre): ejecución 159/179=88.8%, general 159/199=79.9%. La serie mensual del antiguo denominador 199 también se almacena en los datos originales. En el momento de iniciar la investigación y preparación de la actividad, o en el momento de confirmar el proyecto real y las obligaciones existentes, el lado de la IA y el lado humano serán devueltos al objetivo al mismo tiempo. La razón del caso 7 y la comparación del indicador 4 están disponibles.

5. Puntuación autónoma - "Cantidad de decisiones verificadas" en lugar de "la cantidad que se puede automatizar"

§4 es tasa de cobertura de tareas. " Digo lo que pude automatizar, pero no digo ni una palabra sobre "¿Hay un mecanismo para asegurarse de que la decisión fue correcta?" Si automatiza el 100% de las decisiones no verificadas, la tasa de cobertura será de 100%. Así que adjunté al 2026-09-04. No es una transferencia, tiene sentido que un lado se estire y el otro no, así que pondré ambos como están.

El método de conteo es "a qué capa es la prueba de contraataque (= un mecanismo que puede dejar caer el juicio)". La decisión de gestión se dividió en la capa 5, y además de la verificación de la implementación, conectamos la determinación de la elegibilidad, la liquidación del contrato de valor y la búsqueda después del vencimiento. Muestra una distinción entre la finalización de la implementación y la demostración basada en el rendimiento operativo.

La puntuación autónoma es 48.4 puntos (puntuación completa 100, 2026-10-15). La tasa de cobertura de decisión verificada solo se agrega cuando el contrato prefijo se liquida en la medición real después de la liberación. 90 superar el punto es el objetivo, y no se mostrará como logro hasta que se alcance mediante la medición real.

La recuperación comprueba todo, desde la detección anormal hasta la confirmación del estado de la producción. En principio, es imposible pasar la autoridad en áreas más peligrosas a menos que la máquina se encuentre y se rebobine después del envío. La autoridad no se expandirá hasta que salga el tiempo de rebobinado automáticamente, incluso si es 1 veces - el orden se decide como está.

Los tiempos de parada se dividieron en "capas". Hasta ahora, las veces que me quedé dormido antes de la ejecución, las veces que no ejecuté y las veces que el marco se acabó estaban alineados como el mismo "fracaso", por lo que no pude responder "¿Elegí el camino equivocado o cómo hacerlo mal?" No pude responder porque no era un problema con el método de búsqueda, sino porque el registro estaba en la misma fila. Los resultados que no sean los envíos registrados en el libro mayor se dividen en las siguientes capas.

La más común es la capa de elegibilidad. Y no hubo otro juicio que "si hay una clave privada" hasta 2026-09-04. Lo que se hizo fue el juicio, y el juicio se registró en la operación existente, y la operación que no se pudo devolver se detuvo antes de la ejecución. No se puede crear un nuevo contrato de valor a menos que se aprueben todos los estándares 5.

El 2026-09-05 corregimos 1 registro que había confundido la falta de información de ejecución con una tarea no iniciada, tras cotejarlo con la prueba de inicio del modelo. La fila original y las pruebas se conservan en el historial de correcciones del registro operativo. El resultado del trabajo aún no está confirmado y no se cuenta como entrega ni recuperación.

También hay un dispositivo que dificulta el aumento de esta puntuación. Si relajas la prueba, la puntuación aumentará automáticamente, por lo que La puntuación permanecerá sin cambios durante el período en que se reduce el número de pruebas. Hemos establecido un límite superior a la contribución para que no crezca incluso si se produce en masa con actualizaciones detalladas que son fáciles de devolver. La tasa de fracaso no está incluida en la puntuación——Porque si el objetivo es reducir la tasa de fracaso en sí, será la presión para relajar la inspección. Y Este número no se muestra a la IA que decide hacerlo todos los días. Esto se debe a que si el instrumento está optimizado, la vida útil del instrumento terminará.

La ponderación de la puntuación de autonomía, los criterios del control de elegibilidad previo a la ejecución y la política de cobertura de los contratos de valor están fuera del ámbito que puede modificar la IA. Así evitamos que determine cómo se puntúa a sí misma. La política no registra solo datos favorables: aunque el mecanismo de contratos de valor se preparó el 2026-9-4, las 14 entregas de la vía pública no tenían ni 1 predicción registrada previamente. Por ahora solo lo contabilizamos; no bloquea las entregas. Los resultados están en el registro de elegibilidad y la evolución de la puntuación en el historial de autonomía. También publicamos los contratos de valor y pagos, el registro de madurez y exploración y las pruebas de recuperación. Los simulacros de recuperación no cuentan como éxitos en producción.

Para modificar el componente superior, la cobertura de decisiones verificadas, primero hay que decidir con qué indicadores se medirá el valor. La lista de indicadores permitidos y sus valores de referencia está en el mismo lugar. El 2026-09-04, el propietario aprobó 3 indicadores: proporción de días con entregas, proporción de días con publicaciones y número de fallos sin resolver. El 2026-09-05 también aprobó los 3 restantes: tiempo hasta detectar un fallo, coste real por 1 entrega y proporción de rechazos sin motivo registrado. La aprobación se registra por indicador y no aumenta por sí sola la puntuación. Cada referencia es la mediana de los últimos 14 días. Las medidas autónomas diarias posteriores requieren declarar un compromiso de valor antes de empezar; después de publicar, se recopilan las mediciones del periodo declarado y se evalúa el resultado. Aprobar un indicador no suma puntos. No se permite a la IA crear nuevos indicadores porque podría elegir indicadores que cambian por sí solos y aparentar que sus predicciones se cumplen.

6. Los permisos no otorgados a la IA están escritos con una razón

Lo que quiero publicar no es una lista de cosas que se pueden hacer, sino los límites. La ruta de lanzamiento de la aplicación en sí está automatizada, pero El flujo de trabajo de IA para el desarrollo no tiene la autoridad para iniciar esa cadena. La razón está escrita en el archivo de configuración.

Si tiene este permiso, la IA de la configuración que no pide confirmación llamará directamente al flujo de trabajo de envío,Se puede enviar a App Store sin humanos. No se requiere ningún uso básico para esta función: la lectura, el compromiso, el empuje, la creación de relaciones públicas y los comentarios en el repositorio, todos operan sin permiso. Si es necesario, en lugar de ampliar esta autoridad,Crear una ruta separada con un propósito limitado。 De los comentarios en el archivo de configuración del flujo de trabajo

Consulte con la máquina real antes de enviar. Primero, no después. De las reglas estrictas para los humanos en el procedimiento de liberación

7. Extracto del registro de ejecución - Deja las veces que no funcionaron en el mismo formato

El libro mayor es la línea 1 de ejecución 1. Escribe los tiempos enviados y los tiempos que fallaron en la misma columna. El siguiente es un extracto de lo real.

run_id      : ap-20260823-actions
date_jst    : 2026-08-23
route       : actions          outcome : shipped
pr          : 538              artifact: /obsidian/pricing/
repair_of   : ap-20260822-actions
note        : 主系（GitHub Actions）の初出荷。導入から12回目の定時起動で
              初めて成果物が出た。06:18→06:36 JST（約18分）。過去11回は
              10〜90秒で終わっており、所要時間そのものが「回ったが何も
              していない」との違いを示す。
              この行は主系自身が書いていない。出荷したのに台帳が
              0件のままだったのはこのため。

run_id      : ap-20260825-actions
date_jst    : 2026-08-25
route       : actions          outcome : failed
failure_class: auth_or_credential
detected_by : 副系のフォールバックが実行履歴を遡って発見
note        : 台帳に記録が無かった。成果物ゼロで落ちた回は
              「台帳を書く主体がいない」という構造的な穴がある。

Estas 2 filas, juntas, muestran nuestro estado actual. Ya hubo una primera entrega, pero sigue existiendo un hueco: si falla el proceso encargado de escribir el registro, esa ejecución no aparece. A fecha del día 2 del mes 9 quedaban 7 fallos sin resolver, ocurridos entre los días 27 y 31 del mes 8; 3 correspondían al límite semanal de uso. Los conservamos tal como están en el registro. La mediana de detección es de 13.4 horas y el máximo de 70.8; la mediana hasta la reparación es de 6.7 horas. La detección se ha vuelto más lenta que a finales del mes 8, porque el sistema principal omitió ejecuciones durante 3 días consecutivos por la mera existencia de una rama, y lo descubrimos conjuntamente el día 31 del mes 8.

8. Lo que no he podido hacer

Esta fundación no está en un estado de "todas las áreas se completan automáticamente". Organice lo que está escrito en el procedimiento e informe tal como está.

No escriba "totalmente automatizado". Lo que se puede decir es que 2 es que la IA ha hecho una estructura que puede continuar realizando operaciones diarias y que se nota cuando la automatización se detiene.

9. Los manuscritos de relaciones públicas también se califican con el mismo estéreo

La fórmula de puntuación se calibra en función de los resultados de comunicados de prensa anteriores de 5. Es una calibración de n=5 y no es una base para la extrapolación.

El que más se hundió fue el momento en que no había 1 en él. En el manuscrito de entrega, hay una inspección de que CI caerá si hay una expresión exagerada.

10 Pedrador vivo

Esta es la fuente de los números en esta página. Puedes verlo tal como es, incluyendo si se ha actualizado o no.

El costo real que se puede observar es $50.8681 (ejecución de 10, en el momento de 2026-09-02). La ejecución secundaria de 16 es no observada, no cero, porque el registro de la sesión de inicio programada no se puede leer desde el exterior. El límite superior mensual $40 es valor provisional y no se deriva de la medición real.

Esta cantidad se volvió a ingresar más tarde en 25 de agosto de 2026. Hasta justo antes, el libro mayor se mostraba como $0.8149 (ejecución 1). 23 de agosto envío 1 veces $7.2967 faltaba por completo. La razón de la omisión no es un error tipográfico, sino una estructura. Hay un mecanismo que genera la cantidad al final de la ejecución, pero el cuerpo principal que la escribe en el libro mayor es la ejecución del día siguiente, y al día siguiente se detuvo en el fallo de §7. El registro caerá en el momento en que más se necesite.

Este hueco se cerró. Una ejecución independiente, cada mañana a las 9, lee directamente el historial y lo registra. La información permanece aunque falle la ejecución del día siguiente. Pero no es perfecto. Solo escribe el tipo cuando el historial permite distinguir si fue un artículo o una reparación. Cuando no puede determinarlo, el campo queda vacío, y esas filas no se evalúan frente al límite por 1 ejecución que se describe más adelante. La fila del día 23 del mes 8 estaba precisamente así: pasó sin detectar que excedía el límite 3.6 veces; la completamos manualmente. Es un hueco del mismo tipo que el de §7: cuando falla quien escribe el registro, la ejecución no existe en él.

Ya había un problema con 1 en este $7.2967. 1 El límite superior por tiempo es $2.00. Es 3.6 veces. Aun así, no se detuvo porque no había ningún camino que ver al ejecutar el límite superior. El valor estaba escrito, y también había un mecanismo para comprobar si el valor era inconsistente, pero No había lugar para que el conductor que realmente estaba corriendo leyera el valor.

Se conectó el 25 del mes 8. Sin embargo, no puede detener una ejecución que ya está en marcha, porque el coste definitivo se conoce al terminar. Puede impedir la siguiente ejecución, 1 vez: si se supera el límite, la siguiente ejecución programada espera a que una persona lo revise. Solo se detiene el sistema principal, de modo que el sistema secundario sigue publicando mientras espera la revisión, como describen 1/6 y 10/10 de §3. Solo una persona puede levantar el bloqueo. Si la IA pudiera aprobar su propio exceso, el límite sería una mera petición. Este bloqueo aún no se ha activado en producción.