Nesta página

The Legible Protocol

Especificação · Rascunho 0.4 · Schema v2 · 26 de outubro de 2026

Legible Protocol, ou Legible, define um formato aberto de arquivos para declarar contribuições, suas dependências e consequências reconhecidas por quem as recebeu. The Legible Protocol é o título desta especificação.

Resumo. A gramática contém três registros assinados e endereçados por conteúdo: Appoint — formulei isto; Trace — isto dependeu daquilo; Nod — isto produziu consequência para mim. Uma contribuição pode ser registrada antes de ser selecionada para uso. Essa condição, chamada Open Legibility, permite preservar formulações para consideração posterior. A seleção continua com quem decide usar, executar ou financiar o trabalho.

Idioma e edição. O português é a fonte normativa primária do rascunho 0.4. spec/legible-EN.md é a tradução inglesa de referência sincronizada. Divergências técnicas são erratas de conformidade a resolver nos dois textos e nos testes. Nomes de campos, enums, canonicalização e identificadores criptográficos são comuns aos dois idiomas e não são traduzidos nos registros. Texto: CC BY 4.0; código de referência identificado como tal: Apache-2.0 (§16).

Estado e escopo. Esta especificação é um RASCUNHO, não uma edição estável ou certificação. A base inicial utiliza legible/protocol/v2/..., com NCO e NRC canônicas em português e traduções inglesas de referência. Edições não suportadas permanecem distintas de registros malformados sob uma edição suportada.

Como consultar. A seção 1 apresenta a proposta; §2 explica os registros; §3 define seus formatos e verificações. As seções 7.1 e 9 tratam da convenção de reconhecimento e das alegações de conformidade. As seções 5, 10 e 11 definem capacidades opcionais; §12 é um anexo experimental de identidade. Há também requisitos para funções específicas em outras seções, como autoria (§2.1), serviços e portabilidade (§8), segurança (§14) e testes (Apêndice D). Este mapa não torna essas passagens meramente informativas.

MUST significa requisito obrigatório; MUST NOT, proibição; SHOULD e SHOULD NOT, recomendação forte cuja exceção precisa ser compreendida; MAY, permissão. Esses termos têm os significados BCP 14 apenas em maiúsculas. Um requisito vincula a capacidade ou função nomeada, não toda atividade de um produto que utilize os arquivos.

O Apêndice A contém os bytes canônicos da NRC 0.2; B apresenta exemplos fictícios assinados; C orienta a verificação de implementações; D identifica os artefatos de conformidade. O Apêndice E reúne a fundamentação econômica informativa. Uma edição futura deve fixar especificação, schemas e testes sob identificadores imutáveis. Um arquivo mutável de repositório não substitui silenciosamente esta especificação. Divergência entre norma e teste é uma errata a resolver.

1. O que é o protocolo e por quê

O formato permite preservar o que uma pessoa formulou, em que um trabalho se apoiou e qual consequência outra pessoa declarou ter recebido. Cada declaração tem seu autor. Um assistente pode ajudar a preparar o conteúdo; recomenda-se que a pessoa revise a declaração exata e aprove cada assinatura (§2.1).

A área de exemplos acompanha situações fictícias de prestação de serviços, pesquisa e desenvolvimento e coordenação de equipes. Cada caso mostra quem formula uma contribuição, como declara suas dependências e quem reconhece uma consequência recebida. Os exemplos ilustram usos possíveis; não relatam resultados observados nem acrescentam requisitos aos formatos definidos nesta especificação.

Um registro é um arquivo. No perfil básico de identidade, sua integridade e assinatura podem ser conferidas offline a partir desse arquivo. Relações entre registros e provas temporais opcionais exigem seus próprios dados e verificações (§3.6, §13). A assinatura atribui a declaração a uma chave; o leitor avalia suas alegações e evidências.

Os participantes constituem espaços Legible com suas ferramentas, condições de acesso e práticas. Não há servidor, conta, cadastro, índice, token, blockchain ou operador obrigatório. Git é o suporte recomendado para preservar e distribuir arquivos, sem ser condição de validade. Serviços de busca, hospedagem ou pagamento têm suas próprias operações e responsabilidades (§8, §16).

1.1 A condição a que o formato serve

Open Legibility permite formular e preservar contribuições antes da seleção para uso.

Nesta seção, um espaço de coordenação é o conjunto de pessoas e contribuições que alguém pode considerar ao decidir o que fazer. Pode ser uma equipe de uma empresa ou um projeto aberto. A condição permite que uma ideia seja registrada antes de receber uma tarefa, posição ou financiamento.

A existência de um registro pode ser conhecida sem que todo o seu conteúdo seja acessível. Saber quem formulou algo e de que depende pode ajudar uma decisão, respeitadas as condições de acesso. A contribuição pode continuar disponível para outra leitura onde alguém a preserve. Isso não assegura sua descoberta ou audiência.

Git já separa o commit local da aceitação num repositório remoto. Legible aplica essa separação às declarações de formulação, dependência e consequência. O alcance prático depende do espaço que os participantes mantêm, das fontes que podem consultar e dos recursos para preservação e leitura.

1.2 O que permanece independente da seleção

Uma pessoa, projeto ou organização pode apresentar questões e condições de participação numa página, preservar contribuições numa coleção e permitir sua leitura nas ferramentas dos participantes. Estes também podem formular problemas que nenhum mantenedor listou. Espaços públicos, internos e combinados usam a mesma gramática, com suas condições de acesso e confidencialidade.

Preservar uma contribuição, apresentá-la e incorporá-la a um acervo mantido são decisões distintas. Issue, PR, commit ou assinatura Git não constituem automaticamente uma declaração Legible. O merge não comprova uso ou consequência recebida e não gera Nod. Para considerar propostas não incorporadas, o leitor precisa consultar suas referências acessíveis; o checkout do branch principal não inclui suas alterações. A continuidade independente permanece sujeita a direitos, acesso e confidencialidade. O guia informativo está em docs/open-legibility.md.

Um Appoint não exige alocador, posição em ranking ou financiador. Serviços podem definir escopo, cobrar, autenticar, moderar e limitar recursos. Recusar ou remover um registro de um serviço não o invalida por si só no protocolo.

O formato mantém independente	A implementação ou o leitor decide
Criar sem admissão por autoridade canônica	Aceitação e publicação em um serviço
Formular antes da alocação	Atribuir, priorizar, executar ou financiar
Verificar sem índice canônico	Fontes e índices consultados
Preservar sem pontuação oficial	Critérios e julgamentos utilizados
Registrar consequência retrospectivamente	Estimativas e compromissos anteriores
Transportar registros	Arranjos legítimos de acesso e armazenamento

Appoints não exigem responsável designado, prioridade ou status de workflow. Aplicações podem organizar trabalho com metadados externos opcionais. Essa organização não é condição de validade. Portabilidade não garante alternativas economicamente equivalentes; a concentração de um serviço pode criar uma barreira prática mesmo quando seus arquivos são portáteis (§8.1).

1.3 Por que isso pode ser viável agora

Assistentes podem ajudar a descrever o trabalho e a buscar material acessível segundo a pergunta do leitor. A hipótese é que reduzir esses custos amplie as contribuições disponíveis para consideração, preservando tempo e recursos como limitações reais. O Apêndice E apresenta o argumento econômico, suas referências e limites. Essa fundamentação é informativa e não condiciona a validade dos registros.

1.4 Limites da interpretação

O formato torna declarações atribuíveis e examináveis. Credibilidade depende de evidência, contexto, interações e julgamento. Uma chave não identifica automaticamente uma pessoa única ou sua identidade civil.

A descoberta depende de quem preserva, disponibiliza, recupera e lê os arquivos. O CH (§5) fornece contexto privado para interpretar fontes acessíveis. A presença de registros ou de uma ferramenta de busca não garante que uma fonte seja encontrada.

Registrar uma formulação não reserva um problema, não certifica prioridade e não cria direito automático a pagamento. Direitos de uso, acordos e efeitos jurídicos seguem seus próprios instrumentos e a lei aplicável (§7.2, §16).

1.5 O que um registro assim precisa sustentar

Preservar proveniência não basta para assegurar que um serviço ofereça contestação, transporte ou leituras alternativas. A tabela distingue o formato dessas condições.

Propriedade	O formato fornece	O que depende do contexto
Registro independente	Sem admissão canônica ou alocação prévia	Recursos e admissão local
Sem leitura canônica	Sem pontuação ou alocação oficial	Diversidade e alcance dos leitores
Declarações atribuíveis	Assinaturas distinguem quem afirma	Verdade, continuidade e credibilidade
Evidência temporal externa opcional	Lugar para provas de existência anterior	Confiança, disponibilidade e política de verificação
Reconhecimento soberano	Sem montante obrigatório ou cobrança	Incentivos, apoio e acordos externos

O Nod do beneficiário, o Trace de origem do autor e o Trace de um curador são proposições diferentes. A leitura precisa preservar seus declarantes. Um custo reputacional por alegações falsas depende do contexto; a assinatura não o impõe.

1.6 Relação com outros instrumentos

Categoria próxima	A diferença
Sistema de reputação	Não define pontuação oficial; leituras são contextuais
Currículo ou portfólio	Formulação, dependência e reconhecimento são atos separados
Citação acadêmica	Traces estruturam relações e reconhecimento posterior; citações já podem declarar dependência
Avaliação de desempenho	Nod declara consequência sem escala fixa ou fundo obrigatório
Plataforma de matching	Descoberta e alocação são externas; o formato não aloca
Blockchain de contribuições	Não há saldo global ou ledger de consenso
Perfil público	Projeção pública é opcional; CH e registros privados são estados legítimos

Proposição	O que pode ser estabelecido
Esta chave assinou a declaração	Sim, com verificação bem-sucedida do conjunto de assinatura especificado
A dependência realmente existiu	Não pela assinatura isolada
Um humano revisou pessoalmente	Não pela assinatura isolada
O conteúdo assinado existia até T	Apenas sob provas externas verificadas e suas premissas
Alguém recebeu consequência valiosa	O Nod estabelece que seu autor a declarou
Ninguém se beneficiou ou reconheceu	A ausência acessível não estabelece nenhuma dessas conclusões
O autor descobriu primeiro ou possui a ideia	O protocolo não determina

1.7 Recursos e decisões de uso

Tempo, capital comprometido, capacidade e risco continuam limitados. Quem oferece um recurso decide sua utilização, sujeito aos próprios compromissos e obrigações. Preservar uma contribuição para consideração futura não dá direito aos recursos de terceiros nem garante cooperação ou financiamento.

1.8 Rascunhos e registros — duas camadas

Legible define registros formais e um perfil opcional de rascunhos. Nenhum exige tarefa atribuída, organização ou operador central.

Um rascunho é Markdown não assinado com cabeçalho estruturado (frontmatter) para preservar formulações, dependências declaradas e mudanças de direção. Legible adota o perfil Genealogy 0.1, em profiles/drafts.md, e sua fonte única de formato. Participar inteiramente nessa camada é um uso completo. Uma proposta informal de reconhecimento permanece distinta de um Nod assinado.

Um registro é um artefato assinado e endereçado por conteúdo. Seu ID deriva do conteúdo; a assinatura vincula esse ID à chave. Evidências externas de anterioridade são opcionais e podem sustentar que o conteúdo existia até uma data, sob suas premissas de verificação (§13). O autor formaliza uma formulação emitindo um novo Appoint, podendo referenciar o rascunho como evidência (§3.1). O rascunho original permanece separado.

Materiais de apoio. Open Legibility é também o título do livro que desenvolve a prática mais ampla. A Economia da Legibilidade apresenta o argumento econômico. Ler essas obras não é requisito de participação ou validade. O site legibleprotocol.com publica a especificação, materiais e códigos de referência; não oferece um serviço de hospedagem da colaboração.

2. A gramática: três primitivas

Appoint: formulei isto. Trace: isto dependeu daquilo. Nod: isto produziu consequência para mim. .response e .redaction são anotações de ciclo de vida, não primitivas adicionais. Propostas, disputas, alocação e reconhecimento podem ser organizados sem tornar os workflows de uma aplicação requisitos universais.

Neste documento, o core é o conteúdo que determina o ID do registro, armazenado em canonical_content. A assinatura vincula esse ID à chave do autor. O envelope reúne esse conteúdo, o ID, o tipo, a assinatura e eventuais metadados externos. A seção 3 define quais campos pertencem a cada parte.

2.1 Git e identidade básica

Um cliente de autoria é a ferramenta usada para preparar ou assinar registros. As recomendações desta seção orientam essas ferramentas e quem as implementa.

Git permite guardar versões, comparar mudanças e distribuir os arquivos. Cada registro Legible tem sua própria assinatura e pode ser verificado fora do repositório. Um commit assinado ajuda a atribuir uma mudança no Git; o nome e a data informados no commit, sozinhos, não comprovam autoria ou horário.

No perfil básico, o autor é identificado por uma chave pública Ed25519, representada como did:key. Pode gerar essa chave sem criar conta ou obter cadastro central. Essa identificação não demonstra que a chave pertence a uma pessoa única: ela pode ser compartilhada ou transferida. O perfil básico também não permite trocar a chave mantendo o mesmo identificador. A §12 discute uma proposta experimental para essa continuidade de identidade.

Clientes SHOULD apresentar a declaração exata e obter aprovação humana específica para cada assinatura. Agentes SHOULD NOT ter acesso desacompanhado à chave. Exceções SHOULD explicar automação e custódia; não são detectáveis na assinatura comum e não a invalidam por si.

Clientes SHOULD proteger a custódia, limitar permissões e vincular confirmação ao conteúdo efetivamente assinado. Hardware deve corresponder à suite: FIDO não é automaticamente equivalente a Ed25519 simples. Biometria e toque podem proteger acesso sem provar compreensão. Aprovação humana é possível sem interface gráfica.

O autor do registro é quem faz a declaração. Essa pessoa pode ser diferente do autor da obra citada, de quem aprova a assinatura, do operador do serviço e do autor desta especificação. Usar o formato não reúne essas funções numa única responsabilidade (§16).

2.2 Appoint — declarar o que se formulou

Um Appoint permite registrar um problema ou uma proposta antes que alguém decida executar ou financiar o trabalho. A pessoa pode declarar apenas o problema: não precisa apresentar uma solução pronta. Também pode registrar uma solução e indicar o trabalho em que se apoiou. A evidência é opcional, porque a própria formulação pode ser a contribuição; quando houver uma solução executada, referências permitem examiná-la.

A formulação fica no conteúdo assinado, chamado core. Código, conjuntos de dados e documentos de apoio podem permanecer em arquivos externos. Publicar um Appoint revela seu core inteiro; materiais adicionais podem ter outras condições de armazenamento e acesso.

O autor informa suas preferências sobre reconhecimento monetário e não monetário nos campos definidos em §3.1. Essas preferências orientam os clientes. Não impedem terceiros de assinar declarações ou realizar transferências externas, nem concedem autorização de uso da obra ou indicam destino de pagamento.

Há três informações temporais distintas: created é a data que o autor declara no registro; published é um metadado opcional de publicação, fora da assinatura; provas externas podem sustentar que o conteúdo já existia até determinado momento. Nenhuma delas estabelece prazo de reconhecimento ou prioridade jurídica automática.

Uma aplicação que exige confirmação por testemunhas independentes adota uma política diferente daquela que aceita a data mais antiga alegada por qualquer testemunha. Push Git, TSA e log público fornecem evidências com premissas de confiança diferentes (§§13–14).

2.3 Trace — declarar dependência ou descobrir genealogia

Um Trace declara em que trabalho uma contribuição se apoiou. O autor pode incluir Traces de origem ao assinar seu Appoint. Depois, ele ou outra pessoa pode emitir Traces separados para declarar relações adicionais. Quem assina um Trace faz sua própria afirmação, mesmo quando não é autor de nenhum dos trabalhos relacionados. Por isso, um Trace de um curador não deve ser lido como declaração do beneficiário.

Essas relações formam a genealogia declarada do trabalho. Elas podem alcançar artigos, commits, bibliotecas e documentos externos ao Legible. Citar uma obra não cria um autor Legible para ela nem significa que seu autor adotou a NRC. Sua proveniência e seus direitos podem ser estabelecidos por outros meios.

Uma contribuição antiga pode ser registrada depois do trabalho que a usou. Por isso, não há regra target.created < source.created para dependências. O hash identifica o conteúdo referenciado; não determina quando a contribuição intelectual foi formulada.

O conjunto de relações pode conter referências inacessíveis, discordâncias e ciclos. Um leitor que apresenta uma genealogia sem ciclos precisa informar como selecionou as relações e quais premissas utilizou. Essa apresentação não invalida as assinaturas do conjunto original. Ferramentas que percorrem o grafo precisam tratar ciclos e nós repetidos com segurança.

Os pesos expressam sugestões de atribuição feitas pelo declarante. Não são dívidas nem percentuais obrigatórios de pagamento. Para examinar uma relação contestada, o leitor precisa ter acesso às afirmações concorrentes e às evidências pertinentes.

2.4 Nod — reconhecer consequência recebida

Um Nod é a declaração de quem recebeu uma consequência de uma contribuição. O beneficiário descreve o que aconteceu e como escolhe reconhecer esse efeito. O reconhecimento é retrospectivo: a consequência já ocorreu. O Nod não é uma nota de qualidade nem determina o valor da contribuição para outras pessoas.

Há três formas de reconhecimento:

• reputational: declara a consequência sem transferência monetária neste registro;
• monetary: declara a consequência e o montante que o reconhecedor afirma já ter transferido;
• non-monetary: declara a consequência e propõe um arranjo não monetário, cuja aceitação é um ato separado.

Montante transferido não é benefício total. Se uma contribuição ajudou a obter BRL 10.000 e foram transferidos BRL 100 em reconhecimento, o campo é amount: "100.00", currency: BRL. O benefício pode ser explicado separadamente, sem divulgação obrigatória ou proporção prescrita. Nenhuma transferência é exigida para Nod reputacional.

Nod monetário declara transferência já feita; não é instrução de pagamento nem prova de verdade. Evidência de liquidação é opcional e classificada pelo que sustenta. Autorização não comprova liquidação. Reembolso posterior ocorre na via externa; resposta de adequação não o executa (§11).

Um Nod não monetário pode propor participação societária, trabalho, acesso ou outro arranjo como reconhecimento da consequência recebida. Os termos ficam num instrumento externo referenciado pelo registro. A resposta registra a aceitação ou recusa da proposta. A formação, validade, alteração e término de um acordo dependem dos atos das partes, de seus poderes, dos termos e da lei aplicável. Uma proposta de colaboração inteiramente futura pertence a um Appoint ou ao fluxo de uma aplicação; ainda não é reconhecimento de consequência recebida.

Cada reconhecimento tem seu próprio Nod. O beneficiário escolhe quais contribuições e antecedentes reconhece e o valor que oferece. A genealogia pode ajudar nessa escolha, mas não distribui pagamentos automaticamente nem cria direito a uma parcela para cada trabalho relacionado. Vários registros sobre a mesma venda continuam se referindo a uma única venda.

O autor do registro reconhecido pode responder adequate ou inadequate sob sua própria chave. Ele declara como avalia o reconhecimento recebido. Essa resposta tem sua própria visibilidade e pode ser privada, restrita ou pública. Ela não altera o montante, cobra uma diferença, executa reembolso ou certifica cumprimento da NRC.

Uma correção pode substituir a declaração anterior na leitura atual, mantendo o histórico. Corrigir BRL 1.000 para BRL 100 não soma BRL 1.100 e não declara reembolso de BRL 900. Uma nova transferência é um acontecimento separado (§3.6). Não há taxa do protocolo; serviços podem cobrar pelos recursos que oferecem.

3. Formatos canônicos

Os registros são arquivos UTF-8. Um diretório como .legible/appoints/ é uma convenção, não um requisito. Um arquivo pode ser guardado fora do Git e trocado sem seu repositório.

Identidade do registro. id = lowercase_hex(SHA-256(JCS(canonical_content))). Somente o conteúdo do core entra nesse hash. O envelope contém os campos obrigatórios id, type, canonical_content e security, além do opcional published: Time. Nesta edição, o envelope é fechado: uma extensão com outros campos no nível superior utiliza um wrapper explicitamente identificado, como o da §10, sem apresentar todo campo de exibição como se tivesse sido assinado.

id contém exatamente 64 caracteres hexadecimais minúsculos. type é um de appoint, trace, nod, response ou redaction e MUST corresponder ao componente final de content_schema, que é assinado. Uma divergência constitui falha de estrutura, mesmo que hash e assinatura estejam corretos. A assinatura nunca autentica uma substituição arbitrária do rótulo externo type.

3.0 Codificação, tipos comuns e fronteira da assinatura

Codificações aceitas.

JSON é a representação direta de entrada. YAML é permitido como serialização alternativa do mesmo modelo de dados JSON, com o seguinte subconjunto de resolução de escalares: escalares entre aspas ou em bloco são strings; true e false sem aspas são booleanos; null sem aspas é nulo e, portanto, rejeitado nesta edição; escalares simples que correspondem à sintaxe de números JSON são números; os demais são strings.

A sintaxe numérica JSON é -?(0|[1-9][0-9]*)(\.[0-9]+)?([eE][+-]?[0-9]+)?, aplicada ao escalar inteiro. Não se convertem implicitamente timestamps, valores hexadecimais, octais ou booleanos sem distinção de maiúsculas.

O parser MUST rejeitar chaves duplicadas em qualquer nível, múltiplos documentos YAML, âncoras, aliases, chaves de merge, tags YAML explícitas, chaves que não sejam strings e tipos de dados externos ao modelo JSON.

Datas são strings, não objetos nativos de timestamp. Comentários não integram o modelo de dados. Um leitor MUST NOT descartar silenciosamente campos do core que não consiga representar. Escritores SHOULD colocar entre aspas strings que outro modo YAML possa converter, sobretudo datas, DIDs, referências e valores monetários.

Strings e NFC.

Toda string do core, inclusive cada chave de objeto, MUST ser Unicode válido em NFC. Um cliente de autoria SHOULD normalizar antes de calcular o hash e assinar, rejeitando colisões de chaves que a normalização produziria. O verificador confere os dados recebidos sem normalizá-los silenciosamente. Se o core recebido viola NFC, informe essa restrição de schema separadamente do resultado de integridade calculado sobre as strings recebidas. Nenhuma normalização posterior de strings integra JCS.

Números.

Números JSON utilizam valores finitos IEEE-754 binary64 e a serialização da RFC 8785. Chaves duplicadas, Unicode inválido, NaN e infinitos são rejeitados. Uma implementação MUST NOT substituir a ordenação e o tratamento numérico de JCS por uma ordenação genérica de chaves JSON. Esses requisitos estão na RFC 8785.

Valores monetários são strings e nunca passam por ponto flutuante binário. Um parser incapaz de aplicar fielmente o modelo numérico selecionado MUST informar entrada não suportada, em vez de aproximar silenciosamente fora desse modelo.

Ausência e valores vazios.

Campos opcionais ausentes são omitidos. Esta edição não utiliza null. Arrays e mapas opcionais não são vazios quando presentes; ausência representa uma lista vazia de Traces, evidências, timestamps ou context slots. As tabelas abaixo determinam quais campos são obrigatórios. Exemplos esquemáticos não criam valores padrão, e um verificador MUST NOT inserir padrões no core assinado.

Tipos comuns.

Tipo comum	Definição
Text	String NFC não vazia; a verificação não remove espaços no início ou no fim
RecordID	Exatamente 64 caracteres hexadecimais minúsculos
Digest	sha256: seguido de 64 caracteres hexadecimais minúsculos
Time	Data e hora gregorianas válidas em UTC: YYYY-MM-DDTHH:MM:SSZ ou YYYY-MM-DDTHH:MM:SS.sssZ; ano 0001–9999; sem representação de segundo intercalar; exatamente três dígitos fracionários quando presentes
DID	Sintaxe DID; a verificação básica suporta somente a forma Ed25519 did:key definida abaixo
Visibility	public, private ou group
Weight	Número JSON entre 0 e 1, inclusive
DecimalAmount	String correspondente a ^(0|[1-9][0-9]*)(\.[0-9]+)?$; sem sinal, expoente, espaços ou separador de milhar
Currency	Três letras ASCII maiúsculas que identificam uma moeda; o schema não certifica seu status nem a precisão aceita na liquidação
Relationship	builds-upon, uses, extends, references ou replicates
Reference	Um RecordID, uma das referências qualificadas de conteúdo abaixo ou URI absoluto com esquema explícito

Datas e representação.

Strings UTC que representam o mesmo instante podem ter precisões permitidas diferentes e, por isso, IDs diferentes. Compare instantes para exibição, não strings brutas, sem reescrever a representação assinada. Um created futuro ou inesperado é uma questão sobre a alegação temporal, não uma assinatura inválida. created não autoriza substituir outro registro.

Referências de conteúdo.

Hexadecimal simples de 64 caracteres significa somente um RecordID Legible. Digests SHA-256 externos utilizam sha256:<hex>. Referências a objetos Git utilizam git:sha1:<40-lowercase-hex> ou git:sha256:<64-lowercase-hex>, comprometendo-se com o objeto Git sob aquele algoritmo, não com um digest genérico de arquivo.

Referências CID utilizam URI absoluto de conteúdo, como ipfs://<CID>, cuja verificação exige adaptador de endereçamento por conteúdo suportado. A sintaxe de um URI não certifica conteúdo imutável. Outros esquemas, inclusive futuros esquemas de conteúdo, permanecem referências de localização sintaticamente válidas até que um adaptador estabeleça significado mais forte. Não se infere um hash Git não qualificado de uma string que o core trata como ID de registro.

Referências de localização MAY carregar um Digest irmão: target-hash, source-hash ou nods-hash. Nesta edição, esse digest significa SHA-256 dos bytes exatos do artefato externo fornecido, sem normalização textual. Um adaptador de decodificação de transporte MUST identificar os bytes que expõe. Um digest nunca concede permissão de recuperar ou divulgar o artefato. A validade do registro não exige busca automática.

Referências de evidência.

Um objeto Evidence exige type: Text e ref: Reference, com content-hash: Digest opcional. Os tipos são rótulos, não certificações do protocolo. Um leitor pode guardar um rótulo desconhecido sem afirmar que verificou a evidência. Arrays de evidências contêm um ou mais desses objetos; seu conteúdo não pode ser incorporado nesses objetos. Explicações já presentes em payload, statement ou note integram, naturalmente, o core.

Campos comuns do core.

Cada registro exige exatamente os seguintes campos comuns, acrescidos dos campos de sua tabela específica:

Campo	Tipo	Significado
author	DID	Identidade que faz esta declaração
content_schema	Text	Identificador exato do schema da seção correspondente ao tipo
created	Time	Data deste registro declarada pelo autor
visibility	Visibility	Escopo pretendido de divulgação, não controle de acesso

Cada objeto descrito é fechado: campos desconhecidos constituem falha de estrutura para estes schemas exatos. Um schema futuro poderá acrescentar campos. Extensões privadas utilizam identificador de schema distinto; x- não contorna um enum fechado. As aplicações podem manter metadados próprios fora do registro ou em wrapper explicitamente separado.

Visibilidade.

Nenhum campo impõe confidencialidade. Copiar um registro private para um lugar público é divulgá-lo. Uma implementação SHOULD evitar a publicação até que o usuário a selecione; um core marcado public declara uma intenção, não ordena upload nem autoriza universalmente tratamento de dados. Mudar a visibilidade assinada exige novo registro; as condições de acesso externas ao arquivo podem mudar sem reescrevê-lo.

Conjunto de assinatura.

security exige signature: Text, um OpenSSH sshsig em formato ASCII-armored. MAY conter também timestamp-proofs não vazio, e nenhum outro campo no envelope básico.

A mensagem assinada é a codificação UTF-8 da string id em minúsculas, sem quebra de linha final; o namespace SSHSIG é exatamente legible. O algoritmo de chave/assinatura é ssh-ed25519 simples; certificados SSH e variantes sk-* ficam fora deste conjunto.

A versão SSHSIG é 1, e o campo reservado MUST estar vazio. O algoritmo de hash SSHSIG pode ser sha256 ou sha512; verificadores MUST suportar ambos e rejeitar outros valores neste conjunto.

A chave pública da assinatura do envelope MUST coincidir com a chave decodificada de author. Uma assinatura sob git ou qualquer outro namespace não valida aqui. Consulte o formato OpenSSH SSHSIG.

Identidade básica.

No did:key básico, decodifique o valor multibase z com base58btc, exija o prefixo multicodec Ed25519 — bytes ed 01 — seguido de exatamente 32 bytes de chave pública, e rejeite outro codec. Isso fixa o subconjunto utilizado, sem incorporar por referência todos os métodos futuros de identidade. Um método DID sintaticamente válido, mas não suportado, é informado como identity-unsupported; não é tratado como autor verificado. Rotação com DID inalterado não é capacidade básica.

Provas temporais.

Uma entrada timestamp-proofs exige type: Text, ref: Reference e input: "utf8-id"; content-hash: Digest opcional compromete-se com os bytes da prova referenciada. Adaptadores suportados MUST vincular a evidência à mesma mensagem UTF-8 do ID descrita acima, incluindo o cálculo de digest exigido pelo formato da testemunha. Adaptadores desconhecidos produzem unsupported, nunca um limite temporal verificado. Os metadados temporais ficam fora da assinatura; cada prova alegada precisa ser verificada independentemente antes de ser utilizada (§13).

Compromissos privados.

Os campos opcionais private-data-commitment utilizam exatamente sha256(ASCII("legible:private:v1") || 0x00 || nonce || material), em que nonce contém 32 bytes criptograficamente aleatórios e material é a sequência de bytes não divulgada. O campo contém o Digest resultante. O autor guarda privadamente nonce e material; revelar ambos permite conferir o compromisso.

Um escritor MUST NOT utilizar nonce fixo, previsível ou público para alegar confidencialidade. O verificador não consegue inferir a qualidade do nonce pelo digest. content-hash comum continua sendo digest sem salt para conferir bytes de artefatos públicos; não substitua silenciosamente uma construção pela outra.

NCO — assunção da declaração.

Em legible/protocol/v2/..., assinar tem o seguinte significado convencional. O texto canônico é português:

Adoto como minha a declaração contida neste registro e a faço de boa-fé. Quando declaro uma formulação, afirmo que ela corresponde ao que formulei ou ao que estou autorizado a representar. Se faço a declaração em nome de outra pessoa ou organização, afirmo estar autorizado a fazê-lo.

Tradução inglesa de referência:

I adopt the declaration contained in this record as my own and make it in good faith. When I declare a formulation, I state that it corresponds to what I formulated or to what I am authorized to represent. If I make the declaration on behalf of another person or organization, I state that I am authorized to do so.

O signatário adota a declaração efetivamente contida no registro. Adotar uma declaração não confirma a hipótese nem comprova a correção do resultado que ela apresenta. A assinatura verifica integridade e atribuição à chave; não certifica veracidade, titularidade exclusiva sobre materiais referenciados, autoridade jurídica ou permissão para utilizar, publicar ou processar esses materiais.

Divulgação e processamento permanecem decisões separadas, sujeitas às condições aplicáveis. Clientes de autoria SHOULD apresentar o conteúdo exato e disponibilizar a NCO desta edição antes da assinatura. A verificação não comprova aceitação consciente ou boa-fé.

Seleção imutável da edição.

O content_schema assinado, nunca created, seleciona a NCO. Os cinco tipos legible/protocol/v2/... adotam o texto português acima. spec/editions.json distribui essa correspondência e o digest do texto; esse digest é metadado de publicação, não um novo campo assinado ou um compromisso explícito de hash dos bytes da NCO dentro do registro. A associação é normativa por meio do identificador de edição assinado.

O significado de edições publicadas MUST NOT ser substituído silenciosamente. Uma edição desconhecida MUST NOT receber uma NCO conhecida por sufixo, data ou fallback para a edição mais recente. Uma nova declaração sob outra edição exige seu próprio core, ID e assinatura; a assinatura anterior não pode ser reaproveitada.

Referências e edições não suportadas.

As verificações da §3.6 se aplicam aos registros referenciados, inclusive autor, tipo, alvo e ciclos. Um extremo de edição não suportada permanece não resolvido/não suportado; MUST NOT receber autor ou efeito de ciclo de vida inferidos. Esta base inicial oferece suporte apenas aos cinco schemas v2 identificados acima.

Informativo — atribuição entre serviços independentes.

Um registro pode permanecer com seu autor, ser compartilhado depois e ser apresentado por ferramentas e índices independentes. A verificação da assinatura atribui seu conteúdo à chave; a NCO expressa o compromisso convencional associado à assinatura daquela edição. Leitores podem distinguir a declaração do signatário dos resumos, classificações e inferências do serviço. A verificação não comprova aceitação consciente, boa-fé, identidade civil, autoridade jurídica ou direitos. Tampouco transfere ao signatário as responsabilidades do operador por coleta, armazenamento, indexação, publicação ou processamento.

3.1 .appoint

Schema: legible/protocol/v2/appoint. Tipo do envelope: appoint.

Campo adicional	Obrigatório?	Tipo e restrição
metadata	Sim	Objeto: exige title: Text; domain: Text opcional
payload	Sim	Objeto: exige problem: Text; solution: Text opcional
nrc	Sim	Exatamente "0.2"
nrc-hash	Sim	Digest exato do Apêndice A, apresentado na §7.1
accepts-monetary	Sim	Preferência booleana
accepts-non-monetary	Sim	Preferência booleana
license	Não	Text com identificador SPDX ou URI absoluto de licença; declaração, não verificação de autoridade para licenciar
evidence	Não	Array não vazio de Evidence
traces	Não	1–2048 objetos Trace de origem, definidos abaixo
supersedes	Não	RecordID de Appoint anterior do mesmo autor
private-data-commitment	Não	Digest segundo a construção de compromisso privado
context-slots	Não	Array de 1–4 strings Digest; opaco ao core

Cada Trace de origem exige target: Reference, weight: Weight e relationship-type: Relationship; target-hash: Digest é opcional. Os pesos de origem SHOULD somar 1 quando o autor pretende uma atribuição completa. Não somar 1 não constitui falha de validade. Entradas duplicadas de alvo não são automaticamente fundidas, e nenhuma soma estabelece repartição obrigatória de pagamentos.

É permitido não haver solução, evidência ou genealogia de origem. A formulação não precisa inventar dependência, entrega concluída ou tarefa atribuída externamente para tornar-se registro. A existência do Appoint não concede a ninguém um direito sobre o território descrito em problem.

3.2 .trace

Schema: legible/protocol/v2/trace. Tipo do envelope: trace.

Campo adicional	Obrigatório?	Tipo e restrição
source	Sim	Reference ao trabalho que se declara dependente
target	Sim	Reference ao trabalho de que se declara depender
weight	Sim	Weight afirmado pelo autor deste Trace
relationship-type	Sim	Relationship
note	Sim	Text que explica a declaração
source-hash	Não	Digest dos bytes do artefato externo
target-hash	Não	Digest dos bytes do artefato externo
evidence	Não	Array não vazio de Evidence

O autor pode ser terceiro. Um leitor MUST NOT apresentar esse Trace como assinado pelo autor da origem sem verificar efetivamente essa atribuição. A igualdade entre o DID de um extremo e o DID do declarante é uma relação de atribuição verificável, não prova de causalidade real. Ciclos e questões cronológicas são anotações do grafo, não falhas da assinatura.

3.3 .nod

Schema: legible/protocol/v2/nod. Tipo do envelope: nod.

Campo adicional	Obrigatório?	Tipo e restrição
nods	Sim	Reference que identifica a contribuição reconhecida
consequence	Sim	solved, enabled, extended, referenced ou replicated
statement	Sim	Text que descreve a consequência recebida por quem reconhece
nod-type	Sim	recognition ou operational; o segundo identifica uso organizacional, não outro regime de validade
form	Sim	reputational, monetary ou non-monetary
nods-hash	Não	Digest dos bytes do artefato externo
evidence	Não	Array não vazio de Evidence que sustenta a consequência ou sua explicação
corrects	Não	RecordID de Nod anterior, sujeito à §3.6
economic	Se e somente se monetário	Objeto com exatamente amount: DecimalAmount e currency: Currency
settlement-evidence	Não; somente monetário	Array não vazio de objetos de evidência de liquidação definidos abaixo
agreement-hash-reference	Se e somente se não monetário	Digest dos bytes exatos da proposta/termos externos

economic.amount é o valor que o reconhecedor declara ter transferido em reconhecimento de nods. Não é sua receita, o valor universal da contribuição, um preço exigido de alguém ou um saldo do protocolo. Zero é sintaticamente permitido; escritores SHOULD utilizar reputational quando não houve transferência. A grafia decimal permanece como assinada: "100" e "100.00" são strings diferentes, embora um leitor financeiro possa interpretar valores iguais. O core não estabelece valor máximo nem afirma exatidão do pagamento.

Um objeto opcional de evidência de liquidação exige type: Text, ref: Reference e stage entre authorization, instruction, settlement, reversal e other; content-hash: Digest é opcional. O stage escolhido pelo autor é uma alegação. Adaptadores de evidência estabelecem, ou não conseguem estabelecer, o que o artefato sustenta. ap2-mandate, invoice, bank-receipt e onchain-tx são rótulos convencionais de tipo, não garantias de liquidação ou classificação jurídica.

Em Nods não monetários, nods MUST ser um RecordID. A autoridade para responder é o autor verificado desse registro. Autores e clientes precisam conferir se quem negocia efetivamente a proposta externa tem poderes para tanto; a regra do core sobre autoria da resposta não confere autoridade jurídica para conceder participação societária, propriedade intelectual, emprego ou qualquer outro direito. Nods monetários e reputacionais podem referenciar trabalhos externos sem autor identificável pelo protocolo. Essas referências não inventam DID de destinatário, determinação de titularidade ou conta de destino.

3.4 .response

Schema: legible/protocol/v2/response. Tipo do envelope: response.

Campo adicional	Obrigatório?	Tipo e restrição
about-nod	Sim	RecordID do Nod exato ao qual se responde
kind	Sim	adequacy ou agreement-decision
signal	Sim	adequate/inadequate para adequação; accepted/declined para decisão sobre proposta
note	Não	Text
supersedes-response	Não	RecordID de resposta anterior sob as regras de relação abaixo

O autor da resposta MUST coincidir com o autor verificado do registro indicado pelo Nod em nods. Trata-se de autorização referencial, que uma verificação isolada da assinatura não estabelece quando falta o alvo. Um URI externo em nods não fornece autoridade de resposta neste core. agreement-decision aplica-se somente a Nod não monetário.

A resposta registra uma declaração; não executa transferência, reembolso, contrato, renúncia ou cancelamento. Em particular, uma declaração posterior declined não desfaz, por si, um acordo que já possa existir sob termos externos. Um Nod corrigido tem novo ID; a aceitação anterior nunca se associa silenciosamente a termos alterados.

3.5 .redaction

Schema: legible/protocol/v2/redaction. Tipo do envelope: redaction.

Campo adicional: redacts: RecordID, obrigatório. Nenhum outro campo específico é permitido: o core contém somente os quatro campos comuns e redacts. Em particular, esta anotação não inclui explicação em texto livre nem fragmento do conteúdo retirado.

O autor solicita a retirada de registro anterior de sua autoria. Leitores MUST estabelecer a autorização por igualdade de autor em relação ao alvo antes de apresentar uma Redaction como retirada autorizada. Um alvo não resolvido produz relação pendente, não uma ordem para apagar qualquer registro.

O serviço de armazenamento ou indexação trata o pedido segundo suas políticas declaradas de retenção e publicação e suas obrigações aplicáveis. Uma retirada autorizada SHOULD refletir-se na apresentação atual quando legal e tecnicamente possível, sem falsa promessa de apagar todas as cópias. O serviço também pode remover ou restringir conteúdo por autoridade própria, sem Redaction do autor. Sua decisão de moderação não é registro assinado por esse autor e MUST NOT ser apresentada dessa forma.

O autor pode apagar sua cópia local independentemente de anotação. Uma assinatura sobrevivente sobre um ID pode continuar verificável após a retirada do conteúdo, mas a integridade completa do core e seu schema não podem ser recalculados sem o core. Uma Redaction de outra Redaction registra nova retirada; não republica automaticamente o alvo original nem recolhe cópias já divulgadas.

3.6 Verificação, relações e leituras atuais

Resultados independentes. Um verificador MUST distinguir pelo menos integrity, schema, signature/identity e relations. Cada resultado informa sucesso, falha, não resolvido/não suportado ou não verificado, conforme o caso. Evidências temporais e aceitação pela política do serviço são resultados separados. signature-valid MUST NOT ser apresentado como prova de validade completa, veracidade, revisão humana ou autoridade jurídica.

A validação básica confere projeção segura; estruturas dos campos comuns e específicos; correspondência exata entre schema e tipo; NFC; enums fechados e intervalos; igualdade do hash; e o conjunto DID/assinatura especificado. Essas verificações não incluem busca de referências, exigência de timestamps, julgamento da veracidade ou obrigação de armazenamento. O registro é localmente válido quando essas verificações básicas têm sucesso. A aplicação dos efeitos de ciclo de vida exige também as relações abaixo.

Relação	Verificações exigidas antes de aplicar um efeito derivado
Appoint supersedes	O alvo é Appoint; mesmo autor verificado; a cadeia de substituição não contém ciclo
Nod corrects	O alvo é Nod; mesmo autor, referência nods exata e form; cadeia de correção sem ciclo
Response about-nod	O alvo é Nod; seu nods resolve para registro; o autor da resposta coincide com o autor verificado desse registro; par kind/form permitido
supersedes-response	O alvo é resposta autorizada com mesmo autor, about-nod exato e kind; cadeia de substituição sem ciclo
Redaction redacts	O alvo resolve para registro verificado do mesmo autor

Dados de alvo ausentes produzem pending; identidade não suportada produz unsupported; tipo ou autor sabidamente contraditórios produzem failed. Separe esses resultados da assinatura do arquivo local. Uma aplicação MAY guardar ou apresentar uma declaração pendente ou contraditória como tal, conforme sua política, mas MUST NOT aplicá-la como ato autorizado de ciclo de vida. Referências a registros retirados podem permanecer não resolvidas, sem redirecionamento silencioso. Quando os bytes do alvo retirado estiverem indisponíveis, o leitor pode apoiar-se em evidência local previamente verificada, informando essa base; não pode alegar nova verificação apenas pelo aviso de retirada.

Leituras atuais são projeções explícitas. Append-only significa aqui que um registro assinado nunca muda os bytes de outro. Não proíbe retirar cópias locais nem exige retenção perpétua. Em correções e substituições, um descendente autorizado substitui a declaração do ancestral na visualização atual convencional; visualizações históricas conservam ambos. Valores numa cadeia de correção MUST NOT ser apresentados como pagamentos somáveis apenas porque existem dois registros. Uma correção pode ajustar valor, moeda, explicação ou evidência; não afirma, por si, nova transferência. Uma nova transferência independente exige Nod sem corrects.

Se dois registros autorizados conhecidos corrigem independentemente o mesmo antecessor, há folhas conflitantes. A visualização convencional informa as alternativas como não resolvidas, sem escolher o maior created nem somar silenciosamente os valores. Um leitor pode adotar política local de resolução divulgada; MUST identificá-la como sua leitura. Uma resposta que substitui outra muda a posição declarada atual do autor, não um acordo externo por si. Respostas múltiplas sem relação explícita de substituição coexistem, mesmo quando uma tem data posterior. A retirada não restaura silenciosamente um valor monetário substituído; a visualização atual pode ficar indisponível ou indicar retirada.

Transporte duplicado não é novo ato. Reingerir o mesmo ID reproduz o mesmo core. Provas e metadados de publicação podem diferir entre envelopes e precisam de verificação própria; cópias repetidas não aumentam contagens de reconhecimento. Registros assinados distintos que referenciam a mesma venda ou pagamento ainda podem descrever acontecimentos sobrepostos. Contar registros não produz uma soma global de receita.

Verificação de preferências. Quando nods resolve para Appoint, o cliente de autoria SHOULD mostrar suas preferências accepts-* antes de propor reconhecimento com valor. SHOULD evitar iniciar oferta ou pagamento indesejado sem esclarecimento. Um registro assinado contrário a uma preferência permanece declaração legível como tal; divergência de preferência não significa assinatura inválida. Um alvo sem esses campos, externo ou indisponível não fornece preferência afirmativa a inferir.

Edições desconhecidas. O leitor pode verificar um digest calculável ou assinatura suportada sobre schema desconhecido sem alegar conformidade estrutural. MUST distinguir desconhecido de malformado sob schema conhecido. Se guardar ou encaminhar um registro desconhecido, MUST preservar seu core sem reescrevê-lo. Nenhuma exigência obriga guardar, aceitar ou servir material desconhecido, ilícito, excessivamente grande ou indesejado por outra razão.

Limites de recursos. O limite absoluto de Traces de origem é 2.048. Serviços MAY impor limites adicionais de bytes, profundidade, quantidade de provas, taxa e percurso. Uma recusa por limite local é resultado de política, não conclusão criptográfica. Parsers e leitores de grafos SHOULD limitar memória e trabalho antes de operações caras, evitar expansão recursiva e nunca presumir que dados assinados sejam seguros para execução.

---

4. Modelo de dados

O modelo distingue os arquivos que contêm as declarações, as relações que podem ser verificadas entre arquivos acessíveis e as interpretações que um leitor constrói a partir deles. O leitor trabalha com o material ao qual tem acesso; esse conjunto pode representar apenas parte do histórico.

Objeto	O que registra	O que não determina
Appoint	Formulação, atribuição, Traces de origem, adoção NRC, evidência e declaração de licença opcionais	Originalidade, prioridade, titularidade, seleção ou execução
Trace	Afirmação de um autor de que um trabalho depende de outro	Causalidade comprovada ou concordância do beneficiário
Nod	Consequência declarada pelo beneficiário e forma escolhida de reconhecimento	Veracidade, valor justo, direito automático ou liquidação concluída além da declaração
Response	Avaliação de adequação ou decisão sobre proposta pelo autor do registro referenciado	Transferência, reembolso, formação ou extinção automática de direitos
Redaction	Pedido do autor para retirar um registro	Apagamento de todas as cópias ou determinação jurídica sobre retenção
Projeção do grafo	Relações derivadas dos registros acessíveis e da política declarada de validação	Completude, cronologia universal ou ranking oficial
CH	Interesses, critérios e reflexões pessoais que orientam a leitura	Atestação pública ou classificação oficial da pessoa

Um grafo pode combinar registros públicos, de grupos autorizados e privados. Pertencimento a grupos e autorização de leitura são definidos pelo serviço ou arranjo de armazenamento, não por um campo do formato. O leitor não deve confundir o subconjunto que vê com o histórico completo de uma pessoa ou contribuição.

Dinheiro circula por arranjos externos. Uma aplicação pode integrá-los no mesmo produto, desde que diferencie sua atividade de pagamento do registro de declarações e assuma as responsabilidades daquilo que efetivamente opera. O protocolo não oferece custódia, saldo de conta, cadastro de destinos ou motor de liquidação.

5. Heurísticas de coordenação — CH

O CH (Coordination Heuristics) é um documento pessoal e privado em que você registra o que está procurando compreender, quais critérios considera importantes e quais limites precisa respeitar. Também pode reunir referências e reflexões sobre seu trabalho.

Esse contexto ajuda a examinar registros e contribuições de outras pessoas: o que pode ajudar em seu trabalho, o que ainda falta esclarecer e quais caminhos merecem investigação. Os materiais podem estar em espaços e fontes diferentes, conforme as condições de acesso. Você pode fazer essa leitura sozinho ou com ajuda de uma IA, usando os materiais cujo acesso e processamento estejam autorizados.

O uso do CH é opcional. O documento pode mudar conforme suas ideias evoluem. Quando um assistente propõe alterações, você decide quais aceita. A decisão sobre o que fazer a partir da leitura também continua com você.

O caso de P&D na área de exemplos mostra uma diretora usando esse contexto para ler observações e hipóteses de sua equipe antes de decidir sobre um teste.

Os requisitos desta seção aplicam-se às funções de armazenamento, edição e processamento de CH dos produtos que declaram a capacidade de privacidade CH da §9.

5.1 Conteúdo e controle do documento

O CH é escrito em prosa. Pode começar com poucas linhas sobre o que o participante considera importante e procura compreender. As seis partes abaixo sugerem uma organização; o participante pode agrupá-las e usar títulos próprios.

Parte	Conteúdo e origem
Quem sou	Contexto e razões que o participante escolhe apresentar
O que recuso	Limites e condições definidos pelo participante
Em que me apoio	Resumo revisável dos Traces emitidos
O que declarei importante	Resumo revisável dos Nods emitidos
O que outros reconheceram em meu trabalho	Resumo dos Nods recebidos acessíveis
O que procuro	Questões e direções escolhidas pelo participante

As partes baseadas em registros podem ser acrescentadas quando houver Traces ou Nods disponíveis. O participante pode escrever diretamente ou pedir ajuda para formular e organizar seu conteúdo. Ferramentas estruturadas podem acompanhar a prosa; a interpretação continua sendo pessoal e revisável.

O CH MUST NOT mudar automaticamente sem aprovação do usuário. Quando um assistente propõe uma revisão, apresenta o que será acrescentado, retirado ou alterado; o usuário aprova, edita ou recusa essa proposta antes de sua aplicação. Isso inclui os resumos produzidos a partir de registros.

Um caminho convencional é .ch/self.md, fora de .legible/; outra localização privada também é válida. Esse documento é mantido separadamente dos registros assinados e segue os controles de publicação e exportação da §5.2.

5.2 Requisitos de privacidade

Critérios, recusas e intenções podem conter informações sensíveis. Uma implementação que declara a capacidade CH:

• MUST excluir o CH, por padrão, da publicação pública, dos dados de uso e diagnóstico enviados pela aplicação (telemetria) e das exportações comuns de registros ou grafos;
• MUST excluir por padrão o diretório CH escolhido dos commits do repositório, usando o mecanismo de ignore apropriado quando utilizar Git;
• MUST NOT transformar silenciosamente o CH em declaração assinada ou usar uma assinatura para sugerir que o documento descreve objetivamente seu titular;
• MUST fornecer controles claros para transmissão, backup, migração ou divulgação autorizados;
• MUST separar os conteúdos CH de usuários diferentes e MUST NOT compará-los ou agregá-los sem autorização específica e fundamento jurídico apropriado;
• SHOULD cifrar o CH armazenado e os backups privados com implementação estabelecida de criptografia autenticada e chave de cifragem gerenciada separadamente;
• SHOULD evitar copiar conteúdo sensível do CH para registros técnicos de operação (logs), entradas de modelos (prompts), arquivos temporários, diagnósticos ou relatórios de falha além do necessário à operação autorizada.

Uma exportação privada cifrada pode ser usada para backup ou mudança de ambiente. O software SHOULD explicar quais dados privados cada exportação inclui. A implementação cuida do controle de acesso, das chaves de cifragem, dos backups e da eliminação dos dados; uma chave de assinatura, sozinha, não fornece essa proteção.

5.3 Da reflexão à contribuição

Uma reflexão do CH pode dar origem a uma pergunta, proposta ou outro trabalho. O participante pode mantê-la no documento ou selecionar uma formulação para preservar separadamente como rascunho. Se escolher formalizá-la, revisa o conteúdo exato e emite um novo Appoint, conforme §§1.8 e 3.1. A decisão de compartilhar esse rascunho ou registro é separada. Escrever ou resumir algo no CH não executa essas operações.

5.4 Criação, revisão e continuidade

Criação. O participante escreve sua direção inicial ou a desenvolve numa conversa. Pode usar as partes sugeridas em §5.1 conforme forem úteis.

Revisão. Uma mudança de interesse, uma contribuição lida ou um ato assinado pode motivar uma alteração. O participante pode editar o documento; se um assistente preparar a mudança, ela depende da aprovação descrita em §5.1.

Reconstrução. Resumos derivados podem ser refeitos a partir dos registros disponíveis, indicando suas fontes e incertezas. A direção inicial e os julgamentos privados dependem dos próprios arquivos ou backups do participante; não se presume que possam ser recuperados do grafo.

Mudança de ambiente. O participante pode levar seu CH para outra ferramenta por uma transferência privada autorizada. Os registros assinados continuam verificáveis independentemente da disponibilidade desse documento.

5.5 Cuidados com conteúdo sensível

Clientes SHOULD alertar contra a inclusão no CH de dados pessoais desnecessários de terceiros, segredos, credenciais ou materiais mantidos ilegalmente. Credenciais pertencem a um cofre próprio para segredos.

Se o participante escolher formalizar uma formulação confidencial, pode considerar um Appoint privado ou o compromisso sobre material não divulgado definido em §3.1. A assinatura não cifra o conteúdo: armazenamento, acesso e eventual divulgação continuam exigindo seus próprios controles. As considerações de segurança da §14 também se aplicam.

5.6 Busca e interpretação das contribuições

A busca reúne contribuições acessíveis; o participante as examina em função de sua pergunta e do contexto que escolheu manter no CH. Uma IA pode ajudar a explicar relações, diferenças e possíveis caminhos, que o participante avalia. Esse processo também pode revelar uma questão que ele ainda não havia formulado.

Referências diretas, percurso das relações, palavras-chave, busca por sentido e índices compartilhados são meios possíveis de encontrar contribuições. Têm coberturas e vieses diferentes: percorrer somente relações existentes, por exemplo, pode deixar contribuições novas ou desconectadas fora da leitura. Um serviço pode publicar sua própria ordenação de resultados, identificada como leitura daquele serviço (§6).

Uma implementação CH MUST NOT enviar CH ou representação dele derivada a um índice compartilhado sem autorização específica do usuário. Representações numéricas usadas em busca por sentido (embeddings) podem revelar informações dos textos de origem. Quando derivadas do CH privado, precisam da mesma proteção. Quando derivadas apenas de registros públicos, não constituem, por si, exportação desse CH.

O guia para indexadores, informativo, detalha como distinguir declarações, verificações, interpretações e condições de acesso e reutilização ao apresentar resultados.

5.7 Processamento local ou hospedado

Quando houver assistência de IA, processamento local SHOULD ser oferecido quando viável. Um modelo hospedado pode ser usado depois de escolha informada do usuário sobre o conteúdo enviado e o provedor envolvido. A implementação MUST tornar essa transmissão visível antes de ocorrer e SHOULD minimizar os dados enviados.

Essa escolha autoriza a operação do produto e permanece sujeita aos requisitos aplicáveis de proteção de dados. Retenção, uso em treinamento, logs, transferências internacionais e segurança precisam ser avaliados conforme o serviço efetivo e seus arranjos (§14). Usar o CH em um modelo hospedado envolve enviar o conteúdo selecionado àquele provedor.

6. Reputação sem pontuação do protocolo

Nenhum participante recebe pontuação do Legible. Tem declarações que um leitor pode situar num histórico: formulações, dependências, consequências reconhecidas e respostas. Esse histórico é incompleto onde registros são privados, ausentes, retirados ou nunca emitidos.

A reputação é contextual. Colaborador, investidor, empregador, cliente e pesquisador podem ler o mesmo histórico acessível de formas diferentes. O protocolo não define algoritmo que reduza esses propósitos a uma resposta. Um leitor ou serviço pode calcular pontuação para sua finalidade; permanece responsável pela leitura e pela forma de apresentá-la e utilizá-la.

Além do volume e da centralidade. Contagens são fáceis de inflar. Centralidade sobre dependências declaradas pode informar, mas também pode ser fabricada por alegações falsas, identidades Sybil e conluio entre pessoas reais. A assinatura não prova que alguém se apoiou efetivamente num trabalho. Traces de origem e de terceiros precisam continuar distinguíveis na leitura.

Como o protocolo não fixa uma pontuação, não há uma única medida oficial que os participantes possam tentar inflar. Ainda assim, as declarações podem ser manipuladas. Um histórico pode ajudar a avaliar cooperação quando o leitor consegue examinar evidências e quando as pessoas esperam continuar se relacionando. Identidades descartáveis, trocas isoladas e resultados inacessíveis reduzem essa utilidade. Ter registros relacionados, sozinho, não permite distinguir participantes confiáveis.

A centralidade é retrospectiva e pode privilegiar os já conectados. Um problema recém-formulado pode importar antes que alguém dependa dele. Nenhum sinal de centralidade é métrica de sucesso do protocolo. Para uma aplicação, uma pergunta útil é se leitores conseguem descobrir e considerar contribuições que seus filtros anteriores excluiriam e se isso modifica suas decisões.

7. NRC — a condição de reconhecimento

A Nod Recognition Convention (NRC) descreve a expectativa de reconhecimento que o participante adota ao emitir um Appoint: registrar um Nod quando realizar valor econômico numa transação de troca a partir de uma contribuição declarada sob a convenção. A §7.1 explica essa condição. A permissão para usar a obra é tratada separadamente, por suas licenças e pelos instrumentos aplicáveis (§7.2). A NRC não funciona como licença, cobrança ou contrato com toda pessoa que leia ou use a obra.

Todo Appoint desta edição inclui a versão da NRC e o hash de seu texto no core assinado. O verificador pode conferir esses campos. Não pode concluir, a partir do histórico público, se o participante registrou todos os reconhecimentos previstos: um Nod pode ser privado ou estar fora das fontes consultadas. A ausência de um Nod acessível não prova omissão.

7.1 Condição imutável por versão

O texto exato da NRC 0.2 está no Apêndice A. Seu digest é sha256:42b9c41ee986a5b90c67302283d7f2ea6813979a17f41734e35b51a0e5a3953b. nrc MUST ser "0.2", e nrc-hash MUST ser esse digest nos Appoints desta edição. Um texto NRC futuro exige nova versão e edição de schema correspondente; nenhuma publicação posterior reescreve a convenção de um registro existente.

A convenção pede que o participante que a adota registre reconhecimento quando realiza valor econômico numa transação de troca a partir de contribuição declarada sob a convenção. Outras consequências também podem ser reconhecidas voluntariamente. Isso distingue a convenção mínima da variedade mais ampla de Nods.

O registro pode ser privado, restrito ao grupo ou público. Um Nod reputacional sem transferência monetária pode atender à expectativa. Reconhecimentos monetários e não monetários permanecem escolhas soberanas; a convenção não fixa montante, percentual, cobrança, sanção ou direito automático.

Autoria do reconhecimento. Quem emite um Nod declara a consequência que recebeu e como escolheu reconhecê-la. Para avaliar essa declaração, o leitor pode precisar conhecer seu contexto: compromissos contratuais, pressão, relações continuadas ou expectativa de apoio futuro. A assinatura permite atribuir a declaração à chave; a avaliação de seu conteúdo exige essa leitura.

Reconhecer não garante continuidade do apoio. Quem reconhece escolhe o valor; quem oferece um recurso decide se oferece mais, sujeito aos próprios compromissos e obrigações aplicáveis. O provedor pode considerar histórico acessível ao renovar, reduzir ou encerrar apoio futuro. O protocolo não fixa percentual obrigatório nem trata a decisão do provedor como veredito sobre validade.

Remover conteúdo do próprio armazenamento não promete que cópias alheias desapareçam. Registros e evidências possuem responsáveis efetivos pela hospedagem; retenção, retirada e pedidos dos titulares dos dados são tratados pelos responsáveis segundo suas políticas e a lei aplicável (§3.5, §14).

7.2 Licença da obra e acordos externos

O license opcional do Appoint identifica a licença que seu autor afirma aplicar-se ao trabalho referenciado. Concede apenas os direitos que essa licença e a autoridade efetiva do licenciante possam fornecer. O protocolo não verifica titularidade nem transforma uma formulação em propriedade sobre o problema.

Direitos podem depender de licenças, contratos, limitações e exceções legais, relações de emprego e natureza do material. A ausência de licença declarada não estabelece que todo uso exija permissão negociada. Um Nod, por si só, não transfere direitos de propriedade intelectual, não cria obrigação de royalty e não substitui um instrumento legalmente exigido.

A NRC não oferece instrumento para exigir pagamento ou resposta. Comunicação comum e acordos separados continuam possíveis. Um Trace independente pode tornar legível uma relação alegada, sem provar que a pessoa nomeada recebeu consequência, deixou de registrar privadamente ou deve algo.

Incentivos e acordos. O reconhecedor pode querer tornar-se legível como alguém que reconhece: esse histórico pode informar a disposição alheia para colaborar. Um acordo separado também pode exigir relato ou pagamento específicos. São fontes diferentes de obrigação. A gramática descreve ambas sem cobrar, julgar ou garantir qualquer uma.

O guia de coordenação econômica, informativo, descreve acesso aos resultados e propostas de reconhecimento percentual escolhidas depois da consequência, com termos externos e divulgação selecionada.

7.3 eNRC — perfil de aplicação organizacional

Uma organização pode usar a mesma gramática num perímetro privado: Appoints internos, Nods operacionais, acesso de equipes, leituras internas de alocação e liquidação externa. Suas regras governam sua própria admissão e seus workflows, sujeitos às obrigações aplicáveis. Recusar merge não apaga o registro local independente de alguém, embora essa pessoa possa ter deveres de confidencialidade e divulgação.

eNRC usa a NRC 0.2. Nesta edição, o nome identifica seu uso em organizações. Não define outra convenção nem outro hash. Termos internos e relações de emprego permanecem separados. nod-type: operational segue as mesmas regras de campos, assinatura e evidência.

Para tornar público um Appoint privado, um autor autorizado pode emitir novo Appoint com nova visibilidade e referências apropriadas, utilizando supersedes quando suas condições de mesmo autor forem atendidas. A evidência pode referenciar a autorização organizacional necessária sem expor termos confidenciais. O registro anterior, sua visibilidade e sua adoção NRC permanecem inalterados. Registros de outros contribuidores não se tornam públicos automaticamente porque um descendente foi publicado.

Outro autor ou empregador pode emitir declaração própria atribuída, mas não utilizar substituição de mesmo autor para adquirir o registro alheio. Autoria individual, autoridade organizacional e direitos econômicos precisam permanecer distintos. Uma chave de grupo estabelece uma declaração da chave do grupo, não qual indivíduo fez o trabalho ou aprovou a assinatura. Isso exige processos organizacionais apropriados e, quando necessário, instrumentos jurídicos separados.

As aplicações podem calcular alocações internas e integrar pagamentos como serviços próprios. Não há repartição canônica, e o autor da especificação não se torna empregador, operador de folha ou julgador de direitos por publicar o formato.

---

8. Governança e soberania

Contato e operações externas

A chave verificada de assinatura de um registro não fornece canal de contato nem autentica destino de pagamento. Leitores podem utilizar uma conversa existente, diretório organizacional ou perfil fornecido pelo participante, verificando a associação conforme seu ambiente exige. Um contato não confirmado ou indisponível continua explicitamente nessa condição. Não se exige cadastro central de contatos.

Dados de contato, informações bancárias e documentos operacionais pertencem aos canais escolhidos pelas partes, não a campos obrigatórios da contribuição. Transferência externa, aceitação e entrega são distintas das declarações da §2.4 e §§3.3–3.4. Um Nod monetário informa o montante declarado transferido; uma instrução não é evidência de liquidação. Uma proposta não monetária não atesta entrega. Essas fronteiras não acrescentam campos, conjunto de assinatura ou classificação jurídica à edição.

O perfil opcional e versionado de contato (profiles/author-contact.md) oferece uma forma de declarar nome de apresentação ou canal atual para um did:key suportado. É arquivo auxiliar assinado, não quarta primitiva nem condição de verificação de qualquer registro. Seu namespace SSHSIG separado impede reaproveitar uma assinatura de registro como declaração de contato. O perfil não estabelece identidade civil, titularidade de conta ou destino de pagamento. Guardá-lo ou assiná-lo não autoriza publicá-lo. A seleção, correção e retirada do publicador aplicam-se aos dados pessoais publicados, inclusive nomes editoriais e conteúdo dos registros, independentemente da validade do perfil.

8.0 Funções dos serviços

Um registro básico pode ser criado e verificado sem autorização ou funcionamento contínuo de um serviço central do protocolo. Cada aplicação escolhe os serviços de que depende. A tabela mostra quais funções o próprio formato permite realizar e quais operações permanecem com os serviços. Manter a especificação e operar uma aplicação são atividades distintas.

Função possível	Desenho básico
Registrador de identidade	O autor pode gerar uma chave independentemente
Alocador de IDs	O ID deriva do core
Administrador de admissão	Aprovação de participação não integra a validade local
Índice canônico	Descoberta é externa; nenhum índice específico é exigido
Avaliador de qualidade	O protocolo não julga mérito ou verdade
Operador de liquidação	Transferências, quando existem, são externas
Certificador de conformidade	Alegações técnicas podem ser verificadas contra uma edição identificada; não se exige serviço de aprovação oficial

Uma implementação pode usar armazenamento remoto, índice pago, verificação de identidade, serviços de pagamento ou modelos hospedados. Precisa descrever honestamente essas dependências do serviço. Elas não se tornam dependências universais do protocolo porque um produto as exige.

A documentação de cada componente de referência deve identificar as funções que implementa, suas dependências e as verificações executadas. Se um componente é descrito como offline, precisa funcionar sem rede; a ausência de uma biblioteca de rede, sozinha, não demonstra esse comportamento.

8.1 Centralização legível

Um índice pode ser centralizado e útil. Um repositório compartilhado pode facilitar a descoberta. Importam os poderes efetivos do operador, o que o usuário pode levar e as dependências que permanecem após exportar. A concentração da recuperação pode tornar-se barreira prática mesmo quando os arquivos são portáteis.

Um serviço SHOULD publicar descrição breve de sua fronteira de governança: operador, edição suportada, escopo de armazenamento e publicação, moderação, ranking, cobrança, retenção, exportação, uso de modelos hospedados e dependências externas. São declarações do próprio serviço, não aprovações do autor da especificação.

Exemplo: “Indexamos os registros que aceitamos segundo nossas políticas publicadas. Verificamos as propriedades criptográficas indicadas quando suportadas. Calculamos nossa própria ordenação de busca. Não estabelecemos a verdade das contribuições, sua titularidade jurídica ou direito a pagamento.” O produto precisa adaptar a declaração àquilo que faz, em vez de copiar uma ressalva inexata.

8.2 Soberania do participante

O participante pode guardar seus registros, escolher condições de divulgação, utilizar outros leitores e tomar suas próprias decisões de reconhecimento. Portabilidade não torna todo serviço gratuito, toda cópia recolhível ou toda alternativa igualmente útil.

Serviços de armazenamento que declaram capacidade de portabilidade MUST oferecer exportação dos registros do usuário em sua forma assinada original, com provas disponíveis e registros de ciclo de vida associados que possam legitimamente fornecer. MUST distinguir material indisponível, restrito ou retido, em vez de apresentar exportação parcial como completa. Não precisam divulgar registros privados de terceiros, rankings proprietários internos ou material que não possam fornecer legitimamente. Chaves de assinatura e CH são ativos privados separados e MUST NOT ser incluídos silenciosamente em exportação pública do grafo.

8.3 Infraestrutura como participante

Um provedor de infraestrutura pode ser reconhecido por uma contribuição. Uma aplicação pode ajudar a formular, indexar, executar, guardar ou verificar trabalho e receber um Nod pela consequência que produziu. Nenhum percentual obrigatório é reservado ao autor da especificação, a uma implementação ou a um indexador.

Um provedor pode antecipar recursos limitados pela expectativa de reconhecimento futuro e decidir depois se continua. O usuário escolhe o reconhecimento; o provedor escolhe o apoio futuro, dentro de seus compromissos. Esses arranjos não precisam negociar previamente um percentual para serem expressáveis. Uma aplicação que negocia um percentual estabeleceu um arranjo externo, não mudou a convenção básica.

A legibilidade pode ajudar a avaliar a sustentabilidade ou a desproporção da relação. Não calcula justiça a partir de registros incompletos nem infere todo custo e benefício. A assinatura torna alegações examináveis; não encerra a avaliação.

O mesmo guia informativo discute contribuições de infraestruturas de diferentes naturezas, a diferença entre benefícios dos usuários e retorno do operador e as hipóteses de continuidade que precisam ser examinadas na prática.

9. Conformidade

Um produto declara conformidade com uma edição e com as capacidades que implementa. Por exemplo, pode oferecer apenas verificação de registros, ou combinar criação, armazenamento, busca e outras funções. MUST informar quais capacidades declara, sem tratar conformidade como aprovação oficial de todo o negócio. A tabela identifica os requisitos de cada capacidade.

Capacidade	Fronteira exigida
Autoria de registros	Emitir campos e codificações exatos da edição declarada; calcular ID e assinatura; incluir a NRC fixada em Appoints; nunca alterar silenciosamente cores assinados
Verificação de registros	Conferir §3 e informar integridade, schema, assinatura/identidade e relações separadamente; suportar o conjunto básico Ed25519 DID/assinatura
Projeção relacional	Aplicar efeitos de ciclo de vida somente após verificar autoridade; preservar pendências e conflitos; distinguir afirmações de terceiros
Armazenamento e portabilidade	Preservar cores retidos; fornecer exportação legítima segundo §8.2; declarar políticas e limites de retenção
Indexação e descoberta	Atribuir leituras ao serviço; distinguir recusa de política de falha de validade; não representar cobertura parcial como universal
Privacidade CH	Aplicar §5 às operações CH efetivamente oferecidas
Adaptador OKF	Utilizar o wrapper explícito e as regras de ida e volta da §10
Adaptador de evidência de liquidação	Identificar estágio, edição da via/protocolo e alegação verificada sob §11

A recomendação de aprovação humana aplica-se aos clientes de autoria; o verificador não pode exigir prova de presença humana ausente do conjunto criptográfico. Todos os clientes de autoria SHOULD tornar compreensíveis a declaração adotada e a decisão efetiva de divulgação.

Um serviço MAY recusar processamento, retenção, publicação ou indexação segundo suas políticas e obrigações, inclusive restrições de conteúdo, autenticação, preços, capacidade e controles de abuso. MUST NOT descrever essa recusa como assinatura inválida ou violação de schema sem estabelecer efetivamente a falha.

Um produto analítico pode publicar pontuação ou ranking próprios. Um produto conforme MUST NOT chamar sua avaliação de pontuação oficial Legible ou apresentá-la como certificada pelo autor da especificação. Conformidade técnica não certifica conformidade jurídica, adequação de privacidade, qualidade de investimento, exatidão de pagamentos, aptidão de segurança ou veracidade de registros.

Perfis suportados são explicitamente versionados. Recursos desconhecidos não são tratados silenciosamente como verificados. Um produto que utiliza did:legible não pode alegar conformidade com perfil de identidade estável a partir deste rascunho: a §12 não define intencionalmente um método interoperável completo.

10. Interoperabilidade: perfil de reconhecimento OKF

Perfil: legible-okf/0.2-draft, para OKF 0.2. Este adaptador opcional coloca declarações assinadas junto a documentos de conhecimento, sem tornar OKF ou índice específico obrigatórios. OKF 0.2 inclui proveniência, confiança e ciclo de vida; sua presença não fornece, por si, assinatura Legible ou declaração de consequência do beneficiário. Consulte a especificação oficial OKF.

O adaptador é Markdown com frontmatter YAML. O frontmatter MUST conter type OKF não vazio correspondente ao tipo do envelope Legible interno e um mapa legible com o envelope completo da §3. Campos opcionais de apresentação OKF, como title, description, resource, tags e generated, ficam fora desse mapa. O corpo Markdown também é apresentação, não conteúdo assinado adicional.

Ao importar, o adaptador extrai somente o envelope legible e o verifica normalmente. MUST conferir a correspondência do type externo ao tipo e schema internos. O produto MUST distinguir texto de apresentação e core autenticado quando diferem. Nenhum generated.at OKF ou timestamp antigo substitui o created assinado ou constitui evidência de anterioridade.

Ao exportar, o adaptador preserva exatamente os valores do core lido, não calcula outro ID nem normaliza strings recebidas. Importação→exportação→importação MUST deixar core, ID e assinatura inalterados. Metadados desconhecidos de apresentação OKF podem ser preservados quando seguro; não integram o registro assinado. Schemas Legible desconhecidos permanecem desconhecidos, sem tradução silenciosa.

Estrutura esquemática; os placeholders não são fixture assinada:

---
type: appoint
title: Human-readable projection
legible:
  id: <record-id>
  type: appoint
  canonical_content: <complete signed core>
  security: <signature and optional proofs>
---

Um link OKF pode sugerir um Trace candidato. Não é Trace assinado até alguém emiti-lo. Um índice OKF compartilhado pode fornecer candidatos a muitos leitores sem receber seus CHs privados ou adquirir autoridade sobre validade. Uma edição futura de OKF exige atualização identificada do adaptador, não mudança implícita deste mapeamento.

11. Interoperabilidade: evidência de liquidação e AP2/x402

Perfil: legible-settlement-evidence/0.2-draft. Classifica referências a evidências externas de pagamento; não inicia, roteia, custodia ou liquida fundos. Um produto que integra pagamentos o faz em sua própria função operacional.

economic.amount informa a transferência declarada pelo reconhecedor. Evidências opcionais sustentam proposições mais delimitadas:

Estágio	Proposição possível	O que não decorre automaticamente
authorization	Uma parte autorizou uma ação sob restrições indicadas	Que o dinheiro circulou
instruction	Existe instrução, pedido, fatura ou submissão	Que foi aceita ou liquidada
settlement	A fonte referenciada informa transferência num estágio de conclusão	Irreversibilidade, ausência de disputa posterior ou verdade além das premissas da evidência
reversal	Uma fonte informa reembolso, estorno ou desfazimento	Alteração automática do Nod assinado anterior
other	Proposição probatória descrita separadamente	Qualquer conclusão de liquidação não expressa

A terminologia publicada de AP2 0.2 distingue Checkout e Payment Mandates, com formas abertas e fechadas. Tratam de autorização e coordenação transacional; um mandato não é, por si, recibo de liquidação concluída. Um adaptador AP2 MUST identificar a edição AP2 específica, o tipo de objeto, o emissor e a proposição verificada. Este rascunho não fixa a serialização de um SDK AP2 nem afirma implementar todas as vias de pagamento. Consulte a documentação AP2.

Um adaptador x402 ou on-chain também identifica protocolo/via, rede, interpretação transacional e premissas de confirmação suportados. Não deve inferir status de provedor licenciado, garantia universal de liquidação definitiva ou conformidade jurídica apenas pelo rótulo do tipo. Evidências bancárias, de cartão e manuais também podem ser referenciadas. O core não prescreve provedor, via nacional, token ou moeda obrigatória além da sintaxe declarada para o campo de moeda.

O hash de uma fatura prova que seus bytes foram referenciados, não que houve pagamento. Um comprovante bancário pode conter dados pessoais ou confidenciais; publicá-lo é decisão separada. Uma referência não permite recuperá-lo ou retê-lo indefinidamente. Autores podem guardar a evidência privada e fornecê-la seletivamente.

Se um pagamento declarado for posteriormente revertido, outra declaração pode explicar o acontecimento e citar evidência. Uma aplicação pode usar correção para atualizar sua leitura atual, mas MUST distinguir a correção do acontecimento externo que a motivou. Esta edição não define ledger contábil universal, regra de compensação, cobrança negativa ou total entre moedas. Contabilidade operacional e documentos jurídicos permanecem externos.

12. Anexo experimental de desenho: persistência de identidade

Estado: experimental, não perfil estável de conformidade. Este anexo examina como manter um identificador de autor quando a chave autorizada a assinar é trocada. O perfil básico Ed25519 did:key não oferece essa continuidade. O método proposto did:legible poderia usar eventos assinados de autorização para isso. A proposta ainda não define um método completo para troca interoperável de chaves ou recuperação social segura.

A direção de desenho preservada é um evento de gênese assinado seguido de eventos encadeados de autorização de chaves, com possíveis guardiões por limiar e recuperação contestável. São candidatos de desenho, não regras de autorização presumíveis por um verificador básico. Esboços e experimentos de referência existentes exigem versionamento explícito antes do uso com ativos ou histórico de identidade relevantes. .legible/did/log.json contém chaves públicas e timestamps; essa descrição de escopo não é classificação de proteção de dados.

As seguintes decisões precisam ser especificadas e testadas antes que uma edição de persistência possa alegar conformidade:

1. Schemas exatos dos eventos, hashing, domínios de assinatura, signatários autorizados e algoritmos aceitos.
2. Tratamento de dois eventos autorizados com o mesmo antecessor. Um log assinado pode bifurcar; verificar um ramo não prova que outro inexista.
3. Fonte de tempo para a janela de recuperação e meio efetivo de o titular descobrir o evento a tempo de contestá-lo. Um created controlado pelo autor não estabelece tempo transcorrido de aviso público.
4. Validação do limiar, contagem de guardiões distintos, sua substituição, recuperações simultâneas, alcance de veto e efeito de chave atual comprometida.
5. Tratamento de registros assinados por chaves históricas comprometidas, inclusive prova de existência anterior à rotação e registros com evidência temporal insuficiente.
6. Verificação offline com pacote de autorizações fornecido, eventos ausentes, visualizações desatualizadas e resultado explicitamente ambíguo diante de evidências conflitantes.

Um experimento local pode escolher essas políticas, mas MUST identificar-se como experimental e MUST NOT apresentar resolução de identidade não suportada como verificação básica bem-sucedida. Um registro de outro método DID pode ser mantido como dado quando a política permite; a autorização de seu autor permanece não suportada até que um verificador especificado a estabeleça.

A rotação não alcança a data escolhida pelo autor. Uma chave antiga roubada pode assinar registro novo com created antigo. A autorização histórica, sozinha, não o distingue de registro antigo legítimo. Um compromisso verificado anterior ao comprometimento pode fornecer evidência; um timestamp posterior não prova falsificação, porque um registro genuíno pode ter sido testemunhado tarde.

Imutabilidade dos guardiões, veto indefinido e regras específicas de disputa são escolhas com custos e benefícios, não consequências inevitáveis da ausência de operador central. Um perfil futuro pode fazer escolhas diferentes e precisa declarar suas novas premissas. O core não promete agilidade de algoritmos ou recuperação que não especificou.

13. Substrato, testemunhas e adoção

Três verificações frequentemente se confundem e precisam permanecer separadas:

1. Integridade: o core corresponde ao ID.
2. Atribuição: a chave especificada assinou esse ID sob o namespace correto.
3. Evidência temporal: uma testemunha externa sustenta que o core comprometido existia até determinado momento.

O arquivo básico fornece as duas primeiras. A terceira exige material probatório e política de confiança. Às vezes pode ser conferida offline quando esse material, certificados e dados relevantes de cadeia ou log já estão disponíveis. “Evidência externa” nem sempre significa “fazer uma requisição de rede agora”.

Num adaptador RFC 3161, o message imprint do token precisa coincidir com o algoritmo de hash declarado aplicado à mensagem UTF-8 do ID. O adaptador confere integridade do token, assinatura TSA, requisitos pertinentes de certificado/confiança e alegação temporal sob política de verificação informada. O token não prova autoria humana nem o momento da concepção da ideia. RFC 3161.

Num log público ou testemunha em cadeia, o adaptador precisa estabelecer inclusão, ordenação e premissas de confiança aplicáveis. Um compromisso de hash não publica automaticamente o conteúdo nem fornece catálogo completo de declarações de uma chave. Em particular, OpenTimestamps é evidência de existência anterior, não índice público de declarações por autor. OpenTimestamps.

Múltiplas testemunhas independentes podem melhorar a evidência do leitor. Ele precisa informar se exige uma, várias ou um conjunto específico de confiança antes de concluir sobre o tempo. Um array de provas não faz, sozinho, com que uma falsificação exija comprometer todas as testemunhas listadas.

Git é o substrato recomendado, por familiaridade, histórico e portabilidade, não por ser relógio confiável. Commit local não prova horário de publicação remota. Push público pode fornecer evidência por observador ou serviço externo, cuja confiabilidade e registros disponíveis ainda importam. Apagar um arquivo da árvore de trabalho não o retira de objetos históricos ou clones.

Git e adaptador OKF opcional podem reduzir parte do custo de adoção. Não criam leitores ou incentivos de reconhecimento sozinhos. O valor inicial pode ser local: preservar uma formulação e sua genealogia declarada antes de outra instituição escolhê-la. Coordenação mais ampla depende de descoberta, uso efetivo e pessoas decidirem tornar legível seu reconhecimento.

---

14. Considerações de segurança

A verificação de um registro confere propriedades como integridade e assinatura. A segurança de uma aplicação também depende de como ela guarda chaves, recebe conteúdo, consulta a rede e publica dados. Esta seção reúne as ameaças e os limites que o operador precisa considerar nessas operações. Os testes de conformidade não constituem uma auditoria de segurança da aplicação.

Ameaça ou limite	O que o desenho fornece	O que não fornece
Core falsificado ou alterado	Endereçamento por conteúdo e verificação de assinatura sob o conjunto especificado	Verdade, honestidade ou resistência após comprometimento da chave
Reuso de assinatura entre protocolos	Verificação exata do namespace legible	Proteção quando signatário legítimo aprova conteúdo malicioso
Chave comprometida	Atribuição à chave; limite explícito do perfil básico	Revogação ou recuperação em did:key
Identidades Sybil e conluio	Declarações examináveis; ausência de pontuação oficial para inflar	Prova de pessoas únicas ou dependências genuínas
Alegações conflitantes para leitores diferentes	Registros separados atribuídos, se obtidos pelos leitores	Descoberta universal, consenso ou detecção automática de contradições
Genealogia falsa de terceiros	Atribuição ao declarante separada da genealogia de origem	Concordância do beneficiário ou causalidade comprovada
Conteúdo prejudicial ou ilícito	Políticas do serviço, alertas de autoria e publicação atribuível	Classificação jurídica semântica pelo verificador criptográfico
Retirada	Pedido atribuível e tratamento local	Apagamento de cópias externas, caches, backups ou histórico Git
Grafo incompleto	Resultados explícitos de não resolvido e indisponível	Prova de que um registro ausente nunca foi emitido
Esgotamento de recursos	Lista de origem limitada e limites locais permitidos	Ingestão segura ilimitada ou leitura economicamente viável de todo registro

Comprometimento do ambiente e da chave. Malware pode usar indevidamente uma chave desbloqueada ou substituir o que a pessoa vê. Aprovação por registro e custódia em hardware compatível reduzem riscos específicos; não demonstram revisão consciente na assinatura final. O perfil básico não tem cadastro de revogação. Se uma chave é comprometida, uma chave nova cria identidade básica diferente, e leitores precisam de contexto externo para avaliar continuidade.

Declarações divergentes e acontecimentos sobrepostos. Dois Nods com valores distintos não são necessariamente contraditórios: podem descrever transferências, contextos ou correção declarada diferentes. A contradição exige identificar proposições incompatíveis sobre o mesmo acontecimento. Um log público só melhora a visibilidade quando suas regras de publicação, inclusão, disponibilidade e monitoramento efetivamente o fazem. Um timestamp isolado sobre hash não divulgado não oferece essas garantias.

Privacidade dos compromissos. Digests sem salt de dados adivinháveis permitem testes de dicionário. Compromissos privados utilizam a construção da §3.0, com nonce secreto aleatório e abertura controlada separadamente. Hashes, assinaturas, referências e chaves públicas ainda podem permitir associação; opacidade não é alegação de anonimato. Publicar o core expõe todo texto livre nele contido.

Minimização de dados. Clientes de autoria SHOULD desencorajar dados pessoais e detalhes confidenciais desnecessários em texto livre e SHOULD explicitar o escopo de publicação. Não conseguem decidir confiavelmente toda questão semântica ou jurídica. As próprias referências podem identificar pessoas. Registro assinado ou publicamente acessível não constitui base jurídica geral para todo tratamento posterior.

Conteúdo hostil para agentes. Um registro verificado é entrada autenticada, não instrução com autoridade sobre o leitor. Pode conter prompt injection, links maliciosos, pedidos de assinatura ou instruções para revelar CH. Agentes e aplicações MUST NOT transformar conteúdo em autorização de ferramentas apenas porque a assinatura verifica. Recuperação por rede SHOULD aplicar políticas de destinos e esquemas, evitar acesso não autorizado a recursos locais ou de redes privadas e tratar o conteúdo recuperado como não confiável. Verificar não executa código referenciado.

Esgotamento e parsing. Limite tamanho de arquivos, profundidade, recuperação paralela, percurso do grafo e validação de provas conforme a capacidade do serviço. Rejeite recursos YAML inseguros antes da expansão. Registre explicitamente nós visitados e conflitos. Recusa por cota é decisão de processamento, não prova de mentira do signatário.

Sem pressuposto de estado compartilhado. O leitor vê um subconjunto acessível num momento. Não deve utilizar created autodeclarado como relógio global de resolução de conflitos, presumir que toda proposta aceita continue atual ou restaurar um valor corrigido porque um registro posterior desapareceu. Pode conservar evidências anteriormente verificadas conforme política e lei, distinguindo sua base probatória de uma verificação nova.

Exposição a modelos hospedados. Enviar CH a um provedor é divulgação efetiva sob o arranjo de processamento escolhido. Compromissos de privacidade, retenção, treinamento e segurança do provedor precisam de avaliação separada.

Inferência por ausência e concentração. Registro privado, visibilidade seletiva e indexação incompleta limitam o significado do silêncio. Leitores e sistemas de recuperação compartilhados podem convergir mesmo sem pontuação canônica. O protocolo permite alternativas e explicita suas funções; não exige concorrência efetiva nem garante resultados plurais.

15. As perguntas que o protocolo torna legíveis

Pergunta	O que o leitor pode examinar
Quem formulou isto?	Declaração atribuída do Appoint e evidências de apoio
Em que o trabalho se apoiou?	Traces de origem e independentes, distinguindo seus declarantes
Quem afirma ter se beneficiado?	Nods assinados pelos beneficiários declarados
O que foi reconhecido e como?	Consequência declarada, forma escolhida, montante se monetário e evidências opcionais
Como o reconhecimento foi recebido?	Respostas autorizadas e histórico explícito de substituição
Quais alegações foram revistas ou retiradas?	Correções, substituições e retiradas dentro da evidência acessível
O que merece confiança ou novos recursos?	Julgamento contextual do leitor, não resposta do protocolo

Git ajuda a preservar o que mudou e a informação de autoria fornecida num commit; seus metadados não autenticam, sozinhos, identidade civil. O Legible torna examinável outra pergunta: quem declarou que uma contribuição lhe importou, e de que maneira? Um Nod atribui o reconhecimento à chave; não estabelece valor universal ou verdade da consequência.

Os registros preservam formulações, dependências e consequências declaradas para consideração por diferentes leitores. Sua atribuição pode ser conferida entre serviços; a avaliação e as condições de operação seguem §§8 e 16.

16. Licenças e escopo

Esta especificação, inclusive o texto NRC, está disponível sob CC BY 4.0. Código de referência identificado como tal é distribuído sob Apache-2.0. As licenças respectivas regem reutilização, atribuição, exclusões de garantias e limitações de responsabilidade.

Conformidade descreve compatibilidade técnica com capacidade e edição identificadas. Não implica certificação ou endosso da implementação pelo autor da especificação. Aplicações e serviços operam sob seus próprios termos e arranjos; essas atividades são separadas da publicação deste formato.

Registros contêm declarações dos signatários. A assinatura verifica atribuição à chave, não verdade de alegação, titularidade da obra ou autoridade jurídica. A NCO é declaração do signatário, não certificação pelo autor da especificação.

O protocolo registra reconhecimento e referencia evidências externas; não executa pagamentos nem determina os efeitos jurídicos de declaração, assinatura ou acordo. Esses efeitos dependem dos atos efetivos das partes, termos e lei aplicáveis.

---

Agradecimentos

O autor agradece às pessoas abaixo por diálogos e experiências que contribuíram para a formação de suas ideias. Os agradecimentos descrevem essa relação intelectual; não indicam participação na operação do protocolo, certificação ou endosso. As escolhas editoriais são do autor.

• Oswaldo Oliveira (in memoriam, falecido em 2017): escassez/abundância e prática organizacional Prospera.
• Carl Amorim: coautoria do manifesto Prospera e prática que experimentou seus princípios.
• Marcelo Michelsohn: experimentação conjunta de coordenação distribuída, desde Project Syntropy.
• Amanda Guimarães: síntese filosófica e diálogo continuado.
• Courtnay Guimarães: provocação intelectual e defesa adversarial.
• Fernando Lemos: interrogação arquitetural e caminhos corporativos.

Genealogia intelectual e seus limites estão nas obras de apoio do autor, que não integram nem condicionam a norma.

Referências normativas

Somente os subconjuntos explicitamente especificados vinculam suas capacidades. Referenciar documento externo não delega alterações de versão a site mutável. Os títulos bibliográficos são preservados em sua língua original.

1. RFC 2119 e RFC 8174: linguagem de requisitos BCP 14.
2. RFC 8259 e RFC 8785: JSON e JCS, com as restrições adicionais de entrada da §3.0.
3. YAML 1.2.2: serialização alternativa, restrita ao subconjunto explícito da §3.0.
4. Unicode Normalization Forms, UAX #15: NFC para strings do core antes da emissão. As implementações devem documentar as versões Unicode suportadas; strings recebidas nunca são reescritas silenciosamente.
5. RFC 8032: Ed25519; OpenSSH SSHSIG format: estrutura de assinatura, restrita pela §3.0.
6. DID Core 1.0 e did:key method: sintaxe de identificadores e codificação básica de chave; o subconjunto Ed25519 exato é fixado na §3.0.
7. FIPS 180-4: SHA-256 para IDs e compromissos especificados.

Referências específicas de perfil: RFC 3161 para adaptador TSA declarado; OKF 0.2 para §10; edição AP2/x402 e especificações da via explicitamente identificadas para adaptador de liquidação declarado. Esses perfis não são requisitos dos registros básicos.

Referências informativas

---

• [ALM03] Autor, D. H., Levy, F., & Murnane, R. J. (2003). The Skill Content of Recent Technological Change: An Empirical Exploration. Quarterly Journal of Economics, 118(4), 1279–1333.
• [AA11] Acemoglu, D., & Autor, D. (2011). Skills, Tasks and Technologies: Implications for Employment and Earnings. Handbook of Labor Economics, vol. 4B, 1043–1171.
• [Aut14] Autor, D. H. (2014). Polanyi's Paradox and the Shape of Employment Growth. NBER Working Paper 20485.
• [NZ23] Noy, S., & Zhang, W. (2023). Experimental Evidence on the Productivity Effects of Generative Artificial Intelligence. Science, 381(6654), 187–192.
• [BLR25] Brynjolfsson, E., Li, D., & Raymond, L. (2025). Generative AI at Work. Quarterly Journal of Economics, 140(2), 889–942.
• [DA23] Dell'Acqua, F., et al. (2023). Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality. Harvard Business School Working Paper 24-013.

---

Referências adicionais:

• Open Knowledge Format, integração opcional de documentos de conhecimento.
• AP2 e x402, integrações opcionais com protocolos externos de pagamento.
• OpenTimestamps, evidência temporal opcional.
• As licenças da §16 regem a reutilização da especificação e do código de referência, não a validade dos registros.

Apêndice A. Texto canônico NRC 0.2

Os bytes canônicos são o texto português UTF-8 dentro do bloco, com LF, sem BOM ou indentação e um LF após a última linha. Delimitadores não entram. O digest é sha256:42b9c41ee986a5b90c67302283d7f2ea6813979a17f41734e35b51a0e5a3953b. A tradução inglesa em nrc/v0.2/nrc-EN.txt é uma referência de leitura e não substitui esses bytes.

Convenção de Reconhecimento por Nod 0.2
Esta convenção distingue o reconhecimento de consequência da permissão para usar uma obra.
Um participante que adota esta convenção registra um Nod quando realiza valor econômico em uma transação de troca a partir de uma contribuição declarada sob esta convenção, identificando a contribuição e a consequência que recebeu.
O registro pode ser privado, restrito a um grupo ou público. A publicação é uma decisão separada.
O reconhecimento pode não incluir pagamento. Qualquer montante monetário ou oferta não monetária é escolhido pelo reconhecedor; esta convenção não estabelece mínimo, percentual, dívida ou direito automático.
Um Nod monetário informa o montante declarado como transferido em reconhecimento, não o benefício total recebido pelo reconhecedor. O benefício pode ser explicado separadamente.
A convenção não oferece mecanismo de cobrança, execução, penalidade ou exigência. Não obriga à continuidade da colaboração nem à oferta de recursos futuros.
Um registro contém uma declaração, não uma consequência verificada, uma determinação de direitos ou prova de cumprimento por qualquer outra pessoa. A ausência de Nod público não demonstra ausência de registro.
Adotar esta convenção não vincula, por si só, outra pessoa a um contrato nem altera a licença da obra. Eventuais obrigações jurídicas dependem da lei aplicável e dos atos e acordos efetivos das partes.

Apêndice B. Exemplos fictícios assinados

Estes exemplos pertencem à base inicial de publicação e utilizam os schemas v2, a NCO portuguesa e o digest da NRC portuguesa do Apêndice A. As identidades e assinaturas servem exclusivamente aos testes.

Registros fictícios, não transações reais nem declarações de participantes. Chaves privadas de teste são deliberadamente públicas; nunca as use em operação. Cada seed Ed25519 é SHA-256 de legible-v1-public-fixture: seguido de ana, recognizer ou curator. Derive DID sob §3.0. Estes cores usam ASCII e peso inteiro 1, permitindo JSON compacto ordenado como JCS neste caso restrito; isso não substitui JCS geral. Não traduzimos conteúdo assinado ou assinaturas.

Exemplos: formulação sem solução, Appoint dependente, curadoria, montante errado e sua correção, resposta autorizada e retirada. Reconhecimento corrigido é BRL 100, não BRL 1.100. Benefício BRL 10.000 aparece somente na explicação. Eles não comprovam pagamento. Hashes/assinaturas são verificáveis com OpenSSH; mensagem alterada e namespace errado devem falhar. Isso não certifica segurança, parser geral ou implantação.

01-appoint

{
  "id": "8f8aea6e732adc78a6dc5ab5341415aacff280c4055e2e4ea104427b5bb926ab",
  "type": "appoint",
  "canonical_content": {
    "accepts-monetary": true,
    "accepts-non-monetary": true,
    "author": "did:key:z6MkmxdZv6WLYxFmajNpvhyUy6Dr6kcFzE75mMopZWANqHX7",
    "content_schema": "legible/protocol/v2/appoint",
    "created": "2026-09-19T12:00:00Z",
    "metadata": {
      "title": "A reusable export method"
    },
    "nrc": "0.2",
    "nrc-hash": "sha256:42b9c41ee986a5b90c67302283d7f2ea6813979a17f41734e35b51a0e5a3953b",
    "payload": {
      "problem": "How can a software project export its data without tying users to one provider?"
    },
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgb4f852IKOREtTUDuXV3awLtTYp\nC7i8DSUxRYWCs1ZcIAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAEBWN3q192Qx7GG6yMmkkhN8Y/Pdl9LXt/hFm+h978HCJxZC4hmn+48hE2GKEJ\nhBp8NJD/lSMWTBZAaNXHE3O68I\n-----END SSH SIGNATURE-----\n"
  }
}

---

02-dependent-appoint

{
  "id": "2e3876c9a2bcdcee3ea26b690dad892ba7f56ef20c8c717182e74573579de7cb",
  "type": "appoint",
  "canonical_content": {
    "accepts-monetary": true,
    "accepts-non-monetary": false,
    "author": "did:key:z6MkuAa5axDG7AzQHJwSUDVmzBEtkKTyxQrjAduVZwbhqjpw",
    "content_schema": "legible/protocol/v2/appoint",
    "created": "2026-09-19T12:01:00Z",
    "metadata": {
      "title": "Software using the export method"
    },
    "nrc": "0.2",
    "nrc-hash": "sha256:42b9c41ee986a5b90c67302283d7f2ea6813979a17f41734e35b51a0e5a3953b",
    "payload": {
      "problem": "Users need to move their project data.",
      "solution": "Implement the referenced export method."
    },
    "traces": [
      {
        "relationship-type": "uses",
        "target": "8f8aea6e732adc78a6dc5ab5341415aacff280c4055e2e4ea104427b5bb926ab",
        "weight": 1
      }
    ],
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAg2pjSWrsLaWOIQAEXHmEVZs53Y8\nOoV6RCqozbyK6iAYQAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAEAjrvi2lpPoENQyRpxZcKN55lDMDCUwtz6z98d4Rne2P3uJN8U47IrssmC9xK\nOkFLfWc6X604pfeTzW74bqd8IO\n-----END SSH SIGNATURE-----\n"
  }
}

---

03-curator-trace

{
  "id": "c977756d0a8d7761806f2394b232b8a13e600c51757c541e1b2ec18e9a05dd33",
  "type": "trace",
  "canonical_content": {
    "author": "did:key:z6MktHWjMTwzfn6h6U8wFyby42qb3HvWqtkVEXajNk2ttJUp",
    "content_schema": "legible/protocol/v2/trace",
    "created": "2026-09-19T12:02:00Z",
    "note": "A curator asserts this dependency; this is not a declaration by the source author.",
    "relationship-type": "uses",
    "source": "2e3876c9a2bcdcee3ea26b690dad892ba7f56ef20c8c717182e74573579de7cb",
    "target": "8f8aea6e732adc78a6dc5ab5341415aacff280c4055e2e4ea104427b5bb926ab",
    "visibility": "public",
    "weight": 1
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgzYRp9NZVleKRxySvxChAADdWHr\ngJr9wcjGKMPKXCmLkAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAEAxxK6zA0SWuhzjB1mD9SIxYZU4b5/KD9150AQB5TzHHAxIfEwWs4zojaOS7d\ngMcZCif8xfz9zhfqBwrSJPj+MB\n-----END SSH SIGNATURE-----\n"
  }
}

---

04-initial-nod

{
  "id": "d5c2a9a89c1fcb664a6a6a272bea71305949b0eed67edf69a523116953b08990",
  "type": "nod",
  "canonical_content": {
    "author": "did:key:z6MkuAa5axDG7AzQHJwSUDVmzBEtkKTyxQrjAduVZwbhqjpw",
    "consequence": "enabled",
    "content_schema": "legible/protocol/v2/nod",
    "created": "2026-09-19T12:03:00Z",
    "economic": {
      "amount": "1000.00",
      "currency": "BRL"
    },
    "form": "monetary",
    "nod-type": "recognition",
    "nods": "8f8aea6e732adc78a6dc5ab5341415aacff280c4055e2e4ea104427b5bb926ab",
    "statement": "The contribution enabled the software sale. This initial amount contains a transcription error.",
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAg2pjSWrsLaWOIQAEXHmEVZs53Y8\nOoV6RCqozbyK6iAYQAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAECVFTg+wU/cJCAnwUfdf29yXUmpI0YJFVdIALm4Q1RwqztpD/bD+Y3iCXsLFO\nfGChFVEANFsp0+Dw8AfUvngS8P\n-----END SSH SIGNATURE-----\n"
  }
}

---

05-corrected-nod

{
  "id": "aebedf660cd240eebe01cc4bf3225a012d724e80f3f95bc5b7b77d2476f12b4e",
  "type": "nod",
  "canonical_content": {
    "author": "did:key:z6MkuAa5axDG7AzQHJwSUDVmzBEtkKTyxQrjAduVZwbhqjpw",
    "consequence": "enabled",
    "content_schema": "legible/protocol/v2/nod",
    "corrects": "d5c2a9a89c1fcb664a6a6a272bea71305949b0eed67edf69a523116953b08990",
    "created": "2026-09-19T12:04:00Z",
    "economic": {
      "amount": "100.00",
      "currency": "BRL"
    },
    "form": "monetary",
    "nod-type": "recognition",
    "nods": "8f8aea6e732adc78a6dc5ab5341415aacff280c4055e2e4ea104427b5bb926ab",
    "statement": "The contribution enabled a BRL 10000.00 sale. The amount transferred in recognition was BRL 100.00. This corrects the earlier amount; it does not declare a refund.",
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAg2pjSWrsLaWOIQAEXHmEVZs53Y8\nOoV6RCqozbyK6iAYQAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAED985P5YjZO8tXsZfm07MBhQmlclpSzXUTa5ny8vxdF23mYAB3I1JP0R+Xtnt\nU3W3XqrSQdCkhHHst5jRVI7KUL\n-----END SSH SIGNATURE-----\n"
  }
}

---

06-response

{
  "id": "8c896411bda37d14787299983b77a65012759ff5addeb53e3a92eac4567f57ec",
  "type": "response",
  "canonical_content": {
    "about-nod": "aebedf660cd240eebe01cc4bf3225a012d724e80f3f95bc5b7b77d2476f12b4e",
    "author": "did:key:z6MkmxdZv6WLYxFmajNpvhyUy6Dr6kcFzE75mMopZWANqHX7",
    "content_schema": "legible/protocol/v2/response",
    "created": "2026-09-19T12:05:00Z",
    "kind": "adequacy",
    "signal": "adequate",
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgb4f852IKOREtTUDuXV3awLtTYp\nC7i8DSUxRYWCs1ZcIAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAEBzwUXvWoSCXAUKy8X9bF+Kf/tAJ5rJeybfAGngDYD/Q2W72W3fcVHkOyDtCk\nXxzAh6j0+Q1Y8QucpGag5hv04G\n-----END SSH SIGNATURE-----\n"
  }
}

---

07-redaction

{
  "id": "f8e165d7fab903bcf7469c2423e7b2deb5dd5d1caed17d16be01b3f59bc98382",
  "type": "redaction",
  "canonical_content": {
    "author": "did:key:z6MkmxdZv6WLYxFmajNpvhyUy6Dr6kcFzE75mMopZWANqHX7",
    "content_schema": "legible/protocol/v2/redaction",
    "created": "2026-09-19T12:06:00Z",
    "redacts": "8c896411bda37d14787299983b77a65012759ff5addeb53e3a92eac4567f57ec",
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgb4f852IKOREtTUDuXV3awLtTYp\nC7i8DSUxRYWCs1ZcIAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAEBwOHSqTX8liju54Hh1EnsxwUyVtoQrZmR6SGKr0jlJ15079+JG6Kd1xYc3gB\n74mC5xTeHGbMF+27zgTXCLyv8L\n-----END SSH SIGNATURE-----\n"
  }
}

---

Apêndice C. Implementação e casos de conformidade

Cada implementação identifica as capacidades que oferece e os testes que executa. A distribuição inclui a NRC, os schemas, casos positivos e negativos e as licenças para apoiar essa verificação.

Uma avaliação de conformidade examina JCS entre linguagens, NFC, chaves duplicadas, schemas desconhecidos, campos opcionais, correspondência do tipo externo e namespace da assinatura. Também considera relações não autorizadas, alvos ausentes, conflitos, substituição de respostas, registros tardios, ciclos, recusas por política, retirada e ida e volta de documentos OKF, conforme as capacidades declaradas. A recuperação de identidade continua experimental.

Os testes implementados estão identificados em conformance/README.md e conformance/demos/README.md. O roteiro acima também inclui casos a avaliar; não significa que todos estejam implementados ou aprovados. Esta distribuição ainda não inclui um teste específico de ida e volta do wrapper OKF. A compatibilidade com outro produto exige sua própria evidência de execução.

Legible pode ser examinado, implementado, criticado e bifurcado. Propostas independentes identificam autoria, artefato normativo e diferenças, com nomes e versões próprios. Essa relação não estabelece sucessão oficial nem vínculo operacional entre seus mantenedores.

Apêndice D. Artefatos de conformidade

O conjunto de conformidade está em conformance/vectors.json, a fixture assinada em conformance/signed-fixture.json e os sete exemplos completos em conformance/records.json. Os schemas estão em schemas/. Todos pertencem à base inicial identificada por v2 e utilizam identidades fictícias. Um verificador que declara suporte a esta edição MUST reproduzir seus IDs e conferir as assinaturas de teste. Uma edição desconhecida MUST NOT ser reinterpretada como v2. Os testes cobrem também alterações de conteúdo, namespace incorreto e as relações de ciclo de vida da §3.6. A NRC é o texto português e o digest exatos do Apêndice A.

Apêndice E. Fundamentação econômica (informativo)

Este apêndice reúne a motivação econômica do desenho. As hipóteses e referências ajudam a examinar a proposta; não acrescentam requisitos de validade aos registros.

E.1 Custos de registro e leitura

Preservar contribuições antes de selecioná-las não é uma ideia nova. Seu alcance prático depende dos custos de registrar, manter, encontrar e examinar o material. Uma pessoa pode formular algo que não cabe numa tarefa já atribuída; preservar essa formulação permite que outro leitor a considere depois, onde houver armazenamento e acesso adequados.

O argumento do autor é que títulos, credenciais e categorias podem funcionar como aproximações quando examinar cada contribuição é caro. Se o custo total de registro e leitura útil cair, pode ser viável considerar material antes excluído por esses filtros. Assistentes podem ajudar a descrever intervenções durante o trabalho e a buscar fontes segundo uma pergunta particular. A atenção continua finita; a hipótese não pressupõe que toda contribuição seja lida.

E.2 Execução, iniciativa e julgamento

A literatura baseada em tarefas descreve substituição tecnológica de tarefas, não de trabalhadores, sobretudo da execução rotineira codificável, com maior demanda por trabalho cognitivo não rotineiro [ALM03], [AA11]. Quando executar é o gargalo, a entrega funciona como aproximação suficiente da contribuição. Quando a execução cognitiva se torna mais acessível, iniciativa, compromisso e julgamento podem importar relativamente mais. A execução barata não cria seu valor; pode revelar valor que antes não precisava ser registrado.

Uma entrega deixa um artefato; a iniciativa e o julgamento que a tornaram útil nem sempre deixam um registro comparável. O argumento vai além daquela literatura: sistemas generativos também passaram a assistir ou substituir atividades cognitivas não rotineiras, associadas ao paradoxo de Polanyi [Aut14]. Estudos empíricos e experimentos reportam ganhos modestos e desiguais, na ordem de dezenas por cento por tarefa, e resultados piores fora da fronteira de capacidade [NZ23], [BLR25], [DA23]. Esses resultados não estabelecem execução universal a custo zero.

A hipótese é uma assimetria possível entre o custo da execução e o custo de escolher propósitos, assumir responsabilidade e comprometer recursos. Seu alcance varia por atividade e pelas capacidades disponíveis; não é uma lei permanente nem uma previsão sobre o que máquinas jamais farão. O protocolo permite declarar quem atuou em cada camada. A recomendação de aprovação humana na assinatura concerne à assunção da declaração (§2.1); o arquivo não prova presença ou compreensão humana.

E.3 O que observar numa experiência

Uma experiência pode examinar se participantes conseguem preservar perguntas antes da atribuição de trabalho, encontrar contribuições acessíveis que seus filtros anteriores excluiriam e usá-las em novas formulações ou decisões. Custos de descrição, busca, revisão e manutenção precisam entrar nessa avaliação. Uma troca de registros que funciona demonstra operações; o benefício de coordenação exige observação própria, inclusive de resultados inconclusivos ou adversos. As obras de apoio do autor desenvolvem o argumento mais amplo.

Ler esta página em Markdown