#The Nebula Library™

#The Nebula Framework™ — Scientific Edition v1.0

---

#Convenciones normativas y epistemológicas

The Nebula Library™ define la infraestructura institucional mediante la cual los activos científicos, técnicos, semánticos, documentales y experimentales del ecosistema Nebula adquieren identidad persistente, contexto, procedencia, relaciones, versiones, condiciones de acceso y garantías de preservación.

En este documento, activo designa cualquier objeto material o digital que pueda contribuir a producir, justificar, interpretar, implementar o preservar conocimiento. Un activo puede ser un documento, dataset, Observation, Evidence, Scientific Model, Ontology, Knowledge Graph, software, API, protocolo, experimento, decisión, credencial, muestra física referenciada o paquete compuesto. La palabra archivo se reserva para una representación digital concreta; no se utiliza como sinónimo de activo, porque un mismo activo intelectual puede poseer varias representaciones y archivos.

Observation designa un resultado contextualizado de observación. Evidence designa un objeto o relación capaz de apoyar, contradecir o dejar indeterminada una afirmación. Inference designa una proposición derivada mediante un Scientific Model, cálculo, regla o interpretación experta. Knowledge Claim designa una afirmación explícita cuyo estado epistemológico, alcance y soporte pueden ser examinados.

Las expresiones DEBE, NO DEBE, DEBERÍA, NO DEBERÍA y PUEDE poseen fuerza normativa únicamente cuando aparecen en mayúsculas. Estas palabras expresan obligaciones del Framework, no necesariamente requisitos de una implementación tecnológica particular. Las implementaciones pueden variar mientras preserven las propiedades institucionales definidas por este documento.

El estado stable indica que NBL-LIB-001 constituye la definición institucional vigente de The Nebula Library™. Sin embargo, la estabilidad normativa no implica que cada hipótesis científica, modelo o activo contenido en la Library haya sido validado. La Library preserva objetos con estados epistemológicos diferentes y DEBE impedir que su coexistencia se interprete como equivalencia de autoridad.

Este documento distingue entre:

• hechos documentados, respaldados por fuentes verificables;
• hipótesis, abiertas a contrastación;
• interpretaciones, derivadas de Evidence mediante razonamiento declarado;
• visión institucional, que expresa un futuro deseado;
• decisiones arquitectónicas, revisables mediante The Nebula RFC™;
• requisitos normativos, aplicables a activos o procesos conformes.

---

#Prólogo

La ciencia no pierde conocimiento únicamente cuando desaparecen archivos. También lo pierde cuando los resultados sobreviven a los procedimientos, cuando una conclusión queda separada de sus supuestos o cuando una representación ya no puede interpretarse fuera del sistema que la creó. En una organización pequeña, parte de ese contexto puede permanecer en la memoria de sus fundadores; en un ecosistema científico y tecnológico, esa dependencia no escala.

Computational Bioeconomy™ intensifica el problema. Una Biological Trajectory puede comenzar en una finca, continuar mediante sensores y Observations, convertirse en dataset, alimentar un Scientific Model, producir una Inference y originar decisiones en FermentOps®, TraceOps® o RoastOps®. La continuidad científica exige que esas transformaciones puedan reconstruirse después de que cambien personas, instrumentos, formatos y plataformas.

The Nebula Library™ existe para preservar esa continuidad. No es solo una biblioteca de documentos, un repositorio Git, un data catalog, un archivo digital o un Knowledge Graph. Integra funciones de cada uno porque el conocimiento institucional requiere descubrimiento, custodia, preservación, relaciones semánticas y Governance. Esta integración no obliga a centralizar todos los bytes: los activos pueden permanecer distribuidos mientras su identidad, procedencia, estado, derechos y representación autorizada continúen resolubles.

Preservar tampoco significa acumular indiscriminadamente. Conservar sin selección, metadatos o curación produce olvido por saturación. La Library deberá deprecar, archivar y eliminar representaciones cuando corresponda, preservando suficiente memoria para explicar qué ocurrió. Su propósito es permitir que futuras generaciones comprendan qué sabía Nebula, cómo llegó a saberlo, qué permanecía incierto y qué Evidence modificó sus decisiones.

#Resumen Ejecutivo

The Nebula Library™ es la Living Knowledge Infrastructure™ destinada a registrar, organizar, preservar, versionar, relacionar, gobernar y publicar los activos científicos, tecnológicos, semánticos y documentales de The Nebula Framework™.

Su problema central es la fragmentación. Un archivo puede conservar contenido y perder contexto; un dataset puede permanecer accesible y dejar de ser interpretable; un Scientific Model puede ejecutarse y no ser reproducible; una decisión puede implementarse sin que sobrevivan las alternativas evaluadas. La Library convierte objetos dispersos en activos institucionales identificables y relacionados.

Su tesis es:

El conocimiento del ecosistema solo puede acumularse de manera confiable cuando cada activo relevante conserva identidad, contexto, procedencia, versión, estado, relaciones, responsabilidad, condiciones de uso y una estrategia de preservación proporcional a su valor y riesgo.

La Library cumple cuatro funciones. Como catálogo, permite descubrir activos. Como repositorio, almacena o referencia representaciones autorizadas. Como archivo de preservación, mantiene la información necesaria para interpretarlas a través del tiempo. Como Knowledge Graph, conecta Biological Process, Observation, Evidence, Scientific Model, Knowledge Claim, decisión e implementación.

Su modelo conceptual es:

$$\mathcal{L} = \langle A,I,M,P,R,V,G,S \rangle,$$

donde $A$ son activos; $I$, identidad; $M$, metadatos; $P$, procedencia y preservación; $R$, relaciones; $V$, versiones y estados; $G$, Governance; y $S$, servicios de descubrimiento, acceso y reutilización.

La Library adopta como referencias OAIS [1], ISO 16363 [2], ISO 15489-1 [3], ISO 23081-1 [4], PREMIS [5], FAIR [6], DCAT 3 [7], PROV-O [8], DataCite [9], BagIt [10] y la Recomendación de UNESCO sobre Ciencia Abierta [11]. Ninguna resuelve por sí sola el problema de Nebula; su valor reside en integrarlas mediante The Nebula Ontology™, The Nebula Knowledge Model™, The Nebula Governance Model™, The Nebula Standards™ y The Nebula RFC™.

Todo activo conforme deberá poseer identificador persistente, metadatos mínimos, versión, estado, responsable, procedencia, régimen de acceso, derechos, integridad verificable y relaciones relevantes. Los activos críticos deberán incluir estrategia de preservación y criterios de reproducibilidad.

La Library distinguirá entidad intelectual, representación, archivo y bitstream. También separará estado editorial de estado epistemológico. Una versión stable puede contener hipótesis abiertas, y un dataset draft puede incluir Observations válidas todavía no publicadas.

La apertura será gobernada. FAIR no significa necesariamente público. La Library deberá equilibrar colaboración con privacidad, seguridad, propiedad intelectual, contratos y derechos territoriales. Los agentes de IA deberán reconocer versión, vigencia, Evidence, idioma canónico, permisos y contradicciones.

La hipótesis institucional será apoyada si la Library reduce pérdida de contexto, facilita reproducción, mejora descubrimiento y permite reconstruir decisiones. Será debilitada si se convierte en una colección costosa sin utilidad, si concentra conocimiento sin beneficio para quienes lo producen o si la complejidad impide registrar activos oportunamente.

#Parte I — El problema de la memoria científica

#1. Conocimiento disperso y continuidad institucional

El conocimiento no se pierde únicamente cuando desaparece un archivo. También se pierde cuando el archivo permanece, pero ya no puede interpretarse. Una tabla sin unidades, un notebook sin entorno, una Ontology sin versión o una fotografía sin relación con el lote observado pueden conservar bytes y haber dejado de conservar conocimiento.

La fragmentación surge de manera natural. Cada herramienta optimiza su propósito local: el laboratorio registra resultados; Git conserva código; una plataforma operacional almacena eventos; un equipo comparte decisiones por mensajería; un repositorio académico publica artículos; una base de datos mantiene transacciones. Ninguno de estos sistemas, por separado, está obligado a preservar la continuidad epistemológica entre sus objetos.

The Nebula Library™ aborda precisamente esa discontinuidad. No intenta reemplazar los sistemas especializados. Introduce una capa institucional donde cada objeto relevante puede convertirse en un activo descrito, relacionado y gobernado.

#2. La diferencia entre información y conocimiento institucional

La información se convierte en conocimiento institucional cuando la organización puede responder, de manera reproducible, al menos cinco preguntas: qué es el objeto, de dónde proviene, cómo debe interpretarse, qué autoridad posee y con qué otros objetos se relaciona.

Un archivo puede contener información sin cumplir esas condiciones. Una colección de archivos puede ser abundante y carecer de memoria. El conocimiento institucional requiere contexto suficiente para que un actor distinto del creador original pueda evaluar el objeto.

La Library no presupone que todo contexto pueda formalizarse. Parte del conocimiento es tácito, territorial o narrativo. Sin embargo, incluso cuando no pueda convertirse en variables, puede registrarse como testimonio, anotación, protocolo, relación de autoría o limitación. Reconocer lo no formalizado es científicamente preferible a fingir que no existe.

#3. Memoria, autoridad y corrección

Una memoria institucional confiable debe preservar tanto continuidad como corrección. Si una afirmación se refuta, la Library no debe presentarla como vigente; pero eliminarla puede destruir el registro de la refutación y de las decisiones que se tomaron bajo su influencia.

La solución es separar preservación de autoridad. Un activo puede mantenerse disponible con estado superseded, deprecated, retracted o archived. Su existencia histórica no implica recomendación actual.

Esta separación es esencial para Living Knowledge Infrastructure™. El conocimiento vivo no es un conjunto que solo crece. Es un sistema donde claims cambian de estado, Evidence nueva modifica interpretaciones y las versiones anteriores continúan disponibles para reconstruir Temporal Evolution.

#4. Riesgos de no construir la Library

La ausencia de una infraestructura institucional produce riesgos científicos, tecnológicos y económicos. Científicamente, dificulta reproducción y favorece afirmaciones sin trazabilidad. Tecnológicamente, aumenta acoplamiento con plataformas o personas. Económicamente, obliga a repetir experimentos, reconstruir decisiones y renegociar derechos sobre activos mal documentados.

También crea riesgos éticos. El conocimiento aportado por Caficultores, operadores o socios puede quedar incorporado en modelos sin atribución. Los datos sensibles pueden circular sin clasificación. Una representación digital puede sobrevivir más tiempo que el consentimiento o el propósito que justificó su creación.

La Library existe para convertir esos riesgos en objetos de Governance.

---

#Parte II — Fundamentos y estado del arte

#5. Gestión documental y metadatos

ISO 15489-1:2016 define principios para crear, capturar y gestionar registros a través de distintos entornos [3]. ISO 23081-1:2017 extiende esa perspectiva hacia los metadatos que acompañan a los registros y a los procesos que los afectan [4]. Para Nebula, estas referencias establecen que un documento institucional no es solo contenido: es evidencia de una actividad, decisión u obligación, y sus metadatos forman parte de su capacidad de ser gestionado.

La Library abarca además datasets, Scientific Models, software y relaciones semánticas. Por ello, records management aporta autenticidad y responsabilidad, pero no agota el modelo.

#6. Preservación digital

ISO 14721:2025 define el modelo OAIS para organizaciones que aceptan responsabilidad por preservar información y hacerla comprensible para una comunidad designada a largo plazo [1]. Distingue ingest, almacenamiento, gestión de datos, administración, planificación de preservación y acceso. También aclara que «open» no significa acceso irrestricto.

OAIS aporta una idea central: preservar bits no basta. Se necesita Representation Information para que una comunidad futura interprete los objetos. En Nebula puede incluir unidades, Ontology, schemas, instrumentos, versiones de software, vocabularios y documentación de modelos.

ISO 16363:2025 proporciona una base para evaluar la confiabilidad de repositorios digitales [2]. The Nebula Library™ no declara certificación automática; adopta la orientación de que confianza requiere mandato, responsabilidades, sostenibilidad, gestión de objetos, infraestructura y seguridad.

#7. PREMIS, integridad y paquetes

PREMIS 3.0 describe Objects, Events, Rights y Agents relacionados con preservación [5]. La Library deberá poder mapear eventos como validación, migración, generación de checksum y verificación de integridad. PREMIS no sustituye The Nebula Ontology™, que debe representar Observation, Evidence, Biological Trajectory y Scientific Model.

RFC 8493 define BagIt para almacenamiento y transferencia de contenido digital mediante payloads, metadatos y manifiestos de checksums [10]. Puede emplearse en paquetes de preservación, recordando que un checksum demuestra fixity respecto a una referencia, no verdad científica ni legitimidad de uso.

#8. FAIR, Ciencia Abierta e identificación

FAIR promueve objetos Findable, Accessible bajo condiciones claras, Interoperable y Reusable [6]. Estos principios enfatizan identificadores persistentes, metadatos ricos, vocabularios, procedencia y procesamiento por máquinas. FAIR no equivale a abierto: un activo restringido puede ser FAIR si sus metadatos, acceso y condiciones están definidos.

La Recomendación de UNESCO sobre Ciencia Abierta añade inclusión, infraestructuras abiertas, diálogo con la sociedad y respeto al conocimiento tradicional [11]. Nebula adopta esta orientación sin afirmar que todo activo deba publicarse.

DataCite Metadata Schema 4.6 ofrece propiedades para identificar y citar datasets, software, muestras y otros resultados [9]. La Library deberá poder producir metadata compatible cuando un activo requiera DOI, mientras conserva identificadores internos para objetos operacionales, restringidos o intermedios.

#9. Catálogos, procedencia y Semantic Web

DCAT 3 permite describir catálogos, datasets, distribuciones, servicios, series y versiones, facilitando federación [7]. PROV-O representa procedencia mediante Entity, Activity y Agent [8]. SHACL permite validar restricciones sobre grafos RDF [12].

The Nebula Library Profile podrá combinar estas especificaciones con The Nebula Ontology™. La validación semántica reduce errores estructurales, pero no demuestra validez científica.

#10. Diferencia frente a infraestructuras existentes

Los repositorios institucionales organizan publicaciones y datasets; Git preserva código; los data catalogs mejoran descubrimiento; los archivos digitales atienden preservación; los Knowledge Graphs representan relaciones. Nebula requiere continuidad entre procesos biológicos, Evidence, modelos, decisiones y productos.

La contribución de la Library consiste en integrar esas capacidades alrededor de tres propiedades: estado epistemológico explícito, relación entre ciencia y operación sin confundirlas, y Governance territorial y de propiedad intelectual dentro del modelo de preservación.

#Parte III — Tesis y principios institucionales

#11. Tesis de acumulación confiable

$$Q_K=f(I,C,P,V,R,G,A),$$

donde la calidad del conocimiento acumulado $Q_K$ depende de identidad, contexto, procedencia, versionado, relaciones, Governance y accesibilidad autorizada. La expresión es conceptual: no mide verdad, pero identifica condiciones cuya ausencia reduce la capacidad de evaluar y reutilizar conocimiento.

#12. Identidad persistente

Todo activo relevante DEBE poseer un identificador único, estable y no reutilizable. La identidad no dependerá de rutas, nombres de archivo, URL o plataforma. Si el activo es retirado, su identificador no podrá reasignarse.

#13. Contexto como parte del activo

Los metadatos no son accesorios. Un documento requiere autoridad e historial; un dataset, variables, unidades, cobertura y calidad; un Scientific Model, supuestos, dominio, parámetros y validación. La Library utilizará perfiles especializados en lugar de un formulario universal.

#14. Procedencia obligatoria

La procedencia DEBE registrar origen y transformaciones materiales: Agents, Activities, instrumentos, software, datasets, muestras, algoritmos y decisiones. La granularidad será proporcional al riesgo y a la necesidad de reconstrucción.

#15. Temporal Evolution

Los activos Stable no podrán sustituirse silenciosamente. Las versiones, deltas y relaciones de reemplazo se conservarán según política. Esto también aplica a Ontology y vocabularios: una Observation histórica no debe reinterpretarse automáticamente mediante una definición posterior.

#16. Evidence vinculada

Todo Knowledge Claim material DEBERÍA relacionarse con Evidence favorable, adversa o indeterminada. El vínculo no convierte el claim en hecho; deberán conservarse método de Inference, incertidumbre, dominio y limitaciones.

#17. Semántica compartida

The Nebula Ontology™ define el lenguaje conceptual; The Nebula Knowledge Model™ organiza claims y Evidence; la Library materializa ambos mediante registros, mappings y servicios. La consistencia no exige vocabulario único, sino diferencias explícitas.

#18. Apertura responsable y preservación institucional

La Library favorecerá descubrimiento y colaboración cuando no comprometan privacidad, seguridad, propiedad intelectual, contratos o derechos territoriales. Evitará open washing: publicar sin que las comunidades de origen puedan comprender o beneficiarse.

La preservación DEBE contar con mandato, roles, recursos y verificación. Un backup reduce riesgo de pérdida, pero no garantiza interpretabilidad, derechos ni acceso futuro.

#Parte IV — Modelo conceptual de activos

#19. El activo como objeto compuesto

Un activo de conocimiento puede representarse como:

$$a = \langle id,\tau,c,m,p,v,s,r,g,\rho \rangle,$$

donde:

• $id$ es identidad;
• $\tau$ es tipo;
• $c$ es contenido intelectual;
• $m$ son metadatos;
• $p$ es procedencia;
• $v$ es versión;
• $s$ es estado;
• $r$ son relaciones;
• $g$ es Governance;
• $\rho$ es estrategia de preservación.

No todos los componentes se almacenan en un único sistema. La definición permite que el contenido permanezca externo mientras el registro institucional conserva las relaciones necesarias.

#20. Entidad intelectual, representación, archivo y bitstream

La Library DEBE distinguir al menos cuatro niveles.

La entidad intelectual es el objeto conceptual: una monografía, dataset, Ontology o modelo.

La representación es una forma completa de materializar esa entidad, como Markdown, PDF, Parquet o un contenedor de modelo.

El archivo es una unidad almacenada que participa en una representación.

El bitstream es una secuencia de bits incrustada o gestionada dentro de un archivo.

Esta separación evita duplicación semántica. También permite aplicar estrategias de preservación diferentes. Una representación PDF/A puede conservar apariencia; el Markdown puede conservar estructura editable; ambas representan la misma obra y pueden tener checksums independientes.

#21. Colecciones y paquetes de conocimiento

Una colección agrupa activos mediante un criterio institucional, temático o operativo. Un paquete de conocimiento agrega activos que, juntos, permiten comprender o reproducir una actividad.

Una investigación de fermentación puede constituir un paquete con hipótesis, protocolo, sensores, Observations, dataset, notebook, Scientific Model, resultados, informe, Evidence, decisiones y licencia. El paquete no elimina las identidades individuales. Declara una unidad de transferencia o interpretación.

#22. Relaciones semánticas

Las relaciones no deberán limitarse a hipervínculos. Cada relación deberá expresar un significado como deriva_de, utiliza, genera, valida, contradice, implementa, reemplaza, documenta, entrena, evalúa, cita o requiere.

Las relaciones podrán poseer procedencia, tiempo y confianza. La afirmación de que un experimento valida un modelo es, a su vez, un claim que puede requerir Evidence y revisión.

classDiagram
    class KnowledgeAsset {
        +assetId
        +assetType
        +status
        +version
        +canonicalLanguage
    }

    class IntellectualEntity {
        +title
        +description
        +authority
    }

    class Representation {
        +format
        +profile
        +preservationLevel
    }

    class FileObject {
        +filename
        +mediaType
        +checksum
    }

    class ProvenanceEvent {
        +eventType
        +eventTime
        +outcome
    }

    class Agent {
        +agentId
        +role
    }

    class Evidence {
        +evidenceStatus
        +quality
        +context
    }

    class KnowledgeClaim {
        +claimType
        +epistemicStatus
    }

    KnowledgeAsset "1" --> "1" IntellectualEntity : represents
    KnowledgeAsset "1" *-- "1..*" Representation
    Representation "1" *-- "1..*" FileObject
    KnowledgeAsset "1" --> "*" ProvenanceEvent
    ProvenanceEvent "*" --> "1..*" Agent
    KnowledgeClaim "*" --> "*" Evidence : supportedOrContradictedBy
    KnowledgeAsset "*" --> "*" KnowledgeAsset : semanticallyRelatedTo

#23. Estado epistemológico y estado editorial

La Library DEBE separar estado editorial de estado epistemológico. draft, review, stable o deprecated describen el ciclo institucional del activo. hypothesis, observed, inferred, validated, contradicted o indeterminate describen su relación con conocimiento y Evidence.

Un documento Stable puede contener hipótesis abiertas. Un dataset Draft puede contener Observations válidas aún no publicadas. Mezclar ambos ejes produciría errores de autoridad.

---

#Parte V — Arquitectura conceptual

#24. Núcleos integrados

La Library posee cuatro núcleos. El Catalog Core registra identidad, metadatos, localización y descubrimiento. El Repository and Preservation Core conserva o referencia representaciones, verifica integridad y ejecuta políticas. El Semantic and Knowledge Core relaciona activos mediante The Nebula Ontology™ y el Knowledge Graph. El Governance and Trust Core administra roles, acceso, licencias, auditoría y credenciales.

Los núcleos deberán ser separables aunque compartan servicios. Esta modularidad reduce dependencia tecnológica y permite federación.

flowchart TB
    U[Researchers · Caficultores · Engineers · Agents] --> D[Discovery and Access]
    D --> C[Catalog Core]
    D --> K[Semantic and Knowledge Core]
    C --> R[Repository and Preservation Core]
    K --> R
    G[Governance and Trust Core] --> C
    G --> K
    G --> R
    I[Ingestion and Validation] --> C
    I --> R
    I --> K
    R --> E[External Repositories and Storage]
    K --> O[The Nebula Ontology™]
    C --> F[Federated Catalogs]

#25. Catálogo y descubrimiento

El catálogo responde qué existe, quién es responsable, cuál versión está vigente, qué restricciones aplican y cómo acceder. Puede registrar contenido externo si conserva una referencia resoluble. DCAT 3 será base para perfiles federados, extendida para documentos, modelos, experimentos y Evidence.

Los servicios permitirán búsqueda textual, filtros, navegación semántica, resolución de identificadores, recuperación de versiones y consulta de procedencia. Deberán reconocer idioma canónico, traducciones y activos deprecados.

#26. Repositorio y preservación

La Library puede utilizar Git, object storage, bases de datos, repositorios científicos y sistemas documentales. No impone un backend único.

Las estrategias podrán incluir normalización, migración, emulación, conservación de entorno o documentación. Se elegirán según características significativas. Para un modelo de IA, pesos sin código y entorno pueden ser insuficientes; para un documento, texto y estructura pueden importar más que una interfaz histórica.

#27. Knowledge Graph y Evidence Infrastructure

El Knowledge Graph permite responder qué Evidence respalda un modelo, qué Ontology estaba vigente o qué RFC originó un Standard. Las relaciones materiales deberán poseer procedencia y distinguir declaraciones de inferencias automáticas.

Evidence podrá registrarse como activo de primer nivel. Un paquete puede incluir Observation, instrumento, calibración, procedimiento, contexto, checksum e incertidumbre. Proof of Process™ utilizará estas relaciones sin confundir integridad con verdad.

#28. APIs y eventos

La Library podrá exponer APIs para registrar, validar, resolver, recuperar y consultar activos. Eventos como AssetRegistered, VersionPublished, EvidenceLinked o AccessChanged integrarán sistemas externos. Los eventos son señales; el registro persistente conserva la memoria.

#Parte VI — Ciclo de vida e ingesta

#29. Estados institucionales

El ciclo de vida incluye draft, review, candidate, stable, experimental, deprecated, superseded, retracted, archived, restricted y embargoed. El estado editorial no sustituye la política de acceso ni el estado epistemológico.

stateDiagram
    [*] --> Draft
    Draft --> Review
    Review --> Draft: revisions requested
    Review --> Candidate
    Candidate --> Stable: approved
    Candidate --> Experimental
    Candidate --> Rejected
    Experimental --> Stable: validated
    Experimental --> Deprecated
    Stable --> Deprecated
    Stable --> Superseded
    Stable --> Retracted
    Deprecated --> Archived
    Superseded --> Archived
    Retracted --> Archived
    Rejected --> Archived

#30. Ingesta y validación

La ingesta transforma un objeto candidato en activo institucional. Verifica identidad, formato, metadata, derechos, procedencia, integridad, clasificación, relaciones y responsable.

La validación estructural comprueba campos, vocabularios y restricciones mediante SHACL, JSON Schema u otros mecanismos. La validación científica evalúa hipótesis, métodos, Evidence y conclusiones y requiere revisión experta. Ningún schema demuestra verdad.

#31. Publicación y acceso

Publicar significa hacer disponible una versión bajo condiciones explícitas; no implica acceso público. Cada publicación registrará fecha efectiva, representación y política. Un contenido mutable servido bajo una URL sin versión no será el único registro de una edición Stable.

#32. Deprecación, sustitución y retiro

La deprecación indica que un activo ya no es recomendado; la sustitución identifica reemplazo; la retracción comunica un defecto material. Cada estado deberá declarar razón, fecha, autoridad y consecuencias.

La eliminación física puede ser necesaria por privacidad, seguridad o contrato. Cuando sea legal y éticamente posible, el registro conservará identificador, estado y razón.

sequenceDiagram
    participant A as Asset Creator
    participant I as Ingestion Service
    participant C as Curator
    participant S as Steward
    participant R as Repository
    participant K as Knowledge Graph

    A->>I: Submit asset and metadata
    I->>I: Validate structure and integrity
    I->>C: Validation report
    C->>A: Request corrections
    C->>S: Recommend registration
    S->>R: Authorize deposit
    S->>K: Authorize semantic record
    R-->>S: Identifier and checksum
    K-->>S: Relationship validation

#Parte VII — Tipología de activos

#33. Familias principales

La Library gestionará perfiles diferenciados:

Un RFC rechazado conserva valor deliberativo; un Standard Stable posee autoridad normativa; un ADR documenta una decisión concreta. Estas categorías no deberán presentarse como equivalentes.

Un dataset no es automáticamente Evidence. Un Scientific Model no se reduce a su código. Un modelo de IA no se reduce a pesos. Una muestra física no es preservada por su registro digital. Cada perfil debe conservar las representaciones y relaciones necesarias para interpretar el activo.

#34. Colecciones y paquetes

Las colecciones agrupan activos por dominio, programa o autoridad. Los paquetes de conocimiento reúnen objetos necesarios para comprender o reproducir una actividad, manteniendo sus identidades individuales.

Una investigación de fermentación puede incluir protocolo, Biological Trajectory, Observations, dataset, notebook, modelo, informe, Evidence, licencia y decisiones. El paquete facilita transferencia sin borrar la estructura interna.

#Parte VIII — Identidad, metadatos y versionado

#35. Esquema de identificadores

Los identificadores internos podrán seguir patrones como NBL-DS-0001, NBL-MDL-0001, NBL-EXP-0001, NBL-API-0001 o NBL-ADR-0001. El namespace, secuencia y autoridad de asignación deberán estar documentados. Los identificadores no codificarán ubicación ni significado susceptible de quedar obsoleto.

La Library podrá relacionar DOI, ORCID, ROR, ISBN, URI y accession numbers, registrando tipo y autoridad. Un DOI no sustituye un identificador de persona u organización.

#36. Metadatos mínimos

La presencia de campos no garantiza calidad. Curación y validación deberán comprobar precisión, consistencia, actualidad y vocabularios.

#37. Versionado e idiomas

Cada versión declarará cambios, motivación, autoridad, compatibilidad, migración y activos afectados. El versionado semántico podrá utilizarse cuando su significado esté definido por el perfil. DCAT 3 permitirá intercambiar relaciones de versión y series [7].

El idioma canónico identifica la fuente institucional. Las traducciones se vincularán con la versión exacta de origen y declararán estado. Una traducción desactualizada no se presentará como equivalente vigente.

#Parte IX — Procedencia, Evidence y reproducibilidad

#38. Modelo de procedencia

La procedencia puede representarse mediante:

$$Entity \xleftarrow{wasGeneratedBy} Activity \xrightarrow{wasAssociatedWith} Agent.$$

Este patrón de PROV-O [8] permite conectar objetos con actividades y responsables. Nebula lo especializará para Biological Process, Observation, Inference, experimentos, curación y decisiones.

#39. Integridad, autenticidad y verdad

La integridad indica que el contenido no cambió respecto a una referencia. La autenticidad indica que el objeto puede atribuirse y contextualizarse de manera confiable. La verdad científica requiere evaluación de claims y Evidence.

Un hash puede apoyar integridad; una firma puede apoyar autenticidad; ninguna de las dos demuestra que una conclusión sea correcta. Originblok® y Proof of Process™ deberán conservar esta separación.

#40. Niveles de Evidence

La Library podrá utilizar una clasificación inicial:

• Nivel 0: no evaluado;
• Nivel 1: exploratorio;
• Nivel 2: experimental limitado;
• Nivel 3: validado dentro de un dominio;
• Nivel 4: consolidado mediante validaciones independientes.

La clasificación deberá alinearse con The Nebula Epistemology™ y no convertirse en puntuación automática. Un nivel alto en un dominio no autoriza extrapolación ilimitada.

#41. Reproducibilidad

La reproducibilidad exige conservar materiales suficientes para repetir un análisis o reconstruir un resultado: datos, código, entorno, parámetros, semillas, dependencias, instrucciones y resultados esperados.

La replicación científica exige un estudio independiente y no puede garantizarse mediante la Library. La infraestructura puede facilitarla al hacer explícitos métodos y assets.

#42. Paquetes reproducibles

Los paquetes podrán utilizar RO-Crate, BagIt u otras estructuras interoperables cuando sean apropiadas. BagIt aporta manifiestos e integridad para transferencia [10]; un perfil semántico puede añadir relaciones y contexto.

La Library no deberá depender de un único formato de paquete. Deberá definir qué propiedades mínimas deben sobrevivir a cualquier exportación.

---

#Parte X — Acceso, seguridad, privacidad y derechos

#43. Niveles de acceso

Los niveles iniciales podrán incluir público, comunidad, institucional, confidencial, restringido y embargo. Cada nivel deberá poseer criterios y autoridad de asignación.

El control de acceso se aplicará tanto al contenido como a metadata sensible. Incluso conocer que un activo existe puede revelar una estrategia, patente en preparación o relación contractual.

#44. Seguridad

La Library deberá aplicar autenticación, autorización, cifrado, auditoría, backups, recuperación, gestión de secretos, segregación y respuesta ante incidentes según riesgo.

La seguridad de preservación incluye disponibilidad y resiliencia. Un repositorio inaccesible durante años no cumple su propósito aunque sus datos permanezcan intactos.

#45. Privacidad

Los activos con datos personales deberán declarar finalidad, base jurídica, minimización, retención, acceso, anonimización o seudonimización y mecanismo de supresión cuando corresponda.

La procedencia no autoriza registrar indefinidamente cada acción individual. Debe existir proporcionalidad entre auditabilidad y privacidad.

#46. Propiedad intelectual

Cada activo deberá declarar régimen de derechos. Las categorías podrán incluir propietario, abierto, confidencial, licenciado, compartido, patentable o sujeto a contrato.

La ausencia de licencia no significa libertad de uso. La Library deberá impedir reutilización automática cuando los derechos sean ambiguos.

#47. Conocimiento territorial

El conocimiento de Caficultores y comunidades no deberá incorporarse como materia prima sin atribución, consentimiento y reglas de beneficio. Los registros podrán expresar custodios colectivos, restricciones culturales y condiciones de uso.

La Semantic Infrastructure deberá admitir que ciertos conocimientos no pueden publicarse, cuantificarse o transferirse sin pérdida o daño.

#48. Credenciales verificables

W3C Verifiable Credentials Data Model v2.0, Recommendation de 2025, ofrece un modelo interoperable para credenciales verificables [13]. La Library podrá utilizarlo para certificaciones, revisiones, autorizaciones o claims de conformidad.

Una credencial verificable demuestra que un emisor firmó una afirmación; no garantiza que el emisor sea competente ni que la afirmación continúe vigente. Governance deberá definir emisores, revocación y confianza.

---

#Parte XI — Federación e Interoperability

#49. Registro federado

La Library podrá evolucionar hacia un modelo donde universidades, laboratorios, Caficultores y socios mantengan activos en sus propios sistemas y publiquen metadata en un catálogo común.

La federación reduce centralización, pero introduce problemas de disponibilidad, resolución, identidad, políticas y consistencia. Cada nodo deberá declarar responsabilidades y acuerdos de servicio.

#50. Interoperability por capas

La Interoperability comprende:

• nivel técnico: protocolos y formatos;
• nivel estructural: schemas y validación;
• nivel semántico: significado y vocabularios;
• nivel epistemológico: distinción entre Observation, Evidence e Inference;
• nivel organizacional: roles, derechos y procesos;
• nivel temporal: versiones y vigencia.

El intercambio de JSON no garantiza Interoperability si cada sistema interpreta validated de manera diferente.

#51. Perfiles y mappings

The Nebula Library Profile podrá combinar DCAT, Dublin Core, DataCite, PROV-O, PREMIS y The Nebula Ontology™. Los mappings deberán documentar equivalencias, aproximaciones y pérdidas.

No toda clase Nebula tendrá equivalente externo. En esos casos, la extensión deberá ser explícita y no reutilizar términos externos con significado incompatible.

#52. Portabilidad

Todo activo crítico DEBERÍA poder exportarse con metadata, relaciones, integridad y derechos en formatos documentados. La portabilidad reduce dependencia de proveedores y permite preservación distribuida.

La exportación deberá incluir suficiente contexto para que un receptor autorizado pueda reconstruir identidad y relaciones sin acceso al sistema original.

---

#Parte XII — La Library como infraestructura para IA

#53. Corpus gobernado

La Library podrá alimentar búsqueda semántica, RAG, agentes científicos y sistemas de recomendación. Su valor no reside solo en volumen, sino en ofrecer fuentes versionadas, procedencia, permisos y estado epistemológico.

Un corpus sin estas propiedades puede amplificar contenido obsoleto o mezclar borradores con Standards. La recuperación deberá filtrar por vigencia, idioma, autoridad, dominio y acceso.

#54. Citación y trazabilidad de respuestas

Los agentes deberán devolver identificadores y versiones de los activos utilizados. Cuando una respuesta combine Evidence e Inferences, esa composición deberá ser transparente.

Las respuestas generadas no se registrarán automáticamente como conocimiento Stable. Podrán convertirse en candidatos a activo después de revisión y procedencia adecuada.

#55. Restricciones de entrenamiento

El permiso de lectura no implica permiso de entrenamiento. Los activos deberán declarar si pueden utilizarse para entrenamiento, evaluación, embeddings, extracción o generación.

Los modelos derivados deberán relacionarse con datasets y licencias. La Library deberá poder responder qué activos contribuyeron a un modelo y qué restricciones heredó.

#56. Protección contra contaminación epistemológica

Los agentes no deberán tratar frecuencia de aparición como evidencia de verdad. La Library facilitará filtros por Evidence Level, estado y contradicciones.

Un claim contradicho puede conservarse para historia, pero no debe recuperarse como recomendación actual sin advertencia. Esto exige que la búsqueda combine relevancia textual con Governance y semántica.

---

#Parte XIII — Governance y operación

#57. Roles

El Library Steward responde por integridad, política y continuidad. El Collection Steward administra una colección. El Asset Owner responde por propósito y derechos. El Curator mejora metadata y relaciones. El Reviewer evalúa aspectos científicos, técnicos, legales o lingüísticos. Security Officer y Data Protection Officer supervisan controles especializados.

En etapas tempranas una persona puede asumir varios roles, pero las responsabilidades deberán permanecer diferenciadas.

#58. Cambios y Standards

Las modificaciones materiales en schema, identificadores, estados, preservación, acceso o federación deberán tramitarse mediante The Nebula RFC™. La Library preservará versiones, objeciones, Evidence, decisión e implementaciones.

The Nebula Standards™ publicará perfiles normativos y pruebas de conformidad. NBL-LIB-001 define el modelo institucional, no una plataforma única.

#59. Métricas y auditoría

Las métricas deberán evaluar utilidad y riesgo: cobertura de metadata, activos sin steward, tiempo de ingestión, reutilización, resultados reproducibles, incidencias de integridad, activos deprecados aún consumidos, disponibilidad, costo y beneficios territoriales.

Un número alto de activos puede indicar crecimiento o acumulación sin curación. Las métricas requieren contexto.

La auditoría mantendrá historial de creación, modificación, acceso, publicación, permisos, migración y eliminación, aplicando minimización de datos personales.

#Parte XIV — Casos de uso

#60. Investigación de fermentación de café

Un proyecto registra un lote, contexto Digital Terroir®, protocolo, sensores, Observations, muestras, dataset, Scientific Model, Inferences y resultados sensoriales. La Library asigna identidades, conserva relaciones y permite reconstruir qué versión del modelo produjo cada recomendación.

Cuando una nueva temporada contradice una relación previa, la Evidence adversa se vincula al claim. El modelo anterior puede pasar a deprecated sin borrar su uso histórico.

#61. Publicación de un Standard

Un RFC aceptado origina un Standard. La Library conserva el RFC, objeciones, decisión, Standard, pruebas de conformidad e implementaciones.

Una nueva edición del Standard declara qué versiones sustituye y qué migración requiere. Los productos pueden declarar conformidad con una versión exacta.

#62. Liberación de un modelo de IA

El modelo se registra con código, pesos, dataset, métricas, Model Card, licencias y entorno. Una versión de producción se vincula con su deployment y con las Inferences generadas.

Si se descubre sesgo territorial, la evaluación se registra como Evidence adversa, el modelo se restringe y se inicia un RFC para modificar el proceso de validación.

#63. Colaboración universitaria federada

Una universidad conserva datasets en su repositorio y publica metadata compatible con DCAT. La Library los registra como activos federados, preserva DOI, licencia, versión y relaciones con proyectos Nebula.

El acceso se realiza desde la fuente. Si el recurso deja de estar disponible, la Library conserva el registro y activa la política acordada de preservación o contingencia.

#64. Proof of Process™

Un lote comercial requiere demostrar una secuencia de transformación. Proof of Process™ reúne eventos, firmas, Observations, checksums y decisiones almacenados o referenciados por la Library.

La prueba demuestra integridad y procedencia dentro del alcance declarado. No demuestra automáticamente calidad sensorial, sostenibilidad o cumplimiento no incluido.

---

#Parte XV — Validación y refutación del modelo

#65. Preguntas de validación

La Library deberá demostrar que una persona distinta del autor puede comprender un activo; que puede reconstruirse el origen de una Inference; que la versión utilizada en una decisión es recuperable; que una exportación preserva significado esencial; y que Evidence contradictoria puede encontrarse.

#66. Líneas base y pruebas

La evaluación comparará la Library con carpetas compartidas, repositorios aislados, wikis o catálogos sin semántica. Se medirán tiempo de descubrimiento, errores evitados, reproducción, migración, cumplimiento y continuidad.

Las pruebas de conformidad incluirán identificadores, metadata, relaciones, checksums, procedencia, versiones, acceso, portabilidad y simulación de pérdida de proveedor.

#67. Refutación institucional

La hipótesis será debilitada si los usuarios continúan dependiendo de canales informales; si el registro cuesta más que el valor generado; si los activos no pueden interpretarse; si la procedencia es ceremonial; si la IA viola permisos; si los actores territoriales no reciben beneficio; o si la preservación no supera la vida de una plataforma.

Estas fallas pueden exigir simplificar, modificar o abandonar componentes, no atribuir automáticamente el problema a «falta de adopción».

#Parte XVI — Limitaciones

La Library no preserva el mundo material. Un registro de una muestra no evita su degradación.

No garantiza verdad científica. Conserva Evidence y relaciones para facilitar evaluación.

No elimina conocimiento tácito. Puede documentarlo parcialmente, pero una representación no sustituye experiencia.

No resuelve por sí sola incentivos. Los participantes pueden omitir metadata o evitar registrar resultados negativos.

No asegura permanencia absoluta. Toda infraestructura depende de recursos, organizaciones y decisiones.

No puede hacer interoperable cualquier diferencia semántica. Algunos conceptos son inconmensurables o dependen de contextos locales.

No elimina riesgos de vigilancia. Más procedencia puede aumentar exposición si Governance es débil.

No convierte apertura en equidad. Publicar datos puede beneficiar principalmente a actores con mayor capacidad técnica.

No evita obsolescencia de formatos o modelos. Solo permite gestionarla.

No garantiza reproducibilidad cuando faltan materiales, derechos o condiciones ambientales.

No debe convertirse en sustituto de revisión científica, archivo jurídico, sistema operacional o repositorio especializado.

---

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

La agenda prioritaria comprende:

timeline
    title Evolución de The Nebula Library™
    Fase I : Catálogo e identificadores
           : Standards y RFC
    Fase II : Datasets, experimentos y modelos
            : Procedencia y Evidence
    Fase III : Knowledge Graph
             : Semantic Infrastructure
    Fase IV : Federación
            : Repositorios asociados
    Fase V : IA gobernada
           : Reproducción asistida
           : Auditoría independiente

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

La Library opera como capacidad transversal. Preserva relaciones entre estos componentes sin sustituir sus responsabilidades.

#Conclusiones

The Nebula Library™ es la memoria oficial y la infraestructura de continuidad de The Nebula Framework™. Su objeto no es almacenar todos los archivos, sino asegurar que los activos relevantes puedan identificarse, interpretarse, verificarse, relacionarse, preservarse y reutilizarse bajo Governance explícita.

Integra catálogo, repositorio, archivo de preservación y Knowledge Graph porque ninguna función resuelve aisladamente el problema. El catálogo sin preservación descubre objetos que pueden desaparecer; el repositorio sin semántica conserva archivos difíciles de relacionar; el grafo sin objetos confiables conecta afirmaciones frágiles; el archivo sin acceso puede preservar sin producir conocimiento útil.

La unidad fundamental es el Knowledge Asset: entidad intelectual con representaciones, metadata, procedencia, versión, estado, relaciones, derechos y estrategia de preservación. Esta unidad permite continuidad a través de formatos y plataformas.

La Library adopta OAIS, ISO 16363, PREMIS, FAIR, DCAT, PROV-O, DataCite, BagIt y Ciencia Abierta dentro de una epistemología de Computational Bioeconomy™. Preservación no equivale a verdad; integridad no equivale a autenticidad; FAIR no equivale a público; y una credencial no implica confianza ilimitada.

La Library cumplirá su propósito si reduce dependencia de memoria individual, facilita reproducción, conserva desacuerdo, permite migración y devuelve valor a quienes generan conocimiento. Si se transforma en burocracia o extracción centralizada, deberá revisarse mediante Evidence y The Nebula RFC™.

#Glosario

Activo: objeto registrado por su contribución a conocimiento, Evidence, operación o decisión.

Archivo: unidad digital concreta que participa en una representación.

Biological Trajectory: representación temporal y contextualizada de un Biological Process.

Catálogo: servicio de metadata para descubrir y resolver activos.

Checksum: valor calculado sobre bytes para verificar fixity.

Digital Terroir®: representación computacional y gobernada de interacciones que configuran una Biological Trajectory.

Evidence: objeto o relación que apoya, contradice o deja indeterminada una afirmación.

FAIR: principios Findable, Accessible, Interoperable y Reusable.

Governance: sistema de autoridad, responsabilidades, reglas y revisión.

Inference: proposición derivada mediante Scientific Model, cálculo o interpretación.

Intellectual Entity: objeto conceptual que puede poseer varias representaciones.

Interoperability: capacidad de intercambiar activos conservando estructura, semántica, procedencia, estado y Governance.

Knowledge Asset: activo identificado y contextualizado que contribuye al conocimiento.

Knowledge Claim: afirmación con alcance, estado epistemológico y Evidence relacionada.

Knowledge Graph: representación computacional de entidades y relaciones.

Living Knowledge Infrastructure™: infraestructura que preserva activos, Evidence, versiones y contradicciones.

Metadata: información estructurada sobre identidad, contexto, derechos y gestión.

Observation: resultado contextualizado de observar, medir o inspeccionar.

Ontology: especificación explícita de clases, propiedades y restricciones.

Preservation: acciones destinadas a mantener acceso e interpretabilidad a través del tiempo.

Procedencia: historia del origen, producción y transformación de un activo.

Representation: forma completa mediante la cual se materializa una entidad intelectual.

Reproducibilidad: capacidad de reconstruir un análisis con materiales suficientemente documentados.

Semantic Infrastructure: ontologías, vocabularios, identificadores y mappings que preservan significado.

Temporal Evolution: cambio versionado de activos, claims, Evidence o políticas.

Trust Infrastructure: mecanismos para evaluar identidad, integridad, procedencia y autoridad.

#Bibliografía recomendada

1. International Organization for Standardization. ISO 14721:2025 — Space Data System Practices — Reference model for an open archival information system (OAIS). Edition 3, 2025.

2. International Organization for Standardization. ISO 16363:2025 — Space data and information transfer systems — Audit and certification of trustworthy digital repositories. Edition 2, 2025.

3. International Organization for Standardization. ISO 15489-1:2016 — Information and documentation — Records management — Part 1: Concepts and principles. Edition 2, confirmed.

4. International Organization for Standardization. ISO 23081-1:2017 — Information and documentation — Records management processes — Metadata for records — Part 1: Principles. Edition 2, confirmed.

5. PREMIS Editorial Committee. PREMIS Data Dictionary for Preservation Metadata, Version 3.0. Library of Congress, 2015; current official version with maintained schemas and errata.

6. Wilkinson, M. D. et al. “The FAIR Guiding Principles for scientific data management and stewardship.” Scientific Data, 3, 160018, 2016. DOI: 10.1038/sdata.2016.18.

7. World Wide Web Consortium. Data Catalog Vocabulary (DCAT) — Version 3. W3C Recommendation, 22 August 2024.

8. World Wide Web Consortium. PROV-O: The PROV Ontology. W3C Recommendation, 30 April 2013.

9. DataCite Metadata Working Group. DataCite Metadata Schema Documentation for the Publication and Citation of Research Data and Other Research Outputs, Version 4.6. DataCite e.V., 2024. DOI: 10.14454/mzv1-5b55.

10. Kunze, J.; Littman, J.; Madden, E.; Scancella, J.; Adams, C. RFC 8493 — The BagIt File Packaging Format (V1.0). RFC Editor, 2018. DOI: 10.17487/RFC8493.

11. UNESCO. Recommendation on Open Science. Adopted by the General Conference, 23 November 2021.

12. World Wide Web Consortium. Shapes Constraint Language (SHACL). W3C Recommendation, 20 July 2017.

13. World Wide Web Consortium. Verifiable Credentials Data Model v2.0. W3C Recommendation, 15 May 2025.

14. Consultative Committee for Space Data Systems. Reference Model for an Open Archival Information System (OAIS), Magenta Book. Referencia complementaria asociada a ISO 14721:2025.

15. Research Data Alliance. FAIR Data Maturity Model: Specification and Guidelines. Referencia sugerida.

---

#Anexo A — Perfil mínimo de un activo

id: NBL-<TYPE>-<NUMBER>
title: Human-readable title
assetType: document | dataset | model | experiment | ontology | software | evidence
version: 1.0.0
status: draft | review | candidate | stable | experimental | deprecated | superseded | archived
canonicalLanguage: es-419
authors:
  - Agent identifier
owner: Institutional owner
steward: Responsible steward
createdAt: YYYY-MM-DD
updatedAt: YYYY-MM-DD
description: Purpose and scope
license: Declared rights regime
confidentiality: public | community | institutional | confidential | restricted
provenance:
  generatedBy: Activity identifier
  derivedFrom:
    - Asset identifier
relatedAssets:
  - relation: uses
    target: NBL-...
integrity:
  algorithm: sha-256
  checksum: "<digest>"
preservation:
  retentionPolicy: policy identifier
  preferredFormats:
    - media/type

El perfil es ilustrativo. Los perfiles normativos deberán publicarse mediante The Nebula Standards™.

---

#Anexo B — Matriz de conformidad institucional

---

#Anexo C — Reglas de identificadores

1. Un identificador DEBE ser único dentro del namespace de Nebula.
2. Un identificador NO DEBE reutilizarse después de retiro o eliminación.
3. El identificador NO DEBERÍA codificar ubicación física.
4. Los alias y antiguos identificadores DEBEN conservarse como relaciones.
5. Los identificadores externos DEBEN registrar autoridad y tipo.
6. Las versiones DEBEN relacionarse con la entidad intelectual y no crear ambigüedad.
7. La resolución DEBERÍA devolver metadata de estado aun cuando el contenido no esté disponible.
8. La asignación DEBE quedar auditada.
9. La federación DEBE prevenir colisiones de namespace.
10. Los identificadores públicos DEBERÍAN ser citables y persistentes.

---

#Anexo D — Declaración institucional

The Nebula Library™ constituye el catálogo, repositorio, archivo de preservación y Knowledge Graph institucional del ecosistema Nebula.

Su finalidad es asegurar que todo activo científico, técnico, semántico, documental o experimental relevante pueda ser identificado, comprendido, verificado, relacionado, gobernado, preservado y reutilizado de acuerdo con su contexto y sus derechos.

La Library transforma objetos dispersos en patrimonio institucional sin exigir que todos los bytes estén centralizados. Preserva la relación entre Biological Process, Observation, Evidence, Scientific Model, Knowledge Claim, decisión e implementación.

Toda implementación deberá mantener una distinción explícita entre integridad, autenticidad, autoridad y validez científica.

La Library deberá evolucionar mediante The Nebula RFC™, cumplir perfiles publicados por The Nebula Standards™ y permanecer sujeta a The Nebula Governance Model™.

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

The Nebula Framework™