Metodología
Gobernanza Automatizada
Cómo se generan los análisis de AFOS — reglas en código, no en humanos
Dos formas de interactuar con la plataforma alojada
AFOS Analytics tiene dos caminos distintos para interactuar con la instancia en afos-analytics.com. Esta separación es lo que permite que el proyecto sea open-source genuino en el código mientras mantiene calidad auditable en la plataforma alojada.
| Camino | Qué es | Involucramiento AFOS | Reglas |
|---|---|---|---|
| 🍴 Fork | Copias el código y operas tu propia versión | Cero | Solo Apache 2.0 (atribución, archivo NOTICE, sin uso de la marca AFOS) |
| 🔌 Country Onboarding | Contribuyes configuración que onboarda un nuevo país en la plataforma alojada | Revisión técnica del PR, una vez | Reglas de integridad en código — aplicadas automáticamente |
Mejoras al código en sí (bugs, features, nuevos validadores) siguen el flujo estándar de open-source vía CONTRIBUTING.md — nada especial, es solo un PR.
Fork (Apache 2.0 puro)
El código de AFOS está licenciado bajo Apache 2.0. Cualquier persona puede forkar, modificar, operar una instancia propia, cambiar el prompt, remover reglas, cambiar fuentes, usar comercialmente. Esto no es bug — es el contrato del open-source serio.
Responsabilidad del forker: todo. Si forkeas y publicas análisis sesgados, es tu operación, no AFOS. Si tu instancia cae, es tuya. Si monetizas, es tu derecho. Las únicas obligaciones son las de la licencia Apache 2.0 (mantener atribución en NOTICE, citar copyright original) y nuestra política de trademark — el código es libre, pero el nombre "AFOS Analytics" y el logo son marcas registradas. Los forks operan bajo nombre propio.
Este modelo tiene precedente: Linux kernel, PostgreSQL, React, Kubernetes — todos permiten forks y ninguno se responsabiliza por lo que sucede en instancias de terceros. AFOS sigue la misma lógica.
Por qué los forks fortalecen AFOS en vez de debilitarlo
Los forks no son una amenaza — son validación. Si alguien encuentra suficiente valor en AFOS para replicarlo, eso prueba que el método funciona. PostgreSQL se beneficia de la existencia de Supabase, Neon, Aiven; Linux se beneficia de Red Hat, Ubuntu, SUSE; React se beneficia de Next.js, Remix. Cada fork comercial exitoso amplía el mercado del upstream en vez de reemplazarlo.
El moat real de AFOS no está en el código (que es libre por diseño). Está en:
- Histórico de datos persistido en Neon desde el lanzamiento — los forkers empiezan desde cero
- Autoridad SEO construida mediante citas, backlinks y menciones en prensa — lleva años replicar
- Velocidad de ejecución de un solo founder vs un comité corporativo — decisiones en minutos, no semanas
- Comunidad de primeros contribuyentes, reviewers y Country Onboardings completados
- Marca protegida por trademark — obliga a quien copie el código a construir reputación desde cero
Nada de eso es forkeable. Es precisamente por eso que AFOS puede ser 100% open-source sin miedo.
Country Onboarding (contribución de configuración)
Si quieres ayudar a expandir la plataforma alojada de AFOS a nuevos países, contribuyes con Country Onboarding. Es una configuración, no trabajo editorial diario.
Qué envías en un PR:
- Mapeo de eventos de Polymarket relevantes para el país
- Source map de encuestas (qué encuestadoras importan y por qué)
- Source map de noticias (medios de referencia)
- Contexto político local (actores, temas recurrentes, glosario)
- Scaffolding técnico (rutas, traducciones)
Qué NO envías: análisis escritos. La plataforma genera los análisis diarios automáticamente usando tu configuración + pipeline + reglas de integridad. Contribuye una vez, impacto permanente.
Guía técnica paso a paso: docs/platform/add-your-country.md — ~2 horas de trabajo, 1 PR.
Plataforma alojada (gobernanza en código)
La instancia en afos-analytics.com es operada por AFOS. Los análisis publicados bajo la marca AFOS cargan nuestra responsabilidad. La gobernanza aquí es aplicada en código, no por editores humanos revisando cada análisis.
Tres razones técnicas para esto:
- Consistencia. Reglas en código se aplican idénticamente a 100 análisis o 100.000. Revisores humanos varían por día, humor, contexto.
- Escala. Un editor humano ≈ 10 análisis/día en el límite. Un pipeline ≈ infinitos. Queremos el segundo.
- Auditabilidad. Reglas en código viven en git history, versionables, diffables. Decisiones editoriales humanas viven en la cabeza del revisor.
Los validadores automáticos
Antes de publicar cualquier análisis, el pipeline ejecuta validadores. Si alguno falla, el análisis no publica hasta que la causa sea corregida:
| Validador | Qué revisa | Acción en fallo |
|---|---|---|
| Regla de 2 fuentes | Toda afirmación fáctica cita ≥ 2 fuentes independientes | Bloquea publicación, regenera |
| Detector de adjetivos partidistas | Scan de blocklist ("autoritario", "corrupto", "salvador"...) | Bloquea, regenera sin el término |
| Verificador de simetría | FORTALEZAS y DEBILIDADES tienen profundidad comparable (ratio de caracteres, número de bullets) | Bloquea si ratio fuera del rango |
| Triangulación cruzada | El análisis referencia ≥ 2 de los 3 vectores (mercado, encuestas, noticias) | Bloquea, exige cita explícita |
| Frescura de datos | Datos ingeridos ≤ 48h | Aborta pipeline si datos están obsoletos |
Reglas en el prompt (calibración del LLM)
El prompt del LLM que genera análisis incluye explícitamente: "no uses adjetivos partidistas", "atribuye motivaciones solo cuando estén documentadas", "señala cuando las fuentes diverjan en vez de fabricar certeza". Esta calibración está versionada en git — consulta lib/ai/prompts.ts — cualquier cambio pasa por PR revisado.
Las 3 excepciones honestas donde el humano interviene
La transparencia exige nombrar el ~5% de casos donde el humano es inescapable:
- Source drift. Una encuestadora deja de publicar, un sitio cambia de URL, un evento Polymarket se resuelve. El pipeline lo señala vía monitoreo; un mantenedor actualiza la configuración del país.
- Bypass del validador. Casos raros donde el análisis generado pasa todos los validadores pero contiene error fáctico o sesgo sutil. Lectores reportan vía GitHub issue; los mantenedores investigan y corrigen (ajustando el prompt o configuración, no editando el análisis individual).
- Emergencia legal o ética. Riesgo de difamación, violación de ley electoral, intento coordinado de manipulación. Canal: contact@afos-analytics.com. El take-down es posible y está documentado en un log público de incidentes.
Estas excepciones son el caso raro. El caso normal es el pipeline corriendo autónomo 24/7.
Por qué "zero-touch" es diferencial, no limitación
Los medios tradicionales venden el "juicio editorial humano" como calidad. AFOS invierte: las reglas en código son más honestas porque son:
- Auditables. Cualquier lector puede abrir el repositorio y ver exactamente qué regla se aplicó. Imposible en una redacción tradicional.
- Reproducibles. La misma entrada genera la misma salida. Garantía de que ningún caso recibe trato diferente según quién esté de turno.
- Escalables. 14 países hoy, 40 mañana, sin contratar editores. El newsroom model moriría en 20 países.
- Atacables directamente. Si crees que una regla está mal, abre issue. Si crees que el prompt está sesgado, abre issue. La crítica es técnica, no opinativa.
Cómo contribuir
- 📘 Entender el modelo: CONTRIBUTING.md — 3 roles, responsabilidades, reglas
- 🌎 Onboardar un país: Guía "Add your country" — 5 pasos, ~2h, 1 PR
- 🔧 Proponer antes de codear: Template Country Onboarding
- 💬 Duda o reporte de bypass: contact@afos-analytics.com
El nombre del juego es APIs conectadas + reglas en código + mínima intervención humana. Así es como AFOS escala desde el Laboratorio Brasil hasta decenas de países sin convertirse en una redacción.