Pilar 3 — Governança e Democracia (Motor de Governança / Governance Engine)

A tese. Colocar os resultados dos modelos a serviço da governança democrática e dos reguladores da região: observatórios citados de resiliência democrática e regulação, monitoramento de eleições e transparência, inteligência situacional verificável, cada número com sua fonte, cada alerta auditável. A região regula a partir de suas próprias tradições legais, não com modelos prontos dos EUA ou da UE.

O Motor de Governança. Visto como infraestrutura, este pilar é o motor de decisão da plataforma: toma indicadores verificáveis (o Índice de Resiliência Democrática, a camada de liberdades do observatório, o Índice de Cobertura Regulatória) e os converte em insumos para decidir: alertas auditáveis, feeds legíveis por máquina, um painel de calibração de previsões e um registro público de correções. A cadeia é indicadores → decisões, com cada elo rastreável. Uma ressalva de honestidade: hoje "resultados verificáveis" significa procedência verificável, cada número remonta à sua fonte; o histórico demonstrado de previsões resolvidas e correções publicadas ainda está por se acumular, e as duas superfícies que o tornarão visível (o painel de calibração e o registro de correções) já estão ao vivo, começando do zero.

É o terceiro pilar do ciclo: consome os resultados do modelo soberano (2 → 3), e as instituições que passam a depender desses resultados se tornam contribuintes do fundo fiduciário (3 → 1).

A partir das tradições legais da região, não de modelos importados

O princípio norteador do pilar é uma recusa explícita: não se pega um marco de governança de IA dos EUA ou da UE para renomeá-lo. Parte-se das tradições legais latino-americanas, das realidades da economia informal e dos marcos constitucionais da região. Um observatório de regulação que mede a região contra um modelo europeu mede a coisa errada; o desenho começa do direito da região para fora.

As superfícies ao vivo

Observatório de Resiliência Democrática

/gobernanza/observatorio: o Índice de Resiliência Democrática, um composto citado de três subíndices (estado de direito, transparência e anticorrupção, integridade democrática) construídos sobre WGI, V-Dem, WJP, IDEA GSoD, BTI, TI-CPI e OWID, com normalização por metas (goalposts) (p5–p95), pesos iguais e preenchimento de lacunas documentado. Além do ranking, o observatório oferece cinco vistas: ranking, retrocessos (backsliding), deriva autoritária, liberdade (ranking de liberdade econômica sobre o índice da Heritage Foundation; o detalhe por país adiciona camadas de liberdade humana, de imprensa e digital, cada uma com sua própria fonte) e um explorador. Cada componente do índice remonta à sua fonte; a construção do composto, os pesos e as premissas estão documentados na sua página de metodologia. Não é um ranking opaco: é um índice cuja receita está à vista e cujos números podem ser auditados um a um.

Como o índice é construído

O composto é gerado com scripts/build-democracy-index.ts (bun run) e servido estático a partir de public/data/democracy/resilience.json; a página o lê, não o recalcula.

Os goalposts são calculados sobre o pool regional completo, o outlier de um país não define a escala de ninguém. Composição dos subíndices (19 indicadores esperados por país):

Subíndice	Indicadores	Fontes
estado_derecho	10 — wjp_rol_overall, fatores 1 e 8 do WJP, vdem_rule_of_law, vdem_liberal_democracy, rl_est, ge_est, rq_est, idea_gsod_rule_law, bti_governance_index	WJP, V-Dem, WGI, IDEA GSoD, BTI
anticorrupcion	3 — ticpi_score, cc_est, owid_corruption_vdem	TI-CPI, WGI, OWID/V-Dem
integridad_democratica	6 — vdem_electoral_democracy, idea_gsod_representation, idea_gsod_rights, va_est, owid_political_regime, bti_democracy_status	V-Dem, IDEA GSoD, WGI, OWID, BTI

Invariantes do script (todas verificáveis no código):

Regra	Valor exato
Janela temporal	2010–2025 (YEAR_MIN/YEAR_MAX)
Preenchimento por ano	valueAt leva a observação anterior mais próxima do ano; se não houver nenhuma, back-fill a partir da mais antiga
Trajetória	Δ5a ≥ +2 → mejora; ≤ −2 → retroceso; caso contrário, estable
Confiança	observados/esperados ≥ 0,85 → alta; ≥ 0,6 → media; abaixo disso → baja
Caches em quarentena	são lidos como vazios — nunca alimentam o índice
Restrição vinculante	o subíndice de menor pontuação (a prioridade de reforma)
Auditabilidade	cada entrada de contributing[] leva citation_id → registro de fonte em citations.json

A cobertura 25/25 é garantida por desenho: Cuba (sem WJP) ou Suriname (V-Dem/BTI escassos) aparecem com confiança media/baja em vez de sumir do ranking. O painel de retrocessos ordena os países pela queda do composto em 5 anos e, para cada um, identifica o indicador individual com a queda normalizada mais acentuada em ~5 anos (o worst_indicator, com sua citação). Corte de julho de 2026 do arquivo gerado: 25/25 pontuados, mediana regional 51,9, melhor Uruguai, pior Venezuela, 12 países em retrocesso e 4 em melhora.

Observatório de regulação

/gobernanza/regulacion: o rastreador de regulação dos 10 eixos nos 25 países: mais de 2.200 instrumentos legais (2.257 na geração de 30 de julho de 2026; leis, decretos, marcos; a contagem cresce a cada ingestão), extraídos hoje de seis catálogos conectados: Constitute e Climate Change Laws of the World como fontes externas, mais o catálogo legal curado do Futuros (verificado na web) e três rastreadores internos do projeto. O registro de fontes lista 18 catálogos no total; NATLEX, ECOLEX, FAOLEX, WIPO Lex e SHERLOC já estão cableados em src/lib/source-registry.ts (cite-only, com deep link ao catálogo) e com ingestão pendente no catálogo horneado; Digital Policy Alert e OECD.AI seguem registrados e pendentes. Uma vista de exploração de instrumentos em /gobernanza/regulacion/instrumentos busca e filtra o índice plano public/data/regulation/_instruments.json (país, eixo, tipo, estado, texto livre). O Índice de Cobertura Regulatória (ICR) tem fórmula pública (0,45·amplitude + 0,30·vigência + 0,25·atualidade) e é calculado apenas sobre instrumentos verificados: os registros sintéticos provenientes de trackers internos do projeto vão marcados (synthetic: true) e ficam excluídos do índice. Uma camada temporal mostra como a cobertura evolui no tempo. Os instrumentos verificados são citados até a fonte, de modo que um regulador pode ver o que existe e de onde vem a afirmação de que existe.

A fórmula do ICR, componente por componente

O ICR é calculado em scripts/bake-regulation.ts e publicado em public/data/regulation/_analytics.json: a fórmula que a página mostra é a mesma que o código executa:

Componente	Peso	Definição operacional
Amplitude	0,45	pilares com ≥ 1 instrumento registrado / 10 × 100
Vigência	0,30	pilares com framework_status in-effect ou partial / 10 × 100
Atualidade	0,25	pilares com instrumento promulgado nos últimos 6 anos / 10 × 100

Duas invariantes de honestidade protegem o índice: (1) um instrumento sem URL oficial deve ir marcado synthetic: true: a geração descarta qualquer registro que viole essa regra, e (2) o rollup por célula país×pilar que alimenta o ICR filtra synthetic !== true antes de contar, então nenhum registro de demonstração move a pontuação. Cada linha por país publica seus insumos completos (amplitud, vigencia, actualidad, covered_pillars, inforce_pillars, recent_pillars, total_instruments, gaps, rank), a pontuação pode ser recomputada à mão. O ranking ordena por ICR com desempate por pilares cobertos; no corte atual o Brasil lidera com ICR 100 (10/10 nos três componentes, 289 instrumentos). A pontuação não premia volume bruto: 289 instrumentos e 30 dão o mesmo ICR se cobrem os mesmos pilares com a mesma vigência.

Governança de IA

/gobernanza/ia: quem regula a IA em cada país da América Latina, hoje? O mapa por país para os 25: lei de dados, estratégia nacional de IA, marco específico de IA, sandbox regulatório e autoridade designada. É talvez a superfície mais alinhada com a tese do pilar: regular a IA a partir dos marcos próprios da região, não de modelos importados.

Processos constitucionais

/gobernanza/constitucional: o rastreador de processos constitucionais da região: as duas tentativas constituintes do Chile, a reforma judicial do México, o debate constituinte na Colômbia. As constituições são reescritas enquanto ninguém olha; esta superfície olha.

Oracle: leitura antecipada de projetos de lei

/gobernanza/oracle: o rastreador de projetos de lei por país: cada projeto é resumido, cruzado com os 10 eixos Futuros e marcado com uma bandeira de risco, conflito, oportunidade ou vigilância. É demo: a própria página o marca, e a maioria dos projetos são cenários sintéticos sem patrocinador real. A superfície mostra o formato de leitura antecipada, não um feed legislativo ao vivo.

Eleições

/gobernanza/elecciones: o monitoramento eleitoral da região: calendário, resultados de eleições concluídas com percentuais de votação e sinais, com fontes por evento. Serve a instituições e observadores que precisam de um panorama comparável entre países sem abrir mão da rastreabilidade de cada número. A camada ADM1 acrescenta o comparecimento eleitoral do TSE por UF (Brasil) e a participação da contratação direta SECOP II por departamento (Colômbia), cada célula com deep link ao registro. O calendário também existe como superfície própria em /calendario: mais de 130 eventos regionais e eleitorais nos 25 países mais a categoria regional.

Transparência

/gobernanza/transparencia: o registro de IA que o Futuros propõe que os estados adotem, exibido com dados de demonstração: registros de execuções de modelos, prompts e rodadas de agentes, no formato que um registro público de IA exigiria. A própria página avisa: os dados são ilustrativos e ainda não estão conectados a telemetria real. A superfície existe para publicar o formato antes de pedir sua adoção (pregar com o exemplo) não para reportar indicadores institucionais.

Sala de situação

/sala: a sala de situação: um agregador personalizado que reúne, por camada (instabilidade, movimentos de indicadores, anomalias, contradições, previsões, eleições, atenção), o sinal mais severo do momento, tudo com um contrato de integridade de citações, de modo que cada alerta é auditável. É a inteligência situacional do pilar: não "o sistema diz que há risco", mas "este número, desta fonte, moveu esta quantidade, e aqui está o registro".

Consenso

/consenso: deliberação no estilo Pol.is: cada pessoa com conta responde 12 afirmações (acordo, desacordo, passo) e o sistema agrupa todas as respostas em grupos de opinião (k-means). Desde outubro de 2026 as respostas são identificadas: uma por conta, como linhas de civic_action servidas por /api/civic, e somam-se a uma linha de base anônima congelada anterior a essa data (/api/consensus, armazenamento Redis da Upstash, agora somente leitura: o POST responde 410). A página declara a origem na tela ("inclui respostas anônimas anteriores a outubro de 2026"). Uma condição operacional que vale dizer sem rodeios: a linha de base só aparece se as variáveis de ambiente do Upstash Redis estiverem configuradas em produção; sem elas o agregado usa apenas as respostas com conta. Os dois eixos são tensões de política fixadas editorialmente (soberania ↔ integração global e estado ↔ mercado) não emergem do clustering como no Pol.is real. É o canal pelo qual a sociedade civil entra no pilar de governança, não como dado observado, mas como voz deliberativa.

Mecânica do agregado

A resposta de uma pessoa é um vetor de 12 caracteres a|d|p (acordo/desacordo/passo), um por afirmação, validado por regex no servidor e guardado como uma linha civic_action do tipo consensus sobre o alvo consenso:latam-2035; um índice único parcial no banco de dados impõe uma só resposta vigente por pessoa (responder de novo a atualiza; "Reiniciar" a retira com revoked_at). A linha de base é um único HASH do Redis (consensus:v1; a versão da chave é rotacionada se o conjunto de afirmações mudar) em que ninguém mais escreve: é lida limitada a 20.000 vetores e os vetores identificados a 5.000 por leitura. A resposta de /api/consensus distingue dois modos de falha (configured: false (sem Redis) e degraded: true (Redis presente, chamada falhou)); em ambos o agregado é calculado só com as respostas com conta.

O clustering roda inteiramente no cliente: cada vetor é projetado nos 2 eixos (cada eixo soma 6 afirmações com sinal ±1; os "passo" não contam; a pontuação é a média de voto×sinal) e sobre esses pontos 2D roda um k-means com k=3, sementes determinísticas (pontos ordenados por x e depois por y, sem RNG, o mesmo conjunto de votos produz sempre os mesmos grupos) e no máximo 20 iterações; requer ≥ 3 vetores para ativar. Sobre os grupos as afirmações são classificadas (só as com ≥ 2 votos não-passo): consenso = dispersão da taxa de acordo entre grupos ≤ 0,34 e extremidade geral ≥ 15 pontos; divisivas = as 3 de maior dispersão entre grupos.

Propostas

/gobernanza/propuestas: propostas de política redigidas por IA (modelos Opus 4.7, com prompts públicos): cada uma traz a posição do Futuros, a contraposição na sua versão mais forte (steel-man) e a consulta com conta: uma posição por pessoa (apoio, ressalva, oposição; pode ser retirada), emendas e comentários publicados com o nome visível da conta (ver Participação identificada). É uma consulta, não um voto institucional: a própria página o diz. A superfície existe para mostrar o formato de deliberação assistida por IA e recolher posições identificadas, não para substituir a decisão de uma instituição.

Prioridades

/prioridades: o índice segundo as suas prioridades: o visitante fixa seus próprios pesos sobre os 10 pilares e vê o ranking regional se recalcular ao vivo (a mecânica do Better Life Index da OCDE) com os pesos compartilháveis por URL (?w=). Não há um único ranking verdadeiro: a superfície torna explícito que todo índice composto depende de seus pesos. Todo o cálculo roda no cliente sobre o cache de pontuações em memória, sem arquivos de dados nem API.

Foresight: painel de calibração

/foresight é o painel de previsões com calibração pública: cada previsão carrega probabilidade, horizonte e critério de falseamento, e o painel agrupa as resolvidas em bins de calibração para mostrar se um "70%" da plataforma acontece de verdade perto de 70% das vezes. A página separa com honestidade duas populações. A primeira é um arquivo semente de previsões marcadas illustrative: exemplos de metodologia redigidos retroativamente, com selo próprio em cada cartão, que não contam como histórico real. A segunda são as 13 previsões geradas pelo pipeline de pulso social: mecanismo ao vivo com dados defasados, o único lote data de 6 de maio de 2026 e nenhuma previsão vencida foi adjudicada ainda. O histórico de previsão demonstrado está por ser construído; o formato e a mecânica de calibração já estão publicados.

Registro de correções

O registro público de correções, falsifications.json, é o compromisso da plataforma de documentar cada número que publicou e depois corrigiu: cada entrada exige o citation_id de uma afirmação realmente publicada, o valor anterior, o valor corrigido, a data, a razão e o link para a fonte corrigida. O mecanismo está ao vivo e aparece em /confianza e /linaje. Seu estado atual se declara sem maquiagem: zero entradas desde a purga de 23 de julho de 2026, quando foram removidas duas entradas ilustrativas de demonstração que descreviam correções que nunca aconteceram, contra citation_id que nunca existiram. O registro parte vazio e só acumula correções reais e verificáveis: um registro vazio e honesto vale mais que um cheio de ficções.

API e feeds institucionais

O Motor de Governança não termina em painéis: publica seus dados em formatos que uma instituição pode consumir diretamente, sem scraping e sem pedir permissão.

• API pública v1. Todo o corpus gerado é servido estático sob /api/v1: observações em JSON e CSV, um export SDMX-CSV (ISO 17369, observations.sdmx.csv) para institutos de estatística, e uma pasta de trabalho XLSX (futuros-data.xlsx) com as citações incluídas. Referência completa no guia da API pública.
• Servidor MCP. O endpoint api/mcp.ts (POST https://futuros.xyz/api/mcp) expõe o corpus citado como ferramentas do Model Context Protocol: um agente de IA institucional pode consultar indicadores, citações e geografias a partir do Claude, do Cursor ou de qualquer cliente MCP. Guia no capítulo MCP.
• Embeds. Os gráficos citados podem ser incorporados no site de um ministério ou de um veículo de imprensa via iframe, conservando suas citações. Guia em embeds e marca branca.

Por que "cada alerta auditável" não é negociável

A diferença entre um observatório democrático confiável e outro que não é está em se um ator institucional pode defender o que a plataforma lhe diz. Um regulador que age com base num alerta precisa poder mostrar a cadeia: qual número, de qual fonte, medido quando. Por isso o pilar herda o contrato de rastreabilidade em dois cliques de toda a plataforma: e por isso a sala de situação carrega um contrato explícito de integridade de citações. Um alerta sem fonte é ruído; um alerta auditável é ação defensável.

Pilotos de ponta a ponta: roteiro

ROADMAP, não realidade operacional. O corpus de pilotos do Futuros contém 67 propostas desenhadas com critério de bancabilidade: problema, desenho, custeio, financiamento e KPIs, muitas com ministros nomeados como contraparte potencial. Nenhuma roda hoje operacionalmente com uma instituição: zero pilotos em execução. A distinção importa, porque o Motor de Governança completo (indicador → decisão → intervenção → medição) só ficará demonstrado quando o primeiro piloto rodar de ponta a ponta com um parceiro institucional real. Até lá, os pilotos são desenhos prontos para negociar, e esta seção se declara como roteiro.

Compras públicas do Chile, agregadas

A ChileCompra publica a cada mês o universo de ordens de compra como um ZIP sem chave. A Futuros dobra esse arquivo em totais nacionais (contagem, bilhões de pesos, participação da contratação direta, da Compra Ágil e do convênio marco) e não guarda fornecedor, comprador nem item. É a via aberta que substitui o ticket do Mercado Público para o histórico. O feed está registrado na camada de alta frequência e não aparece na interface até existir um consumidor. A janela de refresh são os três meses completos mais recentes.

Participação identificada

Desde outubro de 2026 a camada de participação do pilar (posições e emendas em /gobernanza/propuestas, comentários, respostas em /consenso e votos em pilotos propostos) é registrada com conta. Cada ato é uma linha de civic_action com o identificador da pessoa, o tipo (vote, amendment, consensus, comment, qvote), o alvo e a data; onde a superfície admite uma só posição por pessoa, o banco de dados impõe isso com uma restrição de unicidade. O que isso muda, concretamente:

Antes (demo, por navegador)	Agora (com conta)
Posições e emendas viviam no localStorage; um mesmo visitante contava várias vezes a partir de vários navegadores e nada se agregava entre pessoas.	Uma posição por pessoa e proposta; as contagens que a página mostra são as de toda a comunidade registrada.
Comentários atrás de uma comporta de e-mail simulada.	Comentários publicados com o nome visível da conta; a pessoa autora pode editá-los ou retirá-los (revoked_at), e o retirado deixa de contar.
Respostas de consenso anônimas, identificadas por um id aleatório do navegador.	Respostas ligadas à conta. O agregado mostrado em /consenso soma as respostas identificadas à linha de base anônima congelada anterior a outubro de 2026, e declara isso na tela: "inclui respostas anônimas anteriores a outubro de 2026". Essa linha de base não é atribuída retroativamente nem cresce.

O que não muda: nenhum número cívico publica o e-mail de ninguém; o nome visível é definido por cada pessoa em /cuenta; quem exclui a conta deixa de contar em todos os agregados após sete dias (ver o aviso de privacidade, §9). O objetivo é o mesmo do resto do pilar: que um regulador possa defender o número, inclusive o de quantas pessoas apoiam uma proposta.

O retorno ao ciclo

As instituições que passam a depender desses observatórios e da sala de situação se tornam contribuintes: aportam seus próprios dados ao fundo fiduciário, fechando o loop 3 → 1. O observatório não é um ponto final, é um ímã de dados que alimenta a próxima volta do volante.

Superfícies relacionadas

• Hub de governança: /governance: porta de entrada para todo o pilar.
• /gobernanza/observatorio, /gobernanza/regulacion, /gobernanza/ia, /gobernanza/constitucional, /gobernanza/oracle, /gobernanza/elecciones, /gobernanza/transparencia, /gobernanza/propuestas.
• /sala, /calendario, /consenso, /prioridades.
• Verificabilidade e feeds: /foresight, /confianza, /linaje, API pública, MCP, embeds.

Siga o ciclo até o Pilar 4 — Inteligência de Fronteira, a outra saída do modelo soberano.