#The Nebula RFC™

#The Nebula Framework™ — Scientific Edition v1.0

La identidad institucional, el objeto de Governance y las relaciones documentales de esta edición corresponden al Foundation Draft oficial NBL-RFC-001.

---

#Convenciones normativas y epistemológicas

The Nebula RFC™ define el proceso oficial mediante el cual una idea puede convertirse en una modificación reconocida de The Nebula Framework™. El proceso comprende formulación, revisión, validación, decisión, implementación, monitoreo y preservación. Su finalidad no es producir documentos por sí mismos, sino conservar el razonamiento que permite explicar por qué una alternativa fue adoptada, condicionada, rechazada o retirada.

En este documento, RFC significa Request for Comments y designa un Knowledge Object versionado que formula una propuesta suficientemente concreta para recibir crítica informada. Una propuesta describe un cambio posible; una decisión lo acepta, limita, devuelve, rechaza o retira; una implementación materializa una decisión. Estas entidades DEBEN permanecer diferenciadas.

Evidence respalda, contradice o deja indeterminadas las afirmaciones del RFC. Observation representa un resultado contextualizado de observación. Inference representa una proposición derivada mediante Scientific Model, cálculo, regla o interpretación. El documento DEBE distinguir hechos, hipótesis, interpretaciones, opiniones institucionales y decisiones arquitectónicas.

Las expresiones DEBE, NO DEBE, DEBERÍA, NO DEBERÍA y PUEDE poseen intención normativa únicamente cuando aparecen en mayúsculas. Esta convención se alinea con BCP 14, integrado por RFC 2119 y RFC 8174. ^{[4, 3]}

El estado Stable identifica esta edición como proceso vigente. Toda modificación material de The Nebula RFC™ DEBE proponerse mediante un RFC posterior y preservar la versión sustituida.

---

#Prólogo

Las instituciones científicas y tecnológicas no fracasan únicamente por falta de ideas. También fracasan cuando las ideas se incorporan sin conservar supuestos, cuando las decisiones se confunden con preferencias de autoridad o cuando una implementación adquiere permanencia antes de haber sido evaluada.

En The Nebula Framework™, un cambio local puede alterar años de Evidence. Modificar una Observation afecta datasets y Scientific Models; cambiar un identificador puede romper genealogías; desplegar IA puede modificar quién decide y asume riesgo. La gestión informal funciona mientras pocos participantes comparten memoria, pero esa memoria no escala ni permite auditoría.

The Nebula RFC™ existe para convertir el cambio en conocimiento institucional.

La tradición de Internet ofrece un antecedente relevante. RFC 2026 describe un proceso donde las especificaciones atraviesan desarrollo, revisión, experiencia operacional y publicación, y caracteriza los Standards por estabilidad, competencia técnica, utilidad e interoperabilidad. ^[1] Nebula adopta esos principios sin reclamar equivalencia con el IETF.

El W3C aporta la obligación de preservar objeciones y proporcionar mecanismos formales de consideración y apelación. El W3C Process vigente desde el 18 de agosto de 2025 mantiene Formal Objections como parte explícita de su sistema decisorio. ^[5]

El proceso deberá evitar arbitrariedad y burocratización. Una corrección reversible no requiere el mismo expediente que una reforma científica o un sistema autónomo. La proporcionalidad permite mantener rigor sin bloquear exploración.

La aspiración final no es producir más documentos, sino preservar una Living Knowledge Infrastructure™ capaz de explicar qué cambió, por qué cambió, qué riesgos se aceptaron y qué Evidence podría exigir una revisión futura.

---

#Resumen Ejecutivo

The Nebula RFC™ establece el proceso oficial para proponer, revisar, validar, decidir, implementar y preservar cambios relevantes dentro del ecosistema Nebula.

Su problema central es la pérdida del razonamiento institucional. Conversaciones, prototipos o modificaciones de código pueden producir cambios reales sin conservar problema, alternativas, Evidence, riesgos, objeciones o criterios de retiro. El RFC transforma ese razonamiento en un Knowledge Object versionado y gobernado.

El modelo se fundamenta en ocho principios: todo cambio material se documenta; el problema precede a la solución; la Evidence precede a la aprobación; las alternativas se evalúan; compatibilidad y migración se diseñan; el desacuerdo se preserva; la decisión se registra; y la implementación no sustituye Governance.

El proceso se aplica a cambios científicos, semánticos, arquitectónicos, normativos, técnicos, económicos, operativos y territoriales. Las correcciones editoriales que no alteran significado, contratos o comportamiento pueden utilizar vías más ligeras. La clasificación considera alcance, reversibilidad, semántica, riesgo y permanencia.

El RFC es identificado, versionado y preservado con sus autores, revisores, Evidence, comentarios, decisiones, implementaciones y activos derivados. Sus estados distinguen elaboración, revisión, experimento, aceptación, implementación y Standardization.

La decisión buscará rough consensus informado. RFC 7282 explica que el consensus no se reduce a contar apoyos: los problemas deben ser tratados, aunque no todas las preferencias sean acomodadas. ^[2] Una mayoría no neutraliza una objeción material no resuelta y una objeción individual no concede veto automático.

La estructura mínima incluye problema, objetivos, no objetivos, propuesta, fundamento, alternativas, impacto, compatibilidad, migración, seguridad, privacidad, ética, propiedad intelectual, validación, implementación, retiro, preguntas abiertas e historial. El rigor se ajustará mediante vías abreviada, ordinaria y reforzada.

Los RFC arquitectónicos deberán identificar stakeholders, concerns y viewpoints, coherentemente con ISO/IEC/IEEE 42010:2022. ^[6] Los cambios técnicos deberán considerar desarrollo, operación, mantenimiento y retiro, en línea con la perspectiva de ciclo de vida de ISO/IEC/IEEE 15288:2023. ^[7]

El riesgo se integrará desde la formulación conforme al enfoque de ISO 31000:2018. ^[8] Los RFC de IA deberán incorporar Governance y mejora continua compatibles con ISO/IEC 42001:2023. ^[9]

El proceso será válido si reduce cambios silenciosos, mejora migraciones, permite reconstruir decisiones, preserva Evidence adversa y mantiene una velocidad proporcional al riesgo. Deberá revisarse si se convierte en ceremonia, concentra autoridad, excluye actores o documenta decisiones que ya fueron tomadas.

---

#Parte I — Naturaleza institucional del RFC

#1. El RFC como Knowledge Object

Un RFC es un objeto de conocimiento porque contiene una afirmación estructurada sobre cómo debería evolucionar el ecosistema. Relaciona un problema con una propuesta, Evidence, alternativas, riesgos y una decisión. Su utilidad continúa incluso después de ser rechazado: documenta qué se consideró, qué se aprendió y por qué una dirección no fue adoptada.

Conceptualmente, un RFC puede representarse como:

$$\mathcal{R} = \langle I,P,S,E,A,K,V,D,M,H \rangle,$$

donde:

• $I$ representa identidad;
• $P$ representa problema y propósito;
• $S$ representa solución propuesta;
• $E$ representa Evidence;
• $A$ representa alternativas;
• $K$ representa riesgos y consecuencias;
• $V$ representa validación;
• $D$ representa decisión;
• $M$ representa implementación y migración;
• $H$ representa historial.

La estructura no es una ecuación de decisión. Es una gramática mínima para impedir que el resultado quede separado de su razonamiento.

#2. Diferencia entre RFC, Standard y ADR

El RFC pregunta si y por qué un cambio debería adoptarse. Un Standard define qué requisitos deberá cumplir una familia de activos o implementaciones. Un Architectural Decision Record documenta cómo se resolvió una decisión concreta dentro de una Architecture.

Un RFC aceptado puede originar uno o varios Standards, ADR, experimentos, datasets, modelos o políticas. Ningún artefacto derivado deberá contradecir la decisión y las condiciones del RFC que lo originó. Cuando una implementación revele una contradicción material, el RFC deberá reabrirse o sustituirse.

#3. El RFC como frontera entre exploración y autoridad

Las ideas exploratorias podrán circular mediante notas, issues, discusiones o prototipos. Estas formas son valiosas, pero no poseen autoridad normativa. El cambio ocurre cuando la propuesta ingresa al proceso institucional y recibe identidad, revisión y decisión.

Esta frontera protege dos espacios. Protege la creatividad de una formalización prematura y protege al Framework de cambios adoptados únicamente porque ya fueron programados o financiados.

#4. Propósito de memoria institucional

The Nebula Library™ deberá preservar RFC aceptados, rechazados, retirados y sustituidos. La eliminación de un RFC rechazado destruiría Evidence sobre alternativas evaluadas y podría conducir a repetir errores.

La memoria no exige conservar indefinidamente cada conversación. Exige preservar suficiente contexto para comprender el problema, la decisión y los argumentos relevantes.

---

#Parte II — Autoridad, alcance y jerarquía

#5. Autoridad del proceso

The Nebula RFC™ deriva autoridad de The Nebula Constitution™, The Nebula Governance Model™ y The Nebula Standards™. El proceso no puede utilizarse para modificar un documento superior mediante una vía inferior. Las reformas constitucionales deberán seguir el procedimiento establecido por The Nebula Constitution™, aunque puedan utilizar un RFC como expediente técnico y deliberativo.

#6. Alcance material

Un RFC será obligatorio cuando un cambio pueda modificar de forma material:

• significado científico o epistemológico;
• Ontology, Knowledge Model o Knowledge Graph;
• Architecture, interfaces o contratos públicos;
• identidad, procedencia o Evidence;
• seguridad, privacidad o Trust Infrastructure;
• Scientific Models o sistemas de IA;
• Standards o criterios de conformidad;
• derechos, licencias o modelo económico;
• participación territorial;
• comportamiento de productos del ecosistema;
• capacidad de interpretar datos históricos.

La lista no es exhaustiva. El criterio principal es el impacto sobre significado, obligaciones, Interoperability, riesgo o memoria institucional.

#7. Cambios exentos

Generalmente no requieren RFC las correcciones tipográficas, enlaces, formato, ejemplos no normativos, refactorizaciones internas sin efectos observables y mantenimiento rutinario. La exención desaparece cuando un cambio editorial altera interpretación, una actualización de dependencia modifica comportamiento o una corrección interna afecta un contrato.

#8. Prueba de materialidad

Ante duda, se evaluarán cinco dimensiones:

Un cambio que alcance un nivel alto en cualquiera de estas dimensiones DEBERÍA ingresar al proceso RFC.

#9. Vías proporcionales

El proceso reconoce tres vías:

#Vía abreviada

Para cambios compatibles, reversibles y de bajo riesgo. Exige RFC conciso, revisión de dominio y registro de decisión.

#Vía ordinaria

Para cambios funcionales, semánticos o arquitectónicos de alcance moderado. Exige expediente completo, consulta y validación proporcional.

#Vía reforzada

Para reformas fundacionales, Standards raíz, Scientific Models de alto impacto, sistemas autónomos, cambios incompatibles, derechos territoriales o riesgos críticos. Exige revisión multidisciplinaria, periodo de consulta, Evidence independiente o implementación de referencia cuando corresponda y mecanismo explícito de apelación.

---

#Parte III — Principios del proceso

#10. El problema precede a la solución

Un RFC deberá comenzar con una descripción verificable del estado actual y de su insuficiencia. La disponibilidad de una tecnología no constituye un problema. «Adoptar blockchain», «usar inteligencia artificial» o «migrar a microservicios» son soluciones potenciales; no explican qué necesidad existe ni por qué la alternativa propuesta es adecuada.

El problema deberá declarar actores afectados, contexto, límites y Evidence. Cuando se trate de una oportunidad, deberá explicar qué capacidad se vuelve posible y por qué no puede alcanzarse con los mecanismos existentes.

#11. La Evidence precede a la aprobación

La cantidad y calidad de Evidence deberá corresponder con impacto e incertidumbre. Una propuesta experimental puede apoyarse en plausibilidad y establecer cómo generará Evidence. Una propuesta para modificar un Standard Stable deberá presentar experiencia, incidentes, benchmarks, análisis conceptual o implementaciones que demuestren la necesidad.

La ausencia de Evidence no siempre implica rechazo. Puede justificar estado Experimental con exposición limitada. No deberá justificar adopción permanente basada exclusivamente en confianza en el proponente.

#12. Las alternativas se hacen visibles

Todo RFC sustancial deberá incluir la opción de no cambiar. También deberá evaluar soluciones más simples, extensiones compatibles, adopción de Standards externos y separación del problema en varios RFC.

La comparación no exige un análisis cuantitativo artificial. Exige demostrar que las alternativas principales fueron comprendidas y que sus trade-offs se trataron con honestidad.

#13. La compatibilidad se diseña

La compatibilidad hacia atrás pregunta si los nuevos componentes pueden interpretar activos existentes. La compatibilidad hacia adelante pregunta si componentes antiguos pueden coexistir con nuevos activos o ignorar extensiones de forma segura.

Un cambio incompatible puede ser correcto. Sin embargo, deberá declarar motivo, versiones afectadas, periodo de coexistencia, herramientas, rollback y fecha de retiro. La incompatibilidad no deberá aparecer como descubrimiento posterior a la implementación.

#14. El desacuerdo se preserva

El consenso no requiere uniformidad. RFC 7282 distingue el tratamiento de problemas de la acomodación de todas las preferencias y advierte que contar apoyos no reemplaza el análisis de objeciones. ^[2]

Un RFC deberá conservar comentarios sustanciales, respuestas y objeciones formales. Cuando una decisión avance pese a una objeción, el registro deberá explicar por qué el riesgo se considera tratado, aceptado o fuera del alcance.

#15. La implementación no crea legitimidad por hecho consumado

Un prototipo puede demostrar viabilidad y descubrir ambigüedades. No puede convertir una propuesta en Standard simplemente porque ya existe o porque su costo hundido dificulta retirarla.

Las implementaciones anteriores a la decisión deberán marcarse como experimentales y no crear dependencia irreversible.

#16. La revisión es proporcional y competente

La revisión deberá ser realizada por personas capaces de evaluar el concern correspondiente. La autoridad jerárquica no sustituye competencia científica o técnica. Una propuesta puede necesitar revisores distintos para metodología, seguridad, Ontology, economía y participación territorial.

#17. La decisión es revisable

Toda aceptación deberá declarar condiciones de reapertura: nueva Evidence, incidentes, incumplimiento de métricas, cambio regulatorio, obsolescencia o aparición de una alternativa superior.

El conocimiento institucional no deberá confundir estabilidad con irreversibilidad.

#18. El proceso es accesible

La formalidad no deberá excluir a quienes poseen conocimiento relevante y menor experiencia documental. El Editor y los Stewards deberán ayudar a convertir una contribución en RFC sin apropiarse de autoría ni alterar su intención.

---

#Parte IV — Tipología de RFC

#19. RFC de Research

Formula una hipótesis, método, diseño experimental, Scientific Model o agenda de investigación. Deberá declarar pregunta, variables, controles, datos, incertidumbre, criterios de validación y condiciones de refutación.

Su aceptación puede autorizar investigación sin declarar válidos sus resultados.

#20. RFC semántico

Modifica The Nebula Ontology™, vocabularios, mappings, clases, propiedades o restricciones. Deberá evaluar definición, identidad, dominio, rango, cardinalidad, ejemplos, competencia questions, consultas afectadas y migración de grafos.

Un RFC semántico NO DEBE utilizar owl:sameAs para relaciones de similitud o correspondencia parcial.

#21. RFC de Architecture and Systems

Modifica componentes, servicios, flujos, deployment, almacenamiento, resiliencia u observabilidad. Deberá identificar stakeholders, concerns y viewpoints afectados, coherentemente con el enfoque de Architecture Description de ISO/IEC/IEEE 42010:2022. ^[6]

Deberá evaluar calidad, seguridad, capacidad, fallo, costo, operación, mantenimiento y retiro.

#22. RFC de Standards and Interoperability

Propone o modifica requisitos normativos. Deberá definir alcance, lenguaje normativo, contratos, conformidad, implementaciones, seguridad, privacidad, IPR, compatibilidad y mantenimiento.

La experiencia del IETF muestra que la madurez de un Standard depende de revisión, competencia técnica, utilidad y experiencia interoperable, no solo de publicación. ^[1]

#23. RFC de Data, Observation and Evidence

Modifica schemas, unidades, calidad, procedencia, retención, datasets, Observation o Evidence. Deberá conservar derivación y evaluar cómo el cambio afecta resultados históricos y Scientific Models.

#24. RFC de API, Event and Integration

Modifica interfaces públicas, mensajes, eventos, autenticación, errores, límites, contratos o políticas de retiro. Deberá incluir ejemplos, pruebas de contrato, idempotencia cuando corresponda y análisis de consumidores.

#25. RFC de AI and Scientific Models

Propone entrenamiento, evaluación, despliegue, actualización o retiro de modelos. Deberá incluir Model Card, datos, métricas, sesgos, incertidumbre, Context of Use, supervisión, monitoreo y rollback.

ISO/IEC 42001:2023 establece requisitos para implantar y mejorar un AI Management System. ^[9] El RFC deberá integrarse con esa orientación de ciclo de vida y no limitarse al desempeño inicial.

#26. RFC de Security, Privacy and Trust

Modifica identidad, autorización, cifrado, credenciales, Originblok®, Proof of Process™, datos sensibles o respuesta a incidentes. Requiere revisión especializada y, cuando sea necesario, una sección confidencial separada de la especificación pública.

#27. RFC institucional, económico y territorial

Modifica Governance, licencias, colaboración, modelo económico, distribución de valor, acceso o derechos territoriales. Deberá evaluar actores afectados, asimetrías de poder, participación, beneficios, riesgos y mecanismos de apelación.

#28. RFC Experimental

Autoriza una prueba limitada. Deberá declarar duración, población, entorno, exposición, métricas, seguridad, criterios de éxito, stop conditions y destino de los datos. El estado Experimental NO DEBE interpretarse como aprobación general.

mindmap
  root((Familias RFC))
    Research
      Hipótesis
      Experimentos
      Scientific Models
    Semantics
      Ontology
      Vocabulary
      Knowledge Graph
    Architecture
      Components
      Interfaces
      Resilience
    Standards
      Requirements
      Conformance
      Interoperability
    Data and Evidence
      Observation
      Dataset
      Provenance
    AI
      Evaluation
      Monitoring
      Withdrawal
    Trust
      Security
      Privacy
      Proof of Process™
    Institution
      Governance
      Economy
      Territory

---

#Parte V — Identidad, metadatos y versionado

#29. Identificador institucional

Todo RFC oficial DEBE poseer un identificador persistente con el patrón:

NBL-RFC-NNN

El número tendrá un mínimo de tres dígitos y podrá expandirse cuando la secuencia lo requiera. Los identificadores se asignarán secuencialmente y NO DEBEN reutilizarse, incluso cuando una propuesta sea retirada o rechazada.

El documento NBL-RFC-001 define el proceso y ocupa legítimamente el primer identificador de la familia. Los RFC posteriores comenzarán en NBL-RFC-002.

El identificador representa la continuidad intelectual de la propuesta. Una revisión del mismo RFC conserva el identificador e incrementa su versión. Una propuesta sustancialmente diferente DEBE recibir un identificador nuevo y relacionarse mediante supersedes, derivedFrom o la relación aplicable.

#30. Metadatos mínimos

Todo RFC DEBE incluir YAML Frontmatter conforme con The Nebula Standards™ y, adicionalmente, metadatos capaces de resolver:

• dominio principal;
• vía del proceso;
• responsables de dominio;
• revisores requeridos;
• activos afectados;
• dependencia de otros RFC;
• estado de IPR;
• clasificación de acceso;
• fecha de consulta;
• Decision Record final.

Estos metadatos podrán implementarse mediante campos adicionales o registros vinculados en The Nebula Library™. No todos deberán aparecer necesariamente en el YAML del documento cuando exista un registro institucional resoluble.

#31. Versionado

El RFC utilizará versionado semántico MAJOR.MINOR.PATCH.

Una versión 0.x.y identifica elaboración anterior a la aceptación. La versión 1.0.0 podrá asignarse cuando la propuesta alcance su primera decisión estable o cuando un documento institucional, como NBL-RFC-001, entre en vigor.

Un cambio MAJOR modifica sustancialmente la solución, alcance o compatibilidad. Un cambio MINOR amplía o ajusta la propuesta sin alterar su intención fundamental. Un cambio PATCH corrige errores editoriales o aclaraciones que no modifican significado.

La versión evaluada por el órgano decisor DEBE quedar congelada en el Decision Record. Las ediciones posteriores no deberán reescribir silenciosamente aquello que fue aprobado o rechazado.

#32. Historial de revisión

El historial deberá registrar fecha, versión, autor del cambio, secciones afectadas y motivo. Las respuestas a comentarios sustanciales deberán vincularse con la versión que las resolvió.

Un sistema de control de versiones puede preservar diferencias técnicas, pero no sustituye un historial editorial comprensible. El commit describe qué cambió; el RFC deberá explicar por qué.

---

#Parte VI — Ciclo de vida

#33. Estados canónicos

#Draft

La propuesta se encuentra en elaboración. Puede cambiar de manera sustancial y no posee autoridad institucional.

#Submitted

El Editor confirmó integridad mínima, asignó identidad y registró la propuesta.

#Triaged

La propuesta fue clasificada por dominio, impacto, vía, revisores y conflictos aparentes.

#Under Review

Se encuentra bajo revisión sustantiva o consulta.

#Revision Required

No puede avanzar sin cambios o Evidence adicional. Este estado no constituye rechazo.

#Candidate

La propuesta se considera suficientemente madura para validación final, experimento, implementación de referencia o decisión.

#Experimental

Se autorizó una aplicación limitada bajo condiciones explícitas.

#Accepted

La propuesta fue aprobada en el alcance indicado.

#Conditionally Accepted

Fue aprobada bajo obligaciones pendientes que impiden considerarla implementada o estandarizada.

#Implemented

La decisión fue materializada y vinculada con los activos correspondientes.

#Standardized

La propuesta originó o modificó un Standard oficial que completó sus requisitos de conformidad.

#Rejected

El órgano competente decidió no adoptar la propuesta. El RFC y la justificación se preservan.

#Withdrawn

Los autores retiraron la propuesta antes de una decisión final.

#Superseded

Otro RFC reemplazó su propósito o solución.

#Deprecated

Continúa siendo interpretable, pero no se recomienda para nuevos usos.

#Archived

Se conserva como memoria institucional sin actividad vigente.

#34. Transiciones

stateDiagram
    [*] --> Draft
    Draft --> Submitted: validación editorial
    Submitted --> Triaged: clasificación
    Triaged --> UnderReview: revisores asignados
    UnderReview --> RevisionRequired: cambios necesarios
    RevisionRequired --> UnderReview: nueva versión
    UnderReview --> Candidate: revisión suficiente
    Candidate --> Experimental: Evidence requerida
    Experimental --> Candidate: resultados evaluados
    Candidate --> Accepted: aprobación
    Candidate --> ConditionallyAccepted: obligaciones pendientes
    ConditionallyAccepted --> Accepted: condiciones cumplidas
    Candidate --> Rejected: decisión negativa
    Draft --> Withdrawn
    Submitted --> Withdrawn
    UnderReview --> Withdrawn
    Accepted --> Implemented
    Implemented --> Standardized
    Accepted --> Superseded
    Implemented --> Superseded
    Standardized --> Deprecated
    Rejected --> Archived
    Withdrawn --> Archived
    Superseded --> Archived
    Deprecated --> Archived
    Standardized --> [*]

No todas las propuestas atravesarán todos los estados. Un RFC informativo aceptado puede no generar implementación. Un RFC experimental puede finalizar como Rejected si los resultados contradicen su hipótesis.

#35. Separación entre estado y versión

El estado expresa posición en el proceso. La versión expresa evolución del contenido. Un RFC puede permanecer Under Review a través de varias versiones. Cambiar de estado no requiere necesariamente una versión nueva si el contenido no cambió, pero la decisión de estado DEBE registrarse.

---

#Parte VII — Roles y responsabilidades

#36. Proponente

Formula el problema, prepara el RFC, declara supuestos y conflictos, responde comentarios y colabora con validación. Puede ser una persona, equipo, universidad, organización territorial o working group. No posee derecho automático a aprobación.

#37. RFC Editor

Administra integridad documental, identidad, metadatos, estados, publicación e historial. Puede devolver una propuesta por defectos editoriales, pero no sustituye revisión sustantiva.

#38. Domain Steward

Custodia coherencia dentro del dominio, identifica dependencias, revisores y Standards afectados. Stewardship no constituye veto personal.

#39. Reviewer

Evalúa concerns específicos y declara competencia, limitaciones y conflictos. Su responsabilidad es mejorar la calidad de la decisión.

#40. Conformance Lead y Evidence Custodian

El Conformance Lead verifica que los requisitos sean comprobables. El Evidence Custodian preserva datasets, benchmarks, actas y resultados, garantizando identidad y procedencia, no validez científica por sí solo.

#41. Decision Authority

Adopta la decisión final dentro de una competencia delegada y verifica proceso, Evidence, riesgos, objeciones y condiciones. No deberá presentar como consensus una decisión ejecutiva.

#42. Territorial Representative

Participa cuando el RFC afecta datos, prácticas, identidad, Digital Terroir®, distribución de valor o condiciones territoriales. Su intervención deberá ser material, no simbólica.

#43. Implementer, Secretariat y Library Steward

El Implementer ejecuta la decisión y reporta desviaciones. La Secretaría coordina plazos y Decision Records. El Library Steward preserva el expediente.

#44. Separación de funciones

En una etapa inicial, una persona puede desempeñar varios roles, pero la acumulación DEBE declararse. Las decisiones de alto impacto requieren mitigaciones como revisión independiente, recusación o pruebas externas.

---

#Parte VIII — Estructura obligatoria de un RFC

#47. Núcleo documental

Todo RFC ordinario o reforzado DEBE incluir las secciones siguientes, adaptadas a su dominio:

1. Resumen: problema, propuesta y resultado esperado.
2. Motivación: contexto y necesidad.
3. Definición del problema: estado actual, Evidence y actores afectados.
4. Objetivos: resultados verificables.
5. No objetivos: exclusiones deliberadas.
6. Propuesta: cambio completo.
7. Fundamento: base científica, técnica, institucional o territorial.
8. Alternativas: incluida la ausencia de cambio.
9. Impacto: activos, actores, costos y consecuencias.
10. Compatibilidad: hacia atrás, hacia adelante y semántica.
11. Migración: coexistencia, herramientas, rollback y retiro.
12. Seguridad: amenazas y controles.
13. Privacidad: propósito, minimización, acceso y retención.
14. Ética e impacto social: derechos, equidad y consecuencias.
15. Propiedad intelectual: licencias, patentes y restricciones.
16. Validación: pruebas, experimentos y criterios.
17. Implementación: etapas, responsables y dependencias.
18. Estrategia de retiro: condiciones y preservación.
19. Preguntas abiertas: incertidumbres no resueltas.
20. Historial: versiones y respuesta a comentarios.

La vía abreviada podrá condensar estas secciones, pero NO DEBE omitir un concern relevante únicamente para reducir longitud.

#48. Calidad del problema

Una buena definición del problema deberá permitir que un revisor acepte la existencia del problema aunque discrepe de la solución. Si problema y solución están formulados de manera inseparable, el RFC probablemente oculta supuestos.

#49. Objetivos y no objetivos

Los objetivos deberán ser observables. «Modernizar la plataforma» es una intención vaga. «Permitir que dos implementaciones independientes intercambien Biological Trajectories sin pérdida de procedencia» constituye un objetivo comprobable.

Los no objetivos protegen alcance y evitan que la evaluación exija resolver todo el dominio.

#50. Alternativas

La sección deberá explicar por qué una alternativa no fue seleccionada, no construir versiones débiles para justificar la preferida. Cuando dos alternativas permanezcan razonables, el RFC podrá proponer un experimento comparativo.

#51. Impacto

El impacto deberá incluir efectos directos e indirectos sobre documentos, datos, modelos, usuarios, costos, operación, seguridad, conocimiento territorial y ambiente cuando corresponda.

#52. Preguntas abiertas

Un RFC no necesita responder todo antes de presentarse. Sin embargo, deberá identificar qué preguntas pueden resolverse durante revisión y cuáles impiden la decisión. Una pregunta abierta crítica no deberá ocultarse como trabajo futuro.

---

#Parte IX — Preparación, presentación y triage

#53. Preparación previa

Antes de presentar, los autores DEBERÍAN revisar The Nebula Library™, consultar Standards y RFC anteriores, identificar responsables y verificar que el problema no haya sido resuelto. La consulta temprana reduce duplicación, pero no deberá convertirse en aprobación privada previa al proceso.

#54. Presentación

El RFC se presenta mediante el repositorio o canal oficial. El Editor verifica YAML, identificador, versión, estructura, legibilidad, licencia, relaciones y ausencia de información secreta publicada indebidamente.

La revisión editorial no evalúa si la propuesta es correcta. Evalúa si puede ser revisada.

#55. Triage

El triage determina:

• dominio principal y dominios secundarios;
• vía abreviada, ordinaria o reforzada;
• revisores y stakeholders;
• periodo de consulta;
• necesidad de experimento;
• clasificación de acceso;
• riesgos iniciales;
• conflicto o duplicación con trabajos existentes.

La decisión de triage deberá ser apelable cuando reduzca participación, Evidence o rigor de forma material.

#56. Rechazo editorial

Un RFC puede devolverse antes de Submitted por estar incompleto, ser ininteligible, duplicar exactamente una propuesta vigente o contener información cuya publicación crearía un riesgo. La devolución editorial no constituye rechazo de mérito y deberá indicar cómo corregir.

---

#Parte X — Revisión y comentarios

#57. Revisión multidisciplinaria

La revisión deberá cubrir los concerns relevantes y no todas las disciplinas por rutina. Un cambio de formato documental puede requerir revisión editorial y de Interoperability. Un modelo que automatiza una intervención puede requerir revisión científica, matemática, de IA, seguridad, operación y territorio.

#58. Tipos de comentarios

Los comentarios podrán clasificarse como:

• Blocking: identifica un riesgo o contradicción que impide avanzar.
• Substantive: modifica alcance, diseño o fundamento.
• Conformance: identifica incumplimiento de Standard.
• Security or Privacy: identifica amenaza o vulneración.
• Editorial: mejora claridad sin modificar significado.
• Question: solicita información necesaria.
• Suggestion: propone una mejora opcional.
• Minority Position: preserva una alternativa razonada.

La etiqueta Blocking no otorga veto automático. El Chair o responsable de revisión deberá confirmar que el problema es material y dentro de alcance.

#59. Calidad de comentarios

Un comentario deberá señalar sección, problema, consecuencia y, cuando sea posible, una propuesta de resolución. Los ataques personales, argumentos de autoridad y preferencias sin relación con requisitos no deberán determinar la decisión.

#60. Respuesta de autores

Los autores podrán aceptar, aceptar parcialmente, rechazar con justificación, solicitar aclaración o diferir a otro RFC. Toda respuesta sustancial deberá quedar visible.

El proceso no exige que los autores convenzan a todos. Exige que los problemas sean comprendidos y tratados.

#61. Periodos de revisión

Los periodos deberán corresponder con complejidad y disponibilidad de stakeholders. Una consulta demasiado breve puede producir silencio artificial. Una consulta indefinida puede bloquear cambio.

El charter o Decision Authority podrá establecer plazos y extensiones justificadas. Los cambios urgentes utilizarán la vía de emergencia y revisión posterior, no una consulta ficticia.

#62. Revisión externa

Las propuestas científicas, criptográficas, regulatorias o de alto impacto DEBERÍAN buscar revisión externa cuando la competencia interna sea insuficiente o exista un conflicto institucional significativo.

La ausencia de respuesta externa no deberá presentarse como endorsement.

sequenceDiagram
    participant P as Proponente
    participant E as RFC Editor
    participant S as Domain Steward
    participant R as Reviewers
    participant C as Stakeholders
    participant D as Decision Authority

    P->>E: Submit RFC version
    E->>S: Triage request
    S->>R: Assign concerns
    S->>C: Open consultation
    R-->>P: Structured comments
    C-->>P: Objections and feedback
    P->>R: Responses and revision
    R->>D: Review disposition
    S->>D: Impact and governance summary
    D-->>E: Decision Record
    E-->>C: Publish outcome and rationale

---

#Parte XI — Consensus, dissent y apelación

#63. Consensus informado

Nebula favorecerá rough consensus informado. El objetivo no es medir entusiasmo, sino determinar si los problemas relevantes han sido identificados y tratados. RFC 7282 señala que una mayoría numérica no garantiza consensus y que el proceso debe concentrarse en las razones del desacuerdo. ^[2]

#64. Unanimidad y votación

La unanimidad no será requisito general porque concede veto permanente y puede ocultar presión social. La votación podrá utilizarse cuando el charter la exija, cuando las alternativas sean equivalentes o cuando el órgano necesite adoptar una decisión administrativa después de tratar los argumentos.

El resultado de una votación deberá registrar abstenciones, recusaciones y posiciones minoritarias. No deberá presentarse el porcentaje de votos como Evidence científica.

#65. Lazy consensus

El lazy consensus podrá utilizarse para cambios de bajo impacto cuando exista notificación, plazo y mecanismo claro de objeción. El silencio no deberá interpretarse como aceptación en decisiones de alto impacto, cuando stakeholders carecieron de acceso o cuando el periodo fue insuficiente.

#66. Formal Objection

Una Formal Objection deberá declarar:

• decisión o propuesta cuestionada;
• naturaleza técnica, científica, procedimental o ética;
• rationale;
• Evidence;
• consecuencia prevista;
• cambio capaz de resolverla.

El W3C Process 2025 exige consideración y respuesta formal a este tipo de objeciones y permite apelaciones de decisiones de proceso. ^[5] Nebula adopta esa disciplina sin replicar la estructura del W3C Council.

#67. Resolución de objeciones

La autoridad podrá:

• aceptar la objeción y modificar la propuesta;
• aceptarla parcialmente;
• declarar que el riesgo fue mitigado;
• aceptar conscientemente el riesgo;
• determinar que se encuentra fuera de alcance;
• devolver el RFC;
• rechazar la objeción con rationale.

La respuesta deberá ser pública dentro del nivel de acceso aplicable.

#68. Minority Report

Una posición minoritaria técnicamente razonada podrá publicarse junto al Decision Record. Su propósito es preservar conocimiento, facilitar revisión futura y evitar que el documento final produzca una falsa apariencia de unanimidad.

#69. Apelación

La apelación examina debido proceso, competencia, conflicto de interés, tratamiento de Evidence, proporcionalidad y coherencia con documentos superiores. No constituye una repetición ilimitada de argumentos ya tratados.

Una apelación DEBERÁ aportar nueva información, identificar un defecto material de proceso o demostrar que la decisión contradice una autoridad superior.

---

#Parte XII — Validación e implementación de referencia

#70. Principio de validación proporcional

La validación responde a la pregunta: ¿qué Evidence sería suficiente para justificar el alcance solicitado? Un RFC editorial puede validarse mediante revisión y renderizado. Un RFC de algoritmo requiere datasets, baselines y métricas. Un RFC de Standard necesita implementaciones o pruebas de conformidad.

#71. Implementación de referencia

Una implementación de referencia puede demostrar viabilidad, descubrir ambigüedades y facilitar adopción. No deberá convertirse en la única implementación legítima cuando el RFC declara Interoperability.

La separación entre especificación e implementación es esencial para evitar que detalles accidentales adquieran fuerza normativa.

#72. Prototipo y producción

El prototipo responde si algo puede funcionar bajo condiciones controladas. La validación operacional responde si funciona con usuarios, fallos, carga, seguridad y mantenimiento reales.

Un RFC NO DEBE utilizar éxito de laboratorio como Evidence suficiente para despliegue general cuando las condiciones difieren materialmente.

#73. Validación científica

Los RFC científicos deberán declarar hipótesis, variables, muestra, controles, procedimiento, análisis, incertidumbre, criterios de éxito y refutación. Los resultados negativos y anomalías deberán preservarse.

#74. Interoperability testing

Un RFC que define intercambio DEBERÍA demostrar al menos dos implementaciones o herramientas independientes cuando el costo y madurez lo permitan. La conformidad no deberá evaluarse únicamente contra la implementación del autor.

#75. Security validation

La validación puede incluir threat modeling, pruebas de abuso, revisión criptográfica, análisis de dependencia, penetration testing y recuperación. El RFC deberá declarar qué pruebas son requisitos de aceptación y cuáles permanecen como monitoreo.

#76. Reproducibilidad

El expediente deberá permitir reconstruir datos, código, entorno, parámetros y resultados relevantes. La reproducibilidad no exige publicar información restringida; exige preservar y hacerla accesible a revisores autorizados.

---

#Parte XIII — Decisión

#77. Criterios de aceptación

Un RFC podrá aceptarse cuando:

• el problema sea material y esté suficientemente definido;
• la propuesta sea coherente con documentos superiores;
• las alternativas principales hayan sido evaluadas;
• la Evidence sea proporcional al riesgo;
• las objeciones materiales hayan sido tratadas;
• la compatibilidad y migración sean defendibles;
• exista capacidad razonable de implementación y mantenimiento;
• los derechos y riesgos sean aceptables;
• se encuentren definidos monitoreo y retiro.

La aceptación no exige demostrar perfección. Exige que las incertidumbres residuales sean visibles y gobernables.

#78. Aceptación condicionada

Las condiciones deberán indicar tarea, responsable, plazo o evento, alcance permitido y criterio de cierre. Una condición indefinida convierte la aceptación en ambigua y NO DEBE utilizarse.

#79. Rechazo

El rechazo deberá explicar qué impide la adopción. Las razones pueden incluir problema no demostrado, contradicción superior, riesgo desproporcionado, falta de Evidence, duplicación, incompatibilidad injustificada, ausencia de derechos o inviabilidad.

Un rechazo no declara que la idea sea falsa para siempre. Una propuesta revisada puede recibir un nuevo identificador cuando cambie sustancialmente.

#80. Decision Record

Toda decisión final DEBE incluir:

• RFC e identidad de versión;
• autoridad y participantes;
• conflictos y recusaciones;
• estado resultante;
• resumen de Evidence;
• argumentos principales;
• objeciones y respuestas;
• condiciones;
• activos afectados;
• fechas de vigencia y revisión;
• próximos pasos.

#81. Firma y autenticidad

El Decision Record podrá utilizar firmas digitales, hashes y sellado temporal. Estos mecanismos prueban integridad o autoría según su diseño; no prueban que la decisión sea científicamente correcta.

---

#Parte XIV — Implementación, migración y retiro

#82. Plan de implementación

La implementación deberá traducir la decisión en entregables, responsables, dependencias, pruebas, comunicación y operación. Las desviaciones materiales respecto al RFC deberán generar un ADR, enmienda o nuevo RFC según impacto.

#83. Ciclo de vida del sistema

Los cambios técnicos deberán considerar desarrollo, transición, operación, mantenimiento y retiro. ISO/IEC/IEEE 15288:2023 define procesos de ciclo de vida que facilitan desarrollo e intercambio de información entre stakeholders sin imponer una metodología única. ^[7] El RFC podrá mapear sus actividades a estos procesos cuando aporte claridad.

#84. Migración

El plan deberá identificar fuentes, destinos, transformaciones, validación, coexistencia, rollback y tratamiento de fallos. Las transformaciones de datos y grafos deberán preservar procedencia y declarar pérdidas inevitables.

#85. Deprecación

La deprecación deberá anunciar sustituto, periodo, soporte, impacto y fecha de revisión. Un activo deprecado no deberá desaparecer mientras sea necesario para interpretar decisiones históricas.

#86. Retiro

El retiro termina el uso activo, no necesariamente la preservación. The Nebula Library™ deberá conservar versiones y documentación necesarias para Temporal Evolution.

#87. Monitoreo posterior

El RFC deberá establecer indicadores y condiciones de reapertura. Una decisión aceptada puede ser posteriormente restringida o retirada si la Evidence operacional contradice sus supuestos.

---

#Parte XV — Riesgo, seguridad, privacidad y ética

#88. Risk Governance

El riesgo deberá integrarse durante todo el proceso. ISO 31000:2018 describe un enfoque de identificación, análisis, evaluación, tratamiento, monitoreo y comunicación. ^[8] El RFC deberá distinguir riesgos inherentes, controles y riesgos residuales.

#89. Seguridad

Los RFC deberán considerar identidad, autenticación, autorización, confidencialidad, integridad, disponibilidad, claves, supply chain, auditabilidad, resiliencia y respuesta a incidentes según el dominio.

La sección de seguridad no deberá limitarse a declarar «sin consideraciones conocidas». Cuando los autores no posean competencia suficiente, deberán solicitar revisión.

#90. Privacidad

Las propuestas que procesen información de personas, organizaciones o ubicaciones deberán evaluar finalidad, minimización, acceso, retención, eliminación, transferencias y riesgo de reidentificación. El acceso técnico posible no equivale a uso legítimo.

#91. Ética e impacto social

Los RFC deberán considerar asimetrías de poder, exclusión, automatización, dependencia, explicabilidad, distribución de beneficios, conocimiento local y consecuencias no intencionales.

Un análisis ético no deberá reducirse a cumplimiento legal. Una práctica puede ser legal y contradecir The Nebula Constitution™ o la misión institucional.

#92. Propiedad intelectual

Los autores y participantes deberán declarar patentes, licencias, secretos, restricciones contractuales y derechos de terceros. La aprobación de un RFC no concede automáticamente derechos para implementar.

Cuando un Standard dependa de tecnología restringida, el RFC deberá evaluar alternativas, términos y efecto sobre Interoperability.

#93. Conflictos de interés

Los conflictos financieros, académicos, de autoría, proveedor, territorio o propiedad deberán declararse. La mitigación puede incluir recusación, revisión independiente, publicación o limitación de autoridad.

---

#Parte XVI — Decisiones de emergencia

#94. Naturaleza

Una emergencia puede requerir suspender un servicio, retirar un modelo, bloquear acceso o modificar un control antes de completar el proceso ordinario. La velocidad no elimina Governance; cambia su secuencia.

#95. Requisitos

Toda decisión de emergencia DEBE:

• responder a un riesgo inmediato o material;
• limitarse al alcance y duración necesarios;
• identificar autoridad;
• preservar Evidence;
• registrar acciones;
• establecer expiración;
• iniciar revisión posterior;
• convertirse en RFC o revertirse.

#96. Prohibición de permanencia silenciosa

Una medida temporal NO DEBE transformarse en política estable por inercia. Si continúa siendo necesaria después de la emergencia, deberá completar el proceso ordinario.

#97. Post-incident review

La revisión deberá reconstruir timeline, causas, decisiones, efectos, controles y aprendizajes. El RFC resultante puede modificar Architecture, Standard o procedimiento.

---

#Parte XVII — The Nebula Library™ y memoria institucional

#98. Expediente completo

The Nebula Library™ deberá registrar:

• RFC y versiones;
• metadatos;
• autores y revisores;
• comentarios y respuestas;
• Formal Objections;
• Evidence packages;
• Decision Records;
• implementaciones;
• Standards y ADR derivados;
• métricas y revisiones posteriores.

#99. Propuestas rechazadas

Las propuestas rechazadas forman parte de la memoria porque permiten comprender alternativas y riesgos. Su preservación deberá respetar privacidad, secretos y retención proporcional.

#100. Resolución persistente

Los identificadores deberán continuar resolviendo aunque cambie el repositorio. Una ubicación de archivo no constituye identidad institucional.

#101. Publicación y acceso

El RFC debería ser tan abierto como sea compatible con derechos, seguridad y confidencialidad. Las secciones restringidas deberán separarse cuando sea posible para permitir revisión amplia del núcleo no sensible.

#102. Integridad

The Nebula Library™ podrá calcular checksums, firmas y timestamps para demostrar integridad. Originblok® podrá registrar relaciones de procedencia y Proof of Process™ del expediente de decisión.

---

#Parte XVIII — Métricas y evaluación del proceso

#103. Principio

Las métricas deberán evaluar calidad del proceso y resultados, no volumen documental. Un alto número de RFC puede indicar innovación o fragmentación. Un alto porcentaje de aceptación puede indicar claridad o falta de crítica.

#104. Indicadores

#105. Antimétricas

No deberán utilizarse aisladamente:

• cantidad de RFC producidos;
• porcentaje de aceptación;
• velocidad total sin clasificación de impacto;
• número de comentarios;
• porcentaje de unanimidad;
• número de páginas.

Estas cifras pueden incentivar propuestas fragmentadas, revisión superficial o consenso aparente.

#106. Revisión periódica del proceso

The Nebula RFC™ DEBERÍA revisarse mediante Evidence sobre demoras, participación, errores, adopción, conflictos y mantenimiento. El proceso deberá simplificarse cuando su costo no contribuya a decisiones mejores.

---

#Parte XIX — Casos de uso

#107. Nueva clase ontológica

Un equipo propone FermentationRegime. El RFC semántico define competencia questions, alternativas, ejemplos, relación con Process State y migración. La existencia de un nodo implementado no basta para aprobar la clase.

#108. Nuevo sensor

FermentOps® incorpora un sensor de ORP. Si utiliza contratos existentes, puede no requerir RFC. Si modifica el modelo de Observation o el esquema público, requiere RFC de Data and Evidence.

#109. Modelo predictivo

Un modelo predice finalización de fermentación. El RFC declara datos, baselines, calibración, errores, Context of Use, supervisión y retirada. La aceptación puede limitarlo a recomendación y prohibir control automático.

#110. Cambio incompatible de API

Una API reemplaza identificadores de Lot. El RFC analiza consumidores, mapping, coexistencia y genealogía. Sin migración defendible, el cambio deberá rediseñarse.

#111. Originblok® y blockchain

El RFC comienza por el modelo de confianza y demuestra por qué una base convencional con firmas no resuelve el problema. Blockchain es una alternativa de implementación, no el objetivo.

#112. Objeción territorial y emergencia

La reutilización comercial de datos de Digital Terroir® requiere revisión territorial, económica y de derechos. En una emergencia de seguridad, una acción temporal puede preceder al RFC, pero deberá registrarse, expirar y someterse a revisión posterior.

---

#Parte XX — Validación y refutación de The Nebula RFC™

#114. Hipótesis del proceso

The Nebula RFC™ se apoya en la hipótesis de que documentar problema, Evidence, alternativas, revisión y decisión mejora la calidad, continuidad y legitimidad del cambio.

#115. Validación

La hipótesis podrá evaluarse comparando periodos o proyectos mediante:

• número de cambios silenciosos;
• defectos de migración;
• capacidad de reconstrucción;
• tiempo proporcional por clase;
• satisfacción de participantes;
• diversidad de revisión;
• incidencias posteriores;
• reutilización de argumentos y Evidence.

#116. Pruebas de proceso

Podrán realizarse simulaciones de RFC sobre un cambio conocido, auditorías de expedientes, ejercicios de apelación, recuperación de versiones y revisión externa.

#117. Condiciones de refutación

El proceso deberá revisarse si:

1. los RFC se redactan después de decidir;
2. la Evidence no cambia decisiones;
3. las objeciones se preservan pero no reciben consideración real;
4. la vía ordinaria bloquea cambios simples;
5. la vía abreviada permite eludir revisión material;
6. los actores territoriales carecen de influencia;
7. las implementaciones continúan divergiendo de lo aprobado;
8. la Library no permite reconstruir versiones;
9. los autores evitan el proceso mediante cambios fragmentados;
10. el costo documental supera persistentemente el valor de aprendizaje;
11. la autoridad utiliza consensus para ocultar decisiones ejecutivas;
12. el proceso desalienta contribuciones externas legítimas.

La refutación de una etapa no invalida necesariamente el principio de RFC. Puede exigir rediseñar triage, revisión, autoridad o herramientas.

---

#Parte XXI — Limitaciones

La primera limitación es cultural. Ningún proceso obliga a actuar con honestidad cuando los incentivos premian ocultar riesgos.

La segunda es documental. Un RFC puede ser completo y continuar siendo incorrecto.

La tercera es temporal. La revisión rigurosa consume tiempo y puede entrar en tensión con oportunidades o emergencias.

La cuarta es de competencia. Un ecosistema pequeño puede carecer de revisores independientes para todos los dominios.

La quinta es de participación. La publicación no garantiza que stakeholders comprendan o puedan influir.

La sexta es de poder. La autoridad puede utilizar el proceso para legitimar decisiones previamente tomadas.

La séptima es de información. Algunas propuestas contienen secretos, datos personales o vulnerabilidades que limitan revisión pública.

La octava es económica. Preparar Evidence, prototipos y migraciones requiere recursos desiguales.

La novena es técnica. Las plataformas de colaboración pueden condicionar quién participa y cómo se preserva la discusión.

La décima es epistemológica. El consenso puede seleccionar una alternativa útil sin demostrar que sus afirmaciones sean verdaderas.

La undécima es de escala. Un proceso apropiado para decenas de participantes puede requerir federación cuando el ecosistema crezca.

La duodécima es de automatización. Los validadores pueden verificar estructura y no calidad del razonamiento.

---

#Parte XXII — Agenda de evolución

#118. Machine-readable RFC

Desarrollar un esquema semántico para propuestas, comentarios, Evidence, decisiones y estados, alineado con The Nebula Ontology™ y PROV-O.

#119. Automated conformance

Crear validadores de YAML, estructura, enlaces, versión, terminología y requisitos de dominio, evitando confundir conformidad formal con aprobación.

#120. Federated review

Diseñar mecanismos para revisión entre universidades, organizaciones territoriales y socios sin centralizar toda la información.

#121. Evidence envelopes

Formalizar paquetes portables vinculados con Originblok® y Proof of Process™.

#122. Deliberation analytics

Investigar métricas para detectar comentarios no resueltos, concentración de participación y demoras, sin automatizar decisiones sustantivas.

#123. Multilingual governance

Desarrollar traducciones vinculadas al mismo identificador y mecanismos para resolver discrepancias entre idioma canónico y traducciones.

#124. Confidential review

Definir perfiles para seguridad, patentes y datos sensibles que preserven debido proceso y publicación parcial.

#125. Territorial participation

Desarrollar métodos accesibles para que Caficultores y organizaciones territoriales presenten, revisen y apelen RFC.

#126. AI-assisted RFC

Evaluar IA para detectar contradicciones, dependencias y requisitos omitidos. Sus salidas deberán ser sugerencias verificables; la autoridad no se delegará al modelo.

#127. Appeals and constitutional review

Formalizar plazos, instancias y efectos de apelación conforme madure The Nebula Governance Model™.

timeline
    title Agenda de evolución de The Nebula RFC™
    Fase I : Registro canónico
           : Plantillas y validación editorial
           : Decision Records
    Fase II : Pruebas de conformidad
            : Evidence envelopes
            : Integración con The Nebula Library™
    Fase III : Revisión federada
             : Participación territorial
             : Publicación multilingüe
    Fase IV : Machine-readable Governance
            : Analytics de deliberación
            : AI-assisted review
    Fase V : Evaluación independiente
           : Interoperability entre repositorios
           : Candidato a Standard de proceso

---

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

#128. The Nebula Constitution™

Define autoridad, derechos, límites y procedimiento superior. El RFC proporciona el expediente deliberativo, pero no sustituye el proceso constitucional.

#129. The Nebula Governance Model™

Define órganos, responsabilidades, consensus, apelación y rendición de cuentas. The Nebula RFC™ operacionaliza esas funciones para cambios concretos.

#130. The Nebula Standards™

Define requisitos normativos y conformidad. El RFC propone y justifica su creación o modificación.

#131. La Arquitectura Nebula™

Los RFC arquitectónicos convierten concerns y alternativas en decisiones revisables. Los ADR implementan decisiones específicas derivadas.

#132. The Nebula Knowledge Model™

El RFC es un Knowledge Object con identidad, Evidence, versión, estado y metaconocimiento.

#133. The Nebula Ontology™

Proporciona la semántica para representar propuestas, actores, activos, derivaciones y decisiones.

#134. Digital Terroir®, Originblok® y Proof of Process™

Digital Terroir® aporta contexto científico y territorial. Originblok® preserva identidad y procedencia. Proof of Process™ puede demostrar la ejecución del proceso de cambio sin convertir esa ejecución en prueba de corrección.

#135. FermentOps®, RoastOps® y TraceOps®

Los productos consumen RFC aceptados y generan Evidence operacional que puede reabrirlos o motivar nuevas propuestas.

---

#Conclusiones

The Nebula RFC™ convierte la evolución institucional en un proceso explícito de aprendizaje.

Su unidad no es el documento aislado, sino la relación entre problema, propuesta, Evidence, revisión, decisión, implementación e historial. Esa relación permite comprender qué cambió, por qué cambió y qué alternativas fueron consideradas.

El proceso establece una frontera entre exploración y autoridad. Las ideas pueden madurar mediante conversación y prototipos; adquieren reconocimiento cuando ingresan a un sistema gobernado. El problema precede a la solución, la Evidence precede a la aprobación y la implementación no crea legitimidad por hecho consumado.

Rough consensus informado evita reducir decisiones a mayoría simple o unanimidad obligatoria. Las objeciones deberán recibir respuesta, preservarse y poder activar revisión futura.

La proporcionalidad impide tratar igual una corrección editorial y una reforma científica. Las vías abreviada, ordinaria y reforzada ajustan el rigor al alcance, reversibilidad, semántica y riesgo.

The Nebula Library™ preservará versiones, Evidence, comentarios, Decision Records y activos derivados. Las propuestas rechazadas también forman parte de Living Knowledge Infrastructure™.

El proceso será exitoso si mejora decisiones sin convertirse en trámite ceremonial. No pretende eliminar conflicto ni incertidumbre, sino transformarlos en razonamiento trazable, crítica preservada y evolución responsable.

---

#Glosario

#Architectural Decision Record

Registro de una decisión concreta de implementación arquitectónica compatible con un RFC.

#Candidate

Estado de una propuesta suficientemente madura para validación final o decisión.

#Conformance

Cumplimiento demostrable con requisitos normativos aplicables.

#Consensus

Apoyo suficiente después de tratar problemas materiales, sin exigir unanimidad.

#Decision Authority

Persona u órgano autorizado para adoptar una decisión.

#Decision Record

Objeto que preserva decisión, versión, autoridad, argumentos, objeciones y condiciones.

#Evidence

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

#Experimental

Autorización limitada para generar Evidence bajo condiciones explícitas.

#Formal Objection

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

#Knowledge Object

Unidad identificable de contenido, metaconocimiento y relaciones.

#Minority Report

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

#RFC

Knowledge Object versionado que propone y fundamenta un cambio.

#Rough Consensus

Forma de consensus basada en tratar problemas y objeciones, no en contar apoyos.

#Standardized

Estado en que una propuesta produjo un Standard y completó requisitos de conformidad.

#Triage

Clasificación inicial de dominio, impacto, vía, revisores y riesgos.

---

#Bibliografía recomendada

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

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

3. Bradner, S. RFC 2119 — Key Words for Use in RFCs to Indicate Requirement Levels. IETF Best Current Practice 14, 1997.

4. Leiba, B. RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. IETF Best Current Practice 14, 2017.

5. World Wide Web Consortium. W3C Process Document. Proceso efectivo desde el 18 de agosto de 2025.

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

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

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

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

10. Internet Engineering Task Force. RFC 8874 — Working Group GitHub Usage Guidance. Referencia sugerida.

11. Internet Engineering Task Force. RFC 8179 — Intellectual Property Rights in IETF Technology. Referencia sugerida.

12. Kuhn, T. S. The Structure of Scientific Revolutions. Referencia sugerida.

13. Popper, K. R. The Logic of Scientific Discovery. Referencia sugerida.

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

15. Simon, H. A. The Sciences of the Artificial. Referencia sugerida.

---

#Anexo A — Registro mínimo de RFC

---

#Anexo B — Plantilla mínima

---
authors:
  - Nombre u organización
canonicalLanguage: es-419
category: <dominio>
createdAt: YYYY-MM-DD
description: Descripción concisa del cambio propuesto.
documentType: rfc
effectiveAt: YYYY-MM-DD
id: NBL-RFC-NNN
keywords:
  - Keyword
language: es-419
license: Proprietary
relatedDocuments:
  - NBL-FWK-XXX
shortTitle: Título corto
slug: slug-estable
status: draft
title: Título del RFC
translationStatus: source
updatedAt: YYYY-MM-DD
version: 0.1.0
---

# Título del RFC

## Resumen

## Motivación

## Definición del problema

## Objetivos

## No objetivos

## Propuesta

## Fundamento científico o técnico

## Alternativas consideradas

## Impacto

## Compatibilidad

## Migración

## Seguridad

## Privacidad

## Ética e impacto social

## Propiedad intelectual

## Validación

## Plan de implementación

## Estrategia de retiro

## Preguntas abiertas

## Historial de revisiones

---

#Anexo C — Clasificación de impacto

---

#Anexo D — Prueba de conformidad del proceso

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

1. asigne identificadores persistentes y no reutilizables;
2. conserve versiones y estados por separado;
3. clasifique impacto y vía;
4. preserve problema, propuesta y alternativas;
5. vincule Evidence y procedencia;
6. asigne revisores competentes;
7. declare conflictos de interés;
8. permita comentarios y respuestas trazables;
9. preserve Formal Objections;
10. produzca Decision Records;
11. distinga aceptación, implementación y Standardization;
12. documente compatibilidad, migración y retiro;
13. incorpore seguridad, privacidad y ética según riesgo;
14. registre propuestas rechazadas y retiradas;
15. permita reapertura y Temporal Evolution.

---

#Anexo E — Canon de The Nebula RFC™

El problema precede a la solución.

La Evidence precede a la aprobación, pero no sustituye la responsabilidad.

La implementación no crea legitimidad por hecho consumado.

Una mayoría no elimina una objeción material no tratada.

El desacuerdo informado forma parte de la memoria institucional.

La compatibilidad y el retiro se diseñan antes del despliegue.

La formalidad deberá ser proporcional al impacto.

Un RFC aceptado no es automáticamente un Standard.

Las propuestas rechazadas también producen conocimiento.

Todo cambio estable deberá poder explicar por qué existe.

---

#Anexo F — Declaración institucional

The Nebula RFC™ constituye el proceso oficial para transformar ideas en cambios científicos, semánticos, arquitectónicos, normativos, tecnológicos, operativos, económicos y territoriales dentro de The Nebula Framework™.

Su propósito es asegurar que la evolución del ecosistema no dependa de modificaciones silenciosas, autoridad informal ni conocimiento no preservado.

Nebula reconoce que ningún proceso garantiza decisiones correctas. La legitimidad de The Nebula RFC™ dependerá de su capacidad para hacer visibles problemas, Evidence, alternativas, riesgos, objeciones y responsabilidades; permitir experimentación proporcional; y corregir sus resultados cuando nueva Evidence lo exija.

Las propuestas aceptadas, rechazadas, retiradas y sustituidas forman parte de Living Knowledge Infrastructure™ porque documentan cómo el ecosistema aprende y por qué elige una dirección determinada.

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

The Nebula Framework™