Verifíquelo usted mismo

Cómo Vera, el motor de verificación dentro de Celina, produce evidencia que su equipo de QA puede comprobar sin nosotros en la sala.

Para líderes de calidad, responsables de integridad de datos y equipos de validación de sistemas informatizados.

Todo sistema de IA en investigación clínica pide que se confíe en él. Este está construido para no tener que pedirlo.

Vera es la parte de Celina que comprueba el registro. No el razonamiento del modelo, ni su salida. El registro firmado que la plataforma produce mientras el trabajo ocurre: cada evento con hash, vinculado a su predecesor y direccionado por contenido. Vera recorre esa cadena mecánicamente y emite un certificado que dice exactamente qué comprobó y exactamente qué no pudo comprobar.

Su veredicto es una frase, y nunca cambia.

No break detected under the following checks.

No se detectó ninguna ruptura bajo las siguientes comprobaciones.

No "válido". No "limpio". No "verificado" como palabra suelta. Qué se sostuvo, bajo qué comprobaciones, con las exclusiones nombradas. Cualquiera con la clave pública puede rehacer las cuentas.

Qué es Vera, y qué no es

Vera no contiene ningún modelo de lenguaje en ningún punto de su ruta de verificación. Sin razonamiento probabilístico, sin puntuaciones de confianza, sin inferencia. Misma entrada, mismo veredicto, siempre. Esa propiedad no es una preferencia de diseño. Es la que un equipo de validación realmente pone a prueba, y es la razón por la que su salida puede tratarse como evidencia y no como opinión.

No es lo que produce las respuestas de Celina. Es lo que comprueba si el registro de esas respuestas está íntegro. El modelo propone. La prueba dispone. Vera es la prueba.

Por qué Vera no es una prueba formal

El primer diseño de Vera se construyó en torno a Lean, el demostrador de teoremas. El plan era probar que la lógica de verificación era correcta y dejar que un núcleo pequeño, comprobado por máquina, sostuviera la garantía. Nos apartamos de ese camino, y el motivo merece decirse abiertamente.

Una prueba en Lean se adhiere a un modelo de la cadena. La entrada y la salida, la base de datos, la red y la capa de extracción quedan todas fuera de la prueba. Se prueba el modelo y se confía en que la distancia entre el modelo y producción sea pequeña. Vera recorre el propio flujo de eventos de producción: bytes reales, base de datos real, la cadena completa. Un cambio de regla es un pull request con pruebas, no un proyecto de ingeniería de demostraciones, y un tercero comprueba su trabajo obteniendo una clave pública, no volviendo a ejecutar un demostrador.

Lo que ese intercambio sacrificó es real, y no fingimos lo contrario: una garantía comprobada por máquina de que la propia lógica de verificación es sólida. Esa garantía descansa ahora en la simplicidad de las comprobaciones, en una suite de pruebas ligada a una base de datos real y en el hecho de que cualquiera puede recalcular el resultado y pillarnos en falta. Una prueba dice que nuestro razonamiento es correcto. Una clave publicada dice: demuestre que estamos equivocados. Los equipos de validación confían más en la segunda frase, porque tiene la forma de su propio trabajo.

El recorrido

Vera comprueba el registro en tres niveles.

Nivel cero, la cadena criptográfica. Hashes de eventos, vínculo con el predecesor, integridad de documentos. Cada evento produce el hash que afirma producir, y cada uno se vincula con lo que vino antes.

Nivel uno, estructura. Validez del esquema, ordenación, consistencia bitemporal, cadenas de sustitución. Tiempo de validez y tiempo de transacción están ambos registrados y son coherentes. Cuando algo fue sustituido, la cadena del original al sucesor se sostiene.

Nivel dos, el grafo de procedencia. Cada artefacto se rastrea hasta lo que lo produjo.

Nada se muestrea. El recorrido cubre la cadena completa, y lo que no puede cubrir se nombra en lugar de omitirse.

El certificado

Cada certificado enumera las comprobaciones que se ejecutaron. También lleva un registro de exclusiones prerregistrado que nombra cualquier comprobación que no pudo ejecutarse y por qué. Nada se omite en silencio, y esa es la diferencia entre un certificado y un consuelo.

Los certificados se firman con Ed25519 por una identidad verificadora nombrada, vera-audit-v1. Luego se anexan al mismo registro que describen, como eventos firmados. El acto de verificar está, en sí mismo, en la pista de auditoría.

Verifíquelo usted mismo

Esta es la parte que más importa a un equipo de validación, así que se dice sin rodeos.

Reverificar un certificado requiere la clave pública y nada más. Sin acceso al proveedor, sin base de datos, sin secreto, sin llamada con nosotros.

El algoritmo, el identificador de clave, la clave pública en formato PEM, la codificación de la firma y el contrato de canonicalización del payload están publicados en un endpoint abierto:

GET /vera/v1/keys

Un certificado se reverifica contra esa clave en:

GET /vera/v1/certificates/verify

El contrato de verificación es completo y público. Una función de seguridad o de QA puede obtener la clave, verificar certificados de forma independiente y llegar a su propia conclusión antes de que empiece cualquier conversación comercial. Ese es el orden de operaciones previsto.

El registro que hay debajo

Solo inserción. El registro no puede editarse, solo ampliarse. La corrección es sustitución: la versión anterior permanece, vinculada a su sucesora, con ambas marcas de tiempo intactas. No existe ninguna vía que reescriba la historia, tampoco para nosotros.

Direccionado por contenido. Los artefactos se identifican por hash SHA-256. El registro es el original por construcción, no por política.

Bitemporal. Tiempo de validez y tiempo de transacción se registran ambos en el momento del evento, no se reconstruyen después.

Con clave por jurisdicción. La firma usa un anillo de claves por espacio de nombres, con claves separadas para registros de Estados Unidos y de Brasil, versionadas, con rotación escalonada. Las filas históricas se verifican sin cambios bajo el anillo, porque la transición fue idéntica byte a byte por construcción. Un registro de Estados Unidos y un registro de Brasil son criptográficamente separables.

El perímetro

Dos muros independientes se alzan frente al registro. La identidad a nivel de plataforma rechaza una solicitud no autenticada antes de que llegue al código de la aplicación, y ese rechazo está probado. Detrás, las comprobaciones de principal a nivel de aplicación fallan cerradas: una dependencia mal configurada rechaza en lugar de abrirse por defecto.

La exportación de linaje está disponible por artefacto y por jurisdicción, restringida al titular del registro o a un rol de auditor. Un resultado vacío devuelve un recuento de filas de cero en lugar de un "no encontrado" distinguible, de modo que la interfaz no puede usarse para sondear qué existe.

Las escrituras y las emisiones tienen límite de tasa. Los digests de las imágenes desplegadas se fijan en infraestructura como código, como registro de despliegue, y cualquier desviación hace fallar el build. La suite de pruebas estricta de Vera se ejecuta contra una base de datos real en cada cambio. Su código no sale sin verificar.

Cómo se ve esto frente a ALCOA+

No hacemos ninguna afirmación de cumplimiento. La tabla describe lo que hace el sustrato. La conclusión es suya.

FAQ

¿Esto cumple con 21 CFR Part 11 o con el Anexo 11 de la UE?

No hacemos esa afirmación. El cumplimiento es una evaluación que su organización realiza contra su propio marco. Lo que sí podemos declarar es la capacidad: un registro de solo inserción, encadenado por hash, bitemporal, con atestación humana nominal y certificados verificables de forma independiente. El artículo anterior está escrito para que su equipo de validación pueda evaluarlo directamente.

¿Por qué el certificado dice "no break detected under the following checks" y no "verificado"?

Porque "verificado" sería una afirmación sobre comprobaciones que no se ejecutaron. El certificado nombra las comprobaciones que se ejecutaron y las que quedaron excluidas. Su redacción se limita exactamente a eso. Cualquier cosa más amplia sería un consuelo, no un hallazgo.

¿Qué contiene el registro de exclusiones?

Cualquier comprobación que no pudo ejecutarse en un recorrido dado, nombrada explícitamente, con el motivo. El registro está prerregistrado, es decir, el conjunto de exclusiones posibles se declara de antemano y no se descubre después. Nada se omite en silencio.

¿Puede mi equipo verificar un certificado sin ningún acceso a los sistemas de NexTrial?

Sí. La verificación requiere solo la clave pública, publicada junto con el contrato completo en el endpoint abierto de claves. Sin cuenta, sin acceso a base de datos, sin llamada a soporte.

¿Vera comprueba si las respuestas de Celina son correctas?

No. Vera comprueba si el registro de esas respuestas está íntegro: la criptografía, la estructura y la procedencia. La corrección de una determinación la establece el motor de veredicto determinista sobre un corpus atestado, y la finaliza una persona nombrada. Vera demuestra que el registro no ha sido alterado desde entonces.

¿Qué ocurre si el endpoint de verificación no está disponible?

Los certificados ya emitidos siguen siendo verificables con la clave pública, independientemente de la disponibilidad del servicio, porque la verificación no depende del servicio. El servicio en sí falla cerrado: una dependencia no disponible produce un rechazo explícito, nunca una aprobación silenciosa.

Si se rotan las claves, ¿los certificados antiguos siguen verificándose?

Sí. El anillo de claves está versionado y la rotación es escalonada. Las filas históricas se verifican sin cambios bajo el anillo, por construcción.

¿Podemos exportar el registro a nuestros propios sistemas?

Sí. La exportación firmada de linaje está disponible por artefacto y por jurisdicción para el titular del registro o para un rol de auditor. Viaja como datos. Quien lo recibe no necesita nada de NexTrial para comprobarlo.

¿Qué ocurre cuando un registro es erróneo?

Se sustituye, nunca se edita. El original permanece, vinculado a su sucesor, con ambas marcas de tiempo preservadas. La cadena del original a la corrección es, en sí misma, parte del registro verificado.

¿Vera es un modelo de lenguaje?

No. No hay ningún modelo en su ruta de verificación. No razona. Comprueba.

¿Cómo se prueba a la propia Vera?

Su suite de pruebas se ejecuta contra una base de datos real en cada cambio de código, y una suite que falla bloquea el merge. Los digests de las imágenes desplegadas se fijan como registro de despliegue, y cualquier desviación entre el digest fijado y lo que está en ejecución hace fallar el build.

¿Podemos probarlo antes de cualquier conversación comercial?

Ese es el orden previsto. Obtenga la clave, verifique un certificado, fórmese su propia opinión. Traiga un artefacto y véalo salir con un certificado.

¿Vera se construyó originalmente sobre Lean?

Sí. El primer diseño de Vera se construyó en torno a Lean, el demostrador de teoremas, con una lógica de verificación que debía probarse correcta y comprobarse con un núcleo de confianza pequeño. Movimos la garantía al determinismo, la transparencia total y el recálculo independiente sobre la cadena de producción, porque una prueba sobre un modelo no comprueba sus datos. El artículo anterior expone lo que ese intercambio sacrificó y lo que aportó.

¿Renunciar a la prueba formal hace a Vera menos confiable?

Cambia en qué se apoya la confianza. Una prueba en Lean garantiza la lógica de verificación dentro de los supuestos del modelo y no dice nada sobre la base de datos, la red o la capa de extracción desplegadas. Las comprobaciones de Vera son lo bastante pequeñas para leerse, su suite de pruebas se ejecuta contra una base de datos real en cada cambio, y cualquier tercero puede recalcular su veredicto a partir de la clave pública. Si algún día recuperamos profundidad formal, será probando los pequeños núcleos de especificación, canonicalización, vinculación y sustitución, mientras seguimos ejecutando contra la realidad.

Diseñada para entornos donde la integridad de datos se audita, no se afirma.

NexTrial.ai · Celina · Trial Activation Intelligence