Decisión: Barra de Integridad nace APAGADA en v1.60.0

Contexto

La v1.59.0 (2026-07-17) introdujo el Motor de Integridad F1: la lógica que detecta divergencias plano↔realidad. Hoy entra F2: la página radar (/integrity/) + API + modelos de veredictos.

Pregunta: ¿La activamos ya en CreaRack Pro y en clientes, o esperamos?

Decisión

Nace APAGADO en v1.60.0. El módulo integrity existe en la BD pero NO se asigna a ningún Plan ni a ninguna organización. Solo con org.extra_modules.add(integrity_module) (vía shell post-deploy) aparece la página, el menú y la API.

Razón 1: Calibración del motor

El detector de divergencias (F1) tiene precisión limitada inicialmente:

Heurística de matching Device ↔ DeviceProfile: IP + MAC + hostname (fallible).
Fresh_days = 7: quizá sea 5 o 10 según el ambiente.
Tipos de hallazgo (stale, conflict, undocumented): puede que falten categorías.

Sin feedback humano, el motor es un ruido generator.

Con F2 (veredictos), cada click del usuario es un datapoint de calibración:

plan_updated → “El motor encontró un cambio real, pero el plano estaba desactualizado” (SEÑAL).
real_change → “El motor encontró un cambio real, el plano NO lo reflejaba” (SEÑAL).
false_alarm → “El motor se equivocó; esto es un error del sensor” (RUIDO).

La métrica de calibración es signal_pct = signal / (signal + noise) * 100. Objetivo: > 85% señal antes de Go/NoGo.

Ejemplo:

Primeras semanas: 50 veredictos, 30 son señal, 20 ruido → signal_pct = 60% → NoGo. Tuning necesario.
Semanas 4-6: 200 veredictos, 170 señal, 30 ruido → signal_pct = 85% → Go. Lanzar a Plan 4+.

Razón 2: Impacto usuario (por ahora: cero)

El motor F1 corre “silenciosamente” en el backend. Las métricas de integridad se almacenan (snapshots). Pero sin UI visible, el usuario no sabe que el motor existe ni cómo usarlo.

Si activamos F2 ahora sin tuning:

Usuarios ven página radar con hallazgos, muchos falsos.
Confusión → desconfianza en la métrica.
Abandono de feature (nadie da feedback).

Mejor: Activar primero en beta org (CreaRack interna), calibrar con nuestros propios racks, y luego lanzar a clientes como “garantizado calibrado”.

Razón 3: Garantía de “todo nace apagado”

CreaRack Pro tiene un principio: nuevas features => opt-in primero. Reduce riesgo de regresiones u incompatibilidades.

El patrón es el módulo SaaS + gating:

Módulo se registra (BD) pero sin asignación.
Prefijos gateados en module_registry.
Activación manual post-deploy.

Cumplir ese principio aquí := nada automático, decisión consciente.

Implementación

En v1.60.0 (hoy, 2026-07-17)

# core/migrations/0030_integrity_module.py
SaaSModule.objects.get_or_create(
    slug="integrity",
    defaults={"is_core": False, ...}
)
# NO se asigna a ningún Plan

Resultado: Módulo existe, pero:

/integrity/ → 403 para todos (módulo gateado).
/api/racks/integrity/overview → 403 para todos.
Menú no muestra link ({% ifmodule %} falsa).

Post-deploy (mismo día, manual)

# Shell Django
from core.models import Organization, SaaSModule
org_beta = Organization.objects.get(pk=1)  # Beta org (CreaRack)
integrity_mod = SaaSModule.objects.get(slug="integrity")
org_beta.extra_modules.add(integrity_mod)

Resultado:

Beta org: /integrity/ → 200, página carga.
Otros: /integrity/ → 403.

Activación clientes (post-gate decision, ej. 2026-08-30)

Gate #202 confirma signal_pct > 85%. Marketing/Product decide lanzar.

# Opción A: Añadir a Plan 4+ automáticamente (no hacer esto sin legal review)
# Opción B: Activar manualmente en clientes Pilot (ej. orgs IDs 10, 20, 30)
for org_id in [10, 20, 30]:
    org = Organization.objects.get(pk=org_id)
    org.extra_modules.add(integrity_mod)

O desde admin:

Editor de org → Múltiple select extra_modules → check integrity → save.

Rollback (si falla)

Si durante calibración descubrimos un bug grave en el motor:

org_beta.extra_modules.remove(integrity_mod)
# Siguiente request → 403 de nuevo.
# Datos históricos (IntegrityAck, snapshots) se preservan.

Sin breaking changes, sin migrations de reversión.

Métricas de éxito (gate #202)

A monitorear durante las 4-6 semanas de beta:

Métrica	Objetivo	Nuestro target
Veredictos totales	> 100	Nuestro org opera 500 racks → ~150-200 veredictos esperados
Signal %	> 85%	Si cae < 85%, ajustar heurísticas
Falso positivos	< 15%	Typo, conflictos IP por DHCP, etc.
Feedback frequency	1 veredicto/día	Nuestro ops team activo

Criterio de Go: signal_pct > 85% SOSTENIDO por 2 semanas (no puntual).

Alternativas consideradas

Alt A: Activar globalmente en v1.60.0 (rechazada)

❌ Riesgo: motor sin calibrar → ruido → desconfianza usuario.

Alt B: Ocultar totalmente en v1.60.0, lanzar en v1.61.0 solo (rechazada)

❌ Ineficiente: duplica work si tuning requiere cambios en motor.

Alt C: Flag de feature por org (aceptada, implementada)

✅ Módulo SaaS opt-in = feature flag nativo. Seguro, reversible, controllable.

Referencias

[[feature—racks—integridad-f2-radar-interno]] — La feature completa.
[[entity—core—module—integrity]] — Cómo se implementa el gating.
[[concept—racks—calibracion-sensor]] — Por qué los veredictos calibran.
Gate #202 en Jira — Task de decisión Go/NoGo.

Aprobación

ADR: Edu (CreaRack) · 2026-07-17
Estado: Implementado
Próximo hito: Gate #202 decision ~ 2026-08-30

Véase también

[[feature—racks—integridad-f2-radar-interno]]
[[entity—core—module—integrity]]
[[concept—racks—calibracion-sensor]]
[[decision—20260717—motor-integridad-es-el-analisis-completo]]