Resumo

  • draft-mih-agent-settlement-records-00 faz pagador e recebedor selarem apenas o que cada sistema observou. O estado combinado é derivado por um verificador; nenhuma ponta pode declará-lo sozinha.
  • Pagamento e entrega são independentes. O texto admite pagamento agreed com entrega none, portanto duas observações financeiras compatíveis não provam que o bem, conteúdo ou serviço foi entregue.

Uma transação pode fechar nos livros e continuar aberta no mundo. Essa é a distinção central de Two-Party Settlement Records for Agent Payments, revisão 00, registrada no Datatracker em 2 de outubro de 2026.

O modelo organiza até quatro pontas: termos, observação do pagador, observação do recebedor e entrega. Cada selador fala apenas sobre o próprio sistema. A evidência recebida da contraparte pode ser citada por digest, mas não pode ser reescrita como observação própria.

Nenhuma ponta contém o veredito geral. O verificador valida cápsula, envelope, estrutura, valores, objetos embrulhados, coerência de papel e sua política de chaves. Só então agrupa registros por referência de termos e referência tipada de pagamento para derivar um estado a partir dos bytes aceitos.

Uma única voz continua sendo alegação. payer_stated relata a saída observada pelo pagador; payee_stated, a entrada vista pelo recebedor. A falta da outra ponta não é discordância: ela pode ainda não existir, não ter sido compartilhada ou nunca ser produzida. O rascunho de solicitação de evidência distingue resposta, recusa assinada e ausência registrada.

agreed exige duas pontas associáveis, chaves distintas aceitas, a mesma referência normalizada, o mesmo status e uma regra exata de valor. O que saiu do pagador deve ser igual ao recebido pelo beneficiário mais a tarifa de recebimento, no mesmo ativo e numa escala comum. Não há tolerância. Ignorar a tarifa, por outro lado, classificaria como divergência uma diferença honesta.

Mesmo um acordo perfeito não prova conformidade com os termos. As duas pontas podem concordar sobre quanto circulou e ambas divergirem do valor contratado. A aceitabilidade de uma tarifa depende dos termos e da política comercial, não da simetria criptográfica.

A entrega tem outro eixo. Sem registro de entrega, none. Com um único registro não contraditório, stated. Com digests iguais do conteúdo enviado e recebido, matched. Com digests incompatíveis entre si ou com os termos, mismatch. A combinação inversa também existe: entrega compatível e pagamento apenas payee_stated.

Digest igual delimita bytes, não encerra toda obrigação. Ele não comprova sozinho qualidade, prazo, desempenho de software, autoridade de aceite ou fim de garantias e recursos. Esses juízos dependem da natureza do que foi prometido.

Os status financeiros são igualmente perspectivos. settled significa final no lado do selador — débito para o pagador, crédito ou recebimento para o beneficiário. O modelo prevê reversed e recomenda que uma observação posterior substitua a anterior. Não há promessa universal de irreversibilidade.

Duas chaves diferentes também não nomeiam automaticamente duas contrapartes legítimas. O rascunho deixa a política de vínculo entre chave e parte fora de escopo. Chaves distintas impedem uma única chave de fabricar as duas metades, mas cada identidade ainda precisa ser aceita pelo verificador.

Objetos já assinados são carregados por digest e não podem ser assinados novamente. A assinatura externa prova inclusão, não autoria do objeto original. Um recibo SCITT prova registro numa transparência específica; não prova veracidade nem transforma uma ponta unilateral em acordo bilateral.

O documento continua sendo Internet-Draft individual, sem stream ou nível normativo no Datatracker. Seus mapeamentos para x402, AP2, Payment HTTP, Open Payments, Lightning e ISO 20022 são propostas do próprio texto, não adoção comprovada por esses ecossistemas.

A Especificação Inicial Mínima de Lu Heng recomenda compartilhar a menor forma que permita juntar observações e manter local a decisão de consequência. Running-Code Primacy pergunta quais objetos, chaves, normalizações e substituições realmente rodaram. Reality Layers separa observação assinada, acordo financeiro, entrega e cumprimento contratual.

O recibo operacional deve preservar todas essas camadas: pontas presentes, falhas, política de chaves, estado do pagamento, comparação com termos, estado da entrega, verificação de objetos, cadeia vigente e ação local. Assim uma disputa encontra a fronteira exata da concordância.

Fontes