Resumo

  • draft-templeman-scitt-measurement-capsule-00 conserva declaração, observação independente, diferencial, digests e limitações sem registrar autoridade de execução.
  • UNCHECKABLE não é falha, sucesso, zero nem ausência; uma leitura parcial não permite afirmar que algo não existe.
  • JCS, Merkle, assinatura, Receipt e timestamp comprovam etapas diferentes. A decisão operacional precisa identificar separadamente principal, política, escopo, recurso e recurso de contestação.

Uma cápsula pode estar perfeitamente incluída em uma árvore e ainda descrever uma medição ruim. A raiz confirma que aquele identificador pertence ao conjunto escolhido pelo emissor. Ela não confirma que o emissor escolheu uma população justa, observou o endpoint certo ou usou um instrumento adequado.

Essa diferença entre membership e verdade organiza Declared-versus-Observed Measurement Capsules. Em 2 de outubro de 2026, o Datatracker mostrava a revisão 00 como Individual Submission ativa, submetida em 27 de setembro e válida até 31 de março de 2027. O texto pretende status Experimental, sem stream IETF e sem Area Director responsável. Não é RFC, consenso, adoção, certificação ou prova de operação.

O objeto proposto é emitido por um terceiro que não deveria ser o sujeito nem participante da ação. Ele guarda bytes declarados, uma observação obtida em outra fonte, diferença estruturada, digests, estado, horário e limites. Seu authority_state diz apenas medição; nenhuma autoridade de execução é concedida.

Toda comparação traz duas cadeias de custódia

A declaração tem artefato, versão, localização, horário e digest. Um manifesto em cache e um registry atualizado podem falar de momentos diferentes. O nome do sujeito não resolve essa divergência.

A observação tem vantage, credential, request, parser, timeout e relógio. Ler um protocolo ao vivo, validar signature, verificar state proof e refazer uma avaliação são métodos distintos. Uma resposta vista de uma região não descreve necessariamente todas as regiões.

O diferencial deve nomear campos diferentes, sem escolher o verdadeiro. INCONSISTENT não prova mentira, culpa ou necessidade de ação. A declaração pode estar antiga; a observação também; ambas podem valer para scopes diferentes.

A evidence ladder mantém essa modéstia. Prova verificada contra o commitment de um block header não mostra que o header foi validado contra consenso. Resposta de operator API continua sendo afirmação do operador. Um label não pode ser promovido porque o consumidor deseja um score conclusivo.

Preservar UNCHECKABLE impede a fraude do denominador

Quando uma página termina cedo, um ledger exige permissão ou uma identity check falha, o resultado é UNCHECKABLE. O draft proíbe convertê-lo em pass, fail, zero ou omissão. NOT_LISTED só cabe após leitura completa; total não pode nascer de leitura parcial.

Excluir linhas ilegíveis melhora artificialmente a taxa. Contá-las como zero a piora artificialmente. O sistema deveria mostrar população elegível, tentativas, leituras completas e exceções.

O emissor também escolhe quem entra no batch. Se selecionar principalmente sujeitos propensos a divergir, cada cápsula pode estar correta e o agregado permanecer enganoso. Por isso o batch record deveria publicar inclusion rule e contagem de exclusões por razão. Estados de batches com regras diferentes não são comparáveis.

O schema não deve carregar uma decisão escondida

Fora authority_state, nomes ligados a decision, allow, reject, approve, admit, permission, enforcement, action ou gate são proibidos, assim como alguns valores exatos de autorização e negação. A meta é impedir que a cápsula seja consumida como gate.

A denylist nunca cobre todos os sinônimos; o próprio texto considera allowlists por kind. O controle decisivo está fora do objeto. Se um marketplace converte INCONSISTENT em bloqueio, ele precisa emitir outro record com principal autorizado, policy version, threshold, scope, duração, notice e appeal.

Assinar evidência não transfere ao medidor a responsabilidade pela perda do sujeito. Mesmo quando a mesma empresa mede e decide, as duas funções precisam permanecer identificáveis.

Cinco recibos não viram um só

capsule_id é SHA-256 sobre bytes JCS RFC 8785 sem o próprio campo. O arquivo guarda esses bytes exatos. IDs ordenados alimentam uma Merkle Tree Hash RFC 9162; audit path prova inclusão.

COSE_Sign1 liga issuer key e protected headers ao payload ou Hash Envelope. Um Transparency Service SCITT pode registrar o Signed Statement e devolver Receipt. Um mecanismo temporal pode atestar existência do commitment quando a prova chega ao estado adequado.

Hash identifica conteúdo. Merkle prova membership. Signature atribui bytes a uma key. Receipt prova registro sob uma política. Timestamp limita tempo. Nenhum calibra instrumento, completa amostra, garante independência, obtém endorsement do sujeito ou justifica sanção.

O draft alerta que uma chave válida também assina dados falsos. Comprometer a key ou o credential do signing service permite reescrever e assinar uma cadeia. Só um anchor anterior, mantido fora desse domínio de controle, pode revelar a substituição.

Referência de efeito preserva emissores distintos

effect_reference pode apontar ao digest exato de outro Signed Statement, mas não copia seu outcome. Assim approval, execution e independent measurement podem ser correlacionados sem parecer uma única autoridade.

Approval não prova efeito; action receipt não prova postcondition; measurement não revoga autorização; transparency não reconcilia significados. O consumer faz a junção e produz decisão própria.

O protótipo ainda não usa effect_reference. É uma composição proposta, não interoperabilidade demonstrada.

Correção acrescenta história; não desfaz consequência

Uma cápsula nunca é editada. Correction cria novo objeto e novo batch, aponta para o anterior e registra before, after e motivo. O record substituído permanece. Mudanças em canonicalization ou Merkle também geram IDs novos.

Isso conserva o que o consumer viu no momento da decisão. Também impede apagar um erro após registro. O sujeito precisa de canal de correção/exclusão; consumidores precisam detectar supersession, reavaliar score e gate, e registrar restauração.

Uma correção sem rollback apenas torna o erro auditável. Se credential, contrato ou ranking continua perdido, falta o principal que controla a reparação.

Digest privado ainda pode ser adivinhado

Guardar somente digests reduz exposição direta, mas um valor privado de baixa entropia pode ser enumerado. O draft recomenda blinding e informa que o protótipo não o implementa.

Também recomenda medir só superfícies publicadas para máquinas, não enviar credentials e parar a leitura MCP em discovery. O resultado pode ser mais UNCHECKABLE; isso é melhor que aprofundar coleta sem autoridade.

Como registros append-only não retiram cápsulas erradas, privacy review deve ocorrer antes do registro e cobrir entropia, linkability, retenção e remédio.

Running code de um autor não é prova de ecossistema

O texto relata que a organização do autor construiu 13.184 cápsulas em oito batches e sete kinds, com compromissos OpenTimestamps/Rekor, verificador web e checker separado. São afirmações de implementação fornecidas pelo autor.

O checker é da mesma organização e o draft diz que ele não é implementação independente. Faltam COSE_Sign1, registro num Transparency Service SCITT, effect_reference e blinded digests.

O experimento pede implementação por outra parte, reprodução de IDs/roots, registro por serviço externo, verificação do Receipt por terceiro, referência entre issuers e correções sem perda de batches. Se nenhum resultado surgir em duas revisões, o autor promete retirar o draft. Essa condição é um indicador de maturidade mais forte que volume interno.