#The Nebula Standards™

#The Nebula Framework™ — Scientific Edition v1.0

---

#Convenciones normativas y estatuto del documento

The Nebula Standards™ constituye el estándar raíz para la creación, identificación, descripción, versionado, validación, publicación, interoperabilidad, preservación y Governance de los activos oficiales de The Nebula Framework™. Su autoridad deriva de The Nebula Constitution™ y de The Nebula Governance Model™. Los estándares específicos deberán interpretarse como perfiles o extensiones de esta norma y no como sistemas normativos independientes.

Las palabras DEBE, NO DEBE, REQUERIDO, DEBERÁ, NO DEBERÁ, DEBERÍA, NO DEBERÍA, RECOMENDADO, PUEDE y OPCIONAL, cuando aparezcan en mayúsculas, expresan requisitos conforme a la tradición de BCP 14, integrada por RFC 2119 y RFC 8174. Las mismas palabras en minúsculas conservan su significado ordinario y no adquieren automáticamente fuerza normativa.

En esta norma, un activo es cualquier objeto científico, semántico, tecnológico, documental, organizacional o probatorio reconocido por el ecosistema. Una especificación define requisitos o comportamientos esperados. Una implementación materializa total o parcialmente una especificación. La conformidad de una implementación no convierte sus decisiones particulares en requisitos universales.

Una Observation es el resultado contextualizado de un acto de medición, muestreo, inspección o percepción. Evidence es un objeto o relación que respalda, contradice o deja indeterminada una afirmación. Inference es una proposición derivada mediante un Scientific Model, cálculo, regla o interpretación. Estas categorías NO DEBEN utilizarse como sinónimos.

El estado Stable significa que la versión 1.0.0 es la referencia normativa vigente desde su fecha efectiva. No significa que la norma sea inmutable, completa o aplicable sin perfiles a todos los dominios futuros. Toda revisión deberá conservar la interpretación histórica de los activos creados bajo versiones anteriores.

---

#Prólogo

Un ecosistema científico y tecnológico puede acumular gran cantidad de información y, sin embargo, perder la capacidad de comprenderla. Esto ocurre cuando los identificadores cambian con la ubicación de los archivos, cuando las unidades se omiten, cuando una predicción se presenta como Observation, cuando un dataset se modifica sin incrementar versión o cuando una interfaz pública evoluciona sin permitir que los consumidores migren.

La pérdida no siempre es visible. Los documentos continúan abriendo; las APIs continúan respondiendo; los dashboards continúan mostrando valores. Lo que desaparece es la continuidad del significado.

The Nebula Framework™ requiere Standards porque integra procesos biológicos, instrumentos, Scientific Models, Knowledge Graph, sistemas de inteligencia artificial, conocimiento territorial y decisiones institucionales. Cada componente puede evolucionar a distinta velocidad. Sin reglas comunes, esa diversidad produce fragmentación semántica, incompatibilidad técnica y debilitamiento de Evidence.

La standardization no deberá confundirse con uniformidad. Su propósito es estabilizar identidad, metadatos, procedencia, contratos, estados, conformidad y mecanismos de cambio sin impedir diversidad científicamente justificada.

La experiencia internacional demuestra que un estándar de calidad requiere revisión, implementación, pruebas, mantenimiento y resolución de objeciones. The Nebula Standards™ adopta estos principios sin reproducir automáticamente los órganos o categorías de otras organizaciones.

El estándar raíz deberá servir a investigadores, Caficultores, operadores, universidades, laboratorios, desarrolladores, socios tecnológicos y agentes de inteligencia artificial. Para lograrlo, deberá ser suficientemente preciso para permitir validación automática y suficientemente narrativo para explicar por qué existen sus requisitos.

La formalización puede aumentar consistencia y costo de adopción. Por ello, los requisitos deberán ser proporcionales al riesgo, la madurez y el uso previsto, manteniendo siempre identidad, propósito, versión y procedencia.

---

#Resumen Ejecutivo

The Nebula Standards™ transforma los principios científicos, epistemológicos, semánticos, arquitectónicos y de Governance del Framework en requisitos verificables. Define las condiciones mínimas para que un documento, dataset, Observation, Evidence Artifact, Scientific Model, modelo de IA, Ontology, API, evento, experimento, implementación o paquete de Proof of Process™ pueda ser reconocido como activo oficial.

El estándar adopta nueve compromisos fundamentales.

Primero, todo activo oficial posee identidad persistente y no reutilizable. La identidad institucional no dependerá del nombre del archivo, su ubicación, una URL temporal o la tecnología que lo almacena.

Segundo, todo activo conserva metadatos suficientes para interpretarse. Los documentos Markdown utilizarán YAML Frontmatter; otros activos deberán ofrecer un registro equivalente. El modelo de metadatos incluirá autoría, idioma, estado, versión, licencia, relaciones y fechas.

Tercero, la semántica prevalece sobre el formato. Un activo puede migrar entre Markdown, RDF, JSON-LD, bases relacionales u otros formatos sin cambiar de identidad conceptual, siempre que el significado y la procedencia se preserven.

Cuarto, Observation, Evidence, Inference, Hypothesis y Knowledge Claim permanecen diferenciados. Una firma, un hash o una validación de schema puede demostrar integridad o conformidad estructural, pero NO demuestra por sí sola la verdad de una afirmación.

Quinto, toda modificación material produce una nueva versión. Nebula adopta MAJOR.MINOR.PATCH como convención general, pero interpreta el incremento según el contrato público de cada familia de activos. Una corrección editorial no equivale a un cambio semántico; una nueva serialización no equivale necesariamente a una nueva versión conceptual.

Sexto, la Interoperability se diseña desde el inicio. Comprende niveles técnico, estructural, semántico, epistemológico y de Governance. Los estándares internacionales deberán reutilizarse cuando representen adecuadamente el requisito y no produzcan equivalencias falsas.

Séptimo, la conformidad es verificable y graduada. Un activo podrá ser conforme, parcialmente conforme, experimental o no conforme. La conformidad parcial deberá identificar requisitos incumplidos, riesgo, mitigación, responsable y plazo.

Octavo, los cambios incompatibles requieren migración y preservación histórica. Un activo Stable NO DEBE reemplazarse silenciosamente. Los consumidores deberán disponer de información suficiente para actualizarse o continuar interpretando versiones anteriores.

Noveno, la standardization se somete a Governance. Todo estándar específico deberá originarse mediante The Nebula RFC™, declarar responsables, recibir revisión proporcional, incluir pruebas de conformidad y registrarse en The Nebula Library™.

La norma organiza los activos mediante un modelo común:

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

donde $I$ representa identidad; $T$, tipo; $V$, versión; $S$, semántica; $P$, procedencia; $R$, relaciones; $G$, Governance; y $C$, conformidad. Esta estructura no obliga a utilizar una base de datos concreta. Define la información que deberá permanecer resoluble.

Los documentos oficiales conservarán YAML Frontmatter, un único título principal, estructura legible, bloques correctamente cerrados, terminología oficial y declaración institucional. Las fechas utilizarán ISO 8601. Las referencias temporales que requieran hora deberán incluir zona horaria u offset, evitando tiempos locales ambiguos.

Las representaciones semánticas deberán alinearse con The Nebula Ontology™. RDF, OWL, JSON-LD, PROV-O, DCAT y SHACL podrán utilizarse mediante perfiles versionados. SHACL 2017 continúa siendo la Recommendation estable para validación de grafos; las capacidades de SHACL 1.2 publicadas como Working Draft en 2026 podrán evaluarse experimentalmente, pero no deberán declararse requisitos estables sin una decisión posterior.

Las APIs deberán describirse mediante un contrato independiente del lenguaje. OpenAPI 3.2.0, publicada en 2025, constituye una referencia vigente para interfaces HTTP. Los eventos podrán adoptar CloudEvents 1.0.2 como envelope interoperable, conservando esquemas y semántica Nebula para el payload.

Las credenciales digitales podrán utilizar W3C Verifiable Credentials Data Model 2.0, Recommendation desde mayo de 2025, cuando sea necesario expresar claims emitidos por una autoridad, presentaciones verificables o estados de certificación. La verificabilidad criptográfica NO implica que los claims incluidos sean verdaderos; el verificador deberá aplicar políticas y Evidence.

La norma será validada si permite que equipos independientes creen activos compatibles, interpreten versiones históricas, detecten incumplimientos y migren sin pérdida material de significado. Deberá revisarse si la carga normativa supera persistentemente el valor, si los equipos crean convenciones paralelas o si la conformidad formal oculta defectos científicos.

---

#1. Propósito normativo

The Nebula Standards™ existe para impedir que la evolución del ecosistema degrade identidad, significado, Evidence o capacidad de reproducción.

Su propósito es establecer una base común para que cualquier activo oficial pueda:

• identificarse inequívocamente;
• interpretarse dentro de un contexto compartido;
• relacionarse con otros activos;
• conservar su procedencia;
• declarar versión y estado;
• someterse a revisión;
• verificar su conformidad;
• interoperar con implementaciones distintas;
• preservarse durante Temporal Evolution.

El estándar también delimita aquello que una prueba de conformidad puede y no puede demostrar. Validar YAML demuestra que el Frontmatter puede analizarse. Validar JSON Schema demuestra que una instancia cumple determinadas restricciones. Validar SHACL demuestra conformidad de un grafo con shapes. Ninguna de estas pruebas demuestra automáticamente que una Observation sea exacta, que un Scientific Model sea válido o que una decisión sea legítima.

---

#2. Alcance

Esta norma se aplica a activos creados, administrados, publicados o reconocidos oficialmente por Cafelium SRL dentro de The Nebula Framework™.

El alcance incluye documentos fundacionales, monografías científicas, White Papers, Standards, RFC, Architecture Decision Records, políticas, Ontology, vocabularios, Scientific Models, modelos matemáticos, modelos de IA, datasets, Observations, Evidence Artifacts, experimentos, APIs, SDKs, eventos, schemas, Knowledge Graph, implementaciones de referencia, activos de The Nebula Library™, Originblok® y Proof of Process™.

El estándar NO prescribe una infraestructura de nube, lenguaje, motor de grafos, blockchain, base de datos ni framework de inteligencia artificial. La tecnología podrá variar si conserva los requisitos aplicables.

Los activos exclusivamente personales, borradores informales o notas de trabajo pueden permanecer fuera del registro oficial. Cuando sean utilizados como Evidence, fundamento de una decisión o dependencia de un activo publicado, deberán ingresar al ciclo de Governance con una clasificación apropiada.

---

#3. Fundamentos de standardization

#3.1 Estándar, especificación y perfil

Un estándar establece reglas generales aprobadas mediante Governance. Una especificación describe requisitos para un objeto o interfaz. Un perfil selecciona, restringe o combina requisitos de estándares para un Context of Use.

Un perfil NO DEBE redefinir el significado de términos heredados. Cuando una diferencia sea necesaria, deberá crear un término nuevo o documentar una incompatibilidad.

#3.2 Requisito y explicación

La narrativa explica por qué existe un requisito; el texto normativo declara qué debe cumplirse. Un documento de calidad necesita ambos.

Una explicación NO DEBE utilizarse para introducir obligaciones ocultas. Todo requisito verificable deberá aparecer mediante lenguaje normativo o una tabla explícita de conformidad.

#3.3 Estado del arte

The Nebula Standards™ toma como referencias metodológicas:

• BCP 9 para madurez, implementación y experiencia operacional;
• BCP 14 para lenguaje normativo;
• el W3C Process para consenso, madurez, objeciones e implementación;
• las ISO/IEC Directives para estructura y redacción;
• ISO 8601 para representación temporal;
• FAIR para descubrimiento, acceso, Interoperability y reutilización;
• W3C PROV-O para procedencia;
• W3C DCAT 3 para catálogos;
• W3C SHACL para validación de grafos;
• W3C Verifiable Credentials 2.0 para credenciales verificables;
• JSON Schema para contratos JSON;
• OpenAPI para interfaces HTTP;
• CloudEvents para envelopes de eventos.

Estas referencias no se incorporan completas por simple mención. Cada estándar específico deberá declarar qué versión y qué partes adopta.

#3.4 Neutralidad tecnológica

La neutralidad tecnológica significa que la norma especifica resultados, contratos y propiedades antes que productos concretos.

No significa neutralidad respecto a seguridad, derechos o semántica. Una tecnología que impide exportación, auditoría o preservación puede ser incompatible aunque satisfaga una función inmediata.

---

#4. Autoridad y jerarquía normativa

La jerarquía inicial es:

1. The Nebula Constitution™;
2. The Nebula Doctrine™;
3. documentos fundacionales vigentes;
4. The Nebula Governance Model™;
5. The Nebula Standards™;
6. estándares específicos;
7. RFC aprobados;
8. Architecture Decision Records y Scientific Review Records;
9. políticas y procedimientos;
10. implementaciones y documentación operativa.

Un instrumento inferior NO DEBE contradecir uno superior. Cuando exista ambigüedad, deberá preferirse la interpretación que preserve integridad científica, derechos, Interoperability y capacidad de revisión.

Los conflictos entre instrumentos del mismo nivel deberán resolverse mediante The Nebula RFC™ o el mecanismo de apelación establecido por The Nebula Governance Model™.

graph TD
    C[The Nebula Constitution™] --> D[The Nebula Doctrine™]
    D --> F[Foundational Documents]
    F --> G[The Nebula Governance Model™]
    G --> S[The Nebula Standards™]
    S --> SS[Specific Standards]
    SS --> R[Approved RFC]
    R --> A[Decision Records]
    A --> P[Policies and Procedures]
    P --> I[Implementations]

---

#5. Lenguaje normativo

Las palabras normativas deberán utilizarse únicamente cuando exista intención de establecer un requisito.

DEBE y DEBERÁ indican obligación. NO DEBE y NO DEBERÁ indican prohibición. DEBERÍA indica una recomendación fuerte cuya omisión requiere justificación. NO DEBERÍA indica una práctica desaconsejada. PUEDE indica una opción permitida.

Los autores NO DEBERÍAN utilizar varias palabras normativas para expresar la misma obligación dentro de una oración. Los requisitos deberán ser atómicos, verificables y libres de términos subjetivos como «adecuado», «rápido» o «seguro» sin criterios.

Un requisito deberá identificar, cuando sea necesario:

• sujeto responsable;
• acción o condición;
• objeto;
• contexto;
• excepción;
• método de verificación.

---

#6. Principios generales

#6.1 Consistencia antes que implementación

Las implementaciones pueden diferir, pero deberán conservar identidad, significado y requisitos.

#6.2 Interoperability desde el diseño

Todo activo deberá considerar identificadores, metadatos, semántica, versionado y exportación desde su concepción.

#6.3 Procedencia obligatoria

Todo activo oficial DEBE conservar información suficiente para reconstruir su origen, responsables, transformaciones y dependencias.

#6.4 Versionado explícito

Una modificación material DEBE producir una nueva versión. Un activo Stable NO DEBE alterarse silenciosamente.

#6.5 Semántica sobre formato

Los formatos pueden cambiar. El significado, las relaciones y la procedencia deberán preservarse.

#6.6 Evidence vinculada

Las afirmaciones científicas o técnicas materiales DEBEN relacionarse con Evidence, fuente, experimento, Scientific Model o Decision Record.

#6.7 Compatibilidad proporcional

Todo cambio incompatible DEBE incluir justificación, impacto y estrategia de migración.

#6.8 Conformidad verificable

Todo estándar específico DEBE definir pruebas, criterios o procedimientos de evaluación.

#6.9 Seguridad y privacidad por diseño

Las implicaciones de seguridad, privacidad y derechos deberán evaluarse antes de publicar un activo o interfaz.

#6.10 Preservación interpretativa

Preservar bytes no es suficiente. Los activos deberán conservar información que permita a comunidades futuras comprenderlos.

---

#7. Modelo común de activo

Todo activo oficial deberá poder representarse conceptualmente como:

$$\mathcal{A} = \langle I,T,V,S,P,R,G,C \rangle.$$

I es identidad; T, tipo; V, versión; S, semántica; P, procedencia; R, relaciones; G, Governance; C, conformidad.

#7.1 Identity

Incluye identificador institucional, identificadores externos y autoridad de emisión.

#7.2 Type

Declara la familia del activo y determina requisitos aplicables.

#7.3 Version

Identifica el estado del contenido y su relación con versiones anteriores.

#7.4 Semantics

Declara significado, Ontology, unidades, schemas y términos.

#7.5 Provenance

Conserva autores, agentes, actividades, fuentes y transformaciones.

#7.6 Relations

Conecta dependencias, antecedentes, sustitutos, Evidence y productos derivados.

#7.7 Governance

Declara owner, steward, derechos, acceso, revisión y estado.

#7.8 Conformance

Declara estándar aplicable, perfil, resultado de pruebas y excepciones.

classDiagram
    class NebulaAsset {
        +institutionalId
        +assetType
        +version
        +status
    }

    class Identity {
        +issuer
        +externalIds
    }

    class Semantics {
        +ontologyVersion
        +schema
        +units
    }

    class Provenance {
        +agents
        +activities
        +sources
    }

    class Governance {
        +owner
        +steward
        +rights
    }

    class Conformance {
        +profile
        +result
        +exceptions
    }

    NebulaAsset "1" *-- "1" Identity
    NebulaAsset "1" *-- "1" Semantics
    NebulaAsset "1" *-- "1" Provenance
    NebulaAsset "1" *-- "1" Governance
    NebulaAsset "1" *-- "1" Conformance

---

#8. Identificadores institucionales

Todo activo oficial DEBE poseer un identificador único, persistente y no reutilizable.

El formato general es:

NBL-<TIPO>-<NÚMERO>

El prefijo NBL identifica al ecosistema. El tipo DEBE pertenecer al registro oficial. El número DEBE ser único dentro de su familia.

El identificador NO DEBE cambiar por traslado, renombrado de archivo, cambio de dominio, traducción o migración tecnológica. Una traducción conservará el identificador fuente y declarará idioma y estado de traducción.

La asignación de nuevos prefijos DEBE realizarse mediante RFC o delegación documentada del Standards Council.

---

#9. Nomenclatura, slugs y archivos

Los títulos oficiales DEBEN conservar marcas, mayúsculas y nombres institucionales aprobados.

Los slugs deberán utilizar minúsculas, caracteres ASCII, palabras separadas por guiones y no incluir versión. Una modificación del título no debería cambiar el slug sin necesidad, porque el slug puede funcionar como identificador de navegación.

El nombre recomendado para documentos es:

<ID> - <Título corto>.md

Los sistemas pueden utilizar nombres distintos internamente, pero NO DEBEN presentar el nombre del archivo como identidad canónica.

Los nombres de clases, propiedades, eventos, APIs y variables deberán seguir la convención del estándar específico. La conversión entre estilos —por ejemplo, camelCase, PascalCase o snake_case— deberá ser determinista y documentada cuando exista intercambio.

---

#10. Metadatos y YAML Frontmatter

Todo documento Markdown oficial DEBE incluir YAML Frontmatter válido en UTF-8.

Los campos obligatorios son:

• authors;
• canonicalLanguage;
• category;
• createdAt;
• description;
• documentType;
• effectiveAt;
• id;
• keywords;
• language;
• license;
• relatedDocuments;
• shortTitle;
• slug;
• status;
• title;
• translationStatus;
• updatedAt;
• version.

La ausencia de relaciones deberá expresarse mediante una lista vacía cuando el schema lo requiera, no mediante omisión ambigua.

Las fechas de calendario usarán YYYY-MM-DD. Los timestamps usarán una representación ISO 8601 con offset o Z. Los sistemas NO DEBERÍAN almacenar tiempos locales sin zona cuando el orden o la auditoría dependan de ellos.

La versión publicada ISO 8601-1:2019, con su enmienda de 2022, continúa siendo la referencia vigente durante la fecha efectiva de este estándar, aunque una segunda edición se encuentra en desarrollo. Un futuro perfil Nebula deberá evaluar la nueva edición antes de adoptarla.

El description deberá describir función y alcance, evitando lenguaje promocional. keywords deberá utilizar términos suficientes para descubrimiento sin convertirse en una lista exhaustiva.

---

#11. Estados editoriales y ciclo de vida

Los estados oficiales iniciales son:

Un cambio de estado DEBE registrar fecha, autoridad y fundamento.

Deprecated NO significa eliminado. Superseded requiere identificar el sustituto. Withdrawn requiere describir el riesgo de uso. Archived no autoriza nuevos usos operacionales salvo excepción.

stateDiagram
    [*] --> Draft
    Draft --> Review
    Review --> Candidate
    Review --> Draft
    Candidate --> Experimental
    Candidate --> Stable
    Experimental --> Candidate
    Stable --> Challenged
    Challenged --> Stable
    Challenged --> Withdrawn
    Stable --> Deprecated
    Deprecated --> Superseded
    Superseded --> Archived
    Withdrawn --> Archived
    Archived --> [*]

---

#12. Versionado y compatibilidad

Nebula adopta MAJOR.MINOR.PATCH como convención general.

Una versión MAJOR cambia cuando el contrato público o significado se modifica de forma incompatible. MINOR cambia cuando se añade capacidad compatible. PATCH cambia cuando se corrige un defecto sin modificar el contrato o significado esperado.

La convención se inspira en Semantic Versioning 2.0.0, pero se extiende a documentos, datasets, Ontology y Scientific Models. Cada familia deberá definir qué constituye su «contrato público».

Un documento normativo incrementará MAJOR cuando cambien requisitos de forma incompatible; MINOR, cuando añada requisitos o clarificaciones compatibles; PATCH, cuando corrija erratas sin alterar obligaciones.

Un dataset incrementará versión cuando cambien registros, transformaciones, schema, criterios de inclusión o interpretación. Un cambio de checksum con la misma versión publicada constituye una violación, salvo que se trate de una representación expresamente versionada por separado.

Una Ontology incrementará versión semántica cuando cambien axiomas, definiciones o relaciones con consecuencias de Inference. Una nueva serialización equivalente podrá conservar versión conceptual y declarar versión de distribución.

Un Scientific Model reentrenado, recalibrado o modificado DEBE recibir nueva versión. El uso de nuevos datos puede cambiar el comportamiento aunque la arquitectura permanezca.

Todo activo Stable DEBE conservar un changelog. Los cambios incompatibles DEBEN incluir:

• impacto;
• población de activos afectados;
• método de detección;
• migración;
• periodo de transición;
• rollback;
• fecha de retiro.

---

#13. Estructura y estilo documental

Todo documento normativo debería incluir:

1. YAML Frontmatter;
2. título;
3. tabla de identificación;
4. convenciones;
5. resumen ejecutivo;
6. propósito;
7. alcance;
8. definiciones;
9. requisitos;
10. conformidad;
11. seguridad y privacidad;
12. Governance;
13. relación con el Framework;
14. limitaciones;
15. referencias;
16. declaración institucional.

Los documentos científicos pueden reorganizarse para favorecer narrativa, pero deberán conservar identidad, alcance, clasificación de afirmaciones, Evidence, limitaciones y referencias.

Los documentos DEBEN utilizar Markdown limpio y portable. Deberá existir un único título #. No se deberán saltar niveles de encabezado sin razón. Los bloques de código deberán indicar lenguaje. Las tablas se reservarán para información estructurada o comparativa.

Los diagramas Mermaid permitidos son flowchart, graph, mindmap, sequenceDiagram, classDiagram, stateDiagram, erDiagram, journey, timeline y architecture-beta. Todo diagrama DEBE renderizarse, usar terminología oficial y mantenerse sincronizado con el texto.

Los documentos NO DEBEN depender de HTML propietario para transmitir contenido esencial. Las extensiones podrán utilizarse cuando exista una representación alternativa portable.

---

#14. Terminología oficial y multilingüismo

Los nombres institucionales DEBEN conservarse sin modificación:

• Computational Bioeconomy™;
• Digital Terroir®;
• Living Knowledge Infrastructure™;
• Proof of Process™;
• Originblok®;
• FermentOps®;
• RoastOps®;
• TraceOps®;
• The Nebula Framework™;
• The Nebula Ontology™;
• The Nebula Library™;
• The Nebula RFC™;
• The Nebula Standards™.

Una traducción puede explicar un término, pero NO DEBE sustituir su nombre oficial en identificadores, títulos registrados o claims institucionales.

El idioma canónico inicial es es-419. Las traducciones deberán declarar su relación con el documento fuente y su estado. Una traducción no deberá introducir requisitos nuevos. Cuando exista ambigüedad, prevalecerá la versión canónica, salvo que Governance apruebe un régimen multicanónico futuro.

Las etiquetas de Ontology podrán utilizar language tags. Los términos sin equivalencia exacta deberán conservar una nota terminológica en lugar de forzar correspondencia.

---

#15. Estándares semánticos

Toda representación semántica oficial DEBE mantener coherencia con The Nebula Ontology™ y declarar la versión utilizada.

Las clases deberán representar conceptos definidos, poseer identificador persistente, definición, superclase cuando corresponda, ejemplos y estado. Las relaciones deberán declarar dirección, dominio, rango, significado, restricciones y consecuencias de Inference. Las propiedades cuantitativas deberán declarar tipo de dato, unidad, cardinalidad y obligatoriedad.

Las serializaciones podrán utilizar RDF, OWL, JSON-LD, Turtle y otros formatos aprobados. La selección de un formato NO DEBE modificar el significado.

PROV-O deberá considerarse para procedencia de Entity, Activity y Agent. DCAT 3 deberá considerarse para catalogación de datasets y servicios, incluyendo versiones, distributions y dataset series. SHACL 2017 podrá utilizarse para validar grafos RDF.

Las nuevas capacidades de SHACL 1.2 publicadas como Working Draft en 2026 se clasificarán como experimentales hasta que Governance apruebe una versión estable o exista Evidence suficiente de implementación.

Una forma SHACL satisfecha demuestra conformidad con restricciones declaradas, no verdad científica. Un razonador OWL puede descubrir consecuencias lógicas, pero no determina si los axiomas representan adecuadamente el mundo.

---

#16. Observations, Evidence y Scientific Claims

#16.1 Observation

Toda Observation oficial DEBE incluir, cuando sea aplicable:

• identificador;
• entidad observada;
• propiedad;
• resultado;
• unidad;
• timestamp;
• procedimiento;
• instrumento u observador;
• ubicación;
• contexto;
• calidad;
• incertidumbre;
• procedencia;
• relación con el Biological Process.

Una Observation sin contexto suficiente NO DEBERÍA clasificarse como Evidence consolidada.

#16.2 Evidence

Todo Evidence Artifact DEBE conservar identidad, fuente, método, integridad, contexto, responsable y estado de validación.

La función probatoria deberá representarse mediante una relación con un Knowledge Claim, Hypothesis, Inference o decisión. Un mismo artefacto puede respaldar un claim y ser irrelevante para otro.

Hashes, firmas y sellado temporal PUEDE fortalecer integridad. NO demuestra por sí mismo exactitud, representatividad o causalidad.

#16.3 Claims

Un Knowledge Claim material DEBE declarar:

• enunciado;
• alcance;
• tipo epistemológico;
• Evidence favorable;
• Evidence adversa conocida;
• incertidumbre;
• estado;
• versión;
• Context of Use.

Los resultados preliminares NO DEBEN presentarse como conocimiento consolidado sin indicar su estado.

---

#17. Datasets y transformaciones

Todo dataset oficial DEBE incluir:

• identificador;
• título y descripción;
• dominio;
• procedencia;
• periodo de captura;
• población o unidades de observación;
• variables y unidades;
• frecuencia y resolución;
• schema;
• calidad;
• valores faltantes;
• criterios de inclusión y exclusión;
• transformaciones;
• licencia y restricciones;
• versión;
• checksum;
• responsable.

Los datos derivados DEBEN conservar vínculo con sus fuentes y con el código o procedimiento que realizó la transformación.

La imputación, interpolación, normalización, exclusión y corrección NO DEBEN ejecutarse de forma invisible. Cada transformación deberá producir un artefacto derivado o un registro reproducible.

Los datasets deberían alinearse con FAIR en la medida compatible con derechos, privacidad y capacidad. FAIR no equivale a Open. Un dataset restringido puede ser Findable, Interoperable y Reusable bajo condiciones explícitas.

The Nebula Library™ debería utilizar un perfil de DCAT 3 para describir datasets, distributions, services, versiones y series.

---

#18. Experimentos

Todo experimento oficial DEBE documentar pregunta, Hypothesis, metodología, variables, controles, instrumentos, condiciones, muestra, criterios de inclusión y exclusión, análisis, incertidumbre, limitaciones, responsables y Evidence generada.

El protocolo debería registrarse antes de observar resultados cuando la naturaleza del estudio lo permita. Las desviaciones deberán conservarse.

Los resultados negativos, inconclusos y adversos DEBERÍAN preservarse porque forman parte de Living Knowledge Infrastructure™ y reducen repetición de errores.

La reproducibilidad no exige resultados biológicos idénticos. Exige información suficiente para reconstruir procedimiento, análisis y fuentes de variabilidad.

Un experimento con intervención material deberá incluir seguridad, ética, autoridad y criterios de parada.

---

#19. Scientific Models y Mathematics

Todo Scientific Model DEBE declarar propósito, variables, parámetros, ecuaciones o arquitectura, supuestos, dominio de validez, datos, unidades, incertidumbre, limitaciones, método de validación, versión y responsable.

Las ecuaciones deberán definir símbolos y unidades. Las variables observadas, latentes e inferidas deberán diferenciarse.

Una simulación DEBE declarar condiciones iniciales, solver, tolerancias, código, entorno y versión cuando estos elementos puedan afectar el resultado.

Los modelos deberán incluir condiciones de refutación o criterios de revisión. Una mejora de ajuste no demuestra mayor explicación causal.

The Nebula Mathematics™ proporciona el marco conceptual para estados, eventos, incertidumbre, identifiability y Biological Trajectory. Los estándares específicos deberán reutilizar esa notación o documentar mapeos.

---

#20. Modelos de inteligencia artificial

Todo modelo de IA oficial DEBE incluir una Model Card o registro equivalente con:

• propósito;
• Context of Use;
• arquitectura;
• datos de entrenamiento y evaluación;
• preprocesamiento;
• métricas;
• incertidumbre;
• subgrupos;
• sesgos y riesgos conocidos;
• dependencias;
• responsable;
• versión;
• criterios de monitoreo;
• rollback;
• retiro.

Una Inference producida por IA NO DEBE presentarse como Observation. Los sistemas generativos deberán clasificar sus salidas como contenido o Inference candidata hasta ser validadas.

Todo modelo reentrenado DEBE recibir nueva versión. Los cambios de pesos constituyen cambios materiales aunque el código permanezca.

Los modelos adaptativos deberán declarar qué cambios pueden ocurrir sin aprobación, cómo se limita el aprendizaje y cuándo se crea una nueva versión oficial.

Las decisiones de alto impacto no deberán delegarse a un modelo sin autoridad, supervisión, registro y posibilidad de intervención humana.

---

#21. APIs y schemas

Toda API oficial DEBE declarar identificador, versión, propósito, autenticación, autorización, contratos de entrada y salida, errores, límites, dependencias, política de compatibilidad, observabilidad y retiro.

Las APIs HTTP deberían utilizar una descripción OpenAPI compatible con la versión aprobada por el perfil Nebula. OpenAPI 3.2.0, publicada en septiembre de 2025, constituye la versión de referencia inicial para nuevos contratos; los servicios existentes en 3.1 pueden mantener conformidad mediante un perfil específico.

Los schemas JSON deberían utilizar JSON Schema Draft 2020-12 o una versión aprobada. El identificador del schema, vocabularios y comportamiento de format deberán declararse para evitar diferencias entre validadores.

Las interfaces públicas NO DEBEN cambiar incompatiblemente sin RFC, nueva versión y plan de migración.

La autenticación no sustituye autorización. Los contratos deberán declarar scopes, errores y comportamiento ante recursos inexistentes o restringidos.

---

#22. Eventos y mensajes

Todo evento oficial DEBE incluir:

• tipo;
• identificador;
• timestamp;
• productor;
• versión del schema;
• contexto;
• payload o referencia;
• integridad;
• correlación;
• causación cuando sea conocida;
• clasificación de sensibilidad.

Los nombres de eventos deberían utilizar pasado descriptivo: ObservationCaptured, EvidenceValidated, ModelPublished o RFCApproved.

Un evento declara que algo ocurrió; un comando solicita una acción. NO DEBEN intercambiarse.

CloudEvents 1.0.2 podrá utilizarse como envelope común. El uso de CloudEvents mejora portabilidad de metadatos, pero no define la semántica del dominio ni la evolución del payload.

Los consumidores deberán gestionar duplicados, reordenamiento y reintentos. La combinación de source e id deberá permitir idempotencia conforme al perfil elegido.

Los eventos sensibles NO DEBERÍAN incluir información secreta en atributos de contexto susceptibles de registro por intermediarios.

---

#23. Software y cadena de suministro

Todo software oficial debería declarar repositorio, licencia, versión, dependencias, build process, artefactos, hashes, responsable, vulnerabilidades conocidas y política de soporte.

Las releases críticas deberían ser reproducibles o verificables mediante mecanismos equivalentes.

Nebula podrá utilizar SPDX para Software Bill of Materials y metadatos de licencia y procedencia. SPDX es reconocido como ISO/IEC 5962:2021 y su especificación 3.0 constituye una evolución disponible para perfiles futuros.

Las dependencias deberán fijarse o limitarse de forma compatible con seguridad y mantenimiento. Una dependencia sin soporte deberá ingresar al registro de riesgo.

El código generado por IA NO queda exento de revisión, licencia, seguridad o pruebas.

---

#24. Seguridad

Todo estándar específico DEBE incluir Security Considerations proporcionales al dominio.

La evaluación deberá considerar autenticación, autorización, confidencialidad, integridad, disponibilidad, gestión de claves, auditoría, resiliencia, respuesta a incidentes, dependencias, manipulación de modelos y riesgos físicos.

Una especificación que no introduce riesgos nuevos deberá declararlo y justificarlo. La ausencia de una sección de seguridad no significa ausencia de riesgo.

Los secretos NO DEBEN incluirse en documentos, schemas, ejemplos, eventos o repositorios públicos.

La criptografía deberá utilizar algoritmos y parámetros aprobados por una política específica. Los estándares NO DEBEN inventar algoritmos criptográficos propietarios.

La integridad de un artefacto demuestra que no cambió respecto a una referencia; no demuestra que la referencia fuera correcta.

---

#25. Privacidad y conocimiento sensible

Los activos con datos personales, sensibles o territoriales DEBEN declarar finalidad, base jurídica o autorización, minimización, acceso, retención, anonimización o seudonimización, consentimiento cuando corresponda, eliminación y riesgo de reidentificación.

Los identificadores persistentes pueden aumentar correlación entre fuentes. Su diseño deberá equilibrar trazabilidad y privacidad.

Los datasets anonimizados deberán someterse a evaluación de reidentificación proporcional. Eliminar nombres no garantiza anonimato cuando existen coordenadas, fechas, lotes o trayectorias únicas.

Digital Terroir® puede contener conocimiento de Caficultores, ubicaciones y prácticas. La clasificación de acceso deberá respetar atribución, derechos y acuerdos de beneficio.

Las credenciales verificables deberán minimizar divulgación y permitir que el verifier evalúe issuer, proof, subject y claims. La verificabilidad de una credential NO implica verdad de sus claims.

---

#26. Propiedad intelectual y licencias

Todo activo oficial DEBE declarar licencia o régimen de uso.

Las categorías iniciales pueden incluir Proprietary, Confidential, Internal, Open, Research Use, Commercial License y Patent Pending.

La publicación de un Standard no libera automáticamente implementaciones, datasets, modelos, marcas ni algoritmos asociados.

Las contribuciones externas deberán declarar Background IP, licencia, autoría y derechos sobre derivados.

Los estándares específicos deberían procurar condiciones que permitan implementación independiente cuando Interoperability sea un objetivo. Las restricciones de propiedad intelectual que impidan conformidad o adopción deberán evaluarse mediante Governance.

La ausencia de licencia NO DEBE interpretarse como autorización de reutilización.

---

#27. Originblok® y Proof of Process™

Los perfiles de Originblok® y Proof of Process™ DEBEN cubrir identidad, Observations, eventos, sellado temporal, hashes, firmas, cadena de custodia, procedencia, verificabilidad, auditoría, retención y políticas de corrección.

Blockchain PUEDE utilizarse cuando el modelo de confianza, distribución de autoridad y costo lo justifiquen. NO DEBE considerarse un requisito constitucional ni confundirse con el propósito de la infraestructura.

Proof of Process™ deberá expresar qué claim se pretende respaldar, qué Evidence se incluye, qué Evidence queda fuera, qué verificaciones se realizaron y qué limitaciones subsisten.

Una cadena criptográficamente íntegra puede preservar registros falsos o mediciones defectuosas. La Trust Infrastructure deberá combinar integridad, identidad, Evidence, Semantic Infrastructure y Governance.

W3C Verifiable Credentials 2.0 puede utilizarse para expresar credenciales de procesos, roles o estados emitidos por autoridades. El perfil deberá definir issuer policies, revocation, validity, privacy y verifier rules.

---

#28. Conformidad

Un activo será conforme cuando satisfaga los requisitos generales y los estándares específicos aplicables.

Los niveles son:

• Conformidad completa: todos los requisitos aplicables se cumplen.
• Conformidad parcial: existen excepciones documentadas.
• Conformidad experimental: el activo se utiliza bajo un perfil de validación limitado.
• No conforme: incumplimientos materiales impiden reconocerlo como compatible.

La declaración de conformidad DEBE incluir:

• activo y versión;
• estándar y perfil;
• fecha;
• herramientas;
• resultados;
• excepciones;
• evaluador;
• vigencia.

La autoevaluación PUEDE utilizarse para activos de bajo riesgo. Los claims de certificación o alto impacto deberían requerir revisión independiente.

La conformidad con una versión NO implica conformidad con versiones futuras.

---

#29. Pruebas de conformidad

Los estándares específicos DEBEN incluir criterios verificables y deberían incluir pruebas automatizadas cuando sea posible.

Podrán emplearse:

• validación YAML;
• JSON Schema;
• SHACL;
• linting de Markdown;
• validadores de identificadores;
• pruebas de APIs;
• contract testing;
• checksums;
• pruebas de seguridad;
• pruebas de Interoperability;
• pruebas de migración;
• revisión humana.

Una suite deberá versionarse junto con el Standard. Un cambio de prueba que altere el resultado de conformidad puede requerir nueva versión del perfil.

Los resultados deberán ser reproducibles y conservar Evidence suficiente. Una herramienta propietaria no debería ser la única vía para demostrar conformidad.

---

#30. Excepciones

Una excepción temporal podrá aprobarse ante restricciones científicas, técnicas, operativas, territoriales o jurídicas.

Toda excepción DEBE declarar:

• requisito afectado;
• causa;
• alcance;
• riesgo;
• mitigación;
• responsable;
• fecha de inicio;
• expiración;
• plan de regularización;
• autoridad.

Una excepción sin fecha de revisión se considera deuda normativa.

Las excepciones repetidas pueden indicar que el Standard es inadecuado. Governance deberá evaluar si corresponde modificar la norma en lugar de renovar dispensas.

Una excepción NO DEBE utilizarse para ocultar no conformidad o evitar revisión.

---

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

Todo activo deprecado DEBE conservarse, indicar motivo, identificar sustituto cuando exista, definir periodo de transición y documentar impacto.

Un activo retirado NO DEBE eliminarse si forma parte de trazabilidad, decisiones, Evidence o reproducción histórica.

Los consumidores deberán recibir notificación proporcional antes de una retirada programada. Las APIs deberán publicar fechas y alternativas.

Una vulnerabilidad crítica puede justificar retirada inmediata. La decisión deberá conservarse y revisarse posteriormente.

Los identifiers retirados NO DEBEN reutilizarse.

---

#32. Proceso de creación de Standards

Todo Standard específico deberá seguir un ciclo gobernado.

flowchart TD
    A[Problema identificado] --> B[The Nebula RFC™]
    B --> C[Clasificación y alcance]
    C --> D[Revisión científica, técnica y territorial]
    D --> E[Draft Standard]
    E --> F[Implementación o prototipo]
    F --> G[Pruebas de conformidad]
    G --> H[Candidate]
    H --> I{Evidence suficiente}
    I -->|No| E
    I -->|Sí| J[Stable]
    J --> K[Mantenimiento]
    K --> L[Revisión, sustitución o retiro]

El ciclo comprende:

1. identificación del problema;
2. RFC;
3. definición de stakeholders y alcance;
4. revisión;
5. implementación o prueba;
6. criterios de conformidad;
7. resolución de objeciones;
8. aprobación;
9. publicación;
10. registro en The Nebula Library™;
11. mantenimiento.

El estado Stable debería requerir, cuando sea viable, al menos dos implementaciones o validaciones independientes para interfaces de Interoperability. Cuando no sea posible, la limitación deberá declararse.

---

#33. Registro en The Nebula Library™

Todo Standard Stable DEBE registrarse en The Nebula Library™.

El registro incluirá documento, versión, estado, RFC de origen, responsables, dependencias, implementaciones, pruebas, historial, activos relacionados, licencia y checksum.

The Nebula Library™ deberá preservar versiones anteriores y permitir resolver relaciones de sustitución.

Los catálogos deberían utilizar DCAT 3 mediante un Application Profile Nebula. El catálogo no reemplaza el repositorio ni la preservación de artefactos.

Los activos externos podrán registrarse mediante referencia cuando exista estabilidad y derecho de acceso suficientes.

---

#34. Governance de Standards

La administración corresponde a los órganos definidos por The Nebula Governance Model™.

Los roles iniciales son:

• Standard Owner;
• Editor;
• Domain Steward;
• Reviewer;
• Conformance Lead;
• Security Reviewer;
• Privacy Reviewer;
• Territorial Reviewer;
• Library Steward.

El Standard Owner responde por propósito y ciclo de vida. El Editor mantiene coherencia textual. El Domain Steward administra términos y requisitos del dominio. El Conformance Lead desarrolla pruebas. Los reviewers evalúan perspectivas específicas.

Los conflictos de interés DEBEN declararse. Los cambios materiales deberán preservar comentarios, objeciones, respuesta y Decision Record.

---

#35. Revisión periódica y métricas

Todo Standard Stable DEBERÍA revisarse periódicamente o ante eventos gatillo.

La revisión evaluará:

• vigencia;
• adopción;
• claridad;
• incidentes;
• seguridad;
• privacidad;
• Interoperability;
• costo de conformidad;
• excepciones;
• evolución tecnológica;
• necesidad de deprecación.

Las métricas pueden incluir activos conformes, defectos detectados, tiempo de migración, implementaciones independientes, excepciones y adopción.

El número de páginas, requisitos o reuniones NO demuestra calidad.

Una baja adopción puede indicar falta de necesidad, mala documentación, costo excesivo o ausencia de herramientas. La respuesta no deberá consistir automáticamente en imponer cumplimiento.

---

#36. Compatibilidad internacional

Nebula procurará interoperar con Standards internacionales cuando aporten significado, adopción, seguridad o portabilidad.

Las referencias iniciales incluyen ISO, IEC, IEEE, IETF, W3C, OGC, GS1, FAIR, RDF, OWL, JSON-LD, PROV-O, DCAT, SHACL, OpenAPI, CloudEvents, SPDX y Verifiable Credentials.

La compatibilidad NO implica subordinación conceptual. Nebula podrá definir extensiones cuando los estándares existentes no representen adecuadamente Biological Trajectory, Digital Terroir®, Evidence o Proof of Process™.

Toda extensión deberá:

• declarar el estándar base;
• identificar diferencias;
• evitar redefinir términos;
• definir mapeo;
• proporcionar ejemplos;
• probar round-trip cuando corresponda.

Las referencias normativas deberán fijar versión. Las referencias informativas podrán apuntar a una familia o versión vigente.

---

#37. Agenda de Standards específicos

La primera generación debería incluir:

• NBL-STD-DOC — Documentación;
• NBL-STD-ID — Identificadores;
• NBL-STD-META — Metadatos;
• NBL-STD-OBS — Observations;
• NBL-STD-EVD — Evidence;
• NBL-STD-DS — Datasets;
• NBL-STD-EXP — Experimentos;
• NBL-STD-MDL — Scientific Models;
• NBL-STD-AI — Modelos de IA;
• NBL-STD-ONT — Ontology;
• NBL-STD-API — APIs;
• NBL-STD-EVT — Eventos;
• NBL-STD-SEC — Seguridad;
• NBL-STD-PRV — Privacidad;
• NBL-STD-POP — Proof of Process™;
• NBL-STD-LIB — The Nebula Library™;
• NBL-STD-CONF — Conformidad.

La enumeración constituye agenda, no asignación definitiva de identificadores. La creación deberá seguir The Nebula RFC™.

---

#38. Integridad documental

Un documento .md oficial se considerará estructuralmente íntegro cuando:

• el YAML Frontmatter pueda analizarse;
• los campos obligatorios estén presentes;
• id, version y status coincidan entre YAML y cuerpo;
• exista un único título principal;
• los bloques de código estén cerrados;
• los diagramas Mermaid estén delimitados;
• no existan secciones truncadas;
• finalice con la declaración institucional;
• pueda leerse como UTF-8;
• pueda calcularse un checksum.

La integridad estructural NO demuestra que las referencias sean correctas, que el texto sea científicamente válido o que se haya seguido debido proceso.

Todo documento Stable debería superar validación automatizada y revisión editorial humana.

---

#39. Validación y condiciones de refutación

The Nebula Standards™ deberá validarse mediante uso real.

La validación incluirá:

• creación de activos por equipos independientes;
• intercambio sin acuerdos secretos;
• pruebas de migración;
• reconstrucción de procedencia;
• detección de incumplimientos;
• revisión de incidentes;
• evaluación de costo.

El Standard deberá revisarse si:

1. sus requisitos no pueden verificarse;
2. equipos competentes interpretan obligaciones de forma incompatible;
3. la carga de metadatos supera persistentemente el valor;
4. los activos formalmente conformes continúan perdiendo significado;
5. la versioning policy no permite reconstruir historia;
6. las extensiones internacionales generan equivalencias falsas;
7. las excepciones se vuelven permanentes;
8. la conformidad depende de una única herramienta;
9. la norma impide innovación científicamente legítima;
10. los actores territoriales quedan excluidos por complejidad o costo.

La refutación de un requisito no invalida necesariamente el estándar completo. La Governance deberá permitir corrección modular.

---

#40. Limitaciones

La primera limitación es representacional. Ningún Standard anticipa todos los dominios.

La segunda es institucional. Las reglas no garantizan cultura de integridad.

La tercera es económica. La conformidad requiere tiempo, herramientas y especialistas.

La cuarta es semántica. Las definiciones pueden contener errores.

La quinta es tecnológica. Los formatos y herramientas evolucionan.

La sexta es científica. La conformidad no demuestra verdad.

La séptima es territorial. Las convenciones pueden reflejar prácticas institucionales y no representar adecuadamente conocimiento local.

La octava es jurídica. Las obligaciones varían entre jurisdicciones.

La novena es de seguridad. Publicar especificaciones puede revelar superficies de ataque si no se gestiona responsablemente.

La décima es de adopción. Un Standard técnicamente sólido puede fracasar sin comunidad, implementaciones y soporte.

La undécima es temporal. Una referencia internacional puede cambiar de estado después de la publicación.

La duodécima es de Governance. Una autoridad puede utilizar la standardization para concentrar poder.

---

#41. Relación con The Nebula Framework™

The Nebula Standards™ operacionaliza los principios definidos por:

• La Tesis Nebula™;
• La Visión Nebula™;
• The Nebula Doctrine™;
• The Nebula Constitution™;
• Modelo Científico Nebula™;
• The Nebula Epistemology™;
• The Nebula Mathematics™;
• The Nebula Ontology™;
• La Arquitectura Nebula™;
• The Nebula Knowledge Model™;
• The Nebula Governance Model™;
• The Nebula Economic Model™.

Proporciona la base normativa para The Nebula RFC™, The Nebula Library™, Digital Terroir®, Originblok®, FermentOps®, RoastOps®, TraceOps® y productos futuros.

The Nebula Governance Model™ determina quién aprueba y revisa. The Nebula Standards™ determina qué requisitos debe satisfacer un activo. The Nebula RFC™ determina cómo se propone el cambio. The Nebula Library™ preserva y publica el resultado.

---

#42. Evolución

The Nebula Standards™ evolucionará mediante The Nebula RFC™.

Toda modificación DEBE:

• justificar el cambio;
• identificar impacto;
• preservar historial;
• declarar compatibilidad;
• definir migración;
• actualizar pruebas;
• registrar objeciones;
• publicarse en The Nebula Library™.

La versión anterior permanecerá resoluble.

Una revisión de referencias externas deberá distinguir entre actualización editorial y adopción normativa de una nueva versión. La existencia de una edición nueva no obliga automáticamente a migrar.

---

#Conclusiones

The Nebula Standards™ establece la infraestructura normativa mediante la cual The Nebula Framework™ puede evolucionar sin perder identidad, significado, Evidence, Interoperability ni memoria institucional.

Su contribución principal es transformar principios abstractos en condiciones verificables. Todo activo oficial deberá poseer identidad, versión, semántica, procedencia, relaciones, Governance y estado de conformidad.

El estándar distingue especificación e implementación. Las tecnologías podrán cambiar y las implementaciones podrán competir, pero ninguna deberá redefinir silenciosamente el contrato común.

La norma también distingue integridad, conformidad y verdad. Un hash demuestra correspondencia con un valor; un schema demuestra estructura; una firma demuestra control de una clave bajo determinados supuestos; una revisión científica evalúa Evidence. Ninguna capa sustituye a las demás.

Observation, Evidence e Inference deberán permanecer separadas. Esta distinción protege el Knowledge Model frente a la falsa certeza y permite que Living Knowledge Infrastructure™ preserve contradicciones y correcciones.

La versión forma parte del significado. Un activo Stable no deberá modificarse en silencio. La preservación de versiones históricas permite reconstruir decisiones y reproducir análisis.

Interoperability no será una característica añadida al final. Deberá diseñarse mediante identificadores, metadatos, Ontology, schemas, contratos y pruebas. Los Standards internacionales deberán reutilizarse con precisión, evitando dependencias innecesarias y equivalencias falsas.

La conformidad deberá ser graduada, verificable y proporcional. Las excepciones serán temporales y visibles. Las pruebas automatizadas deberán complementarse con revisión humana.

La standardization será legítima cuando facilite ciencia, ingeniería y cooperación; no cuando produzca burocracia autosuficiente. El costo de cada requisito deberá justificarse por el riesgo que reduce o el valor que habilita.

El éxito de The Nebula Standards™ no se medirá por el número de normas derivadas.

Se medirá por la capacidad de permitir que una Observation capturada hoy continúe siendo interpretable, verificable y reutilizable cuando hayan cambiado los dispositivos, las personas, los modelos y las tecnologías que la rodean.

---

#Glosario

#Activo

Objeto científico, semántico, tecnológico, documental, organizacional o probatorio reconocido por el ecosistema.

#Conformidad

Grado en que un activo satisface requisitos aplicables.

#Data Contract

Contrato versionado que define estructura, semántica, calidad y reglas de intercambio.

#Evidence

Objeto o relación que respalda, contradice o deja indeterminada una afirmación.

#Implementation

Realización técnica total o parcial de una especificación.

#Inference

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

#Interoperability

Capacidad de intercambiar y utilizar información preservando estructura, significado, procedencia y Governance.

#Knowledge Claim

Afirmación identificable con Evidence, alcance, incertidumbre, versión y estado.

#Normative Reference

Referencia indispensable para cumplir un requisito.

#Observation

Resultado contextualizado de un acto de medición, muestreo, inspección o percepción.

#Profile

Selección, restricción o combinación de requisitos para un Context of Use.

#Provenance

Información sobre entidades, actividades y agentes involucrados en producir o transformar un activo.

#Semantic Infrastructure

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

#Standard

Documento aprobado que establece requisitos, convenciones o criterios comunes.

#Specification

Descripción de requisitos, interfaces o comportamientos esperados.

#Temporal Evolution

Cambio documentado de activos, modelos, Standards o conocimiento a través del tiempo.

#Trust Infrastructure

Mecanismos científicos, semánticos, técnicos y de Governance utilizados para evaluar identidad, integridad, procedencia y credibilidad.

---

#Bibliografía recomendada

1. Bradner, S. RFC 2119 — Key Words for Use in RFCs to Indicate Requirement Levels. IETF, 1997.

2. Leiba, B. RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. BCP 14, IETF, 2017.

3. Bradner, S. RFC 2026 — The Internet Standards Process — Revision 3. BCP 9, IETF, 1996, con actualizaciones posteriores.

4. Resnick, P. RFC 7282 — On Consensus and Humming in the IETF. IETF, 2014.

5. World Wide Web Consortium. W3C Process Document. Edición efectiva de 18 de agosto de 2025.

6. ISO e IEC. ISO/IEC Directives, Part 1 — Procedures for the Technical Work. Edición vigente.

7. ISO e IEC. ISO/IEC Directives, Part 2 — Principles and Rules for the Structure and Drafting of ISO and IEC Documents. Edición vigente con enmienda 2026.

8. International Organization for Standardization. ISO 8601-1:2019 — Date and Time — Representations for Information Interchange — Part 1: Basic Rules, con Amendment 1:2022.

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

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

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

12. World Wide Web Consortium. Verifiable Credentials Data Model v2.0. W3C Recommendation, 2025.

13. Wilkinson, M. D. et al. “The FAIR Guiding Principles for Scientific Data Management and Stewardship.” Scientific Data, 2016.

14. JSON Schema Project. JSON Schema Draft 2020-12. 2022.

15. OpenAPI Initiative. OpenAPI Specification v3.2.0. 2025.

16. Cloud Native Computing Foundation. CloudEvents Specification v1.0.2. 2022.

17. Semantic Versioning. Semantic Versioning 2.0.0.

18. SPDX Project. SPDX Specification 3.0; ISO/IEC 5962:2021.

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

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

---

#Anexo A — Plantilla mínima de YAML

---
authors:
  - Cafelium SRL
  - Cafelium Foundation
canonicalLanguage: es-419
category: <category>
createdAt: YYYY-MM-DD
description: <description>
documentType: <documentType>
effectiveAt: YYYY-MM-DD
id: NBL-<TYPE>-<NUMBER>
keywords:
  - <keyword>
language: es-419
license: Proprietary
relatedDocuments: []
shortTitle: <shortTitle>
slug: <slug>
status: draft
title: <title>
translationStatus: source
updatedAt: YYYY-MM-DD
version: 0.1.0
---

---

#Anexo B — Registro mínimo de activo

---

#Anexo C — Declaración mínima de conformidad

assetId: NBL-<TYPE>-<NUMBER>
assetVersion: 1.0.0
standardId: NBL-STD-001
standardVersion: 1.0.0
profile: root
result: conformant
evaluatedAt: YYYY-MM-DDTHH:MM:SSZ
evaluator: <identifier>
tools:
  - name: <tool>
    version: <version>
exceptions: []
evidence:
  - <reference>

---

#Anexo D — Canon normativo

La identidad institucional no depende de la ubicación del archivo.

Un activo Stable NO DEBE modificarse silenciosamente.

La semántica prevalece sobre el formato.

Observation, Evidence e Inference no son categorías intercambiables.

La integridad criptográfica no demuestra verdad científica.

La conformidad estructural no sustituye validación científica.

Todo cambio incompatible requiere migración y preservación histórica.

Interoperability deberá diseñarse, probarse y mantenerse.

Las excepciones serán explícitas, temporales y gobernadas.

Los Standards deberán habilitar evolución, no inmovilizarla.

---

#Anexo E — Declaración institucional

The Nebula Standards™ constituye la referencia normativa oficial de The Nebula Framework™.

Su función es asegurar que toda evolución científica, tecnológica, semántica, documental y organizacional ocurra sobre una base consistente, interoperable, verificable, trazable y revisable.

Las tecnologías podrán cambiar, las implementaciones podrán diferir y los Scientific Models podrán evolucionar. Sin embargo, todo activo oficial deberá conservar identidad, contexto, procedencia, versión, relaciones, derechos y criterios de conformidad.

Toda especificación, producto, dataset, Scientific Model, API, Ontology, experimento o documento que se declare oficialmente compatible con The Nebula Framework™ deberá mantener coherencia con esta norma y con los estándares específicos aplicables.

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

The Nebula Framework™