Verifique você mesmo

Como a Vera, o motor de verificação dentro da Celina, produz evidências que sua equipe de QA pode checar sem a gente na sala.

Para lideranças de qualidade, responsáveis por integridade de dados e equipes de validação de sistemas computadorizados.

Todo sistema de IA em pesquisa clínica pede para ser confiado. Este foi construído para não precisar pedir.

A Vera é a parte da Celina que checa o registro. Não o raciocínio do modelo, nem a saída dele. O registro assinado que a plataforma produz enquanto o trabalho acontece: cada evento com hash, vinculado ao seu antecessor e endereçado por conteúdo. A Vera percorre essa cadeia mecanicamente e emite um certificado que diz exatamente o que ela checou e exatamente o que não pôde checar.

O veredito dela é uma frase, e nunca muda.

No break detected under the following checks.

Nenhuma quebra detectada sob as seguintes verificações.

Não "válido". Não "limpo". Não "verificado" como palavra solta. O que se sustentou, sob quais verificações, com as exclusões nomeadas. Qualquer pessoa com a chave pública pode refazer a matemática.

O que a Vera é, e o que ela não é

A Vera não contém modelo de linguagem em nenhum ponto do seu caminho de verificação. Sem raciocínio probabilístico, sem scores de confiança, sem inferência. Mesma entrada, mesmo veredito, sempre. Essa propriedade não é preferência de design. É a propriedade que uma equipe de validação de fato testa, e é o motivo pelo qual a saída dela pode ser tratada como evidência, e não como opinião.

Ela não é o que produz as respostas da Celina. Ela é o que checa se o registro dessas respostas está íntegro. O modelo propõe. A prova dispõe. A Vera é a prova.

Por que a Vera não é uma prova formal

O primeiro desenho da Vera foi construído em torno do Lean, o provador de teoremas. O plano era provar que a lógica de verificação estava correta e deixar um núcleo pequeno, checado por máquina, carregar a garantia. Nós saímos desse caminho, e o motivo merece ficar às claras.

Uma prova em Lean se prende a um modelo da cadeia. Entrada e saída, o banco de dados, a rede e a camada de extração ficam todos fora da prova. Você prova o modelo e torce para que a distância entre o modelo e a produção seja pequena. A Vera percorre o próprio fluxo de eventos de produção: bytes reais, banco de dados real, a cadeia inteira. Uma mudança de regra é um pull request com testes, não um projeto de engenharia de provas, e um terceiro checa o trabalho dela buscando uma chave pública, não rodando um provador de novo.

O que essa troca abriu mão é real, e não fingimos o contrário: uma garantia checada por máquina de que a própria lógica de verificação é sólida. Essa garantia agora se apoia na simplicidade das verificações, em uma suíte de testes vinculada a um banco de dados real e no fato de que qualquer pessoa pode recalcular o resultado e nos pegar no erro. Uma prova diz que o nosso raciocínio está correto. Uma chave publicada diz: prove que estamos errados. Equipes de validação confiam mais na segunda frase, porque ela tem o formato do próprio trabalho delas.

O percurso

A Vera checa o registro em três níveis.

Nível zero, a cadeia criptográfica. Hashes de eventos, vínculo com o antecessor, integridade de documentos. Cada evento gera o hash que afirma gerar, e cada um se vincula ao que veio antes.

Nível um, estrutura. Validade de esquema, ordenação, consistência bitemporal, cadeias de substituição. Tempo válido e tempo de transação estão ambos registrados e coerentes. Quando algo foi substituído, a cadeia do original ao sucessor se sustenta.

Nível dois, o grafo de proveniência. Cada artefato rastreia até o que o produziu.

Nada é amostrado. O percurso cobre a cadeia inteira, e o que ele não consegue cobrir é nomeado, não pulado.

O certificado

Todo certificado enumera as verificações que rodaram. Ele também carrega um registro de exclusões pré-declarado que nomeia qualquer verificação que não pôde rodar e por quê. Nada é omitido em silêncio, e essa é a diferença entre um certificado e um consolo.

Os certificados são assinados com Ed25519 por uma identidade verificadora nomeada, vera-audit-v1. Depois, são anexados ao mesmo registro que descrevem, como eventos assinados. O ato de verificar está, ele próprio, na trilha de auditoria.

Verifique você mesmo

Esta é a parte que mais importa para uma equipe de validação, então vai dita sem rodeios.

Reverificar um certificado exige a chave pública e nada mais. Sem acesso ao fornecedor, sem banco de dados, sem segredo, sem ligação para a gente.

O algoritmo, o identificador da chave, a chave pública em formato PEM, a codificação da assinatura e o contrato de canonicalização do payload estão publicados em um endpoint aberto:

GET /vera/v1/keys

Um certificado é reverificado contra essa chave em:

GET /vera/v1/certificates/verify

O contrato de verificação é completo e público. Uma função de segurança ou de QA pode buscar a chave, verificar certificados de forma independente e chegar à sua própria conclusão antes de qualquer conversa comercial começar. Essa é a ordem pretendida das coisas.

O registro por baixo

Somente inserção. O registro não pode ser editado, apenas acrescentado. Correção é substituição: a versão anterior permanece, vinculada à sucessora, com os dois carimbos de tempo intactos. Não existe caminho que reescreva a história, nem para nós.

Endereçado por conteúdo. Os artefatos são identificados por hash SHA-256. O registro é o original por construção, não por política.

Bitemporal. Tempo válido e tempo de transação são ambos registrados no momento do evento, não reconstruídos depois.

Chaveado por jurisdição. A assinatura usa um anel de chaves por namespace, com chaves separadas para registros dos Estados Unidos e do Brasil, versionadas, com rotação em etapas. As linhas históricas verificam inalteradas sob o anel, porque a transição foi idêntica byte a byte por construção. Um registro dos Estados Unidos e um registro do Brasil são criptograficamente separáveis.

O perímetro

Duas muralhas independentes ficam na frente do registro. A identidade no nível da plataforma recusa uma requisição não autenticada antes que ela chegue ao código da aplicação, e essa recusa é testada. Atrás dela, as checagens de principal no nível da aplicação falham fechadas: uma dependência mal configurada recusa em vez de abrir por padrão.

A exportação de linhagem está disponível por artefato e por jurisdição, restrita ao titular do registro ou a um papel de auditor. Um resultado vazio retorna contagem de linhas zero, e não um "não encontrado" distinguível, de modo que a interface não pode ser usada para sondar o que existe.

Gravações e emissões têm limite de taxa. Os digests das imagens implantadas são fixados em infraestrutura como código, como registro de implantação, e qualquer divergência faz o build falhar. A suíte de testes estrita da Vera roda contra um banco de dados real a cada mudança. O código dela não sobe sem verificação.

Como isso se apresenta frente ao ALCOA+

Não fazemos afirmação de conformidade. A tabela descreve o que o substrato faz. A conclusão é sua.

FAQ

Isso é compatível com o 21 CFR Part 11?

Não fazemos essa afirmação. Conformidade é uma avaliação que a sua organização realiza contra o seu próprio framework. O que podemos declarar é a capacidade: um registro somente inserção, encadeado por hash, bitemporal, com atestação humana nominal e certificados verificáveis de forma independente. O artigo acima foi escrito para que a sua equipe de validação possa avaliá-lo diretamente.

Por que o certificado diz "no break detected under the following checks" e não "verificado"?

Porque "verificado" seria uma afirmação sobre verificações que não foram executadas. O certificado nomeia as verificações que rodaram e as que foram excluídas. A redação se limita exatamente a isso. Qualquer coisa além disso seria um consolo, não um achado.

O que há no registro de exclusões?

Qualquer verificação que não pôde ser executada em um determinado percurso, nomeada explicitamente, com o motivo. O registro é pré-declarado, ou seja, o conjunto de exclusões possíveis é definido de antemão, não descoberto depois. Nada é pulado em silêncio.

Minha equipe pode verificar um certificado sem nenhum acesso aos sistemas da NexTrial?

Sim. A verificação exige apenas a chave pública, publicada junto com o contrato completo no endpoint aberto de chaves. Sem conta, sem acesso a banco de dados, sem chamado de suporte.

A Vera checa se as respostas da Celina estão corretas?

Não. A Vera checa se o registro dessas respostas está íntegro: a criptografia, a estrutura e a proveniência. A correção de uma determinação é estabelecida pelo motor de veredito determinístico sobre um corpus atestado, e finalizada por uma pessoa nomeada. A Vera prova que o registro não foi alterado desde então.

O que acontece se o endpoint de verificação estiver indisponível?

Os certificados já emitidos continuam verificáveis com a chave pública, independentemente da disponibilidade do serviço, porque a verificação não depende do serviço. O serviço em si falha fechado: uma dependência indisponível produz uma recusa explícita, nunca uma aprovação silenciosa.

Se as chaves forem rotacionadas, os certificados antigos continuam verificando?

Sim. O anel de chaves é versionado e a rotação é feita em etapas. As linhas históricas verificam inalteradas sob o anel, por construção.

Podemos exportar o registro para os nossos próprios sistemas?

Sim. A exportação assinada de linhagem está disponível por artefato e por jurisdição para o titular do registro ou para um papel de auditor. Ela viaja como dado. Quem recebe não precisa de nada da NexTrial para checá-la.

O que acontece quando um registro está errado?

Ele é substituído, nunca editado. O original permanece, vinculado ao seu sucessor, com os dois carimbos de tempo preservados. A cadeia do original até a correção faz parte, ela mesma, do registro verificado.

A Vera é um modelo de linguagem?

Não. Não há modelo no caminho de verificação dela. Ela não raciocina. Ela checa.

Como a própria Vera é testada?

A suíte de testes dela roda contra um banco de dados real a cada mudança de código, e uma suíte com falha bloqueia o merge. Os digests das imagens implantadas são fixados como registro de implantação, e qualquer divergência entre o digest fixado e o que está rodando faz o build falhar.

Podemos testar antes de qualquer conversa comercial?

Essa é a ordem pretendida. Busque a chave, verifique um certificado, forme a sua própria opinião. Traga um artefato e veja ele sair com um certificado.

A Vera foi originalmente construída sobre o Lean?

Sim. O primeiro desenho da Vera foi construído em torno do Lean, o provador de teoremas, com a lógica de verificação a ser provada correta e checada por um núcleo confiável pequeno. Movemos a garantia para o determinismo, a transparência total e o recálculo independente sobre a cadeia de produção, porque uma prova sobre um modelo não checa os seus dados. O artigo acima expõe o que essa troca abriu mão e o que ela comprou.

Abandonar a prova formal torna a Vera menos confiável?

Muda em que a confiança se apoia. Uma prova em Lean garante a lógica de verificação dentro das premissas do modelo e não diz nada sobre o banco de dados, a rede ou a camada de extração implantados. As verificações da Vera são pequenas o bastante para serem lidas, a suíte de testes dela roda contra um banco de dados real a cada mudança, e qualquer terceiro pode recalcular o veredito dela a partir da chave pública. Se um dia acrescentarmos profundidade formal de volta, será provando os pequenos núcleos de especificação, canonicalização, vínculo e substituição, enquanto continuamos executando contra a realidade.

Projetada para ambientes onde a integridade de dados é auditada, não afirmada.

NexTrial.ai · Celina · Trial Activation Intelligence