Registro de cambios

oloproof 0.1.0a1 está publicado, así que el camino dorado empieza con pip install oloproof en un entorno limpio y pasa directamente a oloproof init y oloproof run. Las versiones se compilan y publican desde un commit etiquetado en CI, mediante la publicación de confianza de PyPI, sin ningún token almacenado.

Una ejecución o una comparación que se detiene antes de tiempo registra ahora cada consulta que hizo, y el workbench las reproduce: el intervalo válido en todo momento estrechándose en cada consulta frente a un umbral que no se mueve, y la consulta en la que cada regla decidió. Solo dibuja intervalos que el motor registró. Un intervalo de muestra fija nunca se anima como si estuviera en vivo, porque observarlo hasta que parezca bueno anula su garantía.

⌘K o Ctrl+K enumera todos los destinos que usted puede ver, y un id de ejecución o un digest de comparación pegado lo abre. g y luego una letra navega, j y k recorren las filas de una tabla, y ? enumera todos los atajos. Un caso se abre junto a su ejecución, con su cadena de evidencia y las personas que lo etiquetaron. Toda animación se detiene con movimiento reducido.

El workbench sirve ahora oloproof.com, y el camino dorado de extremo a extremo se superó en el servidor: un revisor etiquetó 80 casos que extrajo el espacio de trabajo, encontró 7 respuestas erróneas que el juez había aprobado, y el espacio de trabajo decidió Aprobado sobre su muestra verificada (91,2 %, intervalo de 74,5 % a 100,0 %) donde la ejecución enviada por sí sola tenía evidencia insuficiente. El acceso es por invitación.

oloproof collect recibe OTLP/HTTP de un SDK estándar de OpenTelemetry, ensambla spans de GenAI y OpenInference en trazas direccionadas por contenido y mantiene su contenido en su máquina; un envío sigue su política de salida de datos. oloproof traces promote convierte una traza en un caso de prueba con su procedencia y rechaza los duplicados.

Su colector firma un compromiso sobre cada traza que selló cada hora. Después, el espacio de trabajo extrae una muestra con su propia aleatoriedad y comprueba cada traza extraída frente al compromiso, de modo que una muestra no puede seleccionarse a conveniencia reteniendo trazas. oloproof traces evaluate juzga la muestra sobre sus salidas registradas, el espacio de trabajo la decide bajo la evaluación que fijó un Owner, y una secuencia de confianza sigue cada métrica a lo largo de las muestras en la página Production del proyecto.

Un Owner o Admin abre una cola y asigna revisores, que etiquetan desde el teclado: aprobado o fallido, una puntuación en una escala declarada o una preferencia a ciegas entre dos ejecuciones, cada una registrada por cuenta. El navegador del revisor obtiene el contenido de los casos de oloproof collect en su lado con un ticket firmado de cinco minutos, así que el espacio de trabajo nunca lo guarda.

Una ejecución puede firmarse con una clave de runner que registró un Owner, o con el worker gestionado. Un Owner fija la evaluación completa (suite, evaluadores, métricas y ejecución de referencia) y su política de gate, y el espacio de trabajo decide cada versión del sistema en su primera ejecución de exactamente esa evaluación, frente a la ejecución fijada. Las etiquetas humanas solo cuentan si vienen de etiquetadores independientes, contados por cuenta.

Un intervalo PPI corrige a un juez con una muestra aleatoria de etiquetas humanas, y su garantía exige una muestra que nadie haya elegido. El espacio de trabajo extrae ahora esa muestra después de que la evidencia de la ejecución quede congelada allí, se guarda la semilla para sí y comprueba el intervalo corregido con su propio motor. La página de la ejecución indica si el espacio de trabajo verificó un intervalo; una muestra extraída en su propia máquina sigue marcada como de buena fe.

Una política con early_stopping: true ejecuta los casos en lotes con semilla y detiene una ejecución, o una candidata y su referencia al unísono, en cuanto todas las reglas han decidido, lo que se registra como DECIDED_EARLY junto con los casos que no necesitó. Las tasas detenidas usan un intervalo de apuestas válido en todo momento, así que mirar después de cada lote conserva su garantía. La tasa de aprobación de un juez puede someterse a un gate sobre un intervalo PPI que combina el juez con una muestra aleatoria a ciegas de etiquetas humanas, mostrado junto a los intervalos de solo el juez y solo humanos.

Cuatro notificaciones, cada una una categoría que un miembro puede desactivar desde el propio email: un trabajo gestionado terminó o falló, una ejecución o comparación enviada cuyo gate bloquea una publicación, el uso al 80 % y al 100 % de la asignación gratuita, y un miembro que se unió. Un email de gate cita la decisión almacenada y enlaza a la ejecución, sin contenido de casos. Solo email: ni Slack, ni pager, ni webhook.

Inicie sesión con una dirección de email y una contraseña además de con un proveedor, con direcciones verificadas y restablecimientos. Una persona puede eliminar su propia cuenta: el usuario y todos los espacios de trabajo a los que solo ella pertenecía desaparecen a la vez, y el worker purga la evidencia de esos espacios de trabajo.

Un juez puede responder a una pregunta tipada (sí o no, una opción, una puntuación según niveles) con una probabilidad para cada respuesta, leída de las probabilidades de tokens de un modelo local en una sola pasada hacia delante. Su calibración se mide frente a etiquetas humanas y se registra en su entrada del registro, y una cascada envía a un juez más potente solo los casos en los que un juez barato duda. Un clasificador entrenado también puede ser un evaluador, sin clave y sin red.

Etiquete los casos de una ejecución desde un archivo o el terminal, y pruebe un juez en borrador frente a esas etiquetas antes de adoptarlo. Un juez informa de su sesgo junto a su acuerdo, uno cuyo sesgo supera un margen declarado queda excluido de los gates, y una validación deja de contar en cuanto cambia el modelo que midió. Sondas sin etiquetas comprueban si un veredicto se mueve cuando nada importante cambió, y las comparaciones por pares se plantean en ambos órdenes, de modo que una respuesta preferida solo por su posición aparece sin que nadie etiquete.

Una trayectoria registra qué agente dio cada paso, y cada traspaso. Los evaluadores juzgan el enrutamiento (si la solicitud llegó al agente que debía atenderla), los permisos de herramientas (si algún agente llamó a una herramienta que no le correspondía) y los agentes que se pasan el control de un lado a otro en lugar de terminar, y los segmentos agrupan los casos por ruta.

Una suite puede medir cada caso varias veces. Las réplicas se agregan por caso antes de cualquier intervalo, las comparaciones las emparejan como fracciones y la ejecución informa de cuántos casos discreparon consigo mismos. Un sistema puede marcar un fallo como transitorio para que el runner lo reintente: en un sistema RAG real eso recuperó 18 de 22 casos ausentes y estrechó el intervalo un 39 %.