Laboratorio I+D+I — MVP mínimo para validación institucional (bomberos/rescate)
Línea de investigación distinta de
notebook-infraestructura-transporte.md: aquella es
sobre tecnología de canal (qué hardware/protocolo hace viable el transporte del mensaje);
esta es sobre producto y validación — qué es lo mínimo que tiene sentido enseñarle a un
consorcio de bomberos/rescate real (ej. tipo Consorcio Provincial de Bomberos de Huelva, usado
aquí como ejemplo de la clase de institución, no un contacto ya establecido) para conseguir
validación de expertos antes de seguir invirtiendo.
El objetivo de esta fase, dicho explícitamente
No es conseguir que adopten NumChat, ni un piloto de campo, ni una venta. Es conseguir que un
bombero/técnico de rescate real se siente delante de la demo y diga si el concepto y el
contenido tienen sentido operativo — si las categorías, acciones y matices del cartucho de
Situaciones Críticas reflejan cómo comunican de verdad, qué falta, qué sobra, qué está mal
planteado. Es validación de contenido con expertos de dominio, no validación de despliegue.
Por qué esto no necesita construir nada nuevo
Todo lo necesario ya existe y funciona:
El cartucho Situaciones Críticas (10 categorías, acciones, matices, destinatario) en
src/config/schemas.ts / cartridgeContent.ts.
La demo acústica de dos móviles intercambiando el código por sonido, sin red — ya construida y
es la pieza más vistosa para una demo en persona.
La herramienta de construcción de cartuchos (cartridge-builder/), que ya sabe importar un
documento de protocolo real vía IA y convertirlo en un borrador de cartucho — es decir, si la
sesión de validación funciona bien, el siguiente paso natural (pedirles su manual de
procedimientos real y construir un cartucho de verdad a partir de él) también está ya resuelto
como herramienta.
El "MVP" aquí no es tecnología — es el guion de la sesión y el mecanismo de recogida de
feedback, para que la validación sea comparable si se repite con más de una institución.
Qué NO prometer en esta sesión (honestidad, no venta)
Por lo aprendido en el notebook de infraestructura de transporte:
No presentar el canal acústico como listo para un despliegue real de rescate — es una prueba de
concepto de corto alcance, en la misma sala, no algo que funcione a través de escombros o a
distancia real todavía.
No prometer BLE, vibración-baliza, ni hardware LoRa/wearable — son líneas de investigación
abiertas, no funcionalidad actual.
Ser explícitos sobre esto en la propia sesión: "esto valida el lenguaje y la lógica del
protocolo; la parte de cómo viaja la señal en un despliegue real es la siguiente fase, y
vuestra opinión sobre qué necesitáis de verdad (alcance, robustez, integración con vuestro
equipo) es precisamente lo que nos ayudaría a priorizar."
Guion propuesto de la sesión (60-90 min)
Contexto (10 min): qué es NumChat — un protocolo de comunicación por código numérico
configurable por sector ("cartucho"), pensado para funcionar sin red. Dejar claro desde el
principio que se busca su criterio experto, no una venta.
Demo en vivo (15 min): dos móviles, cartucho de Situaciones Críticas, intercambio de
mensajes por sonido. Que ellos mismos compongan un mensaje con el teclado guiado y vean cómo
se traduce.
Repaso guiado del contenido del cartucho (30-40 min), categoría por categoría — esto es el
núcleo de la sesión, con preguntas concretas por eje:
Categorías (10, tope fijo del protocolo): ¿cubren los tipos de incidente reales que
manejáis? ¿Cuáles sobran, cuáles faltan, cuáles fusionaríais?
Subcategorías: ¿hay categorías que necesiten más granularidad de la que tiene hoy?
Acciones: ¿son los verbos/operaciones que usáis de verdad por radio o en el parte?
Matices: ¿reflejan los estados/prioridades reales (crítico, en curso, resuelto, silencio
operativo...)? ¿Falta algún matiz que uséis constantemente?
Destinatario: ¿a quién dirigís realmente los mensajes en una operación (mando, sanidad,
otros equipos...)? ¿La lista de hoy encaja?
Pregunta de cierre, la más importante: "si esto existiera de verdad, ¿lo usaríais? ¿Qué
tendría que ser cierto para que sí?" — la respuesta a esto, más que cualquier otra, es la señal
real de validación o de que hay que pivotar el enfoque.
Puerta abierta (5 min): si hay interés genuino, plantear (sin comprometer nada en la
sesión) la posibilidad de co-construir un cartucho real a partir de su propio manual de
procedimientos, usando la herramienta de importación por IA ya construida.
Mecanismo de recogida de feedback
Para que el resultado sea comparable entre instituciones (si se repite esta sesión con más de una
en el futuro), conviene un formulario/checklist corto y estructurado por los mismos ejes del
guion (categorías / subcategorías / acciones / matices / destinatario / "¿lo usaríais?"),
rellenado durante o justo después de la sesión — no una charla informal sin registro. Formato
concreto (papel, formulario digital, entrevista grabada) aún por decidir.
Cómo abordar a una institución de este tipo (investigado 2026-09-07)
Un consorcio provincial de bomberos español (verificado con el caso de Huelva como ejemplo real)
es una entidad pública gestionada normalmente por la Diputación provincial, con:
Un departamento/área de Formación propio (en el caso de Huelva, con centro de formación
dedicado en Valverde del Camino) que ya gestiona colaboraciones externas de forma habitual — es
la vía de entrada más realista y de menor fricción para una demo/sesión de validación, mucho
más accesible que el comité ejecutivo o un canal de contratación formal.
Precedentes reales de colaboración externa con otras entidades (ej. centros de formación
navales, colegios profesionales) — confirma que este tipo de institución sí acepta
colaboraciones puntuales de bajo compromiso, no solo procedimientos de compra pública.
La pauta general de innovación abierta con pymes/startups en España coincide en esto: la
primera validación debe tener alcance pequeño y ejecutable (una sesión, no un proyecto), con
visibilidad real pero sin comprometer grandes recursos de ninguna de las dos partes.
Conclusión práctica: el punto de entrada a proponer no es "contratación" ni "pilotar el
sistema", es "una sesión de validación de una hora con vuestro equipo de formación/técnicos" —
pedir poco, con un entregable concreto (el cartucho actual + la demo) ya construido.
Preguntas abiertas, sin resolver todavía
¿A qué institución concreta dirigirse primero, y por qué vía (contacto personal, solicitud
formal al departamento de Formación, otra)?
Formato definitivo del formulario/checklist de feedback — papel, digital, entrevista.
¿Se hace la sesión con el cartucho actual tal cual, o se prepara antes una versión afinada
con mejor terminología en español de protección civil, para no gastar la primera impresión
en detalles de redacción evitables?
Si la validación va bien, ¿cuál es el siguiente paso concreto — pedirles un documento de
protocolo real para probar la importación por IA del cartridge-builder en vivo con ellos?