#La Arquitectura Nebula™

#The Nebula Framework™ — Scientific Edition v1.0

La identidad institucional, el alcance de ingeniería, la nomenclatura y las relaciones documentales de esta edición corresponden al registro oficial NBL-FWK-009.

---

#Convenciones arquitectónicas

La Arquitectura Nebula™ define una arquitectura de referencia para materializar los principios científicos, epistemológicos, matemáticos y semánticos de The Nebula Framework™. No prescribe una implementación única ni declara obligatoria una plataforma tecnológica determinada.

En este documento, Architecture designa la organización fundamental de un sistema, expresada mediante sus elementos, relaciones, principios de diseño y evolución. Architecture Description designa la representación documentada de esa Architecture. Esta distinción es coherente con ISO/IEC/IEEE 42010:2022, que separa la arquitectura de una entidad de interés de la descripción utilizada para expresarla y establece requisitos para viewpoints, model kinds y architecture frameworks.

Un componente es una unidad arquitectónica con responsabilidades y contratos explícitos. Un servicio es una capacidad accesible mediante una interfaz gobernada. Un evento es una representación inmutable o versionada de algo que ocurrió o fue declarado. Un flujo es una secuencia de intercambio entre componentes. Un plano transversal es una capacidad que afecta varias capas, como identidad, seguridad, Semantic Infrastructure, Governance u observabilidad.

Las expresiones debe, deberá y no debe identifican requisitos de conformidad arquitectónica. Debería identifica una decisión preferente que admite excepciones justificadas. Puede identifica una alternativa permitida.

El estado Stable indica que esta versión constituye la referencia arquitectónica oficial. No implica que los productos, servicios, protocolos, bases de datos o tecnologías concretas hayan sido congelados.

---

#Prólogo

La arquitectura de un sistema científico no es neutral respecto al conocimiento que ese sistema puede producir.

Cuando una infraestructura conserva únicamente el último valor de una variable, elimina la trayectoria que condujo hasta él. Cuando combina una Observation con una predicción sin diferenciarlas, debilita la integridad epistemológica. Cuando asigna una identidad nueva sin registrar derivación, rompe la genealogía material. Cuando impide exportar modelos o datos, transforma una decisión tecnológica en una restricción científica. Cuando exige conectividad permanente, excluye contextos territoriales donde la operación debe continuar sin acceso estable a servicios remotos.

Las decisiones arquitectónicas determinan qué puede observarse, qué puede reconstruirse, qué puede corregirse y qué puede interoperar. Por ello, La Arquitectura Nebula™ no deberá comenzar con productos tecnológicos, sino con compromisos científicos.

The Nebula Framework™ sostiene que los procesos biológicos deben estudiarse como Biological Trajectories: representaciones temporales y contextualizadas de estados, eventos, intervenciones, Evidence e incertidumbres. Esa proposición requiere una infraestructura capaz de preservar continuidad desde el fenómeno material hasta la decisión.

La infraestructura deberá distinguir el proceso real de su representación. Deberá conservar señales brutas sin presentar todo registro como Evidence válida. Deberá relacionar Evidence con Knowledge Claims. Deberá ejecutar Scientific Models sin confundir sus Inferences con Observations. Deberá aplicar The Nebula Ontology™ para preservar significado. Deberá permitir que el conocimiento evolucione sin borrar las versiones anteriores que explican una decisión histórica.

Este conjunto de responsabilidades excede la arquitectura convencional de una aplicación. Nebula no es únicamente un sistema de captura, una plataforma IoT, un repositorio analítico, un Knowledge Graph o una solución de trazabilidad. Es una infraestructura de conocimiento distribuida donde convergen sistemas materiales, dispositivos, operadores, modelos, identidades, estándares, procesos científicos y decisiones institucionales.

La Arquitectura Nebula™ deberá operar, además, en condiciones heterogéneas. Parte de la infraestructura estará cerca del proceso biológico, donde la latencia, la conectividad y la disponibilidad energética pueden ser restrictivas. Otra parte residirá en servicios institucionales capaces de integrar información entre lotes, territorios, organizaciones y periodos. Algunas decisiones deberán tomarse localmente; otras requerirán análisis histórico o revisión humana.

Este documento adopta, por tanto, una arquitectura federada, modular, event-driven y semánticamente gobernada. La federación permite que las capacidades se distribuyan sin perder identidad. La modularidad reduce dependencia tecnológica. Los eventos preservan Temporal Evolution. La Semantic Infrastructure permite que los componentes compartan significado.

La arquitectura deberá ser suficientemente estable para sostener investigación reproducible y suficientemente evolutiva para incorporar nueva Evidence, estándares y dominios biológicos.

---

#Resumen Ejecutivo

La Arquitectura Nebula™ define cómo The Nebula Framework™ transforma Observations en Evidence, Knowledge Claims, Inferences y decisiones verificables.

Su principio rector es que la ciencia dirige a la tecnología. Los dispositivos, protocolos, bases de datos, modelos de inteligencia artificial y servicios de nube deberán seleccionarse en función de preguntas científicas, requisitos de Evidence, riesgos y Context of Use. Ninguna tecnología constituye un fin institucional por sí misma.

La arquitectura se organiza en cinco capas funcionales.

La Capa de Captura conecta procesos biológicos con instrumentos, sensores, operadores y sistemas externos. Conserva señales, muestras, eventos e intervenciones con su identidad y tiempo de origen.

La Capa de Evidence valida estructura, procedencia, integridad, calidad metrológica y contexto. Distingue Data Artifacts, Observations y Evidence. Un registro no se convierte en Evidence únicamente por haber sido almacenado.

La Capa de Conocimiento aplica The Nebula Ontology™, el Knowledge Model y el Knowledge Graph para relacionar entidades, Biological Trajectories, Scientific Models, Knowledge Claims y Governance.

La Capa de Inteligencia ejecuta análisis descriptivos, Scientific Models, motores de Inference y modelos de inteligencia artificial. Toda salida deberá conservar modelo, versión, entradas, incertidumbre y Context of Use.

La Capa de Aplicaciones expone capacidades a FermentOps®, RoastOps®, TraceOps®, Originblok®, Proof of Process™ y servicios futuros mediante interfaces estables.

Las cinco capas se encuentran atravesadas por planos de identidad y procedencia, Semantic Infrastructure, seguridad y privacidad, Governance, observabilidad, calidad y ciclo de vida.

La arquitectura adopta una distribución edge–institutional–federated. Las capacidades próximas al proceso deberán operar localmente cuando la conectividad sea limitada. La computación remota se utilizará para integración histórica, entrenamiento, coordinación y análisis intensivo. El modelo conceptual de fog computing de NIST proporciona una referencia para distribuir computación, comunicación, almacenamiento y control entre dispositivos y servicios centrales en sistemas IoT.

La comunicación podrá utilizar patrones sincrónicos y asincrónicos. MQTT 5.0 constituye una referencia para telemetría ligera bajo un modelo publish–subscribe, mientras CloudEvents proporciona una estructura interoperable y agnóstica de protocolo para describir eventos. OPC UA podrá utilizarse donde se requieran modelos de información industrial y comunicación desde dispositivos de campo hasta sistemas empresariales.

La arquitectura será offline-capable, pero no asumirá que todo componente deba operar completamente desconectado. Las capacidades críticas deberán declarar qué funciones continúan localmente, qué información se almacena temporalmente y cómo ocurre la reconciliación posterior.

Originblok® proporcionará identidad y procedencia, pero no dependerá constitucionalmente de blockchain. Proof of Process™ organizará pruebas sobre transformaciones, pero no confundirá integridad criptográfica con exactitud científica. Digital Terroir® representará contexto multiescalar. El Knowledge Graph conectará afirmaciones y Evidence, sin convertirse en una fuente automática de verdad.

La seguridad se basará en identidad, autorización explícita, mínimo privilegio y protección de recursos. NIST SP 800-207 define Zero Trust Architecture como una estrategia que evita conceder confianza implícita por la ubicación de red y concentra la protección en identidades, activos y recursos.

La Governance de inteligencia artificial deberá aplicar registro de modelos, evaluación de riesgos, monitoreo, explicabilidad proporcional y capacidad de retirada. NIST AI RMF 1.0 proporciona un marco voluntario para gestionar riesgos durante el diseño, desarrollo, despliegue y uso de sistemas de IA.

La evolución arquitectónica deberá preservar compatibilidad mediante contratos versionados, data migrations, event upcasting, Semantic Versioning gobernado y Architecture Decision Records. ISO/IEC/IEEE 15288:2023 proporciona un marco de procesos de ciclo de vida aplicable desde concepción y desarrollo hasta utilización, soporte y retirada, sin imponer una metodología única.

La arquitectura se validará mediante pruebas de conformidad, resiliencia, Interoperability, reconstrucción de procedencia, reproducibilidad de modelos, recuperación ante fallos, seguridad y capacidad de migración.

Deberá considerarse fallida si obliga a confundir Observation e Inference, destruye contexto, produce dependencia irreversible, no puede operar en condiciones territoriales reales o no permite reconstruir cómo una afirmación llegó a utilizarse en una decisión.

---

#Parte I — Fundamentos arquitectónicos

#1. Arquitectura y descripción arquitectónica

La Arquitectura Nebula™ deberá distinguir el sistema real de los documentos que lo describen.

La Architecture comprende componentes, responsabilidades, restricciones, interfaces, datos, despliegues y procesos de evolución. La Architecture Description comprende diagramas, viewpoints, contratos, decisiones y modelos utilizados para comunicarla.

Esta distinción evita asumir que un diagrama constituye la realidad operacional. Un componente puede aparecer aislado en una vista lógica y compartir infraestructura física con otros. Un flujo representado como una secuencia sencilla puede depender de colas, reintentos, reconciliaciones y controles de acceso.

La Architecture Description deberá declarar:

• sistema de interés;
• stakeholders;
• concerns;
• viewpoints;
• model kinds;
• decisiones;
• correspondencias;
• inconsistencias conocidas.

ISO/IEC/IEEE 42010:2022 establece requisitos para estructurar descripciones arquitectónicas mediante conceptos y viewpoints, pero no prescribe el método o herramienta de diseño. Nebula adoptará esta separación para permitir múltiples vistas sin confundirlas con arquitecturas independientes.

#2. Stakeholders y concerns

La Architecture deberá responder a concerns diferentes.

Los investigadores necesitan reproducibilidad y acceso a Evidence. Los operadores necesitan disponibilidad, respuestas comprensibles y mecanismos de intervención. Los Caficultores necesitan accesibilidad, control legítimo y beneficio. Los ingenieros necesitan contratos y observabilidad. Los reguladores necesitan reconstrucción y auditoría. Las organizaciones necesitan seguridad, continuidad y sostenibilidad.

Un diseño que optimiza únicamente latencia puede degradar trazabilidad. Un diseño que conserva toda señal indefinidamente puede generar costos y riesgos de privacidad. Un diseño que maximiza apertura puede vulnerar conocimiento territorial.

Los viewpoints deberán hacer visibles estas tensiones.

#3. Sistema de interés y entorno

El sistema de interés incluye:

• infraestructura de captura;
• servicios edge;
• comunicaciones;
• Evidence Infrastructure;
• Semantic Infrastructure;
• Scientific Model;
• aplicaciones;
• Governance técnica.

El entorno incluye procesos biológicos, usuarios, redes externas, laboratorios, proveedores, repositorios, sistemas regulatorios y servicios institucionales.

La frontera no deberá interpretarse como límite de responsabilidad. Una Observation generada por un laboratorio externo puede ingresar al sistema, pero su procedencia y competencia deberán conservarse.

---

#Parte II — Principios arquitectónicos

#4. La ciencia dirige a la tecnología

Toda capacidad deberá relacionarse con una pregunta científica, necesidad operacional o requisito de Governance.

La incorporación de un sensor deberá justificar variable, resolución, ubicación, incertidumbre y valor de información. La adopción de una base de grafos deberá responder a relaciones semánticas que no se gestionen adecuadamente mediante estructuras más simples. La adopción de IA deberá demostrar una mejora frente a líneas base.

Este principio impide architecture by fashion: construir alrededor de una tecnología y buscar posteriormente un problema.

#5. Los datos conservan su contexto

Ningún registro científico deberá separarse silenciosamente de:

• entidad observada;
• tiempo;
• procedimiento;
• instrumento;
• unidad;
• ubicación;
• calidad;
• procedencia;
• Context of Use.

La arquitectura deberá conservar el contexto como objeto gobernado y no como texto informal que se pierde durante integraciones.

#6. Toda Evidence es trazable

La trazabilidad deberá cubrir no solo materia y custodia, sino también datos, modelos, transformaciones y decisiones.

PROV-O proporciona una ontología para representar entidades, actividades, agentes y derivaciones en contextos heterogéneos. La arquitectura deberá reutilizar o alinear estas relaciones dentro del plano de procedencia.

La trazabilidad no implica verdad. Un registro íntegro puede contener una medición incorrecta. La arquitectura deberá preservar simultáneamente procedencia, integridad y calidad.

#7. Los componentes son modulares e interoperables

Cada componente deberá poseer responsabilidades limitadas y contratos explícitos.

La modularidad no equivale a fragmentación extrema. Un diseño distribuido introduce costo de coordinación, observabilidad y consistencia. Los límites deberán seleccionarse alrededor de capacidades estables, dominios semánticos y necesidades de aislamiento.

Interoperability deberá existir en niveles técnico, estructural, semántico y epistemológico.

#8. La evolución ocurre sin romper el conocimiento

La compatibilidad no significa congelar interfaces para siempre.

La arquitectura deberá permitir:

• nuevas versiones;
• deprecación;
• migración;
• lectura de datos históricos;
• coexistencia temporal;
• transformación semántica;
• retirada segura.

Una versión antigua deberá continuar siendo interpretable incluso cuando ya no se utilice para crear nuevos registros.

#9. La operación local conserva autonomía

Los sistemas territoriales deberán mantener las funciones críticas necesarias durante interrupciones de conectividad.

La arquitectura no deberá convertir la disponibilidad de Internet en requisito implícito para observar un proceso, registrar una intervención o aplicar un límite de seguridad.

#10. La confianza se verifica por capas

La confianza no se asignará globalmente a un dispositivo, usuario o servicio.

Cada interacción deberá evaluar identidad, autorización, integridad, contexto y riesgo. Esta posición es consistente con Zero Trust Architecture, donde la ubicación de red no concede confianza implícita.

---

#Parte III — Modelo arquitectónico general

#11. Las cinco capas funcionales

architecture-beta
    group process(cloud)[Biological and Territorial Domain]
    group capture(cloud)[Capture Layer]
    group evidence(cloud)[Evidence Layer]
    group knowledge(cloud)[Knowledge Layer]
    group intelligence(cloud)[Intelligence Layer]
    group applications(cloud)[Application Layer]

    service biological(server)[Biological Process] in process
    service operators(server)[Operators and Instruments] in process

    service acquisition(server)[Acquisition Gateway] in capture
    service edge(server)[Edge Runtime] in capture
    service sampling(server)[Sampling and Manual Entry] in capture

    service validation(database)[Evidence Validation] in evidence
    service eventstore(database)[Immutable Event Store] in evidence
    service provenance(database)[Provenance Registry] in evidence

    service ontology(database)[Semantic Infrastructure] in knowledge
    service graph(database)[Knowledge Graph] in knowledge
    service catalog(database)[The Nebula Library™] in knowledge

    service models(server)[Scientific Model Runtime] in intelligence
    service inference(server)[Inference Engine] in intelligence
    service registry(database)[Model Registry] in intelligence

    service ferment(server)[FermentOps®] in applications
    service roast(server)[RoastOps®] in applications
    service trace(server)[TraceOps®] in applications
    service origin(server)[Originblok®] in applications

    biological:R -- L:acquisition
    operators:R -- L:sampling
    acquisition:R -- L:edge
    edge:R -- L:validation
    sampling:R -- L:validation
    validation:R -- L:eventstore
    eventstore:R -- L:provenance
    eventstore:R -- L:ontology
    provenance:R -- L:graph
    ontology:R -- L:graph
    graph:R -- L:models
    registry:R -- L:models
    models:R -- L:inference
    inference:R -- L:ferment
    inference:R -- L:roast
    graph:R -- L:trace
    provenance:R -- L:origin

Las capas representan responsabilidades lógicas. No exigen despliegues físicamente separados. Una instalación piloto puede reunir varias capacidades en un único nodo, siempre que las responsabilidades continúen diferenciadas.

---

#Parte IV — Capa 1: Captura

#12. Propósito de la captura

La Capa de Captura conecta el proceso material con la infraestructura informacional.

Su función no consiste únicamente en recibir valores. Debe registrar actos de observación, muestreo, intervención y control con suficiente información para que posteriormente puedan evaluarse.

La captura deberá admitir:

• sensores digitales;
• instrumentos de laboratorio;
• entradas humanas;
• dispositivos móviles;
• controladores;
• sistemas externos;
• importaciones;
• archivos históricos.

#13. Acquisition Gateway

El Acquisition Gateway normaliza transporte y empaquetado sin alterar silenciosamente el significado.

Sus responsabilidades incluyen:

• autenticación del dispositivo;
• timestamping;
• recepción de mensajes;
• validación sintáctica;
• deduplicación;
• buffering;
• control de secuencia;
• etiquetado de procedencia;
• entrega al Edge Runtime.

No deberá ejecutar transformaciones científicas irreversibles sobre la señal bruta.

#14. Edge Runtime

El Edge Runtime proporciona capacidad próxima al proceso.

Deberá permitir:

• operación desconectada;
• persistencia local;
• reglas de seguridad;
• control de actuadores autorizado;
• preprocesamiento documentado;
• diagnóstico;
• sincronización posterior.

La arquitectura edge reduce dependencia de latencia y conectividad, pero introduce riesgos de divergencia, actualización incompleta y exposición física. El modelo de fog computing de NIST describe una distribución de recursos entre dispositivos y nube para sistemas IoT, referencia útil para esta separación de capacidades.

#15. Protocolos de captura

MQTT 5.0 podrá utilizarse para telemetría publish–subscribe cuando resulte apropiado por ancho de banda, desacoplamiento y dispositivos limitados. Su adopción deberá definir tópicos, calidad de servicio, sesiones, retención, seguridad y semántica del payload.

OPC UA podrá utilizarse para integración industrial y modelado de información de dispositivos y sistemas. Sus Companion Specifications demuestran un enfoque donde industrias y equipos definen modelos especializados sobre una infraestructura común.

La coexistencia de protocolos no deberá generar múltiples modelos semánticos incompatibles. Los adaptadores deberán mapear hacia contratos internos canónicos.

#16. Tiempo y sincronización

Toda Observation deberá distinguir:

• event time;
• acquisition time;
• processing time;
• record time.

El tiempo del dispositivo puede diferir del tiempo institucional. La arquitectura deberá conservar precisión, fuente y estado de sincronización.

Los mensajes fuera de orden no deberán reescribirse silenciosamente. Deberán integrarse mediante reglas bitemporales o de Event Time.

#17. Captura humana

Las entradas humanas son Observations legítimas cuando su procedimiento, autor, competencia y contexto se encuentran documentados.

La interfaz deberá evitar obligar al usuario a inventar precisión. Cuando una descripción sea cualitativa, deberá conservarse como tal.

---

#Parte V — Capa 2: Evidence

#18. Propósito de la Evidence Infrastructure

La Capa de Evidence transforma registros capturados en objetos evaluables.

Esta transformación comprende validación, no interpretación científica completa. Un dato puede ser estructuralmente válido y científicamente dudoso.

La capa deberá distinguir:

• raw artifact;
• parsed record;
• Observation candidate;
• validated Observation;
• Evidence Artifact;
• rejected or quarantined artifact.

#19. Inmutabilidad y corrección

Los registros originales deberán preservarse mediante append-only semantics cuando sea proporcional.

Una corrección no deberá reemplazar silenciosamente el dato original. Deberá producir:

• corrección;
• motivo;
• autoridad;
• relación con el antecedente;
• fecha de vigencia.

La inmutabilidad absoluta puede entrar en conflicto con privacidad, errores o requisitos legales. Nebula adopta preservación trazable, no una prohibición universal de eliminación.

#20. Validación estructural y semántica

La validación estructural determina si un registro cumple el contrato.

La validación semántica determina si las entidades, unidades, propiedades y relaciones corresponden con The Nebula Ontology™.

SHACL permite validar grafos RDF mediante shapes y restricciones. Podrá utilizarse para perfiles de Evidence, aunque la conformidad con un shape no demuestre exactitud científica.

#21. Calidad metrológica

La capa deberá incorporar:

• estado de calibración;
• rango;
• resolución;
• incertidumbre;
• límites de detección;
• ubicación;
• procedimiento;
• flags de calidad.

Una lectura fuera de rango no deberá descartarse automáticamente. Puede representar un fallo o un evento real. El estado deberá conservarse para revisión.

#22. Event Store

El Event Store preservará sucesos relevantes en secuencia lógica o temporal.

Eventos elegibles incluyen:

• Observation;
• Sampling;
• Intervention;
• State Transition;
• Identity Assignment;
• Custody Transfer;
• Model Inference;
• Decision;
• Correction.

CloudEvents proporciona una estructura estándar para describir eventos de forma independiente del protocolo. Nebula podrá utilizarla como envelope de transporte, manteniendo los payloads bajo contratos semánticos propios.

#23. Procedencia

El Provenance Registry deberá relacionar:

• artefactos;
• actividades;
• agentes;
• versiones;
• derivaciones;
• transformaciones.

PROV-O se diseñó para representar e intercambiar información de procedencia entre sistemas y contextos heterogéneos.

#24. Evidence negativa y cuarentena

Los registros que no superen controles deberán preservarse cuando posean valor para investigar fallos.

La cuarentena evitará que datos dudosos alimenten modelos operacionales sin perder la posibilidad de análisis.

---

#Parte VI — Capa 3: Conocimiento

#25. Propósito

La Capa de Conocimiento organiza Evidence mediante identidad, semántica y relaciones.

No deberá tratar toda afirmación del Knowledge Graph como verdadera. Deberá representar:

• Observations;
• Inferences;
• Hypotheses;
• Knowledge Claims;
• Evidence favorable;
• Evidence adversa;
• incertidumbre;
• revisión;
• Temporal Evolution.

#26. Semantic Infrastructure

La Semantic Infrastructure comprende:

• The Nebula Ontology™;
• vocabularios;
• mappings;
• units;
• identifiers;
• shapes;
• context definitions;
• schema registry;
• reasoning profiles.

JSON-LD 1.1 podrá utilizarse para expresar Linked Data mediante estructuras JSON, facilitando APIs sin perder contexto semántico.

SSN/SOSA constituye una referencia para Sensors, Observations, Samplers, Actuators, Procedures y Features of Interest. Los perfiles Nebula deberán declarar qué versión utilizan.

#27. Knowledge Graph

El Knowledge Graph deberá permitir consultas que atraviesen materia, proceso, Evidence y conocimiento.

Ejemplos:

• ¿Qué Observations respaldan una transición?
• ¿Qué Scientific Model generó una Inference?
• ¿Qué Lot deriva de una mezcla?
• ¿Qué Knowledge Claims permanecen restringidos a un Digital Terroir®?
• ¿Qué Evidence contradice una predicción?

El grafo podrá utilizar almacenamiento especializado, pero deberá permitir exportación mediante estándares abiertos.

#28. The Nebula Library™

The Nebula Library™ será el catálogo institucional de:

• documentos;
• datasets;
• Scientific Models;
• Ontology versions;
• APIs;
• schemas;
• RFC;
• Decision Records;
• experimentos;
• software;
• Evidence packages.

DCAT Version 3 podrá utilizarse para catalogar recursos sin sustituir el modelo científico de su contenido.

#29. Identity Resolution

La resolución de identidad deberá distinguir:

• mismo objeto;
• versión;
• derivación;
• similitud;
• equivalencia comercial;
• representación externa.

Originblok® administrará identidades y relaciones de procedencia, pero no deberá declarar sameAs cuando solo exista correspondencia aproximada.

#30. Genealogía material

La arquitectura deberá representar:

• división;
• mezcla;
• transformación;
• muestreo;
• transferencia;
• pérdida;
• reconciliación.

TraceOps® deberá alinearse con EPCIS 2.0 cuando sea pertinente, extendiendo la representación para incluir Evidence y Biological Trajectory.

GS1 Digital Link podrá relacionar identificadores físicos con recursos digitales resolubles, pero no reemplazará la Ontology ni la política de identidad de Nebula.

---

#Parte VII — Capa 4: Inteligencia

#31. Propósito

La Capa de Inteligencia convierte Evidence y conocimiento en análisis, Inferences y recomendaciones.

No deberá modificar retrospectivamente las Observations utilizadas. Toda ejecución deberá generar un artefacto derivado con procedencia.

#32. Scientific Model Runtime

El runtime deberá soportar:

• modelos descriptivos;
• modelos matemáticos;
• simulaciones;
• modelos probabilísticos;
• modelos causales;
• aprendizaje automático;
• modelos híbridos.

Cada ejecución deberá registrar:

• modelo;
• versión;
• inputs;
• parámetros;
• entorno;
• timestamp;
• output;
• incertidumbre;
• Context of Use.

#33. Model Registry

El Model Registry administrará:

• identidad;
• versiones;
• propietario;
• estado;
• Evidence;
• métricas;
• riesgos;
• dependencias;
• aprobación;
• retirada.

Un archivo de modelo no deberá desplegarse sin una Model Card o registro equivalente conforme al Modelo Científico Nebula™.

#34. Motor de Inferences

El motor podrá integrar:

• reglas semánticas;
• razonamiento temporal;
• modelos estadísticos;
• cálculos matemáticos;
• políticas operacionales;
• interpretación humana.

La arquitectura deberá distinguir inferencias deterministas, probabilísticas, algorítmicas y humanas.

#35. AI Governance

Los modelos de IA deberán someterse a:

• evaluación de riesgo;
• validación;
• monitoreo de deriva;
• análisis de subgrupos;
• explicabilidad proporcional;
• supervisión humana;
• rollback;
• retirada.

La arquitectura deberá permitir que una recomendación sea rechazada y que la intervención humana quede registrada.

#36. Online y offline inference

Las Inferences críticas y de baja latencia podrán ejecutarse en edge cuando el modelo, hardware y Governance lo permitan.

Los modelos intensivos podrán ejecutarse en infraestructura institucional.

La versión edge y la versión central deberán conservar compatibilidad de identidad y declarar diferencias de precisión.

#37. Drift y Temporal Evolution

El monitoreo deberá detectar:

• data drift;
• concept drift;
• calibration drift;
• sensor drift;
• context drift;
• performance degradation.

Una actualización de modelo no deberá reemplazar silenciosamente la versión utilizada anteriormente.

stateDiagram
    [*] --> Registered
    Registered --> Validated: evaluación científica
    Validated --> Approved: Governance
    Approved --> Deployed: publicación controlada
    Deployed --> Monitored: operación
    Monitored --> Recalibration: deriva limitada
    Recalibration --> Validated
    Monitored --> Restricted: desempeño parcial
    Monitored --> Withdrawn: riesgo o refutación
    Restricted --> Validated: nueva Evidence
    Withdrawn --> Archived
    Monitored --> Superseded: nueva versión
    Superseded --> Archived
    Archived --> [*]

---

#Parte VIII — Capa 5: Aplicaciones

#38. Principio de aplicaciones delgadas

Las aplicaciones deberán consumir capacidades compartidas y no replicar identidades, reglas o Knowledge Models de manera independiente.

FermentOps®, RoastOps® y TraceOps® podrán presentar vistas especializadas, pero deberán utilizar contratos comunes.

#39. FermentOps®

FermentOps® deberá integrar:

• Biological Trajectory;
• Observations;
• intervenciones;
• estados;
• Scientific Models;
• alertas;
• Decision Records.

La aplicación deberá operar con conectividad degradada para funciones críticas.

#40. RoastOps®

RoastOps® deberá preservar continuidad entre materia, historia previa, perfil térmico, equipo y resultados.

Las recomendaciones deberán declarar el Scientific Model y el Context of Use.

#41. TraceOps®

TraceOps® deberá administrar identidades, eventos, custodias y genealogías.

La trazabilidad logística no deberá confundirse con Proof of Process™.

#42. Originblok®

Originblok® deberá proporcionar:

• identidad persistente;
• resolución;
• procedencia;
• enlaces;
• firmas;
• historial.

Su arquitectura será tecnológicamente neutral respecto a blockchain. El mecanismo deberá justificarse según el modelo de confianza.

#43. Proof of Process™

Proof of Process™ construirá paquetes de Evidence capaces de respaldar afirmaciones.

Un paquete podrá incluir:

• identity graph;
• event sequence;
• Observation references;
• calibration records;
• Scientific Model outputs;
• signatures;
• validation status;
• limitations.

#44. APIs y SDKs

Las APIs deberán:

• utilizar contratos versionados;
• declarar semántica;
• aplicar autenticación y autorización;
• admitir paginación y errores;
• proporcionar idempotencia donde corresponda;
• evitar exponer detalles internos innecesarios.

Los SDKs deberán ser conveniencias sobre contratos públicos, no la única forma de integración.

---

#Parte IX — Planos transversales

#45. Plano de identidad y procedencia

Este plano deberá garantizar que cada objeto relevante pueda relacionarse con una autoridad de identidad y una historia de derivación.

Incluye:

• device identity;
• user identity;
• service identity;
• material identity;
• model identity;
• document identity;
• provenance.

#46. Plano semántico

El plano semántico gobierna:

• términos;
• schemas;
• Ontology;
• mappings;
• unidades;
• constraints;
• context definitions.

No deberá existir un schema de producción sin steward y versión.

#47. Plano de seguridad y privacidad

La seguridad se aplicará a datos en tránsito, reposo y uso.

La arquitectura deberá utilizar:

• autenticación;
• autorización;
• mínimo privilegio;
• cifrado;
• gestión de secretos;
• segmentación;
• audit logs;
• vulnerability management.

#48. Plano de Governance

Governance deberá definir:

• ownership;
• stewardship;
• aprobación;
• retención;
• clasificación;
• acceso;
• uso permitido;
• deprecación;
• retirada.

Una decisión técnica de alto impacto deberá conservar un Architecture Decision Record.

#49. Plano de observabilidad

La observabilidad deberá incluir:

• logs;
• metrics;
• traces;
• events;
• health checks;
• data quality;
• model performance;
• semantic conformance.

La observabilidad técnica deberá distinguirse de Observation científica.

#50. Plano de resiliencia

Cada servicio deberá declarar:

• dependencia;
• timeout;
• retry;
• idempotencia;
• circuit breaker;
• fallback;
• recovery point;
• recovery time.

Los reintentos no deberán duplicar eventos materialmente únicos.

---

#Parte X — Distribución edge, institucional y federada

#51. Edge Domain

El Edge Domain se sitúa cerca del proceso.

Deberá priorizar:

• disponibilidad local;
• baja latencia;
• seguridad operacional;
• almacenamiento temporal;
• sincronización;
• actualizaciones firmadas;
• diagnóstico remoto limitado.

#52. Institutional Domain

El Institutional Domain integra:

• historical store;
• Knowledge Graph;
• model training;
• Governance;
• catalogs;
• cross-site analytics;
• publication.

No deberá convertirse en un punto único de fallo para la operación local.

#53. Federation Domain

La federación permite colaboración entre organizaciones sin centralizar necesariamente toda la información.

Podrá utilizar:

• shared identifiers;
• signed claims;
• data spaces;
• controlled APIs;
• federated queries;
• selective disclosure.

#54. Sincronización

La sincronización deberá utilizar:

• immutable identifiers;
• checkpoints;
• conflict policies;
• causal metadata;
• idempotent operations.

Los conflictos no deberán resolverse automáticamente mediante «última escritura gana» cuando afecten Evidence o identidad.

flowchart LR
    P[Biological Process] --> E[Edge Node]
    E --> L[Local Event Store]
    L --> D{Connectivity}
    D -->|Available| I[Institutional Platform]
    D -->|Unavailable| Q[Offline Queue]
    Q -->|Restored| I
    I --> K[Knowledge Graph]
    I --> M[Model and Evidence Services]
    K --> F[Federated Exchange]
    M --> E2[Signed Model Package]
    E2 --> E

---

#Parte XI — Contratos, eventos y APIs

#55. Data Contracts

Todo flujo deberá poseer un contrato que declare:

• identidad;
• schema;
• semántica;
• unidades;
• temporalidad;
• calidad;
• version;
• owner;
• privacy classification.

#56. Schema Registry

El Schema Registry deberá conservar versiones y reglas de compatibilidad.

La validación sintáctica deberá ocurrir antes de aceptar un evento, salvo en canales de cuarentena.

#57. Event-driven Architecture

Los eventos permiten desacoplar productores y consumidores y preservar Temporal Evolution.

Sin embargo, event-driven no significa ausencia de contratos. Cada event type deberá poseer semántica, versión y owner.

#58. Commands y Events

Un Command solicita una acción.

Un Event declara que algo ocurrió.

La arquitectura no deberá utilizar eventos con nombres imperativos que oculten comandos ni presentar comandos fallidos como hechos.

#59. Idempotencia

Los componentes consumidores deberán gestionar duplicados.

La identidad del evento deberá ser distinta de la identidad de la entidad material.

#60. APIs sincrónicas

Las APIs sincrónicas son apropiadas para consultas y acciones con respuesta inmediata.

No deberán utilizarse para encadenar procesos largos que puedan ejecutarse de manera asincrónica.

---

#Parte XII — Almacenamiento y ciclo de vida de datos

#61. Polyglot Persistence

No existe una base de datos universal para todos los objetos.

La arquitectura podrá utilizar:

• time-series storage;
• object storage;
• relational storage;
• graph storage;
• event store;
• search index.

La proliferación deberá gobernarse. Cada tecnología adicional aumenta costo y complejidad.

#62. Raw, Curated y Knowledge Zones

La infraestructura podrá organizar datos en zonas:

#Raw Zone

Conserva artefactos originales.

#Curated Evidence Zone

Contiene Observations validadas y contextualizadas.

#Knowledge Zone

Contiene relaciones, Inferences y Knowledge Claims.

La promoción entre zonas deberá ser trazable y reversible.

#63. Retención

La retención deberá responder a:

• valor científico;
• obligación legal;
• privacidad;
• costo;
• reproducibilidad;
• riesgo;
• propiedad intelectual.

No todo dato debe conservarse indefinidamente.

#64. Reproducibilidad

Un resultado reproducible deberá conservar:

• dataset version;
• code;
• model;
• parameters;
• environment;
• Ontology version;
• execution record.

The Nebula Library™ deberá permitir resolver estos objetos incluso cuando hayan sido deprecados.

---

#Parte XIII — Seguridad, privacidad y Trust Infrastructure

#65. Modelo de amenazas

La arquitectura deberá considerar:

• suplantación de dispositivos;
• manipulación de sensores;
• alteración de eventos;
• replay;
• acceso no autorizado;
• exfiltración;
• model poisoning;
• adversarial inputs;
• pérdida de claves;
• insider threats.

#66. Identidad de servicios

Los servicios deberán poseer identidades verificables.

NIST SP 800-207A describe un modelo Zero Trust para aplicaciones cloud-native basado en identidades de aplicaciones y servicios, además de controles de red.

#67. Integridad criptográfica

Las firmas y hashes podrán demostrar integridad, autoría o secuencia.

No deberán presentarse como prueba de calidad científica.

#68. Privacidad

La arquitectura deberá aplicar:

• minimización;
• purpose limitation;
• access control;
• retention limits;
• de-identification;
• consent where applicable.

Digital Terroir® puede contener ubicaciones y prácticas sensibles, por lo que su acceso deberá gobernarse de manera explícita.

#69. Selective Disclosure

Proof of Process™ deberá permitir verificar una afirmación sin revelar toda la Evidence cuando existan restricciones legítimas.

Esta capacidad constituye una agenda de investigación para Trust Infrastructure.

---

#Parte XIV — Quality Attributes

#70. Matriz de atributos

#71. Trade-offs

Los atributos pueden entrar en tensión.

La retención completa favorece reproducibilidad y aumenta costo. La replicación mejora disponibilidad y complica consistencia. La explicación detallada mejora transparencia y puede revelar propiedad intelectual.

Los trade-offs deberán documentarse mediante Architecture Decision Records.

---

#Parte XV — Escalabilidad y extensibilidad

#72. Escalabilidad técnica

La arquitectura deberá escalar por:

• volumen de Observations;
• número de procesos;
• cantidad de modelos;
• consultas;
• usuarios;
• organizaciones.

La escalabilidad no deberá evaluarse únicamente mediante throughput. También deberá evaluarse el costo de preservar semántica y procedencia.

#73. Escalabilidad científica

Incorporar un nuevo dominio requiere demostrar que los conceptos centrales continúan siendo aplicables.

La transición de café a cacao no deberá consistir en cambiar etiquetas. Deberá evaluar:

• entidad material;
• proceso;
• variables;
• escalas;
• Scientific Models;
• riesgos;
• resultados.

#74. Extensiones de dominio

Los módulos de dominio deberán reutilizar el núcleo y añadir términos específicos.

No deberán redefinir Observation, Evidence, Lot o Biological Trajectory salvo que exista una incompatibilidad demostrada.

#75. Multi-tenancy

Cuando varias organizaciones compartan infraestructura, deberán separarse:

• identidad;
• acceso;
• configuración;
• datos;
• modelos;
• Governance.

La separación lógica deberá probarse.

---

#Parte XVI — Gobernanza Arquitectónica

#76. Architecture Board

La Governance deberá designar una función responsable de:

• principios;
• viewpoints;
• estándares;
• Decision Records;
• excepciones;
• roadmap;
• debt;
• conformance.

#77. Architecture Decision Records

Toda decisión significativa deberá documentar:

• problema;
• contexto;
• alternativas;
• decisión;
• consecuencias;
• Evidence;
• fecha;
• autoridad;
• revisión.

#78. The Nebula RFC™

Las modificaciones de contratos públicos, Semantic Infrastructure o principios deberán seguir The Nebula RFC™.

Los cambios internos reversibles podrán utilizar procesos más ligeros.

#79. Excepciones

Una excepción deberá declarar:

• requisito incumplido;
• justificación;
• riesgo;
• mitigación;
• alcance;
• expiración;
• owner.

Una excepción permanente deberá motivar revisión del estándar.

#80. Deuda arquitectónica

La deuda incluye:

• componentes sin owner;
• contratos implícitos;
• duplicación semántica;
• versiones sin migración;
• servicios no observables;
• modelos sin registro;
• secretos no gestionados.

La deuda deberá cuantificarse y priorizarse según riesgo científico y operacional.

---

#Parte XVII — Ciclo de vida

#81. Etapas

stateDiagram
    [*] --> Conceived
    Conceived --> Designed: requirements and viewpoints
    Designed --> Prototyped: experimental implementation
    Prototyped --> Verified: technical tests
    Verified --> Validated: scientific and operational tests
    Validated --> Approved: Governance
    Approved --> Operational
    Operational --> Monitored
    Monitored --> Evolving: change required
    Evolving --> Validated
    Monitored --> Deprecated
    Deprecated --> Retired
    Retired --> Archived
    Archived --> [*]

ISO/IEC/IEEE 15288:2023 define procesos aplicables a concepción, desarrollo, producción, utilización, soporte y retirada de sistemas, sin imponer un único modelo de ciclo de vida. La Arquitectura Nebula™ utiliza esta orientación para organizar evolución y responsabilidad.

#82. Prototipos

Un prototipo deberá identificarse como experimental.

No deberá convertirse en infraestructura crítica sin validación y Governance.

#83. Deployment

Los despliegues deberán ser:

• reproducibles;
• firmados;
• versionados;
• reversibles;
• observables.

#84. Retirada

La retirada deberá preservar:

• datos históricos;
• contratos necesarios;
• exportación;
• documentación;
• dependencias científicas.

---

#Parte XVIII — Casos de uso arquitectónicos

#85. Caso A: conectividad interrumpida

Un nodo edge pierde conexión durante una fermentación.

El sistema deberá continuar registrando Observations e intervenciones, aplicar reglas de seguridad locales y almacenar eventos.

Al restablecerse la conexión, deberá sincronizar sin duplicar ni alterar event time.

#86. Caso B: sensor fuera de calibración

Una Observation procede de un sensor cuya calibración expiró.

El dato podrá preservarse, pero deberá recibir un quality status. Las Inferences que lo utilicen deberán conservar esa limitación.

#87. Caso C: nueva versión del modelo

Se despliega un Scientific Model mejorado.

Las Inferences previas deberán continuar relacionadas con la versión antigua. No se recalcularán silenciosamente salvo que se genere una nueva actividad explícita.

#88. Caso D: mezcla de lotes

Dos lotes se mezclan.

TraceOps® deberá crear una nueva identidad material, conservar inputs, cantidades, tiempo y autoridad. No deberá transferir automáticamente todos los Knowledge Claims a la mezcla.

#89. Caso E: Evidence contradictoria

Un análisis de laboratorio contradice una inferencia.

El Knowledge Graph deberá conservar ambas fuentes. El modelo podrá ser marcado como challenged y sus recomendaciones suspendidas.

#90. Caso F: organización externa

Una universidad aporta resultados.

La arquitectura deberá conservar identidad institucional, metodología, licencia, procedencia y restricciones de acceso.

---

#Parte XIX — Verificación y validación

#91. Verificación arquitectónica

La verificación determina si la implementación satisface la Architecture Description.

Incluye:

• contract testing;
• schema validation;
• security testing;
• performance testing;
• migration testing;
• fault injection;
• conformance.

#92. Validación científica

La validación determina si la infraestructura preserva las distinciones y Evidence necesarias para el Modelo Científico Nebula™.

#93. Validación operacional

Deberá evaluarse en condiciones reales:

• conectividad limitada;
• fallos de energía;
• dispositivos heterogéneos;
• operadores;
• datos fuera de orden;
• alta latencia;
• eventos duplicados.

#94. Interoperability testing

Dos implementaciones independientes deberán intercambiar:

• Observations;
• Biological Trajectories;
• Evidence packages;
• model records;
• identity events.

El receptor deberá reconstruir significado sin acuerdos secretos fuera del estándar.

#95. Security testing

Deberá incluir:

• penetration testing;
• credential compromise;
• replay;
• tampered firmware;
• unauthorized model deployment;
• privilege escalation.

#96. Recovery testing

La existencia de backups no demuestra capacidad de recuperación.

Los procedimientos deberán probarse periódicamente.

---

#Parte XX — Condiciones de refutación

La Arquitectura Nebula™ deberá revisarse o considerarse inadecuada si:

1. no puede distinguir Observations e Inferences;
2. destruye contexto durante integración;
3. no permite reconstruir procedencia;
4. exige conectividad permanente para funciones críticas;
5. los contratos impiden migración;
6. la Semantic Infrastructure no mejora Interoperability;
7. el Knowledge Graph produce falsa certeza;
8. los modelos no pueden retirarse;
9. la seguridad impide participación legítima;
10. la distribución introduce más riesgo que resiliencia;
11. los costos superan persistentemente el valor;
12. los dominios nuevos requieren redefinir el núcleo completo;
13. la arquitectura bloquea refutación científica;
14. los actores territoriales pierden control legítimo sobre su información;
15. la complejidad no mejora conocimiento ni operación.

La refutación podrá afectar un patrón, componente o principio de distribución sin invalidar necesariamente la totalidad del Framework.

---

#Parte XXI — Limitaciones

La primera limitación es representacional. Una Architecture Description nunca contiene la totalidad del sistema.

La segunda es temporal. Las tecnologías y amenazas evolucionan.

La tercera es territorial. La infraestructura deberá operar bajo restricciones heterogéneas.

La cuarta es metrológica. La arquitectura no corrige por sí sola Observations defectuosas.

La quinta es semántica. Las ontologías pueden contener errores.

La sexta es computacional. La procedencia completa genera volumen y costo.

La séptima es organizacional. La modularidad requiere coordinación y stewardship.

La octava es de seguridad. Ningún diseño elimina todo riesgo.

La novena es de privacidad. La trazabilidad puede revelar información sensible.

La décima es epistemológica. Una Inference trazable puede continuar siendo incorrecta.

La undécima es de adopción. Los estándares pueden ser rigurosos y no ser utilizados.

La duodécima es de complejidad. La arquitectura distribuida puede dificultar mantenimiento.

La decimotercera es económica. La independencia tecnológica posee costos de implementación.

La decimocuarta es ambiental. La infraestructura consume energía y materiales.

---

#Parte XXII — Agenda de investigación y evolución

#97. Offline-first Scientific Infrastructure

Investigar reconciliación bitemporal, sincronización y operación degradada.

#98. Semantic Event Architecture

Desarrollar perfiles que integren CloudEvents, The Nebula Ontology™ y procedencia.

#99. Evidence Packaging

Formalizar paquetes portables de Proof of Process™.

#100. Selective Disclosure

Investigar mecanismos para verificar Claims sin revelar toda la Evidence.

#101. Federated Knowledge Graph

Evaluar consultas y razonamiento entre organizaciones con control local.

#102. Edge AI

Determinar qué modelos pueden ejecutarse localmente con seguridad y reproducibilidad.

#103. Model Portability

Crear formatos y perfiles independientes de herramientas.

#104. Digital Terroir®

Desarrollar arquitectura de contexto multiescalar y sensible a privacidad.

#105. Architecture Metrics

Definir indicadores de semantic drift, Evidence completeness y reproducibilidad.

#106. Sustainability

Medir consumo de energía, almacenamiento y ciclo de vida de dispositivos.

timeline
    title Agenda de La Arquitectura Nebula™
    Fase I : Capture Gateway
           : Edge Event Store
           : Evidence Contracts
    Fase II : Semantic Infrastructure
            : Knowledge Graph
            : Originblok® Identity
    Fase III : Model Registry
             : Inference Engine
             : Proof of Process™
    Fase IV : Federated Exchange
            : Offline Reconciliation
            : Selective Disclosure
    Fase V : Independent Implementations
           : Cross-domain Validation
           : Nebula Architecture Standard

---

#Parte XXIII — Relación con The Nebula Framework™

#107. Modelo Científico Nebula™

Define qué debe observarse, modelarse y validarse.

La Architecture proporciona las capacidades para ejecutar ese ciclo.

#108. The Nebula Epistemology™

Define Data Artifact, Observation, Evidence, Inference, Hypothesis y Knowledge Claim.

La arquitectura deberá preservar estas distinciones en almacenamiento, interfaces y visualización.

#109. The Nebula Mathematics™

Define estados, eventos, variables, incertidumbre y Scientific Models.

La arquitectura deberá conservar sus unidades, parámetros, versiones y entornos.

#110. The Nebula Ontology™

Define identidad y significado.

La arquitectura deberá utilizarla como Semantic Infrastructure.

#111. Knowledge Model™

NBL-FWK-010 deberá especificar cómo se organiza y gobierna el conocimiento dentro de las capacidades arquitectónicas aquí definidas.

#112. The Nebula Constitution™

Governance, derechos, autoridad y revisión limitan todas las decisiones técnicas.

---

#Conclusiones

La Arquitectura Nebula™ establece cómo The Nebula Framework™ convierte principios científicos en capacidades operacionales sin subordinarlos a una tecnología específica.

Su estructura de cinco capas preserva una continuidad: Capture registra; Evidence valida y contextualiza; Knowledge organiza significado; Intelligence produce Inferences; Applications transforman esas capacidades en herramientas para personas y organizaciones.

La arquitectura distingue claramente el proceso material de su representación. Una Biological Trajectory no es el proceso, sino una Information Entity que integra estados, Observations, eventos, Inferences e incertidumbre.

La distribución edge–institutional–federated permite operar cerca del proceso sin aislar el conocimiento. La operación local protege continuidad; los servicios institucionales permiten integración histórica; la federación permite colaboración sin requerir centralización absoluta.

La Semantic Infrastructure ocupa una posición central. Sin Ontology, los contratos pueden intercambiar estructuras y perder significado. Sin procedencia, los resultados no pueden reconstruirse. Sin Temporal Evolution, las correcciones destruyen la historia. Sin Governance, la arquitectura puede concentrar poder y vulnerar derechos.

La modularidad protege al Framework frente a cambios tecnológicos, pero no deberá confundirse con una multiplicación indiscriminada de servicios. La complejidad deberá justificarse por aislamiento, escalabilidad, propiedad del dominio o resiliencia.

La seguridad no residirá únicamente en perímetros de red. Se basará en identidades, autorización, integridad, observabilidad y evaluación continua. La confianza no será un atributo binario de un componente; será el resultado verificable de varias capas.

La inteligencia artificial será una capacidad gobernada. Toda predicción deberá conservar modelo, versión, Evidence, incertidumbre y Context of Use. Toda intervención deberá mantener responsabilidad humana o institucional identificable.

La arquitectura deberá evolucionar. Sin embargo, evolucionar no significa reemplazar silenciosamente. Los contratos, modelos, schemas y ontologías deberán mantener versiones y migraciones. Los objetos históricos deberán continuar siendo interpretables.

La Arquitectura Nebula™ no será validada por la cantidad de tecnologías que integre. Será validada cuando pueda preservar una Observation desde su origen hasta una decisión, permitir que terceros autorizados reconstruyan esa trayectoria, continuar operando durante fallos, cambiar de componentes sin perder conocimiento y admitir nueva Evidence sin borrar el pasado.

Su objetivo final no es automatizar la biología.

Es construir una Living Knowledge Infrastructure™ donde la tecnología amplifique la comprensión científica, la capacidad territorial y la confianza verificable.

---

#Glosario

#Acquisition Gateway

Componente que recibe señales, eventos y registros desde dispositivos, operadores y sistemas externos.

#Architecture

Organización fundamental de un sistema expresada mediante elementos, relaciones, restricciones y principios de evolución.

#Architecture Decision Record

Registro de una decisión arquitectónica, sus alternativas, justificación y consecuencias.

#Architecture Description

Representación documentada de una Architecture mediante viewpoints, modelos y correspondencias.

#Biological Trajectory

Representación temporal y contextualizada de estados, eventos, Observations, intervenciones, Evidence e incertidumbres.

#CloudEvents

Especificación agnóstica de protocolo para describir eventos de manera interoperable.

#Computational Bioeconomy™

Campo interdisciplinario orientado a representar y gobernar transformaciones biológicas mediante conocimiento computacional.

#Data Contract

Acuerdo versionado que define estructura, semántica, calidad, ownership y reglas de intercambio de datos.

#Digital Terroir®

Modelo contextual multiescalar de condiciones territoriales, ambientales, biológicas, históricas y operacionales.

#Edge Runtime

Entorno de ejecución próximo al proceso que proporciona captura, persistencia, reglas y operación desconectada.

#Evidence Infrastructure

Conjunto de componentes que valida, contextualiza y preserva objetos utilizables como Evidence.

#FermentOps®

Aplicación operacional dedicada a procesos de fermentación.

#Governance

Sistema de autoridad, responsabilidad, políticas y procesos que regula la arquitectura.

#Inference

Afirmación derivada mediante Scientific Model, cálculo, regla o interpretación.

#Interoperability

Capacidad de intercambiar y utilizar información conservando estructura, significado, procedencia y estado epistemológico.

#Knowledge Graph

Representación computacional de entidades, relaciones y Knowledge Claims.

#Knowledge Model

Estructura conceptual mediante la cual se organiza y gobierna conocimiento.

#Living Knowledge Infrastructure™

Infraestructura que preserva Evidence, modelos, conocimiento y Temporal Evolution.

#Model Registry

Repositorio gobernado de identidad, versiones, validación, riesgos y estado de Scientific Models.

#MQTT

Protocolo publish–subscribe estandarizado por OASIS para intercambio de mensajes.

#Observation

Resultado contextualizado de un acto de medición, muestreo, inspección u observación humana.

#OPC UA

Arquitectura y conjunto de especificaciones para comunicación e información industrial interoperable.

#Originblok®

Infraestructura de identidad y procedencia del ecosistema Nebula.

#Proof of Process™

Paquete o conjunto de Evidence que respalda una afirmación sobre una transformación.

#RoastOps®

Aplicación operacional dedicada a transformaciones térmicas de tostado.

#Scientific Model

Representación formal o computacional utilizada para describir, explicar, simular o predecir un fenómeno.

#Semantic Infrastructure

Conjunto de Ontology, vocabularios, identifiers, schemas, mappings y validadores que preservan significado.

#Temporal Evolution

Cambio documentado de datos, modelos, conceptos, componentes y Knowledge Claims a través del tiempo.

#The Nebula Library™

Catálogo institucional de documentos, datasets, modelos, schemas, software y Evidence packages.

#TraceOps®

Aplicación operacional encargada de identidad, custodia, genealogía y eventos de trazabilidad.

#Trust Infrastructure

Conjunto de mecanismos científicos, semánticos, técnicos y de Governance que permiten evaluar identidad, integridad, procedencia y credibilidad.

#Viewpoint

Convención para construir una vista arquitectónica orientada a determinados stakeholders y concerns.

#Zero Trust Architecture

Enfoque de seguridad que evita conceder confianza implícita por ubicación y protege recursos mediante identidad y autorización explícitas.

---

#Bibliografía recomendada

1. International Organization for Standardization, International Electrotechnical Commission e Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 42010:2022 — Software, Systems and Enterprise — Architecture Description. 2022.

2. International Organization for Standardization, International Electrotechnical Commission e Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2023 — Systems and Software Engineering — System Life Cycle Processes. 2023.

3. Rose, S., Borchert, O., Mitchell, S. y Connelly, S. NIST SP 800-207 — Zero Trust Architecture. National Institute of Standards and Technology, 2020.

4. Chandramouli, R. y Butcher, Z. NIST SP 800-207A — A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. NIST, 2023.

5. Tabassi, E. Artificial Intelligence Risk Management Framework 1.0. NIST AI 100-1, 2023.

6. Iorga, M. et al. NIST SP 500-325 — Fog Computing Conceptual Model. NIST, 2018.

7. OASIS. MQTT Version 5.0. OASIS Standard, 2019.

8. Cloud Native Computing Foundation. CloudEvents Specification.

9. OPC Foundation. OPC Unified Architecture and UA Companion Specifications.

10. World Wide Web Consortium. PROV-O: The PROV Ontology. W3C Recommendation, 2013.

11. World Wide Web Consortium. Shapes Constraint Language — SHACL. W3C Recommendation, 2017.

12. World Wide Web Consortium. Semantic Sensor Network Ontology. W3C Recommendation, 2017.

13. World Wide Web Consortium. JSON-LD 1.1. W3C Recommendation, 2020.

14. World Wide Web Consortium. Data Catalog Vocabulary — DCAT Version 3. W3C Recommendation, 2024.

15. GS1. EPCIS and Core Business Vocabulary Standard. GS1 Standards.

16. GS1. GS1 Digital Link Standard.

17. Bass, L., Clements, P. y Kazman, R. Software Architecture in Practice. Referencia sugerida.

18. Hohpe, G. y Woolf, B. Enterprise Integration Patterns. Referencia sugerida.

19. Kleppmann, M. Designing Data-Intensive Applications. Referencia sugerida.

20. Newman, S. Building Microservices. Referencia sugerida.

---

#Anexo A — Viewpoints arquitectónicos

---

#Anexo B — Registro mínimo de componente

---

#Anexo C — Prueba de conformidad arquitectónica

Una implementación será compatible con La Arquitectura Nebula™ cuando:

1. preserve la diferencia entre proceso y representación;
2. distinga Data Artifact, Observation, Evidence e Inference;
3. conserve contexto y procedencia;
4. utilice contratos versionados;
5. aplique The Nebula Ontology™;
6. permita operación local proporcional;
7. gestione sincronización y conflictos;
8. preserve Temporal Evolution;
9. registre Scientific Models;
10. soporte rollback y retirada;
11. proteja identidades y recursos;
12. permita exportación interoperable;
13. documente Architecture Decision Records;
14. pruebe recuperación ante fallos;
15. mantenga trazabilidad desde Capture hasta Application.

---

#Anexo D — Canon arquitectónico

La ciencia dirige a la tecnología.

La captura no convierte automáticamente un registro en Evidence.

El contexto forma parte del dato científico.

Toda derivación deberá conservar procedencia.

Una Inference no deberá presentarse como Observation.

La operación crítica no dependerá innecesariamente de conectividad externa.

La modularidad deberá reducir dependencia, no multiplicar complejidad sin propósito.

La interoperabilidad deberá preservar significado y estado epistemológico.

La seguridad deberá proteger recursos mediante identidad y autorización explícitas.

Toda evolución deberá conservar la capacidad de interpretar el pasado.

---

#Anexo E — Declaración institucional

La Arquitectura Nebula™ constituye la referencia oficial para el diseño, implementación y evolución de los sistemas tecnológicos de The Nebula Framework™.

Su propósito es materializar el Modelo Científico Nebula™, The Nebula Epistemology™, The Nebula Mathematics™ y The Nebula Ontology™ mediante una infraestructura modular, interoperable, resiliente y gobernada.

Nebula reconoce que ninguna arquitectura es definitiva y que toda decisión tecnológica deberá permanecer abierta a evaluación, migración y sustitución.

La validez de esta Architecture dependerá de su capacidad para preservar Evidence, contexto, semántica, reproducibilidad y Temporal Evolution mientras opera bajo las condiciones reales de los territorios y organizaciones que integran el ecosistema.

Versión: 1.0.0
Estado: Stable
Idioma canónico: Español Latino (es-419)
Documento: NBL-FWK-009

The Nebula Framework™