# LRU_FUNDAMENTOS > Fichero: `LRU_FUNDAMENTOS.md` · documento vivo sin sufijo de sesión > Ubicación canónica: `public/docs-app/v1/doc/LRU_FUNDAMENTOS.md` > Origen: sesión s57 · 2026-04-18 · Manuel & Claude Opus 4.7 > Actualizado: sesión s68 · 2026-04-20 · integración de Postulados 1, 2 y 3 del destilado s67 > Actualizado: sesión s70 · 2026-04-21 · integración de Postulados 6, 7 y 8 del destilado s69 > Actualizado: sesión s76 · 2026-04-22 · integración del destilado principal s71 (`lru_estructuras_subyacentes_s71.md`) y piezas específicas del addendum s69 (`lru_postulados_6_7_8_9_addendum_s69.md`) — nuevas subsecciones **§6.7 El nivel 0 físico como sustrato epistémico**, **§8.5 Las máquinas de estados como sintaxis del enlatado**, **§11bis Pluralidad de inteligencias coexistiendo** (con subsección final **§11bis.5 · Las dos clases de inteligencia enlatada y el papel de los casos**). Bloques 3 + 4 de la integración E.2. > Actualizado: sesión s89 · 2026-04-25 · integración de T-S85-F1 desde el destilado `lru_atachapterdef_refactor_s85.md §2 + §10` — nueva sección **§11ter Pluralidad de realms coexistiendo sobre base común** con 4 subsecciones (base agnóstico y realms específicos · implicaciones arquitecturales · refinamiento del Postulado 5 · paralelo estructural con §11bis). Quinta cristalización fundacional del proyecto. Inserción sin renumeración. > Actualizado: sesión s123 · 2026-05-05 · integración de T-S117-F1 desde el destilado `lru_postulado_12_hardware_fisico_sustrato_s117.md` — nueva sección **§11sexies El hardware físico como sustrato del sistema** (Postulado 12) con 7 subsecciones (texto canónico §11sexies.0 + dos citas literales de Manuel s53 §11sexies.1 + tres encarnaciones físicas §11sexies.2 + arquitectura común puerto≠canal/RouterService/cadena transducción §11sexies.3 + laboratorio real/virtual de señales §11sexies.4 + refinamiento de postulados existentes §11sexies.5 + implicaciones para sesiones futuras §11sexies.6). **Séptima cristalización fundacional del proyecto culminada** — los 12 postulados P1-P12 quedan ahora todos integrados al núcleo. Inserción sin renumeración honrando el cluster mental §11/§11bis/§11ter/§11quater/§11quinquies/§11sexies. Tras 5 aplazamientos consecutivos (s118-s122) la integración cierra T-S117-F1 + T-S119-1. > Propósito: articular el marco conceptual del sistema — de qué está hecho, qué operaciones soporta, cómo se encarna > Documentos hermanos del núcleo: `LRU_MISION`, `LRU_ARQUITECTURA`, `LRU_MAPA`, `LRU_METODO` > **Nota s68 (2026-04-20)**: los Postulados 1, 2 y 3 articulados en el destilado `lru_postulados_fundacionales_s67.md` quedan integrados en este documento como secciones propias: **§7 El bucle perceptor-inteligencia-efector** (Postulado 1 — era §6 hasta s70), **§8 Las guías estructuradas** (Postulado 2 — era §7 hasta s70), **§9 Los actores en tres niveles** (Postulado 3 — era §8 hasta s70). Las secciones renumeradas en s68 (§9-§12) se han renumerado de nuevo en s70 (§12-§15) por la integración de las nuevas §§6, §10, §11. La integración s68 preservó la voz del núcleo cristalizada en s57 — las 5 primitivas §2, la Vista de Actor §3, las 4 operaciones §4, la sesión multipistas §5 siguen siendo válidas. Los Postulados 4 (darwinismo digital) y 5 (aeronáutico como primer realm) viven integrados en `LRU_MISION`. El destilado s67 se preserva como fuente autoritativa original con citas textuales de Manuel y argumentación densa. > **Nota s70 (2026-04-21)**: los Postulados 6, 7 y 8 (plano fundacional) articulados en el destilado `lru_postulados_6_7_8_9_s69.md` quedan integrados en este documento. **§6 La realimentación como estructura causal universal** (Postulado 6 — fundacional de primer orden, ubicado deliberadamente antes del bucle de §7 para que sirva de lente sobre §§7-9 y §§12-15). **§10 Los casos reales documentados como material didáctico de primera clase** (Postulado 7). **§11 La jugabilidad como propiedad estructural del sistema** (Postulado 8 — plano fundacional; el plano de uso vive en `LRU_MISION`). El Postulado 9 (continuidad simulación-control real) vive integrado en `LRU_MISION`. La disciplina ética operativa derivada del §2.8 del Postulado 7 vive integrada en `LRU_METODO`. El destilado s69 se preserva como fuente autoritativa original con citas textuales de Manuel. > **Nota s76 (2026-04-22)**: material del destilado principal s71 (`lru_estructuras_subyacentes_s71.md`) y piezas específicas del addendum s69 (`lru_postulados_6_7_8_9_addendum_s69.md`) integrados como cuatro piezas. > **§6.7 El nivel 0 físico como sustrato epistémico** articula dentro del Postulado 6 el sustrato material sobre el que la realimentación universal opera — las leyes de la naturaleza ejecutándose sin agente decisional, el *"estado de la ciencia interconectado aquí y ahora"* de Manuel s71. Da fundamento técnico explícito al Postulado 9 (continuidad sim-control real) y criterio objetivo de fidelidad. > **§8.5 Las máquinas de estados como sintaxis del enlatado** articula dentro del Postulado 2 (guías estructuradas) el formato técnico privilegiado para condensar inteligencia viva en algo conservable — estados + transiciones + condiciones. Explica asimetría de encaje con los postulados y frontera continuo/discreto como frontera enlatado/vivo. Candidata de primera clase para `GuideDef` en Realm v3. > **§11bis Pluralidad de inteligencias coexistiendo** articula la corrección de Manuel en s71 a la dicotomía previa del addendum s69 (*"dos inteligencias coexistiendo o muchas más"*): enumeración no cerrada de al menos diez clases con propiedades distintas, más la distinción estructural entidades funcionales vs entidades declarativas como candidata de primera clase para el schema Realm v3 (T-S67-A1). > **§11bis.5 Las dos clases de inteligencia enlatada y el papel de los casos** articula la distinción física/normativa del enlatado y la observación potente de que los accidentes producen actualizaciones del corpus normativo y casi nunca del corpus físico — asimetría del darwinismo digital. > Piezas del addendum s69 preservadas en destilado y no integradas al núcleo por decisión pieza-por-pieza de T-S74-A8: §4.5 *"latas no neutras"* (ética de valores en guías, semilla para sesión específica futura); §7 *"linaje cultural"* (articulación filosófica disponible cuando el proyecto necesite situarse en tradición intelectual). > No se renumera — se usan §6.7, §8.5, §11bis y §11bis.5 para preservar punteros cruzados del MAPA. Bloques 3 + 4 de la integración E.2. Cerró T-S71-A1 y T-S74-A8. Los destilados s71 y s69-addendum se preservan como fuentes autoritativas originales. > **Nota s89 (2026-04-25)**: integración de T-S85-F1 desde el destilado `lru_atachapterdef_refactor_s85.md §2 + §10` (cristalización fundacional emergente en s85 durante el debate agnosticidad/especificidad sobre `ATAChapterDef`). Nueva sección **§11ter Pluralidad de realms coexistiendo sobre base común** con 4 subsecciones articulando la arquitectura **base agnóstico + N realms específicos** ya materializada arquitectónicamente en s86 con `src/realm/aviation/` como primer realm específico. Las dos citas literales de Manuel s85 preservadas como gold del proyecto en la apertura de §11ter. Refinamiento del Postulado 5 absorbido en §11ter.3 (no se toca `LRU_MISION` en s89). Paralelismo estructural directo con §11bis ("Pluralidad de inteligencias coexistiendo") nombrado en §11ter.4 — el patrón "N sobre sustrato común" aplicado a dos ejes ortogonales del proyecto. Inserción sin renumeración. Quinta cristalización fundacional del proyecto culminada (tras s67 P1-P5, s69 P6-P9, s74 voz fundacional, s76 pluralidad de inteligencias, s89 pluralidad de realms). Cerró T-S85-F1. > **Nota s91 (2026-04-25)**: integración de T-S84-F1 desde el destilado `lru_postulado_10_diseno_como_innovacion_s84.md` (cuarta cristalización fundacional · cristalizada en s84 · única cristalización fundacional pendiente tras s89). Nueva sección **§11quater El diseño del Realm como espacio de innovación dentro del respeto** con 7 subsecciones (texto canónico §11quater.0 + articulación literal de Manuel §11quater.1 + distinciones P10 vs P8/P9/P5 §11quater.2 + materializaciones concretas en el schema §11quater.3 + hilos transversales como ejercicio metodológico §11quater.4 + relación con principio 11 implícito de ARQUITECTURA §11quater.5 + implicaciones para sesiones futuras §11quater.6). Las dos citas literales de Manuel s84 preservadas como gold del proyecto en §11quater.1. **Postulado preoperativo a P8** integrado como §11quater honrando el cluster mental "plano fundacional de P8 + sus variantes estructurales" (§11/§11bis/§11ter/§11quater). Inserción sin renumeración. Regla operativa derivada articulada en `LRU_METODO §6bis` nueva. Anotación complementaria (no absorción) en `LRU_ARQUITECTURA §8` sobre el principio 11 implícito que sigue pendiente como dimensión arquitectural propia. `LRU_MISION` no se toca por decisión explícita (replica disciplina s89): P10 vive en FUNDAMENTOS por naturaleza y en METODO por consecuencia operativa. **Octava aplicación del patrón "destilado fundacional → integración al núcleo"** tras s68/s70/s76/s89. **Cuarta cristalización fundacional culminada** — los 10 postulados P1-P10 quedan ahora todos integrados al núcleo. Ninguna cristalización fundacional pendiente al cierre de s91. Cerró T-S84-F1. > **Nota s123 (2026-05-05)**: integración de T-S117-F1 desde el destilado `lru_postulado_12_hardware_fisico_sustrato_s117.md` (séptima cristalización fundacional · cristalizada en s117 · aplazada 5 sesiones consecutivas s118-s122 por priorización de código de producto y validación de capacidades MCP). Nueva sección **§11sexies El hardware físico como sustrato del sistema** con 7 subsecciones (texto canónico §11sexies.0 + dos citas literales de Manuel s53 §11sexies.1 — cita fundacional sobre dispositivos intercambiables y cita gold sobre concepto twin — + tres encarnaciones físicas con propiedades estructurales propias §11sexies.2 + arquitectura común puerto≠canal/RouterService/cadena de transducción §11sexies.3 + laboratorio real/virtual de señales como articulación canónica §11sexies.4 + refinamiento de 7 postulados existentes sin invalidación §11sexies.5 + implicaciones para sesiones futuras + frente hwObj productor §11sexies.6). Las dos citas literales de Manuel s53 preservadas como gold del proyecto en §11sexies.1. **Postulado transversal** integrado como §11sexies honrando el cluster mental "plano fundacional de P8 + sus variantes estructurales" (§11/§11bis/§11ter/§11quater/§11quinquies/§11sexies). Inserción sin renumeración. P12 **no genera regla operativa propia en `LRU_METODO`** (a diferencia de P10/§6bis y P11/§6ter) porque articula propiedad estructural del sustrato, no disciplina sobre cómo se construye el Realm — replica el patrón de §11ter (pluralidad de realms). Anotación complementaria (no absorción) en `LRU_ARQUITECTURA §8` sobre la Capa 0 del hardware como sustrato formalizado. `LRU_MISION` no se toca por decisión explícita (replica disciplina s89/s91). **Octava aplicación del patrón "destilado fundacional → integración al núcleo"** tras s68/s70/s76/s89/s91/s99. **Séptima cristalización fundacional culminada** — los 12 postulados P1-P12 quedan ahora todos integrados al núcleo. Ninguna cristalización fundacional pendiente al cierre de s123. Cerró T-S117-F1 + T-S119-1 (herencia activa). El destilado fuente `lru_postulado_12_hardware_fisico_sustrato_s117.md` (913 líneas, 11 citas verbatim, 11 sitios arqueológicos cruzados) pasa a referencia histórica post-integración. --- ## Qué es este documento `LRU_MISION` declara **para qué** existe el proyecto. `LRU_ARQUITECTURA` describe **cómo está construido** hoy. `LRU_FUNDAMENTOS` articula **de qué está hecho** el sistema — las piezas conceptuales sobre las que toda la arquitectura se apoya, y que seguirán siendo válidas aunque la arquitectura concreta evolucione. No es especulación filosófica. Es **el vocabulario con el que el proyecto piensa sobre sí mismo**. Cuando aparece una duda de diseño, este documento ofrece las distinciones base para razonarla. Cuando llega un Claude o un colaborador nuevo, este documento le da el marco para entender cualquier otra parte del proyecto. El marco ha emergido a lo largo de muchas sesiones de trabajo arquitectural. Su estabilidad viene de que **ya estaba operando implícitamente** en las decisiones tomadas: lo que hacemos aquí es nombrar lo que ya era. Por eso no es ornamento: es reconocimiento. --- ## 1 · El sistema como sistema operativo de señales La idea central es simple y tiene consecuencias profundas: **el LRU Platform es un sistema operativo de señales**. No es un simulador de aviones, ni una plataforma de formación, ni un sistema de telemetría, ni un laboratorio de instrumentos. Es algo más fundamental que todo eso: **la infraestructura genérica sobre la que cualquier realidad observable mediante señales puede ser compartida, orquestada y comprendida entre múltiples actores humanos y no humanos, con independencia del dominio, de la ubicación física, y del origen real o virtual de los datos**. Los casos de uso — formación aeronáutica, simulación A320, mantenimiento, investigación, fabricación, certificación, domótica, industrial, médico — son **aplicaciones** de esta infraestructura. No son su propósito. Son consecuencias de lo que la infraestructura permite. Como sistema operativo, la plataforma gestiona un conjunto pequeño de primitivas y ofrece un conjunto pequeño de operaciones sobre ellas. Las secciones siguientes articulan unas y otras. --- ## 2 · Las cinco primitivas El sistema tiene cinco primitivas. Cuatro son **materiales** (qué cosas hay) y una es **sustrato** (sobre qué se despliegan las cosas). Todas son necesarias para describir cualquier situación del sistema. ### 2.1 · Señal Una **señal** es una magnitud identificable con significado en un dominio. Es el ladrillo atómico del sistema. Una señal tiene identidad (`sensorId` en formato `{fuente}/{puerto}`), magnitud física (temperatura, presión, velocidad...), unidad primaria y rango, dirección (observable / actuable / bidireccional), contrato de unidades (cómo convertir), y contrato de transporte (cómo codifica en cada protocolo). Estas son sus **propiedades intrínsecas** — viven en el Realm que la declara. Tiene además propiedades **contingentes** que solo existen en runtime: origen (Loc / Rnd / HwSim / HwReal según RouterMode), calidad (válida / sospechosa / muerta / sintética), y posición temporal (vivo en el DataPlane, histórico en una grabación, programado en un escenario). Las señales son **el vocabulario del dominio**. Un A320 es un conjunto coherente de señales (N1, EGT, altitud, velocidad vertical, presión hidráulica...). Un termostato es otro conjunto. Un cuerpo humano es otro. Cuando decimos *"el Realm es el resto del mundo que le falta al actor"*, lo que queremos decir es: el Realm es el vocabulario completo de señales de ese mundo, disponible para quienes se conectan a él. Una señal **no sabe de dónde viene**. No sabe a dónde va. No sabe si alguien la está escuchando. Solo **es**: tiene propiedades declaradas y un valor vivo. El resto del sistema opera sobre ella sin necesidad de saber más. ### 2.2 · Conexión Una **conexión** es el tejido por el que las señales viajan entre lugares del sistema. Llamarla "comunicación" sería parcial. Una conexión es más que un canal: es la relación establecida entre dos puntos por la que una señal viaja respetando un contrato de protocolo. Las conexiones tienen propiedades que las señales no tienen: latencia, ancho de banda, probabilidad de pérdida, orden de entrega, autenticación. Las conexiones atraviesan **fronteras** — F1 in-memory, F2 inter-tab, F3 red, F4 hardware, F5 sesión↔sesión. Obedecen **protocolos** — ARINC 429, MIL-STD-1553, MQTT, BLE, WebSocket, serial, STOMP, AMQP. Cada protocolo es un contrato estable: una vez que dos partes acuerdan hablar ARINC 429, lo que viaja entre ellas es auditable, reproducible y comprensible sin ambigüedad. Las conexiones son visibles. El sistema **no las esconde**. A través de `Analyzer1`, cualquier actor autorizado puede ver qué está viajando por los cables, con decodificación bit a bit cuando corresponda. Esto es principio, no accidente: las conexiones son una primitiva del sistema, y toda primitiva merece ser inspeccionable. Un Realm maduro no solo declara qué señales existen — declara también **qué protocolos son legítimos para cada señal**. Un EGT en un A320 puede viajar por ARINC 429 label 211 BNR 19 bits, por MQTT como JSON, o por ADC 12-bit. Todas son encarnaciones válidas de la misma señal. El Realm declara este menú de contratos aceptables, y `Analyzer1` verifica que las conexiones reales respetan el menú. ### 2.3 · Actor Un **actor** es cualquier entidad que participa en el sistema aportando o consumiendo señales. Hay cuatro tipos de actor: * **Humano con dispositivo** — alumno con teléfono, instructor en pantalla grande, fabricante con pieza real en su banco, técnico diagnosticando un sistema. * **Dispositivo físico autónomo** — ESP32 con firmware, LRU real, ADIRU, PLC industrial, wearable. * **Proceso de software** — `SimService` generando datos, `SimSequencePlayer` reproduciendo una grabación, futuro bridge hacia MSFS o X-Plane. * **Observador pasivo** — grabadora FDR, monitor remoto, viewer de Debug1. Cada actor tiene: * **Identidad** — quién es. Puede ser `sessionId`, `deviceId`, `userId`, `role` según corresponda. * **Capacidades** — qué puede aportar o consumir. Este teléfono tiene IMU pero no GPS. Este ESP32 tiene 5 ADC. Este humano tiene rol instructor. Estas capacidades son parte de la semántica del actor, no solo metadata. * **Presencia** — cuándo está conectado. Algunos actores son permanentes (`SimService` siempre está vivo mientras la sesión lo está). Otros son efímeros (un alumno entra a una sesión formativa y se va cuando termina). * **Autoría** — lo que el actor hace queda registrable y atribuible. Un fallo inyectado por un instructor queda marcado como suyo. Un valor que llega de un hardware real queda marcado como proveniente de ese hardware concreto. Sin autoría no hay evaluación formativa ni trazabilidad operativa. Los actores **no viven en el Realm**. El Realm describe qué señales existen en el dominio. Los actores viven en runtime, y la relación actor↔señal se establece en la **mesa de parcheo** (`EnlacesPanel` y sus escenarios). Esta distinción es importante: preserva la separación entre descripción del dominio y encarnación concreta en una sesión de uso. ### 2.4 · Escenario Un **escenario** es un contexto temporal que da sentido a la actividad de los actores sobre las señales. Un escenario completo contiene: * Una **fase inicial** — condiciones del sistema al empezar. En un A320: "en crucero FL350, motor caliente, Mach 0.78, piloto automático activo". * Una **timeline de eventos** esperados o posibles. En t=30 s ocurre cambio de régimen. En t entre 60 y 120 s se puede inyectar un fallo eléctrico. * **Fallos disponibles** — qué puede salir mal en este escenario. Pérdida de generador, flame-out, despresurización. * **Overrides disponibles** — qué puede modificar el instructor en tiempo real sin romper la coherencia. * **Expectativas** — qué debe ocurrir según procedimiento. La altitud esperada en cada punto de la timeline, la reacción correcta del piloto a cada fallo. Estas expectativas son la partitura contra la que se puede evaluar formativamente. * **Narrativa** — el para qué del escenario. Qué se entrena, qué se prueba, qué se diagnostica. El escenario es lo que conecta las señales (primitiva 1) con los actores (primitiva 3) a lo largo del tiempo. Es donde la orquesta **toca una pieza concreta** en lugar de improvisar. Un escenario puede vivir dentro del Realm del dominio (el A320 lleva consigo sus escenarios típicos: engine surge, bus transfer, GPWS caution). O puede vivir como pieza compartida entre dominios compatibles: un escenario "falla eléctrica progresiva" puede funcionar en A320, B737 o C172 con pequeños ajustes. El schema Realm v2 (desplegado en s56) soporta ambas modalidades. ### 2.5 · Tiempo El **tiempo** es el sustrato sobre el que las demás primitivas se despliegan. No lo ponemos al mismo nivel que las cuatro anteriores. Está debajo de todas. Una señal sin tiempo es un tipo, no un valor. Un actor sin tiempo no actúa. Un escenario sin tiempo es un fichero, no una partitura. Las conexiones sin tiempo no transportan, solo existen como posibilidad. El sistema maneja **tres tiempos distintos**: * **Tiempo vivo** — lo que está pasando ahora. El `DataPlane` contiene el estado actual. Los actores producen y consumen valores a 60fps. La orquesta está tocando. * **Tiempo grabado** — lo que pasó, preservado en una sesión multipistas. Se puede reproducir, navegar, inspeccionar, mezclar. La orquesta ha tocado y queda accesible. * **Tiempo programado** — lo que va a pasar según la partitura de un escenario. Las expectativas declaradas. La orquesta va a tocar. Los tres tiempos **coexisten** en operación. Una sesión formativa puede tener pistas en vivo del alumno interviniendo ahora, pistas grabadas de un vuelo real del FDR importado, y pistas programadas por el escenario que marcan las expectativas. El motor del sistema orquesta los tres como si fueran uno — el alumno no nota diferencia entre ellos. Para él es "la realidad sobre la que opera". El tiempo como sustrato tiene consecuencias prácticas importantes. La evaluación formativa es fundamentalmente temporal ("el alumno reaccionó 8 segundos tarde", "la desviación acumulada fue de 12 ft rms"). La navegación de una sesión grabada ofrece pausa, retroceso, velocidad variable, salto a marker, loop sobre región. El replay mezclado permite usar grabaciones reales como base sobre la que los actores tocan su parte. --- ## 3 · La Vista de Actor Las cinco primitivas son los materiales. La **Vista de Actor** es la operación que las hace reales para alguien. ### 3.1 · Qué es una vista Una **vista de actor** — también llamada **workspace** — es la configuración completa que un actor activa al entrar al sistema. Es la intersección dinámica de: * Qué Realms tiene cargados — el vocabulario del mundo al que se conecta * Qué señales ve — un subset posiblemente reducido del Realm * Qué señales puede aportar — qué producir al sistema * Qué intervenciones tiene permitidas — fallos que puede inyectar, overrides que puede aplicar, escenarios que puede lanzar * Qué otros actores percibe — presencia de quién más está en la sala * Qué escenario está viviendo — la partitura activa * Qué tiempo está habitando — vivo, grabado o programado * Qué representación visual se le ofrece La vista es **dinámica**. Cambia cuando el instructor inyecta un fallo (algo nuevo aparece), cuando un alumno se conecta (un actor nuevo se hace visible), cuando el escenario avanza de fase. La vista es **personal**. Dos actores en la misma sesión pueden tener vistas radicalmente distintas del mismo momento del sistema. Un instructor ve toda la orquesta; un alumno de combustible ve solo su parte más el contexto mínimo. ### 3.2 · Cómo compone las cinco primitivas La vista no es una sexta primitiva. Es **la primitiva operativa** — la que materializa las otras cinco para un actor concreto. Es donde el sistema se vuelve real para un humano o un programa. La metáfora es la del **plato cocinado**. Puedes hablar de harina, agua, sal y levadura como primitivas del pan. Pero "el pan" — el plato en la mesa — es lo que alguien come. El plato no es un quinto ingrediente; es **el producto de la composición** en un momento concreto. La vista es así: compone señales, conexiones, actor, escenario y tiempo en una experiencia. ### 3.3 · Las vistas que ya existen implícitamente Hoy el proyecto tiene varias vistas operando aunque no se llamen así: * **Sim1** — la vista típica del instructor. Panel completo, todos los instrumentos visibles, EnlacesPanel accesible, Signal Lab disponible, capacidad de inyectar fallos. * **Col4** — la vista del alumno en formación tradicional. Ve instrumentos, interactúa con ellos, tiene menos controles que Sim1. * **Debug1** — la vista del operador remoto. Observa el DataPlane, inyecta comandos, graba y reproduce. * **Analyzer1** — la vista del analizador de protocolos. Ve las conexiones en bruto, decodifica frames. * **EnlacesPanel** (con sus escenarios guardados) — vistas de cableado guardadas, que el usuario puede activar para cambiar cómo las señales están conectadas. Lo que hasta ahora se trataba como "productos distintos" son **templates de vista** con diferentes valores en las dimensiones del workspace. Esta articulación elimina la necesidad de inventar productos nuevos para cada necesidad: basta con un template de vista adecuado. ### 3.4 · Horizonte implícito — el motor de vistas Si la vista es la primitiva operativa, el proyecto pedirá tarde o temprano un **motor de vistas** unificado: un componente que, dado un descriptor de vista (qué Realms, qué subset de señales, qué permisos, qué escenario, qué presentación), genere la experiencia completa para el actor. Hoy Sim1, Col4, Debug1 y EnlacesPanel componen las primitivas a mano, cada uno con su lógica. Funciona, pero está por debajo de la abstracción que el proyecto ya pide. Cuando haya 10 tipos de actores distintos y 50 vistas guardadas, sin motor de vistas el sistema será inmanejable. No es trabajo para una sesión concreta. Es **dirección natural** del proyecto. Este documento lo nombra para que cuando llegue su momento, el camino ya esté dibujado. --- ## 4 · Las cuatro operaciones Sobre las primitivas, el sistema soporta un número finito de operaciones. Todo lo que el sistema puede hacer se reduce a combinaciones de estas cuatro. | Operación | Qué hace | Dónde se implementa hoy | |---|---|---| | **DECLARAR** | Un Realm declara el vocabulario de señales y los escenarios posibles del dominio | `src/realm/` — schema Realm v2 desplegado en s56 | | **CONECTAR** | Un actor se conecta al sistema aportando o consumiendo señales concretas por un protocolo | `EnlacesPanel` + `CommsManager` con sus adaptadores | | **OBSERVAR** | Cualquier actor autorizado ve el estado actual de cualquier señal accesible | `DataPlane` (runtime) + `Sim1` (UI) + `Debug1` (subsistema) + `Analyzer1` (conexiones) | | **INTERVENIR** | Un actor autorizado cambia el estado de una señal — override, fallo, cambio de escenario | `SimService` + `ControlBus` (arbitra permisos) | Esta reducción es lo que hace al sistema un sistema operativo. Un usuario — humano o programa — no necesita saber de aviones para operar: necesita saber qué Realms hay declarados, cómo conectar, qué puede observar, qué puede intervenir. Un ejemplo concreto con las cuatro operaciones en una sesión A320: * El Realm A320 **declara** 187 señales típicas (sensores de motor, actitud, navegación, sistemas) con sus quantities, protocolos y escenarios disponibles. * Un instructor con pantalla grande **conecta** su Sim1 al Realm. Tres alumnos con teléfonos **conectan** sus apps. Un ESP32 real **conecta** por MQTT aportando valores reales de temperatura. * Todos **observan** sus subsets de señales. El instructor ve la orquesta completa. Los alumnos ven sus partes. El Analyzer1 ve el tráfico ARINC sintético entre componentes. * El instructor **interviene** cambiando de fase de escenario (de crucero a approach). Inyecta un fallo progresivo en el motor 2. Los alumnos **intervienen** ajustando sliders de su parte. El ControlBus arbitra las escrituras para que no haya conflictos. Esta reducción a cuatro operaciones es el **API conceptual** del sistema. El resto son detalles. --- ## 5 · La sesión multipistas como objeto temporal El tiempo grabado (primitiva 2.5) se materializa en un objeto de primera clase que el proyecto llama **sesión**. La sesión no es simplemente un log — es la **totalidad de lo que ocurrió** en el sistema durante un intervalo, capturado para que se pueda reproducir, inspeccionar, editar no destructivamente, mezclar y evaluar. ### 5.1 · Por qué la metáfora es la mesa multipistas profesional La metáfora de una DAW (Digital Audio Workstation) profesional es precisa, no aproximada. Una sesión profesional de grabación musical tiene exactamente las propiedades que necesitamos: * **Pistas independientes** con su propia frecuencia natural, alineadas sobre un eje de tiempo común. * **Edición no destructiva** — la grabación original no se altera; los cambios son operaciones superpuestas. * **Bouncing de pistas derivadas** — se calculan a partir de otras pistas. * **Marcadores, regiones y loops** sobre el timeline. * **Reproducción flexible** — pausa, velocidad variable, salto, scrubbing. * **Mezcla** — se pueden combinar pistas de orígenes diferentes respetando el eje temporal. Todo esto aplica a una sesión del sistema sin forzarlo. ### 5.2 · Los ocho tipos de pista Una sesión contiene múltiples tipos de pista independientes: | Pista | Contenido | Alimenta al reproducir | |---|---|---| | **data** | Señales numéricas — valores de sensores y actuadores | DataPlane — los instrumentos se mueven | | **protocol** | Frames reales — ARINC words, MQTT msgs, BLE bursts | CommsManager — Analyzer1 los procesa como si fueran en vivo | | **event** | Fallos inyectados, transiciones de escenario, cambios de router | SimService + RouterService | | **effect** | Intervenciones del Signal Lab y del instructor con parámetros | SimService — reproduce la intervención, no solo el resultado | | **annotation** | Marcas, notas de texto, ratings de evaluación | UI de revisión | | **media** | Audio del instructor, video de cámara, PiP | Web Audio + contenedor multimedia | | **actor** | Presencia y acciones de cada actor a lo largo del tiempo | Registro de quién hizo qué cuándo | | **derived** | Pistas calculadas a partir de otras pistas | Evaluación formativa automática | Las **pistas derivadas** son el superpoder del modelo. No se graban — se **calculan en tiempo de edición** a partir de otras pistas. Ejemplos: * `tiempo_reaccion_alumno` = t(acción correctiva) − t(fault_injected) * `desviacion_perfil` = ALT_real − ALT_esperada_del_escenario * `correlacion_N1_EGT` = cross-correlation entre dos pistas de datos * `score_aproximacion` = función compleja de múltiples pistas Las pistas derivadas son **no destructivas y extensibles**. Se puede añadir una pista derivada nueva a una grabación de hace seis meses, y el sistema la calcula al reproducir. Esto convierte la sesión grabada en **instrumento de evaluación** — no solo muestra qué pasó, sino que permite medirlo contra expectativas. ### 5.3 · Los cuatro modos de reproducción La misma sesión grabada puede reproducirse en modos distintos según el objetivo: * **REPLAY_SIM** — reproduce los valores al DataPlane. Los instrumentos se mueven como si fuera en vivo. Uso: el alumno revive la situación con los instrumentos reales. * **REPLAY_COMMS** — reproduce las tramas nativas (ARINC words, MQTT msgs) al sistema de comunicaciones. El Analyzer1 las procesa como si llegaran del hardware. Uso: formación en protocolos, diagnóstico de tramas. * **REPLAY_ANALYSIS** — reproduce el path completo de cada dato (desde origen hasta instrumento). Pausar, retroceder, inspeccionar cada transformación. Uso: análisis post-vuelo, debriefing forense. * **REPLAY_MIXED** — mezcla grabación con simulación en vivo. Los motores vienen de un FDR real grabado; la navegación la aporta SimService. Uso: entrenamiento con datos reales, contexto histórico. El **MIXED** es el modo que conecta con lo más ambicioso del sistema. Una grabación de un vuelo real puede servir de *backing track* sobre el que un alumno toca su parte. Un fabricante puede probar su motor real contra una grabación de vuelo de cliente. El mezclador es parte del motor del sistema, no una aplicación separada. ### 5.4 · Navegación temporal La reproducción no es lineal. El motor de sesión soporta: * Pausa y resume * Retroceso a cualquier instante * Velocidad variable (0.1x a 10x; más allá requiere interpolación fina) * Salto a marker ("ir al momento del fallo") * Loop sobre región (repetir el approach tres veces para practicar) * Scrubbing frame a frame * Sincronización a evento ("ir al momento donde EGT cruzó 900°C") Esta navegación es idéntica en vivo y en replay, salvo el retroceso, que solo existe en replay. **El vivo y el replay no son modos distintos del sistema** — son dos puntos sobre un continuo temporal donde el sistema puede estar leyendo. Lo que cambia es el origen de las pistas (buffer vivo vs log persistente) y la disponibilidad de retroceso. ### 5.5 · Almacenamiento La sesión tiene dos capas con requisitos distintos: * **Capa continua** — alta frecuencia, compresión necesaria. Sensores a 60fps con 137 canales son 500 KB/s crudo, 30 MB/min. Inasumible para sesiones largas. La solución es compresión delta (registrar solo cuando el valor cambia más de un umbral), cuantización por sensor según resolución útil, almacenamiento binario plano. * **Capa eventos** — baja frecuencia, semántica completa. Fallos, escenarios, comandos de instructor, anotaciones. Van como JSON estructurado, indexable, con timestamps exactos. El almacén natural es **RabbitMQ Streams** (ya en la infraestructura del proyecto): append-only, offset-based, persistente, múltiples consumidores independientes, reconexión retoma desde offset. La infraestructura está lista; lo que falta es el módulo que graba y el que reproduce (M6 del roadmap histórico, hoy llamado "viewer externo de Debug1" en la visión fundacional). ### 5.6 · Estado actual del proyecto La sesión multipistas existe hoy **en piezas** no unificadas: * `SimSequenceRecorder` y `SimSequencePlayer` — primera versión funcional de grabación y reproducción de valores (`src/simulation/`). * `DebugBus` — bus de eventos que podría alimentar la capa eventos. * `RabbitMQ Streams` — infraestructura preparada pero no usada como FDR. * Visión fundacional de Debug1 (marzo 2026) — prometía *"pantalla externa · filtros · timeline · diff · replay"* pero no se implementó completa. Una sesión dedicada al **viewer externo de Debug1** unificará estas piezas bajo el modelo multipistas articulado aquí. El análisis `lru_debug1_analysis_s55.md` identifica esto como el gap mayor entre visión e implementación, y conecta directamente con la dimensión formativa declarada en `LRU_MISION`. --- ## 6 · La realimentación como estructura causal universal Las cinco primitivas de §2 describen **de qué está hecho el sistema**. Las secciones siguientes describen cómo esas piezas se acoplan entre sí — el bucle perceptor-inteligencia-efector (§7), las guías estructuradas (§8), los actores en tres niveles (§9), los casos reales documentados (§10), la jugabilidad estructural (§11), la orquesta distribuida (§12). Esta sección, que precede deliberadamente a las anteriores en el orden de lectura, articula **la propiedad fundacional sobre la que todo lo demás opera**. La realimentación no es **una** propiedad del sistema entre otras. Es **la** propiedad fundacional de la que depende la eficacia, la flexibilidad y la inteligencia de todo lo demás. Un sistema sin realimentación ejecuta; un sistema con realimentación aprende, ajusta, corrige, se adapta. Los sensores, la capa intermedia, los actuadores, las guías, los actores, la sesión multipistas — todo esto vale **porque la realimentación los acopla en bucles que se corrigen**. Sin realimentación son piezas inertes. > *"La realimentación como estructura causal universal es más importante y fundamental porque es el que le da potencia, inteligencia y flexibilidad a todo. La realimentación es la que hace eficaz o 'inteligente' a cualquier sistema, y todo esto son sistemas interconectados de inteligencia distribuida que se materializa en las realimentaciones multinivel. Es como el funcionamiento de una red neuronal o una GPU — proceso distribuido o en paralelo."* — Manuel, s69 ### 6.1 · La realimentación es la definición operativa de inteligencia Lo que §7 llamará "capa intermedia" no es una pieza con propiedades misteriosas — es **un bucle de realimentación suficientemente rico** cuyas cinco funciones cognitivas (percepción interpretada, conocimiento, inferencia, previsión, decisión) y dos sustratos (valores/intenciones, atención) son la anatomía interna del bucle. La inteligencia emerge cuando la realimentación opera con profundidad suficiente; no es propiedad añadida. Esta lectura se inscribe en la tradición intelectual de la **cibernética** (Wiener, Ashby), la **teoría de sistemas** (Bertalanffy) y la **cognición encarnada** (Varela, Maturana), que sostienen desde mediados del siglo XX que la inteligencia es **propiedad de bucles de control acoplados**, no propiedad sustantiva de ninguna pieza individual. El postulado no resuelve el debate filosófico — adopta la posición operativa que mejor sirve al diseño del sistema. ### 6.2 · La inteligencia del sistema LRU es distribuida, no centralizada No hay un único bucle grande que coordine todo. Hay **muchos bucles de realimentación operando en paralelo a distintos niveles**, acoplados donde se tocan. El piloto tiene su bucle personal; el autopiloto tiene el suyo; la tripulación tiene un bucle colectivo; la torre de control otro; la aerolínea uno más lento; el regulador uno aún más lento; la industria completa uno lentísimo. Todos operando simultáneamente. La inteligencia del sistema completo es **propiedad emergente** de ese conjunto de bucles acoplados — no reside en ningún nivel individual. Y esto explica algo importante para la plataforma: no hay que diseñar la inteligencia del sistema; hay que **diseñar las condiciones de acoplamiento entre bucles** y dejar que la inteligencia emerja del conjunto. ### 6.3 · Los bucles operan en escalas temporales distintas Esta multiescala es crítica para entender el sistema: - **Milisegundos** — el bucle del sensor al actuador a través de la capa intermedia automática (control clásico). - **Segundos a minutos** — el bucle cognitivo del operador humano percibiendo, interpretando, decidiendo, actuando, observando resultado. - **Minutos a horas** — el bucle de coordinación entre actores (tripulación, equipo quirúrgico, equipo de operaciones). - **Días a semanas** — el bucle de aprendizaje individual consolidando experiencia en competencia (§9). - **Meses a años** — el bucle organizacional ajustando procedimientos y formación. - **Años a décadas** — el bucle regulatorio cristalizando aprendizaje en corpus normativo (§8 y la sección de darwinismo digital de `LRU_MISION`). La misma estructura causal — percibir → interpretar → decidir → actuar → percibir el efecto → iterar — se repite en todas las escalas. Lo que cambia es la constante de tiempo. Y lo que las une es que **fallos de acoplamiento entre niveles** (un nivel no recibe la realimentación de otro, o la recibe distorsionada o tarde) producen los modos de fallo más severos del sistema completo. Los casos reales documentados de §10 son catálogo precisamente de esos fallos de acoplamiento. ### 6.4 · La analogía con la arquitectura computacional moderna es material, no decorativa El progreso en inteligencia computacional ha sido progreso en **arquitecturas de realimentación masivamente paralelas, distribuidas, y crecientemente reconfigurables**. Cuatro niveles de profundidad creciente: - **Las redes neuronales** aprenden porque hay **backpropagation** — realimentación del error hacia atrás ajustando pesos distribuidos en miles de unidades. La realimentación opera *sobre el modelo*; el sustrato (la arquitectura del cómputo) es fijo. - **Las GPU** son potentes no por velocidad bruta sino porque ejecutan **muchos bucles pequeños en paralelo** en lugar de un bucle grande secuencial. La realimentación opera *a escala* gracias a paralelización masiva; el sustrato sigue siendo fijo. - **Las FPGA** rompen la última frontera: el hardware mismo se reconfigura desde software. La realimentación puede operar **a nivel de la propia arquitectura del bucle**, no solo dentro del bucle. Si el patrón de operación cambia, la propia topología del circuito se reescribe. Es **la instanciación de hardware desde software** — la frontera hardware/software, que la informática clásica trataba como categoría dura, se vuelve gradual. - **El principio común** es que las analogías concretas (redes neuronales, GPU, FPGA) son ejemplos del principio en este momento histórico; el principio sobrevive aunque las tecnologías cambien. Lo que importa es la dirección: del cómputo secuencial sobre hardware fijo hacia bucles distribuidos sobre sustrato reconfigurable. > *"Las FPGA son desde mi punto de vista lo más potente porque es la instanciación de hardware desde el software. Hay mucho que decir y desarrollar en esta plataforma sobre esa tecnología que todavía no está verbalizado."* — Manuel, s69 El mundo físico operativo — aviación, agricultura, minería, sanidad, industria — funciona con esa misma arquitectura: múltiples actores humanos y automáticos con bucles locales, acoplados donde se tocan, produciendo comportamiento colectivo inteligente del que ningún componente individual es responsable total. ### 6.5 · Reinterpretación del marco a la luz de §6 Un postulado verdaderamente fundacional ilumina hacia atrás. Esta sección reinterpreta las secciones anteriores y posteriores sin invalidarlas: - **El bucle perceptor-inteligencia-efector (§7)** describe **el bucle canónico del operador individual**. Las 5 funciones cognitivas y los 2 sustratos no son "lo que hay dentro de una capa intermedia" — son **la anatomía interna de un bucle de realimentación suficientemente rico**. Y el sistema completo tiene muchos bucles así, operando en paralelo a distintas escalas. - **Las guías estructuradas (§8)** no son documentación externa al modelo; son **realimentación acumulada y cristalizada** del sector a lo largo del tiempo. Cada checklist es la precipitación de mil bucles de realimentación previos donde alguien aprendió algo. El corpus regulatorio es **memoria de bucles pasados convertida en entrada para bucles futuros**. - **Los actores en tres niveles (§9)** son **tres bucles de realimentación operando en escalas temporales distintas**, acoplados donde se tocan. Esto explica por qué "competencia y privilegios son categorías primeras y separadas": competencia es lo que emerge del bucle individual; privilegios son lo que regula el bucle organizacional. - **Los casos reales documentados (§10)** son **bucles de aprendizaje a escala de corpus cerrándose**: accidente → investigación → lección → guía modificada → formación → operación → ausencia de recurrencia (o persistencia, si el bucle no funcionó). - **La jugabilidad estructural (§11)** es **realimentación con loop corto y baja penalización** — el mecanismo por el que la cognición consolida aprendizaje rápido. El juego "ejercita la plataforma" porque la obliga a cerrar bucles rápido y bien. - **El darwinismo digital** (sección de `LRU_MISION`) es **la realimentación operando a escala del corpus regulatorio**. Las 170+ enmiendas de Annex 1 son el bucle cerrándose en horizonte de décadas. Es el mismo mecanismo que el bucle del operador individual, solo que lentísimo. - **La continuidad simulación-control real** (sección de `LRU_MISION`) es posible porque simulación y operación real son **el mismo bucle de realimentación con el origen del estado cambiado**. El aprendizaje se traslada entre ellos porque la estructura causal es idéntica. - **El aeronáutico como primer realm** (sección de `LRU_MISION`) es buen primer realm en parte porque **tiene sus bucles de realimentación más maduros y mejor acoplados** entre niveles. Cinco niveles operando simultáneamente con acoplamiento explícito. ### 6.6 · Consecuencia arquitectural fundamental El sistema LRU **no es una plataforma que "tiene bucles de realimentación entre sus capacidades"**. Es **una plataforma de bucles de realimentación acoplados multinivel** — su arquitectura, sus primitivas, su sesión multipistas, sus actores múltiples, su Realm como mundo que le falta a la pieza real, su indistinción físico/virtual, su continuidad local/remoto — todo está diseñado para soportar el acoplamiento de múltiples bucles operando en paralelo a escalas distintas. Esta lectura **no añade requisitos arquitecturales nuevos al sistema**; nombra con precisión lo que la arquitectura ya está haciendo. Y al nombrarlo, da criterio para futuras decisiones: cuando aparezca duda de diseño, la pregunta canónica que esta sección introduce es *"¿esta decisión facilita o dificulta el acoplamiento entre bucles a distintas escalas?"*. ### 6.7 · El nivel 0 físico como sustrato epistémico La realimentación universal del Postulado 6 opera sobre un sustrato que no ejecuta decisiones ni procesa símbolos, pero sí ejecuta causalidad material: **las leyes de la naturaleza**. Esta subsección articula ese sustrato como primera clase del marco, no como asunto técnico. > *"La naturaleza ejecuta. Aerodinámica, electromagnetismo, termodinámica, química y otras muchas más es el estado de la ciencia aplicado con la tecnología que por primera vez lo interconecta aquí y ahora."* — Manuel, s71 La formulación es precisa en sus dos palabras clave: **"Estado de la ciencia"** — el nivel 0 que el sistema LRU modela no son las leyes físicas en abstracto, es **el estado actual de formalización que la ciencia ha logrado**. Las leyes físicas como realidad material son invariantes a escala humana, pero su formalización matemática sigue avanzando. Navier-Stokes se refina en regímenes extremos; los modelos de combustión se completan década tras década; las dinámicas de materiales se reformulan con datos nuevos. El estado de la ciencia es también inteligencia enlatada — cocinada por la comunidad científica a lo largo de siglos, preservada en artículos revisados, libros de texto y bases de datos de constantes físicas, verificable por repetibilidad experimental y peer review. La vida útil mayor del nivel 0 en el sistema es real — no porque las leyes físicas sean inmutables, sino porque la ciencia fundamental aplicable a los dominios maduros del proyecto es muy estable. La aerodinámica aplicada a un A320 no se ha renovado desde los años 30; las regulaciones aeronáuticas cambian cada año. La estabilidad diferencial es histórica, no metafísica. **"Interconecta aquí y ahora"** — el verbo no es *aplicar* sino **interconectar**, y la diferencia es sustantiva. Aplicar el estado de la ciencia es lo que hace cualquier ingeniería: calcular con ecuaciones, dimensionar con márgenes, especificar con estándares. Interconectar el estado de la ciencia es lo que el LRU Platform hace: **las ecuaciones se ejecutan en vivo en piezas virtuales funcionales que participan del bucle con piezas reales**, con otros actores conectados, con guías actuando sobre el bucle, con casos ilustrando la situación. La ciencia formalizada **se convierte en ciudadano activo del sistema**, no en material de referencia externo. Esto da definición operativa del nivel 0 en el marco: son las **piezas virtuales funcionales que encarnan el estado de la ciencia y participan del bucle bidireccional con la realidad material**. No son solo `namedFormulas` o `derivations` como material técnico — son **sustrato ejecutable sobre el cual el resto del sistema opera con garantía de coherencia con el mundo físico real**. **Dónde vive ya técnicamente en el sistema**: el proyecto tiene infraestructura considerable para representar el nivel 0, aunque dispersa. `quantities.ts` declara dimensiones y unidades como vocabulario del nivel 0. Las seis funciones aerodinámicas en `units.ts` (iasTas, tasMach, machTas, iasMach, computeTAT, computeVMO) son modelos matemáticos de funciones de transferencia físicas — validadas en s63 como candidatas al motor `namedFormulas` del Realm. Los `derivations` de Realm v2 son lenguaje declarativo para conectar señales con relaciones matemáticas. Lo que falta es declaración explícita de que esto **es sustrato epistémico de primera clase**, con disciplina de trazabilidad a fuentes científicas y extensibilidad a dominios nuevos sin imponer el aeronáutico como molde. **Consecuencia para el Postulado 9**: la continuidad simulación-control real (sección de `LRU_MISION`) gana fundamento técnico explícito. El interface puede ser único **porque está construido sobre el invariante físico**. El operador entrenado en simulador acopla su cognición con un modelo del nivel 0; cuando opera en lo real, acopla la misma cognición con el nivel 0 real. El aprendizaje se transfiere porque la pieza estable — la física — no cambia al cruzar la frontera simulación/real. Y esto da **criterio objetivo de fidelidad**: la calidad del simulador es la coincidencia medible entre el modelo del nivel 0 que codifica y el nivel 0 real, dentro de los regímenes que declara cubrir. Por eso los simuladores aeronáuticos certificados tienen requisitos cuantitativos de desviación — la fidelidad es mensurable porque el referente material es estable. Esta articulación permite también razonar sobre qué dominios son maduros para el proyecto: un dominio con nivel 0 bien formalizado (aviación comercial, procesos químicos industriales conocidos, aerodinámica subsónica) es candidato sólido. Un dominio con nivel 0 parcialmente formalizado (respuesta humana bajo estrés extremo, neurociencia cognitiva fina) requiere más cuidado — el modelo puede ser útil pero la fidelidad no es verificable con los mismos criterios. --- ## 7 · El bucle perceptor-inteligencia-efector Las cinco primitivas de §2 describen **de qué está hecho el sistema**. Esta sección describe **cómo esas piezas se mueven entre sí** — la estructura operativa que el sistema encarna cuando las primitivas están vivas y acopladas. ### 7.1 · El mundo se modela en bucle, no en puntos El mundo que el sistema observa y modifica no es un conjunto estático de valores. Es un **bucle causal con realimentación** entre tres piezas: - **Sensores** — perciben el estado del entorno físico o virtual. - **Capa intermedia** — interpreta lo percibido, decide qué hacer. - **Actuadores** — modifican el estado del entorno. El orden canónico es *percibir → interpretar → decidir → actuar → percibir el efecto → iterar*. Las tres piezas no son simétricas formalmente — son **acopladas causalmente**. No hay actuación sin percepción previa; no hay percepción útil sin interpretación; no hay interpretación sin modelo del mundo. > *"El mundo virtual es idílico: el concepto actuador es ideal y no realista. En el mundo físico pueden ocurrir muchas cosas imprevistas y mediante realimentación de los sentidos o los sensores hacemos los cambios o la reingeniería que sea necesaria."* — Manuel, s67 El bucle **no sustituye** a las primitivas de §2 — las organiza sistémicamente. Una señal con dirección `observable` pertenece al lado sensor del bucle. Una señal `actuable` pertenece al lado actuador. Una señal `bidireccional` participa en ambos lados. Las operaciones **OBSERVAR** e **INTERVENIR** de §4 son, respectivamente, el interface del bucle con el lado sensor y con el lado actuador. ### 7.2 · La capa intermedia no es caja negra La capa intermedia es donde residen las **funciones cognitivas** del sistema — lo que el sistema *sabe*, lo que *deduce*, lo que *decide*. Descomponerla es necesario porque sus piezas son modulares y evolutivamente añadibles. Cinco funciones cognitivas, independientes pero acopladas: - **Percepción interpretada** — convertir los datos crudos que llegan de los sensores en estado interpretado del sistema. No es el sensor — es entender qué dice el sensor. - **Conocimiento** — el modelo acumulado del dominio. Lo que el sistema sabe sobre el mundo que observa. Es lo que un Realm declara: qué señales existen, qué relaciones tienen, qué rangos son legítimos, qué escenarios son posibles. - **Inferencia** — deducir lo no observado a partir de lo observado más el conocimiento. Si la lectura de un sensor se pierde pero el conocimiento dice que hay correlación estable con otros sensores, la inferencia rellena el hueco. - **Previsión** — proyectar hacia el futuro cómo evolucionará el estado si no se interviene, o si se interviene de tal manera. Es distinta de la inferencia: la inferencia reconstruye lo oculto presente, la previsión anticipa lo futuro. - **Decisión** — elegir entre alternativas de actuación, informada por las cuatro funciones anteriores. Y dos sustratos transversales, que no son operaciones sino condiciones sobre las que operan las anteriores: - **Valores e intenciones** — qué se optimiza, qué se prioriza, qué se evita. Ningún sistema de control es *neutro* — optimiza algo a costa de otra cosa. Estos valores deben ser declarables, no quedar hardcoded en el código de decisión. - **Atención** — qué se mira ahora mismo, qué se ignora. El ancho de banda cognitivo es limitado — en el alumno, en el instructor, en el sistema automático. La atención es recurso que el sistema asigna, no propiedad fija. ### 7.3 · La asimetría sensor/actuador justifica la simetría del modelo El trabajo arquitectural de s65 articuló `SensorFaultDef` con 16 kinds y `ActuatorFaultDef` con 6 kinds. La asimetría numérica **no es arbitraria** — refleja una propiedad del mundo: - Los **sensores** tienen 16 modos de fallo porque **leer el mundo es difícil** de muchas maneras: ruido, deriva, retraso, cuantización, saturación, pérdida de comunicación, deriva térmica, envejecimiento. Cada uno altera la relación entre lo que el sensor dice y lo que el mundo es. - Los **actuadores** tienen 6 modos porque **modificar el mundo con garantía también es difícil**: bloqueo, deriva, pérdida de efectividad, runaway, hard-over, float. Cada uno altera la relación entre lo que se le ordena al actuador y lo que el actuador hace. - La **capa intermedia** es difícil por **las dos razones a la vez**: depende de lecturas imperfectas y produce decisiones cuyo efecto es imperfecto. Sus modos de fallo son aún más variados y peor catalogados que los de sensores y actuadores — y enseñar a operar bajo esos modos de fallo es función didáctica central del sistema. El modelo simétrico de sensor y actuador como entidades paralelas no es decorativo: **el bucle exige que ambos lados del mundo sean modelables con precisión comparable**. El núcleo arquitectural del proyecto (`LRU_ARQUITECTURA`) reconoce esta simetría como deuda consciente — el schema Realm v2 tiene `EntityDef` de kind sensor maduro y carece de `ActuatorDef` de primera clase (T-S65-N3). La integración del marco del bucle impulsa el rediseño de schema hacia Realm v3 donde ambos lados queden simétricamente articulados. ### 7.4 · El bucle en el sistema operativo de señales El bucle no es nueva primitiva — es **estructura emergente** de las cinco primitivas existentes. Pero al nombrarlo como tal, el proyecto gana: - Un **vocabulario** para razonar sobre arquitectura: *"¿en qué lado del bucle vive esto?"*. - Un **criterio** para detectar huecos: cuando una operación importante no encaja ni en OBSERVAR ni en INTERVENIR, probablemente es una función cognitiva de la capa intermedia todavía no modelada como tipo propio. - Un **marco** para la evolución futura: los tipos nuevos del Realm v3 (ActuatorDef, IntelligenceDef descomponible en subtipos cognitivos, grafo de realimentación explícito) se derivan directamente del bucle. El horizonte que esto abre es que la capa intermedia, hoy dispersa entre `SimService`, `ScenarioDef.narrative`, `ConditionDef` y lógica hardcoded en UI, pase a vivir en el Realm como tipo declarable. Es trabajo arquitectural pendiente, no de esta sección. --- ## 8 · Las guías estructuradas Los operadores de sistemas complejos no actúan por improvisación ni por memoria individual. Operan apoyados en **guías externas estructuradas** que condensan conocimiento acumulado y lo hacen aplicable bajo presión. > *"Un técnico de mantenimiento debe solucionar fallos técnicos o averías, para ello puede utilizar un manual aeronáutico que podemos llamar troubleshooting. Cuando un piloto tiene una emergencia no actúa de forma anárquica, utiliza una guía rápida. Todo esto es comportamiento estructurado, y es una base de la enseñanza y del aprendizaje. Muchas cosas son demasiado complicadas para tenerlas todas en la cabeza y por eso existen los libros y el aprendizaje o la enseñanza. La humanidad ha avanzado gracias a ello."* — Manuel, s67 Las guías no son texto decorativo, ni comentarios, ni documentación externa al modelo. Son **ciudadanos de primera clase del Realm**: estructura declarativa, acoplada al estado del bucle (qué sensores disparan qué guía, qué actuadores comanda cada paso, qué sensores se monitorizan entre pasos), enseñable, criticable, mejorable. ### 8.1 · La tipología de cuatro guías Cuatro tipos, distinguidos por su **uso** más que por su **forma**. La forma subyacente es común — secuencia de pasos con condiciones de entrada, acciones y criterios de transición — pero el uso activa disciplinas distintas en el operador. | Tipo | Entrada | Salida | Característica | |---|---|---|---| | **Procedimiento de emergencia** (QRH-style) | Síntoma agudo | Secuencia ordenada bajo presión temporal | Tiempo apremia, memoria cede, la estructura sustituye a la comprensión completa | | **Procedimiento de diagnóstico** (Troubleshooting-style) | Síntoma observado | Árbol de decisión con tests desambiguadores | Tiempo no apremia tanto, espacio de causas grande, hay que ir podando | | **Procedimiento operativo normal** (Checklist-style) | Fase o transición | Lista de verificación ordenada | Ni emergencia ni diagnóstico — rutina estructurada para no olvidar | | **Material didáctico** (Aprendizaje-style) | Concepto a enseñar | Secuencia pedagógica con retroalimentación | No es *cómo actuar* sino *cómo entender para luego saber actuar* | Los cuatro comparten estructura subyacente: **condición de entrada + pasos + condiciones de éxito/fallo en cada paso + referencias cruzadas entre guías**. Pero cada tipo tiene acentos distintos — el procedimiento de emergencia optimiza para tiempo mínimo, el troubleshooting para cobertura del espacio de causas, el checklist para completitud, el didáctico para comprensión. ### 8.2 · La competencia como esqueleto común OACI Annex 1 define **competencia** como *combinación de habilidades, conocimiento y actitudes requeridas para ejecutar una tarea al estándar prescrito*, y la descompone jerárquicamente: - **Unidad de competencia** — función discreta (ej. *"gestionar una emergencia de motor en crucero"*). - **Elemento de competencia** — acción acotada con evento desencadenante y evento terminador (ej. *"identificar el motor afectado a partir de instrumentos"*). - **Criterio de ejecución** — el estándar al que debe ejecutarse. Esta ontología es **el esqueleto de las guías**. Las guías son secuencias declarables de elementos de competencia. Material didáctico y procedimiento operativo comparten estructura; se diferencian por su uso, no por su forma. **La ontología de competencia precede a la ontología de guías** — primero se declara qué se sabe hacer (competencias), luego se declara cómo se aplica bajo cada tipo de situación (guías). Adoptar esta ontología desde el primer realm aeronáutico permite que los realms futuros de otros dominios la reutilicen con nombres distintos pero estructura idéntica — una unidad de competencia en medicina (*"gestionar una crisis hipertensiva"*) tiene la misma forma declarativa que una aeronáutica. ### 8.3 · El acoplamiento de guías con el bucle Una guía no vive aislada. Se acopla al bucle de §7 por tres vías: - **Disparo** — qué estado de sensores/capa intermedia activa la guía. Un síntoma observado dispara un procedimiento de diagnóstico; un fallo crítico dispara un procedimiento de emergencia; una transición de fase dispara un checklist. - **Acción** — qué actuadores comanda cada paso de la guía, explícita o implícitamente a través del operador humano. - **Monitorización entre pasos** — qué sensores se vigilan entre acciones para decidir si continuar, retroceder, ramificar. Esta tríada convierte la guía en **declaración ejecutable contra el bucle**: el sistema puede saber si un operador está siguiendo la guía, dónde se desvía, cuándo reacciona tarde, qué pasos omite. Esto es lo que permite la evaluación formativa de §5 (las pistas derivadas contra expectativas) — la guía es la partitura, la sesión grabada es la ejecución, la comparación es la evaluación. ### 8.4 · Relación con las primitivas existentes La primitiva **Escenario** de §2.4 ya incluye como piezas *expectativas — qué debe ocurrir según procedimiento, la partitura contra la que se puede evaluar formativamente* y *narrativa — qué se entrena, qué se prueba, qué se diagnostica*. Es el germen de la guía: ya estaba embebido en el Escenario. Lo que §8 añade al marco existente: - Elevar **Guía** a tipo propio, separable de Escenario. Un Escenario declara *qué ocurre* en el tiempo. Una Guía declara *cómo debe responder un actor* a lo que ocurre. Son acoplables pero distintos — la misma Guía puede invocarse desde varios Escenarios, el mismo Escenario puede evaluarse contra varias Guías alternativas. - Nombrar la **tipología de cuatro guías** como estructura declarativa común. - Articular la **ontología unidad/elemento/criterio de competencia** como esqueleto subyacente. El rediseño del schema Realm hacia v3 incorporará `GuideDef` (con variantes discriminadas por tipo), `CompetenceDef`, `CompetenceElement` y `CompetenceCriterion` como tipos de primera clase. Trabajo arquitectural pendiente, no de esta sección. ### 8.5 · Las máquinas de estados como sintaxis del enlatado La tipología de guías de §8.1 tiene una propiedad estructural que merece nombrarse explícitamente: **las máquinas de estados son la sintaxis del enlatado**. Son el formato técnico privilegiado para condensar inteligencia viva en algo conservable y ejecutable por quien no es el experto que lo articuló. La observación emergió en la exploración post-cierre de s69. Si el resultado de enlatar inteligencia tiene que ser ejecutable bajo presión por alguien distinto del experto que lo articuló, el formato necesita ser **explícito, paso a paso, sin ambigüedad**. La máquina de estados es exactamente eso: - **Estados** — los pasos discretos en los que el sistema puede estar. - **Transiciones** — las decisiones explícitas entre pasos. - **Condiciones** — los criterios verificables que disparan las transiciones. Es la forma matemática que la inteligencia toma cuando se condensa para conservación. Por eso una QRH bien estructurada tiene forma de árbol de decisión con condiciones binarias; una checklist es secuencia de estados con transiciones por confirmación; un troubleshooting es grafo de estados con transiciones por síntoma observado. **Dónde encajan las máquinas de estados en el marco** — la sintaxis del enlatado se aplica de forma asimétrica a través de los postulados: - **Encajan con las guías de §8** — porque las guías son inteligencia enlatada y el enlatado tiene esta sintaxis. - **Encajan con los puntos de bifurcación de §10** (casos reales) — porque los puntos donde el sistema entra en estado de decisión discreta son exactamente donde la cognición humana es más vulnerable y donde el material didáctico tiene más valor. - **Encajan con las fases de los escenarios** (`preflight`, `taxi`, `takeoff`, `cruise`, `approach`...) — porque las fases son estados con transiciones disparadas por tiempo o condiciones observables. **Dónde no encajan las máquinas de estados**: - **No encajan con la inteligencia viva del bucle** (§7, capa intermedia con 5 funciones cognitivas + 2 sustratos) — porque opera con percepción borrosa, modelos probabilísticos, atención que se distribuye gradualmente. Forzar máquina de estados sobre eso pierde la sustancia. - **No encajan con la cognición del jugador** (§11) — porque la consolidación del aprendizaje es proceso continuo, no transición discreta. - **No encajan con los acoplamientos entre bucles** (§6) — porque son acoplamientos dinámicos con retardos variables y calidad variable de la señal. **La frontera continuo/discreto como frontera enlatado/vivo**: el operador opera en lo continuo (vuela el avión, monitoriza, ajusta) hasta que alcanza un estado donde tiene que decidir entre alternativas discretas (¿continuamos o desviamos? ¿declaramos emergencia? ¿aplicamos QRH X o Y?). Esos son puntos donde **lo continuo colapsa en estado discreto**, se ejecuta una transición, y vuelve a lo continuo. Los accidentes ocurren típicamente en estos puntos — porque la decisión discreta bajo presión, con información parcial e incertidumbre alta, es donde la cognición humana es más vulnerable. Todo el corpus de Crew Resource Management está diseñado precisamente para mejorar la calidad de las transiciones discretas en momentos críticos. **Consecuencia arquitectural**: el rediseño del schema Realm hacia v3 puede beneficiarse de tratar la máquina de estados como **formalismo privilegiado para `GuideDef`** (con estados, transiciones y condiciones como elementos estructurales), y de representar explícitamente los puntos donde el sistema entra en máquina de estados de decisión en `CaseStudyDef` — son los momentos donde la jugabilidad del Postulado 8 tiene más valor formativo, donde la simulación parcial puede recrearse con bifurcación, donde la lección se cristaliza en guía nueva. Decisión concreta del schema corresponde a T-S67-A1; aquí se nombra como estructura subyacente. --- ## 9 · Los actores en tres niveles La primitiva **Actor** de §2.3 describe cuatro tipos de encarnación en runtime — humano con dispositivo, dispositivo físico autónomo, proceso de software, observador pasivo. Esa primitiva sigue siendo válida: describe *quién está conectado ahora mismo al sistema*. Esta sección añade el nivel complementario — **quién puede conectarse, con qué autorización, dentro de qué organización, regulado por qué autoridad**. No es sustitución, es **estructura estructural** encima de la estructura operativa. > *"Los roles están establecidos en el mundo aeronáutico, busca sobre el sistema de documentación ATA100 y similares. Esos son los personajes protagonistas pero en otros entornos tendrán otros nombres, pero sus roles suelen ser repetitivos."* — Manuel, s67 El sistema LRU distingue **tres niveles de actor**, anidados y acoplados, reflejando la estructura del corpus regulatorio aeronáutico internacional. No es invención conceptual — es adopción consciente de una estructura mundialmente validada durante 75 años. ### 9.1 · Nivel individuo — personas en roles abstractos con licencia y privilegios Personas ejerciendo un **rol abstracto** con una **licencia** (o equivalente) que les otorga **privilegios** específicos. Los roles son tipológicos y se repiten entre dominios con nombres distintos pero función equivalente: - **Operadores** — interactúan con el bucle físico en tiempo real. En aeronáutica: piloto con licencias escalonadas PPL/CPL/MPL/ATPL, co-piloto, flight engineer, flight navigator. En quirófano: cirujano, anestesista, instrumentista. En planta industrial: operador de sala de control. - **Técnicos de mantenimiento** — diagnostican y reparan el sistema cuando el bucle falla. En aeronáutica: licencia EASA Part-66 Cat A/B1/B2/B3/C. En electromedicina: técnico biomédico certificado. En automoción: mecánico certificado. - **Instructores y examinadores** — transmiten competencia y verifican su adquisición. En aeronáutica: instructor Part-147 teórico o práctico, examinador de conocimiento, assessor práctico. En cualquier sector: formador certificado, examinador homologado. - **Aprendices** — adquieren competencia bajo supervisión. En aeronáutica: student pilot, aprendiz en Part-147. En cualquier sector: estudiante en formación reglada, residente, trainee. - **Reguladores de soporte** — licencian a los otros actores. Son roles *sobre* roles. Ejemplos aeronáuticos: examinador médico (evalúa fitness médico del personal licenciable), auditor (verifica cumplimiento organizacional), inspector de aeronavegabilidad. - **Roles operativos de soporte** — actores que no operan ni mantienen pero son críticos para la operación. En aeronáutica: flight dispatcher, controlador aéreo, aeronautical meteorological personnel, aeronautical station operator. En dominios industriales equivalen a planificador de producción, supervisor de turno, analista de datos operacionales. - **Diseñadores y fabricantes** — producen el sistema físico y su documentación primaria. En aeronáutica cubiertos por EASA Part-21. Su rol no es operar el bucle sino **definirlo**. ### 9.2 · Nivel organización — estructuras colectivas con estatus regulatorio Las personas no operan aisladas — operan dentro de **organizaciones aprobadas** con estatus regulatorio. Esto es pieza de primera clase del modelo, no metadato del individuo. | Tipo de organización | Ejemplo aeronáutico EASA | Equivalente conceptual | |---|---|---| | Diseño y producción | Part-21 | Fabricante con certificación del sector | | Mantenimiento | Part-145 | Taller autorizado, centro de servicio técnico | | Formativa | Part-147 | Centro formativo homologado, universidad acreditada | | Gestión continua | Part-CAMO | Gestor de flota, asset management | | Operador del servicio | Aerolínea (Part-OPS, AOC) | Hospital, planta, empresa operadora | Un individuo en un rol ejerce **dentro** de una organización. Un mecánico Part-66 trabaja en organización Part-145. Un instructor trabaja en organización Part-147. La persona y la organización están acopladas pero son niveles distintos del modelo: un mismo individuo puede cambiar de organización preservando su licencia; una organización puede cambiar de personal preservando su aprobación. **El desacoplamiento es propiedad estructural, no detalle administrativo**. ### 9.3 · Nivel autoridad — entes reguladores y certificadores Tres capas anidadas: - **Global** — define estándares mínimos universales. En aeronáutica: OACI/ICAO con sus 19 Annexes (Annex 1 Personnel Licensing, Annex 6 Operation of Aircraft, Annex 8 Airworthiness) y su corpus de Documentos. En medicina: WHO. En industria: IEC/ISO. En telecomunicaciones: ITU. - **Regional** — implementa y puede endurecer. En Europa: EASA. En Estados Unidos: FAA. En China: CAAC. En Reino Unido post-Brexit: UK CAA basada en reglas EASA. En medicina europea: EMA. Esta capa produce reglamentaciones vinculantes como Regulation (EU) 1321/2014 que consolida Part-M/145/66/147/CAMO. - **Estatal** — emite licencias individuales, audita organizaciones, supervisa cumplimiento. En España: AESA. En Francia: DGAC. Cada estado contratante de OACI tiene una autoridad nacional con esta responsabilidad. Este nivel es **metasistémico**: no opera directamente sobre el bucle físico, opera **sobre la estructura del sistema completo** — quién puede operar, quién puede enseñar, quién puede mantener, quién puede certificar. Es el nivel que garantiza que el resto del modelo funciona. ### 9.4 · Competencia y privilegios como categorías primeras Dos distinciones que el corpus regulatorio aeronáutico ha madurado y el modelo LRU adopta: **Competencia** — definida por OACI Annex 1 como combinación de habilidades, conocimiento y actitudes requeridas para ejecutar una tarea al estándar prescrito. Descomponible jerárquicamente en unidades, elementos y criterios (ver §8.2). La competencia es **propiedad del individuo**, acreditada por la licencia, desarrollada mediante formación y experiencia. **Privilegios** — lo que el titular de una licencia está autorizado a hacer. Varían según ratings, endorsements, experiencia acumulada, estado médico vigente y validez temporal. **Licencia ≠ privilegio**: dos actores con la misma licencia pueden tener privilegios distintos. El modelo LRU debe poder expresar afirmaciones como: *"Juan tiene licencia Cat B1 pero no está autorizado a certificar el sistema hidráulico del A320 hasta completar formación de tipo específica"*, o *"María tiene licencia ATPL con type rating A320 pero su medical certificate está caducado, por lo que sus privilegios están suspendidos"*. ### 9.5 · Relación con la primitiva Actor de §2.3 La primitiva Actor de §2.3 y los tres niveles de esta sección son **complementarios, no competidores**: - **§2.3 describe la encarnación en runtime**: qué entidad está conectada ahora al sistema aportando o consumiendo señales. Sus cuatro tipos (humano con dispositivo, dispositivo físico autónomo, proceso de software, observador pasivo) siguen siendo el vocabulario correcto para el plano operativo — qué hay en la sala cuando la sesión corre. - **§9 describe la estructura estructural del actor**: qué rol ocupa, qué licencia trae, qué privilegios le confiere, en qué organización opera, bajo qué autoridad está regulado. Es el plano en el que se modela *quién puede hacer qué*, anterior e independiente de *quién está conectado ahora*. Un actor humano concreto en runtime (§2.3) ocupa un rol abstracto (§9.1), con una licencia y privilegios concretos, ejerciendo dentro de una organización (§9.2), regulado por una autoridad (§9.3). Una sesión en la que participan instructor + tres alumnos tiene cuatro actores runtime, cuatro roles abstractos activos (instructor + aprendiz × 3), probablemente una única organización (el Part-147 que los ampara) y una autoridad regional implicada. El rediseño del schema Realm hacia v3 incorporará `RoleDef` abstracto (separable de la primitiva Actor de runtime), `LicenseDef`, `PrivilegeDef`, `OrganizationDef` y `AuthorityDef` como tipos de primera clase. La primitiva Actor de §2.3 no desaparece — se acopla a estos tipos nuevos. Trabajo arquitectural pendiente, no de esta sección. --- ## 10 · Los casos reales documentados como material didáctico de primera clase Los accidentes, incidentes y eventos reales documentados son **ciudadanos de primera clase del modelo LRU**, no anécdotas ni material ilustrativo accesorio. Su peso pedagógico no viene de la metáfora sino de la realidad material: ocurrieron, y las lecciones que dejaron tienen consecuencias verificables y trazables. El sistema los modela como tipo declarable con estructura propia, no como texto narrativo adherido a un escenario genérico. > *"Merecería decidir si el proyecto usa ejemplos canónicos de accidentes reales como material didáctico de primera clase, si este tipo de ejemplos ilustran y pueden ser hilo conductor de mostrar situaciones reales con consecuencias y aprendizaje además de ejercitar el modelo de referencia este o otros."* — Manuel, s68 ### 10.1 · Los casos encarnan los bucles de §7 bajo estrés, leídos a la luz de §6 Los casos reales muestran qué interpretaron los sensores, cómo la capa intermedia (automatismo + tripulación + organización) decidió, qué actuadores actuaron, y cómo la realimentación funcionó o falló. Son **el bucle perceptor-inteligencia-efector bajo estrés documentado**. Y a la luz de §6, son **el catálogo documentado de fallos de acoplamiento entre bucles a distintas escalas** — el autopiloto operó bien en su escala pero la tripulación no recibió a tiempo la realimentación de su desconexión; la tripulación decidió bien con la información que tenía pero el bucle organizacional no le había dado formación para esa situación; la organización había detectado un patrón pero el bucle regulatorio no había cerrado la lección en guía formal. Los casos enseñan lo que ningún escenario sintético puede enseñar: **qué pasa cuando el mundo físico introduce imprevistos que exceden lo anticipado**, y cómo los bucles de realimentación de distintos niveles se desacoplan bajo presión real. ### 10.2 · Los casos son el origen histórico de las guías de §8 El corpus regulatorio aeronáutico evolucionó en respuesta a casos investigados. Annex 13 de OACI existe precisamente para eso — investigación de accidentes e incidentes. Enmiendas sucesivas a Annex 1 y otros anexos responden a lecciones extraídas de eventos reales. El ciclo es: **caso → investigación → lección → guía nueva o modificada → formación → operación**. La sección §8 cubre el final del ciclo (las guías estructuradas y su aplicación); esta sección cubre **el origen** (el caso que generó la lección). Las dos son complementarias, no alternativas. A la luz de §6, este ciclo es **el bucle de realimentación más lento del sector cerrándose**: una operación falló, el sistema completo lo detectó (años a veces), lo procesó (investigación oficial), produjo aprendizaje cristalizado (guía modificada), lo distribuyó (formación), y se observa si funciona (ausencia o persistencia de recurrencia). Modelar los casos en el Realm permite trazar, para una guía dada, qué casos fueron su origen — y al revés, para un caso dado, qué guías existen hoy gracias a él. ### 10.3 · Los casos son evidencia viva del darwinismo digital Cada caso que modifica el corpus es una mutación arquitectural que sobrevivió. Las 170+ enmiendas de Annex 1 desde 1948, citadas en `LRU_MISION` como evidencia empírica del darwinismo digital, tienen trazabilidad documental: muchas de ellas son respuestas concretas a accidentes investigados. El caso real es el material genético del que se alimenta la evolución del corpus. ### 10.4 · El accidente moderno se modela como topología multi-nivel, no como cadena lineal La investigación sistemática de accidentes desarrollada desde los años noventa ha enseñado que los accidentes raramente tienen causa única. Aprender de ellos exige capturar una estructura de capas, no reducirla a narrativa lineal. Los marcos maduros de análisis que el proyecto adopta como referencia: - **El modelo del queso suizo** (James Reason, 1990) — capas sucesivas de defensa, cada una con agujeros móviles. El accidente ocurre cuando los agujeros se alinean momentáneamente y dejan pasar una trayectoria completa. La lección es defensa en profundidad: no hay causa única, hay fallos latentes acumulados. - **Shell Causal Model / Tripod Beta** (Shell, años 90, ampliado por Hudson y otros) — descompone el accidente en causas inmediatas (acto disparador), causas preliminares (condiciones que lo hicieron posible), y fallos latentes en barreras de defensa. Organiza el análisis como árbol, no como cadena. - **AcciMap** (Rasmussen, 1997) — extiende el análisis verticalmente a través de los niveles del sistema sociotécnico (gobierno, regulador, empresa, supervisión, equipo, individuo, equipamiento). Permite visualizar dónde se rompió la cadena de defensas. - **STAMP / CAST** (Leveson, MIT, 2004) — trata el accidente como fallo de control, no como cadena causal. Aplica teoría de control a sistemas sociotécnicos. Especialmente útil para sistemas con software complejo y automación de alto nivel. - **HFACS** (Wiegmann y Shappell, marina/aviación EEUU) — taxonomía estructurada de Human Factors organizada en cuatro niveles (actos inseguros, precondiciones, supervisión, influencias organizacionales). Útil para clasificar y comparar casos. Marcos abiertos a integración futura: **Safety-II / Resilience Engineering** (Hollnagel) que invierte el foco hacia entender por qué las cosas salen bien la mayor parte del tiempo, complementario al análisis de fallos. El modelo `CaseStudyDef` (o equivalente) en el Realm v3 debe poder representar al menos las primeras tres taxonomías como vistas estructuradas del mismo caso, no como narrativa libre. La estructura subyacente es **topología de capas y barreras**, no relato lineal. ### 10.5 · Doble uso — operador y diseñador Los casos sirven a dos audiencias didácticas distintas, ambas de primera clase: - **Como material para el operador** — qué hacer y qué no hacer ante el síntoma concreto. La guía de emergencia y el procedimiento de diagnóstico se ilustran con el caso real que motivó su existencia. - **Como material para el diseñador** — qué fallos del sistema permitieron que el operador llegase al apuro. La elevación implícita aquí del rol "Diseñadores/fabricantes" del Postulado 3 (§9) como **actor formativo de primera clase** es trabajo arquitectural pendiente, registrado como tensión T-S69-A1. Ambos usos son simultáneos: el mismo `CaseStudyDef` puede consumirse desde la vista del aprendiz operador (foco en respuesta correcta bajo estrés) o desde la vista del aprendiz diseñador (foco en defensas que faltaron en el sistema completo). ### 10.6 · Disciplina ética operativa El uso de material didáctico basado en casos reales con víctimas exige disciplina explícita, no implícita. La regla operativa derivada de este postulado vive en `LRU_METODO` §6 como disciplina del proyecto, pero su núcleo se enuncia aquí porque es propiedad del modelo, no convención metodológica: **El caso real documentado con nombre propio se analiza; la clase de situación técnica que lo ilustra se juega.** Operativamente: los casos con nombre (AF447, Tenerife, Sioux City, Asiana 214) se consumen solo en modos de análisis retrospectivo y simulación parcial en el punto de bifurcación con comparación histórica — no hay retry con scoring sobre ellos. Las situaciones técnicas similares se modelan como escenarios jugables plenamente, desvinculadas de la identidad histórica, pudiendo citar como fuente de inspiración al caso real con respeto sin reclamar su identidad. > *"El modo juego libre con retry y scoring se usa con mesura y solo cuando la distancia histórica y el tipo de caso lo permiten, no deben asociarse a accidentes con nombre propio solo a situaciones similares. De otra forma efectivamente es poco ético."* — Manuel, s69 ### 10.7 · Relación con las primitivas existentes La primitiva **Escenario** de §2.4 ya incluye narrativa (qué se entrena/prueba/diagnostica) y expectativas (la partitura contra la que se evalúa). El caso real documentado **extiende** la primitiva Escenario, no la reemplaza: - Un Escenario sintético declara una situación posible y plausible de un dominio. - Un `CaseStudyDef` declara una situación que **ocurrió en una fecha y lugar concretos**, con investigación oficial documentada, lecciones extraídas, y modificaciones al corpus regulatorio que generó. El rediseño del schema Realm hacia v3 incorporará `CaseStudyDef` como tipo de primera clase con campos para la topología multi-nivel de §10.4 y referencias bidireccionales a `GuideDef` (qué guía se modificó como respuesta) y a `RegulatoryAmendment` (qué enmienda al corpus se motivó). Trabajo arquitectural pendiente, no de esta sección. --- ## 11 · La jugabilidad como propiedad estructural del sistema La interactividad con **baja penalización al error, loop corto de realimentación y motivación intrínseca** es mecanismo cognitivo privilegiado por el que el aprendizaje se consolida. No es adorno pedagógico ni envoltorio — es mecánica real del cerebro bajo exploración voluntaria. El jugador prueba, falla, reintenta, ajusta modelo, explora más allá del camino prescrito, descubre por curiosidad, se identifica con el rol. La retención y la profundidad del aprendizaje son superiores a las del estudio lineal en todos los contextos donde la jugabilidad es posible. A la luz de §6, esta superioridad cognitiva se explica con precisión: **el juego es realimentación con constante de tiempo corta y baja penalización**, exactamente la condición que la cognición humana necesita para consolidar modelos. El estudio lineal tiene constante de tiempo larga (la consecuencia de una decisión llega tarde o no llega) y penalización ambigua (no se sabe qué se ha aprendido bien hasta el examen). El juego cierra el bucle en segundos. Este postulado tiene **plano fundacional** (esta sección, sobre cómo el sistema soporta la jugabilidad como propiedad estructural) y **plano de uso** (sección equivalente en `LRU_MISION` sobre la dimensión de uso propia que esto abre). Las dos secciones son complementarias y se referencian mutuamente. ### 11.1 · Jugable por defecto, pasivo como excepción justificada El material didáctico del sistema es **jugable por defecto**; el modo pasivo es **excepción justificada, no norma**. Esto obliga al modelo a declarar estructura de juego como propiedad de primera clase del material — no narrativa pasiva que el aprendiz estudia, sino: - **Puntos de decisión explícitos** donde el jugador decide con información disponible. - **Consecuencias ramificadas** que hacen visible el impacto de las decisiones. - **Modo retry** no destructivo. - **Métricas de éxito visibles** cuando tenga sentido. - **Scoring** cuando aporte motivación sin distorsionar el aprendizaje. - **Hint progresivo** cuando ayude al jugador atascado sin saltarse la curva. El material sin jugabilidad declarada es **material incompleto**, salvo cuando hay razón fundada para que sea pasivo. El caso canónico de excepción justificada lo nombra §10: los casos reales documentados con identidad histórica se consumen en modos no-lúdicos por disciplina ética. Otros casos de excepción justificada pueden emerger — la disciplina es **nombrar la razón**, no omitir la jugabilidad por inercia. ### 11.2 · El juego como stress test cognitivo del sistema completo Un sistema que soporta bien la jugabilidad soporta automáticamente bien casi todo lo demás. El juego exige al sistema cosas que el modo formativo lineal no demanda: - **Consistencia del estado al hacer retry** — el estado inicial debe ser reproducible exactamente. - **Determinismo de las ramas del escenario** — las mismas decisiones deben producir las mismas consecuencias. - **Registro fino de decisiones del jugador** para evaluarlas post-hoc. - **Visibilidad de consecuencias** — el jugador ve el impacto de lo que hace con latencia corta. - **Métrica en vivo** — scoring, progreso, tiempos, eficiencia. Resolver la jugabilidad bien resuelve simultáneamente requisitos que el **debriefing forense, la evaluación formativa, y la operación con supervisión** también necesitan. El juego es **stress test cognitivo del sistema completo** — si el sistema lo pasa, está fuerte para todos los usos. > *"La versión fuerte, el juego ejercita la plataforma y le puede dar un campo o dimensión adicional interesante."* — Manuel, s69 Esta formulación convierte la jugabilidad de "feature didáctica opcional" en **criterio de calidad arquitectural transversal**. Un subsistema que soporta bien la sesión multipistas pero mal el retry determinista está incompleto. La sesión multipistas de §5 es la infraestructura técnica que la jugabilidad necesita: las pistas derivadas calculan métricas de scoring; los cuatro modos de reproducción soportan retry y comparación; el almacenamiento append-only en RabbitMQ Streams da consistencia de estado. ### 11.3 · Lo que el juego no hace — no construye Realms de fantasía La jugabilidad en este sentido **no construye Realms de fantasía**. Los Realms siguen siendo modelos serios de dominios reales — el juego es **modo de operar sobre ellos**. Un A320 no se modifica para que sea más divertido; pero aprender a operarlo puede hacerse jugando. Esta distinción delimita el alcance del juego en el sistema: **forma, no deforma**. ### 11.4 · Relación con las primitivas existentes La estructura de juego declarable es **extensión natural** de la primitiva Escenario de §2.4. Un Escenario actual ya tiene narrativa, expectativas, eventos y fallos disponibles. Lo que §11 añade es: - **Puntos de decisión** como tipo de evento de primera clase, distintos de los eventos automáticos. - **Ramificación** del timeline según decisiones tomadas. - **Métricas declaradas** ligadas a pistas derivadas (§5.2). - **Reglas de scoring** componibles con las métricas. - **Hints progresivos** declarables como respuesta a estados de bloqueo. El rediseño del schema Realm hacia v3 incorporará estos elementos como ampliación de `ScenarioDef` o como tipos hermanos discriminados (`PlayableScenarioDef`, `LinearScenarioDef`). Trabajo arquitectural pendiente, no de esta sección. El plano de uso — la dimensión de juego como segunda vía legítima de uso de la plataforma, no subordinada a la formación — vive en `LRU_MISION`. --- ## 11bis · Pluralidad de inteligencias coexistiendo El sistema LRU no tiene una sola naturaleza de inteligencia ni dos. Tiene **pluralidad de inteligencias con propiedades distintas, conviviendo y ejercitándose juntas**. El marco que los 9 postulados articulan, leído bajo esta lente, gana unidad nueva: el sistema es lugar de encuentro entre naturalezas de inteligencia radicalmente distintas, cada una con su disciplina de existencia. La articulación emergió en s71 como corrección explícita a una dicotomía previa. El addendum del destilado s69 había nombrado dos tipos — inteligencia viva y inteligencia enlatada — con las cinco propiedades de la conserva (alguien la cocinó, se conserva el resultado no el proceso, cualquiera puede consumirla, tiene fecha de caducidad, hay arte en el enlatado). Manuel corrigió: > *"Dos inteligencias coexistiendo o muchas más."* — Manuel, s71 La corrección es sustantiva. La dicotomía era simplificación útil; la realidad del marco es más rica. ### 11bis.1 · La enumeración no cerrada El sistema LRU modela y conecta, al menos, las siguientes inteligencias distintas: **Inteligencia física** — las leyes de la naturaleza ejecutándose sin agente decisional. Aerodinámica, electromagnetismo, termodinámica, química, óptica, acústica, mecánica de materiales, fluidos, transferencia de calor, biomecánica, bioquímica, neurofisiología, ecología, y muchas más según el dominio. Es **inteligencia sin intención** — la naturaleza no decide, ejecuta. Sustrato articulado en §6.7 como nivel 0 epistémico. **Piezas virtuales funcionales** — entidades del Realm que ejecutan modelos computables del comportamiento físico. Un motor simulado, un sensor virtual, un actuador digital con dinámica interna. No son conocimiento *sobre* la pieza real — son **sustitución funcional** de la pieza real. Participan del bucle bidireccional con las piezas reales correspondientes. Son inteligencia física encarnada en entidad ejecutable del sistema. **Inteligencia viva cognitiva** — la que ocurre en tiempo real en la capa intermedia del bucle perceptor-inteligencia-efector de §7. Las cinco funciones cognitivas (percepción interpretada, conocimiento, inferencia, previsión, decisión) más los dos sustratos (valores/intenciones, atención) operando en un humano en tiempo real. Cara, irrepetible, sensible al contexto, no replicable por otro humano distinto. **Inteligencia enlatada normativa** — las guías estructuradas de §8 en sus cuatro variantes (emergencia QRH-style, troubleshooting, checklist, didáctica). Inteligencia cocinada por un experto y puesta disponible para consumo por otros en otro tiempo. Vida útil media (años), verificable contextualmente, específica por dominio operativo. **Inteligencia enlatada histórica** — los casos reales documentados de §10. Inteligencia destilada de experiencia costosa, con fecha y lugar concretos, con víctimas reales, con investigación oficial. Tiene disciplina ética propia codificada en `LRU_METODO §6` — frontera "caso con nombre se analiza, situación técnica se juega". Ciudadanos de primera clase del modelo. **Inteligencia institucional** — el corpus regulatorio de §9 materializado en autoridades (OACI, EASA, FAA), organizaciones (Part-145, Part-147, Part-21), licencias, privilegios. Es inteligencia enlatada pero con propiedades colectivas y vida propia — se actualiza por deliberación institucional, no por decisión individual; sus enmiendas recorren años de proceso formal. Annex 1 de OACI con 170+ enmiendas en 75 años es evidencia empírica. **Inteligencia del diseñador** — el fabricante, el ingeniero de sistemas, el arquitecto aprendiendo de casos para construir sistemas tolerantes a fallos. Inteligencia viva aplicada al diseño, con bucle propio más lento que el del operador. Señalada en §10.5 (doble uso operador/diseñador) y articulada como tensión abierta hacia sesiones arquitecturales futuras. **Inteligencia emergente por jugabilidad** — la que consolida el jugador por repetición con baja penalización y loop corto, articulada en §11 y en `LRU_MISION` *"El juego como segunda vía de uso legítima"*. Es inteligencia viva aprendiendo, pero bajo condiciones específicas distintas del currículo formal. **Inteligencia del acoplamiento simulación-real** — la que se consolida cuando el interface es el mismo en simulación y operación real, y la cognición aprendida en uno se traslada al otro porque la estructura causal es idéntica. Articulada en `LRU_MISION` *"La continuidad entre simulación y control real"*. **Inteligencia de la ciencia aplicada en formalización activa** — lo que permite que la inteligencia física modelada en piezas virtuales sea fiel. El estado actual de la ciencia con sus formalismos verificados empíricamente. Muy estable relativo a las demás inteligencias del sistema, pero sigue evolucionando en regímenes extremos o en dominios nuevos. Articulada en §6.7 como *"estado de la ciencia"*. La lista **no está cerrada**. El proyecto probablemente encontrará más inteligencias a medida que explore dominios nuevos y acoples entre ellas. ### 11bis.2 · Lo que la pluralidad implica arquitecturalmente Cada inteligencia tiene: - **Vida útil propia** — desde la escala de siglos (leyes físicas bien formalizadas) hasta la escala de segundos (decisión cognitiva viva de un operador). - **Forma de verificación propia** — empírica repetible (física), contextual (guía normativa), histórica (caso real con investigación oficial), institucional (corpus regulatorio vigente). - **Disciplina de gestión propia** — quién la mantiene fresca, cómo se actualiza, qué responsabilidad ética tiene quien la usa. - **Modo de consumo propio** — se ejecuta (pieza virtual funcional), se aplica paso a paso (guía), se analiza con distancia ética (caso con nombre), se encarna en rol (inteligencia institucional), se ejercita en vivo (inteligencia cognitiva). El sistema LRU no es plataforma de una sola naturaleza de inteligencia; **es lugar donde muchas inteligencias de naturalezas distintas coexisten y operan juntas**. ### 11bis.3 · La distinción estructural — entidades funcionales vs entidades declarativas Dentro del Realm coexisten dos funciones estructuralmente distintas que el marco actual no nombra como tales: **Entidades funcionales** — piezas virtuales que **ejecutan comportamiento**. Un sensor que produce lecturas según modelo de lectura; un motor virtual que responde a comandos con dinámica interna; un actuador digital con latencia propia. Estas entidades **participan del bucle** bidireccional con las piezas reales. El tiempo corre en ellas — tienen estado que evoluciona con las ecuaciones del dominio o con el modelo simulado. **Entidades declarativas** — inteligencia que **actúa sobre otras entidades**. Una guía que describe qué hacer según las lecturas de los sensores; un escenario que programa qué inyectar en el tiempo; un caso histórico que describe qué ocurrió y qué lección dejó; una competencia que declara el estándar al que se debe ejecutar una tarea. Estas entidades **no participan del bucle directamente** — dirigen, describen o evalúan lo que ocurre en el bucle. La distinción tiene consecuencias arquitecturales: las entidades funcionales tienen disciplinas de modelado físico (validación contra realidad, fidelidad numérica, tiempo real). Las entidades declarativas tienen disciplinas de expresividad (cobertura de casos, claridad de condiciones, trazabilidad a fuentes oficiales). Mezclarlas bajo el mismo tipo base del schema oculta una diferencia estructural importante. Realm v2 actual no hace esta distinción explícita: `EntityDef` con discriminador `kind` cubre principalmente entidades funcionales (sensores, escenarios como plan funcional); las guías no están modeladas como tipo de primera clase y los casos tampoco. Realm v3 probablemente se estructura con **dos ramas de primer nivel** — entidades funcionales y entidades declarativas — cada una con sus subtipos. Esta decisión corresponde a la sesión arquitectural dedicada (T-S67-A1); aquí se nombra la distinción como estructura subyacente a considerar. ### 11bis.4 · Relación con las primitivas existentes y con los 9 postulados La pluralidad de inteligencias no añade primitivas al sistema — lo organiza con claridad nueva: - **Las cinco primitivas de §2** (señal, conexión, actor, escenario, tiempo) son el **vocabulario común** sobre el que las distintas inteligencias operan. Son dimensiones del sustrato, no inteligencias en sí. - **Los 9 postulados integrados** describen operaciones del sistema que **cada una involucra una o varias de las inteligencias enumeradas**. El Postulado 1 articula el bucle donde opera la inteligencia viva cognitiva; los Postulados 2 y 7 son las dos formas de inteligencia enlatada (normativa e histórica); el Postulado 3 articula la inteligencia institucional; el Postulado 6 es el mecanismo por el que todas aprenden; el Postulado 8 es condición bajo la que la inteligencia emergente por jugabilidad opera; el Postulado 9 es la preservación del aprendizaje al cruzar la frontera simulación/real; la inteligencia física es el sustrato que §6.7 articula. - **La sesión multipistas de §5** es el espacio temporal donde las inteligencias se acoplan en vivo. Las distintas pistas preservan manifestaciones de distintas inteligencias (sensores reales = física + piezas virtuales; acciones humanas = inteligencia viva; aplicaciones de guías = inteligencia enlatada instanciada). La pluralidad no reemplaza ni reorganiza los postulados. **Les da marco unificador** que explica por qué los 9 convergen en un proyecto coherente y no son colección arbitraria de observaciones. ### 11bis.5 · Las dos clases de inteligencia enlatada y el papel de los casos La pluralidad enumerada en §11bis.1 deja implícita una distinción que merece articulación explícita porque tiene consecuencias arquitecturales y epistémicas fuertes. La exploración post-cierre de s69 la articuló por primera vez; este apartado la integra. Dentro del sistema coexisten **dos clases estructuralmente distintas de inteligencia enlatada**, con propiedades muy distintas y disciplinas de gestión separadas: **Inteligencia enlatada física** — modelos de las funciones de transferencia del mundo. Vida útil muy larga (siglos). Verificable empíricamente por repetibilidad experimental. Universal por dominio físico — la aerodinámica aplica en cualquier avión, no depende del fabricante. Los `namedFormulas` y las `derivations` del Realm son su forma técnica actual; las seis funciones aerodinámicas de `units.ts` son ejemplo vivo. Articulada en §6.7 como *"estado de la ciencia interconectado"*. **Inteligencia enlatada normativa** — guías estructuradas (QRH, troubleshooting, checklist, didáctica) que codifican juicio profesional sobre operación. Vida útil media (años a décadas). Verificable contextualmente. Específica por dominio operativo — una QRH de A320 no sirve para B737. El `GuideDef` candidato del Realm v3 es su forma técnica. Articulada en §8. ### El papel estructural de los casos reales — interface entre las dos clases Aquí la observación potente: **los casos reales del §10 son la interface entre las dos clases de enlatado**. Son eventos donde el modelo físico se cumplió rigurosamente — la física no falla — pero la inteligencia normativa aplicada falló en anticiparla, capturarla o resolverla adecuadamente. De ahí una asimetría empíricamente observable en cómo los accidentes actualizan el corpus: **Los accidentes producen actualizaciones del corpus normativo y casi nunca actualizaciones del corpus físico.** El corpus físico (ecuaciones, constantes, funciones de transferencia del nivel 0) es muy estable porque el referente — la naturaleza — es estable. Un accidente no invalida las ecuaciones de Navier-Stokes; las confirma al milímetro. Lo que el accidente revela es **que el corpus normativo no contemplaba bien la situación o no la manejaba bien** — faltaba un procedimiento, un checklist tenía un paso omitido, una formación no cubría cierto régimen, una comunicación entre actores era ambigua. Annex 13 de OACI es precisamente la **infraestructura institucional para convertir la lección del accidente en actualización del corpus normativo**, con mecanismos explícitos para que la actualización llegue al operador (enmiendas a regulaciones, Service Bulletins, revisiones de formación). Esta asimetría da lectura más precisa al **darwinismo digital** articulado en `LRU_MISION`: lo que evoluciona por selección contra la realidad es principalmente el corpus normativo, no el corpus físico. El darwinismo digital opera sobre las latas normativas; las latas físicas evolucionan por progreso científico interno, a escala de siglos. ### Consecuencia arquitectural para Realm v3 La distinción tiene implicaciones directas para T-S67-A1: - Las **dos clases de enlatado merecen disciplinas de declaración distintas**. Las entidades que encarnan inteligencia física (piezas virtuales funcionales, `namedFormulas`) tienen disciplina de trazabilidad a fuentes científicas, verificación empírica y permanencia. Las entidades que encarnan inteligencia normativa (`GuideDef` y variantes) tienen disciplina de versionado frecuente, trazabilidad a autoridad que la emite, vigencia temporal y revisión periódica. - **El `CaseStudyDef` merece tratarse como tipo interface** entre ambas — puede referenciar tanto modelos físicos (para reproducir el evento con fidelidad) como guías normativas (para analizar qué lata normativa falló o qué lata nueva se creó como lección). Esta articulación da al caso real estructura declarable no solo como narrativa cronológica sino como **punto donde la inteligencia enlatada normativa se actualiza por encuentro con la realidad**. Las piezas del addendum s69 `§4.5 · Las latas no neutras` (codificación de valores en guías y declarabilidad de "qué stakeholder cocinó esta lata") y `§7 · Linaje cultural` quedan preservadas en el destilado anillo 2 como material para sesiones futuras — la primera como semilla para sesión específica sobre ética del diseño normativo (no urgente, no bloquea T-S67-A1), la segunda como articulación filosófica disponible cuando el proyecto necesite situarse en tradición intelectual larga. --- ## 11ter · Pluralidad de realms coexistiendo sobre base común El sistema LRU no se piensa como **un** Realm aeronáutico ni como Realm genérico que admite "configuraciones aeronáuticas". Se piensa como **base común agnóstico + N realms específicos coexistiendo sobre él**, cada uno con su estructura propia, sin que ninguno contamine a los demás. El aeronáutico es el primer realm construido, no el único previsto ni el privilegiado arquitectónicamente. La articulación cristalizó en s85 durante un debate sobre dónde alojar `ATAChapterDef` — ¿en el schema base como concesión al dominio dominante, o en un paquete propio que reconozca su naturaleza específica? Manuel articuló en dos frases la respuesta y la consecuencia estructural completa. Ambas son **gold del proyecto** (Patrón 3) y se preservan literalmente: > *"La plataforma es agnóstica, el aeronáutico es específico, ATA es específico del aeronáutico."* — Manuel, s85 > > *"src/realm/aviation/ es un primer realm, podrá haber distintos tipos de realms, src/realm/ es el base y es agnóstico y común para el resto."* — Manuel, s85 La primera frase nombra **una jerarquía de pertenencia** — la plataforma engloba a los realms, los realms específicos engloban a sus piezas concretas. La segunda frase nombra **la consecuencia estructural** — el código se organiza separando base común y realms específicos como capas distintas, con realms hermanos coexistiendo en paralelo sobre el mismo fundamento. La cristalización refina el Postulado 5 (`LRU_MISION "El aeronáutico como primer realm — razones estratégicas"`) haciendo explícita su dimensión arquitectural: la palabra *"primer"* siempre presupuso pluralidad, pero hasta s85 esa pluralidad vivía como horizonte estratégico. A partir de s85 vive también como **estructura**. ### 11ter.1 · El base agnóstico y los realms específicos El sistema se organiza en dos capas estructurales distintas: **El base agnóstico** es el sustrato común que ningún dominio puede colonizar. Aloja las cinco primitivas (§2), el bucle perceptor-inteligencia-efector (§7), la sesión multipistas (§5), la realimentación universal (§6) y el schema declarativo del Realm con sus tipos transversales (`TaxonomyNode`, `EntityDef`, `ScenarioDef`, `FaultDefBase`, `ActuatorDef`, etc.). En código vive en `src/realm/`. Es agnóstico **por disciplina, no por casualidad** — cualquier referencia específica a un dominio concreto en este nivel se considera deuda y se renombra. Ejemplo histórico: el campo `systemId?` de `FaultDefBase` y `ActuatorDef`, que llevaba comentario literal *"ATA chapter"* y violaba la agnosticidad, fue renombrado a `taxonomyRef?` en s86 al materializar T-S84-A9. **Los realms específicos** son paquetes propios donde cada dominio aporta su estructura. Cada uno contribuye sus tipos, sus validadores y sus catálogos canónicos sin que ningún otro realm sepa de su existencia. El primer realm específico construido es el aeronáutico, materializado arquitectónicamente en s86 con T-S84-A9-mat: `src/realm/aviation/` aloja `ATAChapterDef` (capítulos ATA 100 / iSpec 2200) con su catálogo canónico de 18 chapters. Los realms hipotéticos previstos siguen el mismo patrón. Un realm industrial vivirá en `src/realm/industrial/` con tipos como `ISO14224ComponentDef` o equivalentes; un realm doméstico en `src/realm/domotics/` con su taxonomía de habitaciones y zonas; un realm médico, nuclear, automotriz o agrícola en su carpeta propia con la ontología de su dominio (CIE-11 e ICD-10 en clínico, INPO/IAEA en nuclear, ISO 26262 en automoción). El listado no está cerrado — es la dimensión del dominio del Postulado 5 enumerada estructuralmente. Un **realm concreto** (como `src/realm/examples/a320.realm.ts`) compone piezas del base común y piezas del realm específico correspondiente. Importa `EntityDef` y `TaxonomyNode` del base, importa `ATA_CATALOG` de aviation, y declara su contenido propio (sensores, actuators, scenarios, faults del A320). Es **encarnación**, no descripción — la distinción §14.1 aplica directamente. El base admite uso directo como realm agnóstico cuando un realm concreto no necesita ningún dominio específico (sandbox genérico, pruebas preliminares de hardware sin asignación de dominio, demos sin ontología comprometida). Es **uso secundario legítimo, no prioritario** — el base no se diseña en función de este uso, sino que lo permite como caso degenerado del modelo general. ### 11ter.2 · Lo que la pluralidad implica arquitecturalmente La estructura tiene cuatro consecuencias directas: **El base no privilegia a ningún dominio**, ni siquiera al aeronáutico aunque sea el primero construido y el más maduro empíricamente. La presión de que un patrón aeronáutico válido se filtre al base por familiaridad es deuda en formación, y se controla con la disciplina explícita de renombrar o reubicar cualquier referencia específica que aparezca en `src/realm/`. El precedente del renombre `systemId?` → `taxonomyRef?` en s86 es ejercicio empírico de esta disciplina. **Los realms hermanos no se contaminan entre sí**. El paquete `src/realm/aviation/` no sabe que existe `src/realm/industrial/` ni viceversa. Cada uno declara su universo de tipos completo y autónomo. La interoperabilidad entre dominios — cuando el proyecto necesite que un caso clínico utilice infraestructura de domótica, por ejemplo — emerge en realms concretos que importen de varios paquetes específicos a la vez, no en el base ni en los paquetes específicos. **Cada realm específico organiza sus tipos, validadores y catálogos en su propio paquete**. La validación Zod de `ATAChapterDef` vive en `src/realm/aviation/ata.ts` junto al tipo, no en `src/realm/validators.ts`. Esto es divergencia deliberada respecto al patrón del base (donde tipos en `types.ts` y validadores en `validators.ts` son ficheros separados) — el realm específico se autoencapsula. El sub-patrón está pendiente de consolidación tras 2-3 ejercitaciones más en realms futuros (T-S85-A2). **El plan de cada realm es propio**. El catálogo canónico, la lista de tipos, el alcance del paquete y el ritmo de llenado dependen del dominio. ATA en aviation arrancó con 18 chapters de un alcance β y se completa por uso (T-S85-A1). Realms futuros llegarán con sus propios alcances iniciales y sus propias progresiones, no con plantilla impuesta por aviation. ### 11ter.3 · Refinamiento del Postulado 5 El Postulado 5 (`LRU_MISION "El aeronáutico como primer realm — razones estratégicas"`) articula tres razones estratégicas para haber empezado por el aeronáutico — origen fundacional, modelo regulatorio mundialmente reconocido, consistencia tipológica como fuerza — y nombra reversibilidad y pluralidad de dominios candidatos en su párrafo de cierre. Hasta s85 la pluralidad vivía como horizonte estratégico: *"el trabajo de primer realm aeronáutico levanta la ontología; los realms siguientes la encarnan con sus propios contenidos"*. §11ter convierte ese horizonte en **estructura del modelo**. La palabra *primer* del Postulado 5 ya no significa solo orden cronológico ni adopción estratégica reversible; significa **posición arquitectural en una topología de realms hermanos coexistiendo sobre base común**. El aeronáutico ocupa el primer hueco arquitectural; los demás dominios candidatos enumerados en MISION (medicina clínica, planta industrial, reactor nuclear, cocina profesional, automoción, infraestructura energética, agricultura de precisión, biotecnología, electromedicina) ocupan huecos hermanos del mismo nivel cuando se construyan. El Postulado 5 sigue intacto en su dimensión de uso (la estrategia del por qué empezar por aeronáutico). §11ter le añade la dimensión fundacional (cómo se acomodan estructuralmente N realms sobre el base). Las dos dimensiones son complementarias, no competidoras — patrón análogo al doble plano del Postulado 8 (jugabilidad fundacional en `LRU_FUNDAMENTOS §11` + jugabilidad como vía de uso en `LRU_MISION`). ### 11ter.4 · Paralelo estructural con §11bis §11bis ("Pluralidad de inteligencias coexistiendo") y §11ter ("Pluralidad de realms coexistiendo") aplican el mismo patrón mental del proyecto a planos distintos. §11bis dice: el sistema LRU es lugar donde **N inteligencias de naturalezas distintas** (cognitiva humana, enlatada normativa, enlatada histórica, enlatada física, institucional, del diseñador, emergente por jugabilidad, del acoplamiento simulación-real, de la ciencia aplicada, física inamovible) coexisten y operan juntas sobre las cinco primitivas como vocabulario común. §11ter dice: el sistema LRU es lugar donde **N realms de dominios distintos** (aeronáutico, industrial, doméstico, médico, nuclear y los que vengan) coexisten y se construyen sobre el base común agnóstico como sustrato compartido. Las dos articulaciones son la **misma idea fundacional aplicada a dos ejes ortogonales del proyecto** — el eje de la naturaleza de la inteligencia y el eje del dominio del mundo. La coincidencia no es estilística: es evidencia de que el proyecto ha encontrado un patrón estructural propio para acomodar pluralidad. Cuando emerjan otros ejes que admitan N elementos sobre sustrato común (cinco postulados podrían ser candidatos a hacer emerger algo así, por ejemplo el Postulado 9 con la pluralidad de modos de uso del continuo simulación/real), el patrón será aplicable de nuevo. La consecuencia metodológica: **la pluralidad sobre sustrato común no es excepción puntual; es disciplina del modelo**. Cualquier sesión arquitectural futura que se encuentre debatiendo si un dominio merece tipo propio en el base o paquete específico, tiene resuelto el debate antes de empezar — paquete específico, salvo que pueda demostrar ser estructuralmente común a todos los dominios posibles. --- ## 11quater · El diseño del Realm como espacio de innovación dentro del respeto El Postulado 10 cristaliza un principio que el proyecto venía ejerciendo implícitamente desde su origen pero que no había llegado a articulación explícita. Su nombramiento en s84 — durante el diseño concreto de roles aeronáuticos, no como ejercicio filosófico abstracto — es ejemplo del patrón sano de cristalización del proyecto: los postulados emergen del trabajo real, no se inventan en abstracto. Esta sección integra el **Postulado 10** del destilado fundacional `lru_postulado_10_diseno_como_innovacion_s84.md` (cuarta cristalización fundacional · cuarta culminada en s91 con T-S84-F1) — postulado del **diseñador del Realm**, distinto de los postulados anteriores sobre el sistema (P1-P3, P6), el uso (P8, P9), el alcance (P5), la dinámica (P4) y el material (P7). P10 articula la libertad creadora de quien construye el Realm y la encuadra con disciplina honesta. El Postulado 10 es **postulado preoperativo a P8**: opera antes en la cadena causal del proyecto. Antes de que un usuario pueda jugar con un sistema (P8), alguien tuvo que diseñar el Realm que lo describe. La libertad de ese diseño es lo que P10 articula con rigor. Por eso la integración como §11quater respeta el cluster mental "plano fundacional de P8 + sus variantes estructurales" (§11 jugabilidad, §11bis pluralidad de inteligencias, §11ter pluralidad de realms, §11quater libertad del diseñador). ### 11quater.0 · Texto canónico > **Postulado 10 · El diseño del Realm como espacio de innovación dentro del respeto** > > El Realm describe potenciales estructurales. Su diseño respeta la realidad de los dominios que modela — el corpus regulatorio, las convenciones profesionales, las restricciones físicas — como marco orientador, pero no está obligado a reproducirla fielmente. El diseñador del Realm puede declarar configuraciones que la realidad actual no contempla cuando son estructuralmente coherentes y aportan valor formativo, exploratorio o innovador. La plataforma es espacio donde la imaginación, la creatividad y la inspiración son guías legítimas del diseño, no solo de su uso. La realidad pone reglas; el proyecto las respeta; el diseño añade. ### 11quater.1 · Articulación literal de Manuel — gold del proyecto Las dos articulaciones de Manuel durante s84 quedan preservadas literalmente como gold del proyecto. La primera surgió durante el debate sobre cómo modelar la transversalidad del Part-147 (centro de formación que necesita representar contextos de Part-145, Part-CAMO, etc., para fines didácticos): > *"Quiero representar a centro 147 y poder actuar como cualquiera de los otros tipos de organización porque es formación y en formación se puede actuar como cualquiera de los otros, en principio no modelamos con exactitud fiel la realidad es una aproximación y podremos cambiarla al menos virtualmente e implementar alternativas posibles. La formación y la creatividad no tienen fronteras y este es un ejercicio de innovación y creatividad, no nos limita la realidad nos pone reglas pero podemos aportar nuestra visión la imaginación, la creatividad la inspiración y otros son guía del proyecto."* > > — Manuel, s84 La segunda al confirmar la elevación a postulado: > *"Sí me parece muy bien el tratamiento merece un postulado 10."* > > — Manuel, s84 Estas dos voces son entrada autoritativa al postulado. Cualquier reformulación posterior debe poder leerse como articulación fiel de lo que estas frases dicen. ### 11quater.2 · Distinción respecto a postulados existentes El Postulado 10 se distingue con precisión de los postulados más cercanos para evitar lectura errada. **P10 vs P8 (jugabilidad como propiedad estructural).** El Postulado 8 (§11) articula que la jugabilidad **del sistema construido** es propiedad estructural — el usuario puede explorar el Realm A320 con configuraciones hipotéticas, fallos que nunca han ocurrido, secuencias improbables. El sistema lo permite por diseño. El Postulado 10 articula que la libertad de diseño **del Realm mismo** es propiedad estructural — el diseñador del Realm puede declarar configuraciones organizativas, normativas o didácticas que la realidad regulatoria no contempla. La plataforma lo permite por diseño. P8 opera sobre el acto de usar el sistema; P10 opera sobre el acto de construirlo. Son **complementarios y secuenciales**: P10 habilita configuraciones de Realm que P8 luego permite explorar. Sin P10, P8 estaría limitado a las configuraciones que la realidad regulatoria ya contempla. **P10 vs P9 (continuidad simulación↔control real).** El Postulado 9 (en `LRU_MISION`) articula que no hay frontera fuerte entre lo simulado y lo operativo — la misma plataforma sirve para formación, simulación, mantenimiento, fabricación, certificación, investigación y juego. P9 opera sobre el plano runtime (encarnación). P10 opera sobre el plano descriptivo (Realm como objeto declarativo): la diferencia entre lo real y lo innovado en el diseño del Realm sí debe nombrarse explícitamente. La invariante "descripción ≠ encarnación" del Realm v2 (principio fundacional desde s56) sigue intacta y P10 la refuerza con un nuevo eje de libertad en el plano descriptivo. **P10 vs P5 (agnóstico al dominio).** El Postulado 5 articula que la plataforma es agnóstica al dominio por diseño — capas 0-2 del schema no saben si modelan aviación, domótica, industrial o médico. P10 amplía esta agnosticidad en una dimensión nueva: dentro del dominio modelado (cualquiera que sea), el diseñador puede declarar configuraciones que la realidad de ese dominio no contempla. Si mañana se añade un Realm médico, el principio aplica igual: el diseñador puede declarar protocolos clínicos hipotéticos con marcador estructural para fines formativos sin pretender que existen en la práctica clínica establecida. P10 es por tanto **principio agnóstico al dominio**, materializado por primera vez en s84 sobre el dominio aeronáutico pero válido transversalmente. ### 11quater.3 · Materializaciones concretas en el schema P10 no es solo articulación filosófica. Tiene materialización concreta en el schema desde s84 y queda como disciplina activa para futuros tipos. **Primera materialización · `SimulatedContextDef.notEqualToReal: true` literal obligatorio.** Durante el debate de Tanda E sobre cómo modelar la transversalidad del Part-147, emergió la necesidad de un mecanismo en el schema que permita a cualquier organización declarar contextos operativos que encarna con fines didácticos sin pretender ser legalmente esos contextos. La decisión cristalizó como tipo de primera clase con campo `notEqualToReal: true` como **literal type obligatorio en TypeScript** (no `boolean`). Un `SimulatedContextDef` que no declare este campo no se valida — el schema fuerza que el diseñador nombre explícitamente la diferencia entre lo real y lo innovado. Vive en `RealmManifest.simulatedContexts?: SimulatedContextDef[]` y es referenciable por id desde cualquier `OrganizationDef`. Esta apertura honra P10 en su amplitud máxima: cualquier organización del Realm puede declarar contextos simulados que extienden lo real. **Segunda materialización · `OrganizationApprovalDef.notEqualToReal?: true` opcional.** El tipo de primera clase para representar el hecho regulatorio de aprobación de una organización por una autoridad incluye campo opcional para casos hipotéticos/didácticos. Permite declarar configuraciones del tipo *"este Realm explora qué pasaría si la autoridad aprobara a este centro Part-147 para una categoría que no existe todavía en la regulación"*. El campo opcional (no obligatorio como en `SimulatedContextDef`) permite que el mismo tipo sirva tanto para aprobaciones reales como para aprobaciones hipotéticas, siempre con disambiguación explícita cuando aplica. **Espacio para futuras materializaciones.** P10 no agota en estos dos tipos. Cualquier futuro tipo del schema puede honrarlo con marcadores análogos cuando la innovación de diseño lo justifique: `RoleDef` con variants didácticas, `RegulatoryFrameworkDef` con frameworks hipotéticos, `LicenseDef` con licencias compuestas que la regulación no contempla, `SimulatedContextDef` ampliado con `divergencesFromReal: string[]`. La regla operativa derivada de P10 (en `LRU_METODO §6bis`) aplica universalmente: cuando se declare configuración fuera de la realidad regulatoria, marcador estructural explícito. > **Nota s96 (2026-04-26)**: el par fundacional articulado arriba **queda cerrado en código vivo desde s95+s96**. La 1ª materialización (SimulatedContextDef.notEqualToReal: true literal obligatorio) se materializó en s95 (T-S84-A8 Tanda 2 · `aviation/organizations.ts`) con superRefine P10 explícito que emite mensaje didáctico además del rechazo estructural Zod. La 2ª materialización (OrganizationApprovalDef.notEqualToReal?: true literal opcional) se materializó en s96 (T-S84-A8 Tanda 3 · `aviation/approvals.ts`) preservando la opcionalidad para que el mismo tipo sirva tanto a aprobaciones reales como a hipotéticas. Adicionalmente s96 introdujo el escape P10 en superRefines cruzados como sub-patrón firme tras 2ª aplicación: superRefine (16) NominatedPersonDef.roleType×orgTypes (s95) y superRefine (31) AirworthinessDef.kind AD/SB/AMP coherence (s96) saltan la coherencia con el corpus EASA cuando el diseñador declara `notEqualToReal: true` honrando P10. Tres frentes complementarios del postulado activos en código: literal obligatorio (forzar nombrar la diferencia), literal opcional (permitir disambiguar cuando aplica), y escape en validaciones cruzadas (preservar libertad de innovación sobre coherencia con corpus real cuando se nombra explícitamente). ### 11quater.4 · Hilos transversales como ejercicio metodológico P10 tiene **dimensión metodológica** además de la dimensión sobre el contenido del schema. Durante s84 emergieron dos observaciones de Manuel que articularon material estructural de **hilos transversales** que el proyecto identifica, reconoce, trata con rigor cuando madura, y difiere estratégicamente cuando el momento no es el adecuado. **Aviónica como hilo técnico transversal.** Lo que el proyecto LRU lleva 28+ sesiones materializando (sensores, actuadores, señales, displays, comunicaciones, protocolos, ProtocolEncoding, DerivedSensorDef, EntityDef, DataPlane) es literalmente un framework declarativo para **aviónica integrada**. La definición reglamentaria EASA de "avionics system" — *aircraft system that transfers, processes, displays or stores data* — coincide semánticamente con lo que el schema ya modela. Esta lente cambia la lectura del schema: el proyecto modela formalmente lo que la industria aeronáutica describe textualmente en sus technical publications y opera técnicamente en sus IMA / ARINC 653 / ARINC 664. La infraestructura aviónica concreta se difiere a sesión dedicada (T-S84-A5) sin forzar resolución prematura. **ATA como hilo documental-organizador transversal.** El sistema ATA (ATA 100 / iSpec 2200) es el esqueleto organizador transversal de la documentación técnica aeronáutica desde los años 60. Atraviesa AMM, TSM, IPC, CMM, SRM, WDM y todas las demás technical publications. Indexa fault codes, procedures, parts, components, training modules. Es el sistema de coordenadas del corpus técnico aeronáutico. Materializado como `ATAChapterDef` en `src/realm/aviation/` por T-S84-A9-mat en s86 — primera materialización de la disciplina de hilos transversales. **La disciplina como ejercicio de P10.** Las dos articulaciones siguen el mismo patrón metodológico: (1) reconocimiento del hilo cuando emerge en el trabajo concreto; (2) articulación estructural explícita en el destilado; (3) tratamiento estratégico — diferimiento a sesión dedicada cuando el momento no es el adecuado, materialización cuando llega; (4) anclaje preparado para que la materialización futura tenga destino claro. Esta disciplina es ejercicio del Postulado 10 en su dimensión metodológica: el diseñador del Realm tiene libertad de ver y nombrar estructuras transversales que la mirada por dominio no captura, y libertad de tratarlas con rigor cuando maduran sin forzar resolución prematura. Es coherente con `LRU_METODO §5bis` *"un proyecto a la vez"* (cristalizado s74, integrado s76) y con el patrón complementario *"exploración vs implementación separadas"* (consolidado s81). ### 11quater.5 · Relación con `LRU_ARQUITECTURA §8` principio 11 implícito `LRU_ARQUITECTURA §8` registra desde s55 un **principio 11 implícito, pendiente de articulación explícita** — *"la plataforma es herramienta de aprendizaje"*. P10 lo amplía con matiz importante: la plataforma no es solo herramienta de aprendizaje pasiva — es espacio donde el aprendizaje incluye libertad de imaginar, explorar y declarar configuraciones que extienden lo que existe. La formación no es reproducción del manual; es ejercicio de creatividad estructurada dentro del marco de respeto. P10 no absorbe el principio 11 implícito · lo amplía. El principio 11 sigue como dimensión arquitectural propia pendiente de articulación si una sesión futura decide elevarlo. La diferencia es honesta: principio 11 articula la dimensión arquitectural (cómo se construye el sistema técnicamente para servir aprendizaje); P10 articula la dimensión del acto de construir (libertad del diseñador del Realm para innovar). Son cercanos pero no idénticos. ### 11quater.6 · Implicaciones para sesiones futuras P10 establece como **disciplina activa** para cualquier nuevo tipo del schema, cualquier nuevo campo, cualquier nueva relación: evaluar también bajo la pregunta *"¿este diseño contempla configuraciones innovadoras además de las reales?"*. Si la respuesta es no por defecto, se nombra explícitamente; si la respuesta es sí, se proporciona marcador estructural. Ejemplos de preguntas que sesiones futuras se harán: - Al diseñar `CaseStudyDef` (sesión dedicada al Postulado 7): ¿el schema permite casos hipotéticos didácticos además de casos reales documentados? ¿Cómo se nombra la diferencia? - Al diseñar `KnowledgeModuleDef` (T-S84-A3): ¿el schema permite módulos formativos que extienden los oficiales Part-66 Appendix I con material exploratorio? - Al diseñar `AvionicsPartitionDef` y la AvionicsInfrastructureLayer (T-S84-A5): ¿el schema permite particiones IMA hipotéticas para escenarios de exploración arquitectural más allá de las certificadas reales? Cuando se construyan los editores del Realm (Realm editor, Viewmap editor, Scenario editor), el editor debe **reconocer y mostrar visualmente los marcadores P10**. Un `SimulatedContextDef` en el editor aparece con badge visual identificando configuración simulada que no equivale a real. El usuario del editor (diseñador del Realm) tiene feedback visual de cuándo está dentro del marco regulatorio y cuándo está innovando. La transparencia es ergonomía de diseño honrada por el postulado: la plataforma no esconde la diferencia, la hace visible al diseñador en su herramienta de trabajo. Cuando se ejecuten sesiones formativas sobre Realms que contengan configuraciones P10-marcadas, los usuarios finales también deben tener feedback claro. Un alumno que opera en un `SimulatedContextDef` debe saber que está aprendiendo en contexto simulado equivalente, no en contexto real legalmente certificado. Esto conecta con `LRU_METODO §6` *"Disciplina ética sobre material de casos reales"* (integrado s70 desde Postulado 7) y con `LRU_METODO §6bis` *"Disciplina honesta sobre configuraciones simuladas"* (integrado s91 desde este postulado): dos disciplinas distintas sobre dos clases de material distintas, ambas operativas en paralelo. --- ## 11quinquies · Disposición evolutiva del diseño estructural del realm específico El Postulado 11 cristaliza una disposición que el proyecto LRU Platform venía ejerciendo implícitamente desde s84 pero que no había llegado a articulación explícita. Su nombramiento en s98 — durante el destilado fundacional dedicado a la cristalización sembrada en s97 D1, no como ejercicio filosófico abstracto — es ejemplo del patrón sano de cristalización del proyecto: los postulados emergen del trabajo real, no se inventan en abstracto. Esta sección integra el **Postulado 11** del destilado fundacional `lru_estructura_sectorial_s98.md` (sexta cristalización fundacional · sexta culminada en s99 con T-S97-F1) — segundo postulado del **diseñador del Realm**, complementario al Postulado 10. P10 articula la libertad creadora del diseñador sobre el contenido del Realm; P11 articula la disciplina evolutiva del diseñador sobre la estructura del realm específico. Forman par natural fundacional: la libertad creadora de P10 sin la disciplina evolutiva de P11 sería caos creativo; la disciplina evolutiva de P11 sin la libertad creadora de P10 sería rigidez estructural sin innovación. Juntos articulan **creatividad estructurada como disciplina del diseñador del Realm**. P11 es además **culminación tardía** de tensión articulada en s71 que llevaba 27 sesiones diferida (T-S71-A1/A2). Las 13 sesiones intermedias (s84-s97) ejecutaron tácitamente el "Camino II+" que s71 había recomendado — aeronáutico-first con anotación explícita de frontera dominio↔modelo. P11 nombra retroactivamente la disciplina que esas 13 sesiones ejercieron sin articular. La integración como §11quinquies completa el cluster mental del plano fundacional de P8 (§11 jugabilidad, §11bis pluralidad de inteligencias, §11ter pluralidad de realms, §11quater libertad del diseñador sobre contenido, §11quinquies disposición evolutiva del diseñador sobre estructura). ### 11quinquies.0 · Texto canónico > **Postulado 11 · Disposición evolutiva del diseño estructural del realm específico** > > El realm específico se estructura con cuidado sobre lo conocido hoy, sin anticipar formas que aún no tienen disparador real. Las relaciones entre sus piezas son explícitas y planas; las jerarquías y abstracciones se difieren hasta que emerjan de necesidad material concreta. Cada sector decide su propia forma estructural a medida que se construye, sin replicar plantilla impuesta de otros sectores. La estructura se compromete con la legibilidad presente y con la capacidad de reestructuración futura, no con la corrección anticipada de un diseño ideal. La realidad pone reglas; el proyecto las respeta; el diseño las estructura como puede leerse hoy y reestructurarse cuando llegue. La resonancia deliberada en la última frase con el cierre del Postulado 10 (*"La realidad pone reglas; el proyecto las respeta; el diseño añade"*) nombra el par fundacional del diseñador. ### 11quinquies.1 · Articulación literal de Manuel — gold del proyecto Las tres articulaciones de Manuel durante s97 D1 quedan preservadas literalmente como gold del proyecto. La primera surgió cuando Claude planteó la pregunta sobre el nombramiento del tipo nuevo: > *"Ahora estamos definiendo la aviación en general y algún avión en particular como puede ser el A320; después describiremos otros modelos de aviones como pueden ser el A350 o el A380 de Airbus, también podríamos definir el avión B737 o el avión B747 de Boeing, o podríamos definir otros modelos de aviones de otros fabricantes. Esto es el sector aeronáutico, que engloba aviones y otros actores relacionados. En el futuro definiremos otros sectores con sus actores, modelos y submodelos de máquinas, sistemas, instalaciones o lo que corresponda, que pueden no ser iguales y pueden diferir. Si estructuramos bien la información, nos puede ayudar a ser homogéneos y facilitarnos en el futuro seguir ampliando a otros sectores."* > > — Manuel, s97 D1 La segunda al confirmar la disposición operativa no-anticipatoria: > *"Ahora no tenemos necesidad de describirlos porque tenemos el objetivo de crear el primer modelo funcional, pero teniendo en cuenta la estructura para que no hagamos algo sin estructura que nos obligue constantemente a rehacer lo hecho."* > > — Manuel, s97 D1 La tercera al articular la estructura plana como decisión consciente sobre alternativas jerárquicas: > *"Podrá haber algún realm que tenga muchas cosas particulares y especiales, pero eso lo ajustaremos y particularizaremos cuando llegue, no antes. Aviación en general podría ser un realm también, podría ser jerárquico sobre aviones, pero eso nos daría una estructura en árbol complicada; podríamos generarlo al mismo nivel como estructura plana y después establecer las relaciones con los aviones o con otras estructuras relacionadas. Tener una estructura plana ahora nos ayuda a tener todo más visible sin tener una estructura complicada; en el futuro podríamos reestructurarla."* > > — Manuel, s97 D1 Estas tres voces son entrada autoritativa al postulado. La voz s71 articuló la **tensión** y nombró el "sector" por primera vez en el corpus del proyecto; la voz s97 articula la **disposición** con material acumulado de 13 sesiones de ejecución tácita del Camino II+. Cualquier reformulación posterior debe poder leerse como articulación fiel de lo que estas frases dicen. ### 11quinquies.2 · Distinción respecto a postulados existentes El Postulado 11 se distingue con precisión de los postulados más cercanos para evitar lectura errada. **P11 vs §11ter (pluralidad de realms coexistiendo).** §11ter (cristalizado s85, integrado s89) articula la pluralidad de realms coexistiendo sobre base común agnóstica. Cada dominio tiene su paquete propio sin contaminarse entre sí. P11 opera **dentro** de cada realm específico. §11ter establece **autonomía espacial** del realm específico (cada uno en su paquete); P11 establece **autonomía formal** del realm específico (cada uno con su forma interna del schema). La relación es de continuidad: §11ter abrió la puerta a que cada realm fuera distinto; P11 declara que esa diferencia incluye también la forma interna, no solo la separación de paquetes. **P11 vs P10 (diseño del Realm como espacio de innovación).** P10 opera sobre **qué contenido puede declarar** el diseñador (configuraciones que la realidad no contempla, marcadas explícitamente). P11 opera sobre **qué forma estructural tiene el schema dentro del paquete del realm específico** y cómo esa forma evoluciona sin anticiparse. Par natural complementario: postulado del diseñador sobre el contenido + postulado del diseñador sobre la estructura. **P11 vs P9 (continuidad simulación↔control real).** P9 opera sobre el plano runtime; P11 opera sobre el plano descriptivo. Hay alineación profunda en disposición: P9 articula *"navegar la corriente, no predecirla"* y *"desacoplamiento temporal y late binding"*; P11 aplica esa misma disposición al diseño estructural del schema — no anticipar formas que no tienen disparador real. **P11 es P9 aplicado al plano descriptivo del schema**. **P11 vs P5 (aeronáutico como primer realm).** P5 articula la adopción del aeronáutico como primer realm con reversibilidad implícita. P11 complementa P5 con disciplina estructural: cada uno de los dominios candidatos futuros (medicina, industrial, ferroviario, naval...), cuando se materialice, tendrá libertad para estructurar su propio realm específico según sus propias particularidades. La cadena P5 → §11ter → P11 narra el desarrollo del proyecto sobre el eje del dominio: estratégico (P5) → estructural espacial (§11ter) → estructural formal (P11). ### 11quinquies.3 · Materializaciones concretas en el schema P11 no es solo articulación filosófica. Tiene materialización concreta y empíricamente verificada en el schema desde s97 (T-S84-A8 Tanda 4) y queda como disciplina activa para futuros sectores. **Primera materialización · pattern singleton+plural en aviation.** Decisión P1 de s97 D1 (tras pushback constructivo de Manuel sobre unificación con `AircraftProfile`) cristalizó la primera estructura sectorial del proyecto. `AircraftProfile` y `AviationProfile` se declaran como tipos hermanos planos · ambos extienden `RealmProfile` base · ninguno contiene al otro. Sin abstracción `SectorProfile` que englobe ambos. La distinción **singleton ↔ plural** sigue criterio "compartido entre instancias del sector → singleton · divergente entre instancias → plural": el vocabulario regulatorio del sector (Part-66 europeo) es singleton (`AviationProfile?` en `RealmManifest`) porque hay una EASA, una regulación europea, un corpus canónico; los modelos físicos son plurales (`AircraftProfile[]`) porque hay múltiples aviones con características divergentes. La materialización honra P11 en cuatro frentes: (1) estructura plana, no jerárquica; (2) singleton vs plural según naturaleza; (3) opcionalidad respetando backward compatibility (`aviationProfile?` opcional permite que realms preexistentes sigan validando · "compromiso mínimo con el futuro"); (4) migración gradual sin breaking change (la transición del legacy `NOMINATED_PERSON_APPLICABILITY` al nuevo `aviationProfile.nominatedPersonApplicability` se hizo en s97 cerrando el `@todo P8(c) s95` con borrado completo del legacy · la estructura emergente reemplaza a la suelta cuando la nueva estructura está madura, no antes). **Espacio para futuras materializaciones.** P11 no se agota en el pattern singleton+plural materializado en aviation. Cuando lleguen sectores futuros, cada uno decidirá su propia forma estructural según sus propias particularidades. El pattern singleton+plural es **caso particular materializado primero**, no estructura impuesta a sectores siguientes. Industrial podría querer eje adicional de "proceso productivo"; medicina podría tener `protocolProfiles[]` plurales sin objetos físicos; ferroviario podría tener tanto `trainsetProfiles[]` como `infrastructureProfiles[]` plurales. La disciplina del proyecto es **dejar que cada sector encuentre su forma cuando llegue**, honrando P11 sin replicar plantilla. ### 11quinquies.4 · Hilos transversales como ejercicio metodológico P11 tiene **dimensión metodológica** además de la dimensión sobre la estructura del schema. Tres patrones transversales del proyecto operan como ejercicio del postulado y merecen articularse. **Estructura plana visible como herramienta del círculo incremental.** El proyecto opera sobre un **círculo incremental** que gira a través de las sesiones (cristalizado en s74 §9). La estructura plana visible que P11 exige es la herramienta que permite ese círculo: si la estructura del schema fuera jerárquica anticipatoria, cada vuelta del círculo tendría que descender por el árbol para ver el material; con estructura plana, cada vuelta lo ve directamente. La materialización aviation s97 lo demuestra empíricamente: las 11 colecciones aviation pobladas en `a320.realm.ts` con 53 entries totales son legibles directamente — un Claude nuevo entrando al proyecto puede ver toda la estructura aeronáutica sin descender por jerarquías. **Diferimiento estratégico como disciplina fundacional.** Las dos voces (s71 *"crear el primero y ver cómo responde a las expectativas y volver atrás o no"* + s97 *"podrá haber algún realm que tenga muchas cosas particulares y especiales, pero eso lo ajustaremos y particularizaremos cuando llegue, no antes"*), separadas por 27 sesiones, articulan la misma disciplina: **el diferimiento no es procrastinación · es disciplina arquitectural sostenida**. Coherente con `LRU_METODO §5bis` *"un proyecto a la vez"* y con el patrón complementario *"exploración vs implementación separadas"*. P11 amplía estos principios: **la abstracción estructural también puede ser sesión dedicada cuando emerja necesidad real**. **Anotación explícita de frontera como ergonomía del refactor futuro.** s71 §3.3 recomendó Camino II+ con la cualificación clave del símbolo "+": *cada decisión de diseño debe nombrar si el tipo resultante es candidato plausible a núcleo agnóstico futuro o es específico de dominio*. La materialización s97 implementa la anotación de frontera mediante **separación estructural**: `AviationProfile` y `AircraftProfile` como tipos hermanos planos cuya separación nombre-por-nombre es la anotación de frontera. Cuando llegue el segundo sector, la abstracción `SectorProfile` (si se decide hacer) tendrá material ya clasificado. **La separación estructural explícita es la forma más simple y robusta de anotar fronteras arquitecturales para refactor futuro** — ergonomía del refactor, facilita la operación que vendrá sin imponer la abstracción que aún no tiene disparador. ### 11quinquies.5 · Relación con `LRU_ARQUITECTURA §8` principio 11 implícito y con P10 P11 refuerza el **principio 1 arquitectural** (agnosia al dominio) en su dimensión estructural fina: la agnosticidad no es solo "el código de capas 0-2 no sabe del dominio", es también "el código del realm específico tiene libertad estructural propia". La cadena de refuerzos es: P5 establece agnosticidad estratégica · §11ter la materializa espacialmente (paquetes separados) · P11 la materializa formalmente (forma interna libre). P11 **no absorbe el principio 11 implícito** (*"la plataforma es herramienta de aprendizaje"*) registrado en `LRU_ARQUITECTURA §8`. P11 articula la dimensión del acto de construir el Realm (libertad estructural del diseñador del realm específico); el principio 11 implícito articula la dimensión arquitectural propia (cómo se construye el sistema técnicamente para servir aprendizaje). Son cercanos pero no idénticos. El principio 11 sigue pendiente de articulación arquitectural propia si una sesión futura decide elevarlo. P11 tampoco absorbe a P10. P10 opera sobre qué configuraciones del Realm puede declarar el diseñador (libertad sobre el contenido); P11 opera sobre qué forma estructural tiene el schema del realm específico (disciplina sobre la estructura). La diferencia operativa: P10 produce marcadores estructurales (`notEqualToReal: true`) cuando el contenido se aparta de la realidad regulatoria; P11 produce decisiones estructurales (singleton vs plural, plano vs jerárquico) cuando la forma del schema se elige conscientemente. Son disciplinas paralelas sobre dos clases de decisiones distintas que pueden coexistir sin solaparse. ### 11quinquies.6 · Implicaciones para sesiones futuras P11 establece como **disciplina activa** para cualquier nuevo sector que se materialice, cualquier nuevo tipo del schema dentro de un realm específico, cualquier decisión sobre forma estructural: evaluar bajo cuatro preguntas operativas. **Pregunta 1 · ¿Qué se comparte entre las instancias de este sector?** Lo compartido es candidato a singleton del sector. Si no se comparte nada concreto entre instancias (caso hipotético improbable), no hay singleton — el sector se compone solo de modelos plurales sin profile de sector. **Pregunta 2 · ¿Qué diverge entre las instancias de este sector?** Lo divergente es candidato a plural. Si todo diverge (caso hipotético improbable), el sector no tiene singleton viable — cada instancia es modelo independiente sin marco compartido. **Pregunta 3 · ¿La estructura propuesta es legible directamente sin descender por jerarquías?** Si requiere descender más de un nivel para ver el material, viola P11 — replantear como estructura plana o nombrar explícitamente la jerarquía como decisión consciente con disparador real. **Pregunta 4 · ¿La estructura propuesta tiene anotación de frontera explícita para refactor futuro?** Si la estructura mezcla en un mismo tipo material que probablemente divergirá entre sectores, viola Camino II+ — separar estructuralmente para que la frontera quede nombrada en código. P11 establece además **anti-anticipación** como disciplina principal: no abstraer `SectorProfile` (ni cualquier otra abstracción análoga sobre realms específicos) hasta que existan al menos dos sectores materializados con suficiente material para identificar qué es genuinamente común vs qué es específico de cada sector. La señal de que la abstracción es legítima sería: dos sectores materializados con material denso · campos que aparecen idénticos por nombre y estructura en ambos profiles del sector · refactor de dos a tres sectores que resulta costoso por duplicación de campos comunes. Antes de esa señal, anticipar la abstracción viola P11. La regla operativa derivada de P11 vive en `LRU_METODO §6ter` *"Disciplina evolutiva del diseño estructural"* (integrado s99 desde este postulado): cuando el diseño estructural de un realm específico abra alternativa entre estructura plana visible y estructura jerárquica anticipatoria, el realm declara la estructura plana hasta que necesidad material concreta dispare reestructuración. La complejidad estructural se gana, no se anticipa. --- ## 11sexies · El hardware físico como sustrato del sistema ### 11sexies.0 · Texto canónico > **Postulado 12 · El hardware físico es sustrato del sistema.** > > El sistema LRU se construye sobre encarnaciones físicas concretas que son sustrato suyo, no aplicación suya sobre hardware externo. Las encarnaciones existen operativamente desde el origen del proyecto · sostienen la primitiva Actor del núcleo · materializan el concepto twin físico-virtual · habilitan las cinco configuraciones operativas de la orquesta distribuida · y demuestran activamente la agnosticidad de dominio del proyecto cada vez que un sensor genérico alimenta un instrumento específico. El sustrato físico está articulado en tres encarnaciones con propiedades estructurales propias — microcontroladores con firmware, teléfonos con sensores, banco de pruebas con motor real — coexistiendo bajo una arquitectura común (la distinción `puerto ≠ canal`, los modos del RouterService, la cadena F4→F1) que las hace operacionalmente intercambiables sin que el resto del sistema sepa cuál está activa. ### 11sexies.1 · Articulación literal de Manuel — gold del proyecto Durante la sesión s53, en debate sobre cómo modelar la decisión BLE (si los 3 ESP32 iban en `a320.realm` o en `a320-hw.realm` separado), Manuel articuló: > *"Los dispositivos hardware se pueden utilizar en cualquier simulación — en un A320, B737, una casa, una fábrica. Los sensores también pueden proceder de otros dispositivos: un teléfono, un motor."* > > — Manuel, s53 Esta cita es **fundacional**: forzó el rediseño del schema Realm v1→v2 al hacer evidente que `a320-hw.realm` separado violaba la universalidad. Es, arqueológicamente, el momento donde el principio de universalidad del hardware se concreta con ejemplos. Complementariamente, en la misma sesión s53 sobre el concepto twin: > *"Lo físico y lo virtual son hermanos gemelos: cuando uno se mueve, el otro lo refleja. No importa cuál de los dos es la fuente — en el sistema operan como uno solo."* > > — Manuel, s53 Las dos citas se preservan como **gold del proyecto** (Patrón 3 de `LRU_METODO`) y dan voz a las dos dimensiones complementarias del postulado: universalidad del sustrato (cita 1) y indistinguibilidad operativa (cita 2). ### 11sexies.2 · Tres encarnaciones físicas con propiedades estructurales propias El sustrato físico no es homogéneo. Tres encarnaciones coexisten con propiedades estructurales **radicalmente distintas** que merecen articulación separada: **Encarnación 1 · Microcontrolador con firmware genérico** — ESP32 con firmware `rpc1cl` v2.1.0. Veinticinco puertos por dispositivo, predefinidos y agnósticos al realm: `temp1..3`, `adc1..6`, `ax/ay/az`, `gx/gy/gz`, `sd1..4`, `sw1..4`, `cnt1..3`. Tres dispositivos en producción (75 puertos totales). Siete entradas FPGA disponibles como ventana al horizonte LRM. **Presencia permanente** · disposición pre-declarada · sustrato profesional fijo. **Encarnación 2 · Teléfono con sensores variables por modelo** — la app de teléfono (T-S117-N4) opera doble rol simultáneo: soporte para humano-con-dispositivo (gestos, pantalla táctil) y dispositivo-físico-autónomo (acelerómetro, giroscopio, barómetro, GPS). **Presencia efímera** · sensores heterogéneos por modelo · sustrato distribuido oportunista. **Encarnación 3 · Banco de pruebas con motor real** — pieza profesional con sensores específicos del aparato (régimen, temperaturas, presiones, vibraciones). Validación cruzada Realm A320 híbrido. **Presencia ocasional** · sustrato profesional itinerante. Tratarlas como una sola pieza homogénea sería pérdida de información estructural. Son tres tipos de aparato del laboratorio, no variantes del mismo concepto. ### 11sexies.3 · Arquitectura común que hace las tres intercambiables Pese a las diferencias estructurales, las tres encarnaciones operan bajo una arquitectura común que las hace **funcionalmente equivalentes** para el cockpit consumidor. Tres piezas constituyen esa arquitectura común: **Pieza 1 · La distinción canónica `puerto ≠ canal`** (cristalizada en §8.2). El `puerto` es nombre físico del hardware (`adc1`, `ax`, `temp1`); el `canal` es nombre lógico asignado por el instrumento (`aguja_altitud`, `slider_throttle`); el `ChannelMap = Record` es el cableado que vive en el ORC. Esta distinción es la **bisagra estructural del sustrato** que permite que el mismo hardware alimente cualquier realm sin saber a cuál. **Pieza 2 · Los cuatro modos del RouterService** (`Loc`/`Rnd`/`HwSim`/`HwReal`). La señal `cas_capt` puede estar en cualquiera de los cuatro estados sin que el cockpit lo distinga. Los cuatro son legítimos y combinables. **Pieza 3 · La cadena de transducción de cuatro capas** (semántica · protocolo · transducción · física), articulada en `lru_fase4_signal_model.html §5`: cada capa solo conoce a su vecina · la semántica nunca menciona ADC · la física nunca menciona °C. La cadena evoluciona en escalas temporales radicalmente distintas (semántica ~nunca · protocolo décadas · transducción años · física meses). La indistinguibilidad operativa que estas tres piezas garantizan **es propiedad descriptiva del código existente**, no promesa abstracta. La escribe el ORC cada vez que un instrumento lee de un slot Float64 sin saber su procedencia. ### 11sexies.4 · El sistema como laboratorio real/virtual de señales Articulación nueva producida en s117 que canoniza una propiedad operativa que el proyecto venía sosteniendo distribuidamente: > **El sistema LRU es un laboratorio real/virtual de señales** — un espacio operativo donde las señales pueden venir indistintamente de fuentes reales o virtuales, en cualquier combinación, sin que el resto del sistema (cockpit · instrumentos · evaluación · grabación · replay) las distinga. Tres componentes constituyen el laboratorio: las **tres encarnaciones físicas** (§11sexies.2) son los tres tipos de aparatos disponibles; los **cuatro modos del RouterService** son los cuatro estados operativos que cada señal puede ocupar; la **cadena de transducción** es la bisagra invisible que hace operativa la indistinguibilidad. Las **cinco configuraciones operativas** de §12.2 (instructor en pantalla, alumnos en teléfonos, hardware real intercalado, viewer remoto, actor-proceso) son cinco modos legítimos y combinables del laboratorio. La formulación *"laboratorio real/virtual de señales"* se prefiere a articulaciones más abstractas (*"laboratorio empírico de la universalidad"*, propuesta inicial de Claude en s117) porque habla de **lo que el sistema literalmente hace cuando funciona**, no de un principio que se demuestra. ### 11sexies.5 · Refinamiento de postulados existentes sin invalidación P12 es **postulado transversal**: refina varios postulados anteriores sin invalidarlos · les añade dimensión material que estaba implícita pero no articulada. Siete acoplamientos: - **P1 (bucle perceptor-inteligencia-efector, §7)** · los perceptores físicos del bucle son operativamente las tres encarnaciones, no sensores abstractos sin encarnación. - **P5 (aeronáutico como primer realm)** · el sustrato físico es común a todos los realms posibles · está hoy más maduro que la pluralidad de realms. - **P6 (realimentación universal, §6)** · el bucle de realimentación se cierra en mundo físico · la FPGA es instanciación de hardware desde software. - **P9 (continuidad simulación↔control real)** · P12 articula el sustrato físico que hace operativa esa continuidad temporal · los dos postulados son complementarios. - **§2.3 (primitiva Actor)** · dos de los cuatro tipos de actor (humano-con-dispositivo, dispositivo-físico-autónomo) requieren sustrato físico. - **§11ter (pluralidad de realms)** · el sustrato físico es parte del base agnóstico común a todos los realms. - **§11bis (pluralidad de inteligencias)** · la inteligencia física inamovible se encarna empíricamente en las tres encarnaciones. P12 desplaza el centro de gravedad de la universalidad desde el lado semántico (P5 · §11ter) hacia el lado material (sustrato común físico). Ningún postulado existente queda invalidado · todos quedan completados con su dimensión material. ### 11sexies.6 · Implicaciones para sesiones futuras P12 establece como **disciplina activa** para el frente operativo *"hwObj productor de señales"* — entendido como dispositivo (físico o virtual) que escribe valores al DataPlane desde el lado físico, alimentando canales que los swObj consumen vía `channelMap`. Seis tensiones secundarias T-S117-N1..N6 sembradas en s117 orientan ese frente sin precipitar materialización: - T-S117-N1 · materialización de `puertoHwObj` en los 75 sensores HW. - T-S117-N2 · materialización de `HardwareProfile` como subclase de `RealmProfile`. - T-S117-N3 · BleAdapter para conexión directa ESP32 ↔ navegador. - T-S117-N4 · app de teléfono como hwObj productor. - T-S117-N5 · UI multi-teléfono con vistas parciales coordinadas. - T-S117-N6 · convención de gateway industrial para banco motor. P12 **no genera regla operativa propia en `LRU_METODO`** (a diferencia de P10/§6bis y P11/§6ter) porque articula propiedad estructural del sustrato, no disciplina sobre cómo se construye el Realm. Las disciplinas que P12 orienta viven en las tensiones secundarias con dirección concreta, no en abstracción metodológica general. Esto replica el patrón de §11ter (pluralidad de realms), que tampoco generó sección propia en METODO. P12 **no absorbe ni invalida** el principio 11 implícito de `LRU_ARQUITECTURA §8` ("la plataforma es herramienta de aprendizaje"), ni los Postulados 10 y 11. Coexiste con todos ellos articulando el plano material que los demás dan por supuesto. El destilado fuente — `lru_postulado_12_hardware_fisico_sustrato_s117.md` (913 líneas, 12 secciones, 11 citas verbatim preservadas, 11 sitios arqueológicos cruzados) — se preserva como referencia histórica post-integración. Tras integración s123, la regla de disputa T-S117-F1 queda retirada y este postulado vive aquí en el núcleo. --- ## 12 · La orquesta distribuida como horizonte La metáfora de la orquesta ha emergido en varias sesiones como forma natural de articular hacia dónde va el proyecto. Merece lugar propio en este documento porque no es decoración — es **modelo operativo** de algo que el sistema ya está habilitado para hacer. ### 12.1 · La metáfora, precisa En una orquesta musical real: * Las **señales** son las notas (lo que se toca). * Las **conexiones** son el aire que transporta el sonido, más la visibilidad mutua entre músicos. * Los **actores** son los músicos con sus instrumentos y capacidades distintas. * El **escenario** es la partitura (lo que están tocando). * El **tiempo** es el compás común sobre el que todo se despliega. * La **vista** de cada músico es su silla en la orquesta — su perspectiva personal: ve unos atriles, oye unos instrumentos más que otros, tiene su parte de la partitura delante, mira al director cuando corresponde. El director tiene su silla con vista de toda la orquesta. El primer violín tiene la suya. El timbalero la suya. La misma orquesta, la misma sala, la misma partitura, la misma música — **experiencias radicalmente distintas según la silla que ocupas**. Hay sillas que se pueden componer: un director asistente ocupa una casi igual a la del director principal pero sin la batuta. Un espectador ve todo pero no interviene. Un crítico registra y compara con partituras anteriores. ### 12.2 · Qué implica para el sistema Aplicar la metáfora con precisión significa que el proyecto soporta **configuraciones orquestales** donde múltiples actores participan simultáneamente con roles diferenciados: * **Instructor en pantalla grande** — ve toda la orquesta, interviene a voluntad, inyecta fallos, cambia escenario. * **Alumnos en teléfonos** — cada uno con una parte de señales asignada (combustible, motores, hidráulico, eléctrico). Cada uno aporta valores mediante sliders y switches a la señal que le toca. Ve su contexto mínimo más su parte. * **Hardware real intercalado** — un ESP32 aporta valores reales de un sensor que sustituyen lo que un alumno tocaría. Un motor físico en un banco de pruebas aporta sus parámetros al Realm en lugar de la pieza simulada. * **Viewer remoto** — un experto en otro continente observa la sesión en tiempo real sin intervenir, pudiendo grabar y recuperar sesiones anteriores para comparar. * **Actor-proceso** — un `SimService` externo aporta las partes que ningún humano está tocando, completando la coherencia del mundo. Todas estas configuraciones son **la misma operación arquitectural** (la conexión de actores al sistema) con distintos valores de parámetros. El proyecto no necesita productos distintos para cada una. Necesita el motor de vistas y los Realms suficientemente articulados. ### 12.3 · La formación como caso de primera clase Como establece `LRU_MISION`, la formación es **origen fundacional y caso de primera clase**. La orquesta es naturalmente un modelo formativo: * Aprender a tocar una parte implica aprender la señal, su rango esperado, su comportamiento bajo distintos regímenes. * Tocar en orquesta implica aprender a coordinar con otros músicos, ver qué aporta cada parte, entender cómo el conjunto es más que la suma. * La grabación permite revisar qué hizo cada músico, cómo reaccionó a la batuta, dónde se desvió del procedimiento. * El director puede inyectar fallos (notas extrañas, cambios de tempo) para ver cómo responde la orquesta. Todos los elementos están alineados. Lo que el proyecto ha ido construyendo pieza a pieza — `DataPlane`, `EnlacesPanel`, `SimService`, `Sim1`, `Debug1`, Realms, escenarios — converge naturalmente hacia esta operativa orquestal. ### 12.4 · Multi-dominio La fuerza de la abstracción es que la orquesta no es solo de aviación. Las mismas primitivas y operaciones sostienen: * Una orquesta **médica** donde varios especialistas monitorizan distintos sistemas de un paciente simulado, con el docente inyectando condiciones. * Una orquesta **industrial** donde operadores aprenden a gestionar una planta con PLCs, alarmas y procedimientos, con el instructor simulando incidencias. * Una orquesta **domótica** donde un técnico diagnostica una casa con múltiples sensores y actuadores de distintos fabricantes, usando protocolos reales. El proyecto ya contempla este horizonte multi-dominio (sección 11.4 del `LRU_PROJECT_REFERENCE` histórico: *"Realms para otros dominios — domótica, industrial, médico"*). El marco de primitivas articulado aquí hace viable esa expansión sin reinvención. --- ## 13 · Las introspecciones del sistema Un sistema maduro ofrece introspección sobre sus primitivas. Un sistema operativo tiene `top` para procesos, `df` para archivos, `netstat` para conexiones. Este sistema tiene — o tendrá — herramientas dedicadas a inspeccionar cada primitiva. | Primitiva | Herramienta de introspección | Estado | |---|---|---| | Señales | `DataPlaneDebug` + `Debug1` + `Sim1` SignalsPanel | Parcial | | Conexiones | `Analyzer1` | 3 protocolos de 9 implementados | | Actores | `Debug1` subsistema transversal + `RegistryDebug` | Parcial — viewer externo pendiente | | Escenarios | `EscenariosContext` + `SimSequenceRecorder` + `EnlacesPanel` | Disperso | | Tiempo | No existe herramienta dedicada todavía | Pendiente | Cada introspección es **legítima y merece herramienta propia**. La tentación de "meter todo en Sim1" es incorrecta: Sim1 es una vista de actor (capítulo 3), no una herramienta de introspección. Las herramientas de introspección son transversales a las vistas — un instructor puede tener Debug1 y Analyzer1 abiertos al mismo tiempo que Sim1, cada uno mostrando el sistema desde un ángulo distinto. La falta de herramienta dedicada al **tiempo** es reveladora. Hoy el tiempo se inspecciona indirectamente: mirando el DataPlane en vivo (presente), o abriendo una sesión grabada con SimSequencePlayer (pasado), o leyendo un escenario en EscenariosContext (futuro programado). No hay herramienta que unifique los tres tiempos en una interfaz. El viewer externo de Debug1, cuando se materialice, probablemente será esa herramienta. --- ## 14 · Tres distinciones que el proyecto sostiene Cerramos con tres distinciones conceptuales que aparecen repetidamente en el trabajo arquitectural y que merecen quedar enunciadas con claridad. Todas son base para razonar bien sobre el sistema. ### 14.1 · Descripción ≠ encarnación Un Realm **describe** un dominio. Una sesión concreta del sistema **encarna** ese Realm con actores específicos, conexiones concretas y un escenario activo. La misma descripción admite muchas encarnaciones. El Realm A320 puede encarnarse como simulación pura (todos los actores son SimService), como hardware real (actores son ESP32 reales), como replay histórico (actores son pistas grabadas de un vuelo pasado), o como híbrido de cualquier combinación. **El Realm no cambia en ninguno de esos casos** — lo que cambia es qué actor aporta qué señal. ### 14.2 · Puerto ≠ canal Un **puerto** es el nombre físico del hardware (`adc1`, `sd2`, `gpio17`). Un **canal** es el nombre lógico del instrumento (`aguja_altitud`, `led_alerta`, `slider_throttle`). El cableado entre mundos es precisamente **la asignación canal → puerto**. Esta distinción permite que un mismo instrumento (definido en términos de canales) se conecte a hardware con distintas distribuciones de puertos sin cambiar el instrumento. Es principio de desacoplamiento que el proyecto preserva desde sus inicios. ### 14.3 · Escenarios (cableado) ≠ scenarios (física) El proyecto usa los dos términos con significados distintos y precisos: * **Escenarios** (en español, en EnlacesPanel) — snapshots de cableado entre swObj y hwObj. Son presets de conexión. * **Scenarios** (en inglés, en sim-catalog) — definiciones de comportamiento temporal de señales: fases de vuelo, progresión de fallos. Un escenario (cableado) responde "quién se conecta con quién". Un scenario (comportamiento) responde "cómo evolucionan los valores". Son ortogonales. Una sesión puede cambiar cableado sin cambiar scenario, o al revés. El schema Realm v2 respeta esta distinción: los `ScenarioDef` son comportamiento temporal; el cableado vive fuera del Realm, en runtime. --- ## 15 · Nota de origen Este documento consolida trabajo acumulado a lo largo de muchas sesiones, pero cristaliza especialmente en **s57** (2026-04-18). Las contribuciones principales por sesión: * **s22** — arquitectura core con DataPlane como fuente de verdad y modelo de sesión multipistas bocetado. * **s29** — puente Signal Lab → SessionRecording, EffectTrack como pista específica. * **s32** — binding model y hardware model con distinción `sensorId`/`channel` y jerarquía 3 niveles. * **s33** — aircraft model como prehistoria del Realm v2. * **s51** — primeros apuntes sobre orquesta distribuida con múltiples teléfonos. * **s53** — rediseño arquitectural consolidado (4 capas, 3 servicios, señal con 8 dimensiones, 10 principios). * **s55** — `LRU_MISION` articulado, Debug1 como subsistema transversal, gaps del consolidated identificados. * **s56** — schema Realm v2 desplegado en `src/realm/`. * **s57** — articulación del marco conceptual presente: 5 primitivas, Vista de Actor, 4 operaciones, sesión multipistas como objeto temporal, tiempo como sustrato, orquesta como horizonte. * **s67** — cristalización fundacional de los 5 postulados en el destilado `lru_postulados_fundacionales_s67.md`, con OACI/EASA/FAA como modelo regulatorio empírico y corpus aeronáutico como referencia de sistema estructurado durante 75 años. * **s68** — integración de los Postulados 1, 2 y 3 del destilado s67 como secciones nuevas (en s68 numeradas §6, §7 y §8 — bucle perceptor-inteligencia-efector, guías estructuradas, actores en tres niveles; renumeradas en s70 a §7, §8 y §9). Las secciones que existían como §6-§9 antes de s68 (orquesta, introspecciones, distinciones, nota de origen) se renumeraron a §9-§12 en s68. La primitiva Actor de §2.3 se preserva como plano operativo en runtime, complementaria al plano estructural del actor (en s68 §8, en s70 §9). * **s70** — integración de los Postulados 6, 7 y 8 (plano fundacional) del destilado s69. Postulado 6 (realimentación como estructura causal universal) entra como nueva §6 ANTES de las secciones integradas en s68, deliberadamente, para que sirva de lente sobre todas las posteriores; las secciones s68 (Postulados 1-3) bajan a §§7-9 con sus subsecciones renumeradas y las referencias internas actualizadas. Postulado 7 (casos reales documentados como material didáctico de primera clase) entra como nueva §10. Postulado 8 plano fundacional (jugabilidad como propiedad estructural del sistema) entra como nueva §11; el plano de uso vive en `LRU_MISION`. Las secciones §§9-12 vigentes hasta s70 (orquesta, introspecciones, distinciones, nota de origen) bajan a §§12-15 sin cambios sustanciales salvo referencias cruzadas. La disciplina ética del Postulado 7 (caso con nombre se analiza, situación técnica se juega) se nombra en §10.6 y se codifica como regla operativa en `LRU_METODO`. El Postulado 9 (continuidad simulación-control real) vive integrado en `LRU_MISION`. El marco no era invención — era reconocimiento. Lo que hacemos aquí es nombrar piezas que el proyecto ya llevaba usando. --- *LRU Platform · Fundamentos del sistema · Documento vivo del núcleo · s57 · 2026-04-18 · ampliado s68 2026-04-20 con Postulados 1, 2 y 3 del destilado s67 · ampliado s70 2026-04-21 con Postulados 6, 7 y 8 (plano fundacional) del destilado s69 · ampliado s76 2026-04-22 con §6.7, §8.5, §11bis y §11bis.5 del destilado s71 + addendum s69 · ampliado s89 2026-04-25 con §11ter del destilado s85 · ampliado s91 2026-04-25 con §11quater (Postulado 10) del destilado s84 · ampliado s99 2026-04-26 con §11quinquies (Postulado 11) del destilado s98 · Manuel & Claude Opus 4.7*