Metodologia
Governança Automatizada
Como as análises do AFOS são geradas, regras em código, não em humanos
Duas formas de interagir com a plataforma hospedada
AFOS Analytics tem dois caminhos distintos de interação com a instância em afos-analytics.com. Essa separação é o que permite o projeto ser open-source verdadeiro no código enquanto mantém qualidade auditável na plataforma hospedada.
| Caminho | O que é | Envolvimento AFOS | Regras |
|---|---|---|---|
| 🍴 Fork | Você copia o código e roda sua versão | Zero | Só Apache 2.0 (atribuição, NOTICE file, sem uso da marca AFOS) |
| 🔌 Country Onboarding | Você contribui configuração que onboarda um novo país na plataforma hospedada | Revisão técnica do PR, uma vez | Regras de integridade em código, aplicadas automaticamente |
Melhorias no código em si (bugs, features, novos validadores) seguem o fluxo padrão de open-source via CONTRIBUTING.md , nada de especial, é só um PR.
Fork (Apache 2.0 puro)
O código do AFOS é licenciado Apache 2.0. Qualquer pessoa pode forkar, modificar, operar uma instância própria, trocar o prompt, remover regras, mudar fontes, usar comercialmente. Isso não é bug, é o contrato do open-source sério.
Responsabilidade do forker: tudo. Se você forkar e publicar análises enviesadas, isso é sua operação, não do AFOS. Se sua instância cair, é sua. Se você monetizar, é seu direito. As únicas obrigações são as da licença Apache 2.0 (atribuição no NOTICE, citar copyright original) e da nossa política de trademark , o código é livre, mas o nome "AFOS Analytics" e o logo são marcas registradas. Forks operam sob nome próprio.
Esse modelo tem precedente: Linux kernel, PostgreSQL, React, Kubernetes, todos permitem forks e nenhum se responsabiliza pelo que acontece em instâncias terceiras. AFOS segue a mesma lógica.
Por que forks fortalecem o AFOS em vez de enfraquecer
Forks não são ameaça, são validação. Se alguém encontra valor suficiente no AFOS para replicar, isso prova que o método funciona. PostgreSQL se beneficia da existência de Supabase, Neon, Aiven; Linux se beneficia de Red Hat, Ubuntu, SUSE; React se beneficia de Next.js, Remix. Cada fork comercial bem-sucedido amplia o mercado do upstream, não substitui.
O moat real do AFOS não está no código (que é livre por design). Está em:
- Histórico de dados persistido no Neon desde o lançamento, forkers começam do zero
- Autoridade SEO construída com citações, backlinks e menções em imprensa, leva anos pra replicar
- Velocidade de execução de solo-founder vs comitê corporativo, decisões em minutos, não semanas
- Comunidade de primeiros contribuidores, reviewers e Country Onboardings concluídos
- Marca protegida por trademark, força quem copiar o código a construir reputação do zero
Nada disso é forkável. É exatamente por isso que o AFOS pode ser 100% open-source sem medo.
Country Onboarding (contribuição de configuração)
Se você quer ajudar a expandir a plataforma hospedada do AFOS para novos países, contribui com Country Onboarding. É uma configuração, não trabalho editorial diário.
O que você envia em um PR:
- Mapeamento de eventos do Polymarket relevantes para o país
- Source map de pesquisas (quais institutos importam e por quê)
- Source map de notícias (veículos de referência)
- Contexto político local (atores, temas recorrentes, glossário)
- Scaffolding técnico (rotas, traduções)
O que você NÃO envia: análises escritas. A plataforma gera as análises diárias automaticamente usando sua configuração + pipeline + regras de integridade. Contribua uma vez, impacto permanente.
Guia técnico passo-a-passo: docs/platform/add-your-country.md , ~2 horas de trabalho, 1 PR.
Plataforma hospedada (governança em código)
A instância em afos-analytics.com é operada pelo AFOS. Análises publicadas sob a marca AFOS carregam nossa responsabilidade. A governança aqui é aplicada em código, não por editores humanos revisando cada análise.
Três razões técnicas para isso:
- Consistência. Regras em código aplicam-se identicamente a 100 análises ou 100.000. Revisor humano varia por dia, humor, contexto.
- Escala. 1 editor humano ≈ 10 análises/dia no limite. 1 pipeline ≈ infinitas. Queremos o segundo.
- Auditabilidade. Regras em código vivem em git history, versionáveis, diff-áveis. Decisões editoriais humanas vivem na cabeça do revisor.
Os validadores automáticos
Antes de publicar qualquer análise, o pipeline roda validadores. Se algum falhar, a análise não publica até a causa ser corrigida:
| Validador | O que checa | Ação em falha |
|---|---|---|
| Regra de 2 fontes | Toda alegação factual cita ≥ 2 fontes independentes | Bloqueia publicação, regera |
| Detector de adjetivos partidários | Scan de blocklist ("autoritário", "corrupto", "salvador"...) | Bloqueia, regera sem o termo |
| Verificador de simetria | FORTES e FRACOS têm profundidade comparável (ratio de caracteres, número de bullets) | Bloqueia se ratio fora da faixa |
| Triangulação cruzada | Análise referencia ≥ 2 dos 3 vetores (mercado, pesquisas, notícias) | Bloqueia, exige citação explícita |
| Frescor de dados | Dados ingeridos ≤ 48h | Aborta pipeline se dados obsoletos |
Regras no prompt (calibração do LLM)
O prompt do LLM que gera análises inclui explicitamente: "não use adjetivos partidários", "atribua motivações apenas quando documentadas", "sinalize quando fontes divergirem em vez de fabricar certeza". Essa calibração é versionada em git, veja lib/ai/prompts.ts , qualquer mudança passa por PR revisado.
As 3 exceções honestas onde humano intervém
Transparência exige nomear os ~5% dos casos onde humano é inescapável:
- Source drift. Um instituto para de publicar, um site muda URL, um evento Polymarket resolve. Pipeline sinaliza via monitoria; mantenedor atualiza a configuração do país.
- Bypass de validador. Caso raro em que a análise gerada passa em todos os validadores mas contém erro factual ou viés sutil. Leitor reporta via GitHub issue; mantenedor investiga e corrige (ajustando prompt ou configuração, não editando a análise individual).
- Emergência legal ou ética. Risco de difamação, violação de lei eleitoral, tentativa coordenada de manipulação. Canal: contact@afos-analytics.com. Take-down é possível e documentado em log público de incidentes.
Essas exceções são o caso raro. O caso normal é pipeline rodando autônomo 24/7.
Por que "zero-touch" é diferencial, não limitação
Jornais tradicionais vendem "julgamento editorial humano" como qualidade. AFOS inverte: regras em código são mais honestas porque:
- Auditáveis. Qualquer leitor pode abrir o repositório e ver exatamente qual regra foi aplicada. Impossível em redação tradicional.
- Reproduzíveis. A mesma entrada gera a mesma saída. Garantia que nenhum caso recebe tratamento diferente por quem estava de plantão.
- Escaláveis. 15 países hoje, 40 amanhã, sem contratar editor. Newsroom model morreria em 20 países.
- Ataques diretos. Se achar que uma regra está errada, abra issue. Se achar que o prompt está enviesado, abra issue. A crítica é técnica, não opinativa.
Como contribuir
- 📘 Entender o modelo: CONTRIBUTING.md, 3 roles, responsabilidades, regras
- 🌎 Onboardar um país: Guia "Add your country", 5 passos, ~2h, 1 PR
- 🔧 Propor antes de codar: Template Country Onboarding
- 💬 Dúvida ou reporte de bypass: contact@afos-analytics.com
O nome do jogo é APIs conectadas + regras em código + mínima intervenção humana. É assim que o AFOS escala do Laboratório Brasil para dezenas de países sem virar newsroom.