Saltar a contenido

Commitment devices para proteger kill switches del override emocional

El mayor riesgo del experimento no es técnico, es emocional: después de un drawdown -15%, el user puede ceder y desactivar el kill switch. analysis/retail-learning-bias|96.4% vs 95.3% siguen tradeando post-loss. Solución: commitment devices estilo Ulysses contract — hacer que romper el kill switch sea costoso o imposible en el momento hot.

El problema

Hot-cold empathy gap (Loewenstein): la persona en estado calmo ("cold") subestima cuánto sus emociones ("hot") la van a llevar a decisiones opuestas. El user hoy diseña kill switches razonables; después de 3 meses de dolor de drawdown, los va a querer desactivar.

Time inconsistency: preferences at T0 vs T1 difieren. En T0 ("este es un experimento de diversificación, tolero -25%"), en T1 ("no puedo dejar que me quemen más, doble down" o "salgo todo"), decisiones opuestas.

Evidence empírica en retail trading (Barber 2019): traders rentables y no rentables siguen tradeando al año siguiente (96.4% vs 95.3%). La data de resultados no cambia el comportamiento. Solo restricciones ex-ante funcionan.

Patterns de commitment device aplicables

1. Delay forzado

Regla: cualquier override de un kill switch requiere 7 días de delay antes de ejecutarse.

  • User dice "quiero desactivar el drawdown cap" → sistema requeire nuevo "confirm" 7 días después.
  • El hot state típicamente pasa en 48-72h. El 7-day delay casi garantiza que el user vea el estado cold antes de ejecutar.

Implementación: el Risk Agent tiene override_requests.md con timestamp; solo aplica si el request tiene >7 días + re-confirm en texto completo.

2. Multi-factor approval

Regla: override requires 2+ sign-offs: - El user escribe el override por escrito. - Un "accountability partner" (spouse, contador, amigo) confirma. - El sistema registra ambos logs.

Fricción adicional hace el override menos probable en hot state.

3. Journaling obligatorio

Regla: antes de ejecutar un override, el user debe escribir a mano: - ¿Qué sentí esta semana que quiero este override? - ¿Qué va a ser diferente en 30 días? - ¿Qué le diría a mí-mismo-de-hace-3-meses si pudiera?

El acto de escribir activa el cold state. Muchos users dejan de querer el override después del journal.

4. Pre-commitment público (agresivo)

Regla: el user declara en algún canal público (post, tweet, grupo) su kill switch y las consecuencias.

  • Ej: "Si pierdo 25%, cierro y vuelvo a SPY. Les debo una cena si me salto esto."
  • Social pressure refuerza la disciplina.

Desventaja: caro emocionalmente para muchos. Opcional.

5. Third-party execution

Regla: el kill switch es ejecutado por un tercero (contador, accountability partner) que el user no puede revocar unilateralmente.

  • Ej: el contador cierra posiciones automáticamente si ve el drawdown cross the threshold, sin esperar orden del user.
  • Máxima robustez pero requiere relación de confianza con un tercero.

6. Hardcoded sin override path

Regla más extrema: el sistema no expone un UI para override. Solo un "cold shutdown" que cierra todo, no un "disable kill switch".

  • El user puede apagar el sistema completo.
  • No puede decir "sigue pero sin kill switch".
  • Todo o nada.

Recomendación para este proyecto

Stack de commitment devices en capas, implementado en el Risk Agent:

Capa 1: Delay forzado (obligatorio)

  • Todos los override requests requieren 7 días de cooldown.
  • Durante esos 7 días, el kill switch sigue activo.

Capa 2: Journaling obligatorio (obligatorio)

  • El override request debe incluir respuestas a 3 preguntas específicas (pre-registradas en memory/override-template.md).
  • Si las respuestas son vacías / one-liners → reject.
  • Las respuestas se loggean en memory/override-journal.md (permanent).

Capa 3: Multi-factor (opcional pero recomendado)

  • El user pre-registra 1 accountability partner.
  • El override requires confirmation del partner via un channel independiente.

Capa 4: Hard floors (no override)

  • Algunos kill switches no tienen override path:
  • Drawdown 40% → close all, sin override. Full stop.
  • Peor que SPY a 36 meses → end experiment, sin override.

Estos son los absolute floors — ni el user en cold state pre-registró la opción de overridear.

Implementación en el sistema del user

Agregar a memory/config.md:

## Kill switches (ordenados por severity)

### Nivel 1 — flagged, user can review
- Drawdown mensual > 15% → notify + request confirmation to continue.

### Nivel 2 — override posible con friction
- Drawdown total > 15% → pausar rebalance. Override requires 7-day cooldown + journal.
- Sharpe < 0 después de 6 meses → pausar. Override requires 7-day + journal.

### Nivel 3 — hard override requiring multi-factor
- Drawdown total > 25% → close all positions. Override requires 14-day + journal + partner sign-off.

### Nivel 4 — no override possible
- Drawdown total > 40% → close all, end experiment. NO OVERRIDE.
- Peor que SPY a 36 meses → end. NO OVERRIDE.

Gaps

  • Enforcement técnico: ¿el sistema realmente impone el delay, o depende del user "honrarlo"? Diseño ideal es que el Risk Agent lo impone via memory/override-requests.md con timestamps y el Execution Agent verifica antes de ejecutar cualquier trade.
  • Accountability partner technology: ¿email? ¿phone call? ¿shared doc? Práctica pendiente.
  • Revisión ex-ante: el user debe leer ESTE documento antes de empezar, en estado cold. Después sin esto, los kill switches se diluyen.

Relaciones