Pular para o conteúdo
Júlio Folli

ObservaDH

Observatório Digital de Discurso e Direitos Humanos

Período
2024 — 2026
Atuação
Concepção, arquitetura de dados e desenvolvimento full-stack
Categoria
Pesquisa aplicada · Dados públicos
Stack
Next.jsTypeScriptPostgreSQLSupabaseTailwind CSSAnálise semântica assistida por LLM
ObservaDH — interface em produçãoPré-visualização ao vivo

O processo legislativo brasileiro é público, mas não é legível. O ObservaDH parte dessa distinção: os dados existem em APIs abertas, em ementas de linguagem jurídica e em tramitações fragmentadas entre duas casas — e é exatamente essa fragmentação que torna o acompanhamento inviável para quem é diretamente afetado por essas proposições.

Problema

Uma proposição que restringe direitos raramente se anuncia como tal. Ela aparece como alteração pontual em um artigo de outra lei, tramita apensada a um projeto de tema distinto e muda de relator três vezes antes de qualquer repercussão pública. Organizações da sociedade civil, pesquisadores e cidadãos acompanham esse fluxo manualmente, o que significa acompanhar tarde.

O objetivo do projeto não foi produzir mais um agregador de notícias legislativas, e sim reduzir o custo cognitivo de fiscalizar: identificar o que está em tramitação, classificar o impacto provável sobre Direitos Humanos e a população LGBTI+, e expor a série histórica de forma comparável.

Arquitetura de dados

O sistema opera em quatro estágios desacoplados, o que permite reprocessar classificações sem refazer a coleta.

  1. 01Ingestão — rotinas periódicas consultam as APIs abertas da Câmara dos Deputados e do Senado Federal, normalizando identificadores, autoria, datas e situação de tramitação em um esquema relacional único.
  2. 02Normalização — deduplicação de proposições apensadas, reconciliação de autores e padronização de ementas em texto plano, isolando ruído de formatação típico dos documentos oficiais.
  3. 03Classificação — análise semântica assistida por modelo de linguagem atribui eixos temáticos e sinaliza direção provável do impacto; a saída é tratada como indicação revisável, não como veredito, e fica persistida junto ao texto de origem.
  4. 04Apresentação — camada Next.js consulta os dados já consolidados e renderiza recortes temáticos, séries temporais e fichas individuais de cada proposição com link para a fonte oficial.

Rigor metodológico

Por ser um projeto de iniciação científica, a exigência não é apenas que a interface funcione: é que o dado seja auditável. Toda proposição exibida mantém vínculo direto com o registro oficial, e toda classificação automática é apresentada como camada interpretativa separada do dado bruto.

Essa separação é uma decisão epistemológica antes de ser técnica. Um observatório que confunde inferência com fato perde a função que justifica sua existência.

Impacto

O resultado é uma base consultável que permite perguntas que antes exigiriam semanas de leitura: quais eixos concentram maior volume de proposições restritivas, como isso se distribui ao longo das legislaturas, e quais projetos avançaram em fases decisivas de tramitação.

A ferramenta serve simultaneamente como produto de pesquisa acadêmica e como instrumento prático de defesa de direitos — a mesma base alimenta análise formal e consulta pública.

Decisões de projeto

  • Pipeline em estágios, não em script único

    Coleta, normalização e classificação são processos independentes. Quando o critério de classificação muda, apenas o último estágio é reexecutado sobre dados já persistidos, o que mantém o histórico comparável e evita reconsultas desnecessárias às APIs públicas.

  • Inferência automática sempre rotulada

    A classificação por LLM aparece marcada na interface e nunca substitui a ementa original. O usuário pode discordar da leitura da máquina sem perder o acesso à fonte.

  • Gráficos como recorte, não como decoração

    Cada visualização responde a uma pergunta específica de fiscalização. Onde um número bastava, não há gráfico.