Alguns meses atrás, publiquei aqui o texto , onde contei por que abandonamos o sonho do "grande banco de dados centralizado" e assumimos que o Conhecimento Tradicional Associado à biodiversidade (CTA) exige uma arquitetura federada. A frase que resumiu aquele incômodo continua valendo:
"Se os dados não estão fisicamente sob o controle de quem os gerou, a soberania é apenas uma promessa bonita em um termo de consentimento."
De lá para cá, a proposta amadureceu bastante. A versão 3.3 da Arquitetura para um Sistema de Informações sobre Conhecimento Tradicional Associado à Biodiversidade está inteira, documentada e aberta no GitHub, com DOI, histórico de versões e registro das decisões técnicas:
Este post é uma divulgação de até onde chegamos e um convite. Antes dele, porém, deixe-me contar o que mudou.
Quatro fontes, não duas
A primeira mudança é a mais fácil de explicar, e talvez a mais bonita.
Na versão anterior, a arquitetura reconhecia dois caminhos pelos quais uma evidência de conhecimento tradicional chega até nós: o artigo científico (fonte secundária) e o relato de campo, registrado diretamente com a comunidade detentora (fonte primária). Ao conversar com colegas de museus, arquivos e herbários, ficou evidente que estávamos deixando duas portas enormes fechadas.
A versão 3.2 abriu essas portas. Hoje a federação acolhe quatro tipos de fonte de evidência:
| Fonte | O que é | Ferramenta |
|---|---|---|
| Secundária | Artigos, teses e livros já publicados | BioCultDB + BioCultPapers |
| Primária | Relato registrado em campo, junto à comunidade (CLPI obrigatório) | BioCultRelatos |
| Acervos históricos e museológicos | Coleções, registros e documentos guardados em museus e arquivos | BioCultAcervos |
| Obras de naturalistas | Relatos de viajantes que percorreram o Brasil nos séculos XVII a XIX | BioCultNaturalistas |
Repare no que essas quatro fontes têm em comum: todas descrevem a relação entre pessoas e a biodiversidade, e todas dizem respeito a alguém. Uma anotação feita por um naturalista alemão em 1817 sobre o preparo de uma raiz não é um dado "sem dono" só porque é antiga. Ela descreve a prática de uma comunidade que, muito provavelmente, ainda existe. Se essa evidência descreve o saber de um povo, esse povo mantém autoridade sobre como ela é registrada, usada e compartilhada — venha ela de um PDF de 2024 ou de um manuscrito de dois séculos atrás. É o A dos princípios C.A.R.E. (Authority to Control) aplicado sem exceções, inclusive retroativamente.
Soberania que cabe num pen drive
A segunda mudança é técnica, quase modesta, e mudou tudo.
Na versão 3.0, cada membro da federação era soberano — mas soberano exigindo um servidor de banco de dados rodando, configurado e administrado. Na prática, isso significava dizer a uma associação comunitária: "vocês têm total autonomia sobre seus dados, basta manter um MongoDB no ar". É uma soberania que só se realiza para quem tem equipe de TI.
A versão 3.1 resolveu esse nó com uma decisão simples: cada unidade federada guarda tudo em um único arquivo SQLite com JSON, compartilhado entre as ferramentas daquela unidade. Sem servidor de banco de dados, sem administrador, sem dependência externa.
O efeito prático é enorme:
-
Fazer backup vira copiar um arquivo.
-
Levar os dados embora vira copiar um arquivo.
-
Saber exatamente onde mora o conhecimento da comunidade vira apontar para um arquivo.
Quando alguém pergunta "onde estão os nossos dados?", a resposta deixa de ser um diagrama de nuvem e passa a ser um objeto concreto, que se copia, se guarda e se leva. Soberania deixa de ser cláusula contratual e vira propriedade física.
As peças do ecossistema
Vale reapresentar os personagens, agora que são sete:
-
BioCultDB — a biblioteca do que já foi publicado. Interface web com três ambientes bem separados: Aquisição (onde o pesquisador digita), Curadoria (onde alguém valida) e Apresentação (onde o público consulta, com painel analítico e assistente conversacional). É a peça mais madura, em produção.
-
BioCultPapers — o garimpeiro com IA. Aplicativo de desktop que lê montanhas de PDFs científicos e extrai, de forma estruturada, espécies, usos, comunidades e localidades. Poupa meses de trabalho manual.
-
BioCultRelatos — a escuta atenta e consentida. Dedicado ao registro primário, em campo. Aqui a regra de ouro é o CLPI (Consentimento Livre, Prévio e Informado), exigido pela Lei 13.123/2015. Sem "sim" explícito e documentado, o dado não entra.
-
BioCultAcervos — a memória institucional. Para as evidências que dormem em coleções, arquivos e museus.
-
BioCultNaturalistas — o olhar do viajante, revisitado. Para as obras dos séculos XVII a XIX, uma fonte riquíssima e ainda muito pouco sistematizada.
-
BioCultTermos — o guardião da linguagem. Plataforma de vocabulários controlados no padrão SKOS-XL, da W3C. Cada membro roda a sua própria instância, com o seu próprio vocabulário. Ninguém é obrigado a adotar a taxonomia conceitual de outro.
-
Pluriverso — a ponte. O middleware que conecta todo mundo sem administrar os dados de ninguém.
Sejamos honestos sobre o estágio de cada um: BioCultDB, BioCultPapers e BioCultTermos existem e funcionam. BioCultRelatos está em desenvolvimento inicial. BioCultAcervos, BioCultNaturalistas e o próprio Pluriverso, hoje, são repositório e documentação — arquitetura definida, código por escrever. É exatamente por isso que esta proposta está pública agora, e não depois de pronta.
O Pluriverso não é um só
A terceira mudança, trazida pela versão 3.3, corrige um vício de origem que eu mesmo não tinha percebido.
Eu vinha desenhando o Pluriverso como um componente único — o índice nacional, a ponte, no singular. Repare na armadilha: acabei reintroduzindo pela porta dos fundos exatamente o centralismo que a federação queria evitar. Só que, dessa vez, disfarçado de infraestrutura neutra.
A versão 3.3 generaliza o Pluriverso como componente instanciável em múltiplos escopos. Uma associação que reúne várias comunidades pode rodar o seu próprio Pluriverso, federando apenas os seus membros, para o seu próprio uso — sem depender do índice público global e sem pedir licença a ninguém. Cada instância tem seu próprio arquivo SQLite, seu próprio comitê de governança, seus próprios critérios de admissão. Não há hierarquia entre instâncias. Um mesmo membro pode ser coletado por várias delas ao mesmo tempo, porque a coleta lê apenas aquilo que já foi publicado.
O Pluriverso, seja qual for a instância, tem três funções e nenhum poder além delas:
-
Coletar periodicamente os registros marcados como públicos por cada membro — nunca em tempo real, nunca sem publicação explícita.
-
Traduzir sem uniformizar. Se a iniciativa científica registra Manihot esculenta, a comunidade registra Maniaka na sua língua e o quilombo registra macaxeira, o Pluriverso mapeia as equivalências em SKOS-XL e devolve os três — preservando na tela o nome exato que cada um escolheu usar. Tradutor, não ditador taxonômico.
-
Oferecer uma API pública unificada, com a origem de cada registro sempre explícita.
E há uma quarta característica que considero a mais importante de todas: a saída é reversível. Se um membro decide sair da federação, seus dados são removidos imediatamente do índice, e os mapeamentos semânticos são desfeitos. Os dados primários, afinal, nunca saíram do arquivo soberano da própria comunidade. Sair é limpo, auditável e imediato — não um pesadelo técnico de registros espalhados por logs e backups.
Por que isso está no GitHub
Aqui chego ao ponto que mais me interessa neste post.
Eu poderia ter guardado esta proposta até que ela estivesse "pronta" — todos os componentes implementados, todas as arestas aparadas, um relatório bonito para apresentar em um seminário. Escolhi o contrário, e escolhi conscientemente.
Esta é uma proposta aberta, e ela está incompleta de propósito.
Está no GitHub porque lá a discordância tem endereço. Se você acha que a coleta periódica é insuficiente e deveríamos suportar consulta federada em tempo real, . Se você trabalha em um museu e o modelo de acervos não cabe na sua realidade, abra uma issue. Se você é de uma comunidade tradicional e a arquitetura, do jeito que está, ainda pressupõe coisas que a sua realidade não tem — conexão estável, alguém que saiba rodar um contêiner, alfabetização em inglês técnico —, essa é a crítica mais valiosa que eu poderia receber, e ela também cabe em uma issue.
Cada decisão técnica está registrada em um ADR (Architecture Decision Record), com o contexto que a motivou e as alternativas descartadas. Não é só o "o quê": é o "por quê". Isso existe justamente para que outra pessoa possa discordar com precisão, e não no vazio.
A proposta tem , pode ser citada, versionada e bifurcada. Se alguém quiser pegar essa arquitetura, mudar metade dela e implementar do seu jeito, ótimo — é para isso que ela está lá. E que fique claro: a Arquitetura BioCultural não pretende substituir nada. O Brasil já tem iniciativas de peso nessa área — o Projeto GEF "Entre-Ciências", a Rede de Conhecimentos sobre Sociobiodiversidade, a modernização do SISGEN, o trabalho do SiBBr. Não são concorrentes. São parte do mesmo esforço. O que ofereço é um modelo de arquitetura, soberano por desenho, que qualquer uma dessas iniciativas pode adotar, adaptar ou simplesmente usar como contraponto para pensar as suas próprias escolhas.
O que está realmente em jogo: repartição de benefícios
Deixei para o fim aquilo que, para mim, justifica todo o resto.
A Lei 13.123/2015, o Protocolo de Nagoya e o Artigo 8(j) da Convenção sobre Diversidade Biológica dizem, cada um a seu modo, a mesma coisa: quem acessa conhecimento tradicional associado à biodiversidade deve consentimento e deve repartir os benefícios com quem o detém. É lei, não é gentileza.
Só que a repartição de benefícios, hoje, esbarra em um problema profundamente banal: frequentemente não se sabe, com precisão, de quem veio o quê. A evidência foi extraída de um artigo, que citou outro artigo, que registrou o relato de uma comunidade que não foi nomeada. O caminho de volta se perde. E, quando o caminho de volta se perde, a repartição vira estimativa, negociação genérica ou — o cenário mais comum — simplesmente não acontece.
É aqui que a arquitetura deixa de ser um assunto de engenharia e vira um assunto de justiça. Uma federação como esta produz, quase como efeito colateral do seu funcionamento normal:
-
Proveniência rastreável até a origem. Cada evidência carrega o caminho de volta à sua fonte, seja ela um artigo, um relato, um item de acervo ou uma obra do século XVIII.
-
Atribuição explícita e permanente. Todo registro no índice federado sabe de qual membro veio. O crédito não se dilui na agregação.
-
Consentimento registrado, não presumido. No caso das fontes primárias, o CLPI é parte do dado, não um documento perdido numa gaveta.
-
A linguagem da própria comunidade preservada. O termo tradicional não é traduzido e descartado; ele permanece, atribuído a quem o usa.
-
Auditabilidade. Trilhas de mudança que permitem verificar, depois, quem contribuiu com o quê.
Junte essas cinco coisas e a repartição de benefícios deixa de depender de boa vontade e passa a ter base documental. Se uma iniciativa nacional de organização e sistematização de conhecimento tradicional associado à biodiversidade adotar uma arquitetura com essas características, estaremos avançando concretamente rumo a uma repartição de benefícios justa, precisa e robusta:
-
justa, porque o benefício segue o caminho da evidência até quem realmente a detém;
-
precisa, porque a atribuição é registro, e não estimativa;
-
robusta, porque não depende da memória, da boa fé ou da permanência de nenhum intermediário — está na estrutura do sistema.
Essa é a aposta. Não é uma aposta em software: é uma aposta em que a forma como organizamos os dados determina quem recebe o que. Uma arquitetura centralizada tende a produzir repartição difusa. Uma arquitetura federada, com proveniência e atribuição no seu núcleo, produz repartição rastreável. A escolha técnica é, aqui, uma escolha política — e é melhor fazê-la com os olhos abertos.
Venha discordar comigo
A descentralização dá trabalho. Desenhar endpoints de coleta paginados, gerenciar mapeamentos semânticos distribuídos e lidar com a latência de coletas periódicas exige muito mais massa cinzenta do que subir um banco centralizado no Docker.
Mas quando vemos uma comunidade tendo em mãos as chaves do seu próprio arquivo de dados, decidindo com autonomia o que expor e o que proteger, fica claro que esse é o único caminho tecnicamente honesto. É a tecnologia deixando de ser instrumento de colonização de dados para virar espaço de diálogo, onde muitos mundos e muitos saberes possam, enfim, coexistir.
A proposta está lá, aberta, com todas as suas lacunas à vista:
Leia, critique, bifurque, implemente. Abra uma issue dizendo que estou errado. Nada me deixaria mais satisfeito.
Agradecimentos
A formulação desta proposta técnica e a consolidação de sua visão ética e conceitual não seriam possíveis sem os diálogos, provocações e insights preciosos de parceiros fundamentais. Registro meu profundo agradecimento à Viviane Fonseca, do Jardim Botânico do Rio de Janeiro (JBRJ); ao Lucas Zelesco, da Fundação Nacional dos Povos Indígenas (FUNAI); e aos membros do Comitê Gestor Useflora, cuja dedicação à salvaguarda da sociobiodiversidade e ao respeito às comunidades tradicionais inspirou cada linha de código e de arquitetura deste projeto.
Referências
Repositórios oficiais das ferramentas que compõem o ecossistema federado:
-
— a proposta completa, com diagramas C4, ADRs e histórico de versões
-
— banco de dados de conhecimento tradicional de fontes secundárias
-
— extração automatizada de metadados de artigos em PDF com IA
-
— registro de fontes primárias junto às comunidades, com CLPI
-
— evidências em acervos históricos e museológicos
-
— evidências em obras de naturalistas dos séculos XVII a XIX
-
— infraestrutura terminológica SKOS-XL
-
— middleware de federação, índice e mapeamento semântico
Como citar a arquitetura: DALCIN, E. (2026). Arquitetura para um Sistema de Informações sobre Conhecimento Tradicional Associado à Biodiversidade — Versão 3.3 [Software documentation]. Zenodo.