#The Nebula Governance Model™

#The Nebula Framework™ — Scientific Edition v1.0

La identidad institucional, el propósito de Governance y las relaciones documentales de esta edición corresponden al registro oficial NBL-FWK-011.

---

#Convenciones normativas y epistemológicas

The Nebula Governance Model™ define el sistema mediante el cual The Nebula Framework™ adopta decisiones, asigna autoridad, administra riesgos, resuelve objeciones y dirige la Temporal Evolution de sus documentos, Scientific Models, Knowledge Model, Ontology, Architecture, Standards y servicios operacionales.

En este documento, Governance designa el sistema humano e institucional mediante el cual se orienta, supervisa y responsabiliza al ecosistema. Management designa la planificación, ejecución y control cotidiano dentro de los límites establecidos por Governance. La Governance decide propósitos, principios, derechos, tolerancias y autoridades; Management organiza recursos y acciones para cumplirlos. La separación no implica aislamiento: una misma persona puede participar en ambos ámbitos, pero no deberá confundir la autoridad de gobernar con la responsabilidad de ejecutar.

Una decisión es un acto institucional identificable que selecciona, autoriza, restringe o retira una alternativa. Una Decision Record es la representación trazable de ese acto. Evidence designa los objetos y relaciones que respaldan o cuestionan una decisión. Consensus designa una condición de apoyo suficiente en la que las objeciones legítimas han sido consideradas y no subsiste una objeción sostenida capaz de demostrar un riesgo material no tratado. Consensus no equivale a unanimidad, silencio ni mayoría simple.

Las expresiones DEBE, DEBERÁ y NO DEBE identifican requisitos de conformidad. DEBERÍA identifica una práctica recomendada cuya excepción exige justificación. PUEDE identifica una alternativa permitida. Esta convención se inspira en la tradición de especificaciones del IETF, donde los términos normativos deben interpretarse solo cuando aparecen de forma explícitamente normativa. ^[12]

La condición Stable identifica esta edición como referencia vigente. No significa que las decisiones producidas bajo el modelo sean infalibles ni que su estructura institucional no pueda reformarse conforme a The Nebula Constitution™.

---

#Prólogo

Toda infraestructura de conocimiento necesita Governance porque el conocimiento no evoluciona por acumulación automática. Evoluciona mediante decisiones: qué observar, qué preservar, qué publicar, qué modelo aprobar, qué riesgo aceptar, qué estándar adoptar y qué afirmación retirar.

Estas decisiones distribuyen autoridad y consecuencias. La selección de una variable determina qué parte del proceso se vuelve visible. La definición de una Ontology influye sobre qué entidades pueden representarse. La aprobación de un Scientific Model puede modificar intervenciones materiales. La política de acceso puede proteger conocimiento territorial o convertirlo en un recurso extraído sin participación legítima.

La ausencia de Governance explícita no elimina el poder. Lo desplaza hacia quienes controlan repositorios, credenciales, código, presupuesto o conocimiento especializado. Las decisiones continúan ocurriendo, pero sus criterios, responsables y mecanismos de impugnación permanecen ocultos.

The Nebula Governance Model™ existe para impedir que la evolución científica y tecnológica dependa exclusivamente de autoridad informal, urgencia operativa o preferencia del implementador.

Su propósito no consiste en burocratizar la investigación. Un sistema de Governance excesivamente pesado puede retrasar experimentos, desalentar contribuciones y convertir cada modificación en un procedimiento desproporcionado. El desafío es construir proporcionalidad: decisiones reversibles y de bajo impacto deben avanzar con rapidez; decisiones constitucionales, científicas o de alto riesgo requieren Evidence, revisión y registro más rigurosos.

La Governance también debe proteger la posibilidad de estar equivocados. Una institución científicamente madura no es aquella que evita toda contradicción, sino aquella que puede detectar, documentar y corregir sus errores sin destruir la memoria de cómo se produjeron.

The Nebula Framework™ se desarrolla en la intersección de investigación, ingeniería, bioeconomía, inteligencia artificial y territorios productivos. Esa posición impide adoptar sin adaptación un único modelo de gobierno corporativo, académico o comunitario. La Governance debe integrar responsabilidad organizacional, revisión científica, standardization, Architecture Governance, conocimiento local y derechos sobre información.

ISO 37000:2021 proporciona principios y aspectos de prácticas para orientar a órganos de gobierno y grupos responsables de que las organizaciones cumplan su propósito. ISO/IEC 38500:2024 aplica principios de Governance al uso actual y futuro de tecnologías de información. Estas referencias sustentan la separación entre dirección institucional y administración técnica, pero no determinan la estructura específica de Nebula. ^{[1, 2]}

La tradición de standardization aporta otra lección. El IETF desarrolla especificaciones mediante revisión pública, madurez, experiencia operacional y resolución de conflictos; el W3C combina consenso, participación, implementación, Formal Objections y mecanismos de apelación. Estos procesos muestran que la calidad de un estándar depende tanto de su contenido como de la legitimidad y trazabilidad de su desarrollo. ^{[10, 13]}

Nebula adopta esa orientación sin copiar mecánicamente sus órganos. El ecosistema posee una escala, misión y composición diferentes. Su Governance deberá ser suficientemente formal para proteger la integridad científica y suficientemente ligera para permitir experimentación.

---

#Resumen Ejecutivo

The Nebula Governance Model™ establece el mecanismo oficial para dirigir la evolución de The Nebula Framework™, su conocimiento, Architecture, Standards, Scientific Models y servicios.

Su premisa fundamental es que la Evidence precede a la decisión, pero no la sustituye. Evidence puede mostrar riesgos, desempeño o alternativas; la decisión incorpora además propósito, derechos, incertidumbre, recursos y responsabilidad. Por ello, toda decisión material deberá declarar qué parte deriva de Evidence, qué parte constituye interpretación y qué parte expresa una elección institucional.

El modelo persigue cinco objetivos: preservar integridad científica; mantener coherencia arquitectónica; facilitar Temporal Evolution; sostener Interoperability; y proteger el conocimiento institucional y territorial.

La Governance se organiza en cuatro dominios coordinados.

La Governance estratégica protege The Nebula Thesis™, Vision, Doctrine, Constitution y dirección institucional. Determina qué propósitos no deberán sacrificarse por ventajas de corto plazo.

La Governance científica administra preguntas, métodos, modelos, Ontology, Evidence y programas de investigación. No decide mediante jerarquía administrativa qué hipótesis son verdaderas; decide qué métodos y afirmaciones pueden recibir determinado estado institucional.

La Governance técnica regula Architecture, APIs, SDKs, schemas, seguridad, modelos de datos, interoperabilidad y ciclo de vida tecnológico. Las implementaciones deberán ajustarse a Standards y no convertir decisiones de proveedor en reglas del Framework.

La Governance operativa administra publicaciones, versiones, incidentes, catálogos, permisos y cumplimiento cotidiano.

El modelo añade un dominio transversal de Governance territorial y bioeconómica, necesario para representar a Caficultores, organizaciones territoriales y actores afectados por Digital Terroir®. La participación territorial no será consultiva por defecto cuando una decisión afecte identidad, conocimiento, acceso, distribución de valor o condiciones de operación.

Los principales órganos propuestos son: Foundational Council, Scientific Council, Standards Council, Architecture Review Board, Knowledge Governance Council, Data and AI Governance Council, Territorial and Bioeconomy Council, Framework Secretariat y Constitutional Review Chamber. Estos nombres describen funciones. Una implementación inicial puede combinar órganos cuando preserve separación de responsabilidades, recusación y derecho de apelación.

Las decisiones se clasifican por alcance e impacto. Las modificaciones editoriales y operativas reversibles pueden utilizar aprobación delegada. Los cambios de Standards requieren RFC, revisión y pruebas de implementación. Los cambios científicos requieren Evidence y revisión competente. Las reformas constitucionales siguen el procedimiento superior de The Nebula Constitution™.

El modelo adopta rough consensus con objeciones registradas. RFC 7282 sostiene que el consenso técnico no es mayoría simple y que las objeciones deben ser comprendidas y tratadas, aunque no todas deban ser acomodadas. El W3C Process vigente exige considerar opiniones legítimas, permite registrar Formal Objections y contempla reabrir decisiones cuando aparece nueva información. Nebula toma estas prácticas como referencia para evitar tanto el veto individual como la tiranía de la mayoría. ^[13]

Los instrumentos oficiales son The Nebula Standards™, The Nebula RFC™, Architecture Decision Records, Scientific Review Records, Decision Records, control de versiones, The Nebula Library™, registros de riesgo, registros de conflicto de interés y auditorías de conformidad.

El ciclo de cambio comprende identificación del problema, propuesta, clasificación, justificación, consulta, revisión, decisión, implementación, publicación, monitoreo y revisión posterior. Cada fase puede devolver la propuesta para corrección o terminarla.

Risk Governance se alinea con ISO 31000:2018, que continúa vigente en julio de 2026 aunque una tercera edición se encuentra en desarrollo. Compliance Governance puede apoyarse en ISO 37301:2021. La gestión de reportes de irregularidades puede considerar ISO 37002:2021 y sus principios de confianza, imparcialidad y protección. ^{[3, 4, 5]}

La Governance de inteligencia artificial deberá integrar ISO/IEC 42001:2023 y NIST AI RMF 1.0. En julio de 2026, NIST informa que AI RMF 1.0 se encuentra en revisión; por tanto, Nebula deberá versionar el perfil utilizado y evitar asumir que una guía externa permanece estática. ^[6]

La Governance de conocimiento deberá considerar ISO 30401:2018 como referencia vigente, reconociendo que una segunda edición se encontraba en fase Draft International Standard en julio de 2026. La Governance de datos podrá considerar ISO/IEC 38505-1:2017, también en revisión. ^{[8, 9]}

El modelo será validado si permite decisiones oportunas, trazables, impugnables y coherentes; si reduce contradicciones arquitectónicas; si protege Evidence adversa; si permite retirar modelos inseguros; y si incorpora actores afectados de manera material.

Deberá considerarse insuficiente si produce parálisis, concentra autoridad sin control, utiliza consenso como silencio, convierte Standards en barreras de innovación o permite que intereses comerciales alteren afirmaciones científicas.

---

#Parte I — Naturaleza y propósito de Governance

#1. Governance como sistema

Governance no es una reunión periódica ni una colección de aprobaciones. Es un sistema compuesto por propósitos, órganos, derechos, procesos, instrumentos, información y mecanismos de rendición de cuentas.

Puede representarse conceptualmente como:

$$\mathcal{G} = (P, A, R, D, E, C, M, T)$$

donde:

• $P$ representa propósito y principios;
• $A$ representa autoridades;
• $R$ representa roles y responsabilidades;
• $D$ representa decisiones;
• $E$ representa Evidence;
• $C$ representa controles y mecanismos de impugnación;
• $M$ representa métricas;
• $T$ representa Temporal Evolution.

La calidad de Governance no depende solo de la existencia de estos componentes, sino de sus relaciones. Una autoridad sin Evidence produce arbitrariedad. Evidence sin autoridad produce análisis sin decisión. Un proceso sin apelación produce rigidez. Una apelación sin registro produce repetición del conflicto.

#2. Governance y Management

Governance determina:

• propósito;
• principios;
• tolerancia al riesgo;
• delegaciones;
• derechos;
• criterios de éxito;
• límites.

Management determina:

• actividades;
• asignación de recursos;
• cronogramas;
• procedimientos;
• controles cotidianos;
• implementación.

El órgano de Governance no debería microgestionar operaciones. Management no deberá modificar silenciosamente principios o Standards mediante conveniencia local.

#3. Bienes gobernados

El modelo gobierna:

• documentos fundacionales;
• Standards;
• RFC;
• Architecture;
• Knowledge Model;
• Ontology;
• Scientific Models;
• datasets;
• identidad y procedencia;
• aplicaciones;
• propiedad intelectual;
• acceso;
• relaciones territoriales;
• riesgos;
• modelo económico.

Cada bien requiere un steward y una autoridad de decisión claramente identificados.

#4. Stakeholders

Los stakeholders incluyen:

• Caficultores;
• investigadores;
• operadores;
• ingenieros;
• usuarios;
• organizaciones territoriales;
• aliados tecnológicos;
• universidades;
• financiadores;
• autoridades;
• clientes;
• comunidades afectadas;
• generaciones futuras del ecosistema.

No todos participan en todas las decisiones. La inclusión deberá corresponder con conocimiento, afectación, derechos y responsabilidad.

---

#Parte II — Objetivos de Governance

#5. Preservar la integridad científica

La Governance científica deberá impedir que resultados se clasifiquen según conveniencia comercial.

Los Scientific Models deberán recibir estados mediante Evidence, validación y revisión. Una autoridad administrativa puede suspender el uso de un modelo por riesgo, pero no declarar que una hipótesis es verdadera.

La Evidence adversa deberá preservarse. Los conflictos entre resultados deberán representarse en Living Knowledge Infrastructure™.

#6. Garantizar coherencia arquitectónica

La Architecture deberá evolucionar dentro de principios comunes.

La Governance técnica evitará:

• duplicación semántica;
• APIs incompatibles;
• identidades paralelas;
• dependencias irreversibles;
• modelos sin registro;
• seguridad inconsistente.

La coherencia no significa uniformidad absoluta. Las extensiones de dominio podrán diferir cuando las diferencias sean científicamente justificadas.

#7. Facilitar Temporal Evolution

La Governance debe permitir cambio sin destruir estabilidad.

Esto requiere:

• clasificación de cambios;
• versiones;
• periodos de deprecación;
• migración;
• compatibilidad;
• monitoreo;
• retirada.

Una decisión que nunca puede revisarse se convierte en dogma. Una decisión que cambia sin control destruye confianza.

#8. Mantener Interoperability

Los Standards deberán prevalecer sobre implementaciones particulares dentro de su alcance.

Un proveedor puede ofrecer una solución eficiente, pero no deberá alterar la semántica oficial ni impedir exportación. Interoperability incluye estructura, significado, procedencia y estado epistemológico.

#9. Proteger conocimiento institucional y territorial

La protección comprende:

• preservación;
• integridad;
• atribución;
• derechos;
• seguridad;
• acceso;
• continuidad;
• uso legítimo.

El conocimiento territorial no deberá perder autoría cuando ingresa al Knowledge Graph. La Governance deberá distinguir custodia, licencia y propiedad.

#10. Crear y proteger valor

ISO 37000 relaciona Governance con propósito y responsabilidades del órgano de gobierno. ISO 31000 vincula risk management con creación y protección de valor. Nebula integra ambas orientaciones: Governance deberá producir valor científico, territorial, tecnológico y económico sin ocultar trade-offs. ^[1]

---

#Parte III — Principios canónicos

#11. La Evidence precede a la decisión

Toda decisión material deberá identificar Evidence disponible, calidad, incertidumbre y vacíos.

Este principio no exige esperar certeza completa. Exige conocer qué se sabe y qué se asume.

En una emergencia, puede decidirse con Evidence limitada. El Decision Record deberá declarar esa limitación y establecer revisión posterior.

#12. Toda decisión relevante se documenta

Una decisión relevante modifica Standards, derechos, Architecture, modelos, recursos críticos o estado de Knowledge Claims.

El registro deberá contener:

• problema;
• alternativas;
• Evidence;
• participantes;
• conflictos;
• decisión;
• fundamento;
• consecuencias;
• fecha;
• revisión.

La documentación debe ser proporcional. No toda acción operativa requiere un expediente extenso.

#13. Los cambios son revisables

Toda decisión deberá indicar:

• fecha de revisión;
• condición de reapertura;
• indicadores;
• autoridad competente.

El W3C Process contempla reabrir decisiones cuando aparece nueva información. Nebula adopta esta práctica como principio general de Temporal Evolution. ^[13]

#14. Los Standards prevalecen sobre implementaciones

Dentro de su alcance, un Standard define el contrato institucional.

Una implementación puede excederlo, pero no presentarse como conforme si altera requisitos.

Las excepciones deberán documentarse, limitarse y expirar.

#15. Governance habilita innovación responsable

Una Governance madura no busca eliminar riesgo. Busca aceptar riesgos informados que no vulneren principios, derechos o seguridad.

Los experimentos deberán disponer de sandboxes, estados preliminares y límites de exposición.

#16. Autoridad y responsabilidad permanecen unidas

Quien posee autoridad para aprobar una decisión deberá responder por sus consecuencias dentro del alcance definido.

La responsabilidad no deberá transferirse completamente a un algoritmo, proveedor o comité abstracto.

#17. La participación corresponde con afectación

Las personas afectadas deberán disponer de información y canales proporcionales para participar, objetar o apelar.

Este principio es esencial para Digital Terroir® y conocimiento territorial.

#18. La transparencia posee límites legítimos

La transparencia no exige revelar información personal, secretos, vulnerabilidades o conocimiento territorial sensible.

Las restricciones deberán justificarse y no utilizarse para ocultar errores o conflictos de interés.

---

#Parte IV — Jerarquía normativa

#19. Orden institucional

La jerarquía propuesta es:

1. The Nebula Constitution™;
2. documentos fundacionales;
3. The Nebula Standards™;
4. The Nebula RFC™ aprobados;
5. políticas;
6. Architecture Decision Records y Scientific Review Records;
7. procedimientos;
8. guías;
9. implementaciones.

Un instrumento inferior no deberá contradecir uno superior.

#20. Documentos fundacionales

Definen propósito, visión, doctrina, Constitution, Scientific Model, Epistemology, Mathematics, Ontology, Architecture, Knowledge Model y Governance.

Sus modificaciones requieren mayor escrutinio porque afectan múltiples dominios.

#21. Standards

Los Standards definen requisitos normativos para Interoperability, identidad, Evidence, seguridad, datos, modelos o APIs.

Deberán ser implementables y verificables.

#22. RFC

Un RFC propone cambios, experimentos, Standards o prácticas.

Su aprobación no necesariamente lo convierte en Standard. Puede recibir estado Experimental, Informational o Standards Track.

#23. Políticas y procedimientos

Las políticas establecen reglas institucionales.

Los procedimientos describen cómo ejecutarlas.

Una política no deberá utilizarse para modificar principios constitucionales sin el proceso correspondiente.

graph TD
    C[The Nebula Constitution™] --> F[Foundational Documents]
    F --> S[The Nebula Standards™]
    S --> R[Approved RFC]
    R --> P[Policies]
    P --> D[Decision Records]
    D --> O[Procedures and Guides]
    O --> I[Implementations]

---

#Parte V — Dominios y niveles de Governance

#24. Governance estratégica

Protege propósito, doctrina y sostenibilidad institucional.

Aprueba:

• dirección general;
• reformas fundacionales;
• alianzas críticas;
• modelo económico;
• tolerancia institucional al riesgo;
• derechos y obligaciones.

#25. Governance científica

Administra:

• programas de investigación;
• Scientific Models;
• validación;
• estado de Knowledge Claims;
• Ontology científica;
• integridad;
• publicación.

La Governance científica no sustituye peer review externo cuando resulte necesario.

#26. Governance técnica

Administra:

• Architecture;
• APIs;
• SDKs;
• schemas;
• seguridad;
• infraestructura;
• despliegue;
• Technical Standards;
• deuda arquitectónica.

#27. Governance operativa

Administra:

• versiones;
• incidentes;
• catálogos;
• accesos;
• publicaciones;
• soporte;
• cumplimiento rutinario.

#28. Governance territorial y bioeconómica

Evalúa decisiones sobre:

• Digital Terroir®;
• conocimiento local;
• datos de finca;
• participación;
• atribución;
• distribución de beneficios;
• impactos ambientales y sociales.

FAO propone principios aspiracionales y criterios para una bioeconomía sostenible que abordan dimensiones de sostenibilidad y trade-offs en niveles internacional, nacional y local. Nebula utilizará esa orientación para evitar tratar la bioeconomía como intrínsecamente sostenible. ^[15]

#29. Coordinación

Una decisión puede atravesar varios dominios.

Ejemplo: desplegar un modelo automático de fermentación requiere Governance científica, técnica, operativa, de IA y territorial.

El lead body coordinará la decisión, pero no absorberá competencias de los demás.

---

#Parte VI — Órganos de Governance

#30. Foundational Council

Custodia los documentos fundacionales y propósito institucional.

Funciones:

• interpretar coherencia superior;
• iniciar reformas;
• evaluar desviaciones doctrinales;
• aprobar cambios fundacionales;
• proteger continuidad.

No deberá decidir resultados científicos específicos.

#31. Scientific Council

Funciones:

• revisar Scientific Models;
• aprobar metodologías;
• evaluar Evidence;
• definir agendas;
• supervisar integridad;
• clasificar Knowledge Claims.

Sus miembros deberán declarar competencia y conflictos.

#32. Standards Council

Funciones:

• administrar Standards Track;
• evaluar RFC;
• aprobar perfiles de Interoperability;
• coordinar implementaciones;
• administrar deprecaciones.

#33. Architecture Review Board

Funciones:

• revisar Architecture;
• aprobar ADR de alto impacto;
• administrar technical debt;
• evaluar seguridad, resiliencia y portabilidad;
• mantener viewpoints.

#34. Knowledge Governance Council

Funciones:

• administrar Knowledge Model;
• stewardships;
• The Nebula Library™;
• preservación;
• acceso;
• metaconocimiento;
• calidad.

#35. Data and AI Governance Council

Funciones:

• gobernar datos y modelos de IA;
• evaluar impacto;
• autorizar despliegues;
• monitorear deriva;
• retirar modelos;
• revisar incidentes.

ISO/IEC 42001:2023 establece requisitos para un sistema de gestión de IA orientado a desarrollo, provisión o uso responsable. NIST AI RMF 1.0 ofrece un marco voluntario y adaptable para gestionar riesgos de IA. Nebula podrá mapear sus controles a ambas referencias. ^{[6, 16]}

#36. Territorial and Bioeconomy Council

Funciones:

• representar actores territoriales;
• revisar conocimiento sensible;
• evaluar distribución de valor;
• participar en decisiones de Digital Terroir®;
• supervisar consentimiento y atribución;
• analizar impactos.

#37. Framework Secretariat

Funciones:

• administrar agendas;
• mantener registros;
• publicar decisiones;
• verificar plazos;
• coordinar consultas;
• custodiar The Nebula Library™.

La Secretaría no deberá alterar decisiones sustantivas mediante edición.

#38. Constitutional Review Chamber

Funciones:

• resolver apelaciones superiores;
• revisar debido proceso;
• interpretar Constitution;
• ordenar mitigaciones;
• publicar decisiones motivadas.

Deberá poseer independencia suficiente respecto al órgano apelado.

architecture-beta
    group strategic(cloud)[Strategic Governance]
    group scientific(cloud)[Scientific Governance]
    group technical(cloud)[Technical Governance]
    group operational(cloud)[Operational Governance]
    group territorial(cloud)[Territorial Governance]

    service foundational(server)[Foundational Council] in strategic
    service chamber(server)[Constitutional Review Chamber] in strategic
    service science(server)[Scientific Council] in scientific
    service knowledge(server)[Knowledge Governance Council] in scientific
    service standards(server)[Standards Council] in technical
    service architecture(server)[Architecture Review Board] in technical
    service dataai(server)[Data and AI Governance Council] in technical
    service secretariat(server)[Framework Secretariat] in operational
    service territory(server)[Territorial and Bioeconomy Council] in territorial

    foundational:R -- L:science
    science:R -- L:standards
    standards:R -- L:architecture
    knowledge:R -- L:dataai
    secretariat:T -- B:foundational
    secretariat:T -- B:standards
    territory:R -- L:science
    chamber:T -- B:foundational

---

#Parte VII — Roles, competencia y conflictos

#39. Chair

El Chair facilita deliberación, protege debido proceso y determina Consensus según el charter.

No deberá utilizar su posición para suprimir objeciones legítimas.

#40. Editor

El Editor integra cambios aprobados y mantiene coherencia documental.

No posee autoridad unilateral sobre contenido normativo.

#41. Steward

El Steward administra calidad y ciclo de vida de un activo.

Puede proponer cambios y ejecutar decisiones dentro de su delegación.

#42. Reviewer

El Reviewer evalúa Evidence, metodología, Architecture o conformidad.

Deberá declarar competencia y conflicto de interés.

#43. Decision Authority

La Decision Authority adopta la decisión final dentro de un alcance.

Debe verificar que el proceso y la Evidence sean suficientes.

#44. Objector

Cualquier stakeholder autorizado puede registrar una objeción sustentada.

El Objector deberá identificar problema, consecuencias y, cuando sea posible, mitigación.

#45. Observer

Un Observer puede acceder y comentar sin participar formalmente en la decisión.

#46. Conflicto de interés

Los conflictos pueden ser:

• financieros;
• académicos;
• comerciales;
• personales;
• territoriales;
• de autoría;
• de proveedor.

La existencia de un conflicto no siempre exige exclusión. Exige declaración, evaluación y mitigación.

#47. Recusación

La recusación deberá aplicarse cuando el conflicto pueda comprometer razonablemente la independencia.

La razón y el efecto sobre quorum o Consensus deberán registrarse.

---

#Parte VIII — Derechos de decisión

#48. Matriz de autoridad

#49. Delegación

La autoridad puede delegarse mediante:

• alcance;
• duración;
• condiciones;
• límites;
• mecanismo de revocación.

La responsabilidad superior no desaparece por delegación.

#50. Quorum

Cada charter deberá definir quorum cuando sea necesario.

El W3C Process no exige un quorum universal y permite que cada charter establezca umbrales. Nebula seguirá un enfoque contextual, evitando decisiones materiales con participación nominal insuficiente. ^[13]

#51. Decisiones conjuntas

Cuando dos órganos poseen autoridad material, deberán utilizar decisión conjunta o escalamiento.

No deberá resolverse mediante competencia informal.

---

#Parte IX — Evidence y calidad de decisión

#52. Evidence Package

Toda propuesta material debería incluir:

• problema;
• contexto;
• alternativas;
• Evidence favorable;
• Evidence adversa;
• incertidumbre;
• riesgos;
• impactos;
• reversibilidad;
• plan de validación.

#53. Niveles de Evidence

El nivel requerido depende del riesgo.

Una decisión experimental puede apoyarse en Evidence preliminar y exposición limitada.

Una decisión de alto impacto requiere Evidence corroborada, validación y plan de reversión.

#54. Opinión experta

La opinión experta puede informar decisiones cuando la Evidence es incompleta.

Deberá registrarse como opinión, con identidad, competencia, fundamento e incertidumbre.

#55. Ausencia de Evidence

La ausencia de Evidence no deberá interpretarse automáticamente como seguridad.

Una propuesta novedosa puede carecer de fallos reportados porque nunca ha sido utilizada.

#56. Precaution y proportionality

Cuando existe riesgo grave e incertidumbre elevada, Governance puede limitar despliegue.

La precaución no deberá convertirse en prohibición indefinida sin revisión.

#57. Decision Quality Review

Después de la implementación, deberá evaluarse:

• si la Evidence era adecuada;
• si los supuestos se cumplieron;
• si los riesgos se materializaron;
• si la decisión produjo valor;
• qué aprendizaje debe conservarse.

---

#Parte X — Consensus, dissent y apelación

#58. Rough Consensus

Nebula utilizará rough consensus para decisiones técnicas y científicas cuando no se requiera votación formal.

Rough consensus significa que:

• las opiniones relevantes fueron escuchadas;
• los problemas técnicos fueron tratados;
• no subsiste una objeción material no respondida;
• existe apoyo suficiente para avanzar.

RFC 7282 enfatiza que rough consensus no es contar votos y que una objeción técnicamente sólida puede ser más importante que una mayoría amplia. ^[11]

#59. Unanimidad

La unanimidad puede ser deseable, pero no será requisito general.

Exigir unanimidad concede veto permanente y puede favorecer inmovilidad.

#60. Votación

La votación se utilizará cuando:

• el charter la exige;
• Consensus no puede alcanzarse;
• la decisión es administrativa;
• se necesita seleccionar entre alternativas equivalentes.

El resultado deberá registrar votos, abstenciones, objeciones y conflicto de interés.

#61. Silencio

El silencio no deberá interpretarse siempre como consentimiento.

Lazy consensus puede utilizarse para cambios de bajo impacto cuando exista notificación suficiente, plazo y posibilidad clara de objeción.

#62. Objeción formal

Una Formal Objection deberá incluir:

• decisión cuestionada;
• argumento técnico o procedimental;
• consecuencias;
• Evidence;
• cambio solicitado.

El W3C exige registrar y responder Formal Objections, incluyendo su rationale y resolución. Nebula adoptará esa trazabilidad. ^[13]

#63. Apelación

La apelación evalúa:

• debido proceso;
• autoridad;
• consideración de Evidence;
• conflicto;
• proporcionalidad;
• coherencia constitucional.

No deberá utilizarse como repetición ilimitada de argumentos ya tratados sin nueva información.

#64. Minority Report

Una minoría podrá publicar un informe razonado junto a la decisión.

Este mecanismo preserva conocimiento y facilita revisión futura.

flowchart TD
    A[Propuesta] --> B[Consulta]
    B --> C{¿Objeción sostenida?}
    C -->|No| D[Consensus]
    C -->|Sí| E[Análisis y mediación]
    E --> F{¿Resuelta?}
    F -->|Sí| D
    F -->|No| G[Decisión con dissent o votación]
    G --> H[Formal Objection]
    H --> I[Appeal Review]
    I --> J{Resultado}
    J -->|Affirm| K[Decisión confirmada]
    J -->|Return| L[Trabajo adicional]
    J -->|Overturn| M[Decisión anulada]

---

#Parte XI — Instrumentos de Governance

#65. The Nebula Standards™

Los Standards contienen requisitos verificables.

Deberán declarar:

• alcance;
• términos;
• requisitos;
• seguridad;
• privacidad;
• Interoperability;
• conformidad;
• evolución.

#66. The Nebula RFC™

El RFC es el instrumento principal de propuesta.

Estados sugeridos:

• Draft;
• Review;
• Candidate;
• Experimental;
• Informational;
• Standard;
• Rejected;
• Withdrawn;
• Superseded.

RFC 2026 describe un proceso de madurez, revisión, publicación y experiencia operacional. Aunque su estructura fue actualizada por documentos posteriores, continúa siendo referencia fundamental del IETF Standards Process. ^[10]

#67. Architecture Decision Record

Un ADR documenta una decisión arquitectónica.

Deberá incluir alternativas y consecuencias, no solo la opción seleccionada.

#68. Scientific Review Record

Documenta evaluación de:

• método;
• Evidence;
• reproducibilidad;
• incertidumbre;
• limitaciones;
• estado recomendado.

#69. Decision Record

Es el registro general de una decisión de Governance.

#70. Version Control

Toda versión material deberá poseer identidad, fecha, estado y relación con versiones anteriores.

El control de versiones no reemplaza Governance; solo registra cambios.

#71. Peer Review

La revisión puede ser:

• interna;
• externa;
• abierta;
• ciega;
• independiente;
• comunitaria.

El método deberá corresponder al riesgo y al tipo de conocimiento.

#72. The Nebula Library™

Será la publicación de registro de:

• Standards;
• RFC;
• ADR;
• decisiones;
• revisiones;
• modelos;
• objeciones;
• versiones;
• auditorías.

#73. Registers

La Governance deberá mantener:

• risk register;
• decision register;
• conflict register;
• exception register;
• model register;
• incident register;
• appeals register.

---

#Parte XII — Ciclo de cambio

#74. Identificación

El ciclo comienza cuando se identifica:

• problema;
• oportunidad;
• contradicción;
• riesgo;
• obsolescencia;
• nueva Evidence.

#75. Propuesta

La propuesta describe el cambio y su alcance.

#76. Clasificación

El Secretariat clasifica impacto y proceso requerido.

#77. Justificación

La justificación contiene Evidence, alternativas, riesgos y beneficios.

#78. Consulta

Los stakeholders relevantes reciben acceso y plazo.

#79. Revisión

La revisión evalúa mérito científico, técnico, territorial, legal y económico.

#80. Decisión

La autoridad adopta, rechaza, devuelve, limita o autoriza experimento.

#81. Implementación

La implementación deberá cumplir condiciones, pruebas y migración.

#82. Publicación

La decisión, versión y estado se publican en The Nebula Library™.

#83. Seguimiento

Se monitorean resultados e indicadores.

#84. Revisión posterior

La decisión puede confirmarse, modificarse o retirarse.

stateDiagram
    [*] --> Identified
    Identified --> Proposed
    Proposed --> Classified
    Classified --> Consulted
    Consulted --> Reviewed
    Reviewed --> Approved
    Reviewed --> Returned
    Reviewed --> Rejected
    Returned --> Proposed
    Approved --> Implemented
    Implemented --> Published
    Published --> Monitored
    Monitored --> Confirmed
    Monitored --> Revised
    Monitored --> Withdrawn
    Revised --> Proposed
    Rejected --> Archived
    Withdrawn --> Archived
    Confirmed --> [*]

---

#Parte XIII — Gestión de riesgo, cumplimiento e integridad

#85. Risk Governance

Risk Governance deberá integrarse en decisiones, no funcionar como revisión tardía.

El proceso comprende:

• identificación;
• análisis;
• evaluación;
• tratamiento;
• monitoreo;
• comunicación.

ISO 31000:2018 proporciona principios y directrices aplicables a cualquier organización y permanecía vigente en julio de 2026, aunque ISO había iniciado su revisión. ^[3]

#86. Risk Appetite

Cada dominio deberá declarar tolerancias.

La tolerancia científica para un experimento puede ser diferente de la tolerancia operacional para un sistema automático.

#87. Compliance Governance

ISO 37301:2021 establece requisitos y orientación para sistemas de compliance y se basa en principios de buena Governance, proporcionalidad, transparencia y sostenibilidad. Nebula podrá integrarlo con sus sistemas de calidad, seguridad y conocimiento. ^[4]

#88. Reporting wrongdoing

Los actores deberán disponer de canales protegidos para reportar:

• manipulación de Evidence;
• conflicto no declarado;
• uso indebido;
• vulneración de derechos;
• incumplimiento de Standards.

ISO 37002:2021 estructura whistleblowing alrededor de confianza, imparcialidad y protección, con procesos de recepción, evaluación, tratamiento y cierre. ^[5]

#89. Scientific misconduct

Las acusaciones deberán investigarse con:

• imparcialidad;
• confidencialidad proporcional;
• derecho de respuesta;
• preservación de Evidence;
• protección contra represalias;
• resolución documentada.

#90. Security Governance

ISO/IEC 27001:2022 proporciona requisitos para un sistema de gestión de seguridad de la información basado en riesgos y orientado a confidencialidad, integridad y disponibilidad. Nebula deberá integrar seguridad con Governance científica, no tratarla como responsabilidad exclusiva de infraestructura. ^[7]

---

#Parte XIV — Governance de datos, conocimiento e IA

#91. Data Governance

Los datos deberán poseer:

• owner;
• steward;
• propósito;
• clasificación;
• calidad;
• retención;
• acceso;
• lineage.

ISO/IEC 38505-1:2017 aplica principios de Governance de IT a datos creados, recopilados, almacenados o controlados por sistemas y permanecía vigente en julio de 2026, aunque se esperaba su sustitución. ^[9]

#92. Knowledge Governance

El conocimiento deberá gobernarse según:

• estado epistemológico;
• Evidence;
• versión;
• derechos;
• preservación;
• revisión.

ISO 30401:2018 continúa siendo la referencia publicada, mientras ISO/DIS 30401 se encontraba en fase de consulta en julio de 2026. El Framework deberá distinguir norma vigente y borrador. ^[8]

#93. AI Governance

Todo sistema de IA deberá poseer:

• responsable;
• Context of Use;
• clasificación de riesgo;
• Evidence de desempeño;
• monitoreo;
• límites;
• mecanismo de retirada;
• supervisión humana.

#94. Automated Decisions

Una decisión automatizada de alto impacto requerirá autoridad explícita y posibilidad de intervención.

El sistema deberá conservar input, modelo, output y acción.

#95. Model Change

Un modelo reentrenado constituye una nueva versión.

No deberá desplegarse por actualización automática sin evaluación proporcional.

#96. Generative AI

Las salidas generativas deberán clasificarse como contenido o Inference candidata.

No deberán incorporarse a Knowledge Model como hechos sin validación.

NIST mantiene un perfil específico de AI RMF para IA generativa y actualizó su página en abril de 2026. ^[16]

---

#Parte XV — Participación, apertura y legitimidad

#97. Ciencia abierta

La UNESCO Recommendation on Open Science fue adoptada el 23 de noviembre de 2021 y promueve conocimiento accesible y reutilizable, infraestructuras abiertas, participación social y diálogo con sistemas de conocimiento indígenas y tradicionales. Nebula deberá aplicar apertura responsable, reconociendo restricciones legítimas. ^[14]

#98. Participación territorial

La participación deberá ocurrir antes de que la decisión sea irreversible.

Los actores territoriales deberán comprender:

• propósito;
• datos;
• riesgos;
• beneficios;
• derechos;
• opciones.

#99. Lenguaje

Las consultas deberán utilizar lenguaje comprensible.

La traducción no deberá reducirse a etiquetas; debe preservar significado y consecuencias.

#100. Public consultation

Los Standards de amplio impacto deberían recibir consulta pública o del ecosistema.

Los comentarios y respuestas deberán conservarse.

#101. Confidential consultation

Cuando la información sea sensible, la consulta podrá limitarse a actores autorizados.

La restricción deberá documentarse.

#102. Equity and benefit

Una decisión sobre conocimiento territorial deberá evaluar quién obtiene valor, quién asume riesgo y quién puede objetar.

---

#Parte XVI — Incidentes y Governance de emergencia

#103. Incident

Un incidente es un evento que amenaza seguridad, integridad científica, continuidad, derechos o confianza.

#104. Incident Commander

Podrá recibir autoridad temporal para:

• suspender servicios;
• aislar componentes;
• retirar modelos;
• bloquear accesos;
• preservar Evidence.

#105. Condiciones

La autoridad de emergencia deberá poseer:

• alcance;
• duración;
• activación;
• registro;
• revisión;
• expiración.

#106. Post-incident review

Toda emergencia material deberá producir:

• timeline;
• causa;
• impacto;
• decisiones;
• Evidence;
• acciones;
• cambios requeridos.

#107. Emergency Standard

Puede emitirse un requisito temporal cuando exista riesgo inmediato.

Deberá expirar o ingresar al proceso normal dentro de un plazo definido.

---

#Parte XVII — Transparencia, rendición de cuentas y auditoría

#108. Publicación de decisiones

Las decisiones públicas deberán incluir:

• resultado;
• rationale;
• participantes;
• objeciones;
• versión;
• fecha.

La información sensible podrá redactarse, preservando una explicación suficiente.

#109. Accountability

Cada decisión deberá tener un accountable owner.

Los comités no deberán utilizarse para diluir responsabilidad.

#110. Audit Trail

El audit trail deberá permitir reconstruir:

• propuesta;
• comentarios;
• revisiones;
• decisión;
• implementación;
• efectos;
• cambios posteriores.

#111. Auditoría

Las auditorías pueden ser:

• científicas;
• técnicas;
• de seguridad;
• de conocimiento;
• de proceso;
• territoriales.

#112. Independence

La independencia deberá corresponder al riesgo.

Una auditoría de alto impacto no debería ser ejecutada únicamente por quienes diseñaron el sistema.

#113. Findings

Los findings deberán clasificarse, asignarse y cerrarse con Evidence.

---

#Parte XVIII — Indicadores y madurez

#114. Indicadores

#115. Niveles de madurez

#Nivel 0 — Implícito

Las decisiones dependen de autoridad informal.

#Nivel 1 — Registrado

Existen registros básicos y responsables.

#Nivel 2 — Definido

Existen charters, procesos y roles.

#Nivel 3 — Implementado

Los procesos se aplican de manera consistente.

#Nivel 4 — Medido

Existen indicadores, auditorías y revisiones.

#Nivel 5 — Adaptativo

La Governance aprende y se reforma mediante Evidence.

#116. Antimétricas

No deberán utilizarse aisladamente:

• número de reuniones;
• número de documentos;
• volumen de comentarios;
• porcentaje de unanimidad;
• cantidad de Standards.

Estas métricas pueden aumentar sin mejorar Governance.

---

#Parte XIX — Casos de uso

#117. Aprobación de un Scientific Model

Un equipo propone un modelo para detectar fin de fermentación.

El Scientific Council revisa método y Evidence. Data and AI Governance evalúa riesgo y monitoreo. Territorial Council analiza uso en finca. Architecture Board verifica despliegue. La aprobación limita Context of Use y exige supervisión.

#118. Cambio de Ontology

Se propone dividir una clase.

Standards Council evalúa Interoperability. Knowledge Governance analiza migración. Scientific Council revisa significado. Se publica mapping y periodo de deprecación.

#119. Incidente de integridad

Se descubre que un dataset fue corregido sin registro.

Se preservan versiones, se suspenden claims afectados, se investiga procedencia y se publican correcciones.

#120. Proveedor propietario

Un proveedor ofrece una plataforma que no permite exportar modelos.

Architecture Board evalúa dependencia. Standards Council verifica contratos. La solución puede aceptarse como experimento, pero no como infraestructura canónica sin plan de portabilidad.

#121. Objeción territorial

Una organización de Caficultores objeta el uso de datos de localización.

La decisión se suspende dentro del alcance afectado. Territorial Council revisa consentimiento, beneficio y riesgo. La Review Chamber resuelve si existe conflicto.

#122. Emergencia operacional

Un modelo emite recomendaciones peligrosas.

Incident Commander lo retira. Se conserva Evidence, se notifica a usuarios y se inicia revisión científica.

---

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

#123. Validación

The Nebula Governance Model™ deberá evaluarse mediante:

• simulaciones de decisión;
• auditorías;
• estudios de tiempo;
• revisión de incidentes;
• satisfacción de stakeholders;
• Interoperability;
• capacidad de apelación;
• calidad de Decision Records.

#124. Pruebas de conformidad

Una implementación deberá demostrar:

• autoridad definida;
• conflicto gestionado;
• Evidence preservada;
• decisiones versionadas;
• objeciones registradas;
• apelación disponible;
• cambios monitoreados.

#125. Validación comparativa

El modelo deberá compararse con Governance informal o procesos anteriores.

La mejora puede medirse por menor retrabajo, reducción de incompatibilidades, mayor trazabilidad y respuesta más rápida a incidentes.

#126. Condiciones de refutación

El modelo deberá revisarse si:

• ralentiza de forma desproporcionada decisiones simples;
• concentra autoridad;
• las objeciones no producen consideración real;
• los órganos duplican funciones;
• los Standards bloquean innovación;
• los actores territoriales carecen de influencia material;
• la Evidence se utiliza selectivamente;
• las apelaciones carecen de independencia;
• las decisiones no pueden reconstruirse;
• las métricas incentivan cumplimiento superficial.

---

#Parte XXI — Limitaciones

La primera limitación es institucional. Un documento no puede crear cultura de integridad por sí solo.

La segunda es humana. Las personas pueden ocultar conflictos, manipular procedimientos o utilizar lenguaje técnico para concentrar poder.

La tercera es de escala. Una estructura adecuada para un ecosistema pequeño puede no funcionar en una federación amplia.

La cuarta es temporal. Los órganos y Standards pueden quedar obsoletos.

La quinta es epistemológica. Evidence incompleta puede conducir a decisiones razonables y equivocadas.

La sexta es de participación. Consultar no garantiza influencia real.

La séptima es económica. La revisión y preservación requieren recursos.

La octava es de confidencialidad. La transparencia puede entrar en conflicto con seguridad y derechos.

La novena es de urgencia. Las emergencias requieren velocidad y pueden reducir deliberación.

La décima es técnica. Las herramientas de workflow pueden imponer procesos rígidos.

La undécima es territorial. Las formas institucionales pueden no representar adecuadamente prácticas comunitarias.

La duodécima es de independencia. En ecosistemas pequeños, los participantes pueden desempeñar múltiples roles.

---

#Parte XXII — Agenda de investigación

#127. Governance metrics

Desarrollar indicadores que midan calidad y no solo actividad.

#128. Machine-readable Governance

Representar roles, decisiones, políticas y excepciones mediante Semantic Infrastructure.

#129. Governance de Knowledge Graph

Investigar mecanismos para claims competidores y autoridad contextual.

#130. Participación territorial

Evaluar modelos de representación, consentimiento y beneficio.

#131. AI-assisted Governance

Estudiar IA para clasificar propuestas o detectar conflictos sin delegar autoridad final.

#132. Governance de modelos adaptativos

Definir cuándo una actualización automática constituye nueva versión.

#133. Federated Governance

Desarrollar mecanismos entre organizaciones con autonomía local.

#134. Proof of Governance

Investigar paquetes verificables que demuestren debido proceso sin revelar información sensible.

#135. Emergency Governance

Evaluar autoridad temporal, expiración y revisión.

#136. Sustainable bioeconomy governance

Desarrollar indicadores vinculados con principios de FAO, valor territorial y límites ambientales.

timeline
    title Agenda de The Nebula Governance Model™
    Fase I : Charters y registros
           : RFC y ADR
           : Matriz de autoridad
    Fase II : Scientific y Standards Councils
            : Appeals process
            : Risk Governance
    Fase III : Territorial Governance
             : Data and AI Governance
             : Conformance audits
    Fase IV : Federated Governance
            : Machine-readable policies
            : Proof of Governance
    Fase V : Independent evaluation
           : International alignment
           : Governance Standard candidate

---

#Conclusiones

The Nebula Governance Model™ establece que la evolución del Framework no deberá depender de autoridad informal, urgencia o preferencia tecnológica.

Gobernar significa orientar, supervisar y asumir responsabilidad. Gestionar significa ejecutar dentro de ese marco. La separación permite evitar que una decisión operativa modifique silenciosamente principios institucionales.

La Evidence precede a la decisión, pero no la reemplaza. Toda decisión incorpora interpretación, valores, riesgos y responsabilidad. La Governance deberá declarar esas dimensiones en lugar de ocultarlas detrás de una apariencia exclusivamente técnica.

El modelo organiza Governance estratégica, científica, técnica, operativa y territorial. Esta estructura reconoce que una misma decisión puede afectar conocimiento, Architecture, derechos y valor bioeconómico.

Los órganos propuestos distribuyen funciones y crean mecanismos de revisión. Su implementación puede ser proporcional, pero deberá preservar separación de responsabilidades, conflictos declarados y derecho de apelación.

Rough consensus permite avanzar sin reducir decisiones a mayoría simple. Las objeciones deberán comprenderse y responderse. Una minoría no posee veto automático, pero una objeción técnicamente sólida no deberá desaparecer bajo el peso de una votación.

The Nebula Standards™, RFC, ADR, Scientific Review Records, Decision Records y The Nebula Library™ constituyen la memoria formal de Governance.

El ciclo de cambio garantiza que las propuestas sean clasificadas, revisadas, implementadas y monitoreadas. La publicación no cierra el aprendizaje. Toda decisión material deberá poder reabrirse cuando aparece nueva Evidence.

Risk, compliance, seguridad, datos, conocimiento e IA deberán gobernarse como dominios relacionados. Ningún modelo automático queda fuera de responsabilidad humana. Ninguna firma criptográfica reemplaza calidad científica. Ningún Standard externo elimina la necesidad de interpretar su aplicabilidad.

La participación territorial constituye una condición de legitimidad para Computational Bioeconomy™. El conocimiento de Caficultores y comunidades no deberá convertirse en activo institucional sin atribución, derechos y mecanismos de influencia.

La Governance será madura cuando pueda explicar no solo qué decidió, sino por qué, con qué Evidence, bajo qué autoridad, frente a qué objeciones y con qué mecanismo de corrección.

Su éxito no se medirá por la ausencia de desacuerdo.

Se medirá por la capacidad de convertir el desacuerdo informado en decisiones responsables y conocimiento institucional durable.

---

#Glosario

#Architecture Decision Record

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

#Consensus

Condición de apoyo suficiente en la que las objeciones legítimas han sido consideradas y no subsiste una objeción material sin respuesta.

#Constitutional Review Chamber

Órgano de apelación e interpretación superior del Framework.

#Decision Record

Representación trazable de una decisión institucional.

#Digital Terroir®

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

#Evidence

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

#Formal Objection

Objeción sustentada que activa consideración y respuesta formal.

#Governance

Sistema mediante el cual se orienta, supervisa y responsabiliza al ecosistema.

#Interoperability

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

#Knowledge Claim

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

#Living Knowledge Infrastructure™

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

#Management

Planificación y ejecución cotidiana dentro de los límites de Governance.

#Minority Report

Registro razonado de una posición minoritaria que acompaña una decisión.

#Rough Consensus

Forma de Consensus basada en consideración de problemas y objeciones, no en mayoría simple.

#Scientific Review Record

Registro de evaluación de método, Evidence, incertidumbre y estado científico.

#Steward

Responsable de calidad y ciclo de vida de un activo gobernado.

#Temporal Evolution

Cambio documentado de documentos, Standards, modelos, decisiones y conocimiento.

#The Nebula Library™

Publicación de registro y catálogo institucional.

#The Nebula RFC™

Instrumento formal para proponer cambios, Standards, experimentos o prácticas.

#The Nebula Standards™

Conjunto de especificaciones normativas del ecosistema.

#Trust Infrastructure

Mecanismos científicos, técnicos, semánticos y de Governance que permiten evaluar credibilidad.

---

#Bibliografía recomendada

1. International Organization for Standardization. ISO 37000:2021 — Governance of Organizations — Guidance.

2. International Organization for Standardization e International Electrotechnical Commission. ISO/IEC 38500:2024 — Information Technology — Governance of IT for the Organization.

3. International Organization for Standardization. ISO 31000:2018 — Risk Management — Guidelines.

4. International Organization for Standardization. ISO 37301:2021 — Compliance Management Systems — Requirements with Guidance for Use.

5. International Organization for Standardization. ISO 37002:2021 — Whistleblowing Management Systems — Guidelines.

6. International Organization for Standardization e International Electrotechnical Commission. ISO/IEC 42001:2023 — Artificial Intelligence — Management System.

7. International Organization for Standardization e International Electrotechnical Commission. ISO/IEC 27001:2022 — Information Security Management Systems — Requirements.

8. International Organization for Standardization. ISO 30401:2018 — Knowledge Management Systems — Requirements.

9. International Organization for Standardization e International Electrotechnical Commission. ISO/IEC 38505-1:2017 — Governance of Data.

10. Bradner, S. RFC 2026 — The Internet Standards Process — Revision 3. IETF Best Current Practice 9, 1996.

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

12. Leiba, B. RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. 2017.

13. World Wide Web Consortium. W3C Process Document. Edición efectiva de 2025.

14. UNESCO. Recommendation on Open Science. Adoptada en París el 23 de noviembre de 2021.

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

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

17. Ostrom, E. Governing the Commons. Referencia sugerida.

18. Freeman, R. E. Strategic Management: A Stakeholder Approach. Referencia sugerida.

19. Ansell, C. y Gash, A. “Collaborative Governance in Theory and Practice.” Referencia sugerida.

20. DeNardis, L. The Global War for Internet Governance. Referencia sugerida.

---

#Anexo A — Registro mínimo de decisión

---

#Anexo B — Clasificación de cambios

---

#Anexo C — Prueba de conformidad

Una implementación será compatible con The Nebula Governance Model™ cuando:

1. distinga Governance y Management;
2. defina autoridades y delegaciones;
3. preserve Evidence de decisiones;
4. registre conflictos de interés;
5. permita objeciones;
6. disponga de apelación;
7. clasifique cambios;
8. aplique Standards;
9. mantenga versiones;
10. preserve Minority Reports;
11. gobierne riesgo;
12. gobierne datos, conocimiento e IA;
13. incorpore participación territorial;
14. publique decisiones de forma proporcional;
15. realice revisión posterior.

---

#Anexo D — Canon de Governance

La Evidence precede a la decisión, pero no reemplaza la responsabilidad.

Toda decisión material deberá poder reconstruirse.

Consensus no es unanimidad, silencio ni mayoría simple.

Una objeción legítima deberá recibir consideración y respuesta.

Los Standards prevalecen sobre implementaciones particulares dentro de su alcance.

La autoridad delegada conserva límites, duración y rendición de cuentas.

La emergencia no suspende la obligación de registrar y revisar.

La Governance científica administra estados institucionales; no decreta verdad.

La participación deberá corresponder con la afectación y los derechos.

Toda decisión podrá revisarse cuando aparezca nueva Evidence.

---

#Anexo E — Declaración institucional

The Nebula Governance Model™ constituye el mecanismo oficial para dirigir la evolución científica, tecnológica, semántica, territorial e institucional de The Nebula Framework™.

Su propósito es asegurar que las decisiones relevantes sean transparentes, documentadas, trazables, impugnables y coherentes con The Nebula Constitution™.

Nebula reconoce que ninguna estructura de Governance elimina el error, el conflicto o la incertidumbre. Su legitimidad dependerá de la capacidad para considerar Evidence, distribuir autoridad, proteger derechos, resolver objeciones y corregir decisiones sin borrar la historia.

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

The Nebula Framework™