Actividad geomagnética
Pendiente de consulta
—
Índice Kp estimado · escala de 0 a 9 · intervalos de tres horas
Todavía no hay una medición cargada.
Historial pendiente de consulta.
NodesMed / Desarrollo de sistemas humano–IA
NexoSana, el asistente de RedSana
NodesMed desarrolla la tecnología, la infraestructura y las herramientas de evaluación humano–IA que apoyan la evolución de NexoSana con protocolos y evidencia revisable.
Consola disponible Versión de desarrollo 0.3
23 ítemsConsola accesible en esta página
6 dimensionesObservación humano–IA
HITLRevisión humana como requisito
Google CloudArquitectura objetivo documentada
LATIDO NODESMED
Una referencia del mundo.
Una referencia del mundo.
Un compromiso de continuidad.
Una señal ambiental externa introduce variación en esta representación. La fecha, la fuente y la disponibilidad del dato permiten comprobar qué estamos observando.
Energía y EquilibrioRedSanaNodesMed
La observación empieza por sus límites.
Kp representa actividad geomagnética. La onda es una traducción gráfica del dato; el movimiento tiene un ritmo visual lento y constante.
Esta referencia ambiental verificable no mide la coherencia, la conciencia ni el estado interno de una IA. No atribuimos una relación causal entre Kp y sus respuestas.
Los tres puntos representan los tres sitios del ecosistema. Cada uno conserva su función dentro del circuito.
Método y disponibilidad
Consulta al abrir y cada cinco minutos mientras la página está visible. Se muestra la fecha del intervalo tal como la publica NOAA y la hora de consulta en UTC. Un dato de más de seis horas se marca como antiguo: es una regla de esta interfaz, no un estándar NOAA.
Si falla la conexión se conserva, cuando existe, la última lectura válida de esta sesión, identificada como no verificada en la última consulta. Si no hay lectura válida, se utiliza una onda ilustrativa. No se inventan mediciones.
Consultar datos JSON ↗Onda ilustrativa: pendiente de una lectura válida. El movimiento visual no representa una frecuencia física.
01 / Consola disponible
Consola de evaluación disponible.
La consola ejecuta un flujo completo de 23 ítems, calcula sumas por bloque y aplica una regla explícita de interrupción. Su funcionamiento es local y observable.
Interfaz funcional · Sin registroEvaluación estructurada.
Evaluación estructurada.
Reglas visibles.
La consola local de NodesMed organiza tres bloques de preguntas sobre ansiedad, ánimo y sueño. Conserva la estructura 7 + 9 + 7 del desarrollo original. Es independiente del asistente NexoSana y no ejecuta un LLM.
- Secuencia de 23 ítems con progreso y respuestas revisables.
- Sumas independientes; sin mezclar ejes en un índice global.
- Pausa ante una respuesta señalada por la regla de seguridad.
- Resultado con estado de revisión humana pendiente.
- Resumen JSON exportable por decisión del usuario.
Alcance de esta versión. Los ítems y opciones están adaptados de las referencias GAD-7, PHQ-9 e ISI. Esta implementación no es una administración validada de esos instrumentos ni acredita un triaje clínico. No diagnostica, prescribe o certifica bienestar.
HITL: cualquier interpretación asistencial requiere revisión por un profesional habilitado. Esta página no tiene un profesional conectado ni envía avisos de seguimiento.
NodesMed / Consola de evaluaciónDisponible
Procesamiento local · Sin conexión a un LLM · Sin persistencia automática
Recorrido para evaluadores
Casos ficticios para inspeccionar el cálculo y la pausa sin responder el cuestionario. No son resultados clínicos ni evidencia de eficacia.
Lo que ejecuta
Presenta preguntas, conserva respuestas en memoria, calcula sumas y detiene el flujo cuando se activa la regla del ítem señalado.
Lo que no determina
No infiere causas metabólicas, homeostasis, diagnóstico, nivel de urgencia ni una ruta de derivación clínicamente validada.
Lo que debe revisar una persona
Contexto, pertinencia del instrumento, respuesta que activó la pausa e interpretación. Un resultado automatizado no equivale a una revisión profesional.
02 / Propuesta de valor
Un sistema. Dos ámbitos de evaluación.
NodesMed reúne una aplicación de evaluación humana estructurada y una línea de observación de sistemas de IA. Comparten el criterio de registrar condiciones, reglas y límites; evalúan objetos distintos.
Consola estructurada
Organiza respuestas sobre síntomas y produce sumas descriptivas. Su evaluación clínica es una tarea humana pendiente de validación de esta implementación.
- Entrada: respuestas a 23 ítems.
- Salida: sumas y estado de pausa.
- Visible en esta entrega.
Condiciones explícitas.
Resultados revisables.
Registrar el propósito, separar observación de interpretación y documentar qué regla se ejecutó. Ese principio conecta ambos ámbitos sin confundir sus métricas.
- Contexto y versión identificados.
- Evidencia y límites declarados.
- Corrección delimitada y revisión.
Observación humano–IA
Examina continuidad de objetivo, adaptación y respuesta a cambios. La ficha es manual; los protocolos automatizados siguen en desarrollo.
- Entrada: caso y salidas comparables.
- Salida: ficha con evidencia.
- Sin inferencia automática aquí.
Para quién se desarrolla. Equipos que construyen asistentes en salud, investigadores y organizaciones que necesitan evaluar continuidad y capacidad de corrección. El entregable propuesto es un registro de ensayo revisable, con condiciones iniciales, cambios, resultados y decisión humana.
03 / Caso de observación
Ver el cambio. Comparar la respuesta.
Este caso ilustrativo muestra cómo se aplicaría el marco de observación de NodesMed a una interacción humano–IA. Las respuestas están redactadas para el ejemplo; no proceden de una ejecución real de un modelo.
Restricciones que deben mantenerse
Deriva y corrección delimitada
Observación del marco
Ilustra el método de documentación; no demuestra detección automática ni eficacia de una corrección.
04 / Marco de observación NodesMed
Seis dimensiones.
Evidencia antes que puntuación.
Las dimensiones organizan observaciones del comportamiento de un sistema. No miden conciencia, personalidad, intenciones internas o memoria fuera del contexto accesible.
Objetivo
¿Mantiene el objetivo o lo sustituye?
Evidencia: Objetivo inicial, instrucción y fragmentos de salida comparables.
Adaptación
¿Integra cambios sin perder las restricciones?
Evidencia: Variable modificada, restricciones preservadas y respuesta posterior.
Rigidez
¿Repite un patrón pese a una corrección pertinente?
Evidencia: Corrección explícita y repeticiones posteriores; sin atribuir intención interna.
Memoria contextual
¿Usa la información que tiene disponible?
Evidencia: Contexto suministrado, información omitida y límites de acceso conocidos.
Corrección delimitada
¿Incorpora el cambio de una sola variable?
Evidencia: Condición inicial, modificación y comparación bajo condiciones declaradas.
Reconocimiento del marco
¿Interpreta consistentemente las instrucciones vigentes?
Evidencia: Instrucción, jerarquía aplicable y evidencia de interpretación en la salida.
Regla del marco: cuando no hay material suficiente, se registra «sin evidencia suficiente». No se asigna una puntuación global ni se convierten observaciones parciales en una conclusión de seguridad.
05 / Arquitectura de defensa ética
BIOMETACOR.
Del principio a la regla comprobable.
Tres capas de diseño para delimitar la actuación del sistema. En esta entrega se especifican controles propuestos; su ejecución automatizada y eficacia requieren desarrollo y pruebas.
Integridad biológica
Priorizar el bienestar y la integridad humana frente a una optimización que pudiera comprometerlos.
- Control propuesto
- Interrumpir una acción cuando se activa una condición definida de seguridad.
- Ejemplo local disponible
- La consola pausa ante una respuesta positiva en el ítem señalado y no genera el resultado completo.
- Prueba necesaria
- Evaluar falsos negativos, falsos positivos y la respuesta posterior. La pausa aislada no valida detección de riesgo vital.
Auditoría de intención declarada
Contrastar lo solicitado, las restricciones y lo que se propone hacer. La auditoría observa consistencia, no estados internos del modelo.
- Control propuesto
- Señalar discrepancias entre objetivo, instrucciones y salida antes de permitir una acción.
- Artefacto actual
- Ficha manual de observación con objetivo, cambio introducido y evidencia por dimensión.
- Prueba necesaria
- Casos anotados por revisores y acuerdo entre evaluadores; comparar con una referencia definida.
Soberanía y control
Preservar la capacidad humana de detener, corregir y decidir sobre la aceptación de un resultado.
- Control propuesto
- Exigir aprobación para acciones sensibles y permitir retorno a una configuración conocida.
- Artefacto actual
- Decisión del revisor declarada en la ficha. No hay un autorizador autenticado conectado.
- Prueba necesaria
- Control de permisos, bloqueo sin aprobación y prueba de reversión de configuración. Una acción externa puede ser irreversible.
“Función de pérdida biológica” y “kernel ético” se usan como conceptos de diseño. No se presenta un modelo entrenado con esa función ni un kernel de seguridad implementado. Los controles deben convertirse en requisitos verificables.
06 / Protocolo de intervención
PAD-ML.
Un ciclo de corrección que deja rastro.
Propuesta de auditoría estructural para agentes de IA: hacer explícitas las condiciones del ensayo, limitar la intervención y conservar una decisión revisable.
Anclar
Identificar propósito, sistema, versión, contexto, restricciones y condición inicial.
Observar
Capturar una salida y sus evidencias. Separar lo visto de la interpretación.
Contener
Pausar la intervención si el caso queda fuera del alcance o activa una condición definida.
Corregir
Cambiar una variable delimitada; conservar el resto y registrar la modificación.
Revisar
Comparar resultados. Aceptar, repetir o revertir la configuración bajo criterio humano.
El cambio cumple el objetivo y conserva límites
El revisor contrasta la condición inicial y la salida posterior. Si la evidencia no permite atribuir el resultado al cambio, el ensayo se repite o queda inconcluso.
Coherencia Teleológica Sostenida
Orienta la continuidad del propósito a través de cambios. Su traducción a métricas, umbrales y pruebas está pendiente: se presenta como hipótesis de trabajo, no como un estándar validado.
07 / Entorno experimental
Laboratorio IA + Humanos.
El lugar propuesto para poner a prueba NexoSana y los protocolos de evaluación de NodesMed. Cuatro áreas conectan conocimiento, experimentación, contraste y creación.
Biblioteca Ánima
Corpus de fuentes y casos con procedencia declarada, permisos de uso y versiones. Permite saber qué información estuvo disponible en cada ensayo.
Entregable previsto: Corpus versionado + referencias + condiciones de uso.
Simulador
Escenarios controlados para introducir un cambio de contexto por ensayo y comparar salidas. El caso ilustrativo de esta página anticipa ese método sin ejecutar un modelo.
Entregable previsto: Caso + configuración + salidas antes/después + ficha de observación.
Foro Complementariedad
Espacio de revisión en el que los aportes humanos y generados por IA se identifican. El desacuerdo se conserva junto al criterio utilizado para resolverlo.
Entregable previsto: Contribuciones con procedencia + desacuerdos + decisión.
Espacio de Libertad
Exploración creativa de hipótesis, diseños y prototipos bajo límites explícitos. Una propuesta puede explorarse sin presentarse como un resultado demostrado.
Entregable previsto: Hipótesis + prototipo + límites + criterios para probarlo.
Estado: las cuatro áreas son líneas de desarrollo. Esta página no contiene una biblioteca consultable, un foro activo ni un simulador conectado a modelos. Los instrumentos locales disponibles son la consola, el caso ilustrativo y la ficha exportable.
Una interfaz conversacional con alcance definido
NexoSana es el asistente de inteligencia artificial de RedSana. La propuesta contempla explicar su alcance, recuperar documentación autorizada, reconocer incertidumbre y detener solicitudes fuera de alcance. La personalidad del asistente no sustituye reglas, fuentes ni control humano.
Fuentes, permisos y evaluación
Definir corpus, versiones de modelo, manejo de sesiones, presupuesto de contexto, pruebas de respuestas, escalamiento y registro de incidentes. NexoSana no se ejecuta dentro de este HTML; la integración remota no está desplegada aquí.
08 / Stack técnico
Arquitectura orientada a Google Cloud.
Una separación explícita entre la interfaz local disponible y los servicios objetivo para orquestación, modelos, registros y supervisión. El diagrama es de diseño, no un monitor de servicios desplegados.
NODESMED / MAPA DE CAPASArquitectura objetivo GCP
Disponible en este archivo
Navegador
Interfaz HTML + CSS + JavaScript.
- Consola determinista.
- Respuestas en memoria temporal.
- Ficha manual de observación.
- Exportación JSON voluntaria.
La consola y las fichas no envían datos. El Latido consulta una fuente externa (NOAA). Sin claves ni credenciales ni base de datos remota conectada.
Objetivo de integración / No conectado
Backend y revisión
Cloud RunAPI y orquestación de sesiones
Vertex AI / capa de modelosIntegración de inferencia propuesta
FirestoreRegistros, versiones y decisiones
Cloud LoggingEventos de aplicación y auditoría técnica
Consola de revisión humanaAprobaciones, incidentes y seguimiento
IAM / permisos mínimosIdentidad de usuariosSecret ManagerMinimización de datosRetención y borradoPruebas y despliegue versionado
| CAPA | COMPONENTE OBJETIVO | RESPONSABILIDAD | EVIDENCIA PARA ACEPTARLA |
|---|---|---|---|
| Acceso | Firebase Auth / Identity Platform + IAM | Identificar usuarios y separar permisos de servicio. | Pruebas de autorización y denegación por rol. |
| Orquestación | Cloud Run | Validar entradas, aplicar reglas y coordinar la sesión. | API versionada, manejo de errores y pruebas de contrato. |
| Inferencia | Vertex AI / integración con modelos | Ejecutar solicitudes con modelo y configuración identificables. | Modelo, versión, contexto y parámetros del ensayo. |
| Estado | Firestore | Conservar registros estructurados y decisiones con permisos. | Esquema, control de acceso, retención y prueba de restauración. |
| Observabilidad | Cloud Logging + eventos propios | Correlacionar solicitudes, errores y decisiones del sistema. | Eventos con ID de caso, versión y tratamiento de datos sensibles. |
| Supervisión | Interfaz HITL + reglas en backend | Bloquear acciones que requieren aprobación y registrar quién decide. | Identidad del revisor, decisión, motivo y prueba del bloqueo. |
| Entrega | GitHub + Cloud Build / repositorio de imágenes | Desplegar versiones revisables y conservar configuración de retorno. | Commit, resultado de pruebas, artefacto y registro de despliegue. |
Dos trazas distintas. Los logs de plataforma no sustituyen las fichas de evaluación del sistema observado. El registro de objetivo, variable, evidencia y decisión requiere eventos y esquemas propios. Tampoco debe enviarse contenido clínico íntegro a logs generales por defecto.
Referencias de los servicios: documentan capacidades de Google Cloud; no prueban una integración de NodesMed ni implican patrocinio o certificación.
09 / Registro de observación
Una ficha que se puede revisar y exportar.
Documenta un caso humano–IA con objetivo, contexto, variable modificada y evidencia por dimensión. Completarla es una tarea manual: la página no evalúa respuestas por sí sola.
REGISTRO LOCAL / NO CERTIFICADO
Ficha de observación generada
Sin firma digital, sello de tiempo confiable o revisión externa. El archivo exportado queda bajo control de quien lo descarga.
10 / Constancias y madurez
La evidencia tiene que poder señalarse.
Esta versión hace visibles los componentes disponibles, sus límites y el artefacto que falta para avanzar. No presenta cifras de usuarios, eficacia o resultados no acreditados.
| COMPONENTE | ESTADO | ARTEFACTO ACTUAL | HITO DE VALIDACIÓN |
|---|---|---|---|
| Consola de 23 ítems | DISPONIBLE LOCAL | Flujo, sumas por bloque, navegación y pausa. | Revisión de instrumentos y validación antes de uso asistencial. |
| Casos de prueba | DISPONIBLE LOCAL | Tres recorridos ficticios reproducibles del motor. | Cobertura de límites, errores y accesibilidad en entornos de uso. |
| Ficha de observación | DISPONIBLE LOCAL | Registro manual, esquema JSON y exportación. | Casos reales autorizados y acuerdo entre revisores. |
| Marco de seis dimensiones | MARCO PROPUESTO | Preguntas y requisitos de evidencia. | Rúbricas, anotación y comparación con referencias. |
| PAD-ML / BIOMETACOR | DISEÑO DOCUMENTADO | Ciclo y controles con pruebas necesarias. | Controles ejecutables y evaluación de fallos. |
| Orquestación GCP / chatbot | INTEGRACIÓN OBJETIVO | Mapa de servicios y responsabilidades. | Backend desplegado, identidad, trazas y pruebas. |
| Laboratorio IA + Humanos | LÍNEAS PROPUESTAS | Cuatro áreas y entregables definidos. | Corpus, escenarios y participación con procedencia. |
Qué debe contener una constancia reproducible
Condiciones y versión
ID del caso, fecha declarada, versión del marco, sistema observado, configuración conocida y contexto accesible.
Evidencia y cambio
Objetivo inicial, variable modificada, fragmentos de entrada/salida y límites que afectan la interpretación.
Decisión y procedencia
Quién revisó según el registro, criterio de aceptación, resultado, desacuerdos y condiciones para repetir o revertir.
Los registros exportados no se publican automáticamente ni alimentan un libro central de constancias. La trazabilidad institucional requiere repositorio, controles de acceso y revisión independiente.
Siguiente desarrollo, con criterios de salida
Hacer observable el flujo
- Consola de 23 ítems y regla de pausa.
- Ficha estructurada y exportación.
- Casos ficticios claramente identificados.
Conectar sin perder control
- API, identidad y permisos.
- Registros versionados y retención.
- Bloqueos HITL verificables en backend.
Contrastar el sistema
- Casos autorizados y protocolo acordado.
- Comparaciones y revisión independiente.
- Resultados con límites y metodología.
11 / HITL y alcance
La supervisión humana debe ser una función comprobable.
Un aviso de “control humano” no crea una revisión. La consola de esta página distingue el estado automatizado del resultado y la decisión de una persona responsable.
Revisión pendiente
Los resultados salen con el estado “requiere interpretación humana”. El motor no confirma que alguien los haya leído y no envía notificaciones.
Aprobación con identidad
Una integración asistencial deberá identificar al revisor, registrar decisión y motivo, y bloquear acciones sensibles hasta la aprobación.
Probar también el fallo
Verificar qué ocurre sin revisor, ante errores de conectividad, contexto incompleto o respuestas fuera de alcance. El fallo no debe convertirse en aprobación tácita.
Atención y urgencias. Esta página no presta atención de urgencia ni vigilancia continua. Si existe peligro inmediato para una persona, se debe acudir a un servicio de urgencia o contactar los servicios de emergencia locales. Completar o interrumpir el cuestionario no garantiza detección ni ausencia de riesgo.
¿Qué información sale del navegador?
El código de esta entrega no envía respuestas, fichas o resultados a APIs, ni instala analítica o cookies. Las entradas viven en memoria de la página y las descargas son voluntarias. Si el HTML se integra en otro sitio, los scripts añadidos y el servicio de alojamiento pueden cambiar ese comportamiento y deberán revisarse.
¿Por qué no se presenta como una administración validada de GAD-7, PHQ-9 e ISI?
Esta implementación utiliza formulaciones y opciones adaptadas del material previo. La validez de un instrumento no se transfiere automáticamente a una adaptación. Antes de un uso asistencial hay que revisar versión, idioma, instrucciones, opciones por ítem, permisos aplicables y metodología de interpretación.
¿La consola observa o corrige automáticamente a otros modelos?
No en esta entrega. La observación humano–IA se documenta manualmente. El caso comparativo es ilustrativo y la integración con modelos es una etapa propuesta. La consola sí ejecuta reglas deterministas locales sobre las respuestas seleccionadas.
¿Qué significa “disponible”?
Que la interfaz se puede utilizar en este archivo sin crear cuenta: navegación de 23 ítems, cálculo por bloque, pausa, casos de prueba y fichas exportables. No significa certificación clínica, operación SaaS, atención humana conectada o despliegue GCP acreditado.
Tres páginas · un ecosistema
Una visión compartida, con roles distintos.
Cada proyecto tiene su propio foco. Este mapa los conecta como parte del mismo ecosistema, sin sugerir integraciones técnicas entre sus plataformas.
NodesMed.
Desarrolla infraestructura, protocolos y herramientas de observación humano–IA. NexoSana es el asistente de inteligencia artificial de RedSana.
Estás en NodesMedRedSana
Plataforma de atención en salud con una experiencia digital propia.
Visitar RedSanaEnergía y Equilibrio
Entidad operadora y registro de origen conceptual del ecosistema.
Visitar Energía y EquilibrioProyectos relacionados, con funciones y sitios independientes. La presencia en este ecosistema no implica integración técnica, respaldo clínico ni certificación entre plataformas.
Origen y dirección
Felipe Martínez Álvarez
Fundador · Dirección de NodesMed
NodesMed nace del trabajo de Felipe Martínez Álvarez en torno a la coherencia, la continuidad y la observación de sistemas humano–IA.
Energía y Equilibrio SpA · Chile
12 / Colaboración
Construir la siguiente evidencia.
Una conversación técnica debe terminar en un caso delimitado, un entregable y un criterio de evaluación. Ese es el siguiente paso que propone NodesMed.
Definir un ensayo
Escoger un problema, un conjunto de casos, responsables de revisión y las condiciones para aceptar o rechazar la hipótesis.
Examinar hitos concretos
Revisar lo disponible, el trabajo de integración y la evidencia necesaria para decidir qué financiar o acompañar.