Cómo validamos cada decisión

La mayoría de protocolos DeFi optimizan parámetros con un backtest, miden sharpe, ganan, deployan. Eso funciona para alpha quant — falla para producto en infraestructura financiera, donde un parámetro mal validado se cobra millones cuando aparece el régimen que no estaba en el backtest.

Quipu usa un método formal de research que documenta cada hipótesis antes de testearla y refuta más rápido de lo que confirma.

El esqueleto: hipótesis pre-registradas

Cada decisión de producto entra al sistema como una hipótesis con la forma:

Si X entonces Y porque Z

Donde:

• X es la condición operativa exacta — un parámetro o combinación de parámetros sobre un dataset declarado.
• Y es la observación falseable — métricas concretas con thresholds explícitos (drawdown ≤ N, ROI ≥ M, ventanas positivas ≥ K).
• Z es el mecanismo causal — no descriptivo. “Porque el hedge protege” es flojo. “Porque el hedge a ratio bajo reduce notional, P&L y drawdown linealmente con costo proporcional de cobertura” es operacional.

La hipótesis se pre-registra en el repo (con status: designed) antes de correr el backtest. Esto elimina selection bias — no podés ajustar la hipótesis después de ver la data.

Acceptance criteria & refutation criteria

Cada hipótesis declara explícitamente:

• Acceptance criteria (todos AND): qué tiene que pasar para que la hipótesis avance a analyzed.
• Refutation criteria (cualquier OR): qué hace que la hipótesis se considere refutada.

Ejemplo abstracto del shape (basado en la hipótesis del yield reserve):

Tipo	Criterio
A1	yield neto > 0 sobre el período observado
A2	CERO eventos donde el recovery del withdraw no completó dentro de la ventana operativa
A3	yield organic (no incentive-driven en porciones materiales)
R1	yield neto ≤ 0 (el costo se come la ganancia)
R2	Cualquier evento histórico donde el recovery no llegó a tiempo
R3	APY mayoritariamente subsidiado
R4	Las primitivas de seguridad disponibles no permiten implementar las policies necesarias

Si cualquiera de los R* se cumple, la hipótesis falla. Si todos los A* se cumplen Y ningún R* se cumple, la hipótesis pasa a analyzed. Para replicated (= axioma candidate) hace falta un dataset independiente o operación real post-launch.

Stress tests 4D

Una hipótesis que pasa el backtest principal todavía tiene que sobrevivir a 4 dimensiones de stress:

1. Parameter sensitivity: ¿el resultado es robusto a barridos del parámetro? Cada parámetro relevante se testea sobre una grilla amplia, no en un único punto.
2. Regime decomposition: ¿el resultado depende de un solo régimen? Si todo el alpha viene de un único bear stretch, la hipótesis es frágil.
3. Dataset variation: ¿se replica en datasets independientes? Mínimo 2 datasets distintos antes de aceptar.
4. Null baseline: ¿le ganás a un baseline trivial (no hedgear, parámetro fijo, constante random)?

Si la hipótesis falla algún stress test, no se descarta inmediatamente — pero el result_summary tiene que documentar el failure mode, y el status no avanza a replicated.

Promoción / refutación asimétrica

Promover (= ganar confianza) cuesta más que refutar (= perder confianza). Reglas:

• Una hipótesis pasa a analyzed con backtest principal + 1 dataset variation + parameter sensitivity.
• Pasa a replicated sólo con dataset independiente real (no derivado del primero) o observación post-launch.
• Pasa a axiom (= invariante usable como base de otras hipótesis) sólo si ha sido replicated Y se identifica el mecanismo causal Z.
• Una hipótesis se refuta con un solo R* cumpliéndose. No hay “casi refutado”.

Esto introduce una asimetría a favor de la duda — preferimos descartar 10 hipótesis verdaderas a aceptar 1 falsa.

Los axiomas que ganamos

Hasta hoy, el sistema tiene A1–A21 (axiomas validados de comportamiento del LP) y F1–F4 (axiomas validados del hedge). Cada uno está documentado en research/AXIOMS.md con:

• Statement formal
• Hipótesis que lo originaron (al menos una promoted to replicated)
• Datasets donde se validó
• Counter-examples conocidos

Ningún parámetro del producto en producción sale de un único experimento — todos están respaldados por al menos 2 hipótesis convergentes.

Por qué esto importa para vos

Ningún parámetro vivo en producción salió de “intuitivamente parece bien”. Cada uno es el output de un sweep de combinaciones, validado sobre múltiples datasets, con stress tests documentados, y el result_summary que vos podés auditar — incluso si los valores específicos del runtime no se publican, la metodología de cómo se eligieron sí está abierta y replicable.

Reproducibilidad

Todo el research vive en el monorepo:

• Hipótesis: research/system/entities/hypotheses/H-NN.yaml
• Evidence reports: research/docs/evidence/reports/E-NN_*.md
• Datasets reconstruidos: módulo research/backtest/datasets/econometric_reconstruction.py (21 unit tests)
• Axiomas: research/AXIOMS.md

Cada número que aparece en este docs site es traceable hasta un result_summary específico de un experimento específico. Si encontrás una claim sin trazabilidad, abrí un issue — es un bug del docs.