Arquivos têm hash. Ativos precisam de identidade.
Sistemas digitais sabem dizer, com precisão, se dois arquivos são exatamente iguais. A pergunta maior é outra: como saber se dois arquivos diferentes representam o mesmo ativo?
Um mesmo ativo existe em muitos arquivos, formatos, sistemas e momentos da sua vida. O conteúdo pode continuar representando o mesmo bem — mas o arquivo já não é o mesmo.
Um contrato existe em PDF, em imagem e em XML.
Uma matrícula imobiliária recebe uma averbação.
Uma nota fiscal é reemitida.
Um documento passa de um sistema para outro.
Sem uma identidade persistente para o ativo, cada nova ocorrência pode ser tratada como um objeto novo. A história do ativo se fragmenta entre documentos, bancos de dados, instituições e blockchains, sem uma referência comum capaz de conectá-los. O resultado pode ser:
O problema não é armazenar documentos. É saber a que ativo cada documento pertence.
São duas ferramentas para duas perguntas diferentes. Uma não substitui a outra.
Mesmo conteúdo, arquivos diferentes, hashes diferentes — e isso está correto. Se um único byte muda, o hash muda. É excelente para provar integridade binária, mas não foi criado para reconhecer o ativo por trás do arquivo.
Os elementos permanentes do ativo são organizados por regras canônicas e convertidos em um identificador determinístico. Mesmo ativo, mesma identidade — em qualquer formato ou sistema de origem.
O protocolo não depende de uma lista prévia de todos os ativos. Depende da regra canônica de cada classe de ativo — as AC⚡Master Keys, que definem o que identifica um imóvel, um veículo, uma duplicata. A primeira ocorrência inaugura a identidade; as seguintes se relacionam a ela.
Reconhecer a identidade é o primeiro passo. A pergunta seguinte é mais importante:
Qual é a relação desta nova ocorrência com aquilo que já está registrado?
O protocolo responde com um entre cinco códigos. A resposta depende também da operação: registrar compara a nova ocorrência com o registro e pode inaugurar uma identidade; consultar informa o estado canônico atual do ativo e nunca cria identidade.
| Situação | Registrar | Consultar |
|---|---|---|
| Documento ilegível | AC⚡INL | AC⚡INL |
| Identidade ou ocorrência não validada com segurança | AC⚡QTN | AC⚡QTN |
| Chave válida, sem identidade existente | AC⚡UNIcria a identidade | AC⚡INLnão localizada |
| Mesma chave, sem diferença documental | AC⚡DUP | AC⚡UNIlocalizada e íntegra, salvo estado adverso já registrado |
| Mesma chave, conteúdo documental diferente | AC⚡PARo protocolo registra o que mudou e sob qual autorização | AC⚡PARsalvo estado adverso já registrado |
Na paridade, o protocolo não qualifica a mudança: registra o que mudou e sob qual autorização — qualificá-la é da instituição. Na consulta, uma vez localizada a identidade, o resultado reflete o sinal mais crítico já registrado para ela, independentemente da ocorrência consultada.
AC⚡UNI em consulta significa identidade localizada e sem estado adverso registrado. Não significa autorização para realizar nova operação sobre o ativo.
Quando as ocorrências de um ativo se conectam à mesma identidade canônica, a história dele passa a existir em um só lugar: o que o ativo era, o que aconteceu com ele, o que mudou e qual é o seu estado atual.
A linha do tempo contém os eventos processados pelo protocolo. O que acontece fora dele não é reconstruído por inferência — por isso cada alteração do ativo deve passar pelo protocolo.
“O hash tradicional responde se dois arquivos são iguais. O AC⚡PROTOCOL Corrente⚡Alternada responde se eles representam o mesmo ativo — e o que aconteceu com esse ativo ao longo do tempo.”
O arquivo pode mudar. O formato pode mudar.
A identidade canônica permanece.
Gera. Verifica. Preserva.