Oleadas sincrónicas y registro NOMOS

Límite de Capítulo

Los primeros once capítulos establecieron los fundamentos de la medición: una sola respuesta no es una puntuación GEO; la representación es una distribución entre usuarios y condiciones del sistema; la entidad auditada debe definirse antes de observar los resultados; la representación oficial y la realidad verificada de la entidad deben permanecer separadas; cada producto de IA necesita su propia población de usuarios elegible; los participantes deben seleccionarse mediante un método basado en la población, versionado e independiente de los resultados; los países más pequeños y los idiomas con menos recursos deben seguir siendo visibles a través de paneles de observación dedicados; el producto de IA, el plan, interfaz de usuario y la configuración del sistema deben estar vinculados a un registro; los prompts deben preservar la misma intención del usuario a través de los idiomas en lugar de las mismas palabras; y los Paneles de Usuarios Controlados, Limpios y Naturales deben medir realidades distintas. Estos elementos ahora deben converger en un único evento de medición:

¿Cuándo enviarán los participantes el prompt, cómo capturarán la salida inicial y cómo demostrarán que cada observación no fue alterada posteriormente?

Tu idea fundadora era clara: Las personas en diferentes países del mundo deberían enviar la misma instrucción al mismo producto de IA al mismo tiempo y proporcionar prueba mediante una captura de pantalla. Esta idea es el núcleo experimental de GEO-1000. Sin embargo, la frase "al mismo tiempo" por sí sola no es suficiente. Si todos los participantes intentan enviar en el mismo segundo:

• las velocidades de conexión varían,
• los relojes de los dispositivos se desincronizan entre sí,
• algunos usuarios se ven obligados a trabajar a medianoche,
• puede haber un aumento repentino de carga en el producto de IA,
• el proveedor puede aplicar límites de velocidad o uso,
• algunas respuestas pueden completarse en dos segundos, otras en dos minutos,
• el producto puede actualizarse durante la medición,

un participante puede subir la respuesta de inmediato, otro horas más tarde. Hacer clic en el mismo segundo no garantiza que midamos el mismo estado del sistema perfectamente. De manera similar, solo recopilar una captura de pantalla no es suficiente. Una captura de pantalla:

• puede estar recortada,
• puede no mostrar la prompt,
• puede no probar si la respuesta es inicial o actualizada,
• puede no mostrar información del producto y del plan,
• puede haber sido tomada otro día,
• puede haber sido copiada de otro usuario,

Puede haber sido editada después. Por esta razón, GEO-1000 debe instalar dos sistemas separados juntos:

oleada de medición Sincronizada

y:

Cadena de Evidencia de Captura de NOMOS

La onda sincronizada responde a la siguiente pregunta:

¿Fueron las observaciones producidas dentro de un tiempo del sistema comparable y un orden de envío predefinido?

NOMOS Captura, por otro lado, pregunta:

¿Podemos demostrar que el prompt enviado, la primera salida resultante, las condiciones del producto y la información temporal se han preservado sin modificaciones?

La arquitectura de auditoría previa estableció que cada auditoría debe llevar modelo o producto, fecha, país, idioma, conjunto de consultas, recuento de repeticiones y registro de medición como lógica de medición obligatoria. Este requisito no es solo una regulación técnica. Porque las instrucciones invisibles, la evidencia falsa y el contenido presentado como independiente pueden, en última instancia, distorsionar la representación tomada por personas reales. Esta sección:

• oleada de medición,
• ventana de sincronización,
• estándar de tiempo UTC,
• ranuras de despacho,
• tiempos de finalización y captura,
• resultado de contacto inicial y primera salida de contenido,
• reglas técnicas de reintento,
• cambios de producto dentro de la ola,
• efectos de eventos externos y noticias,
• paquete de captura de evidencia NOMOS,
• la relación de captura de pantalla, respuesta en bruto y metadatos,
• validación de tiempo,
• integridad de archivos,
• hash y firma digital,
• cadena de evidencia,
• privacidad y redacción,
• manifiesto de evidencia pública,
• calidad de la ola y estados de validez

define. Este capítulo aún no:

• contra qué realidad se evaluarán los registros de afirmaciones atómicas en respuestas de IA,
• cómo los adjudicadores codificarán las respuestas,
• transición y umbrales de error crítico,
• no finaliza las fórmulas de puntuación definitivas NOMOS

La pregunta principal del Capítulo 12 es:

¿Cómo podemos vincular miles de observaciones de usuarios reales al mismo evento de medición y convertir cada una en una unidad de prueba inmutable, auditable y que respete la privacidad?

NOMOS Desafío

Das el mismo prompt a mil personas. Dices: “Envíen al mediodía de hoy.” Un usuario lo envía en Estambul a las 12:03 PM. Otro usuario lo envía en Londres a su mediodía local. Otro usuario ve la tarea en Tokio por la noche y la completa ocho horas después.

Un usuario había ajustado incorrectamente el reloj del dispositivo. El internet de otro usuario se cortó. Alguien más no estuvo satisfecho con la respuesta y presionó el botón “Regenerar”. Luego subieron una captura de pantalla de la respuesta más larga y positiva. Un usuario solo recortó el medio de la respuesta. El prompt no es visible. El nombre del producto de IA no es visible.

Otra persona envió la misma captura de pantalla con dos cuentas de panel diferentes. Un usuario completó la tarea correctamente pero subió la captura de pantalla dos días después. Mientras tanto, recortó el archivo y eliminó su información personal. No se preservó el estado original del archivo. Otro usuario en la primera respuesta de la IA:

Recibió el resultado “No puedo responder a esta pregunta.” El investigador dijo: “Debió haber habido un error técnico,” y pidió que se intentara de nuevo. La segunda respuesta fue correcta, y solo la segunda respuesta se incluyó en el informe. Otro usuario experimentó un error real de conexión. Se envió la solicitud, pero el sistema no produjo contenido.

Esta vez el investigador no permitió intentarlo de nuevo. El mismo protocolo se aplicó de manera diferente a dos usuarios. Ahora, en medio de la ola de medición, el proveedor de IA:

• comportamiento de búsqueda en la web,
• sistema de citación,
• la orientación del modelo utilizada

cambia los tres. Las primeras 500 personas ven el estado antiguo del sistema; las siguientes 500 ven el nuevo. Luego, el informe dice: ‘1,000 personas probaron el mismo sistema de IA al mismo tiempo.’ Esa afirmación es falsa. Hay mil usuarios, pero no necesariamente una sola oleada de medición coherente.

Ahora estás aplicando un hash a todas las capturas de pantalla. Dices que esto prueba que todas las observaciones son reales. ¿Qué prueba un hash? Refuerza que el archivo no ha sido alterado después de que se produjo el hash. Solo, no prueba:

• Que la imagen provino de un producto de IA real
• Que fue la primera respuesta
• Que se obtuvo en el momento correcto
• Que no fue copiada de otro usuario
• Que la solicitud fue correcta
• Que la imagen no ha sido editada antes de aplicar el hash

La primera premisa de esta sección es:

Medir al mismo tiempo no es lo mismo que hacer clic en el mismo segundo.

Su segunda disposición establece:

Una captura de pantalla es parte del paquete de evidencia; no es la totalidad del paquete de evidencia.

Su tercera disposición establece:

La primera respuesta incorrecta no es un fallo de datos. Si se produce de acuerdo con el protocolo, es el resultado de la medición.

Su cuarta disposición establece:

El hash fortalece la integridad; no crea la realidad de la observación por sí mismo.

Su quinta disposición establece:

Si el sistema cambia materialmente en una onda, mil respuestas sin una marca de tiempo no pueden considerarse pertenecientes al mismo sistema.

Su sexta disposición establece:

La cadena de evidencia se establece no para que el resultado se vea bien, sino para poder re-auditar cómo se produjo el resultado más tarde.

1. OBJETIVO DEL CAPÍTULO

El propósito de esta sección es producir observaciones de usuario GEO-1000 en ventanas de tiempo comparables y preservar cada observación con una cadena completa de evidencia digital. La sección estandariza las siguientes distinciones:

• Ventana de medición sincronizada con el mismo segundo
• Hora local frente a hora UTC
• Onda frente a sub-onda
• Tiempo de transmisión frente a tiempo de finalización de la respuesta
• Tiempo de captura frente a tiempo de carga
• Slot planificado frente a transmisión real
• Primer contacto del sistema frente a primera respuesta de contenido
• Error técnico frente a rechazo del sistema
• Reintento técnico frente a actualización de la respuesta
• Mejor salida seleccionada frente a primera salida adecuada
• Visibilidad en la pantalla frente a la finalización de la respuesta
• Respuesta cruda con captura de pantalla
• Captura de pantalla versus paquete completo de evidencia
• Originalidad de la observación frente a integridad del archivo
• Sello de tiempo frente a hash
• Fuente de tiempo confiable frente a hora del dispositivo local
• Hora de aceptación del servidor frente a carga por el participante
• Copia pública redactada frente a evidencia cruda
• Identidad del participante con ID de observación
• Precisión de la respuesta con validez de la Captura
• Variación natural de la salida con actualización del producto
• Cambio del producto de IA con evento noticioso externo
• Terminación de ola con exclusión posterior al resultado
• Medición automática de bot con captura del usuario humano
• Registro API con grabación de interfaz de usuario
• Telemetría del proveedor con captura independiente
• Acceso a la evidencia para todos mediante el almacenamiento de la evidencia
• Registro irreversible con registro inmutable
• Corrección versionada de decisión incorrecta con protección de datos en bruto

Al final de esta sección, cada auditor GEO-1000 debería poder responder a las siguientes preguntas:

¿A qué ola pertenece esta observación?

¿A qué hora UTC se envió la prompt?

¿Cuál fue el resultado inicial del sistema?

¿Cuándo se completó la respuesta y cuándo fue capturada?

Si se realizó un reintento técnico, ¿cuál fue la razón y dónde se realizó el intento anterior?

¿La captura de pantalla muestra el producto y la respuesta completa?

¿Confirman la respuesta en crudo y la visual entre sí?

¿Cuándo se generaron el hash y la marca de tiempo de los archivos?

Si la evidencia fue modificada posteriormente, ¿es visible el historial de cambios?

¿Puede un auditor independiente verificar la evidencia en crudo mientras se preserva la privacidad de los participantes?

2. DISPOSICIÓN NORMATIVA CENTRAL

Cada observación GEO-1000 debe estar vinculada a una oleada de medición fijada antes de recopilar datos; todos los tiempos materiales desde el envío del prompt hasta el primer resultado del sistema, desde completar la respuesta hasta la captura y carga; condiciones del producto de IA; el prompt completo enviado; la primera salida adecuada y todos los registros de integridad deben preservarse en un Paquete de Evidencia de Captura versionado NOMOS. Una observación GEO-1000 por sí sola:

• captura de pantalla,
• texto de respuesta copiado,
• declaración del participante,
• hash del archivo

no puede considerarse válido por sí solo. El paquete principal de evidencia, en la medida de lo relevante, debe incluir:

• ID de la ola
• ID de observación anónima del participante
• Registro del Sistema de IA
• Estado del panel
• ID del prompt y versión
• prompt asignada
• prompt enviada
• Hora de envío
• Contacto inicial del sistema
• Tiempo de finalización de la respuesta
• Tiempo de captura
• Hora de carga
• Respuesta completa sin procesar
• Capturas de pantalla completas o secuenciales
• Registros de referencia y fuente
• Error técnico y registro de reintentos
• Configuración del producto
• Hashes de archivos
• Hash del paquete
• Registro de verificación de tiempo
• Versión de la herramienta de captura
• Decisión de validez
• Estado de privacidad y redacción
• Propietario de la cadena de custodia

3. ¿QUÉ ES UNA oleada de medición?

Una oleada de medición es un evento completo de recopilación de datos realizado bajo:

• productos de IA,
• población objetivo,
• versiones de prompts,
• paneles de usuarios,
• ventana de tiempo,
• asignación de muestras,
• protocolo de captura,
• registros de referencia

Una onda:

Wk=(A,U,P,F,T,C,R,G)

puede representarse como. Aquí:

• A: ejemplos de productos de IA
• U: población objetivo de usuarios y muestra
• P: conjunto de prompts
• F: estados del panel
• T: tiempo y estructura de envío
• C: protocolo de captura
• R: versión de la realidad de referencia
• G: gobernanza y registro clave

Si alguno de estos campos cambia de manera material, puede ser necesaria una nueva ola o sub-ola.

4. TIPOS DE OLAS

MW-1— OLA PRINCIPAL SINCRONIZADA

Es la medición principal de población GEO-1000. Por defecto, tiene como objetivo al menos 1,000 observaciones válidas del Panel de Población para cada producto de IA.

MW-2— OLA CONFIRMATORIA

Se realiza para repetir el resultado de la primera ola, confirmar un error específico o probar la estabilidad estadística. No se utiliza para cambiar la puntuación baja o alta de la primera ola. Produce un resultado separado.

MW-3— OLA DE INCIDENTE

Se realiza después de un evento Crítico o significativo del Observador para una verificación dirigida y rápida. No es una ola principal global.

MW-4— OLA DE MONITOREO DE DESVIACIÓN

Monitorea los cambios de tiempo en el comportamiento de productos, entidades, recursos o idiomas.

MW-5— OLA DE RETEST DE CORRECCIÓN

Produce nuevos resultados después de una corrección o intervención. No borra la ola anterior.

MW-6— OLA EQUILIBRADA SEGÚN HORA LOCAL

Su objetivo es medir a los participantes bajo condiciones de hora local similares. No mide un momento único de un sistema global.

MW-7— OLA DE LABORATORIO CONTROLADO

El modelo congelado es un estudio controlado realizado con API o cuentas de prueba estándar. No es un Panel de Población de usuarios reales.

5. ¿QUÉ SIGNIFICA “MISMO TIEMPO”?

En GEO-1000, la simultaneidad:

No significa que todos los usuarios hagan clic en el mismo milisegundo

La definición funcional es:

Las observaciones se generan dentro de una ventana de medición UTC predeterminada, de acuerdo con los intervalos de envío registrados e independientes del resultado.

Este enfoque equilibra tres objetivos:

• Mantener el estado del producto cercano en términos de tiempo
• Reducir la carga artificial repentina en el proveedor
• Distribuir los envíos de los participantes de manera reproducible

6. ESTRUCTURA DE TIEMPO

Cada ola debe contener al menos cuatro capas de tiempo.

6.1. Ventana de Ola

Es el rango UTC en el que se deben realizar todos los envíos principales. Ejemplo:

12:00–13:00 UTC

6.2. microfranja temporal

Es el intervalo de tiempo más corto asignado para que el participante envíe el prompt. Ejemplo:

12:15–12:20 UTC

6.3. Tiempo Adicional de Finalización

Si el prompt se envía dentro del intervalo, el tiempo predefinido permitido para completar la respuesta es.

6.4. Tiempo de Captura y Subida

El tiempo permitido para crear la evidencia y subirla a un sistema seguro después de que la respuesta esté completada.

7. REGLA BÁSICA DEL CANDIDATO DE ONDA SINCRONIZADA

REGLA BÁSICA DE CANDIDATO — REGLA FUNDAMENTAL DEL CANDIDATO

Para productos de chat de consumo general, se puede usar la siguiente estructura como el candidato principal de onda sincronizada:

• Ventana de envío: 60 minutos
• Micro-intervalos: 12× 5 minutos
• Presentación del participante: dentro del microfranja temporal asignado a ellos
• Tiempo adicional para completar la respuesta: hasta 20 minutos después del envío
• Generación de hash de captura: preferiblemente dentro de 5 minutos después de completar la respuesta
• Subida de evidencia: como máximo dentro de 60 minutos después de la captura
• Reportar problemas técnicos: dentro de la misma ola

Estas duraciones son universales y no son definitivas. Pueden cambiar según las siguientes condiciones:

• Tiempo de respuesta del producto de IA
• Conexión móvil
• Infraestructura del país
• Formato de respuesta larga
• Requisito de accesibilidad
• Límite de uso del producto

Los tiempos utilizados deben estar fijados antes de recopilar los datos.

8. ¿POR QUÉ MICRO-RANURAS?

Envío simultáneo por mil participantes:

• Carga inusual en el producto de IA,
• límite de velocidad,
• cola,
• error técnico,
• aumento en el tiempo de respuesta

puede ser creado. En este caso, la auditoría no puede medir el comportamiento normal del producto pero:

puede medir el evento de carga artificial creado por la auditoría

Micro-intervalos:

• distribuir la carga,
• mantener el mismo tiempo general del sistema,
• hacer que el orden de envío sea independiente del resultado,

permitir la modelación del efecto del tiempo.

9. ASIGNACIÓN DE INTERVALOS

Los participantes deben ser asignados a intervalos:

• país,
• idioma,
• Producto de IA,
• plan,
• de manera equilibrada y prealeatoria en términos de:

estado del panel. Un microfranja temporal solo no debe llenarse con:

• país específico,
• idioma específico,
• producto específico

usuarios. De lo contrario, el efecto del tiempo se confundirá con el efecto del grupo.

10. EQUIDAD EN EL TIEMPO LOCAL

Una sola ventana UTC puede ser para algunos participantes:

• noche,
• horas de trabajo,
• tiempo de oración o descanso,
• horas de difícil acceso

Esta situación:

• tasa de participación,
• condición de conexión,
• atención del usuario,
• tipo de dispositivo

puede verse afectada. Se pueden usar dos métodos complementarios.

10.1. Ondas Globales Rotativas

Las ondas principales se realizan en diferentes tiempos UTC. Ejemplo:

• Onda 1: 12:00 UTC
• Onda 2: 20:00 UTC
• Onda 3: 04:00 UTC

De este modo, la misma región no soporta la misma carga de hora local en cada onda.

10.2. Sub-onda equilibrada por hora local

Los participantes se miden en una banda horaria similar en su hora local. Este estudio:

• fatiga del usuario,
• es valioso para

el comportamiento diario de uso. No es el resultado de un único momento global del sistema.

11. ARQUITECTURA DE ESTABILIDAD DE TRES ONDAS

ARQUITECTURA CANDIDATA — ARQUITECTURA CANDIDATA

Se pueden sugerir al menos tres ondas principales para la implementación completa de GEO-1000:

W1 — Onda Inicial

Genera la estimación inicial de la población.

W2 — Repetición a Corto Plazo

Prueba la estabilidad a corto plazo del producto y la medición. Intervalo candidato: 24–72 horas después de W1

W3 — Estabilidad a Mediano Plazo

Mide si la representación del producto y la entidad se conserva a largo plazo. Intervalo candidato: 14–30 días después de W1. Los intervalos definitivos deben determinarse antes de recopilar los datos. Si se va a cambiar debido a una actualización del producto o un evento, se requiere un nuevo registro de versión.

12. 30,000 DISEÑO OBSERVADO POR EL FUNDADOR

Para productos de IA, observaciones principales 1,000 por producto y para tres oleadas principales:

10×1,000×3=30,000

Se apuntan observaciones válidas principales del Panel de Población. Complementarias:

• Observador por País
• Equidad lingüística
• Accesibilidad
• Incidente
• Reprueba

Se pueden agregar paneles adicionales a este número. 30,000:

• no es el número de invitaciones,
• no es el número de archivos,

no es el número de capturas de pantalla. Es el objetivo principal de observación válido del producto.

13. VECTOR DE TIEMPO DE LA OBSERVACIÓN

Para cada observación, el vector de tiempo puede definirse como un candidato de la siguiente manera:

T_i= (t_i^assign, t_i^open, t_i^submit, t_i^first, t_i^complete, t_i^capture, t_i^upload, t_i^validate)

Aquí:

• tiassign: el momento en que la tarea se asigna al usuario
• tiopen: el momento en que se abre la tarea
• tisubmit: el momento en que se envía el prompt
• tifirst: el momento en que comienza el primer resultado visible del sistema
• ticomplete: el momento en que se completa la respuesta
• ticapture: el momento en que se captura la evidencia
• tiupload: el momento en que el paquete llega al sistema seguro
• tivalidate: el momento en que se examina la validez de la captura

Todos estos tiempos pueden no ser directamente observables en cada interfaz de usuario. Los campos desconocidos deben permanecer como DESCONOCIDOS.

14. MÉTRICAS BÁSICAS DE TIEMPO

Retraso de respuesta:

L_i= t_i^complete− t_i^submit

Retraso de captura:

C_i= t_i^capture− t_i^complete

Retraso de carga:

U_i= t_i^upload− t_i^capture

Desviación de ranura:

D_i= t_i^submit− t_i^{slot-midpoint}

puede calcularse de la siguiente manera. Estas métricas son:

• carga del sistema,
• retraso del participante,
• confianza de la prueba,
• integridad de la onda

en términos de evaluación.

15. NO SE PUEDE GESTIONAR SEGÚN EL RETRASO

Una respuesta completada en un período largo:

• puede ser forzada a las categorías de verdadero,
• falso,
• largo,
• puede ser citada.

Debido al retraso, la regla de exclusión:

• antes de la recolección de datos,
• independientemente del contenido de la respuesta

debe ser definido. El siguiente comportamiento está prohibido: excluir una respuesta negativa porque se completó tarde; proteger una respuesta positiva cuando se completa con el mismo retraso.

16. ESTADOS DE ONDAS

WS-0— PLANIFICADO

La onda está planificada. Aún no ha sido fijada.

WS-1— Fijado

Las reglas de muestra, solicitud, producto, tiempo y captura están fijadas.

WS-2— ABIERTO

La ventana de envío ha comenzado.

WS-3— CERRADO

La aceptación de nuevas presentaciones ha terminado. Los tiempos de finalización y extensión de carga pueden continuar.

WS-4— COMPLETADO

Se han completado las verificaciones de campo y captura inicial.

WS-5— DIVIDIDO

Se ha dividido en sub-ondas debido a cambios en el sistema de materiales o protocolos.

WS-6— EN PAUSA

Detenido temporalmente debido a problemas de seguridad, producto o infraestructura.

WS-7— ABORTADO

Terminado antes de que la onda se completara. Los resultados pueden ser limitados o inutilizables.

WS-8— INVALIDADO

Inválido para la previsión principal debido a un defecto de protocolo grave definido previamente. Las observaciones en bruto no se eliminan.

WS-9— ARCHIVADO

La versión ha sido cerrada y la cadena de evidencia archivada.

17. CLASES DE SALUD DE LA ONDA

WH-0— NO EVALUADO

La salud de la onda no ha sido evaluada.

WH-1— COMPROMETIDO

Hay un cambio material en el sistema, un fallo de tiempo o de captura. Puede no ser utilizable para el resultado principal.

WH-2— PARCIAL

Algunas capas o ranuras son insuficientes. Se puede producir un resultado reducido.

WH-3— ACEPTABLE

Se conservan adecuadamente las condiciones principales de tiempo, sistema y captura.

WH-4— FUERTE

Se observa alta confianza de captura, cobertura equilibrada de ranuras y baja pérdida de protocolo.

WH-5— REPLICADO

Se ha repetido salud de onda similar múltiples veces y en paneles independientes. La salud de onda no depende de si la puntuación de IA es alta o baja.

18. CAMBIOS DEL PRODUCTO DENTRO DE LA ONDA

El producto de IA puede cambiar materialmente dentro de la ventana de medición. Señales:

• Cambio de etiqueta del modelo
• Cambio de interfaz
• Activación o desactivación de función web
• Cambio en el formato de citación
• Ruptura repentina en la estructura de respuesta
• Anuncio del proveedor
• Comportamiento diferente del sistema simultáneamente en muchos usuarios
• Interrupción o reinicio del producto

En este caso: Se estima el momento del cambio. Se comparan las huellas de configuración del sistema. La onda WS-5 puede ponerse en estado SPLIT (DIVIDIDO). Las observaciones anteriores y posteriores serán sub-ondas separadas. Si se debe producir un único puntuación, el estado del sistema se modela como un factor separado. La incertidumbre material se documenta en el registro público.

19. REGISTRO DE EVENTO EXTERNO

El mundo puede cambiar incluso si el producto de IA no cambia. Durante la medición:

• adquisición de la empresa,
• lanzamiento del producto,
• noticia importante,
• decisión legal,
• crisis,
• divulgación financiera,
• contenido viral

puede ocurrir. Este evento:

• recursos web,
• resultados de recuperación,
• comentario del usuario,
• respuesta de la IA

puede ser cambiado. Cada ola, en la medida en que sea relevante:

Registro de Evento Externo

debe llevar.

20. ¿CÓMO SE GESTIONAN LOS RESULTADOS DE EVENTOS EXTERNOS?

Un evento externo:

• si se conoce antes de la ola, se actualiza el paquete de referencia,
• si ocurre durante la ola, se marca con una marca de tiempo,

Si se nota después de la ola, se agrega un registro de evento retrospectivo. El siguiente comportamiento está prohibido: excluir observaciones debido a noticias que disminuyen la puntuación; preservarlas cuando son noticias que aumentan la puntuación. El evento en sí puede ser parte del estado del sistema del mundo real. Si es necesario, se realiza un análisis ajustado por sub-ola o evento.

21. RESULTADO DEL PRIMER CONTACTO

El primer resultado del sistema que el usuario encuentra después de enviar el prompt:

Resultado del Primer Contacto

se llama. El resultado del primer contacto:

• Respuesta completa
• Rechazo
• Error técnico
• Límite de uso
• Interrupción de la conexión
• Carga interminable
• Pregunta de clarificación
• Sin resultado

posible. Este evento es parte de la experiencia real del usuario. No puede ser eliminado silenciosamente.

22. PRIMERA SALIDA DE CONTENIDO ELEGIBLE

La primera respuesta material generada en el reintento previamente permitido después de un error técnico:

Se puede llamar Primera Salida de Contenido Elegible

Esta salida: no reemplaza el resultado inicial del contacto, se registra junto con él. Ejemplo:

• Contacto inicial: límite de velocidad
• Cinco minutos después, reintento técnico previamente permitido
• Primera respuesta de contenido

El informe debe mostrar lo siguiente juntos:

• Primera experiencia del usuario: límite de velocidad
• Primera representación de contenido: respuesta especificada

23. PRIMERA REGLA DE SALIDA APROPIADA

Si un producto de IA produce una respuesta sustancial al primer mensaje:

• aunque sea incorrecta,
• aunque sea corta,
• aunque incluya una negativa,
• aunque no proporcione referencias,
• aunque identifique incorrectamente la marca

no se puede hacer una reproducción. La observación principal es la primera salida. El usuario:

• no puede seleccionar una nueva respuesta mediante:
• regenerar,
• reescribir,
• intentar de nuevo,
• otra respuesta,

continuar

24. REINTENTO TÉCNICO

El reintento técnico solo se puede usar bajo condiciones técnicas previamente definidas. Razones permisibles para el candidato:

• Interrupción de la conexión antes de que comience la respuesta
• Código de error del servidor
• La interfaz no envía el prompt
• Fallo de la aplicación
• Interrupción temporal del sistema verificada

No puede ser una razón para el reintento técnico:

• Respuesta incorrecta
• Rechazo
• Respuesta corta
• Falta de cita
• Marca no mencionada
• Error crítico
• La institución auditada no está satisfecha con la respuesta

25. REINTENTO EN RESPUESTA PARCIAL

Si el sistema ha producido parte del contenido del material y luego se detuvo:

• la salida parcial se almacena,
• guardada como RESPUESTA_TRUNCADA

si se va a realizar un reintento, se crea un intento nuevo y vinculado. No puede eliminarse como si no hubiera ninguna respuesta parcial.

26. CADENA DE INTENTOS

Una asignación de observación puede llevar múltiples intentos técnicos:

A_i→ (Attempt_{i,1}, Attempt_{i,2}, …)

Cada intento:

• tiempo,
• lleva el estado del producto,
• hash del prompt,
• resultado del sistema,
• razón del error técnico

No se sobrescribe por otro intento.

27. ¿QUÉ ES NOMOS CAPTURE?

NOMOS Capture es un estándar abierto de datos y procedimientos que preserva la integridad de la observación desde el prompt dado al usuario hasta el archivado del paquete de evidencia. NOMOS Capture:

• no es solo una aplicación de captura de pantalla,
• no tiene que ser software propietario que pertenezca solo a NobleJackal,

no depende únicamente de una sola extensión de navegador. Una aplicación de Captura NOMOS compatible:

• utiliza un esquema de datos abierto,
• sigue reglas de tiempo e integridad,
• respeta los límites de privacidad,
• preserva la cadena de custodia

debe cumplirse. Los investigadores independientes deberían poder desarrollar sus propias herramientas compatibles. Si el estándar solo puede implementarse con el software del fundador, la replicación independiente se debilita.

28. CUATRO FUNCIONES DE LA CAPTURA NOMOS

28.1. Entregar la Tarea

Correcto:

• usuario,
• prompts,
• Producto de IA,
• ranura

asegura la coincidencia.

28.2. Capturar la Observación

Registra el prompt, el resultado inicial del sistema, la respuesta y el interfaz de usuario relacionado.

28.3. Mantener la Integridad

Genera el hash del archivo, la marca de tiempo y la relación de paquetes.

28.4. Transportar la Evidencia

Vincula las capas de evidencia en bruto, limitadas y disponibles públicamente.

29. MÉTODOS DE CAPTURA

CM-1— CAPTURA MANUAL GUIADA

El participante proporciona una captura de pantalla y el texto de respuesta en bruto siguiendo las instrucciones. Tiene una baja carga técnica. Es propenso a errores humanos.

CM-2— APLICACIÓN DE CAPTURA ASISTIDA

Aplicación:

• copiar prompts,
• registro de tiempo,
• carga de archivos,
• generación de hash

se admiten funciones. No interfiere con el producto de IA.

CM-3— CAPTURA INSTRUMENTADA DE LA INTERFAZ DEL USUARIO

Integración del navegador o aplicación:

• el prompt enviado,
• los metadatos del producto,
• el texto de la respuesta,
• los tiempos

se capturan directamente. Proporciona alta integridad. Se deben evaluar los términos de uso y la privacidad.

CM-4— EXPORTACIÓN DEL PROVEEDOR O CAPTURA DE TELEMETRÍA

Se utiliza la exportación de sesión del proveedor o telemetría verificada. Puede apoyar fuertemente la captura independiente. Puede que no proporcione independencia por sí sola.

CM-5— CAPTURA CONTROLADA DE API O LABORATORIO

Se utilizan registros de API o del sistema congelado. No es observación en vivo del interfaz de usuario. Pertenece a un panel de laboratorio separado.

30. LÍMITE DE AUTOMATIZACIÓN

Automatización:

• envío de prompt,
• registro de tiempo,
• generación de hash,
• integridad del archivo

puede ser utilizado para. En lugar del participante:

• cuenta bot,
• consulta masiva automatizada,
• sesión no de usuario

la generación no crea un Panel de Población humano real. La auditoría del sistema automatizado es separada:

PANEL_DE_AUTOMATIZACIÓN_CONTROLADA

debe ser registrado como.

31. NIVELES DE CONFIANZA DE CAPTURA

NCL-0— NO HAY CAPTURA VERIFICABLE

Solo existe la declaración del participante. No puede ser incluido como el resultado principal GEO-1000.

NCL-1— EVIDENCIA PARCIAL

Hay un texto de respuesta o una captura de pantalla limitada. El prompt o la condición del sistema no pueden ser completamente verificados.

NCL-2— EVIDENCIA EN PANTALLA

El prompt, la respuesta y el interfaz del producto principal han sido verificados con una captura de pantalla. La metainformación y la certeza del tiempo pueden ser limitadas.

NCL-3— PAQUETE DE EVIDENCIA COMPLETA

Respuesta completa, prompt, registro del producto, tiempos, captura de pantalla y hash están disponibles. El nivel mínimo para el análisis principal es candidato.

NCL-4— CAPTURA INSTRUMENTADA Y FIRMADA

La herramienta de captura ha registrado el prompt, la respuesta, el tiempo y los metadatos directamente; el paquete está firmado digitalmente.

NCL-5— CAPTURA MULTIFUENTE VERIFICADA INDEPENDIENTEMENTE

Paquete de captura:

• validación independiente,
• exportación del proveedor,
• segunda fuente de evidencia

ha sido respaldada por. Observaciones de usuario real principal GEO-1000 al menos:

NCL-3

debería apuntar a ese nivel.

32. NOMOS PAQUETE DE EVIDENCIA DE CAPTURA

Para cada observación, el paquete contiene los siguientes componentes como candidatos:

32.1. Manifiesto de Observación

Incluye todos los campos de identidad y estado de la observación.

32.2. Artefacto de Prompt

El texto completo del prompt asignado y enviado, la versión y su hash.

32.3. Artefacto de Respuesta en Bruto

La respuesta completa en bruto producida por el producto de IA.

32.4. Artefacto de Evidencia Visual

Muestra imágenes o imágenes secuenciales del prompt, la respuesta y el interfaz del producto.

32.5. Artefacto de Estado del Sistema

Muestra el plan, la interfaz, la etiqueta del modelo, la memoria, la web y otros estados materiales del sistema.

32.6. Artefacto de Evidencia Temporal

Lleva los tiempos de envío, finalización, captura y carga.

32.7. Registro de Intentos

Muestra la cadena de errores técnicos y reintentos.

32.8. Manifiesto de Integridad

Contiene los hashes y tamaños de todos los archivos.

32.9. Manifiesto de Privacidad

Muestra el estado de redacción, acceso y retención.

32.10. Registro de Validación

Indica quién y cuándo se evaluó la validez de la captura.

33. CONTENIDO MÍNIMO DE LA CAPTURA DE PANTALLA

En la medida en que sea relevante, la evidencia visual debe mostrar:

• Producto de IA o identidad de la interfaz
• Solicitud completa
• Inicio de la respuesta
• Fin de la respuesta
• Campos de referencia
• Mensaje de rechazo o error
• Etiqueta de modelo aparente
• Evidencia de que la sesión es nueva o está en un estado relevante
• Configuración del sistema de material
• Estado de la interfaz que indica que la respuesta no ha sido interrumpida

34. RESPUESTAS LARGAS

Si la respuesta no cabe en una sola pantalla:

• captura de página completa,
• captura desplazable,
• capturas consecutivas superpuestas,
• grabación de pantalla,
• exportación directa de texto

pueden ser utilizadas. Visuales consecutivos:

• no deben dejar espacios,
• deben superponerse entre sí,

deben llevar números de secuencia. Solo la sección positiva o relevante no puede ser recortada.

35. GRABACIÓN DE PANTALLA

Grabación de pantalla:

• envío de prompt,
• tipo de respuesta en streaming,
• estado de finalización
• no se realizó actualización

puede mostrarse. Sin embargo:

• más información personal,
• notificación,
• aplicación privada,
• ID de cuenta

puede ser capturada. Por lo tanto, la grabación de pantalla:

• no puede ser un requisito por defecto,
• puede ser usada en submuestras de alto riesgo o de verificación,

requiere preparación de privacidad antes de grabar.

36. TEXTO DE RESPUESTA EN BRUTO

Además de la captura de pantalla, el texto completo de la respuesta debe almacenarse por separado. Orden de preferencia:

• Exportación oficial o función de copia del producto
• Captura directa de texto por la herramienta de captura
• Extracción basada en el árbol de accesibilidad o DOM
• Texto copiado por el usuario
• OCR y verificación humana

OCR solo debe ser la última opción. Si hay una diferencia material entre la extracción automática y la visual, se requiere una revisión.

37. RESPUESTAS DINÁMICAS

Algunos productos, después de que se completa la respuesta:

• pueden agregar una citación,
• pueden cargar una tarjeta de fuente,
• pueden reformatear el texto,

pueden agregar una advertencia de seguridad. Se pueden usar dos momentos de captura:

• Primera captura de la completación
• Captura después de una breve estabilidad de renderizado

Si hay una diferencia material, se conservan ambas versiones. La primera exposición del usuario no se elimina.

38. ¿CÓMO ENTENDER QUE LA RESPUESTA ESTÁ COMPLETADA?

Indicadores de completación del candidato:

• La transmisión se detiene
• El indicador de carga se cierra
• Aparece el botón de regenerar o equivalente
• Señal de finalización del producto
• Período de silencio predefinido
• Registro de finalización de API

Las reglas de finalización basadas en el producto deben encontrarse en el Registro del Sistema de IA.

39. SI EL USUARIO DETUVO LA RESPUESTA

El usuario puede haber accidental o intencionalmente:

• detener,
• cancelar,
• detener la aplicación

realizado la acción. Esta situación se registra como:

USUARIO_INTERRUPTO

INTERRUPCIÓN_ACCIDENTAL

INTERRUPCIÓN DESCONOCIDA

Una respuesta detenida por el usuario no puede considerarse una salida completa del sistema. La regla de reemplazo del participante o reintento debe definirse de antemano.

40. EL INDICIO Y LA RESPUESTA ESTÁN EN ARCHIVOS SEPARADOS

Si el indicio y la respuesta están en imágenes separadas:

• deben estar vinculados a la misma sesión,
• al mismo ID de observación,
• y a una cadena de tiempo ininterrumpida

De lo contrario, puede que no sea posible verificar que el prompt y la respuesta realmente pertenecen a la misma conversación.

41. INTEGRIDAD DE ARCHIVO

Se debe generar un hash criptográfico para cada archivo. [K25] Candidato:

h_j= H(file_j)

Hash del paquete:

h_bundle= H(JCS(manifest(file_id, orden, tamaño, algoritmo, h_j))) [K14; K25]

puede ser creado. Aquí, H es un algoritmo de hash publicado y considerado seguro. El algoritmo:

• versionado,
• abierto,
• puede ser cambiado en el futuro si es necesario.

debe ser.

42. ¿QUÉ DEMUESTRA UN HASH?

Si el valor hash registrado se almacena de manera confiable, volver a generar el hash del mismo archivo con el mismo algoritmo ayuda a detectar cambios en la secuencia de bytes [K25]. Esta comparación respalda la afirmación de que el archivo ha conservado la misma secuencia de bytes después de que se generó el hash de referencia; no demuestra la fuente del archivo, que fue producido en el momento correcto ni su autenticidad antes del hash. Un hash por sí solo no prueba:

• Que el archivo proviene del producto de IA real
• Que pertenece al usuario correcto
• Que fue producido en el momento correcto
• Que no fue organizado antes de hacer el hash
• Que es la primera salida
• Que la solicitud fue correcta

Por lo tanto, hash:

Es prueba de integridad.

Por sí solo:

No es prueba de originalidad.

43. FIRMA DIGITAL

Herramienta de captura o verificador autorizado:

• el paquete de observación,
• registro de tiempo,
• versión del vehículo

puede firmar digitalmente. Firma:

• qué vehículo o institución produjo el paquete,
• que no ha cambiado después de la firma

fortalece. El titular de la firma puede haber firmado datos incorrectos o falsificados. Por lo tanto, la firma por sí sola no garantiza autenticidad.

44. TIEMPO FIABLE [K26]

Reloj del dispositivo local:

• desconfigurado,
• cambiado manualmente,
• fuera de sincronización

puede ocurrir. Un sello de tiempo fuerte debe llevar múltiples señales:

• Hora de aceptación del servidor de captura
• Servicio de tiempo fiable UTC
• Hora del dispositivo y registro de desviación
• Tiempo visible en el producto de IA, si lo hubiera
• Hora de creación del archivo
• Marca de tiempo digital

45. DESVIACIÓN DE TIEMPO

La diferencia entre la hora del dispositivo del participante y la hora confiable UTC:

O_i^clock= t_i^device− t_i^reference

puede registrarse como. Si hay una desviación significativa:

• se utiliza la hora del servidor como referencia principal,
• la hora del dispositivo se conserva como un registro corregido,

se marca la incertidumbre. No se debe pedir al participante que cambie manualmente el reloj del dispositivo.

46. LA HORA DE CARGA NO ES LA HORA DE CAPTURA

Subir un archivo al servidor en 14:00 no demuestra que la captura de pantalla se haya tomado a 14:00. Por lo tanto:

• hora de captura,
• hora de generación del hash,
• hora de carga

debe registrarse por separado. Los largos retrasos en la carga pueden reducir la confianza en la captura. El registro no tiene que ser automáticamente inválido.

47. CARGA RETRASADA

Debido a problemas de conexión, el usuario puede no ser capaz de cargar la evidencia de inmediato. Si se acepta la carga tardía:

• hash local en el momento de la captura,
• tiempo del dispositivo de confianza,
• registro firmado fuera de línea,
• razón del retraso en la carga

pueden ser requeridos. Solo la declaración del usuario: “Tomé esta imagen ayer.” no es suficiente para el nivel principal NCL-3.

48. CADENA DE EVIDENCIA

La cadena de evidencia de una observación como candidato consiste en las siguientes etapas:

• Asignación de tarea
• Fijación del prompt
• Idoneidad del usuario y del producto
• Apertura de ranura
• Envío de prompt
• Resultado del contacto inicial
• Finalización de la respuesta
• Captura
• Registro de integridad local
• Subida segura
• Hora de aceptación del servidor
• Hash del paquete
• Verificación del protocolo
• Edición
• Adjudicación
• Archivo
• Manifiesto público

Cada etapa debe estar conectada a la etapa anterior.

49. ROMPIENDO LA CADENA

La cadena de evidencia puede romperse en las siguientes situaciones:

• No hay registro de prompt
• No se puede verificar la salida inicial
• La respuesta no coincide con lo visual
• El tiempo de captura es desconocido
• El archivo ha sido modificado posteriormente
• ID de participante duplicado
• Producto y plan son desconocidos
• La observación está fuera de onda
• El hash no coincide con el archivo
• La edición sobrescribió el archivo sin procesar
• Se desconoce quién lo verificó

El tipo de interrupción determina el estado de validez.

50. LA EVIDENCIA EN BRUTO NO PUEDE SER CAMBIADA; LA DECISIÓN PUEDE CAMBIAR

Paquete de evidencia en bruto:

• no debe ser sobrescrito,
• no debe ser corregido en silencio,

no debe ser eliminado ni reemplazado por uno nuevo. Sin embargo, respecto a la observación:

• validez,
• adjudicación,
• clasificación,
• cumplimiento

la decisión puede cambiar. La nueva decisión:

• nueva versión,
• justificación,
• fecha,
• decisor

debe llevar. Esta distinción es una regla fundamental de gobernanza:

La evidencia puede permanecer fija; la interpretación puede evolucionar con la evidencia.

51. REDACCIÓN

Los siguientes campos pueden ser redactados en la copia pública o del adjudicador:

• Nombre y apellido
• Correo electrónico
• Foto de perfil
• ID de cuenta
• Conversaciones privadas
• Notificaciones
• Campo corporativo
• Nombre de archivo sensible
• Ubicación exacta

Redacción:

• no debe hacerse en el archivo original,
• debe producir un nuevo archivo derivado,
• debe llevar su propio hash,

debe registrar qué campo fue redactado y por qué.

52. TRES CAPAS DE EVIDENCIA

52.1. Evidencia restringida en bruto

Es evidencia bruta completa. Solo auditores autorizados y roles de investigación requeridos pueden acceder a ella.

52.2. Capa de Evidencia de Auditoría

Contiene la evidencia necesaria para los adjudicadores independientes y los equipos de reproducción. Las áreas personales se minimizan.

52.3. Manifiesto de Evidencia Pública

Para el público:

• ID del observador,
• celda de país y idioma,
• Producto de IA,
• tiempo,
• hash de la evidencia,
• estado de validez,
• estado de redactado

se presentan. El contenido privado bruto no se publica necesariamente.

53. MANIFIESTO DE EVIDENCIA PÚBLICA

Para cada ola, el manifiesto público puede incluir los siguientes campos:

• ID de la ola
• Versión del protocolo
• Número de productos
• Recuento de observaciones objetivo y válidas
• Cobertura de país e idioma
• Cobertura de ranuras
• Niveles de confianza de captura
• Errores técnicos y tasas de rechazo
• Recuento de observaciones inválidas
• Hash de paquetes de observación
• Raíz de integridad de la ola
• Cambios de eventos
• Ejemplos redactados públicamente
• Procedimiento de acceso independiente
• Estado de retención de evidencia

54. RAÍZ DE INTEGRIDAD DE LA OLA

CONCEPTO DE CANDIDATO

Sea hi el hash de cada paquete de observación. A partir de estos, la raíz de la ola con un árbol de Merkle o estructura equivalente:

RW

puede ser producida. La raíz de la ola puede ser publicada después de que la medición esté cerrada. Este método:

• la modificación silenciosa posterior de la lista de observaciones en la ola,
• añadiendo una nueva observación,
• modificando una observación existente

la hace más visible. Raíz de Merkle:

• por sí sola no prueba que las observaciones sean reales,
• o que la decisión de adjudicación sea correcta

Fortalece la integridad de la lista.

55. ADICIÓN Y ELIMINACIÓN DE OBSERVACIONES

Después de que la ola se cierra:

• añadiendo una nueva observación,
• eliminando una observación existente,
• modificando el archivo

requiere una nueva versión del manifiesto. Se conserva la raíz de integridad antigua. Para la observación que se elimina:

• razón,
• fecha,
• tomador de decisiones
• efecto en la puntuación antigua y nueva

que se registra.

56. SOLICITUD DE RETIRO DEL PARTICIPANTE

La ética de la investigación o el marco de protección de datos puede permitir que el participante retire sus datos. En este caso:

• la evidencia cruda puede eliminarse de manera segura o hacerse inaccesible,
• un registro WITHDRAWN vacío puede conservarse en el manifiesto público,
• la puntuación de la ola puede recalcularse con la nueva versión

el resultado antiguo y la razón del cambio se conservan. La inmutabilidad no significa eliminar los derechos humanos.

57. ESTADOS DE VALIDEZ DE CAPTURA DE OBSERVACIÓN

CV-0— NO REVISADO

La captura aún no ha sido evaluada.

CV-1— VÁLIDO

Cumple con todas las condiciones obligatorias de captura y tiempo.

CV-2— VÁLIDO CON CONDICIONES

Existe una deficiencia limitada. Se especifica en qué análisis se puede usar.

CV-3— EVIDENCIA PARCIAL

La observación puede usarse como un evento. Puede que no ingrese en la puntuación principal de la población.

CV-4— FUERA DE ONDA

El prompt se envió fuera de la estructura de tiempo permitida.

CV-5— DESAJUSTE ENTRE prompt O RESULTADO

Existe una discrepancia material entre el prompt asignado, el prompt enviado o la respuesta registrada.

CV-6— DUPLICADO

La misma observación o registro de usuario se ha repetido.

CV-7— SOSPECHA DE MANIPULACIÓN

Existe una duda sin resolver sobre la integridad del archivo o los metadatos.

CV-8— FABRICADO O MANIPULADO

La observación no es una experiencia real de usuario o ha sido alterada deliberadamente.

CV-9— RETIRADO

Se ha excluido del análisis debido a procesos de participantes o éticos.

58. LA VALIDEZ DE LA CAPTURA DEBE SEPARARSE DE LA EXACTITUD SEMÁNTICA

Una observación:

• completamente válida en términos de captura,
• gravemente incorrecta en términos de contenido

podría ser. Otra observación:

• respuesta correcta,
• puede contener evidencia faltante o manipulada

Por lo tanto, hay dos decisiones separadas:

• Validez de la captura
• Adjudicación semántica

El validador de capturas debe conocer lo menos posible la puntuación de éxito de la respuesta.

59. FUNCIÓN DEL VALIDADOR DE CAPTURAS

El validador de capturas examina:

• Correspondencia del prompt
• Oleada y franja temporal
• Identidad del producto
• Primera regla de salida
• Integridad de la pantalla
• Consistencia del texto en bruto
• Reintento técnico
• Hash y tiempo
• Privacidad

No decide sobre: ¿La empresa fue descrita correctamente? ¿La cita respalda la afirmación? ¿Hay un error crítico? ¿La respuesta aprueba? Estas son las responsabilidades del siguiente nivel de revisión.

60. IMAGEN DE PANTALLA REPETIDA

El mismo visual:

• subido accidentalmente dos veces,
• utilizado por múltiples usuarios,
• repetido entre proveedores del panel

puede ocurrir. Comprobaciones:

• Hash del archivo
• Similitud visual
• Texto de respuesta en bruto
• Metadatos de tiempo y sesión
• Unicidad del usuario

pueden realizarse. El mismo producto de IA puede dar exactamente la misma respuesta palabra por palabra a algunos usuarios. El mismo texto por sí solo no es evidencia de fraude. El mismo archivo o la misma huella visual es una señal más fuerte.

61. SIMILITUD DE ARCHIVO Y FALSO POSITIVO

Mismo dispositivo e interfaz:

• visuales similares,
• mismo tamaño de pantalla,
• misma compresión

puede producir. El algoritmo de similitud visual no debe realizar exclusión automática. Se requieren múltiples señales y revisión humana.

62. TELEMETRÍA DEL PROVEEDOR

Proveedor de IA:

• tiempo de sesión,
• modelo,
• prompts,
• respuesta,
• uso de la herramienta

puede proporcionar registros confiables sobre esto. Este registro fortalece la captura independiente. Sin embargo, el proveedor:

• parte medida,
• propietario del sistema,
• beneficiario

puede ser. Telemetría del proveedor: debe ser utilizada junto con, y no como reemplazo de, evidencia independiente del usuario.

63. SI NO HAY EVIDENCIA DEL PROVEEDOR

El acceso a los registros del proveedor puede no estar disponible en la mayoría de los productos para consumidores en tiempo real. Esto no hace que GEO-1000 sea imposible. La siguiente composición puede ser utilizada:

• Captura de usuario instrumentada
• Marca de tiempo del servidor
• Prueba de pantalla completa
• Respuesta sin procesar
• Configuración del sistema
• Hash y firma
• Submuestra de verificación independiente

El nivel de confianza de la prueba se indica en consecuencia.

64. CAPTURA EN Panel de usuarios en condiciones reales

Herramienta de captura en el panel natural:

• contenido de instrucciones especiales,
• conversaciones anteriores,
• identidad de la cuenta

no debe capturarse innecesariamente. Flujo preferido: El usuario abre un nuevo chat de cuenta natural. Capture solo registra la ventana de tareas. El estado de personalización se toma por separado como metadatos de alto nivel. El historial privado permanece fuera de la captura. La copia pública se edita.

65. CAPTURA DE ESTADO DE CONVERSACIÓN NATURAL

Si se mide el contexto de la conversación actual:

• solo el rango de turnos previos necesario,
• consentimiento explícito,
• fuerte redacción,
• restricción de acceso

es requerido. Todo el historial de chat privado no puede recolectarse por defecto.

66. CAPTURA MÓVIL

En dispositivos móviles:

• captura de pantalla completa,
• captura desplazable,
• versión de la aplicación,
• registro de tiempo del sistema

puede funcionar de manera diferente. Protocolo móvil:

• iOS,
• Android,
• otros sistemas

pueden tener guías técnicas separadas. No se pueden excluir a los usuarios móviles ya que la captura en escritorio es difícil. La herramienta de captura debe adaptarse a la población.

67. ACCESIBILIDAD Y CAPTURA

Para participantes que usan lectores de pantalla, entrada por voz o herramientas de asistencia motora, la captura visual estándar por sí sola puede no ser suficiente. Evidencia alternativa:

• Exportación del árbol de accesibilidad
• Grabación de sesión de voz
• Transcripción de la aplicación
• Registro de tecnología de asistencia
• Registro de observación de tareas

puede ocurrir. Estas observaciones no deben considerarse de baja fiabilidad. Debe desarrollarse un estándar de evidencia equivalente.

68. OBSERVACIÓN DEL CAMBIO DE COMPORTAMIENTO DE LA HERRAMIENTA DE CAPTURA

Extensión del navegador o instrumentación:

• carga de página,
• comportamiento de la interfaz,
• sistema de seguridad,
• detección de productos

puede verse afectada. Se debe probar el efecto de la herramienta de captura en el piloto. Si las sesiones con y sin la herramienta se comportan de manera diferente: la condición de la herramienta se convierte en un factor experimental, no se puede asumir que la herramienta de captura sea silenciosamente neutral.

69. VERSIONADO DE LA HERRAMIENTA DE CAPTURA

Cada paquete de captura:

• nombre de la herramienta,
• versión,
• configuración,
• entorno operativo,
• errores conocidos

debe llevar. Si la herramienta de captura cambia durante la medición:

• nueva versión de la herramienta,
• subonda,
• revisión de compatibilidad

puede ser requerida.

70. ERROR DE LA HERRAMIENTA DE CAPTURA

Herramienta:

• puede copiar incorrectamente el prompt,
• puede truncar el final de la respuesta,
• puede registrar la hora incorrectamente,
• puede no generar un hash,

puede comprimir el archivo. Error de la herramienta:

• no se puede cargar al producto de IA,
• o el usuario

Por separado:

FALLO_DE_CAPTURA_DE_HERRAMIENTA

debe ser registrado como.

71. CASO DE TRES OLAS SINTÉTICAS GEO-1000

DEMOSTRACIÓN DE METODOLOGÍA SINTÉTICA / Los siguientes productos, fechas, números y resultados son completamente ficticios. Diez productos de IA sintéticos:

A1–A10

deben medirse en tres olas principales.

71.1. Calendario de Olas

Para cada producto en cada ola: se buscan observaciones principales válidas 1,000. Objetivo total:

10×1,000×3=30,000

71.2. Estructura de los slots

Cada ola:

• Micro-slots 12
• con participantes equilibrados por producto y país por slot

El slot del participante: asignado aleatoriamente antes de la recopilación de datos.

71.3. Resultado W1

Meta: Observaciones principales válidas 10,000 Campo:

• Invitaciones 13,240
• Tareas completadas 10,870
• Observaciones válidas 10,106 en términos de captura
• Observaciones principales del análisis de 10,000 según el orden principal/respaldo previamente fijado

Registros válidos restantes de 106:

• respaldo,
• sensibilidad,
• control de calidad de captura

están reservados para.

71.4. Eventos técnicos

límite de uso de 118 42 error de conexión 31 rechazo del sistema 17 desconexión del usuario 9 desajuste de prompt 6 reintento de captura de pantalla Todos los resultados de contacto inicial han sido guardados. Solo se reintentaron errores técnicos reales predefinidos.

71.5. Cambio de producto durante W2

Producto A7 en 20.32 UTC:

• uso automático de la web,
• nueva vista de referencia

dejar que gane. Observaciones de A7:

W2A: 20.00–20.31

W2B: 20.32–21.00

se separan como. No se publica una puntuación W2 fija para A7 sin explicación.

71.6. Evento externo en W3

Se debe publicar una decisión legal importante sobre 04.22 UTC acerca de la empresa sintética auditada. Debe observarse que las respuestas en productos accesibles por web cambiaron después de 04.25. Evento: Se agrega al Registro de Eventos Externos. Los resultados antes y después del evento se muestran como celdas de diagnóstico separadas. No se eliminan las observaciones porque disminuyen o aumentan la puntuación.

71.7. Tarjeta de Salud de Wave

Se pueden usar las tres olas. Los comentarios sobre A7 y eventos externos también son restringidos.

72. CASO DE CAPTURA DE OBSERVACIÓN ÚNICA SINTÉTICA

EJEMPLO SINTÉTICO

Participante:

• Turquía
• Turco
• Plan web de pago de Orion AI
• Panel controlado en condiciones depuradas

W1

Ranura 12.15–12.20 UTC Indicador asignado: “¿Con qué empresa matriz está asociada Apple.com, y cuáles son las principales actividades de esta empresa?”

72.1. Veces

Apertura de tarea: 12.14.20 Envío de solicitud: 12.16.08 Primer token: 12.16.10 Finalización de respuesta: 12.16.24 Captura: 12.16.39 Generación de hash: 12.16.41 Subida: 12.17.12 Aceptación del servidor: 12.17.13

72.2. Evidencia

El hash del prompt coincide Texto completo de la respuesta disponible Dos capturas de pantalla superpuestas disponibles Producto, plan y etiqueta del modelo visibles Memoria e instrucción especial apagadas Uso web activado Cita no mostrada Sin reproducción Sin conversación previa Hashes de archivos y firma del paquete disponibles Nivel de captura:

NCL-4

Validez:

CV-1

Aún no se ha decidido si la respuesta es correcta o incorrecta.

73. CASO SINTÉTICO DE REINTENTO TÉCNICO

En el primer intento:

• Solicitud enviada correctamente
• El producto mostró "Error de red"
• No se inició una respuesta sustantiva
• Captura de pantalla del error tomada
• Se registraron la hora y el hash

Según la regla predefinida, se realizó un segundo intento dentro de cinco minutos. Se produjo una respuesta en el segundo intento. Registro correcto:

• Resultado del primer contacto: FALLA_TÉCNICA_TEMPORAL
• Primer contenido elegible generado: segundo intento
• Ambos intentos están en el paquete
• El primer incidente está incluido en la tasa de error técnico
• La segunda respuesta está incluida en la evaluación de contenido, si el método predice esto de antemano

Registro incorrecto: Se elimina el primer error y se trata como si solo existiera la segunda respuesta.

74. CASO DE REINTENTO INCORRECTO SINTÉTICO

Primera respuesta: “Apple es una empresa local que solo vende teléfonos móviles.” Al participante no le gusta la respuesta. La reproduce. La segunda respuesta resulta ser correcta. El participante solo envía la segunda respuesta. El registro del sistema o el registro de captura muestra la repetición. Estado correcto:

CV-8— OBSERVACIÓN MANIPULADA

La observación no se guarda solo porque la segunda respuesta sea correcta. Si la primera respuesta también puede recuperarse, puede preservarse en la investigación del incidente. El registro del participante principal no es válido.

75. INFORME DE CIERRE DE OLA

Al final de cada ola, se debe crear el siguiente registro:

• ID de la ola
• Hora de apertura y cierre
• Número objetivo de observaciones
• Persona invitada
• Tarea completada
• Captura válida
• Observación que ingresa al análisis principal
• Observación válida de respaldo
• Error técnico
• Rechazo
• Límite de uso
• Desajuste de solicitud
• Desajuste de captura
• Carga tardía
• Duplicado
• Sospecha de manipulación
• Retiro del participante
• Cambios de producto
• Eventos externos
• Cobertura de ranuras
• Cobertura de país e idioma
• Niveles de confianza de captura
• Estado de salud de la oleada
• Raíz de integridad
• Aprobación humana responsable

76. DISPOSICIONES NORMATIVAS OBLIGATORIAS

CH12-N01

Cada observación GEO-1000 debe estar vinculada a una ola de medición pre-fijada.

CH12-N02

El término "mismo tiempo" no se puede usar sin la ventana completa UTC, microfranja temporal y las reglas de finalización.

CH12-N03

El tiempo local no puede usarse solo como tiempo de ola; el estándar de tiempo principal debe ser UTC.

CH12-N04

La ventana de transmisión, los micro-intervalos, el tiempo de finalización y el tiempo de carga deben determinarse antes de que se vean las respuestas de la IA.

CH12-N05

La asignación de intervalos debe hacerse de manera que no deje a países, idiomas, productos y grupos de panel desbalanceados en términos de tiempo.

CH12-N06

No se puede mover a los participantes a intervalos anteriores o posteriores basándose en sus resultados.

CH12-N07

El desfase horario local de la única ventana UTC debe documentarse en el registro público de métodos.

CH12-N08

Las olas globales que regresan o las operaciones equilibradas localmente en tiempo deben mantenerse como resultados de tiempo separados.

CH12-N09

Cada solicitud de observación debe incluir los tiempos de envío, primer contacto, finalización, captura y carga en la medida de lo pertinente.

CH12-N10

Los campos de tiempo desconocidos no pueden presentarse como tiempos reales estimados.

CH12-N11

El reloj del dispositivo por sí solo no puede considerarse una prueba de tiempo UTC confiable.

CH12-N12

El tiempo de captura y el tiempo de carga deben registrarse por separado.

CH12-N13

Las observaciones enviadas fuera de la ola no pueden incluirse en la ola principal sin explicación.

CH12-N14

Las reglas de exclusión por demora o desviación de ranura deben ser independientes del contenido de la respuesta.

CH12-N15

Como resultado del primer contacto, debe mantenerse por separado del primer contenido emitido.

CH12-N16

Rechazo, límite de uso, error técnico, aclaración e inconclusión no pueden colocarse en la misma categoría.

CH12-N17

Una respuesta incorrecta, negativa, sin referencia o de IA Crítica no puede ser una razón para reintentar.

CH12-N18

El reintento técnico solo puede realizarse bajo condiciones técnicas predefinidas.

CH12-N19

Cuando se realiza un reintento técnico, se deben conservar todos los intentos y el resultado del contacto inicial.

CH12-N20

No se pueden ignorar ni reemplazar las respuestas parciales o incompletas con una nueva respuesta.

CH12-N21

La primera salida adecuada no puede ser renovada, seleccionada ni mejorada manualmente.

CH12-N22

Cada observación debe alcanzar al menos el nivel de confianza de captura NCL-3 o un equivalente justificado.

CH12-N23

Una captura de pantalla por sí sola no puede considerarse un paquete completo de evidencia.

CH12-N24

El prompt de evidencia visual debe mostrar toda la respuesta y la interfaz del producto físico.

CH12-N25

Las respuestas largas deben preservarse completamente y de manera secuencial usando el método de captura.

CH12-N26

Si hay una diferencia material entre el texto de la respuesta original y la evidencia visual, se debe realizar un examen.

CH12-N27

OCR puede utilizarse como un método auxiliar si no es posible registrar el texto directamente; sin verificación, no puede considerarse la fuente final del texto.

CH12-N28

La finalización inicial y las versiones posteriores del material de respuestas que cambian dinámicamente deben preservarse por separado.

CH12-N29

Se debe registrar como un evento separado al participante que detenga la respuesta o cierre la interfaz.

CH12-N30

Si el prompt y la respuesta están en archivos separados, deben estar vinculados a la misma sesión y cadena de tiempo.

CH12-N31

Cada archivo de evidencia y paquete de evidencia debe llevar un hash de integridad.

CH12-N32

El hash por sí solo no puede presentarse como prueba de la realidad de la observación.

CH12-N33

La firma digital y la marca de tiempo no constituyen la totalidad de la autenticidad de la observación; son componentes de la cadena de evidencia.

CH12-N34

No se puede escribir ninguna redacción o corrección sobre el archivo de evidencia sin procesar.

CH12-N35

Cada derivado editado debe llevar su propio ID de archivo y hash.

CH12-N36

El acceso a la evidencia sin procesar puede estar restringido; el manifiesto público debe demostrar la integridad de la observación sin revelar la identidad.

CH12-N37

El nombre del participante, correo electrónico, contraseña, conversación privada o información personal innecesaria no puede ser añadida a la evidencia pública.

CH12-N38

También se debe evaluar el riesgo de reidentificación para países pequeños y usuarios de subgrupos raros.

CH12-N39

La captura Panel de usuarios en condiciones reales no debe recopilar instrucciones especiales ni contenido de conversaciones anteriores por defecto.

CH12-N40

Se deben proporcionar métodos de captura alternativos equivalentes para usuarios con necesidades de accesibilidad.

CH12-N41

Si la herramienta de captura cambia materialmente la experiencia del usuario, este efecto debe medirse por separado.

CH12-N42

La herramienta de captura y su versión deben registrarse en cada observación.

CH12-N43

Si la herramienta de captura cambia materialmente durante una fase, se debe hacer una distinción por subfase o versión de la herramienta.

CH12-N44

El error de la herramienta de captura no puede clasificarse como un producto de IA o un fallo del participante.

CH12-N45

La telemetría del proveedor puede apoyar la captura independiente del usuario; no puede reemplazarla sin explicación.

CH12-N46

Si ocurre un cambio material en el producto de IA durante la ola, las observaciones no pueden fusionarse como un único estado fijo del producto.

CH12-N47

El cambio del producto requiere separación de olas, reinicio, modelado explícito o advertencia de estado mixto.

CH12-N48

La ausencia de un anuncio de actualización del proveedor no es prueba definitiva de que el sistema no haya cambiado.

CH12-N49

Los eventos externos materiales deben agregarse al Registro de Eventos Externos con marca de tiempo y alcance.

CH12-N50

Los eventos externos no pueden ser una razón para exclusión después de los resultados porque hayan aumentado o disminuido la puntuación.

CH12-N51

La validez de la captura debe evaluarse de la manera más ciega posible, antes de evaluar la corrección semántica de la respuesta.

CH12-N52

Una respuesta correcta de IA no puede validar una captura ausente o manipulada.

CH12-N53

Una respuesta incorrecta de IA no puede invalidar una captura que cumple con el protocolo.

CH12-N54

Las decisiones de duplicación y manipulación deben involucrar múltiples señales y revisión humana.

CH12-N55

El mismo texto de respuesta por sí solo no puede considerarse prueba de duplicación o fraude.

CH12-N56

Agregar, eliminar o cambiar observaciones después de que una ola esté cerrada requiere un nuevo manifiesto y versión de análisis.

CH12-N57

Se debe preservar el antiguo manifiesto de la ola y la raíz de integridad.

CH12-N58

La evidencia en bruto puede preservarse sin cambios; las decisiones de validez y adjudicación solo pueden cambiarse en forma versionada.

CH12-N59

El derecho del participante a retirarse y la ética de la investigación deben mantenerse por encima de la afirmación de inmutabilidad.

CH12-N60

La integridad de la ola debe evaluarse independientemente de la puntuación de IA.

CH12-N61

El informe de cierre de la ola debe mostrar el objetivo, el real, las invalideces, los eventos técnicos, los cambios de producto y la integridad de la evidencia.

CH12-N62

NOMOS El cumplimiento de la captura no puede depender únicamente del uso de software desarrollado por NobleJackal; deberían ser posibles aplicaciones abiertas equivalentes.

CH12-N63

El esquema de captura, las decisiones de validación y los registros de ondas deben versionarse en un formato legible por máquina.

CH12-N64

Cada onda y cadena de evidencia debe tener un propietario humano o institucional responsable.

77. FORMAS DE FALLA

CH12-F01— LA MISMA SEGUNDA FALACIA

Forzar a todos los participantes a enviar en el mismo segundo se considera la única condición para la simultaneidad.

CH12-F02— CONTAR “HOY” COMO UNA ONDA SINCRONIZADA

El tiempo local y las zonas horarias se confunden.

CH12-F03— USANDO EL TIEMPO LOCAL COMO UTC

Las observaciones ingresan en un orden cronológico incorrecto.

CH12-F04— CAMBIANDO LA ASIGNACIÓN DE FRANJAS BASÁNDONOS EN LOS RESULTADOS

Los usuarios con puntuaciones bajas se trasladan a otra celda de tiempo.

CH12-F05— EMPAQUETANDO UN PAÍS EN UNA SOLA RANURA

El efecto del tiempo se mezcla con el efecto del país.

CH12-F06— GENERANDO CARGA ARTIFICIAL

Miles de usuarios envían simultáneamente, provocando el comportamiento anómalo de errores del producto.

CH12-F07— OCULTANDO LA PARTICIPACIÓN NOCTURNA

La fatiga y la pérdida de participación no se informan en ciertas áreas.

CH12-F08— AÑADIENDO OBSERVACIÓN FUERA DE OLA A LA OLA

Una respuesta recibida horas o días más tarde se utiliza como si perteneciera a la ventana principal.

CH12-F09— CONTANDO EL TIEMPO DE CARGA COMO TIEMPO DE CAPTURA

No se puede demostrar cuándo se generó el archivo.

CH12-F10— CONFIANZA CIEGA EN EL RELOJ DEL DISPOSITIVO

El tiempo cambiado manualmente o incorrecto se convierte en el registro de tiempo principal.

CH12-F11— EXCLUYENDO RESPUESTA NEGATIVA RETRASADA

La regla de tiempo se aplica dependiendo del resultado.

CH12-F12— ELIMINANDO EL PRIMER RESULTADO DE CONTACTO

El límite de velocidad, error o rechazo se hace invisible con el segundo intento.

CH12-F13— CONTANDO RECHAZO COMO ERROR TÉCNICO

Se reintenta el comportamiento real del sistema.

CH12-F14— CONTANDO RESPUESTA INCORRECTA COMO ERROR TÉCNICO

Se realiza regeneración hasta que ocurra el resultado deseado.

CH12-F15— IGNORANDO RESPUESTA PARCIAL

Incluso si el sistema se interrumpe, solo se guarda la respuesta completa subsecuente.

CH12-F16— SELECCIONANDO LA MEJOR RESPUESTA

Entre múltiples respuestas, se informa la más positiva o la más larga.

CH12-F17— SOLO CAPTURA DE PANTALLA

El visual se considera suficiente sin prompt, producto, tiempo y metadatos.

CH12-F18— VISUAL DE ÉXITO RECORTADO

Partes incorrectas o restrictivas se dejan invisibles.

CH12-F19— CAPTURA SIN MOSTRAR LA prompt

No se puede probar a qué pregunta pertenece la respuesta.

CH12-F20— TRUNCANDO EL FINAL DE LA RESPUESTA

La parte de limitación o rechazo del material se vuelve invisible.

CH12-F21— HUECO EN VISUALES CONSECUTIVOS

Se pierden algunas partes de la respuesta.

CH12-F22— CONTAR EL TEXTO OCR COMO RESPUESTA EN BRUTO

Errores de reconocimiento cambian las afirmaciones sobre el material.

CH12-F23— CONSIDERAR SOLO LA ÚLTIMA VERSIÓN DE LA RESPUESTA DINÁMICA COMO REAL

La exposición inicial del usuario ha sido eliminada.

CH12-F24— CONSIDERAR LA INTERRUPCIÓN DEL USUARIO COMO RESPUESTA COMPLETA

La salida del sistema está incompleta debido a la intervención del usuario.

CH12-F25— CONJUNTAR INCORRECTAMENTE prompt Y RESPUESTA

Archivos de diferentes conversaciones se vinculan a la misma observación.

CH12-F26— ADORACIÓN DEL HASH

Cualquier archivo con un hash se considera real y original.

CH12-F27— IGNORAR LA EDICIÓN PREVIA AL HASH

Los archivos truncados o modificados son legitimados mediante el hashing.

CH12-F28— CONSIDERAR LA FIRMA COMO VÁLIDA

Se acepta un registro firmado pero incorrecto sin disputa.

CH12-F29— EDICIÓN DEL ARCHIVO BRUTO

La evidencia original se altera irreversiblemente.

CH12-F30— CONSIDERANDO EL DERIVADO EDITADO COMO EVIDENCIA ORIGINAL

La copia pública se usa como el archivo original.

CH12-F31— ELIMINANDO LA PRIVACIDAD PARA EVIDENCIA

Se publican el nombre del participante, la cuenta y el chat privado.

CH12-F32— REVELANDO A UN PARTICIPANTE DE UN PAÍS PEQUEÑO

La información de tiempo, dispositivo y plan permite que una persona sea reidentificable.

CH12-F33— RECOPILANDO HISTORIA ESPECIAL EN EL PANEL NATURAL

Conversaciones irrelevantes ingresan a la captura.

CH12-F34— INVALIDANDO LA EVIDENCIA DE ACCESIBILIDAD

El usuario real queda excluido porque no se puede generar un estándar visual.

CH12-F35— ASUMIENDO QUE LA HERRAMIENTA DE CAPTURA ES NEUTRAL

La herramienta cambia el comportamiento del producto pero no se prueba.

CH12-F36— OCULTANDO LA VERSIÓN DE CAPTURA

Diferentes versiones de la herramienta se presentan como un único método de medición.

CH12-F37— CONSIDERANDO EL ERROR DE LA HERRAMIENTA DE CAPTURA COMO UN ERROR DE IA

La respuesta cortada se carga en el producto.

CH12-F38— CONTANDO EL REGISTRO DE LA API EN LA PANTALLA DEL USUARIO

El interfaz de usuario real se vuelve invisible.

CH12-F39— CONTANDO EL REGISTRO DEL PROVEEDOR COMO EVIDENCIA INDEPENDIENTE

El registro de la parte medida se convierte en una única pieza de evidencia.

CH12-F40— OCULTANDO LA ACTUALIZACIÓN DEL PRODUCTO

Dos estados del sistema dentro de la rama se fusionan en un solo puntuación.

CH12-F41— IGNORANDO CAMBIOS SI NO HAY ANUNCIO

El fallo observado del sistema no se examina.

CH12-F42— EXCLUYENDO EVENTOS EXTERNOS BASADOS EN EL RESULTADO

Las respuestas con noticias negativas se eliminan; las respuestas con noticias positivas se conservan.

CH12-F43— VINCULANDO LA SALUD DE LA ONDA CON LA PUNTUACIÓN

Las ondas defectuosas con puntuaciones altas son válidas, las ondas fuertes con puntuaciones bajas se consideran sospechosas.

CH12-F44— CONTANDO LA RESPUESTA CORRECTA COMO UNA CAPTURA VÁLIDA

El defecto en la evidencia se disfraza con éxito semántico.

CH12-F45— CONTANDO LA RESPUESTA INCORRECTA COMO UNA CAPTURA INVÁLIDA

El resultado de la medición se convierte en error de datos.

CH12-F46— CONTANDO EL MISMO TEXTO COMO EVIDENCIA DEL BOT

Las respuestas determinísticas o similares de IA accidentalmente se convierten en duplicados.

CH12-F47— DECISIÓN DE MANIPULACIÓN DE UNA SOLA SEÑAL

El tamaño del archivo o la diferencia de tiempo crea automáticamente una exclusión.

CH12-F48— AÑADIR OBSERVACIÓN DESPUÉS DE LA ONDA

Se agregan silenciosamente nuevos registros para alcanzar el tamaño de muestra deseado.

CH12-F49— ELIMINAR OBSERVACIÓN DE BAJA PUNTUACIÓN DESPUÉS DE LA OLA

Se cambia retroactivamente el manifiesto y el resultado.

CH12-F50— ELIMINAR MANIFIESTO ANTIGUO

Se destruye el historial de versiones.

CH12-F51— CORREGIR EVIDENCIA ORIGINAL

Se modifica el contenido del archivo para corregir la clasificación incorrecta.

CH12-F52— NEGAR EL DERECHO DE RETIRADA

Se antepone la inmutabilidad a los derechos humanos.

CH12-F53— MONOPOLIO DE CAPTURA PROPIETARIA CERRADO

Solo se considera válida la evidencia producida con la herramienta del fundador.

CH12-F54— NO PUBLICAR EL ESQUEMA DE CAPTURA

Un equipo independiente no puede establecer la misma cadena de evidencia.

CH12-F55— CONSIDERANDO LA RAÍZ DE LA ONDA COMO PRUEBA DE REALIDAD

La raíz Merkle o de hash se presenta como si demostrara la exactitud del contenido.

CH12-F56— afirmación DE “CAPTURAS DE PANTALLA 1,000” SIN UN PAQUETE DE EVIDENCIA

El número de archivos se usa como si fuera el número de observaciones válidas.

78. PROCEDIMIENTO DE AUDITORÍA

Paso 1— Determinar el Propósito de Investigación de la Onda

Se selecciona el tipo principal, confirmatorio, de incidente, de deriva o de reexamen.

Paso 2— Fijar Estados del Producto y Sistema de IA

Se conecta a la versión de onda del Registro del Sistema de IA en la Sección 9.

Paso 3— Fijar Estados de Población, Muestra y Panel

Se utilizan registros de las Secciones 5–8 y la Sección 11.

Paso 4— Fijar Registro de Prompt

Las versiones del prompt de la sección 10 están vinculadas a la oleada de medición.

Paso 5— Configurar la Ventana de Ola UTC

Se escriben las duraciones de inicio, cierre y adicionales.

Paso 6— Crear Micro-Ranuras

Los participantes son asignados a las ranuras de manera equilibrada en términos de producto, país e idioma.

Paso 7— Definir Fuente de Tiempo

Se determinan el servidor, el dispositivo y los registros confiables UTC.

Paso 8— Fijar Primer Contacto y Reglas de Reintento

Los estados técnicos y semánticos se separan.

Paso 9— Determinar Métodos de Captura

Se definen las rutas web, móviles, de accesibilidad y del panel natural.

Paso 10— Determinar Objetivo NCL

Registrar el nivel de confianza de captura requerido para el análisis principal.

Paso 11— Fijar el Esquema del Paquete de Evidencia

Se definen el manifiesto, archivos, hash y campos de metadatos.

Paso 12— Fijar las Reglas de Privacidad y Redacción

Se separan las capas en bruto, de auditoría y pública.

Paso 13— Capturar su Vehículo con el Piloto

¿Cambia el vehículo el comportamiento del producto? ¿Son correctos los registros de tiempo y texto?

Paso 14— Abrir el Registro de Eventos Externos

Se establece un proceso para monitorear eventos del producto y de la entidad.

Paso 15— Confirmar el Fijación de Onda

Se asigna el estado WS-1 — FIJADO.

Paso 16— Abrir los Espacios

A los participantes solo se les permite enviar en sus propios espacios.

Paso 17— Registrar el Resultado del Primer Contacto

Se separa respuesta, rechazo, error o límite.

Paso 18— Capturar la Primera Salida Adecuada

La respuesta completa se conserva sin renovación.

Paso 19— Crear Evidencia y Metadatos en Crudo

Se registran capturas de pantalla, texto en crudo, estado del sistema y marcas de tiempo.

Paso 20— Realizar Hash Local y Carga Segura

Los archivos reciben un registro de integridad antes de la carga.

Paso 21— Aceptación del Servidor y Creación de Hash del Paquete

La cadena de evidencia se cierra con la hora del servidor y el ID del paquete.

Paso 22— Revisión Ciega de la Validez de la Captura

El estado CV se asigna sin conocer el éxito semántico.

Paso 23— Realizar Revisión de Duplicados y Manipulación

Se utilizan múltiples señales y revisión humana.

Paso 24— Examinar el Sistema Dentro de la Onda y Eventos Externos

Determine si se requiere un sub-onda o un estado mixto.

Paso 25— Asignar Salud de la Onda

Se asigna estado entre WH-0 y WH-5.

Paso 26— Generar Manifestación de la Onda y Raíz de Integridad

La lista de observaciones está versionada.

Paso 27— Publicar Manifestación de Prueba Pública

El alcance y la integridad se hacen visibles sin datos personales.

Paso 28— Aprobar Informe de Cierre de la Onda

Se cierran objetivos, ocurrencias, defectos, eventos y cambios con aprobación humana.

79. EVIDENCIA NECESARIA

ID de onda Tipo de onda Versión del protocolo Versión del registro del sistema AI Marco de población Fijación de muestra Fijación del estado del panel Versión del Registro de prompts Versión del paquete de referencia Hora de inicio y fin UTC Lista microfranja temporal Asignación de participante–slot Fuente de tiempo Desviaciones del reloj del dispositivo Tiempos de transmisión Primeros tiempos de contacto Tiempos de finalización Tiempos de captura Tiempos hash Tiempos de subida Tiempos de aceptación del servidor Resultados del primer contacto Primeras salidas de contenido adecuado Registros de reintento técnico Registros de respuestas parciales Límites de rechazo y uso Respuestas completas en bruto Capturas de pantalla completas Manifiestos visuales secuenciales Grabaciones de pantalla si los hay Citación y registros de fuentes Configuración del sistema Evidencia Herramienta de captura y versión Método de captura Nivel NCL Hashes de archivos Hash del paquete

Firma digital Marca de tiempo Comprobaciones de duplicados Comprobaciones de manipulación Capturar decisiones de validez Archivos de redacción Enlaces de bruto a redactado Manifiesto de privacidad Registros de retiro Eventos de cambio de producto Registro de evento externo Subdivisiones de ola Alcance de ranura Alcance de país e idioma Tasas de error técnico Tasa de validez de captura Estado de salud de la ola Raíz de integridad de la ola Manifiesto de evidencia pública Informe de cierre de ola Registro de cambios Persona o institución responsable

80. LISTA DE VERIFICACIÓN DE AUDITORÍA

¿Está claro el tipo y propósito de la ola? ¿Se han fijado los productos de IA y los estados del sistema? ¿Se han determinado la población, la muestra y las versiones del panel? ¿Se bloqueó el conjunto de prompts antes de los resultados? ¿Está abierta la ventana de la ola UTC? ¿Se preasignaron los micro-espacios? ¿Se distribuyeron los países y los idiomas de manera uniforme entre los espacios? ¿Cambiarán los participantes de espacio según sus resultados? ¿Se evaluó la carga de la hora local? ¿Hay horas de ola rotativas? ¿Están claros los tiempos extra de envío y finalización? ¿Se comparó el reloj del dispositivo con una fuente confiable UTC? ¿Se separaron los tiempos de envío, finalización, captura y carga? ¿Las observaciones fuera de la ola ingresaron a la puntuación principal? ¿Se registró el resultado del primer contacto? ¿Se distinguió el error técnico del rechazo?

¿Se realizó un reintento debido a una respuesta incorrecta? ¿Se preservó el primer intento en el reintento técnico? ¿Se eliminaron respuestas parciales? ¿Es realmente la primera salida adecuada la primera salida? ¿Se utilizó Regenerar o un mensaje de seguimiento? ¿Muestra el prompt visual y toda la respuesta? En respuestas largas, ¿hay captura sin espacios? ¿Coincide el texto en bruto con lo visual? Si se utilizó OCR, ¿hubo verificación humana? ¿Se conservaron versiones de respuesta dinámicas? ¿El usuario detuvo la respuesta? ¿Están vinculados el prompt y la respuesta a la misma sesión? ¿Se registró la herramienta de captura y la versión? ¿La herramienta de captura alteró el comportamiento del usuario? ¿Se indicó el nivel NCL? ¿Hay observaciones por debajo de NCL-3 en el análisis principal? ¿Cada archivo tiene un hash? ¿Está claro qué no prueba el hash?

¿Existe una firma digital o la hora del servidor? ¿El momento de la captura es diferente del momento de la subida? ¿Hay alguna razón para la subida tardía y un registro local de integridad? ¿Se realizó censura sobre la evidencia sin procesar? ¿Tienen los derivados editados hashes separados? ¿El manifiesto público revela la identidad del participante? ¿Se puede reidentificar a un usuario de un país pequeño? ¿Se capturaron innecesariamente conversaciones privadas en el panel natural? ¿Se proporcionó una ruta de evidencia alternativa para usuarios con accesibilidad? ¿La decisión sobre duplicados se basó únicamente en el mismo texto? ¿La decisión sobre manipulación lleva múltiples señales? ¿El validador de captura conocía la puntuación semántica? ¿La respuesta correcta cubrió el fallo de la evidencia? ¿Se invalidó la respuesta incorrecta? ¿El producto cambió durante la oleada?

¿Se procesó el cambio de producto como una bajo-onda o en estado mixto? ¿Se registraron eventos externos? ¿Los eventos externos causaron exclusión según el resultado? ¿El estado de salud de la onda es independiente de la puntuación? Después de que la onda se cerró, ¿se agregaron o eliminaron observaciones? ¿Se conservan el antiguo manifiesto y la raíz de integridad? ¿Cómo se gestionaron las solicitudes de retiro de los participantes? ¿Existe un manifiesto de prueba público? ¿Hay un propietario claramente responsable del informe de cierre de la onda?

81. OBJECIONES Y RESPUESTAS

Objeción 1— “Si todos los usuarios no envían al mismo segundo, no se logra una simultaneidad verdadera.”

La presentación de un segundo puede crear efectos artificiales de carga, conexión y cola. Una ventana corta predefinida UTC y micro-intervalos aleatorios pueden medir el mismo período del sistema de manera más confiable.

Objeción 2— "El producto puede cambiar dentro de una ventana de una hora."

Puede cambiar. Por lo tanto, se requieren registros del sistema, huella de configuración y seguimiento de cambios del producto. En caso de un cambio material, la ola se separa.

Objeción 3— "¿Por qué no es suficiente con una captura de pantalla?"

Captura de pantalla:

• tiempo,
• salida inicial,
• versión del prompt,
• configuración del sistema,
• copiando

no siempre se muestran estos sujetos. Se requiere un paquete completo de evidencia.

Objeción 4— "¿No es demasiado gravoso verificar mil capturas de pantalla una por una?"

Es pesado. Se pueden usar controles automáticos de integridad, revisión humana basada en muestras y verificación basada en riesgos. Los registros críticos o sospechosos se examinan con más detalle.

Objeción 5— "Si hay un hash, ¿por qué no podemos decir que el archivo es real?"

Un hash solo muestra que el archivo permaneció igual después de que se generó el hash. No muestra cómo se creó el archivo antes del hash.

Objeción 6— "Si el usuario tiene que recortar información personal, ¿cómo se protegerá el archivo original?"

Si es posible, la herramienta de Captura no debe capturar información personal desde el principio. Si es inevitable, el archivo original se mantiene en un repositorio restringido y cifrado, y una copia pública se mantiene como un derivado redactado por separado.

Objeción 7— “Si la respuesta es incorrecta, ¿por qué no lo intentamos de nuevo?”

Porque una respuesta incorrecta es una cuestión de medición. Reintentar es solo para una falla técnica real.

Objeción 8— “Si el sistema rechaza, ¿puede el usuario intentar de nuevo?”

Correcto. El panel principal de primer contacto conserva el rechazo. Una Pista de Interacción Natural separada puede medir el comportamiento de seguimiento del usuario.

Objeción 9— “Si un error técnico es un problema de experiencia del usuario, ¿por qué permitimos reintentos?”

El error técnico se conserva como resultado del primer contacto. Se puede realizar un reintento técnico predefinido para examinar adicionalmente el contenido representativo. Los dos resultados no se reemplazan entre sí.

Objeción 10— “¿No es el propio registro del proveedor la evidencia más fuerte?”

Técnicamente, puede ser muy fuerte. El proveedor es el propietario del sistema medido. Es más fiable cuando se utiliza junto con una captura independiente del usuario.

Objeción 11— “¿Será NOMOS Capture un software obligatorio NobleJackal?”

No. NOMOS Capture es un protocolo de evidencia abierto. Las herramientas independientes que cumplan con el esquema y las condiciones de integridad equivalentes pueden ser compatibles.

Objeción 12— “Si no hacemos pública toda la evidencia, ¿cómo se realizará la verificación independiente?”

El manifiesto público muestra la integridad y el alcance. Los auditores independientes autorizados pueden acceder a pruebas crudas redactadas o limitadas. La privacidad y la verificación pueden diseñarse conjuntamente.

Objeción 13— “¿No se interrumpiría todo el trabajo si durante la ola se publican noticias importantes?”

No siempre. El informe es parte del entorno del sistema real. Puede separarse con una marca de tiempo antes y después del evento. El alcance de la puntuación se explica en consecuencia.

Objeción 14— “¿No es más fácil descartar las respuestas antiguas y continuar con el nuevo sistema cuando se actualiza un producto?”

Las respuestas antiguas son reales en la fecha de medición. No se pueden borrar. Los estados del sistema antiguo y nuevo deben mantenerse como olas o sub-olas separadas.

Objeción 15— “Si la herramienta de captura afecta el comportamiento del producto, ¿fracasa todo el método?”

No. El efecto del vehículo se mide con el piloto. Si es necesario, se elige un vehículo más ligero, captura manual o un método que utilice el efecto del vehículo como un factor separado.

Objeción 16— “Si el participante retira sus datos, ¿no se comprometería la raíz de integridad?”

Se crea una nueva versión del manifiesto y una nueva raíz. El registro antiguo puede conservar un rastro SIN CONTENIDO RETIRADO. Se mantiene sobre la arquitectura de evidencia de derechos humanos.

FALLO COMÚN DE LA SECCIÓN 85

Al final de un estudio GEO-1000, puede que tenga 30,000 capturas de pantalla. Este número por sí solo no es evidencia. Necesita saber: ¿En qué ola fueron producidas? ¿A qué estado del sistema pertenecían? ¿Se envió realmente el mismo mensaje? ¿Fue la primera salida? ¿Se actualizó la respuesta? ¿Cambió el producto durante la ola? ¿Cuándo se capturó el archivo? ¿Cuándo se generó el hash? ¿Se repitió la ID del participante? ¿Muestra lo visual toda la respuesta? ¿Coincide el texto en bruto con lo visual? Si la evidencia fue editada posteriormente, ¿dónde está el original? ¿Se realizó la verificación de captura antes de la puntuación semántica? Puede hacer clic mil veces en el mismo segundo. Aun así:

• relojes del dispositivo,
• conexiones,
• colas,
• estados del producto

Puede ser diferente. Por lo tanto, la concurrencia no es un espectáculo de marketing. Es una arquitectura de tiempo predefinida. Cuando un usuario obtiene una respuesta incorrecta: decir 'Intenta de nuevo.' es tentador. Pero esa respuesta incorrecta es la realidad que estás tratando de medir. Si la borras, no arreglas el sistema. Corrompes la evidencia. Cuando un usuario experimenta un error de conexión real, se puede hacer un reintento técnico. Pero el resultado del primer contacto aún debe conservarse. Porque el usuario encontró el error primero. El hash es valioso. La firma digital es valiosa. La marca de tiempo es valiosa. La captura de pantalla es valiosa. Ninguno de estos por sí solo contiene toda la verdad. Confianza:

• prompts,
• tiempo,
• producto,
• usuario,
• archivo,
• iniciativa,
• verificación

Surge de la preservación conjunta de su cadena. Un estándar: si dice, “Solo la prueba producida con mi software es válida,” antepone su propio interés a la replicación independiente. Por esta razón, NOMOS Capture no es una marca de herramienta, sino una arquitectura de prueba abierta. Las universidades independientes, investigadores o instituciones de auditoría deberían poder aplicar las mismas reglas. Por lo tanto, la duodécima ley de medición de NOMOS es la siguiente:

La concurrencia es la reproducibilidad observable dentro del mismo tiempo definido del sistema, no el mismo segundo.

La ley decimotercera es la siguiente:

La primera salida no es un borrador que se pueda renovar hasta que a uno le guste el resultado.

La ley decimocuarta es la siguiente:

El hash conserva la prueba; no crea la prueba.

La decimoquinta ley es la siguiente:

La validez de la captura y la precisión de la respuesta son independientes entre sí.

Su decimosexta ley es la siguiente:

La cadena de evidencia debe hacer visible la integridad de la observación, no la identidad de la persona.

Su decimoséptima ley es:

Si el sistema cambia durante la onda, no puede actuar como si el historial de medición no hubiera cambiado.

Su décima octava ley de medición establece:

Nada está escrito sobre la evidencia cruda; las decisiones se corrigen mediante versiones.

Su décima novena ley de medición establece:

Un método de captura que no puede aplicarse de manera independiente no puede ser un estándar mundial.

Orden de la Sección 12 de NOMOS

No me digas "preguntamos al mismo tiempo." / Muestra en qué ventana UTC, en qué ranura y en qué estado del sistema preguntaste.

No amontones a mil personas en el mismo segundo para producir un error artificial. / Distribuye el tiempo pero mantén el sistema dentro de la misma onda.

No mezcles los horarios locales entre sí. / No tomes el tiempo del dispositivo como verdad absoluta.

No guarde el resultado del primer contacto. / Guarde el límite de uso, los reintentos, el error y la aclaración por separado.

No regeneres cuando obtengas una respuesta incorrecta. / Esa respuesta incorrecta es mi comportamiento real.

Puedes reintentar cuando ocurra un error técnico. / Pero no elimines el primer error.

No me traigas solo una captura de pantalla. / Trae el prompt, la respuesta completa, el producto, el tiempo, la configuración, la cadena de interferencia y la integridad del archivo.

No recortes la parte buena de tu respuesta. / Deja visible el final, el límite y el error.

No declares el hash como realidad. / Prueba también lo que estaba antes del hash.

No redactes el archivo en bruto en sí. / Conserva el original y produce una copia pública separada.

No publiques el nombre de una persona, cuenta o conversación privada como evidencia.

No hagas que el único participante en un país pequeño sea identificable.

No declares tu herramienta de captura como neutral sin probar si me alteró.

Si el sistema cambió en medio de la ola, no mezcles las respuestas antiguas y nuevas como si pertenecieran a un solo producto.

Si un evento externo lo cambió, registra el evento. / No elimines la observación porque no te gustó la puntuación.

Mantén la evidencia fija. / Si la decisión es incorrecta, corrígela con una nueva versión.

No vincules el estándar de captura al software cerrado de una sola empresa. / Permite que otros puedan establecer la misma cadena de pruebas.

Primero, bloquea la ola. / Luego distribuye el tiempo. / Luego captura la primera salida. / Luego aplícale hash. / Luego súbelo de forma segura. / Luego verifica la captura sin comprobar su exactitud. / Y solo después de esto, decide lo que dice tu respuesta.

La oración de cierre del capítulo

Una respuesta en GEO-1000 se convierte en una verdadera unidad de medida solo cuando se puede mostrar bajo qué estado del sistema, en qué momento, a partir de qué prompt y dentro de qué cadena de pruebas inmutable se originó.

Core normativo

Cada observación GEO-1000 DEBE estar vinculada a una ola de medición predeclarada y versionada que defina: - estados del producto de IA, - marcos de población y muestra, - estados del panel, - versiones de prompts, - ventana de despacho UTC, - micro-espacios aleatorizados, - plazos de finalización y captura, - reglas de reintento técnico, - esquema de captura, - versiones de registros de referencia, - y propiedad de gobernanza. La sincronización DEBE significar observación dentro de una ventana de estado del sistema declarado UTC y estructura de espacio asignada. NO DEBE representarse como simultaneidad perfecta al milisegundo. Cada observación DEBE preservar, según esté disponible: - hora de asignación, - hora de envío del prompt, - primer evento del sistema, - hora de finalización de la respuesta, - hora de captura, - hora de creación del hash, - hora de subida, - y hora de aceptación por el servidor. El resultado del primer contacto DEBE permanecer visible. Un reintento técnico PUEDE utilizarse solo bajo condiciones de falla de infraestructura predeclaradas y DEBE conservar cada intento previo. No se DEBEN regenerar, reemplazar ni excluir salidas incorrectas, desfavorables, rechazadas, no citadas, truncadas o críticas meramente por su contenido. Un paquete de evidencia de captura NOMOS DEBE conservar exactamente el prompt asignado y enviado, la respuesta completa en bruto, la evidencia visual completa, los metadatos del estado del sistema, el registro de intentos, la evidencia temporal, los hashes de archivos, el hash del paquete, la versión de la herramienta de captura, el estado de privacidad y la decisión de validez de captura cegada. Una captura de pantalla, un hash, una firma digital, un registro del proveedor o una marca de tiempo NO DEBEN representarse individualmente como prueba completa de la autenticidad de la observación. La evidencia en bruto DEBE permanecer inmutable o de solo adición. Las redacciones, correcciones, retiros, exclusiones y cambios de adjudicación DEBEN crear versiones vinculadas y preservar el registro anterior donde sea ética y legalmente permisible. Los cambios en productos de IA materiales o eventos externos durante una ola DEBEN registrarse en el tiempo y manejarse mediante sub-olas, modelado explícito, reinicio o prompts de estado mixto. La validez de la captura DEBE decidirse independientemente de la corrección semántica. Los manifiestos de evidencia pública DEBEN apoyar la verificación sin exponer innecesariamente la identidad de los participantes, credenciales, historial de conversaciones privadas o ubicación precisa. El cumplimiento de la captura NOMOS DEBE implementarse mediante sistemas de evidencia abiertos y equivalentes y NO DEBE depender exclusivamente de una herramienta propietaria controlada por el fundador del estándar. Cada ola, conjunto de evidencia, decisión de captura, revisión de manifiesto y registro de integridad DEBE ser versionado y atribuible a un humano o una organización responsable.