# Novedades del producto: Barra de Integridad + CNS/ITSM (versión markdown de prueba)

> 21 de julio de 2026 · CreaRack Pro v1.61.5 en producción · para Txell y Dani.
> Esta es la versión `.md` del informe — la versión completa con gráficos es el HTML del mismo nombre.

## En sencillo

CreaRack dibuja el plano de los racks; el Agente ve qué equipos hay funcionando de verdad. La **Barra de Integridad** es una nota de 0 a 100 por rack que dice cuánto se parece el plano a la realidad, y que **baja sola** cuando algo cambia en la red y nadie actualiza el dibujo. Cuando el sistema confirma que un cambio es real, abre una incidencia con una explicación escrita en claro, y al resolverla el plano y la nota se ponen al día solos. **Todo está apagado para clientes**: solo lo vemos nosotros mientras medimos si el detector acierta. Si en una red ajena acierta el 80% o más, se enciende y se vende; si no, se rediseña o se descarta.

## 1. Estado del plan

| Fase | Qué es | Versión | Estado |
|---|---|---|---|
| F1 · Motor | Cruce plano↔realidad: clasifica equipos y calcula las dos notas. Foto diaria 04:15 | v1.59.0 | ✔ En producción |
| F2 · Radar interno | Página Integrity: notas, histórico y cola de revisión con 3 veredictos | v1.60.0 | ✔ En producción |
| F3 · CNS/ITSM | Cambio confirmado → incidencia con explicación de la IA; resolver = re-verificar | v1.61.0 | ✔ En producción |
| Pulido | Textos EN + 4 arreglos de monitorización cazados al verificar el sensor | v1.60.1 · v1.61.1→.5 | ✔ En producción |
| F4 · Cara externa | Racha por sitio + bloque en el Project Report | — | ◌ Aparcada a propósito |
| Calibración | Foto diaria en la oficina + veredictos nuestros | — | ▶ En marcha |
| Validación | El examen en red ajena contra el umbral pre-declarado | — | ◷ Septiembre-octubre |

**El plan está concluido en todo lo que dependía de construir.** F4 y la activación comercial esperan al examen — por diseño, no por retraso.

## 2. La Barra de Integridad

La documentación de racks **se pudre en silencio**: alguien sustituye un servidor, no actualiza el plano, y seis meses después el plano miente. Como el Agente ve la red de verdad, la Barra compara continuamente "lo que el plano dice" con "lo que la red demuestra".

**Las dos notas** (un solo número mentiría):

- **Coverage** — ¿qué porcentaje de los equipos del plano puede observar el sensor?
- **Fidelity** — de lo observable, ¿cuánto cuadra con el plano? Esta es la que decae sola.

Regla de oro: lo que el sensor no puede ver va a **cuarentena** y jamás baja la fidelity — un MSP no puede sacar mala nota por física de red.

**Las cinco clases** que asigna el motor cada madrugada:

| Clase | Significado |
|---|---|
| matched_alive | En el plano y vivo en la red. El caso feliz |
| matched_stale | En el plano pero días sin señales de vida. ¿Retirado? ¿Apagado? |
| ip_conflict | Dos equipos comparten IP de gestión. Huele a sustitución o clonado |
| unobservable | El sensor no puede verlo. Cuarentena: ni puntúa ni castiga |
| undocumented | Vivo en la red pero en ningún plano. Se reporta a nivel de organización |

**El radar interno** (página `/integrity/`, módulo activado solo en nuestra org): cada aviso llega con su evidencia y el técnico dicta uno de tres veredictos — *Plan updated* (corregí el plano), *Real change* (abre incidencia), *False alarm* (a cuarentena silenciada). Cada veredicto alimenta automáticamente el contador señal/ruido del examen: usar el producto ES calibrarlo.

**Límite honesto**: el Agente ve el *qué* (existencia, vida, identidad), no el *dónde* físico. Una mudanza dentro de la misma red no es detectable sola — por eso la confirmación humana está siempre en el circuito.

## 3. El examen antes de vender (gate)

Umbral declarado por escrito **antes** de mirar datos (17-07-2026):

| % de avisos que resultan reales | Decisión |
|---|---|
| ≥ 80% | GO — activar y vender |
| 60-80% | Rediseñar el emparejado |
| < 60% | KILL del empaquetado (el score mentiría) |

La oficina solo calibra; la validación de verdad será en la red de un design partner (sept-oct). Seguimiento: task #202.

## 4. El puente con las incidencias (F3)

En vez de inventar un sistema nuevo, la cola de la Barra desemboca en el CNS/ITSM que ya existe:

1. El probe diario detecta un posible cambio y lo pone en la cola con su evidencia.
2. El técnico dicta "Real change" → se abre una **incidencia CNS** con la explicación de la IA en claro ("parece que sustituyeron el servidor del rack 3, ¿actualizo el plano?"). Documental, sin comandos, caduca a los 14 días.
3. **Resolver = reconciliar**: al cerrar la incidencia, el próximo probe re-verifica. Si el plano quedó bien, la nota sube; si no, vuelve a avisar.
4. Regalo: el historial de incidencias resueltas alimenta gratis el informe trimestral del MSP.

## 5. CNS en dos palabras

**CreaRack Network Sentinel** vigila la red (Observatory, Wireless, UPS) y ante una anomalía genera un **Insight**: diagnóstico con causa raíz, confianza (0-100%), riesgo (HIGH/MEDIUM/LOW), telemetría y comandos con su rollback. Estados: *Pending* → *Applied* / *Acknowledged* / *Expired* (4 h) / *Failed*. Con **Explain** le preguntas a la IA con el contexto del caso cargado; las conversaciones quedan guardadas en el insight. Los **patrones recurrentes** y los **grupos de incidentes** filtran el ruido: un fallo de uplink que tumba 5 APs es un grupo, no cinco alarmas.

## 6. ITSM en dos palabras

La disciplina de gestión encima del CNS: **SLA** por riesgo (HIGH: ack 15 min / resolver 60 min · MEDIUM: 30 min / 4 h · LOW: 60 min / 8 h, personalizables), **canales de notificación** (email, Slack, Teams, webhook) filtrables por riesgo, **escalado** en 3 niveles si nadie responde, **ventanas de mantenimiento** que suprimen alertas, y **known issues + runbooks** que aparecen como badge cuando un insight nuevo coincide con un problema documentado.

## 7. La foto real de la oficina

Al encender el sensor para calibrar salieron **cuatro bugs encadenados** de la monitorización, arreglados y desplegados el mismo día (v1.61.1→.5): el ingest bulk no contaba como prueba de vida, los replays del Agente machacaban el estado vivo (130/131 caídos falsos), la lista de incidencias salía invertida, y faltaba el control de orden. Resultado verificado en producción: **88 equipos vivos / 43 caídos reales** de 131 monitorizados. El motor se ganó el sueldo antes de estrenarse: su primera medición detectó que el propio sensor estaba dormido.

## 8. Qué queda y quién lo tiene

- **Gate señal/ruido** (task #202) — Edu, sept-oct, validación en red ajena.
- **F4 cara externa** — tras el feedback MSP.
- **Task #203** — throttle del re-envío histórico del Agente + flapping del WS (próximo `.exe`).
- Hueco anotado sin fecha: `resolved_at` de las incidencias no lo rellena ningún flujo.

---

*Fuentes: plan vivo `barra-integridad/PLAN_BARRA_INTEGRIDAD.md` · STATE.md s227-s229 · guía `crearack-tech--guides--cns-itsm-user-guide` · tasks #202/#203.*