MEMORIA TÉCNICA

Registro de la Propiedad Intelectual de la Comunidad de Madrid

Obra: WHeat-Jobs | Fenotipo

Copyright © 2026 Ricardo Manuel Trigo Calonge
versión 1.0.0.0

1. Identificación de la obra y declaración de autoría

Autor de la obra software
Ricardo Manuel Trigo Calonge
Doctor en Derecho · Licenciado con Grado en Ciencias Químicas · Máster en Fisioterapia, Fisiología y Psicología del Deporte
Madrid, España · 2026

La presente memoria técnica describe la estructura, arquitectura, organización funcional, persistencia, lógica algorítmica y subsistemas principales de la obra software WHeat-Jobs | Fenotipo, a efectos de identificación técnica de la obra y de exposición ordenada de sus elementos originales de diseño e implementación.

Se hace constar que el Dr. Ricardo Manuel Trigo Calonge es autor del diseño funcional, de la arquitectura de software, de la organización lógica del sistema, del modelo algorítmico, del diseño de persistencia y del código fuente incorporado a la presente obra. La eventual utilización de herramientas de asistencia a la programación no altera la autoría sobre la concepción, selección, validación e integración final del resultado.

2. Ficha técnica y entorno de ejecución

Naturaleza de la obra: Aplicación web de gestión biométrica, clínica y evaluación funcional heurística
Arquitectura de software: Patrón Modelo-Vista-Controlador (MVC) con separación entre presentación, servicios, persistencia técnica, cálculo y evaluación heurística
Lenguaje y framework: C# v13.0 | .NET 10.0 | ASP.NET Core MVC | Visual Studio 2026
Gestión de datos: SQL Server y Entity Framework Core (Code-First)
Autenticación y acceso: Microsoft AspNetCore Identity con tipado fuerte de modelos y validación estructurada
Motores de cálculo: Motor hardcodeado, motor declarativo y modo comparativo dual con resolución en tiempo de ejecución
Unidad lógica de entrada: HealthDashDataBundle como bundle fisiológico integrado de perfil, biometría diaria y analítica clínica
Entorno de despliegue: Servidor web con soporte .NET Runtime y almacenamiento interno de ficheros funcionales de trabajo
Canal de importación masiva: Subida web de ficheros comprimidos mediante ZIP fragmentado por bloques (chunked upload), con recomposición secuencial en servidor, extracción controlada y persistencia interna del export.xml

Esquema de la arquitectura lógica del sistema WHeat-Jobs | Fenotipo

Diagrama de Arquitectura

Diagrama 1

3. Descripción funcional y algorítmica

3.1. Descripción funcional general

WHeat-Jobs | Fenotipo es una plataforma web orientada a la integración, estructuración y explotación funcional de datos biométricos diarios, analíticas clínicas y variables personales de contexto, con la finalidad de generar indicadores compuestos, seguir su evolución temporal y asistir en la interpretación funcional del estado del usuario.

El sistema integra tres fuentes de datos primarias: PerfilPersonal, BiodataDiaria y AnaliticaClinica. A partir de ellas construye una unidad lógica de entrada denominada bundle fisiológico integrado o HealthDashDataBundle, que constituye la base inmediata del cálculo técnico.

La aplicación no se limita al almacenamiento o visualización de información, sino que incorpora una arquitectura propia de formación de contexto fisiológico, cálculo técnico, persistencia histórica, reconstrucción temporal y evaluación heurística orientada a objetivo.

Junto a la gestión manual y estructurada de datos fisiológicos y clínicos, el sistema incorpora un subsistema de importación masiva destinado a la ingestión de exportaciones externas de datos de salud generadas por plataformas de terceros y dispositivos personales. En su estado actual, dicho subsistema admite la subida de ficheros comprimidos ZIP que contienen un export.xml de gran tamaño, evitando la carga directa monolítica del XML mediante una estrategia de subida fragmentada por bloques, recomposición en servidor, extracción controlada y persistencia interna.

Esta arquitectura desacopla la fase de transporte del fichero desde el equipo del usuario y la fase de lectura funcional del XML ya persistido. En consecuencia, el sistema no opera sobre rutas locales del cliente, sino sobre una copia interna validada y almacenada en servidor, reutilizable para lecturas posteriores, generación de archivos reducidos por semana y trazabilidad técnica.

La formación del bundle fisiológico sigue reglas temporales determinadas. La analítica clínica utilizada es la última analítica disponible con fecha igual o anterior a la fecha de cálculo. La biometría diaria, por su parte, se selecciona dentro de una ventana temporal configurable de días naturales, aplicada de forma homogénea al cálculo actual y al cálculo histórico reconstruido.

En la configuración operativa vigente, la ventana biométrica queda expresada, con carácter general, como VentanaBiométrica = [ FechaCalculo − 6 días , FechaCalculo ], siendo ambas fechas inclusivas. En consecuencia, el número máximo teórico de registros biométricos integrados por cálculo es de 7 registros diarios, salvo ausencia material de datos en alguna de las fechas comprendidas.

El núcleo funcional actual se articula mediante tres índices: Score SNC, Score Metabólico y Score Bioenergético. Dichos scores se obtienen a partir del HealthDashDataBundle, incorporando reglas de interpretación, umbrales fisiológicos y, cuando procede, un factor corrector de fiabilidad analítica en función de la antigüedad de la analítica utilizada.

Junto a dichos scores compuestos, la aplicación incorpora además una línea de análisis paralela centrada en la evolución temporal de variables directas de BiodataDiaria y un subsistema específico de análisis energético-metabólico diario basado en EnergyDailyBalance. Estas capas no sustituyen al scoring, sino que lo complementan al permitir examinar tendencias recientes, balance energético, suficiencia proteica y disponibilidad energética funcional desde una perspectiva diaria y longitudinal.

El cálculo técnico se articula mediante una fachada de motor de score capaz de resolver dinámicamente distintas implementaciones. El sistema soporta un motor hardcodeado de referencia operativa, un motor declarativo alineado funcional y matemáticamente con el motor hardcodeado, y un modo de comparación dual destinado al contraste técnico entre ambos.

A diferencia de una implementación declarativa meramente efímera o dependiente únicamente del estado dinámico del sistema, la arquitectura actual incorpora persistencia histórica específica del motor declarativo. En cada ejecución declarativa se registra no solo el resultado numérico obtenido, sino también el estado declarativo efectivo aplicado en ese momento, incluyendo serialización estructurada, metadatos de versión y huella criptográfica de integridad.

La persistencia del estado declarativo efectivo permite reconstruir con precisión el modelo utilizado en cualquier cálculo histórico, facilitando auditoría técnica, comparación longitudinal entre configuraciones y verificación de consistencia lógica entre versiones.

3.2. Fundamentación científico-técnica del motor hardcoded

El motor hardcoded de WHeat-Jobs | Fenotipo no se configura como un sistema de diagnóstico médico autónomo, sino como un modelo funcional de estratificación fisiológica. Su estructura combina, de una parte, umbrales apoyados en referencias clínicas o biomédicas consolidadas y, de otra, tramos heurísticos internos orientados a monitorización funcional, detección de desviaciones y generación prudencial de recomendaciones.

En el dominio metabólico, la base científica es comparativamente más estable. La glucosa basal y la hemoglobina glicosilada (HbA1c) se apoyan en estándares contemporáneos de clasificación de normoglucemia, prediabetes y diabetes, que el sistema reutiliza en forma simplificada para producir scoring funcional. De igual modo, triglicéridos y colesterol HDL se incorporan como variables de contexto cardiometabólico.

La variable pasos / NEAT no constituye un criterio diagnóstico clínico formal, pero sí un marcador funcional razonable del volumen de movimiento habitual. La evidencia y las recomendaciones internacionales de actividad física respaldan la relevancia del movimiento cotidiano y del descenso del sedentarismo como ejes de salud general.

En el dominio SNC, el modelo utiliza HRV, sueño, frecuencia cardiaca en reposo, tensión arterial y magnesio sérico. La literatura apoya que la HRV disminuye con la edad y que una mayor variabilidad suele asociarse a mejor flexibilidad autonómica y mejor capacidad de recuperación; no obstante, los puntos de corte concretos empleados por el motor no equivalen a umbrales diagnósticos universales.

En materia de sueño, el motor combina el tiempo total de sueño con el sueño profundo y, cuando existe dato disponible, con otras variables de arquitectura del sueño. La recomendación general de dormir 7 o más horas por noche en población adulta constituye el apoyo principal del bloque.

La frecuencia cardiaca en reposo se incorpora porque una frecuencia más elevada se ha asociado, a nivel poblacional, con mayor mortalidad total y cardiovascular. En cuanto a la presión arterial, el sistema utiliza una traducción prudente de la literatura y de las guías contemporáneas.

El bloque de magnesio sérico posee respaldo biomédico, aunque con menor uniformidad absoluta en torno al concepto de nivel óptimo. La literatura reciente sobre estandarización de rangos de referencia propone prestar especial atención a niveles séricos en torno a 0,85 mmol/L.

En el dominio bioenergético, hemoglobina, TSH y ferritina constituyen el núcleo base. La hemoglobina se emplea como marcador indirecto de capacidad de transporte de oxígeno; la TSH, como proxy de regulación tiroidea; y la ferritina, como indicador de reservas de hierro.

La modulación bioenergética por sueño profundo, HRV y frecuencia cardiaca en reposo responde a una hipótesis fisiológica plausible: el estado de recuperación autonómica y del sueño condiciona la expresión funcional del sistema bioenergético.

Conclusión metodológica: el motor hardcoded de WHeat-Jobs | Fenotipo es un sistema mixto: combina tramos clínicamente anclados con tramos funcionales heurísticos. La convergencia posterior del motor declarativo acredita la reproducción fiel de esa lógica, pero no transforma automáticamente todos los umbrales en estándares clínicos oficiales.
3.3. Evaluación heurística orientada a objetivo
Precisión terminológica del sistema: el HealthDashDataBundle constituye el bundle fisiológico de entrada; los resultados numéricos de cada motor constituyen los scores técnicos; y el snapshot funcional representa la síntesis resultante de la consideración conjunta de los motores, su comparación técnica, la interpretación heurística, las recomendaciones y el prediagnóstico funcional.

Sobre el resultado técnico de cálculo, el sistema aplica una segunda capa de evaluación heurística destinada a determinar la dirección del estado, la magnitud del cambio, la alineación con el objetivo y el comportamiento de la pauta.

Esta lógica permite emitir decisiones operativas sobre la pauta, distinguiendo entre mantenimiento, ajuste, intensificación o sustitución, sin confundir la mera convergencia con el cumplimiento efectivo del objetivo.

El sistema dispone de persistencia técnica del cálculo y de persistencia heurística del resultado operativo actual. La primera se registra en HealthScoreHistory; la segunda, en HealthEvolutionSnapshot.

El cálculo histórico puede visualizarse como score técnico persistido o como reconstrucción histórica recalculada sobre datos fuente, manteniéndose el score técnico persistido como referencia principal de trazabilidad.

3.4. Especificación práctica del algoritmo
Especificación práctica del algoritmo

El algoritmo opera en ciclos de captura de contexto, importación, agregación, cálculo, evaluación heurística y persistencia.

FASE 0
Captura externa e importación masiva
Selección por el usuario de un fichero export.zip, subida web fragmentada por bloques, recomposición secuencial del ZIP en servidor, extracción controlada del export.xml y persistencia interna del XML resultante como fuente estable de lectura.
FASE 0 BIS
Reducción semanal, agregación diaria y normalización Biodata
A partir del export.xml ya persistido, el sistema genera un XML reducido por semana natural, reconstruye por fecha la información fisiológica relevante mediante lectura estructural en streaming y transforma el resultado en registros normalizados compatibles con BiodataDiaria.
FASE A
Contexto
Obtención de PerfilPersonal, selección de la ventana temporal configurada de BiodataDiaria y determinación de la AnaliticaClinica más próxima anterior o igual a la fecha de cálculo.
FASE B
Cálculo técnico
Cálculo de Score SNC, Score Metabólico y Score Bioenergético mediante motor técnico seleccionable.
FASE C
Recomendación inmediata
Generación de recomendaciones basadas en el estado funcional actual y en el cruce técnico entre scores y biomarcadores.
FASE D
Evaluación evolutiva y tendencias
Contraste entre histórico, pauta activa y objetivo para determinar dirección, alineación y decisión operativa, incorporando análisis longitudinal de variables directas de BiodataDiaria.
FASE E
Persistencia y trazabilidad
Persistencia del cálculo técnico en HealthScoreHistory, del resultado heurístico actual en HealthEvolutionSnapshot y del balance energético diario en EnergyDailyBalance.
ECUACIÓN CONCEPTUAL DE DESVIACIÓN FUNCIONAL
ΔEstado = |Objetivo - Real|
Expresión conceptual del diferencial entre el estado objetivo y el estado observado. Su traducción operativa se realiza mediante scores, histórico técnico y evaluación heurística orientada a objetivo.

En suma, el sistema analiza el estado actual del usuario, la dirección de su evolución y el comportamiento de la pauta, a fin de determinar si la intervención aplicada aproxima efectiva y progresivamente al objetivo funcional previsto.

3.5. Arquitectura de variables del algoritmo
Arquitectura de variables del algoritmo

El sistema distingue entre variables de latencia aguda y crónica. Aunque la base de datos admite un conjunto amplio de parámetros biométricos, clínicos y de perfil, el motor heurístico opera en su estado actual sobre un núcleo progresivamente auditado de variables esenciales, susceptible de ampliación o recalibración.

LATENCIA AGUDA Vectores dinámicos
  • TemperaturaCorporal: registro térmico basal.
  • HRV: equilibrio del sistema nervioso autónomo.
  • FrecuenciaCardiacaReposo: pulso basal y recuperación.
  • SueñoProfundoMinutos: reparación física.
  • SueñoRemMinutos: recuperación neurocognitiva.
  • Peso: masa corporal total.
  • PasosDiarios: movimiento NEAT.
  • LitrosAgua: hidratación registrada.
  • CaloriasConsumidas: ingesta energética diaria.
LATENCIA CRÓNICA Vectores estructurales
  • GlucosaAyunas: azúcar basal.
  • HemoglobinaGlicosilada: media glucémica de largo plazo.
  • Trigliceridos: grasas circulantes.
  • ColesterolHDL: fracción protectora.
  • ColesterolLDL: fracción aterogénica.
  • ProteinaCReactiva: inflamación de bajo grado.
  • Ferritina: almacén de hierro.
  • TSH: regulación tiroidea.
  • VitaminaD3: soporte inmunometabólico.
  • GGT / ALT: marcadores hepáticos.
  • Creatinina / FiltradoGlomerular: eficiencia renal.
  • CPK: daño muscular.
  • MagnesioSerico: regulador neuromuscular y metabólico.

4. Arquitectura de datos y lógica de negocio

El sistema se apoya en una arquitectura relacional y de servicios orientada a separar con claridad los datos fuente, la formación del bundle fisiológico de entrada, el cálculo técnico, la interpretación heurística y la persistencia del resultado.

Datos base: PerfilPersonal

Define el marco basal y estratégico del usuario. Dispone de CRUD completo.

  • Biometría basal: edad, sexo, altura y composición.
  • Contexto: profesión, clima, entorno y hábitos.
  • Dirección: objetivo principal del usuario.
Datos base: BiodataDiaria

Registra la evolución cotidiana del usuario. Dispone de CRUD completo.

  • Actividad: ejercicio, pasos, carga diaria.
  • Recuperación: HRV, sueño, fatiga, estrés.
  • Homeostasis: pulso, temperatura, SpO2, hidratación.
Datos base: AnaliticaClinica

Aporta validación bioquímica estructural. Dispone de CRUD completo.

  • Metabolismo: glucosa, HbA1c, lípidos.
  • Inflamación y reservas: ferritina, PCR, vitaminas.
  • Función orgánica: renal, hepática, endocrina.
Servicios funcionales principales
  • HealthDashDataService: construcción del bundle fisiológico de entrada a partir de perfil, biometría diaria y analítica clínica.
  • HealthImportController: orquestación MVC del proceso de importación, lectura semanal, generación de XML reducido y agregación posterior.
  • HealthImportPathService: resolución centralizada de rutas internas para export.xml, XML reducidos semanales y directorios temporales.
  • HealthScoreService: fachada central del cálculo técnico de scores.
  • HardcodedHealthScoreEngine: implementación operativa estable de referencia.
  • DeclarativeHealthScoreEngine: implementación basada en configuración dinámica de bloques, inputs y reglas.
  • HealthScoreModeResolver: resolución del motor activo en tiempo de ejecución.
  • HealthRecommendationService: recomendación inmediata basada en estado actual.
  • HealthScoreHistoryService: persistencia del score técnico del cálculo.
  • DeclarativeHistoryService: persistencia histórica específica del motor declarativo.
  • HealthScoreBackfillService: reconstrucción retrospectiva del histórico técnico.
  • BioDataEvolutionService / BioDataTrendAnalysisService: análisis de tendencias sobre variables persistidas en BiodataDiaria.
  • EnergyDailyBalanceService: cálculo y persistencia del balance energético diario, macronutrientes, proteína/kg, alcohol, gasto total y clasificación oficial del estado energético.
  • EnergyDailyBalanceQueryService: construcción de modelos de consulta y visualización del análisis metabólico diario.
  • EnergyExpenditureModelService: aplicación del modelo de ajuste de gasto basal y activo importado.
  • HealthTrendService: análisis y proyección de tendencia sobre histórico persistido.
  • HealthEvolutionService: evaluación evolutiva orientada a objetivo.
  • HealthEvolutionOrchestrator: coordinación del flujo heurístico completo.
  • PlanAdjustmentService: decisión sobre mantenimiento, ajuste, intensificación o sustitución de la pauta.
4.1. Subsistema de análisis de tendencias de BiodataDiaria

Junto al cálculo técnico de scores y a la evaluación heurística global, el sistema incorpora un subsistema específico de análisis de tendencias sobre la entidad BiodataDiaria, destinado a observar la dirección, estabilidad y magnitud del cambio de variables fisiológicas cotidianas.

Este subsistema opera sobre una ventana temporal seleccionable de registros diarios y permite obtener una lectura sintética de la evolución reciente de variables como peso, cintura, frecuencia cardiaca en reposo, HRV, sueño, distancia recorrida, pasos y energía activa.

Desde el punto de vista arquitectónico, este módulo constituye una capa analítica intermedia entre la persistencia diaria de biometría y la evaluación heurística global.

4.2. Subsistema de análisis metabólico diario y dinámica energética funcional

El sistema incorpora un subsistema específico de análisis energético-metabólico diario, destinado a interpretar la relación entre ingesta, gasto energético, distribución nutricional, proteína relativa al peso corporal, actividad física y balance energético final.

La fuente técnica principal de este subsistema es la entidad EnergyDailyBalance, generada a partir de BiodataDiaria y recalculada mediante servicios internos. Dicha entidad consolida la energía ingerida, el gasto basal ajustado, el gasto activo ajustado, el gasto total, el balance energético, los macronutrientes, el alcohol ingerido, la proteína por kilogramo de peso corporal y el estado energético resultante.

La clasificación oficial del estado energético se centraliza en EnergyDailyBalanceService.ResolveEnergyStatus, evitando que las vistas, prompts o módulos auxiliares reclasifiquen el balance mediante umbrales paralelos.

  • DeficitSevero: balance ≤ -900 kcal.
  • DeficitModerado: balance ≤ -450 kcal.
  • DeficitLigero: balance ≤ -150 kcal.
  • Equilibrado: balance < 150 kcal.
  • SuperavitModerado: balance ≤ 500 kcal.
  • SuperavitAlto: balance > 500 kcal.

Sobre esta base se articula el módulo de Análisis metabólico diario, que ofrece una lectura funcional del día evaluado: ingesta total, gasto estimado, balance calórico, distribución de hidratos, proteínas, grasas y alcohol, suficiencia proteica relativa y compatibilidad del patrón observado con preservación de masa magra o pérdida progresiva de grasa.

De forma complementaria, el módulo de Dinámica metabólica representa visualmente la evolución funcional del día mediante una curva por fases, integrando balance energético acumulado e índice relativo de disponibilidad energética. Este índice no constituye una magnitud física directa, sino una señal sintética orientativa que combina balance energético, proteína/kg, hidratos, grasas y alcohol.

Desde el punto de vista arquitectónico, ambos módulos forman una capa analítica específica dentro del sistema, conectada con BiodataDiaria y EnergyDailyBalance, pero separada del motor principal de scores.

Formación del bundle fisiológico de entrada y regla temporal de cálculo

La unidad efectiva de cálculo del sistema es el HealthDashDataBundle, integrado por: PerfilPersonal, una colección acotada de BiodataDiaria y una AnaliticaClinica seleccionada por proximidad temporal anterior o igual a la fecha de cálculo.

La selección de biometría diaria se realiza mediante una ventana temporal natural de N días, siendo N un parámetro configurable del sistema. Cuando N = 7, equivale a [ FechaCalculo − 6 , FechaCalculo ].

La regla temporal aplicada queda reflejada en histórico a través de los campos FechaBioInicio, FechaBioFin, NumeroRegistrosBioUsados y ReglaAplicada.

Arquitectura de importación masiva y persistencia interna del XML

El sistema incorpora una arquitectura específica para la ingestión de exportaciones XML de gran tamaño, basada en la subida de un fichero ZIP fragmentado en bloques.

Una vez reconstruido el ZIP, el sistema realiza una extracción controlada del contenido, localiza el export.xml válido y lo copia a la ubicación interna definitiva del usuario.

Subsistema de importación estructurada y generación automática de BiodataDiaria

La arquitectura actual incorpora un subsistema específico de ingestión documental, reducción estructural, agregación funcional y transformación normalizada de datos externos en registros persistentes de BiodataDiaria.

Una vez persistido el export.xml, la aplicación genera archivos reducidos por semana natural, construidos mediante lectura secuencial en streaming y filtrado selectivo de nodos relevantes.

Sobre dichos XML reducidos semanales actúa un motor de agregación diaria diseñado para reconstruir, por fecha, la información fisiológica relevante contenida en el documento.

Esta cadena captura documental → persistencia interna → reducción semanal → agregación diaria → normalización → persistencia en BiodataDiaria constituye un componente técnico propio del sistema.

Validación y tipado: los modelos emplean DataAnnotations, precisión decimal y restricciones de persistencia mediante Entity Framework Core y SQL Server.

5. Persistencia funcional del sistema

HealthScoreHistory

Snapshot técnico persistido del cálculo funcional.

  • FechaCalculo: fecha efectiva del cálculo.
  • FechaAnaliticaUsada: analítica clínica tomada como referencia temporal.
  • FechaBioInicio / FechaBioFin: ventana real de biometría diaria utilizada.
  • NumeroRegistrosBioUsados: número real de registros diarios incluidos.
  • ScoreSNC / ScoreMetabolico / ScoreBioenergetico: resultado técnico del cálculo.
  • ReglaAplicada: regla temporal y técnica declarada para el cálculo.
  • EdadEnFechaCalculo: edad computada para la fecha evaluada.
  • FactorFiabilidadAnalitica: corrector aplicado por antigüedad de la analítica.
HealthEvolutionSnapshot

Persistencia del resultado heurístico completo de la evaluación operativa vigente.

  • Objetivo y dirección.
  • Alineación de pauta.
  • Score ponderado objetivo.
  • Decisión de pauta.
  • Justificación y recomendación ajustada.
  • Origen de pauta y versión asociada.
UserActivePlan / UserActivePlanVersion

Persistencia real de la pauta activa y de sus versiones.

Permite trazabilidad histórica y vinculación del snapshot heurístico con una versión concreta de pauta.

EnergyDailyBalance

Persistencia diaria del balance energético y nutricional calculado por el sistema.

  • Ingesta: energía total ingerida y macronutrientes.
  • Gasto: energía basal ajustada, energía activa ajustada y gasto total.
  • Balance: diferencia entre ingesta y gasto total.
  • Proteína/kg: indicador funcional de suficiencia proteica.
  • Alcohol: integración energética y moduladora del día.
  • EstadoEnergetico: clasificación oficial centralizada del balance diario.
  • ReglaAplicada: versión del modelo de gasto energético utilizado.
HealthScoreMasterParameters y modelo declarativo

Catálogo maestro técnico y estructura declarativa para la configuración progresiva del motor de cálculo.

Comprende parámetros scoreables, bloques, inputs, modelos y futuras reglas o modificadores.

Persistencia interna del import XML

El sistema conserva internamente una copia funcional del export.xml del usuario como fuente estable de lectura.

  • Origen: ZIP externo subido por bloques y recombinado en servidor.
  • Destino: ruta interna persistente por usuario.
  • Función: lectura completa, generación de reducidos semanales y reutilización funcional posterior.
HealthScoreDeclarativeHistory

Persistencia técnica específica del motor declarativo.

  • Scores persistidos: SNC, Metabólico y Bioenergético.
  • Contexto temporal: fecha de cálculo, analítica usada y ventana biométrica aplicada.
  • Modelo persistido: serialización JSON completa del estado declarativo efectivo.
  • Integridad: hash SHA-256 del modelo declarativo utilizado.
  • Trazabilidad: versión del modelo, origen de configuración y existencia de parámetros de usuario.
Regla operativa vigente: el sistema distingue entre score técnico persistido, reconstrucción histórica recalculada, evaluación heurística vigente y balance energético diario persistido. Cada uno de estos planos cumple una función distinta dentro de la trazabilidad funcional del sistema.

7. Instrucciones y logística funcional

Pautas de suministro de datos, uso operativo y explotación funcional del sistema.

01Entrada: Perfil Personal

Datos básicos de marco: biometría basal, contexto personal, hábitos y objetivo funcional.

02Seguimiento diario

Registro manual o importación estructurada de biometría diaria y datos históricos de salud.

03Lectura semanal reducida

Generación de reducidos semanales, agregación diaria y transformación a BiodataDiaria.

04Verificación: Analítica Clínica

Registro analítico para auditoría de recomendaciones, trazabilidad temporal y confirmación bioquímica.

9. Notas sobre el método heurístico de ensayo y ajuste progresivo

El término heurístico se emplea para designar un enfoque de decisión apoyado en reglas prácticas, comparación temporal y ajuste progresivo, sin pretensión de sustituir el juicio clínico.

El sistema observa resultados, detecta desviaciones, compara tendencias y reajusta recomendaciones en función del comportamiento real de las variables biométricas y clínicas.

12. Estado de protección y derechos de autor

Estado registral: Obra software en trámite de inscripción en el Registro de la Propiedad Intelectual.

Derechos de autor:
© 2026 Ricardo M. Trigo Calonge.
Todos los derechos reservados.

Queda prohibida la reproducción, distribución, comunicación pública o transformación, total o parcial, del código fuente, modelos estructurales, arquitectura software, algoritmos, lógica funcional y documentación técnica asociada, sin autorización expresa del titular.

Índice