Fronteira probabilística

O COADF P-1 enuncia o mínimo: um componente probabilístico devolve um valor junto com uma confiança e o método pelo qual o valor foi obtido, nunca um valor nu, e nunca chega diretamente a uma saída. Este padrão trata da segunda metade, que é a metade que as implementações perdem. A resposta de um modelo pode entrar no sistema. O que ela não pode é se tornar, por caminho algum, aquilo que o sistema trata como estabelecido.

Três coisas precisam valer ao mesmo tempo:

• A saída tem um tipo próprio. Uma proposta e um registro com autoridade são tipos diferentes, tabelas diferentes ou mensagens diferentes. Um código que tem um deles em mãos não consegue passá-lo onde se espera o outro sem uma etapa explícita que alguém possa revisar.
• A fronteira valida em tempo de execução. O contrato é verificado quando a resposta chega, no processo que a recebe, diga o remetente o que disser ter verificado.
• A procedência viaja com o valor. O método, o modelo e sua revisão, a revisão do prompt e a localização na fonte permanecem ligados ao valor em cada etapa, serialização incluída. Sem eles, o P-4 não consegue reconstruir e o P-5 não consegue declarar.

O P-1 também faz o componente informar uma confiança. Como a confiança é expressa, atribuída e usada pertence ao P-2, que o COADF publica apenas como princípio. Este Companion não a descreve, e nada abaixo depende dela.

A saída de um modelo vem de um processo que não pode ser reproduzido a partir de suas entradas como a saída de um parser pode: amostragem, atualizações do modelo e mudanças de prompt, tudo isso a desloca. Isso é aceitável para uma proposta e inaceitável para um fato. O risco não é um modelo às vezes errar; tudo às vezes erra. O risco é perder a capacidade de dizer quais valores vieram de onde, porque todo controle posterior depende disso. Um gate só detém o que consegue ver, uma declaração só nomeia o que está marcado, e uma pessoa revisora só confere o que ainda aponta para sua fonte.

A perda raramente é uma decisão. Ela acontece numa linha de código comum: uma entidade do ORM preenchida a partir do JSON do modelo porque os nomes dos campos por acaso coincidiam, um modelo de resposta que descarta a procedência porque ninguém a acrescentou, uma importação em lote que contorna o formulário onde a validação morava. O padrão existe para tornar impossível escrever essa linha sem perceber.

O isolamento é arquitetural, não necessariamente físico

Microsserviços não são necessários. A propriedade vale quando nenhum caminho de código permite ao lado probabilístico produzir um objeto com autoridade, e um único processo consegue mantê-la tão bem quanto uma rede. A topologia se escolhe por razões próprias (escalar separadamente uma carga de inferência, isolar a biblioteca cliente de um fornecedor, fazer deploy de forma independente), e depois a fronteira se constrói na forma escolhida. As quatro figuras abaixo mantêm a mesma propriedade em quatro formas.

Os mesmos quatro elementos em toda topologia

• Tipos distintos. O lado probabilístico consegue construir uma proposta e nada mais. O registro com autoridade é construído apenas pelo código de domínio, a partir de uma proposta somada a algo que o lado probabilístico não consegue produzir.
• Validação em tempo de execução em todo lado receptor. Um esquema estrito: campos não declarados rejeitados, nenhuma coerção de tipo, vocabulários fechados para valores categóricos, comprimentos limitados. Numa topologia distribuída cada receptor valida, inclusive o lado do domínio quando o remetente é um serviço próprio: “validamos antes de enviar” é uma afirmação sobre outra unidade implantável, possivelmente uma versão mais antiga dela.
• Procedência no contrato. Declarada, obrigatória e preservada por todo mapeador e serializador no caminho de saída.
• Uma etapa explícita de promoção. A única rota de uma proposta até um registro com autoridade é uma função, um endpoint ou um comando que exige o que o lado probabilístico não consegue fornecer. Para valores derivados por um modelo de linguagem, o fence público F-03 do COADF exige verificação humana antes que cheguem a uma saída publicada. A própria promoção fica registrada na trilha de auditoria.

Validação determinística em torno de uma saída estocástica

Verificações que leem apenas o valor (sua forma, seu vocabulário, sua unidade, os intervalos que o próprio domínio define) rodam antes que qualquer pessoa olhe para ele. Elas não tornam um valor verdadeiro. Elas tornam impossível um valor impossível, e fazem isso sempre do mesmo jeito, algo em que a pessoa revisora do valor pode se apoiar.

Opções de aplicação, da mais fraca à mais forte

A maioria dos sistemas quer as três primeiras sempre, e as duas últimas quando o componente probabilístico tem deploy próprio. O perfil Python e FastAPI implementa as três primeiras; o perfil Cloud-native acrescenta as duas últimas.

• Interfaces só de sugestão. A saída do modelo é mostrada a uma pessoa como sugestão e nunca armazenada como valor. Simples e forte; abre mão da rastreabilidade do que foi sugerido, a menos que as sugestões também sejam registradas.
• Um contrato compartilhado e neutro em relação à linguagem (JSON Schema, Protocol Buffers) em vez de modelos nativos da linguagem. Melhor entre linguagens; desloca a questão do rigor para o esquema, onde propriedades adicionais e formatos precisam ser decididos explicitamente.
• Modos de saída estruturada das APIs de modelos. Reduzem respostas malformadas no produtor. Não dispensam o consumidor de validar, porque o consumidor não consegue verificar como o produtor foi configurado.
• Armazenamento separado para propostas e registros, duas tabelas ou dois armazenamentos em vez de uma tabela com um status. Mais pesado, e torna a separação visível em toda consulta que alguém escrever.

• A fronteira controla para onde a saída do modelo pode ir. Ela não torna a saída do modelo correta, e um valor bem formado e errado passa em todas as verificações deste padrão.
• A separação de tipos detém acidentes, não intenção. Quem desenvolve com acesso de escrita ao domínio consegue construir à mão um objeto com autoridade; a revisão de código e a trilha de auditoria são o que torna isso visível.
• Este padrão não diz quando uma proposta precisa de uma pessoa, nem como a confiança é expressa. Isso pertence ao P-2 e ao P-3, que o COADF publica apenas como princípios.
• A validação só é tão boa quanto o contrato. Um esquema permissivo, validado com rigor, continua permissivo.