Resumo

  • A revisão de 5 de setembro do draft individual RMRP cria a Routing Completeness Attestation (RCA), na qual o motor assina, por janela, quantos eventos processou e quantos registros gravou. É um Internet-Draft em andamento, não padrão, implantação ou certificação do IETF.
  • Provas de inclusão Merkle e checkpoints externos protegem registros existentes. Uma chamada executada sem gerar registro não tem folha para ser verificada. O próprio RMRP afirma que sua RCA não prova completude.
  • A conciliação com dados do provedor oferece um denominador externo e pode expor gasto sem registro interno. Conta, período, credencial, modelo e escopo precisam coincidir antes que a diferença tenha significado.

Uma árvore de auditoria pode estar impecável e incompleta. Se 20 mil decisões foram registradas, cada uma pode ter assinatura válida, posição comprovada e raiz publicada fora da empresa. A vigésima milésima primeira chamada, feita por uma credencial que pulou o roteador, não quebra nenhuma dessas verificações. Ela simplesmente não está no conjunto.

Essa é a contribuição mais importante da revisão 01 do Reilly Model Routing Protocol. O documento individual de L. J. Reilly, datado de 5 de setembro, pretende ser Informational e permanece em I-D Exists. Não é RFC, consenso do IETF, prova de interoperabilidade ou relato de incidente.

O texto 01 expande o 00 com canonicalização, assinaturas, divulgação seletiva, orçamento agregado, provas de inclusão, âncoras externas, revogação, níveis de conformidade e conciliação de custos. Em vez de tratar “auditável” como uma qualidade única, a proposta separa alteração, inclusão, completude e confirmação por fonte externa.

Integridade começa depois que o evento vira dado

RFC 8785 produz uma representação JSON determinística. RFC 7515 permite verificar a assinatura dessa representação. O resultado diz se os bytes mudaram e qual chave assumiu a declaração.

Uma cadeia de hashes evidencia a ruptura de uma sequência conhecida. A árvore Merkle baseada em Certificate Transparency permite demonstrar que um Audit Log Record pertence à raiz sem transferir o arquivo inteiro. Provas de consistência mostram que uma árvore posterior estende a anterior.

Nenhum desses mecanismos observa a chamada antes da criação do registro. Se a execução ocorre e o sistema suprime ALR e CAR, todos os hashes restantes continuam certos. A raiz autentica um subconjunto. Não existe operação criptográfica que descubra uma folha que nunca foi criada.

Completude requer outro número: quantos eventos deveriam estar ali? Quando o motor fornece o total de eventos e o total de registros, ele mede a própria narrativa. Essa comparação tem valor operacional, mas não é independente.

A âncora externa preserva a versão recebida

O RMRP reconhece que uma tree head assinada pelo mesmo operador que controla o Audit Store não limita esse operador. O Checkpoint publica a raiz em um destino fora do controle administrativo, como serviço de timestamp, log de transparência ou depósito de arquivo.

Um envio PENDING não pode ser descrito como atestado. Vários destinos tornam a alteração retrospectiva mais cara, sem criar imutabilidade. O intervalo também precisa acompanhar qualquer alegação: cinco minutos e um dia deixam janelas de risco diferentes.

Ainda assim, o terceiro recebeu uma raiz, não assistiu a todas as inferências. Se o conjunto estava incompleto antes da publicação, a âncora prova apenas que aquela versão incompleta foi preservada. Independência de custódia não é independência de contagem.

A RCA transforma omissão em contradição assinada

No nível C3, a RCA registra período UTC, engine_id, total de eventos, número de ALRs, contagens por resultado e tier, raiz da árvore, RCA anterior e assinatura. Diferenças exigem uma nota. O elo anterior torna visível o desaparecimento de uma janela inteira.

A chave do Routing Engine deve ser distinta da chave da Policy Authority. Isso separa funções criptográficas, mas não prova que pessoas ou departamentos diferentes controlam as chaves. O draft admite que o protocolo não consegue impor separação organizacional.

Também declara o limite decisivo: a RCA é a afirmação do sistema auditado sobre a própria completude; ela não prova completude. Um operador pode omitir a chamada e assinar uma contagem falsa. O ganho é outro: a ausência silenciosa passa a contradizer uma afirmação com identidade, período e escopo fixados.

Na arquitetura de RFC 9334, evidência, política de avaliação e resultado de atestação são coisas diferentes. A RCA precisa ser avaliada contra fontes independentes; ela não é, sozinha, o selo de aprovação.

A conta do provedor enxerga o outro lado

O Cost Reconciliation Record compara a soma dos custos internos com o valor reportado pelo provedor para o mesmo período e escopo. unattributed_cost_usd registra gasto do provedor sem CAR correspondente. Segundo o draft, a conciliação é o único controle especificado capaz de detectar inferência totalmente realizada fora do Routing Engine.

Essa fonte é causalmente distinta: o provedor mede na outra ponta da API. Chave direta, rota de emergência ou equipe não integrada pode desaparecer do log corporativo e aparecer na conta externa.

Faturamento não é oráculo. Fuso de fechamento, atraso, retry, cache de tokens, arredondamento, desconto contratado e conta compartilhada explicam diferenças legítimas. A comparação deve alinhar conta, credencial, modelo, região, janela UTC, centro de custo e, quando disponível, número de chamadas. Variância abre investigação; não condena ninguém.

Os níveis C2, C3 e C4 acumulam garantias diferentes. C2 assina registros; C3 soma RCA, revogação e orçamento; C4 acrescenta Merkle, âncoras e conciliação. O rótulo sem intervalo, custodiante, escopo e tolerância esconde mais do que informa.

As camadas de realidade de Heng Lu mantêm separados o draft, a declaração de conformidade, a RCA, o log, a conta e a execução observada. Uma assinatura liga evidências, não transfere autoridade factual entre elas. A primazia do código em execução coloca chamada, custo e resultado reconciliados acima da elegância do formato.