# 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](../examples/README_PT-BR.md) 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](#apêndice-e-fundamentação-econômica-informativo)
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](https://www.rfc-editor.org/rfc/rfc8785.html).

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](https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.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](../examples/README_PT-BR.md#case-rd)
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](../docs/indexing-and-responsibility.md), 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](../docs/economic-coordination-PT.md),
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](../docs/economic-coordination-PT.md) 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](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md).

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:

```yaml
---
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](https://ap2-protocol.org/).

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](https://www.rfc-editor.org/rfc/rfc3161.html).

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](https://opentimestamps.org/).

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](https://creativecommons.org/licenses/by/4.0/legalcode.en). Código de referência identificado como tal é distribuído sob [Apache-2.0](https://www.apache.org/licenses/LICENSE-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](https://www.rfc-editor.org/rfc/rfc2119.html) e [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174.html): linguagem de requisitos BCP 14.
2. [RFC 8259](https://www.rfc-editor.org/rfc/rfc8259.html) e [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785.html): JSON e JCS, com as restrições adicionais de entrada da §3.0.
3. [YAML 1.2.2](https://yaml.org/spec/1.2.2/): serialização alternativa, restrita ao subconjunto explícito da §3.0.
4. [Unicode Normalization Forms, UAX #15](https://www.unicode.org/reports/tr15/): 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](https://www.rfc-editor.org/rfc/rfc8032.html): Ed25519; [OpenSSH SSHSIG format](https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.sshsig): estrutura de assinatura, restrita pela §3.0.
6. [DID Core 1.0](https://www.w3.org/TR/did-core/) e [did:key method](https://w3c-ccg.github.io/did-key-spec/): sintaxe de identificadores e codificação básica de chave; o subconjunto Ed25519 exato é fixado na §3.0.
7. [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final): 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](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md), integração opcional de documentos de conhecimento.
- [AP2](https://ap2-protocol.org/) e [x402](https://www.x402.org/), integrações opcionais com protocolos externos de pagamento.
- [OpenTimestamps](https://opentimestamps.org/), 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.

```text
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

```json
{
  "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

```json
{
  "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

```json
{
  "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

```json
{
  "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

```json
{
  "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

```json
{
  "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

```json
{
  "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.