ወደ ዋናው ይዘት ይዝለሉ
Nebula Foundations™

The Nebula Doctrine™

Documento fundacional que establece los principios doctrinales permanentes que orientan todas las decisiones científicas, tecnológicas e institucionales del ecosistema Nebula.

ይረጋጋምንጭv1.0.0·
ይህ ሰነድ በEspañol ይታያል ምክንያቱም ወደ Amharic የተተረጎመው ገና አይገኝም።

The Nebula Doctrine™

The Nebula Framework™ --- Scientific Edition v1.0


Campo Valor


Documento NBL-FWK-003

Estado Stable

Categoría Foundation

Versión 1.0.0

Idioma canónico Español Latino (es-419)

Traducciones previstas English · አማርኛ

Fecha efectiva 2026-07-19

Organización autora Cafelium SRL

Licencia Proprietary


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

Convenciones doctrinales

The Nebula Doctrine™ establece principios para orientar decisiones científicas, tecnológicas, semánticas, operacionales e institucionales. Su función no consiste en predecir el futuro, definir una implementación particular ni sustituir los procedimientos de Governance que serán desarrollados por The Nebula Constitution™. La doctrina determina los criterios mediante los cuales deberán evaluarse esas implementaciones y procedimientos.

En esta monografía, hecho designa una afirmación respaldada por Evidence verificable o por una fuente científica o normativa identificable. Hipótesis designa una proposición susceptible de contrastación y refutación. Interpretación designa una lectura razonada de la Evidence, sin asumir que sea la única posible. Decisión arquitectónica designa una elección técnica o semántica que puede modificarse cuando cambien las restricciones. Opinión institucional designa una posición adoptada por Nebula que deberá permanecer distinguible de los resultados científicos.

Las palabras «debe», «deberá», «no debe», «debería» y «puede» expresan diferentes niveles de fuerza doctrinal. Su utilización se inspira en la tradición normativa del IETF, particularmente en BCP 14, integrado por RFC 2119 y RFC 8174, aunque este documento no adopta automáticamente todas las convenciones formales de una RFC.

En consecuencia:

  • debe o deberá identifica una obligación necesaria para conservar coherencia con la doctrina;
  • no debe identifica una práctica incompatible con el Framework;
  • debería identifica una orientación preferente que puede admitir excepciones justificadas;
  • puede identifica una posibilidad legítima cuyo uso depende del contexto.

Toda excepción a un principio doctrinal deberá documentar su fundamento, alcance, duración, autoridad responsable y consecuencias previsibles. Una excepción no documentada no constituye evolución doctrinal; constituye pérdida de gobernabilidad.

Las instituciones científicas y tecnológicas suelen describirse mediante aquello que construyen: laboratorios, plataformas, algoritmos, productos, estándares o redes de colaboración. Sin embargo, la identidad intelectual de una institución no reside únicamente en sus artefactos. Reside también en los criterios que utiliza para decidir qué merece ser construido, qué Evidence considera suficiente, qué riesgos está dispuesta a aceptar y qué límites no debería cruzar.

Esta distinción adquiere especial relevancia en dominios donde la tecnología interviene sobre sistemas biológicos. Un proceso biológico no es un objeto completamente determinado por sus especificaciones iniciales. Está condicionado por relaciones dinámicas, variables no observadas, contingencias históricas, diversidad genética, actividad microbiana, condiciones ambientales, prácticas humanas y restricciones materiales. Su representación computacional puede ser rigurosa y útil, pero nunca debe confundirse automáticamente con la totalidad del fenómeno.

The Nebula Framework™ surge para investigar y construir una infraestructura de conocimiento alrededor de esas transformaciones. La Tesis Nebula™ formula la hipótesis de que los procesos biológicos susceptibles de observación pueden representarse como Biological Trajectories verificables. La Visión Nebula™ describe un futuro en el que esa capacidad contribuya a una Computational Bioeconomy™ interoperable, acumulativa y responsable. The Nebula Doctrine™ determina cómo deberán tomarse las decisiones mientras se intenta avanzar desde la hipótesis hacia la visión.

La necesidad de una doctrina no deriva de una preferencia ceremonial. Deriva de la inestabilidad del entorno tecnológico. Los sensores cambian. Los paradigmas de inteligencia artificial evolucionan. Los modelos de almacenamiento se reemplazan. Las arquitecturas centralizadas pueden dar paso a estructuras federadas. Las tecnologías de registros distribuidos pueden resultar apropiadas para ciertos casos e innecesarias para otros. Los estándares se revisan, los mercados se reorganizan y aparecen nuevas obligaciones regulatorias.

Una organización guiada únicamente por tecnologías específicas corre el riesgo de perder continuidad cada vez que cambia su arquitectura. Una organización guiada solo por objetivos comerciales puede abandonar el rigor científico cuando los resultados inmediatos recompensan la simplificación. Una organización guiada exclusivamente por investigación puede producir conocimiento relevante sin desarrollar mecanismos para convertirlo en capacidad territorial, operacional o social.

La doctrina proporciona un nivel de estabilidad diferente. No declara qué base de datos deberá utilizarse, qué algoritmo deberá desplegarse ni qué protocolo deberá controlar un proceso. Declara que la Evidence precede a la opinión, que la transformación constituye el objeto central de estudio, que el contexto otorga significado, que el conocimiento debe ser reproducible, que la tecnología es un medio, que la Interoperability fortalece el ecosistema, que la evolución es continua y que la confianza se construye mediante transparencia verificable.

Estos principios no son independientes. Forman un sistema de restricciones y responsabilidades. La Evidence sin contexto puede inducir interpretaciones erróneas. El contexto sin reproducibilidad puede producir narrativas imposibles de contrastar. La transparencia sin Governance puede vulnerar derechos. La evolución sin memoria puede borrar conocimiento. La interoperabilidad sin soberanía puede facilitar extracción. La tecnología sin propósito puede convertir el Framework en una sucesión de soluciones en busca de problemas.

The Nebula Doctrine™ existe para impedir que la sofisticación tecnológica sustituya al juicio científico y para impedir que la autoridad institucional sustituya a la Evidence.

Resumen Ejecutivo

The Nebula Doctrine™ es el cuerpo de principios permanentes que gobierna la forma en que The Nebula Framework™ investiga, representa, interpreta y transforma procesos biológicos.

Su función consiste en convertir la hipótesis fundacional y la visión institucional en criterios de decisión. La doctrina no prescribe una plataforma, lenguaje de programación, arquitectura de nube, protocolo de comunicación, algoritmo o mecanismo criptográfico particular. Establece condiciones que cualquier implementación deberá satisfacer para considerarse compatible con el Framework.

La doctrina parte de una comprensión sistémica. Computational Bioeconomy™ requiere integrar procesos biológicos, territorios, instrumentos, datos, modelos, conocimiento, organizaciones y consecuencias económicas. Estos elementos no pueden evaluarse de manera aislada. Una decisión técnicamente eficiente puede ser semánticamente incoherente, científicamente débil o socialmente ilegítima. Una decisión científicamente interesante puede ser operacionalmente inviable. Una arquitectura interoperable puede crear riesgos de privacidad o apropiación indebida.

El primer principio, la Evidence precede a la opinión, establece que las afirmaciones relevantes deberán conservar una relación verificable con observaciones, métodos, modelos y fuentes identificables. No elimina el juicio experto, pero exige que este se declare como interpretación y no se presente como medición directa.

El segundo principio, la transformación es el objeto de estudio, sitúa la Biological Trajectory en el centro del Framework. El valor científico no reside únicamente en conocer el origen y el resultado, sino en comprender la evolución que los conecta.

El tercer principio, el contexto otorga significado, establece que ningún dato debe interpretarse sin conocer la entidad observada, el tiempo, el procedimiento, la ubicación, las condiciones y la procedencia relevantes. Digital Terroir® constituye una expresión especializada de este principio.

El cuarto principio, el conocimiento debe ser reproducible, exige que los modelos, inferencias y conclusiones puedan revisarse mediante Evidence equivalente, versiones identificables y procedimientos suficientemente documentados. La reproducibilidad se concibe como una propiedad gradual y auditable, no como una declaración binaria.

El quinto principio, la tecnología es un medio, impide convertir inteligencia artificial, blockchain, Digital Twins, sensores o Knowledge Graphs en fines institucionales. Toda tecnología deberá justificarse por el problema que resuelve, la calidad de la decisión que mejora y los riesgos que introduce.

El sexto principio, la Interoperability fortalece el ecosistema, favorece estándares, vocabularios, identificadores e interfaces que permitan colaboración sin pérdida de significado ni dependencia innecesaria de un proveedor. La interoperabilidad deberá ser técnica, estructural, semántica y epistemológica.

El séptimo principio, la evolución es continua, reconoce que Scientific Model, Knowledge Model, Ontology, Biological Trajectory e infraestructura deberán modificarse cuando nueva Evidence lo justifique. Temporal Evolution deberá preservarse mediante versionado, procedencia y memoria institucional.

El octavo principio, la confianza se construye mediante transparencia, establece que una afirmación confiable debe poder relacionarse con su origen, Evidence, transformación analítica, autoridad y limitaciones. Proof of Process™ y Originblok® se subordinan a este principio.

La doctrina deberá orientar investigación científica, arquitectura tecnológica, modelado, estandarización, Governance, publicación, colaboración y relaciones con los territorios. También deberá resolver tensiones entre principios. Transparencia no implica exposición indiscriminada. Interoperability no implica libre apropiación. Evolución no implica inestabilidad. Evidence no implica ausencia de interpretación. Tecnología neutral no implica indiferencia ante las consecuencias de cada herramienta.

La doctrina podrá revisarse, pero no por conveniencia coyuntural. Toda modificación deberá demostrar que el principio vigente limita la misión, entra en conflicto con Evidence suficientemente robusta o produce consecuencias incompatibles con la Tesis y la Visión. La carga argumentativa corresponde a quienes proponen la modificación.

Parte I --- Naturaleza de la Doctrina

1. La doctrina como sistema de decisión

Una doctrina institucional no es una colección de frases aspiracionales. Es un sistema para reducir arbitrariedad en condiciones de incertidumbre.

En The Nebula Framework™, muchas decisiones no podrán resolverse mediante una regla exclusivamente técnica. La selección de variables para una Biological Trajectory, por ejemplo, depende de hipótesis científicas, capacidad instrumental, costo, privacidad, conocimiento territorial y utilidad operacional. La decisión de abrir un conjunto de datos depende de reproducibilidad, propiedad, consentimiento, riesgo competitivo y beneficio público. La adopción de un modelo predictivo depende de precisión, calibración, explicabilidad, estabilidad y consecuencias de error.

La doctrina proporciona criterios transversales para examinar esas decisiones. No garantiza que todas las personas lleguen a la misma conclusión, pero exige que sus argumentos puedan compararse dentro de un lenguaje común.

flowchart TD
    A[Problema o decisión] --> B[Evidence disponible]
    B --> C[Contexto y actores afectados]
    C --> D[Alternativas científicas y tecnológicas]
    D --> E[Evaluación doctrinal]
    E --> F{¿Compatible con los ocho principios?}
    F -->|Sí| G[Decisión documentada]
    F -->|Parcialmente| H[Excepción justificada y limitada]
    F -->|No| I[Rechazo o rediseño]
    G --> J[Monitoreo de consecuencias]
    H --> J
    J --> K[Temporal Evolution]
    K --> B

La decisión doctrinal no termina con la selección de una alternativa. Debe incluir monitoreo. Una arquitectura considerada adecuada puede producir efectos no previstos. Un modelo inicialmente preciso puede degradarse. Un esquema de datos puede excluir conceptos relevantes. Una política de transparencia puede generar riesgos que solo aparecen después de su aplicación.

Por esta razón, la doctrina vincula decisión y aprendizaje. Cada decisión significativa debe producir nueva Evidence sobre sus efectos y alimentar futuras revisiones.

2. Permanencia sin inmovilidad

La doctrina se denomina permanente porque sus principios pretenden mantenerse válidos a través de cambios tecnológicos y organizacionales. Permanencia no significa invariabilidad absoluta.

Un principio doctrinal es más estable que una implementación, pero también puede resultar incompleto. El conocimiento científico no ofrece garantías de eternidad. La historia de la ciencia contiene conceptos que parecían fundamentales y posteriormente fueron limitados, reformulados o sustituidos.

The Nebula Doctrine™ evita dos extremos. El primero sería convertir sus principios en dogmas inmunes a la Evidence. El segundo sería modificarlos con cada cambio de estrategia, financiación o tecnología.

La estabilidad doctrinal depende de una relación explícita entre núcleo y evolución. El núcleo conserva orientación. La evolución permite corregir errores. Temporal Evolution deberá registrar cuándo se propuso un cambio, qué evidencia lo respaldó, quién participó, qué alternativas se consideraron y cómo se preservó la compatibilidad con los documentos relacionados.

3. Alcance de autoridad

La doctrina debe orientar, como mínimo:

  • la formulación de preguntas de investigación;
  • la selección de Observation y Evidence;
  • el diseño de Scientific Model;
  • la evolución del Knowledge Model;
  • la construcción de Ontology y Knowledge Graph;
  • la selección de tecnologías;
  • el diseño de FermentOps®, RoastOps® y TraceOps®;
  • la operación de Originblok® y Proof of Process™;
  • la política de Interoperability;
  • la Governance de datos, modelos y actores;
  • la publicación científica e institucional;
  • la relación con Caficultores, investigadores, colaboradores y comunidades.

La doctrina no reemplaza los procedimientos operativos, contratos, protocolos científicos, normas de inocuidad, obligaciones legales ni decisiones profesionales especializadas. Los condiciona. Cuando una regla externa legítima sea más restrictiva, deberá cumplirse. Cuando una práctica permitida por la ley sea incompatible con los principios doctrinales, la mera legalidad no bastará para justificarla.

Parte II --- Fundamentos epistemológicos

4. Observation, Evidence e Inference

La claridad doctrinal requiere distinguir tres objetos que frecuentemente se mezclan.

Una Observation es el resultado declarado de un acto de observación, medición, muestreo o inspección. Una temperatura registrada por un sensor, una descripción sensorial o un resultado analítico constituyen observaciones cuando conservan información suficiente sobre el acto que las produjo.

La Evidence es el conjunto de objetos y relaciones que permite utilizar una Observation para respaldar o cuestionar una afirmación. Una lectura sin identidad del instrumento ni relación con el proceso puede ser un dato, pero constituye Evidence débil.

Una Inference es una afirmación derivada mediante un Scientific Model, una regla lógica, un análisis estadístico, una simulación o una interpretación experta.

graph LR
    O[Observation] --> E[Evidence]
    M[Metadatos y procedencia] --> E
    E --> SM[Scientific Model]
    KM[Knowledge Model] --> SM
    SM --> I[Inference]
    I --> V[Validación]
    V --> K[Knowledge Claim]
    K --> D[Decisión]
    D --> O2[Nuevas Observations]

La distinción evita que una predicción sea presentada como medición, que una opinión sea presentada como hecho o que una serie de datos sea considerada prueba suficiente sin evaluar su contexto.

La Ontology de Nebula deberá representar estas diferencias de manera explícita. PROV-O proporciona un fundamento estandarizado para describir entidades, actividades, agentes y relaciones de procedencia; SSN/SOSA ofrece conceptos para sensores, observaciones, procedimientos, muestras, propiedades observadas y entidades de interés. The Nebula Framework™ deberá reutilizar o alinear estos fundamentos antes de crear conceptos equivalentes incompatibles.

5. El carácter provisional del conocimiento

La doctrina no asume que la acumulación de datos conduce automáticamente a la verdad. Los datos pueden ser incompletos, sesgados o incorrectos. Los modelos pueden sobreajustarse. Las ontologías pueden institucionalizar supuestos defectuosos. Las inferencias pueden ser válidas dentro de un dominio y fallar fuera de él.

Por ello, el conocimiento en Nebula deberá conservar estado epistemológico. Una afirmación puede encontrarse en evaluación, respaldada provisionalmente, restringida a un dominio, cuestionada, refutada o sustituida.

La condición provisional no reduce el valor del conocimiento. Lo hace científicamente responsable. Una afirmación útil no necesita ser universal; necesita declarar dónde ha sido evaluada, bajo qué condiciones y con qué nivel de incertidumbre.

6. Evidencia y autoridad

El principio de que la Evidence precede a la opinión no elimina la autoridad experta. Un especialista puede identificar patrones que todavía no han sido formalizados o reconocer una desviación antes de que un modelo la detecte.

Sin embargo, la autoridad no debe operar como sustituto permanente de la evidencia. Cuando una decisión dependa de juicio experto, el sistema deberá registrar que se trata de una interpretación, quién la emitió, qué señales consideró y cómo podrá evaluarse posteriormente.

La doctrina rechaza tanto el autoritarismo humano como el autoritarismo algorítmico. Una afirmación no se vuelve verdadera porque proceda de una persona prestigiosa, una institución reconocida o un modelo complejo.

Parte III --- Principios Doctrinales

I. La Evidence precede a la opinión

7. Razón de existencia

Este principio existe para proteger el Framework frente a decisiones basadas exclusivamente en autoridad, intuición, conveniencia comercial o apariencia tecnológica.

Las organizaciones operan bajo presión. Necesitan decidir antes de disponer de información perfecta. La doctrina no exige esperar indefinidamente. Exige distinguir qué parte de la decisión está respaldada por Evidence y qué parte depende de una hipótesis, una interpretación o una preferencia institucional.

La prioridad de la Evidence tampoco significa que la cantidad de datos determine automáticamente la calidad de una decisión. Mil observaciones mal contextualizadas pueden ser menos útiles que una observación crítica obtenida mediante un procedimiento riguroso.

8. Problema que resuelve

En sistemas complejos, las afirmaciones pueden adquirir legitimidad por repetición. Una explicación inicialmente especulativa puede incorporarse a informes, modelos y decisiones hasta parecer un hecho establecido.

La doctrina interrumpe esa transformación silenciosa. Toda afirmación relevante deberá poder relacionarse con su fuente y estado epistemológico.

Un Scientific Model deberá declarar sus datos, supuestos, versión, dominio y desempeño. Una recomendación deberá declarar qué inferencias la sustentan. Una afirmación comercial deberá limitarse al alcance de la Evidence disponible. Un documento institucional deberá distinguir resultados, hipótesis y visión.

9. Fundamentos y relación con el Framework

Evidence es la materia epistemológica de Living Knowledge Infrastructure™. Originblok® conserva relaciones de identidad y procedencia. Proof of Process™ organiza pruebas sobre una transformación. TraceOps® preserva continuidad. FermentOps® y RoastOps® generan observaciones operacionales. Knowledge Model representa significado. Scientific Model produce inferencias.

Sin prioridad de Evidence, estos componentes podrían crear una infraestructura sofisticada para amplificar afirmaciones no verificadas.

Los principios FAIR establecen que los objetos científicos deben ser localizables, accesibles, interoperables y reutilizables, con identificadores, metadatos, vocabularios y procedencia adecuados. La doctrina adopta FAIR como referencia para la administración científica, pero añade que la reutilización deberá conservar las diferencias entre Observation, Evidence e Inference.

10. Implicaciones científicas y tecnológicas

Científicamente, el principio exige hipótesis contrastables, métodos documentados, tratamiento explícito de incertidumbre y disponibilidad de evidencia negativa.

Tecnológicamente, exige identificadores persistentes, trazabilidad de transformaciones, controles de integridad, sincronización temporal, metadatos y versionado.

No implica que toda Evidence deba almacenarse en un único sistema. Puede existir de forma federada, siempre que las relaciones necesarias puedan resolverse bajo Governance autorizada.

11. Limitaciones y refutación

La Evidence siempre es incompleta. Su prioridad no elimina la necesidad de juicio bajo incertidumbre.

El principio sería aplicado incorrectamente si se utilizara para descartar conocimiento cualitativo solo porque no adopta forma numérica. También sería aplicado incorrectamente si se exigiera un nivel de prueba desproporcionado para decisiones reversibles y de bajo riesgo.

Su utilidad podrá evaluarse comparando decisiones documentadas bajo este principio con decisiones que no distingan fuentes y niveles de confianza. Si la disciplina de evidencia no mejora auditabilidad, aprendizaje o calidad de decisión, deberá revisarse su implementación, no necesariamente el principio.

II. La transformación es el objeto de estudio

12. Razón de existencia

Los sistemas tradicionales registran con facilidad entradas y salidas. La transformación intermedia suele reducirse a una orden de producción, un evento de agregación o un conjunto de controles aislados.

The Nebula Framework™ sostiene que el valor científico se genera durante la evolución. La Biological Trajectory se convierte así en objeto primario.

Una materia inicial y un resultado final no determinan una trayectoria única. Dos procesos pueden llegar a valores similares después de atravesar condiciones diferentes. Esas diferencias pueden afectar estabilidad, reproducibilidad, seguridad, sostenibilidad o comportamiento posterior.

13. Problema que resuelve

La concentración en resultados finales produce una pérdida causal y temporal. Cuando aparece una desviación, la organización conoce el resultado, pero no necesariamente puede reconstruir cómo emergió.

La doctrina exige estudiar estados, transiciones, tasas de cambio, intervenciones, discontinuidades y respuestas. Esta exigencia modifica el diseño de la infraestructura: los eventos no deben ser tratados como puntos aislados, sino como partes de una secuencia contextualizada.

14. Relación con Digital Twins y Systems Engineering

Los estándares ISO 23247 desarrollan principios, arquitecturas de referencia, digital thread y composición de Digital Twins para manufactura. Estos marcos aportan conceptos importantes sobre conectividad, ciclo de vida e interoperación entre representaciones digitales.

Nebula adopta una posición epistemológicamente más limitada respecto al término «twin». Una Biological Trajectory no presume ser una réplica completa del sistema vivo. Es una representación selectiva de aspectos observados e inferidos.

La Systems Engineering aporta una perspectiva de ciclo de vida y relaciones entre procesos, productos, servicios, personas y entidades naturales. ISO/IEC/IEEE 15288:2023 establece un marco común para describir procesos de ciclo de vida de sistemas, referencia útil para organizar la evolución de infraestructuras complejas.

15. Implicaciones

Científicamente, el principio permite estudiar mecanismos, transiciones críticas, dependencia temporal y efectos acumulativos.

Tecnológicamente, exige series temporales, sincronización, modelos de estados, gestión de eventos, almacenamiento de procedencia y representación de intervalos sin datos.

Económicamente, permite reconocer que el conocimiento sobre la transformación puede poseer valor propio.

Socialmente, puede visibilizar las prácticas y decisiones de quienes conducen el proceso, siempre que la infraestructura no se apropie de ese conocimiento sin Governance.

16. Limitaciones y refutación

No todos los procesos requieren observación continua. Instrumentar cada variable puede ser innecesario, invasivo o económicamente inviable.

El principio no exige máxima densidad de datos. Exige que el diseño se centre en la trayectoria relevante para la pregunta.

Podría considerarse limitado si estudios comparativos demuestran que la representación temporal no mejora explicación, predicción, control o trazabilidad frente a registros finales. En ese caso, deberá reducirse la complejidad representacional al nivel justificado por la Evidence.

III. El contexto otorga significado

17. Razón de existencia

Un dato aislado no declara qué fue observado, cómo, cuándo, dónde ni con qué incertidumbre. El valor 22 puede representar temperatura, tiempo, concentración, identificación o resultado sensorial.

Incluso cuando la unidad es conocida, la interpretación puede depender de la ubicación del sensor, su calibración, el material observado, el momento del proceso y la historia previa de la muestra.

El contexto transforma un valor en Observation interpretable.

18. Digital Terroir® como contexto ampliado

Digital Terroir® expresa la aplicación territorial de este principio. Integra, cuando sea pertinente, localización, ambiente, genética, prácticas, infraestructura, temporalidad, conocimiento humano y condiciones socioeconómicas.

No es una etiqueta comercial ni una representación exhaustiva del territorio. Es un modelo contextual gobernado.

La selección de contexto deberá responder a una pregunta. Registrar variables sin relación demostrable con el proceso puede aumentar costos, riesgos y complejidad sin mejorar conocimiento.

19. Semantic Infrastructure

La Semantic Infrastructure deberá expresar entidades, propiedades, unidades, procedimientos y relaciones con suficiente claridad para permitir interpretación entre sistemas.

OWL 2 proporciona un lenguaje de ontologías con semántica formal; SHACL permite definir y evaluar restricciones sobre grafos RDF. Estas herramientas pueden contribuir a expresar significado y conformidad estructural, pero la validación formal no demuestra por sí sola que una observación sea científicamente correcta.

El Knowledge Model debe distinguir significado de formato. Dos sistemas pueden intercambiar JSON y continuar siendo semánticamente incompatibles. También pueden utilizar la misma palabra para conceptos distintos.

20. Implicaciones

Científicamente, el contexto permite controlar factores de confusión, formular hipótesis y evaluar generalización.

Tecnológicamente, exige metadatos, alineamientos ontológicos, unidades explícitas, referencias temporales y reglas de identidad.

Institucionalmente, exige reconocer que el contexto puede incluir información sensible. Digital Terroir® podría revelar ubicaciones, prácticas o relaciones comerciales. La doctrina no permite utilizar la búsqueda de contexto como justificación para capturar información ilimitada.

21. Limitaciones y refutación

Todo contexto es una selección. La pretensión de representar la totalidad del entorno produciría un modelo inmanejable.

El principio deberá evaluarse mediante análisis de contribución: qué variables contextuales mejoran interpretación, comparabilidad o desempeño. Las variables que no aporten valor científico, operacional o de Governance deberían excluirse o conservarse con menor prioridad.

IV. El conocimiento debe ser reproducible

22. Razón de existencia

El conocimiento institucional puede volverse dependiente de personas, plataformas o configuraciones que desaparecen. Cuando un resultado no puede reconstruirse, su valor se limita.

La reproducibilidad protege la continuidad intelectual del Framework. Permite que una inferencia sea revisada, que un modelo sea evaluado y que una afirmación sobreviva a cambios de equipo o infraestructura.

23. Alcance de la reproducibilidad

La doctrina reconoce varias formas relacionadas:

  • repetición del mismo procedimiento bajo condiciones equivalentes;
  • reproducción de un análisis con los mismos datos y código;
  • replicación mediante nueva Evidence;
  • reconstrucción de la cadena de procedencia;
  • evaluación independiente de una afirmación.

No todas las formas serán posibles en todos los contextos. Un proceso biológico no puede repetirse de manera perfectamente idéntica. La reproducibilidad deberá definirse respecto al fenómeno y al nivel de incertidumbre aceptable.

24. Requisitos doctrinales

Un Scientific Model deberá conservar versión, entradas, transformaciones, parámetros y entorno relevante.

Una Inference deberá vincularse con el modelo que la produjo.

Una publicación deberá describir métodos y limitaciones.

Una Ontology deberá conservar historial de cambios y reglas de migración.

Una Biological Trajectory deberá preservar suficientes referencias para evaluar cómo fue construida.

Los principios FAIR apoyan la reutilización por humanos y máquinas, pero FAIR no equivale automáticamente a apertura irrestricta ni a validez científica. La doctrina deberá aplicar estos principios de forma compatible con Governance, privacidad y soberanía.

25. Implicaciones y límites

La reproducibilidad puede aumentar costos de documentación y almacenamiento. Sin embargo, la ausencia de reproducibilidad transfiere esos costos al futuro, cuando una organización intenta explicar una decisión o reconstruir un resultado.

No todas las configuraciones deberán conservarse indefinidamente. Las políticas de retención podrán utilizar niveles de criticidad.

El principio sería refutado en su implementación si los procedimientos añadidos no permiten reconstruir resultados o si la carga documental supera sistemáticamente el valor científico y operacional. La respuesta deberá ser mejorar proporcionalidad, no abandonar auditabilidad.

V. La tecnología es un medio

26. Razón de existencia

Los ciclos tecnológicos crean incentivos para describir problemas mediante las herramientas disponibles. Una organización puede adoptar inteligencia artificial porque existe financiación para IA, blockchain porque promete confianza o Digital Twins porque el término posee legitimidad industrial.

La doctrina invierte esa lógica. El problema, el contexto, la Evidence y el resultado esperado preceden a la selección tecnológica.

27. Neutralidad tecnológica responsable

La doctrina es tecnológicamente neutral respecto a marcas y arquitecturas específicas, pero no moralmente indiferente ante sus consecuencias.

Dos tecnologías capaces de resolver la misma función pueden diferir en consumo energético, explicabilidad, dependencia de proveedor, privacidad, accesibilidad o capacidad de auditoría. La evaluación deberá incorporar esas diferencias.

La neutralidad significa que Originblok® no presupone blockchain, que Scientific Model no presupone aprendizaje profundo y que Living Knowledge Infrastructure™ no presupone una nube centralizada.

28. Inteligencia artificial

Los modelos de inteligencia artificial deberán estar subordinados al propósito científico y operacional. Su adopción deberá considerar calidad de datos, riesgo, explicabilidad, supervisión humana, seguridad, sesgo y degradación temporal.

ISO/IEC 42001:2023 establece requisitos para sistemas organizacionales de gestión de IA y enfatiza gestión responsable, transparencia, trazabilidad y mejora continua. ISO/IEC 23894:2023 proporciona orientación para integrar la gestión de riesgos de IA en organizaciones que desarrollan, despliegan o utilizan estos sistemas. NIST AI RMF 1.0 propone un enfoque voluntario para gestionar riesgos y confiabilidad durante el ciclo de vida.

The Nebula Doctrine™ exige que ninguna Inference algorítmica sea presentada como Observation. También exige que las decisiones de impacto mantengan responsabilidad humana o institucional identificable.

29. Blockchain y registros distribuidos

Una estructura distribuida puede aportar integridad compartida, resistencia a modificaciones o coordinación entre organizaciones sin una autoridad única. También puede introducir costo, complejidad, exposición de metadatos y dificultades de corrección.

Proof of Process™ no debe confundirse con prueba de inclusión en una blockchain. La inmutabilidad de un registro no demuestra la exactitud de su contenido.

Originblok® deberá seleccionar mecanismos de persistencia y firma según el modelo de Governance. En algunos casos, una infraestructura federada con firmas verificables puede ser más adecuada.

30. Sensores y automatización

Un sensor añade capacidad de observación, pero también introduce un modelo de medición. Posee ubicación, rango, incertidumbre, deriva, frecuencia y condiciones de fallo.

La doctrina rechaza la idea de que más sensores producen automáticamente mayor conocimiento. La instrumentación deberá diseñarse desde la pregunta científica.

La automatización deberá ser proporcional al riesgo. Un sistema puede recomendar una intervención, ejecutarla bajo supervisión o controlarla autónomamente. Cada nivel requiere diferentes salvaguardas.

31. Limitaciones y refutación

El principio podría degradarse hasta convertirse en una excusa para posponer innovación. La doctrina no exige certeza absoluta antes de experimentar. Permite prototipos y pruebas, siempre que su naturaleza experimental sea explícita.

La selección tecnológica deberá poder refutarse mediante métricas. Si una tecnología no mejora desempeño, conocimiento, confiabilidad o capacidad de colaboración respecto a alternativas más simples, deberá ser retirada o restringida.

VI. La Interoperability fortalece el ecosistema

32. Razón de existencia

Computational Bioeconomy™ involucra sistemas heterogéneos. Sensores, laboratorios, plataformas operacionales, universidades, organizaciones territoriales, empresas y autoridades utilizan infraestructuras diferentes.

Sin Interoperability, cada integración se convierte en un proyecto particular y cada cambio amenaza con romper continuidad.

33. Cuatro niveles de Interoperability


Nivel Propósito Fallo característico


Técnica Transportar información entre sistemas Protocolos incompatibles

Estructural Compartir organización y formato Campos o esquemas divergentes

Semántica Preservar significado e identidad Conceptos ambiguos

Epistemológica Preservar el tipo de afirmación Confundir Observation con Inference


La doctrina concede especial importancia al nivel epistemológico. Un sistema puede interpretar correctamente una propiedad y, aun así, desconocer si su valor fue medido, interpolado, predicho o introducido manualmente.

34. Estándares y vocabularios

GS1 EPCIS permite compartir eventos de visibilidad mediante un lenguaje común entre organizaciones y constituye una referencia importante para TraceOps®. Su enfoque de eventos puede integrarse con datos de sensores y vocabularios compartidos, pero Biological Trajectory deberá conservar relaciones científicas que exceden la trazabilidad logística.

OWL 2, PROV-O, SHACL y SSN/SOSA proporcionan bloques para Ontology, procedencia, validación y observación. La doctrina favorece su reutilización cuando sean compatibles con el dominio.

La adopción de estándares no será automática. Un estándar puede poseer amplio reconocimiento y continuar siendo insuficiente para una necesidad específica. Las extensiones deberán documentarse y evitar redefiniciones innecesarias.

35. Interoperability y apertura

Interoperability no significa que todos los datos deban ser públicos. Tampoco significa que cualquier actor pueda reutilizar información para cualquier finalidad.

Las interfaces, vocabularios e identificadores pueden ser abiertos, mientras que los datos permanecen bajo controles de acceso. La doctrina exige separar portabilidad de exposición.

Una infraestructura interoperable debe permitir que una organización cambie de proveedor sin perder Biological Trajectories, procedencia o significado. El bloqueo tecnológico que convierte el historial científico en rehén de una plataforma es contrario a la doctrina.

36. Limitaciones y refutación

La interoperabilidad posee costos. Los estándares pueden ralentizar cambios, imponer abstracciones o limitar optimizaciones locales.

El principio no exige uniformidad total. Permite extensiones territoriales y de dominio, siempre que existan alineamientos explícitos.

La utilidad deberá evaluarse mediante intercambios entre implementaciones independientes. Una declaración de compatibilidad sin prueba de transferencia y reconstrucción semántica no será suficiente.

VII. La evolución es continua

37. Razón de existencia

Los procesos biológicos, modelos, territorios y tecnologías cambian. Un Scientific Model desarrollado para una temporada puede degradarse en otra. Una Ontology puede resultar insuficiente cuando se incorpora un nuevo dominio. Una política de Governance puede producir efectos inesperados.

La doctrina reconoce que el conocimiento no es definitivo. Sin embargo, la evolución deberá ser trazable.

38. Temporal Evolution

Temporal Evolution representa los cambios de entidades, modelos, conceptos, reglas y afirmaciones a través del tiempo.

Una nueva versión no debe borrar la anterior. Deberá expresar qué cambió, por qué, quién lo autorizó y qué objetos dependen de la versión reemplazada.

Living Knowledge Infrastructure™ existe para preservar esta historia. Su carácter vivo no consiste solo en recibir datos nuevos, sino en revisar interpretaciones y conservar controversias.

39. Evolución de Scientific Model

Un modelo deberá ser monitoreado después de su despliegue. El desempeño histórico no garantiza desempeño futuro.

La evolución puede incluir recalibración, incorporación de variables, restricción de alcance o sustitución completa. Cada cambio deberá evaluarse con Evidence fuera de muestra y compararse con la versión anterior.

Una actualización que mejora la métrica promedio pero perjudica sistemáticamente a un territorio o tipo de operación deberá ser examinada bajo Governance.

40. Evolución de Ontology y Knowledge Model

Los conceptos también cambian. Nuevos hallazgos pueden exigir subdividir una clase, modificar una relación o declarar que dos términos previamente equivalentes poseen diferencias importantes.

La evolución ontológica deberá preservar compatibilidad cuando sea posible. Cuando no lo sea, deberán existir reglas de migración y advertencias explícitas.

La estabilidad semántica no se logra evitando cambios, sino administrándolos.

41. Limitaciones y refutación

La evolución continua puede generar fatiga, fragmentación y pérdida de comparabilidad. El principio no autoriza cambios permanentes sin umbral de evidencia.

Las versiones estables deberán mantenerse durante periodos suficientes para permitir investigación y operación. Los cambios urgentes requerirán justificación de riesgo.

La doctrina deberá evaluarse por su capacidad de mejorar sin borrar memoria. Si el versionado impide utilizar la infraestructura o produce incompatibilidad constante, la estrategia de evolución deberá rediseñarse.

VIII. La confianza se construye mediante transparencia

42. Razón de existencia

La bioeconomía depende de afirmaciones sobre origen, proceso, calidad, sostenibilidad, conformidad y desempeño. Muchas de estas afirmaciones se sostienen mediante documentos o reputación institucional.

The Nebula Framework™ busca añadir una infraestructura donde dichas afirmaciones puedan relacionarse con Evidence y procedimientos verificables.

La transparencia no significa revelar todo. Significa que los fundamentos de una afirmación puedan ser examinados por actores autorizados.

43. Proof of Process™

Proof of Process™ representa la aplicación central de este principio. Una afirmación sobre una transformación deberá vincularse con identidad, periodo, proceso, observaciones, procedimientos y criterios de evaluación.

La prueba puede poseer diferentes niveles. Un registro manual firmado ofrece una clase de respaldo. Una serie instrumental calibrada ofrece otra. Una replicación independiente añade un nivel adicional.

La doctrina prohíbe presentar todos los niveles como equivalentes.

44. Originblok®

Originblok® proporciona continuidad de identidad y procedencia. Deberá permitir relacionar materiales, procesos, actores, ubicaciones, Evidence y resultados.

Su finalidad no es producir una narrativa inmutable, sino permitir reconstrucción y auditoría.

Cuando se detecte un error, la corrección no deberá borrar el registro anterior. Deberá crear una nueva afirmación relacionada con la original y explicar la modificación.

45. Transparencia, privacidad y confidencialidad

La transparencia posee límites legítimos. Una Biological Trajectory puede contener datos personales, secretos comerciales, ubicaciones sensibles o conocimiento territorial.

La doctrina exige proporcionalidad. Un regulador puede requerir acceso diferente del que recibe un comprador. Un investigador puede trabajar con datos desidentificados. Una comunidad puede establecer restricciones sobre conocimiento tradicional.

La Trust Infrastructure deberá permitir control de acceso, divulgación selectiva y registro de quién consultó o utilizó información crítica.

46. Explicabilidad y capacidad de impugnación

Una decisión basada en Inference debe poder ser cuestionada. La persona u organización afectada deberá conocer, en proporción con el impacto, qué datos, modelo y criterios fueron utilizados.

La explicabilidad no exige que todos los modelos sean simplificados hasta perder utilidad. Exige que la organización pueda proporcionar razones, limitaciones y evidencia suficiente para evaluar la decisión.

La confianza se debilita cuando el sistema exige creer en su autoridad sin permitir revisión.

47. Limitaciones y refutación

La transparencia puede producir sobrecarga informativa. Entregar miles de registros no equivale a explicar una decisión.

Proof of Process™ deberá diseñar representaciones comprensibles y verificables.

El principio podrá evaluarse mediante auditorías adversariales. Si terceros autorizados no pueden reconstruir afirmaciones o si las pruebas producen una certeza mayor que la Evidence disponible, la Trust Infrastructure deberá considerarse defectuosa.

Parte IV --- Relaciones y tensiones doctrinales

48. Los principios forman un sistema

Los ocho principios no deben aplicarse de manera aislada. Cada uno limita y completa a los demás.

La Evidence precede a la opinión, pero el contexto determina qué significa la Evidence.

La transformación es el objeto de estudio, pero no toda variable de la transformación merece ser observada.

El conocimiento debe ser reproducible, pero la reproducción no debe vulnerar derechos.

La tecnología es un medio, pero una tecnología puede modificar relaciones de poder.

La Interoperability fortalece el ecosistema, pero no autoriza apropiación indiscriminada.

La evolución es continua, pero requiere estabilidad y memoria.

La confianza se construye mediante transparencia, pero la transparencia debe ser proporcional.

graph TD
    E[Evidence] --> C[Contexto]
    C --> T[Transformación]
    T --> R[Reproducibilidad]
    R --> I[Interoperability]
    I --> EV[Temporal Evolution]
    EV --> TR[Transparencia]
    TR --> G[Governance]
    G --> E
    TECH[Tecnología como medio] --> E
    TECH --> T
    TECH --> I
    TECH --> TR

49. Evidence frente a urgencia

Las decisiones operacionales pueden requerir acción antes de disponer de Evidence completa. La doctrina permite decisiones precautorias, siempre que se documente la incertidumbre y se establezca un mecanismo de revisión.

Una acción urgente no deberá convertirse retrospectivamente en evidencia de que su justificación era correcta. Sus resultados deberán evaluarse de forma independiente.

50. Transparencia frente a soberanía

La apertura puede facilitar revisión y colaboración. También puede facilitar extracción económica.

La doctrina exige que la soberanía de datos y conocimiento forme parte de Governance. Los actores que generan Evidence deberán comprender las finalidades de uso, las condiciones de reutilización y los mecanismos de beneficio.

La transparencia institucional no debe construirse mediante opacidad contractual para los actores territoriales.

51. Interoperability frente a diversidad

Un vocabulario común puede facilitar integración, pero también imponer categorías externas.

Digital Terroir® deberá permitir extensiones locales y multilingües. La Ontology debe representar equivalencias parciales, conceptos territoriales y relaciones no reducibles a categorías globales.

La diversidad no debe utilizarse como excusa para evitar interoperabilidad. La interoperabilidad no debe utilizarse como excusa para eliminar diversidad.

52. Evolución frente a estabilidad

La innovación requiere cambio. La ciencia requiere comparabilidad.

El Framework deberá utilizar ciclos de versiones estables, periodos de transición y mecanismos de deprecación. Los cambios no retrocompatibles deberán ser excepcionales y poseer herramientas de migración.

53. Automatización frente a juicio humano

Una automatización puede reducir variabilidad y carga operacional. También puede ocultar supuestos y desplazar responsabilidad.

La doctrina exige niveles de autonomía proporcionales al riesgo. Una recomendación informativa requiere controles diferentes de una intervención automática sobre un proceso crítico.

La responsabilidad final deberá permanecer identificable incluso cuando la acción sea ejecutada por software.

Parte V --- Arquitectura doctrinal del Framework

54. Posición dentro del sistema documental

flowchart TD
    T[NBL-FWK-001<br/>La Tesis Nebula™] --> V[NBL-FWK-002<br/>La Visión Nebula™]
    T --> D[NBL-FWK-003<br/>The Nebula Doctrine™]
    V --> D
    D --> C[NBL-FWK-004<br/>The Nebula Constitution™]
    C --> G[Governance y políticas]
    D --> A[Architecture]
    D --> O[Ontology]
    D --> SM[Scientific Model]
    D --> KM[Knowledge Model]
    D --> S[Standards]
    A --> OPS[FermentOps® · RoastOps® · TraceOps®]
    O --> LKI[Living Knowledge Infrastructure™]
    SM --> LKI
    KM --> LKI
    G --> LKI
    LKI --> POP[Proof of Process™]
    LKI --> OB[Originblok®]

La Tesis establece la hipótesis. La Visión define el horizonte. La Doctrina establece principios de decisión. La Constitución deberá definir autoridades, derechos, procedimientos y mecanismos de cumplimiento.

Los documentos técnicos deberán demostrar compatibilidad doctrinal. No bastará con utilizar la terminología oficial.

55. Scientific Model y Knowledge Model

Scientific Model y Knowledge Model cumplen funciones distintas.

Scientific Model describe, explica, simula o predice aspectos de una Biological Trajectory.

Knowledge Model define entidades, relaciones, restricciones y significado.

Un modelo predictivo puede producir resultados sin representar adecuadamente el significado de sus variables. Una Ontology puede expresar significado sin predecir el comportamiento del proceso.

La doctrina exige interacción. Scientific Model deberá consumir objetos semánticamente definidos. Knowledge Model deberá permitir representar inferencias, desempeño, versiones y límites de modelos.

56. Knowledge Graph

El Knowledge Graph integra entidades y afirmaciones. No debe ser considerado una representación automática de verdad.

Cada relación relevante deberá conservar procedencia y, cuando corresponda, temporalidad y estado epistemológico.

Las inferencias derivadas por reglas ontológicas deberán distinguirse de las inferencias producidas por modelos estadísticos. Ambas deberán distinguirse de las observaciones.

57. Operational Domains

FermentOps®, RoastOps® y TraceOps® aplicarán los principios a dominios específicos.

FermentOps® deberá priorizar la evolución biológica y fisicoquímica.

RoastOps® deberá representar la transformación térmica y su continuidad con etapas anteriores.

TraceOps® deberá conservar identidades, eventos, custodias y relaciones entre transformaciones.

Ningún dominio deberá convertirse en silo semántico. La continuidad de una materia a través del Framework depende de una Ontology y una Governance compartidas.

Parte VI --- Aplicación de la Doctrina

58. Investigación científica

Toda investigación de Nebula deberá comenzar con una pregunta explícita y distinguir variables observadas, inferidas y controladas.

Los protocolos deberán definir procedimientos, unidades experimentales, criterios de inclusión, incertidumbre y métodos de análisis.

Los resultados negativos deberán conservarse cuando aporten conocimiento sobre limitaciones o refutaciones.

Las publicaciones deberán evitar presentar asociaciones como mecanismos causales sin diseño suficiente.

59. Arquitectura tecnológica

Toda arquitectura deberá justificar sus componentes mediante requisitos.

La adopción de un sistema distribuido deberá responder a una necesidad de coordinación o confianza.

La adopción de nube deberá evaluar conectividad, soberanía, costo y dependencia.

La arquitectura deberá permitir operación degradada cuando el contexto territorial presente conectividad limitada, siempre que ello no comprometa requisitos críticos.

Los componentes deberán ser reemplazables sin destruir la historia científica.

60. Desarrollo de modelos

Todo Scientific Model deberá poseer una ficha doctrinal con:

  • propósito;
  • población o dominio;
  • Evidence utilizada;
  • variables;
  • versión;
  • métricas;
  • incertidumbre;
  • riesgos;
  • responsable;
  • criterios de revisión y retirada.

Los modelos de alto impacto deberán someterse a evaluación independiente.

61. Construcción de estándares

Los estándares de Nebula deberán definir claramente alcance, terminología, requisitos, ejemplos y criterios de conformidad.

Cuando utilicen lenguaje normativo, deberán declarar sus convenciones.

Las especificaciones deberán favorecer implementaciones independientes y evitar dependencias innecesarias de productos propiedad de una sola organización.

62. Governance

Governance deberá convertir principios en autoridades y procedimientos.

Deberá definir quién puede crear, validar, modificar, consultar y retirar objetos.

También deberá definir mecanismos de impugnación y resolución de conflictos.

La Governance deberá incluir representación de los actores afectados por la infraestructura, no solo de quienes la desarrollan.

63. Publicación de conocimiento

Las publicaciones deberán distinguir conocimiento científico, opinión institucional y comunicación comercial.

Las afirmaciones deberán limitarse al alcance de la Evidence.

Cuando existan restricciones de datos, deberán publicarse metadatos, métodos o mecanismos de acceso controlado suficientes para permitir evaluación.

64. Relaciones con colaboradores y comunidad

Los acuerdos deberán definir uso de datos, atribución, propiedad intelectual, confidencialidad y distribución de beneficios.

La participación no deberá reducirse a extracción de observaciones.

Los Caficultores y operadores deberán poder intervenir en la definición de preguntas relevantes y recibir resultados interpretables.

Parte VII --- Casos doctrinales de referencia

65. Caso A: selección de una tecnología de registro

Una propuesta recomienda utilizar una blockchain pública para todas las observaciones.

La doctrina no acepta ni rechaza la tecnología por su nombre. Exige demostrar el problema: múltiples actores sin confianza mutua, necesidad de verificación independiente o riesgo significativo de alteración.

También exige evaluar costo, privacidad, corrección de errores, consumo de recursos y alternativas.

Si una base federada con firmas verificables satisface los requisitos con menor complejidad, la blockchain no deberá adoptarse por valor simbólico.

66. Caso B: modelo predictivo de fermentación

Un Scientific Model estima el momento óptimo para finalizar una fermentación.

El principio de Evidence exige conocer datos y desempeño. El principio de contexto exige identificar territorios y condiciones evaluadas. El principio de reproducibilidad exige conservar versión y procedimiento. El principio tecnológico exige que el modelo mejore una decisión real. El principio de evolución exige monitorear degradación. El principio de transparencia exige explicar incertidumbre y permitir intervención humana.

Una alta precisión promedio no será suficiente si el modelo falla en condiciones relevantes o si sus errores producen consecuencias desproporcionadas.

67. Caso C: conflicto entre observación humana y sensor

Un operador experimentado identifica una desviación que no aparece en los sensores.

La doctrina no descarta su observación por ser humana. La registra como Observation con procedimiento y actor.

Se investigan calibración, ubicación, variables no medidas y condiciones del proceso.

El conflicto se convierte en oportunidad de aprendizaje. Puede revelar un sensor defectuoso, una señal cualitativa relevante o un sesgo humano.

68. Caso D: intercambio entre organizaciones

Dos organizaciones desean compartir Biological Trajectories.

La Interoperability técnica permite transferir datos. La estructural permite interpretar campos. La semántica permite comprender entidades. La epistemológica permite conocer qué fue medido y qué fue inferido.

Governance define qué puede utilizarse, durante cuánto tiempo y con qué atribución.

El intercambio solo será doctrinalmente válido cuando cumpla las cuatro dimensiones y respete los derechos aplicables.

69. Caso E: modificación de la Ontology

Una nueva investigación muestra que una clase ontológica agrupa procesos biológicamente distintos.

La estabilidad no justifica mantener el error. La evolución tampoco justifica romper silenciosamente compatibilidad.

La nueva versión deberá preservar la clase anterior, declarar su deprecación, definir conceptos más precisos y proporcionar reglas de migración.

Parte VIII --- Validación y refutación de la Doctrina

70. La doctrina debe producir consecuencias observables

Aunque los principios poseen naturaleza normativa, su aplicación debe generar resultados evaluables.

Una doctrina útil debería mejorar:

  • trazabilidad de decisiones;
  • calidad de Evidence;
  • reproducibilidad;
  • capacidad de auditoría;
  • portabilidad;
  • detección de errores;
  • aprendizaje institucional;
  • legitimidad de Governance.

Estas mejoras no deben presumirse. Deberán medirse.

71. Matriz de validación


Principio Indicador de aplicación Señal de fallo


Evidence precede a la opinión Claims vinculados con fuentes y estado epistemológico Afirmaciones sin procedencia

Transformación como objeto Trayectorias con estados y transiciones relevantes Solo entradas y salidas

Contexto otorga significado Observaciones con entidad, tiempo, método y entorno Datos ambiguos

Conocimiento reproducible Resultados reconstruibles por terceros autorizados Dependencia de conocimiento tácito

Tecnología como medio Componentes justificados por requisitos Adopción por moda

Interoperability Intercambio entre implementaciones independientes Bloqueo de proveedor

Evolución continua Versiones y cambios trazables Reemplazos silenciosos

Confianza mediante transparencia Claims auditables e impugnables Autoridad sin prueba


72. Condiciones de refutación

La doctrina deberá considerarse insuficiente si su aplicación rigurosa produce de manera persistente alguno de los siguientes resultados:

  • documentación extensa sin mejora de conocimiento;
  • infraestructura tan compleja que excluya a los actores principales;
  • interoperabilidad formal sin utilidad práctica;
  • transparencia que genere daños superiores a sus beneficios;
  • evolución que destruya comparabilidad;
  • evidencia que desplace ilegítimamente conocimiento humano;
  • neutralidad tecnológica que ignore consecuencias sociales;
  • gobernanza incapaz de resolver conflictos.

La refutación no implica abandonar automáticamente el principio. Puede mostrar que fue interpretado incorrectamente, que su alcance es excesivo o que necesita una distinción adicional.

73. Revisión externa

Las evaluaciones doctrinales deberán incluir, cuando sea posible, revisores externos con conocimientos científicos, técnicos, territoriales y éticos.

Una doctrina evaluada solo por la institución que la formuló corre el riesgo de confirmar sus propios supuestos.

Parte IX --- Limitaciones y riesgos

74. Riesgo de dogmatización

El principal riesgo de una doctrina es convertirse en autoridad incuestionable.

Para evitarlo, cada principio incluye condiciones de validación y posible revisión. La coherencia institucional no debe utilizarse para excluir crítica científica.

75. Riesgo de formalismo

Una organización puede cumplir formularios y conservar metadatos sin producir conocimiento.

La doctrina debe evaluarse por resultados epistemológicos y operacionales, no por volumen documental.

76. Riesgo de centralización

Originblok®, Knowledge Graph y Living Knowledge Infrastructure™ pueden concentrar información y poder.

La arquitectura deberá considerar federación, controles de acceso, separación de funciones y representación de actores territoriales.

77. Riesgo de exclusión tecnológica

La instrumentación avanzada puede favorecer operaciones con más recursos.

El Framework deberá admitir niveles de participación. Una Observation humana rigurosa no debe descartarse por ausencia de sensor.

78. Riesgo de reducción biológica

Una Biological Trajectory puede producir la impresión de que el sistema vivo ha sido completamente descrito.

Los modelos deberán declarar variables no observadas, incertidumbre y límites de representación.

79. Riesgo de optimización estrecha

Un modelo puede mejorar rendimiento y perjudicar diversidad, sostenibilidad o distribución de valor.

FAO ha señalado que las estrategias de bioeconomía deben considerar conjuntamente dimensiones económicas, sociales y ambientales, así como sinergias y compensaciones. La doctrina incorpora esta visión mediante evaluación multidimensional.

Parte X --- Cláusula de Evolución

80. Principio general

The Nebula Doctrine™ podrá revisarse únicamente cuando exista Evidence científica, tecnológica, social o institucional suficiente para demostrar que un principio vigente:

  1. limita de forma material el cumplimiento de La Tesis Nebula™ o La Visión Nebula™;
  2. produce consecuencias incompatibles con la misión;
  3. resulta internamente contradictorio;
  4. ha sido superado por conocimiento suficientemente robusto;
  5. carece de capacidad para gobernar un nuevo dominio relevante.

La conveniencia comercial, la preferencia de una autoridad o la aparición de una tecnología no constituyen por sí solas fundamento suficiente.

81. Procedimiento doctrinal

stateDiagram
    [*] --> Stable
    Stable --> ReviewProposed: propuesta documentada
    ReviewProposed --> EvidenceCollection: admisibilidad
    EvidenceCollection --> Deliberation: expediente suficiente
    Deliberation --> Rejected: fundamento insuficiente
    Deliberation --> ExperimentalAmendment: cambio provisional
    Deliberation --> ApprovedAmendment: consenso y autoridad
    ExperimentalAmendment --> Deliberation: evaluación
    ApprovedAmendment --> Transition: versión y migración
    Transition --> Stable: entrada en vigor
    Rejected --> Stable

Toda propuesta deberá contener el texto afectado, la Evidence, los actores impactados, las alternativas y las consecuencias para documentos relacionados.

Los cambios podrán probarse de manera experimental antes de modificar la versión estable.

La decisión deberá conservar opiniones divergentes significativas. El consenso no debe construirse borrando desacuerdos.

82. Compatibilidad documental

Toda modificación deberá evaluar su relación con:

  • La Tesis Nebula™;
  • La Visión Nebula™;
  • The Nebula Constitution™;
  • Ontology;
  • Architecture;
  • Scientific Model;
  • Knowledge Model;
  • estándares derivados.

Cuando un cambio doctrinal altere documentos posteriores, deberá establecerse un plan de transición.

83. Versionado

Los cambios editoriales que no alteren significado podrán incrementar una versión de corrección.

Los cambios que amplíen o precisen principios sin romper compatibilidad podrán incrementar una versión menor.

Los cambios que modifiquen obligaciones fundamentales requerirán una versión mayor.

Las versiones anteriores deberán permanecer disponibles como parte de Temporal Evolution.

Conclusiones

The Nebula Doctrine™ establece el sistema de principios mediante el cual The Nebula Framework™ deberá conservar coherencia mientras evolucionan la ciencia, la tecnología y sus instituciones.

Su primer compromiso es epistemológico: ninguna autoridad, modelo o narrativa debe reemplazar a la Evidence. Su segundo compromiso es ontológico: la transformación, representada como Biological Trajectory, constituye el objeto central. Su tercer compromiso es semántico: el contexto otorga significado. Su cuarto compromiso es científico: el conocimiento debe poder revisarse y reproducirse.

Su quinto compromiso es instrumental: la tecnología existe para servir al problema, no para definirlo. Su sexto compromiso es ecosistémico: la Interoperability permite colaboración y continuidad. Su séptimo compromiso es temporal: todo modelo y conocimiento puede evolucionar, pero su historia debe preservarse. Su octavo compromiso es institucional: la confianza requiere transparencia, procedencia, auditabilidad y capacidad de impugnación.

Estos compromisos forman una unidad. No pueden aplicarse selectivamente para justificar decisiones previamente tomadas.

The Nebula Doctrine™ no garantiza que el Framework produzca conocimiento verdadero, decisiones correctas o impactos justos. Proporciona condiciones para detectar errores, revisar supuestos, comparar alternativas y atribuir responsabilidad.

Su valor no dependerá de la solemnidad con la que se cite, sino de la disciplina con la que se aplique cuando sus principios resulten incómodos.

Una doctrina científica demuestra su legitimidad cuando permite corregir a la institución que la creó.

Glosario

Biological Trajectory

Representación temporal estructurada de estados, transiciones, observaciones, intervenciones, discontinuidades e incertidumbres asociadas con un proceso biológico.

Computational Bioeconomy™

Campo interdisciplinario dedicado a representar, interpretar y gobernar recursos y transformaciones biológicas mediante modelos computacionales vinculados con contexto, Evidence y distribución de valor.

Decision

Acción adoptada por una persona, organización o sistema autorizado con base en Evidence, Inference, reglas, experiencia u otros fundamentos declarados.

Digital Terroir®

Modelo contextual dinámico de condiciones territoriales, ambientales, biológicas, históricas, operacionales y humanas relevantes para una Biological Trajectory.

Evidence

Objeto o conjunto de relaciones capaz de respaldar o cuestionar una afirmación y cuya calidad puede evaluarse mediante procedencia, método, integridad y contexto.

FermentOps®

Dominio operacional de The Nebula Framework™ dedicado a observar, representar, modelar y gobernar procesos de fermentación.

Governance

Conjunto de autoridades, derechos, responsabilidades, políticas y procedimientos mediante los cuales se administran datos, modelos, identidades, decisiones y controversias.

Inference

Afirmación derivada mediante un Scientific Model, regla, análisis, simulación o interpretación.

Interoperability

Capacidad de sistemas y organizaciones para intercambiar y utilizar información conservando estructura, significado, procedencia y estatus epistemológico.

Knowledge Graph

Estructura de entidades, relaciones y afirmaciones utilizada para integrar, consultar y validar conocimiento.

Knowledge Model

Representación de conceptos, identidades, relaciones, restricciones y reglas semánticas de un dominio.

Living Knowledge Infrastructure™

Infraestructura capaz de incorporar Evidence, revisar modelos e inferencias, preservar versiones y permitir Temporal Evolution gobernada.

Observation

Resultado declarado de un acto de observación, medición, muestreo o inspección.

Ontology

Especificación formal o semiforme de conceptos, relaciones, restricciones y compromisos semánticos.

Originblok®

Infraestructura de identidad, procedencia y persistencia que vincula territorios, actores, materiales, procesos, Evidence y resultados.

Proof of Process™

Conjunto de pruebas que vincula una afirmación sobre una transformación con Evidence contextual, temporal y procedimental.

RoastOps®

Dominio operacional dedicado a representar y analizar transformaciones térmicas de tostado.

Scientific Model

Representación mecanística, estadística, probabilística, lógica o híbrida utilizada para describir, explicar, simular o predecir una Biological Trajectory.

Semantic Infrastructure

Conjunto de ontologías, vocabularios, identificadores, alineamientos, validadores y servicios que preservan significado e Interoperability.

Temporal Evolution

Cambio documentado de procesos, observaciones, modelos, ontologías, políticas o afirmaciones a través del tiempo.

TraceOps®

Dominio operacional encargado de integrar identidades, eventos, custodias, transformaciones y declaraciones de trazabilidad.

Trust Infrastructure

Conjunto de mecanismos científicos, técnicos y de Governance que permiten evaluar identidad, integridad, procedencia, legitimidad y alcance de Evidence y afirmaciones.

Bibliografía recomendada

  1. Bradner, S. RFC 2119: Key Words for Use in RFCs to Indicate Requirement Levels. Internet Engineering Task Force, BCP 14, 1997.

  2. Leiba, B. RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. Internet Engineering Task Force, BCP 14, 2017.

  3. World Wide Web Consortium. OWL 2 Web Ontology Language: Document Overview, Second Edition. W3C Recommendation, 2012.

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

  5. World Wide Web Consortium. Shapes Constraint Language --- SHACL. W3C Recommendation, 2017.

  6. World Wide Web Consortium. Semantic Sensor Network Ontology --- SSN/SOSA, 2023 Edition. W3C, 2023 Edition.

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

  8. International Organization for Standardization. ISO 23247-1:2021 --- Automation Systems and Integration: Digital Twin Framework for Manufacturing --- Overview and General Principles. ISO, 2021.

  9. International Organization for Standardization. ISO 23247-2:2021 --- Automation Systems and Integration: Digital Twin Framework for Manufacturing --- Reference Architecture. ISO, 2021.

  10. International Organization for Standardization. ISO 23247-5:2026 --- Automation Systems and Integration: Digital Twin Framework for Manufacturing --- Digital Thread for Digital Twin. ISO, 2026.

  11. International Organization for Standardization. ISO 23247-6:2026 --- Automation Systems and Integration: Digital Twin Framework for Manufacturing --- Digital Twin Composition. ISO, 2026.

  12. 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. ISO/IEC/IEEE, 2023.

  13. International Organization for Standardization e International Electrotechnical Commission. ISO/IEC 42001:2023 --- Information Technology --- Artificial Intelligence --- Management System. ISO/IEC, 2023.

  14. International Organization for Standardization e International Electrotechnical Commission. ISO/IEC 23894:2023 --- Information Technology --- Artificial Intelligence --- Guidance on Risk Management. ISO/IEC, 2023.

  15. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework 1.0. NIST AI 100-1, 2023.

  16. Wilkinson, M. D., Dumontier, M., Aalbersberg, I. J. et al. "The FAIR Guiding Principles for Scientific Data Management and Stewardship." Scientific Data, vol. 3, artículo 160018, 2016.

  17. Food and Agriculture Organization of the United Nations. Aspirational Principles and Criteria for a Sustainable Bioeconomy. FAO.

  18. Food and Agriculture Organization of the United Nations. Normative and Standard-Setting Instruments for Sustainable Bioeconomy. FAO.

Anexo A --- Canon doctrinal

The Nebula Framework™ reconoce como canon doctrinal los siguientes principios:

I. La Evidence precede a la opinión.

II. La transformación es el objeto de estudio.

III. El contexto otorga significado.

IV. El conocimiento debe ser reproducible.

V. La tecnología es un medio.

VI. La Interoperability fortalece el ecosistema.

VII. La evolución es continua.

VIII. La confianza se construye mediante transparencia.

Estos principios deberán interpretarse conjuntamente y bajo las definiciones de esta edición.

Anexo B --- Prueba de compatibilidad doctrinal

Una iniciativa podrá declararse compatible con The Nebula Doctrine™ únicamente cuando pueda demostrar que:

  1. distingue Observation, Evidence e Inference;
  2. representa la transformación mediante una estructura temporal adecuada;
  3. conserva el contexto necesario para interpretar sus datos;
  4. permite reconstruir resultados y decisiones relevantes;
  5. justifica cada tecnología mediante requisitos y alternativas;
  6. utiliza o alinea estándares de Interoperability cuando sea razonable;
  7. preserva Temporal Evolution de modelos y conceptos;
  8. permite auditar afirmaciones sin exceder límites legítimos de privacidad;
  9. identifica autoridades y responsabilidades;
  10. documenta riesgos, limitaciones y condiciones de revisión.

La ausencia de uno de estos elementos deberá tratarse como una desviación que requiere justificación y plan de corrección.

Anexo C --- Declaración Institucional

The Nebula Doctrine™ constituye el marco permanente de decisión de The Nebula Framework™.

Su propósito es asegurar que la investigación, la tecnología, los modelos, los estándares y la Governance permanezcan subordinados a Evidence verificable, contexto, reproducibilidad, Interoperability, evolución responsable y transparencia.

La doctrina no protege tecnologías, productos ni modelos de negocio particulares.

Protege la coherencia intelectual del Framework y su capacidad de corregirse mediante nueva Evidence.

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

The Nebula Framework™

ደራሲያን: Cafelium SRL, Cafelium Foundation

ፈቃድ: Proprietary

ስሪት: 1.0.0 · መጨረሻ የተዘመነ: 2026-07-19

ተዛማጅ ሰነዶች

Your browser does not support text-to-speech