Projection Engineering projeta Claims incertos em um grafo auditável

Imagem: gerada com o Google Gemini.

Um sistema automatizado afirma que o aluguel de julho não foi pago.

Produzir essa frase é barato. Verificá-la não é. Alguém precisa examinar o contrato de locação, identificar as contas registradas, conferir o período pertinente, distinguir transferências liquidadas das pendentes, perguntar se o pagamento pode ter sido destinado a outra dívida e determinar qual política permite que o resultado desencadeie uma notificação ou um despejo.

A resposta é uma frase. Sua fronteira de verificação se estende pelo mundo.

Esse é o problema estrutural da IA generativa. Não se trata apenas de um modelo poder estar errado. Agora, um Claim plausível pode ser produzido quase instantaneamente, enquanto verificá-lo pode exigir a reconstrução dos registros, pressupostos, transformações, políticas e omissões por trás dele.

A verificação se tornou mais cara do que a geração.

Tornar o modelo mais fluente não corrige essa inversão. Anexar uma citação também não, se ninguém puder dizer qual parte da fonte sustenta cada proposição, qual versão foi usada ou o que precisa ser reaberto quando a fonte mudar.

Instituições maduras resolveram problemas análogos inserindo uma camada de responsabilidade entre a observação e o cálculo. A física construiu a metrologia. O direito construiu a apuração jurídica dos fatos. A IA possui fragmentos de ambas, mas nenhuma disciplina reconhecida responsável por transformar Claims de mundo aberto em premissas que uma decisão possa usar com segurança.

Chamo essa responsabilidade ausente de Projection Engineering.

A camada ausente entre um registro e uma decisão

A metrologia não confia no ponteiro

Um sensor que exibe um número ainda não produziu uma medição confiável. Uma medição também precisa de unidade, histórico de calibração, cadeia de rastreabilidade, incerteza e faixa de validade declarada. O NIST enfatiza que a rastreabilidade metrológica pertence ao resultado de uma medição, e não apenas a um instrumento que carrega uma etiqueta de calibração (Rastreabilidade metrológica: perguntas frequentes e política do NIST).

Essa estrutura ao redor da medição torna a falha diagnosticável. Se uma estrutura física falhar, um investigador pode percorrer o caminho do valor informado, passando pelas transformações e calibrações, até a observação original. A aritmética por si só não oferece esse caminho. A metrologia torna um número capaz de sustentar peso institucional.

Uma resposta de LLM geralmente chega sem uma cadeia equivalente. Raramente identifica a observação que deu origem a cada Claim, o que se perdeu na transformação, onde o Claim continua válido ou quais decisões dependentes precisam ser reabertas após uma correção. É um ponteiro em movimento sem escala nem certificado de calibração.

O direito não confia na alegação

Um tribunal não encontra o passado em si. Encontra alegações, testemunhos, registros, provas materiais e laudos periciais. Por meio de regras probatórias, ônus, padrões de prova e procedimentos autorizados, a apuração jurídica dos fatos decide quais Claims concorrentes podem servir como premissas em um caso específico. A distinção entre realidade substantiva e verdade jurídica formal é um antigo problema da apuração judicial dos fatos (Verdade jurídica formal e verdade substantiva na apuração judicial dos fatos).

Separar a apuração dos fatos da aplicação das regras também separa os erros. Um registro pode ser coletado incorretamente. Uma proposição pode ser admitida sob o padrão errado. Uma premissa correta pode encontrar uma regra implementada incorretamente. Uma conclusão correta pode ser executada contra a pessoa errada. Cada falha pertence a uma camada diferente e exige um reparo diferente.

A metrologia transforma observações em valores rastreáveis. O direito transforma um registro contestado em constatações utilizáveis em um julgamento. Ambos se recusam a permitir que dados brutos fluam silenciosamente para um cálculo com consequências. Essa é a camada ausente nos sistemas de decisão por IA.

Fact significa Accepted Fact

O nome Projection Engineering precisa de uma fronteira rigorosa. Ele não promete fabricar uma verdade absoluta.

Em Projection Engineering, Fact significa Accepted Fact.

Um Accepted Fact é um Claim autorizado para uso como premissa em uma decisão específica sob propósito, escopo, tempo de referência, padrão de prova e política explícitos.

Três objetos devem permanecer distintos:

  • Claim: uma afirmação ou observação apresentada por uma fonte identificada.
  • Accepted Fact: um Claim admitido como premissa por um procedimento autorizado.
  • Conclusão: um resultado calculado a partir de Accepted Facts e regras.

Um Accepted Fact é um Claim com status institucional documentado, não a realidade capturada em um campo. A verdade continua sendo o objetivo: a proposição deve corresponder à realidade. O que o sistema pode preservar é mais limitado e operacional — quem afirmou o quê, a partir de qual registro, em que momento e por meio de qual transformação; quem o aceitou ou rejeitou, sob qual autoridade; e o que decorreu daquele conjunto delimitado de premissas.

Projection Engineering não é dona da verdade. Ela projeta a fronteira ao redor de uma decisão para que outra pessoa possa inspecioná-la e contestá-la.

A IA já é fechada — sobre tokens

Um Transformer congelado é fechado em um sentido computacional útil. Fixe seus pesos, entrada, ambiente de execução e condições de decodificação, e sua passagem para a frente poderá ser reproduzida. A arquitetura calcula qual token deve vir em seguida (Atenção é tudo de que você precisa). Ela é fechada sobre probabilidades de tokens, não sobre a realidade.

Essa distinção explica tanto sua resiliência quanto seu limite. Um corpus de treinamento pode conter X e not-X. A dedução clássica precisa administrar essa contradição porque uma explosão irrestrita pode permitir que qualquer coisa seja derivada. Um modelo de linguagem não explode: passagens contraditórias alteram uma distribuição em vez de invalidar uma prova, porque a implicação lógica não é a operação primitiva realizada.

Pela mesma razão, atenção e softmax não contêm nenhuma regra que garanta que premissas verdadeiras preservem a verdade durante a geração. Sistemas modernos podem reduzir erros expressos com confiança, mas a alucinação persiste em parte porque o treinamento e a avaliação podem recompensar palpites em vez do reconhecimento da incerteza (Por que os modelos de linguagem alucinam).

Tomamos um cálculo sobre a linguagem e o usamos como um julgamento sobre o mundo. O fechamento existe, mas uma camada abaixo de onde a responsabilidade é necessária. Projection Engineering fornece um fechamento diferente: declara quais Claims, políticas, autoridades e momentos definem o mundo dessa decisão. Regras reproduzíveis podem então calcular dentro dele.

O metro mostra o que o fechamento pode fazer

Em 1983, a 17ª Conferência Geral de Pesos e Medidas definiu o metro como a distância percorrida pela luz no vácuo durante 1/299,792,458 de segundo, fixando a velocidade da luz exatamente em 299,792,458 m/s dentro da definição do SI (Resolução 1 da 17ª CGPM (1983)).

O valor não se tornou exato porque a humanidade finalmente mediu a natureza sem incerteza. Uma comunidade autorizada o transferiu através de uma fronteira: de uma grandeza a ser refinada para uma parte da definição do sistema. As medições abaixo dessa fronteira se tornaram mais precisas porque a fronteira era explícita.

Isso não era uma pretensão de possuir a realidade. Era uma convenção datada, adotada por uma autoridade identificável mediante um procedimento definido e revisável por outro procedimento. Projection Engineering fecha uma decisão no mesmo sentido limitado. Não fecha a realidade. Congela quais Claims podem servir como premissas aqui e agora, sob uma política e uma autoridade nomeadas.

Onde a analogia falha

A metrologia é um guia, não um disfarce para problemas não resolvidos.

Primeiro, a medição comum costuma se beneficiar da repetição. Um pagamento, consentimento, inspeção, demissão ou acidente pode ser um evento único. O modelo mais próximo é a metrologia forense: uma única observação precisa sobreviver a um processo contraditório por meio de artefatos preservados, cadeia de custódia, procedimento documentado e limites conhecidos do instrumento.

Segundo, a incerteza numérica muitas vezes pode se propagar por equações. Proposições não resolvidas ainda não dispõem de uma aritmética igualmente geral. Preservar supported, defeated e unknown ao longo de derivações extensas sem convertê-los em falsa precisão continua sendo um problema de pesquisa em aberto.

Terceiro, declarar uma fonte completa ou uma política vinculante é um exercício de autoridade. A rastreabilidade pode revelar essa escolha, mas não torná-la imparcial. Projection Engineering deve expor quem colocou o dedo na balança; não pode prometer retirar todos os dedos.

GAF não é uma lista

Armazenar apenas um Accepted Fact destrói a informação que o tornou aceitável. Perdemos quem o apresentou, o que o contestou, qual política o admitiu e qual autoridade tornou essa política operante.

O entregável de Projection Engineering é, portanto, um Graph of Accepted Facts (GAF).

Records / Observations
          │
          ▼
        Claims ◀──── Evidence / Counterevidence
          │
          ▼
  Evaluation + Projection Policy
          │
          ▼
   Accepted Facts ─────┐
          │             │
          ▼             │
 Rules / Derivations    │
          │             │
          ▼             │
      Conclusions       │
                        │
 Provenance ────────────┘

Um GAF conecta registros originais, Claims extraídos, evidências favoráveis e contrárias, avaliações, política e autoridade, Accepted Facts, derivações, conclusões, versões, marcas temporais e dependências. Padrões existentes já modelam entidades, atividades, agentes e relações de provenance; PROV-O: a ontologia PROV mostra que esse vocabulário não precisa pertencer a um único produto de banco de dados.

Um GAF também não precisa residir em um banco de dados de grafos. Um banco de dados relacional ou um log somente de acréscimo é suficiente se preservar as relações e a linhagem bidirecional.

  • A partir de uma conclusão, um auditor deve poder percorrer para trás os Accepted Facts e Claims até os registros originais.
  • A partir de um registro invalidado, o sistema deve poder percorrer para a frente até cada Accepted Fact, conclusão e ação autorizada que possa precisar ser reaberta.

O primeiro caminho torna uma decisão auditável. O segundo torna a correção computável.

Um pagamento de aluguel, três problemas de engenharia

Voltemos à disputa do aluguel. O inquilino afirma que pagou. O proprietário diz que não recebeu o valor como aluguel. Um livro-razão bancário mostra que o dinheiro se moveu entre as contas registradas de ambos durante o período acordado, mas a descrição está em branco.

A primeira tarefa é a decomposição de proposições:

A payment moved from the tenant's account to the landlord.  [accepted]
That payment discharged this month's rent obligation.       [undetermined]

A transferência e a imputação jurídica são Claims diferentes. Se outra dívida puder existir, a primeira não implica a segunda. Escolher separá-las não é trabalho administrativo. Em um caso de demissão, perguntar se o motivo declarado existiu, se o procedimento foi seguido, se o motivo justificava a demissão e se o agente tinha autoridade produz grafos de decisão diferentes a partir dos mesmos registros.

Isso é formação de questões, o ofício central de Projection Engineering. Quem formula as proposições determina o que pode ser aceito, derrotado ou deixado como desconhecido. O sistema deve preservar quem fez essa decomposição, com qual finalidade, sob qual autoridade e quais alternativas foram excluídas. Uma provenance perfeita após um enquadramento enviesado apenas documenta o viés com elegância.

O segundo problema é a ausência. Não encontrar um pagamento não comprova a falta de pagamento. O período pode estar errado, a busca pode estar incompleta, a transferência pode estar pendente ou outra instituição pode deter o registro. A ausência se torna evidência somente depois que um contrato de completude define o que a fonte promete conter.

Completeness contract C-04

Declarant: operator of ledger L
Scope: all settled transactions for account A during period P
Excludes: pending transactions and records held by other institutions
Authority: signed policy version V

Só então a ausência pode sustentar uma negação dentro daquele escopo. Declarar completa uma fonte conveniente pode transformar um caso desconhecido em um caso decidível, por isso a declaração deve conter identidade, assinatura, data, versão e autoridade.

O terceiro problema é o julgamento humano repetido. Uma pessoa pode decidir que uma transferência da conta registrada, dentro do período acordado, pelo valor exato e sem dívida concorrente, conta como aluguel apesar da descrição em branco. O ativo reutilizável não é aquela resposta específica. É o julgamento geral por trás dela.

Isso é preservação de decisões, mas um exemplo não deve se transformar silenciosamente em precedente. O julgamento permanece um candidato a política até que uma pessoa autorizada especifique seu escopo, exceções, momento de vigência, retroatividade e condições de revogação. Só então ele se torna uma política ratificada.

Do Claim à ação autorizada

Projection Engineering não é um modelo nem um produto de armazenamento. É o processo que projeta registros de mundo aberto em um mundo de decisão fechado e reabre esse mundo quando as evidências ou políticas mudam.

Reality
   │
   ▼
Records / Observations
   │  preservation · calibration · transformation history
   ▼
Claims
   │  proposition decomposition · source evaluation · conflicts and gaps
   ▼
Projection
   │  purpose · scope · reference time · proof standard · authority · policy version
   ▼
GAF
   │  Accepted Facts · provenance · dependencies
   ▼
Closed Decision World
   │
   ▼
Deterministic Conclusion
   │
   ▼
Authorized Action

Cada transição pode produzir um erro diferente:

  • Deixar de coletar um registro original é um erro de coleta.
  • OCR ou extração de má qualidade constitui erro de transformação.
  • Formular a questão errada ou aceitar o Claim errado é um erro de projeção.
  • Calcular uma conclusão errada a partir de Accepted Facts corretos é um erro de regra.
  • Aplicar uma conclusão correta ao alvo errado é um erro de execução.

Cada um exige um reparo diferente. Novas evidências reparam a coleta. Uma nova avaliação repara a projeção. Um mecanismo de regras corrigido pode reproduzir um GAF congelado. Falhas de execução exigem cancelamento, correção ou compensação — não fatos reescritos. Chamar toda falha de “a IA errou” torna todas elas irreparáveis.

Pague uma vez o custo de compreender

A camada ausente não é apenas um risco. Também é uma fonte de desperdício. Um modelo lê um contrato, identifica as partes, extrai obrigações e responde a uma pergunta. A pergunta seguinte muitas vezes paga novamente grande parte do mesmo custo de interpretação. A recuperação reduz o texto carregado, mas ainda movimenta trechos de prosa porque a unidade reutilizável continua sendo o fragmento de documento.

A compilação semântica muda essa unidade. Um documento é interpretado uma vez como proposições estáveis com identificadores, fontes, escopo temporal e dependências. Perguntas posteriores reutilizam essas proposições entre prompts, usuários e documentos. Pagamos uma vez o custo de compreender, quando o Claim entra no sistema, em vez de toda vez que alguém pergunta sobre ele.

O cache de prompts não pode substituir essa camada. Um cache preserva bytes e ordem. Um GAF preserva significado e provenance. Um cache de prefixo pode falhar quando a ordem muda; uma proposição pode se combinar com Claims extraídos em outro lugar e servir a todas as decisões que dependem dela.

A reutilização significativa cria um problema de invalidação mais difícil. Se uma fonte for corrigida, substituída ou revelada como fraudulenta, quais conclusões devem ser reabertas? Um cache de fatos sem provenance é um cache de alucinações: repete o mesmo erro com mais rapidez e confiança.

Linhagem é invalidação de cache.

A estrutura que permite a uma pessoa contestar uma decisão é a mesma que permite a uma máquina recalcular apenas as conclusões afetadas. Responsabilização e eficiência não são recursos concorrentes aqui. São dois usos do mesmo grafo de dependências.

A fronteira com as disciplinas vizinhas

Projection Engineering não substitui Data, Knowledge, Rule, Prompt ou Context Engineering. Ela assume a fronteira de responsabilidade que essas disciplinas atravessam hoje sem um guardião responsável.

Data Engineering move registros por source → ingest → transform → store → serve. Projection Engineering pergunta se um registro qualifica como informação utilizável como premissa por meio de record → claim → evaluate → project → GAF. Um esquema válido pode conter um registro falso.

Knowledge Engineering representa conceitos e relações para uso por máquinas. Projection Engineering trata primeiro cada relação como um Claim e registra quem autorizou seu uso como conhecimento em uma decisão delimitada.

Rule Engineering calcula conclusões a partir das premissas fornecidas. Projection Engineering constrói e congela o grafo de premissas sobre o qual essas regras operam.

Prompt Engineering molda instruções. Context Engineering seleciona informações para o cálculo. Projection Engineering faz a pergunta anterior: que Claim essa informação representa e por que ela pode servir como premissa aqui?

Um prompt melhor não pode resgatar uma premissa aceita incorretamente.

O LLM é um trabalhador, não a autoridade

Um LLM é um trabalhador dentro desse processo. Ele pode extrair Claims candidatos de registros não estruturados, dividir afirmações compostas, identificar conflitos, solicitar evidências ausentes e traduzir a linhagem para uma linguagem legível.

Ele não é a autoridade. Sua saída é outro Claim. A pesquisa sobre atribuição distingue a geração fluente de afirmações sustentáveis por fontes identificadas (Medição da atribuição em modelos de geração de linguagem natural). A pesquisa sobre fidelidade do raciocínio também mostra que a cadeia de pensamento gerada não funciona de forma confiável como o traço causal de execução de uma resposta (Fazer o raciocínio importar: medição e melhoria da fidelidade do raciocínio em cadeia de pensamento).

Se o mesmo modelo extrai um Claim, aceita-o, escolhe a regra, explica o resultado e autoriza a ação, o pipeline colapsa em uma única geração opaca. Uma narrativa post hoc não é um registro de provenance.

A geração pode ser probabilística. A aceitação de Facts, a completude e a autoridade para agir devem ser governadas separadamente.

A garantia estatística não pode explicar meu caso

A contestação mais forte é prática. As organizações não exigem um traço completo de derivação de cada responsável humano por decisões. Elas monitoram resultados agregados, controles de qualidade e auditorias por amostragem. Por que não governar os modelos da mesma forma?

A garantia estatística é útil e muitas vezes suficiente para melhorar um sistema. Ainda assim, não consegue responder à pergunta feita por uma pessoa dentro de um resultado contestado:

Qual foi a premissa no meu caso?

A precisão agregada não revela qual registro estava errado, qual Claim foi aceito, qual política se aplicou ou qual nova evidência poderia sustentar um recurso. A garantia no nível da população e a contestabilidade no nível do caso resolvem problemas diferentes.

Essa distinção define o escopo. Projection Engineering não se destina a todo sistema de IA. Destina-se a sistemas que tomam decisões contestáveis — crédito, remuneração, elegibilidade, despejo, seguro, autorização médica e ações semelhantes nas quais uma pessoa deve poder inspecionar e contestar o conjunto de premissas. O Framework de Gestão de Riscos de IA do NIST trata responsabilização e transparência como propriedades de todo o ciclo de vida, enquanto o Regulamento (UE) 2024/1689 exige registro de eventos para sistemas de alto risco.

Para uma geração de baixo risco que ninguém precise contestar, essa estrutura pode ser excessiva. O escopo faz parte da engenharia.

O contrato mínimo

Um sistema que afirme praticar Projection Engineering deve responder sim a todas as perguntas a seguir:

  1. Ele distingue registros originais de Claims derivados e anexa a cada Claim a fonte, o momento e o histórico de transformação?
  2. Ele decompõe Claims compostos em proposições contestáveis de forma independente e registra quem formulou as questões e por quê?
  3. Ele preserva Claims conflitantes e alternativas rejeitadas em vez de apagá-los?
  4. Ele distingue false, unknown e not found, exigindo um contrato de completude antes de transformar ausência em negação?
  5. Ele consegue rastrear um Accepted Fact para trás até evidência, política, autoridade e versão — e uma fonte invalidada para a frente até as conclusões afetadas?
  6. Ele consegue reproduzir o GAF exato e o snapshot das regras usados em uma decisão e obter a mesma conclusão sob o mesmo fechamento?
  7. Ele consegue preservar julgamentos humanos recorrentes como uma política ratificada com escopo, exceções e momento de vigência?
  8. A aceitação do Claim, o julgamento pelas regras e a autoridade para agir estão separados, com um procedimento para reabrir, em vez de apagar, uma decisão passada?

Se alguma resposta for não, o sistema está promovendo silenciosamente um Claim a Fact em algum ponto.

Por que esta é uma nova disciplina de engenharia

Os componentes já existem: provenance, gestão de evidências, grafos de argumentação, sistemas de manutenção da verdade, event sourcing, mecanismos de regras, logs de auditoria, apuração jurídica de fatos, metrologia e raciocínio de mundo fechado.

Componentes não são uma fronteira de responsabilidade. Bancos de dados e ETL existiam antes de Data Engineering se consolidar como campo. Servidores e scripts de implantação existiam antes de DevOps. Um campo se forma quando falhas recorrentes dispersas pelas organizações são reunidas sob um papel responsável, uma classe de entregáveis e métodos repetíveis de verificação.

Nenhum papel atualmente assume esta pergunta do início ao fim:

Em que momento, pela autoridade de quem e sob qual política um registro da realidade se tornou um Accepted Fact utilizável em uma decisão?

Engenheiros de dados são responsáveis pelos pipelines. Engenheiros de conhecimento são responsáveis pela representação. Engenheiros de ML são responsáveis pelos modelos. Especialistas de domínio explicam as regras. Operadores lidam com exceções. Entre eles, a aceitação de fatos se dissolve em código de limpeza, prompts, lógica de aplicação, inferência de modelos e hábitos não documentados.

Projection Engineering não afirma que todos os componentes são novos. Ela propõe uma nova disciplina de engenharia porque a própria fronteira precisa de um responsável, um entregável e uma forma determinista de testar se suas promessas foram cumpridas.

Torne a verificação barata novamente

O mundo aberto nunca para. Novos registros chegam, testemunhos mudam, sensores são recalibrados e políticas são alteradas. Um sistema que espera pela realidade completa nunca agirá. Um sistema que oculta a incerteza agirá sem responsabilização.

Projection Engineering escolhe um contrato mais restrito:

  • Preservar Claims em vez de apagar a discordância.
  • Dizer Accepted Fact sempre que Fact significar uma premissa autorizada.
  • Conectar cada aceitação a evidência, política, autoridade, tempo e escopo.
  • Nunca transformar unknown em false sem um contrato de completude.
  • Congelar o mundo de decisão e as regras realmente usados.
  • Reproduzir a conclusão a partir das mesmas entradas fechadas.
  • Preservar julgamentos recorrentes como uma política explícita e ratificada.
  • Reabrir decisões quando as evidências mudarem, em vez de reescrever o passado.

Ela não é dona da verdade, não elimina vieses nem torna as máquinas infalíveis. Torna o mundo limitado usado em uma decisão visível o bastante para ser inspecionado, contestado, reproduzido e reparado.

A matemática adquiriu poder social não porque respondeu a todas as perguntas, mas porque pessoas ausentes de uma derivação podiam inspecionar o que decorria das premissas declaradas. A metrologia deu peso às medições ao cercar números de rastreabilidade. O direito tornou o julgamento possível sem reproduzir o passado ao separar alegações de premissas aceitas.

A IA já tem aritmética. O que lhe falta é a instituição ao redor da aritmética.

O objetivo de Projection Engineering é simples:

Tornar a verificação barata novamente.

A realidade nos dá Claims.

Decisões exigem Accepted Facts.

Projection Engineering projeta Claims em um Graph of Accepted Facts auditável.

Artigos relacionados

  • A verdade não é descoberta — por que a realidade aberta nos dá Claims enquanto mundos institucionais delimitados podem produzir fatos operacionais
  • De Claims a GAF — a arquitetura técnica para projetar Claims em um grafo auditável
  • Fluência não é verdade — por que a linguagem persuasiva deve ser substituída por evidências observáveis e verificações

Fontes