Resumo

  • draft-dogru-cedulon-decision-profile-02, de 5 de setembro de 2026, é um Internet-Draft individual ativo, sem endosso ou posição formal da IETF, sem RFC stream e sem Area Director responsável.
  • O perfil reconcilia Decision Records assinados com linhas autenticadas de um Effect Extract. Um allow espera um efeito; deny e defer não esperam nenhum.
  • A revisão 02 afirma que o vínculo não ordena os dois relógios. A data da linha é verificada contra a janela do extract, e não contra a data do Decision Record correspondente.
  • effect-against-refusal mostra que uma recusa e um efeito com a mesma referência coexistem na população auditada. Não prova sozinho que o efeito veio depois nem onde o controle falhou.
  • Uma prova de sequência deve ser separada, nomear a autoridade de cada relógio e a tolerância, e conservar quatro resultados: antes, depois, dentro da margem e indeterminado.

Uma conta que não fecha

O Datatracker classifica o texto de Emek Can Doğru como a revisão 02 de um active individual Internet-Draft, atualizado em 5 de setembro. Também deixa o limite institucional explícito: qualquer pessoa pode enviar um I-D; este não tem endosso nem posição formal no processo da IETF. Não há RFC stream, Responsible AD ou telechat date. O estado no IESG é apenas “I-D Exists”.

O mecanismo trabalha com duas populações. De um lado, o Decider assina um registro dizendo se o agente pode agir. Do outro, um canal, ou o processo que captura suas atividades, autentica a lista de efeitos ocorridos em uma janela. O verifier fecha a auditoria sobre um Decider, um canal e uma janela declarados.

Uma permissão deve encontrar exatamente uma linha sob a mesma ref, com effectHash e effectClass iguais. A ausência vira decision-without-effect. Uma linha sem decisão vira effect-without-decision. Uma recusa — deny ou defer — não espera linha; se uma aparece sob sua referência, o finding é effect-against-refusal.

O nome separa esse caso de um efeito sem decisão alguma, o que é útil. Mas a revisão 02 congelada mostra por que o finding não deve ser narrado como “o agente agiu depois de ser recusado”.

A janela não compara o par

Tanto o Decision Record quanto a linha carregam timestampMs. O algoritmo atual não coloca esses dois números em ordem. Ele apenas exige que a linha caiba em [windowStartMs, windowEndMs). Uma linha anterior ao registro ainda faz o vínculo como se fosse posterior. Conteúdo, classe e referência são medidos; sequência, não.

Pense em uma linha às 10h00 e uma recusa às 10h01. O relatório pode emitir effect-against-refusal, embora a ação aparente ter ocorrido primeiro. Também pode haver relógio adiantado, assinatura tardia, reconstrução do log ou horários escritos por processos diferentes. A combinação das populações continua real. A história temporal continua aberta.

O perfil tem outros controles de tempo. Uma linha fora da janela torna todo o extract malformado. Itens perto do corte entre janelas podem ser adiados ou carregados sob a regra herdada, cujo default no companion é cinco minutos. Essas salvaguardas definem o escopo da auditoria e reduzem falsos vazios na borda. Não estabelecem que os relógios do Decider e do canal tinham a mesma origem ou sincronização.

Assinaturas também não resolvem essa relação. Elas fixam os valores sob determinadas chaves; não mostram quando o valor foi criado, se o relógio estava correto ou se o timestamp foi preenchido depois. A própria seção de trust roots condiciona a garantia à independência entre quem atesta as decisões e quem atesta os efeitos. Integridade interna e cronologia histórica são propriedades diferentes.

Preservar o finding sem exagerá-lo

O relatório deve manter effect-against-refusal como resultado de conservação. Existe um efeito sob uma referência que a população de decisões classifica como recusa. Isso merece investigação. O draft, porém, diz que o finding não localiza a falha: entrega de controle, enforcement, rota alternativa ou captura podem estar envolvidos.

“Efeito presente sob referência recusada” é uma frase suportada. “Agente executou depois de receber a recusa” acrescenta ordem, entrega e capacidade de obedecer. Essa ampliação pode mudar escalonamento de incidente, responsabilidade contratual e decisões disciplinares. Por isso ela precisa de evidência própria.

O princípio de Heng Lu sobre registros exatos oferece uma contenção editorial: o registro descreve a realidade, não a cria. Neste caso, a reconciliação descreve campos e comparações que realmente possui. Não cria uma precedência omitida do cálculo. É uma leitura de Daniel Kade, não uma norma atribuída à IETF ou ao Cedulon.

Um recibo temporal em quatro estados

O resultado de sequência pode ser anexado ao finding existente. A mesma dupla pode legitimamente receber effect-against-refusal e sequence-indeterminate. O primeiro fala da população; o segundo, da força da prova de ordem.

O recibo deve identificar os dois registros por hash dos bytes assinados. Para cada horário, deve indicar a fonte do relógio, quem a controla, como o valor foi capturado e se houve compromisso anterior à auditoria. Também deve publicar a tolerância e a razão operacional para escolhê-la.

Quatro saídas bastam: antes, quando o efeito precede a recusa além da incerteza; depois, quando sucede além dela; dentro-da-margem, quando a diferença não supera o skew; e indeterminado, quando procedência ou sincronização não permitem comparar.

Contadores monotônicos, sequência do canal, timestamp confiável, checkpoint ou observação independente podem reforçar a conclusão. Cada um traz sua autoridade. Um contador mantido pelo Decider não cria independência; uma sequência do canal não prova quando a política chegou ao agente. Mesmo depois estabelece precedência sob premissas declaradas, não causa, culpa ou falha de enforcement.

Running code deve testar o limite

A seção de Implementation Status, nos termos da RFC 7942, relata vinte casos de conformidade e quatro fixtures offline no repositório do autor. Ela também registra os limites: a revisão 02 muda texto e não acrescenta caso; a ordem dos relógios é descrita, não aplicada. Não há medição de log de canal real, implementação independente conhecida ou precommitment temporal nas fixtures públicas.

O próximo avanço verificável seria um conjunto com linha claramente anterior, claramente posterior, diferença dentro da margem, relógios incomparáveis e data inserida após o fato. O teste mais importante deve provar que “indeterminado” chega intacto ao relatório. Um sistema confiável não é o que sempre acusa; é o que sabe quando a evidência terminou.

Fontes

  1. IETF Datatracker: Cedulon Decision Profile
  2. Arquivo IETF: draft-dogru-cedulon-decision-profile-02
  3. Repositório companion do Cedulon
  4. IETF Datatracker: draft principal do Cedulon
  5. RFC 7942: Improving Awareness of Running Code
  6. RFC Editor: How RFCs Are Created
  7. Heng Lu: The Bill of Rights of Uniqueness Coordination