Núcleo RCOS v0.1 Borrador

Sistema Operativo de Comunidad Regenerativa (RCOS)

Especificación Central

Estado: Borrador
Versión: RCOS-Core v0.1
Audiencia: Fundadores de comunidades, profesionales, auditores, implementadores
Palabras clave normativas: DEBE, NO DEBE, DEBERÍA, PUEDE (estilo RFC)

En línea: https://rcos.ecohubs.community/es/standard/core/0.1

Generado el 2026-10-04 · Con licencia CC BY 4.0.

Núcleo RCOS v0.1 · §0 · Informativo

Introducción

0.1 Propósito de RCOS

Define un sistema operativo estandarizado y modular para comunidades pequeñas e intencionales, centrado en la resiliencia, la equidad y la regeneración.

0.2 Alcance del núcleo

Esta especificación define las capas centrales obligatorias requeridas para el cumplimiento de RCOS. Las prácticas específicas de dominio quedan excluidas y se abordan mediante módulos opcionales.

0.3 Principios de diseño

- Basado en restricciones, no en valores
- Precompromiso por encima de la improvisación
- Modular por defecto
- A escala humana
- Tolerante a fallos

0.4 Definiciones y terminología

- Comunidad
- Miembro
- Rol
- Dominio
- Bienes comunes
- Invariante
- Tipo de decisión
- Cumplimiento

Núcleo RCOS v0.1 · §1 · Informativo

Modelo de Conformidad RCOS

1.1 Niveles de conformidad

- Conforme con RCOS-Core
- RCOS-Core + módulos (no normativo)

1.2 Requisito de explicitud

Cualquier mecanismo que afecte al poder, los recursos, las obligaciones o la salida DEBE ser explícito, estar documentado y ser verificable.

1.3 Meta-invariante

Si no está escrito y adoptado, no existe.

Núcleo RCOS v0.1 · §2 · Normativo

Capa 0 — Identidad y Alcance

La Capa 0 define la identidad constitucional de la comunidad. Establece lo que la comunidad es, lo que no es, y las restricciones innegociables bajo las cuales operan todas las demás capas. Ninguna regla, decisión o práctica en capas superiores puede contradecir la Capa 0.

2.1 Definición de Propósito

2.1.1
Una comunidad DEBE definir exactamente un propósito primario.
2.1.2
El propósito primario DEBE describir la razón perdurable de la existencia de la comunidad y NO DEBE ser un objetivo, proyecto o estrategia a corto plazo.
2.1.3
El propósito primario DEBE ser estable a lo largo del tiempo y solo DEBE ser modificado mediante una decisión constitucional tal como se define en la Capa 2 y ejecutada a través del proceso de cambio definido en la Capa 6.
2.1.4
Se PUEDEN definir propósitos secundarios, pero NO DEBEN entrar en conflicto con el propósito primario ni anularlo.
2.1.5
Ninguna acción, decisión o asignación de recursos PUEDE contradecir materialmente el propósito primario declarado.

2.2 Declaración de Alcance

2.2.1
La comunidad DEBE declarar explícitamente el alcance de lo que gobierna.
2.2.2
La declaración de alcance DEBE incluir, como mínimo:
- Activos gobernados por la comunidad
- Dominios de autoridad en la toma de decisiones
- Actividades y responsabilidades bajo control colectivo
2.2.3
La declaración de alcance DEBE listar explícitamente lo que queda fuera de alcance.
2.2.4
Todo lo que no esté explícitamente declarado como dentro del alcance DEBE tratarse como fuera de alcance.
2.2.5
La comunidad NO DEBE ejercer autoridad sobre personas, activos o dominios que estén declarados fuera de alcance.

2.3 Invariantes

2.3.1
Las invariantes son restricciones que definen lo que NO DEBE ser violado mientras estén vigentes.
2.3.2
Las invariantes DEBEN estar explícitamente listadas y documentadas.
2.3.3
Las invariantes DEBEN aplicarse a todas las capas de RCOS.
2.3.4
Ninguna decisión, rol, proceso o medida de emergencia PUEDE anular una invariante.
2.3.5
Si surge un conflicto entre una invariante y cualquier otra regla, la invariante DEBE prevalecer.
2.3.6
Las invariantes solo PUEDEN ser modificadas o eliminadas mediante un proceso de cambio constitucional tal como se define en la Capa 2 y la Capa 6.

2.4 Restricciones de Identidad

2.4.1
La comunidad DEBE declarar cualquier restricción a nivel de identidad que afecte materialmente la participación, el comportamiento o la gobernanza.
2.4.2
Las restricciones de identidad PUEDEN incluir, entre otras:
- Límites éticos o de comportamiento
- Requisitos previos de participación
- Restricciones culturales o ecológicas innegociables
2.4.3
Las restricciones de identidad DEBEN ser verificables y aplicables mediante procesos definidos.
2.4.4
Las restricciones de identidad NO DEBEN aplicarse de manera implícita o informal.

2.5 Artefactos

2.5.1
Los siguientes artefactos son obligatorios para el cumplimiento de la Capa 0:
- Carta de Propósito
- Declaración de Alcance
- Registro de Invariantes
- Registro de Restricciones de Identidad
2.5.2
Los artefactos de la Capa 0 DEBEN:
- Ser accesibles públicamente para todos los miembros
- Estar versionados
- Ser adoptados mediante un proceso formal de ratificación
2.5.3
Si los artefactos de la Capa 0 están ausentes, son ambiguos o internamente contradictorios, la comunidad DEBE considerarse no conforme con RCOS-Core.

Núcleo RCOS v0.1 · §3 · Normativo

Capa 1 — Sistema de Membresía

La Capa 1 define cómo las personas ingresan, participan y salen de la comunidad. Establece la relación explícita entre el individuo y el colectivo, incluyendo derechos, obligaciones y el debido proceso. Ninguna persona puede ser tratada como miembro sin haber pasado por los mecanismos definidos en esta capa.

3.1 Estados de Membresía

3.1.1
La comunidad DEBE definir estados de membresía explícitos.
3.1.2
Como mínimo, DEBEN existir los siguientes estados de membresía:
- Solicitante
- Miembro en Prueba / Periodo Probatorio
- Miembro Pleno
- Miembro Retirado
3.1.3
Cada estado de membresía DEBE tener derechos, obligaciones y limitaciones claramente definidos.
3.1.4
Ningún individuo PUEDE ostentar múltiples estados de membresía simultáneamente.
3.1.5
No se PUEDE asumir ningún derecho u obligación fuera del estado de membresía actual del individuo.

3.2 Ingreso e Incorporación

3.2.1
El ingreso a la comunidad DEBE seguir un proceso de incorporación explícito.
3.2.2
El proceso de incorporación DEBE incluir:
- Revisión de todos los artefactos de RCOS-Core
- Consentimiento explícito a las reglas de la Capa 0 y la Capa 1
- Declaración del estado de membresía inicial
3.2.3
Los criterios de admisión DEBEN ser explícitos y estar documentados.
3.2.4
La membresía informal, implícita o retroactiva NO DEBE ser permitida.

3.3 Periodo de Prueba y Evaluación

3.3.1
La comunidad DEBE definir un periodo probatorio para los nuevos miembros.
3.3.2
El periodo probatorio DEBE tener:
- Una duración definida
- Criterios de evaluación explícitos
- Un proceso de decisión de transición claro
3.3.3
Durante el periodo de prueba, los derechos PUEDEN ser limitados, pero las obligaciones DEBEN ser explícitas.
3.3.4
La falta de transición desde el periodo de prueba DEBE activar un proceso definido de salida o extensión.

3.4 Derechos y Obligaciones

3.4.1
La comunidad DEBE definir explícitamente los derechos de los miembros.
3.4.2
La comunidad DEBE definir explícitamente las obligaciones de los miembros.
3.4.3
Los derechos y obligaciones DEBEN ser simétricos y proporcionales al estado de membresía.
3.4.4
Ninguna obligación PUEDE ser exigida sin un derecho correspondiente y documentado.
3.4.5
Las obligaciones NO DEBEN ser indefinidas o carecer de definición.

3.5 Participación y Contribución

3.5.1
Las expectativas de participación DEBEN estar definidas explícitamente.
3.5.2
Las formas aceptables de contribución DEBEN estar enumeradas.
3.5.3
La sustitución de participación (p. ej., externalización de trabajo) DEBE estar gobernada explícitamente.
3.5.4
La falta persistente de participación DEBE activar un proceso de rendición de cuentas según lo definido en la Capa 4.

3.6 Salida y Separación

3.6.1
La salida voluntaria DEBE ser posible en todo momento.
3.6.2
Los procedimientos de salida DEBEN ser explícitos, documentados y no punitivos.
3.6.3
La salida forzosa DEBE seguir el debido proceso y gestionarse a través de los mecanismos de la Capa 4.
3.6.4
La salida NO DEBE resultar en la pérdida de derechos más allá de aquellos explícitamente vinculados a la membresía.
3.6.5
La separación de activos, roles y responsabilidades DEBE estar definida antes de la salida.

3.7 Suspensión y Estado Temporal

3.7.1
La comunidad PUEDE definir estados de suspensión temporal.
3.7.2
Las condiciones de suspensión DEBEN ser explícitas, limitadas en el tiempo y revisables.
3.7.3
La suspensión NO DEBE utilizarse como sustituto indefinido o punitivo de la salida.

3.8 Artefactos

3.8.1
Los siguientes artefactos son obligatorios para el cumplimiento de la Capa 1:
- Acuerdo de Membresía
- Protocolo de Incorporación
- Protocolo de Salida y Separación
- Registro de Estados de Membresía
3.8.2
Los artefactos de la Capa 1 DEBEN ser:
- Explícitos e inequívocos
- Versionados
- Accesibles para todos los miembros
3.8.3
La ausencia, ambigüedad o violación sistemática de los artefactos de la Capa 1 DEBE resultar en la pérdida del cumplimiento con RCOS-Core.

Núcleo RCOS v0.1 · §4 · Normativo

Capa 2 — Gobernanza y lógica de decisión

La Capa 2 define cómo se toman las decisiones colectivas, quién está autorizado para tomarlas y cómo se limita la autoridad. La gobernanza bajo RCOS está diseñada para hacer que el poder sea explícito, acotado, revisable y reversible.

4.1 Tipos de decisión

4.1.1
Todas las decisiones colectivas DEBEN clasificarse en exactamente uno de los siguientes tipos de decisión:
- Decisiones operativas
- Decisiones estratégicas
- Decisiones constitucionales
4.1.2
Las decisiones operativas se refieren al funcionamiento y la ejecución del día a día dentro de las reglas existentes.
4.1.3
Las decisiones estratégicas se refieren a la dirección a largo plazo, la asignación de recursos significativos o la creación/eliminación de estructuras importantes.
4.1.4
Las decisiones constitucionales se refieren a cambios en los invariantes de la Capa 0, el propósito, el alcance o el propio sistema de gobernanza.
4.1.5
Si una decisión no puede clasificarse claramente, DEBE tratarse por defecto como el tipo de decisión de mayor impacto.

4.2 Mecanismos de decisión

4.2.1
Cada tipo de decisión DEBE tener un mecanismo de toma de decisiones definido de forma explícita.
4.2.2
Los mecanismos de decisión PUEDEN incluir, entre otros:
- Toma de decisiones basada en consentimiento
- Votación por mayoría
- Votación por supermayoría
- Autoridad delegada
- Asignación aleatoria o rotativa
4.2.3
Los mecanismos de decisión DEBEN especificar:
- Participantes elegibles
- Umbrales de decisión
- Condiciones de bloqueo o veto, si las hubiera
- Restricciones de tiempo
4.2.4
Ningún mecanismo de decisión informal o ad hoc PUEDE utilizarse para decisiones colectivas.

4.3 Límites de autoridad

4.3.1
Toda autoridad DEBE asignarse a roles, círculos u órganos definidos de forma explícita.
4.3.2
Las asignaciones de autoridad DEBEN incluir:
- Alcance de la autoridad
- Límites de la autoridad
- Duración o mandato, si corresponde
4.3.3
Ningún individuo u órgano PUEDE ejercer autoridad fuera del alcance que le fue asignado de forma explícita.
4.3.4
La autoridad NO DEBE derivarse del carisma, la antigüedad, la propiedad o la influencia informal.
4.3.5
La autoridad temporal o de emergencia DEBE estar definida de forma explícita, acotada en el tiempo y sujeta a revisión.

4.4 Matriz de decisión

4.4.1
La comunidad DEBE mantener una Matriz de decisión como artefacto central de gobernanza.
4.4.2
La Matriz de decisión DEBE mapear, como mínimo:
- Tipo de decisión
- Dominio de decisión
- Rol u órgano autorizado
- Mecanismo de decisión
- Umbral de aprobación
- Vía de escalamiento
4.4.3
La Matriz de decisión DEBE ser accesible públicamente para todos los miembros.
4.4.4
Las decisiones tomadas fuera de la Matriz de decisión DEBEN considerarse inválidas.

4.5 Protocolo de gobernanza

4.5.1
La comunidad DEBE definir un Protocolo de gobernanza que describa el ciclo de vida completo de una decisión.
4.5.2
El Protocolo de gobernanza DEBE incluir:
- Requisitos de presentación de propuestas
- Proceso de revisión y deliberación
- Ejecución de la decisión
- Documentación y publicación
- Mecanismos de apelación y revisión
4.5.3
El Protocolo de gobernanza DEBE definir cómo se resuelven los conflictos entre decisiones.
4.5.4
Todas las acciones de gobernanza DEBEN documentarse de acuerdo con las reglas de documentación de la Capa 5.

4.6 Salvaguardas y modos de fallo

4.6.1
El sistema de gobernanza DEBE incluir salvaguardas contra:
- Concentración del poder de decisión
- Vetos informales
- Captura de decisiones por subgrupos
- Atrincheramiento de fundadores o roles
4.6.2
Los mecanismos de gobernanza DEBEN permitir la impugnación y revisión sin represalias.
4.6.3
Los fallos persistentes en la gobernanza DEBEN activar un proceso formal de revisión o un proceso constitucional.

4.7 Artefactos

4.7.1
Los siguientes artefactos son obligatorios para el cumplimiento de la Capa 2:
- Matriz de decisión
- Protocolo de gobernanza
- Registro de autoridad
4.7.2
Los artefactos de la Capa 2 DEBEN ser:
- Explícitos e inequívocos
- Versionados
- Accesibles para todos los miembros
4.7.3
La ausencia, ambigüedad o violación sistemática de los artefactos de la Capa 2 DEBE resultar en la pérdida de conformidad con RCOS-Core.

Núcleo RCOS v0.1 · §5 · Normativo

Capa 3 — Sistema Económico y de Recursos

La Capa 3 define cómo fluyen el valor, los recursos y las obligaciones dentro de la comunidad. Su propósito es hacer que el poder económico sea explícito, acotado, auditable y subordinado a la gobernanza, previniendo la acumulación oculta, la dependencia o la coerción.

5.1 Recursos comunes vs privados

5.1.1
Todos los recursos dentro del ámbito gobernado declarado DEBEN clasificarse explícitamente como comunes o privados.
5.1.2
La comunidad DEBE mantener un registro único, explícito y versionado de los recursos gobernados, que incluya como mínimo:
- Nombre o identificador único del recurso
- Clasificación (comunes o privados)
- Administrador/a o propietario/a (según corresponda)
- Reglas de acceso y uso
- Restricciones de transferencia, venta o privatización (si las hay)
5.1.3
Cualquier recurso no clasificado explícitamente DEBE tratarse como sin clasificar, y la comunidad NO DEBE asignarlo, gravarlo, monetizarlo ni transferirlo hasta que la clasificación se complete mediante una decisión autorizada.
5.1.4
Para los recursos comunes, la comunidad DEBE definir explícitamente:
- Responsabilidades de administración
- El órgano o rol autorizado para la toma de decisiones
- Obligaciones de mantenimiento
- Mecanismos de financiación o contribución (si los hay)
5.1.5
Para los recursos privados, la comunidad NO DEBE ejercer autoridad más allá de lo explícitamente declarado en el ámbito, los acuerdos de membresía u otros artefactos gobernados.

5.2 Reconocimiento de contribuciones

5.2.1
La comunidad DEBE definir explícitamente qué categorías de contribución se reconocen. Estas PUEDEN incluir, entre otras:
- Trabajo
- Cuidados y trabajo emocional
- Conocimiento y educación
- Administración y mantenimiento
- Trabajo administrativo o de coordinación
5.2.2
La comunidad DEBE definir un mecanismo de reconocimiento de contribuciones que especifique:
- Qué califica como contribución
- Cómo se registran o reconocen las contribuciones
- Quién puede registrar, validar o impugnar contribuciones
- Si el reconocimiento de contribuciones afecta al acceso a recursos, privilegios u obligaciones, y de qué manera
5.2.3
La comunidad NO DEBE depender estructuralmente de trabajo no remunerado, invisible o informal para la supervivencia del sistema sin definir explícitamente las obligaciones, el reconocimiento o los mecanismos de compensación correspondientes.
5.2.4
Si se utilizan unidades económicas internas (p. ej., créditos de tiempo, puntos, tokens), el Protocolo de Economía Interna DEBE definir:
- Reglas de emisión
- Reglas de transferibilidad
- Mecanismos de expiración, decaimiento o límite máximo (si los hay)
- Mecanismos de prevención de fraude, resolución de disputas y corrección
- Reglas de privacidad y transparencia para saldos y transacciones
5.2.5
El reconocimiento de contribuciones NO DEBE crear autoridad implícita de decisión, poder de veto o influencia en la gobernanza más allá de lo definido en la Capa 2.

5.3 Gestión de tesorería

5.3.1
La comunidad DEBE definir explícitamente qué recursos se mantienen en la tesorería compartida y cómo se articulan los límites de la tesorería con los recursos privados.
5.3.2
Las fuentes de ingresos y cualquier interfaz de ingresos externos DEBEN definirse explícitamente.
5.3.3
La autoridad de gasto DEBE estar explícitamente acotada mediante:
- Asignaciones claras de autoridad
- Umbrales por monto y/o categoría
- Vías de aprobación y escalamiento
- Requisitos obligatorios de registro
5.3.4
La transparencia DEBE ser la norma por defecto para los saldos de tesorería, los ingresos, los egresos, las obligaciones y los compromisos.
5.3.5
Cualquier excepción a la transparencia DEBE estar explícitamente definida, justificada, acotada en el tiempo y NO DEBE impedir que los miembros auditen el cumplimiento.
5.3.6
La comunidad DEBE definir políticas de reservas, riesgos y responsabilidades, que incluyan:
- Límites de endeudamiento
- Obligaciones a largo plazo
- Reservas de contingencia (si las hay)

5.4 Restricciones de acumulación

5.4.1
Los sistemas económicos internos DEBEN prevenir la concentración ilimitada de influencia o control interno a través de recursos, créditos u obligaciones financieras.
5.4.2
Si existen unidades internas, la comunidad DEBE definir uno o más mecanismos de limitación de acumulación, que PUEDEN incluir:
- Límites máximos
- Decaimiento o expiración
- No transferibilidad
- Mecanismos de redistribución o tributación
- Validez acotada en el tiempo
5.4.3
Los mecanismos económicos NO DEBEN permitir que los miembros eludan los límites de autoridad de gobernanza definidos en la Capa 2, incluyendo mediante la compra de influencia, la creación de dependencia o la conversión de poder económico en autoridad informal de decisión.
5.4.4
La comunidad DEBE definir indicadores auditables de riesgo de concentración económica y un mecanismo explícito para ajustar las restricciones cuando se detecten dichos riesgos.

5.5 Artefactos

5.5.1
Los siguientes artefactos son obligatorios para el cumplimiento de la Capa 3:
- Protocolo de Economía Interna
- Reglamento de Tesorería
5.5.2
Los artefactos de la Capa 3 DEBEN ser:
- Explícitos e inequívocos
- Versionados
- Accesibles para todos los miembros (con excepciones explícitas y acotadas)
- Adoptados mediante un proceso de gobernanza autorizado
5.5.3
El Protocolo de Economía Interna DEBE definir, como mínimo:
- Categorías de contribución y mecanismos de reconocimiento
- Límites y reglas de asignación entre recursos comunes y privados
- Unidades internas (si las hay) y restricciones de acumulación
- Interfaces de ingresos externos (si las hay)
- Mecanismos de resolución de disputas y corrección de registros económicos
5.5.4
El Reglamento de Tesorería DEBE definir, como mínimo:
- Fuentes de ingresos
- Umbrales de autoridad de gasto y vías de aprobación
- Requisitos de transparencia y rendición de cuentas (incluyendo excepciones acotadas)
- Restricciones de reservas, riesgos y endeudamiento
- Reglas de conflicto de intereses para gastos y adquisiciones

5.6 Invariantes de capa

5.6.1
Los recursos compartidos, los flujos y las obligaciones DEBEN ser visibles para la comunidad por defecto, con excepciones únicamente limitadas y explícitas.
5.6.2
Los recursos declarados como comunes NO DEBEN privatizarse mediante acciones informales, implícitas o unilaterales.
5.6.3
El reconocimiento de contribuciones DEBE ser explícito, de modo que el trabajo no remunerado o invisible no sea estructuralmente necesario para la supervivencia del sistema.
5.6.4
Los mecanismos económicos DEBEN prevenir la concentración indefinida de influencia interna.

5.7 Reglas de explicitud

5.7.1
Lo siguiente DEBE ser explícito:
- Clasificaciones de recursos comunes vs privados
- Reglas de asignación y acceso para recursos compartidos
- Límites de autoridad de gasto
- Reglas de transparencia
- Interfaces de ingresos externos
5.7.2
Lo siguiente PUEDE ser explícito:
- Modelos de valoración de contribuciones
- Unidades internas (tokens, horas, puntos)
- Categorías presupuestarias y estructuras de contabilidad interna
5.7.3
Lo siguiente DEBE permanecer opcional y fuera del ámbito:
- Actitudes hacia la riqueza
- Resultados igualitarios vs diferenciados
- Decisiones financieras personales

Núcleo RCOS v0.1 · §6 · Normativo

Capa 4 — Conflicto, Reparación y Rendición de Cuentas

La Capa 4 define cómo responde la comunidad cuando la confianza, la coordinación o la seguridad se quiebran.
Su propósito es garantizar que los conflictos se manejen de forma explícita, justa y segura, al tiempo que se previene el abuso de poder, la normalización del daño o la exclusión silenciosa.

6.1 Clasificación de conflictos

6.1.1
La comunidad DEBE definir un sistema explícito de clasificación de conflictos que sea conocido, accesible y utilizable por todos los miembros.
6.1.2
Como mínimo, el sistema de clasificación DEBE incluir las siguientes clases:
- Conflictos interpersonales (entre individuos)
- Conflictos de rol (disputas de autoridad, responsabilidad o mandato)
- Conflictos estructurales (incentivos sistémicos, reglas o problemas de asignación de recursos)
- Violaciones éticas o de límites (violaciones de normas declaradas, alcance o límites de seguridad)
6.1.3
Cada clase de conflicto DEBE definir explícitamente:
- Criterios de entrada (cómo se clasifica una situación en esta clase)
- Prioridad de respuesta esperada y plazos (si los hay)
- Vías de resolución permitidas y requeridas
- Requisitos de documentación y límites de privacidad
6.1.4
Los conflictos que impliquen riesgos creíbles para la seguridad, coerción, abuso o amenazas DEBEN clasificarse como críticos para la seguridad y DEBEN activar salvaguardas elevadas según lo definido en la Sección 6.3.
6.1.5
La clasificación errónea o la evasión de la clasificación DEBE tratarse como un fallo de proceso sujeto a revisión.

6.2 Vías de resolución

6.2.1
La comunidad DEBE definir un proceso mínimo de resolución de conflictos aplicable a todas las clases de conflicto.
6.2.2
El proceso de resolución DEBE incluir una escalera de resolución claramente definida con pasos de escalamiento explícitos.
6.2.3
La escalera de resolución DEBE definir, como mínimo:
- Cómo se plantea, registra y reconoce un conflicto
- Cómo se notifica a las partes involucradas y se las invita a participar
- Cómo se manejan la negativa, la falta de respuesta o la retirada
- Cómo se seleccionan, reemplazan o recusan los mediadores o facilitadores
- Expectativas con plazos definidos para cada etapa (cuando corresponda)
- Requisitos de documentación y reglas de acceso
- Un proceso para revisar fallos procedimentales o puntos muertos
6.2.4
El proceso de resolución DEBE ser accesible sin requerir estatus social, antigüedad, carisma o proximidad informal a los tomadores de decisiones.
6.2.5
Los conflictos no resueltos DEBEN escalar a través de las vías de gobernanza definidas sin eludir la Matriz de Decisión definida en la Capa 2.

6.3 Salvaguardas

6.3.1
La comunidad DEBE definir salvaguardas explícitas para conflictos que involucren asimetrías de poder, relaciones de dependencia o riesgos de seguridad.
6.3.2
Las salvaguardas DEBEN incluir protecciones contra represalias por:
- Plantear una preocupación
- Solicitar mediación
- Proporcionar testimonio o evidencia
- Participar en una revisión o apelación
6.3.3
Cuando exista un diferencial de poder entre las partes, DEBEN aplicarse salvaguardas elevadas, que PUEDEN incluir:
- Facilitación independiente o externa
- Canales separados de recepción, documentación o comunicación
- Suspensión o limitación temporal de la autoridad del rol
- Umbrales adicionales de evidencia y revisión previos a las sanciones
6.3.4
Para conflictos críticos para la seguridad, la comunidad DEBE definir acciones protectoras inmediatas que puedan tomarse antes de completar el proceso completo, que PUEDEN incluir:
- Medidas de separación temporal
- Acceso restringido a espacios o recursos compartidos
- Suspensión temporal del rol
- Plazos de escalamiento de emergencia
6.3.5
Las salvaguardas de seguridad DEBEN prevalecer sobre los derechos de participación, la continuidad del rol y la conveniencia operativa.

6.4 Sanciones, reparación y separación

6.4.1
La comunidad DEBE definir un marco explícito de sanciones y reparación.
6.4.2
Las sanciones y acciones de reparación DEBEN ser:
- Proporcionales a la infracción
- Explícitamente documentadas
- Con plazo definido cuando corresponda
- Revisables y apelables
6.4.3
El marco DEBE definir, como mínimo:
- Tipos de sanciones y reparaciones disponibles
- Precondiciones y estándares de evidencia
- Roles u órganos autorizados para su aplicación
- Mecanismos de revisión y apelación
- Condiciones para la restauración de derechos, roles o participación
6.4.4
Las acciones de separación, suspensión o remoción DEBEN seguir el debido proceso y DEBEN estar alineadas con las reglas de salida y separación definidas en la Capa 1.
6.4.5
Las sanciones NO DEBEN aplicarse mediante exclusión informal, presión social, silencio o retiro implícito de derechos.
6.4.6
Las acciones orientadas a la reparación DEBEN priorizarse sobre las acciones punitivas, excepto en casos críticos para la seguridad.

6.5 Artefactos

6.5.1
Los siguientes artefactos son obligatorios para el cumplimiento de la Capa 4:
- Escalera de Resolución de Conflictos
- Protocolo de Rendición de Cuentas
6.5.2
Los artefactos de la Capa 4 DEBEN ser:
- Explícitos e inequívocos
- Versionados
- Accesibles para todos los miembros, con protecciones de privacidad claramente delimitadas
- Adoptados mediante un proceso de gobernanza autorizado
6.5.3
La Escalera de Resolución de Conflictos DEBE definir, como mínimo:
- Entradas de clasificación de conflictos y umbrales de escalamiento
- Etapas de resolución y reglas de selección de facilitadores
- Límites de documentación y acceso a la información
- Excepciones críticas para la seguridad y salvaguardas inmediatas
6.5.4
El Protocolo de Rendición de Cuentas DEBE definir, como mínimo:
- Mecanismos de investigación, revisión y decisión
- Garantías de debido proceso y protecciones contra represalias
- Opciones de sanción y reparación con reglas de proporcionalidad
- Apelaciones, supervisión y vías de escalamiento
- Coordinación con los procesos de salida y separación de la Capa 1

6.6 Invariantes de la capa

6.6.1
El conflicto DEBE tratarse como una condición gestionada con vías definidas; ignorar, suprimir o normalizar un conflicto no resuelto DEBE considerarse una violación del sistema.
6.6.2
Los conflictos que involucren asimetrías de poder DEBEN activar salvaguardas elevadas.
6.6.3
La reparación y la restauración DEBEN preceder al castigo, excepto cuando la seguridad inmediata esté en riesgo.
6.6.4
La seguridad física, psicológica y de menores DEBE prevalecer sobre los derechos de participación, la continuidad del rol y las consideraciones de reputación.

6.7 Reglas de explicitud

6.7.1
Lo siguiente DEBE ser explícito:
- Sistema de clasificación de conflictos
- Proceso mínimo de resolución y escalamiento
- Salvaguardas y protecciones contra represalias
- Umbrales de sanción, reparación y separación
6.7.2
Lo siguiente PUEDE ser explícito:
- Estilos o metodologías de mediación
- Preferencias de selección de facilitadores más allá de las salvaguardas mínimas
- Prácticas restaurativas o reparativas
6.7.3
Lo siguiente DEBE permanecer opcional y fuera de alcance:
- Normas de expresión emocional
- Encuadre terapéutico, espiritual o ideológico del conflicto

Núcleo RCOS v0.1 · §7 · Normativo

Capa 5 — Operaciones y Coordinación

La Capa 5 define cómo funcionan en la práctica el trabajo diario, la coordinación y el flujo de información. Su propósito es asegurar que las operaciones se mantengan legibles, sostenibles y transferibles, y que no colapsen en jerarquías informales, dependencia o agotamiento.

7.1 Roles y Responsabilidades

7.1.1
Todas las responsabilidades continuas DEBEN asignarse a roles explícitos y con nombre, en lugar de expectativas implícitas o acuerdos informales.
7.1.2
La comunidad DEBE mantener un Registro de Roles que incluya, como mínimo:
- Nombre y propósito del rol
- Alcance de la responsabilidad y autoridad de decisión
- Límites explícitos e interfaces con otros roles, círculos o dominios
- Criterios de elegibilidad (si los hay)
- Duración del mandato, rotación o condiciones de revisión (si las hay)
- Proceso de designación, revisión y remoción
7.1.3
Cada rol DEBE incluir un mecanismo explícito de rendición de cuentas que defina:
- Cómo se revisa el desempeño del rol
- Cómo se gestiona el bajo rendimiento, la sobrecarga o el fallo del rol
- Cómo se realizan los traspasos y la transferencia de conocimiento
7.1.4
Ninguna responsabilidad continua PUEDE existir sin un rol explícito, y ninguna persona PUEDE ser responsabilizada por obligaciones que no estén formalmente asignadas a un rol.
7.1.5
Las responsabilidades temporales o ad-hoc DEBEN estar explícitamente acotadas en el tiempo y NO DEBEN convertirse en continuas sin una definición formal de rol.

7.2 Sistema de Reuniones

7.2.1
La comunidad DEBE definir tipos de reuniones explícitos suficientes para dar soporte a:
- Operaciones
- Gobernanza
- Coordinación y alineación
- Reflexión y aprendizaje
- Gestión de conflictos (según lo requerido por la Capa 4)
7.2.2
Cada tipo de reunión DEBE definir, como mínimo:
- Propósito y alcance de decisión
- Participantes obligatorios vs opcionales
- Cadencia y límites de duración
- Rol de facilitación y proceso de selección o rotación
- Estructura de la agenda
- Requisitos de documentación y publicación
- Requisitos de captura de decisiones cuando se toman decisiones
7.2.3
Las reuniones NO DEBEN exceder su alcance de decisión declarado ni eludir los límites de autoridad definidos en la Capa 2.
7.2.4
La carga de reuniones DEBE estar acotada, monitoreada y ser revisable según lo definido en la Sección 7.4.

7.3 Documentación y Flujo de Información

7.3.1
La comunidad DEBE definir reglas explícitas de documentación para decisiones, roles, operaciones y obligaciones compartidas.
7.3.2
Las reglas de documentación DEBEN especificar, como mínimo:
- Qué información DEBE registrarse
- Dónde se almacenan los registros
- Quién tiene acceso a qué registros
- Plazos de publicación o notificación (si los hay)
- Límites de privacidad y condiciones para el acceso restringido
7.3.3
Todas las decisiones DEBEN ser trazables hasta:
- Tipo y dominio de la decisión
- Rol o cuerpo autorizado
- Mecanismo de decisión y umbral
- Resultado registrado y fecha de entrada en vigor
7.3.4
Los procesos operativos críticos DEBEN estar documentados de modo que la continuidad no dependa de conocimiento tácito de personas específicas.
7.3.5
El flujo de información DEBE diseñarse para prevenir el control de acceso indebido, los cuellos de botella o la dependencia de intermediarios informales.

7.4 Límites de Carga de Trabajo y Capacidad

7.4.1
El tiempo, la atención, la capacidad de coordinación y el trabajo emocional DEBEN tratarse como recursos finitos y limitados.
7.4.2
La comunidad DEBE definir límites explícitos de carga de trabajo, incluyendo:
- Límites a la carga de reuniones (frecuencia, duración o tiempo total)
- Límites a la carga de roles (número de roles, alcance u horas esperadas)
- Expectativas de tiempos de respuesta y disponibilidad (si las hay)
- Mecanismos de renegociación, alivio, sustitución o redistribución
7.4.3
Los límites de carga de trabajo DEBEN ser revisables y ajustables mediante un proceso de gobernanza autorizado.
7.4.4
La sobrecarga persistente, el riesgo de agotamiento, la no-participación crónica o la dependencia de personas que funcionan en exceso DEBEN activar procesos de revisión o reparación según lo definido en la Capa 4.

7.5 Continuidad Operativa

7.5.1
La comunidad DEBE asegurar que ningún individuo sea un punto único de fallo crítico para las operaciones esenciales.
7.5.2
Los roles y procesos operativos esenciales DEBEN incluir:
- Procedimientos documentados
- Mecanismos claros de traspaso
- Acuerdos de respaldo o redundancia cuando sea factible
7.5.3
La planificación de continuidad operativa DEBE revisarse periódicamente.

7.6 Artefactos

7.6.1
Los siguientes artefactos son obligatorios para el cumplimiento de la Capa 5:
- Manual de Operaciones
- Registro de Roles
- Plantillas de Reuniones
7.6.2
Los artefactos de la Capa 5 DEBEN ser:
- Explícitos e inequívocos
- Versionados
- Accesibles para todos los miembros, con protecciones de privacidad claramente delimitadas
- Mantenidos como documentos vivos con propiedad definida y ciclos de revisión
7.6.3
El Manual de Operaciones DEBE definir, como mínimo:
- Procesos operativos esenciales de los que depende la comunidad
- Interfaces entre roles, dominios y tipos de reuniones
- Ubicaciones de la documentación y procedimientos de actualización
7.6.4
Las Plantillas de Reuniones DEBEN definir, como mínimo:
- Estructura de la agenda
- Formato de notas y actas
- Formato de captura de decisiones cuando corresponda

7.7 Invariantes de Capa

7.7.1
Las responsabilidades continuas NO DEBEN existir sin un rol explícito.
7.7.2
Los procesos operativos críticos NO DEBEN depender exclusivamente de la memoria individual, la buena voluntad o la transmisión informal.
7.7.3
La carga de reuniones, la carga de coordinación y el trabajo no remunerado o invisible DEBEN estar acotados y ser revisables.
7.7.4
Las reglas de acceso a la información DEBEN ser explícitas y aplicables.

7.8 Reglas de Explicitud

7.8.1
Lo siguiente DEBE ser explícito:
- Roles y responsabilidades
- Límites e interfaces de autoridad operativa
- Tipos y alcances de reuniones
- Reglas de documentación de decisiones
- Límites de acceso a la información y privacidad
7.8.2
Lo siguiente PUEDE ser explícito:
- Cadencia detallada de reuniones más allá de las restricciones mínimas
- Elección de herramientas para documentación y coordinación
- Calendarios de rotación o sucesión de roles
7.8.3
Lo siguiente DEBE permanecer opcional y fuera de alcance:
- Estilos de trabajo personales
- Preferencias estéticas o culturales
- Coordinación social informal

Núcleo RCOS v0.1 · §8 · Normativo

Capa 6 — Evolución y Adaptación

La Capa 6 define cómo evoluciona el sistema sin colapsar.
Su propósito es asegurar que el cambio sea deliberado, acotado, reversible cuando corresponda, y que produzca aprendizajes en lugar de daños ocultos. La evolución bajo RCOS se trata como un proceso gobernado, no como improvisación.

8.1 Mecanismos de cambio

8.1.1
La comunidad DEBE definir mecanismos de cambio explícitos para modificar, agregar, suspender o eliminar reglas, roles, artefactos o estructuras de decisión.
8.1.2
Los mecanismos de cambio DEBEN distinguir explícitamente entre:
- Cambios permanentes de reglas
- Experimentos con duración acotada según lo definido en la Sección 8.3
8.1.3
Cada cambio propuesto DEBE especificar, como mínimo:
- El/los artefacto(s), capa(s) y sección(es) afectados
- El tipo de decisión y la vía de decisión autorizada según lo definido en la Capa 2
- El efecto previsto, el alcance y los riesgos conocidos
- La fecha de entrada en vigor y cualquier período de transición
- Los requisitos de migración para roles, acuerdos o registros existentes
8.1.4
Los cambios que afecten el propósito, alcance, invariantes o restricciones de identidad de la Capa 0 DEBEN clasificarse como cambios constitucionales y DEBEN seguir el mecanismo de decisión constitucional.
8.1.5
La comunidad DEBE definir mecanismos de revisión explícitos para los cambios adoptados, incluyendo cómo se evalúan, revisan o revierten los cambios cuando producen daño, inestabilidad o concentración no intencionada de poder.

8.2 Versionado y autoridad

8.2.1
Todos los cambios adoptados DEBEN ser versionados y trazables.
8.2.2
La comunidad DEBE mantener un Historial de Versiones que registre, como mínimo:
- Identificador de versión
- Fecha de adopción y fecha de entrada en vigor
- Referencia al registro de decisión (autoridad, mecanismo, umbral)
- Resumen de los cambios
- Notas de migración y restricciones de compatibilidad (si las hay)
8.2.3
En cualquier momento, la comunidad DEBE poder determinar sin ambigüedad:
- Qué versión está actualmente en vigor
- Qué artefactos son los autoritativos para el cumplimiento
8.2.4
Las reglas reemplazadas DEBEN permanecer accesibles para auditoría, aprendizaje y resolución de disputas, junto con las fechas durante las cuales estuvieron en vigor.
8.2.5
Ningún cambio de reglas informal, no documentado o "sobreentendido" PUEDE considerarse válido.

8.3 Experimentos

8.3.1
La comunidad PUEDE adoptar experimentos como desviaciones, extensiones o pilotos explícitamente acotados en el tiempo y reversibles, destinados al aprendizaje.
8.3.2
Cada experimento DEBE definir, como mínimo:
- Alcance (qué se cambia y qué explícitamente no se cambia)
- Duración y puntos de revisión
- Criterios de éxito y fracaso
- Condiciones de reversión y proceso de reversión
- Vía de decisión autorizada para iniciar, extender, modificar o terminar el experimento
8.3.3
Los experimentos NO DEBEN anular las invariantes de la Capa 0 y NO DEBEN eludir las restricciones de gobernanza definidas en la Capa 2.
8.3.4
Los experimentos DEBEN estar explícitamente etiquetados como experimentales en todos los artefactos afectados y DEBEN incluir una fecha de expiración no prorrogable, a menos que se renueven mediante una decisión autorizada.
8.3.5
Si un experimento introduce riesgo para la seguridad, coerción o daño sostenido, la comunidad DEBE suspender o terminar el experimento inmediatamente mediante una acción protectora, seguida de una revisión posterior.

8.4 Captura de aprendizajes y retroalimentación

8.4.1
Los fallos importantes, las adaptaciones, las reversiones y los aprendizajes sistémicos DEBEN ser documentados.
8.4.2
La captura de aprendizajes DEBE incluir, como mínimo:
- Qué ocurrió y por qué fue relevante
- Qué capas, reglas o artefactos estuvieron implicados
- Qué se cambió, intentó o detuvo
- Qué señales, evidencias o umbrales desencadenaron la acción
8.4.3
Los registros de aprendizaje DEBEN ser accesibles según las reglas de acceso a la información de la Capa 5.
8.4.4
Los patrones de fallo recurrentes DEBEN desencadenar una revisión estructural en lugar de culpa individual.

8.5 Seguridad del cambio y reversibilidad

8.5.1
El sistema DEBE preferir cambios reversibles sobre los irreversibles cuando sea posible.
8.5.2
Los cambios irreversibles o de alto impacto DEBEN incluir:
- Períodos extendidos de deliberación o revisión
- Umbrales de decisión más altos cuando sea apropiado
- Reconocimiento explícito del riesgo
8.5.3
Los cambios de emergencia PUEDEN permitirse solo cuando estén explícitamente definidos, DEBEN estar acotados en el tiempo, NO DEBEN anular las invariantes de la Capa 0 y DEBEN someterse a una revisión posterior obligatoria y a ratificación o reversión.

8.6 Artefactos

8.6.1
Los siguientes artefactos son obligatorios para el cumplimiento de la Capa 6:
- Protocolo de Cambios
- Historial de Versiones
- Registro de Aprendizajes
8.6.2
Los artefactos de la Capa 6 DEBEN ser:
- Explícitos e inequívocos
- Versionados
- Accesibles para todos los miembros, con protecciones de privacidad claramente delimitadas
- Adoptados mediante un proceso de gobernanza autorizado
8.6.3
El Protocolo de Cambios DEBE definir, como mínimo:
- Cómo se proponen, revisan, adoptan, publican y rechazan los cambios
- Cómo se clasifican las propuestas por tipo de decisión
- El contenido requerido de las propuestas de cambio
- Las expectativas de transición, migración y deprecación
- Los mecanismos de revisión, corrección y reversión
- Las disposiciones para cambios de emergencia, incluyendo límites temporales estrictos y revisión obligatoria
8.6.4
El Historial de Versiones DEBE definir:
- La estructura autoritativa para los identificadores de versión y los registros de cambios
- Cómo se retienen y acceden las versiones reemplazadas
- Cómo se determina la versión actualmente activa
8.6.5
El Registro de Aprendizajes DEBE definir:
- Qué constituye un evento del que se puede aprender
- El formato de documentación y la responsabilidad
- La cadencia de revisión y síntesis

8.7 Invariantes de la capa

8.7.1
El cambio DEBE ser posible pero acotado; ningún cambio PUEDE ser instantáneo, implícito o imposible de revisar.
8.7.2
Todos los cambios adoptados DEBEN ser versionados, documentados y trazables.
8.7.3
Los experimentos DEBEN estar acotados en el tiempo, explícitamente etiquetados y ser reversibles.
8.7.4
Los fallos importantes y las adaptaciones DEBEN capturarse como aprendizaje compartido, no borrarse ni ocultarse.

8.8 Reglas de explicitud

8.8.1
Lo siguiente DEBE ser explícito:
- Cómo cambian las reglas y quién decide
- Los procesos de versionado, autoridad y revisión
- El alcance, la duración y las condiciones de reversión de los experimentos
- Las condiciones y límites de los cambios de emergencia
8.8.2
Lo siguiente PUEDE ser explícito:
- La frecuencia y cadencia de revisión
- Las cláusulas de caducidad
- Los métodos de retroalimentación y detección
8.8.3
Lo siguiente DEBE permanecer opcional y fuera de alcance:
- El ritmo de innovación
- Las actitudes culturales hacia el riesgo dentro de los límites definidos

Núcleo RCOS v0.1 · §9 · Normativo

Secciones no normativas

Las secciones de este capítulo son informativas, no normativas.
No definen requisitos de cumplimiento, sino que proporcionan orientación, contexto, ejemplos y apoyo al aprendizaje para comunidades, implementadores, auditores y administradores del estándar.

Nada en esta sección puede anular o debilitar los requisitos definidos en las Capas 0–6.

9.1 Módulos opcionales

9.1.1
Los Módulos Opcionales son extensiones específicas de dominio que se construyen sobre RCOS-Core sin modificar sus capas obligatorias.
9.1.2
Los Módulos Opcionales DEBEN:
- Declarar qué capas de RCOS extienden o de cuáles dependen
- Indicar explícitamente cualquier rol, regla o artefacto adicional que introduzcan
- NO anular ni contradecir los invariantes de la Capa 0 ni los requisitos de RCOS-Core
9.1.3
Los Módulos Opcionales PUEDEN definir:
- Prácticas específicas de dominio
- Restricciones o estándares adicionales
- Patrones especializados de gobernanza u operación
9.1.4
Los dominios típicos de los Módulos Opcionales PUEDEN incluir, entre otros:
- Permacultura y gestión regenerativa del territorio
- Sistemas educativos alternativos o comunitarios
- Prácticas de salud, cuidados y bienestar
- Prácticas culturales o espirituales
- Especializaciones económicas (p. ej., cooperativas, fideicomisos de tierras, crédito mutuo)
9.1.5
La adopción de Módulos Opcionales DEBE seguir los mecanismos de cambio definidos en la Capa 6.
9.1.6
Una comunidad PUEDE ser conforme con RCOS-Core sin adoptar ningún Módulo Opcional.

9.2 Implementaciones de referencia

9.2.1
Una Implementación de Referencia es una comunidad real que documenta públicamente cómo aplica RCOS-Core.
9.2.2
Las Implementaciones de Referencia son descriptivas, no prescriptivas. Ilustran cómo se puede instanciar RCOS, no cómo se debe instanciar.
9.2.3
Una comunidad PUEDE declararse Implementación de Referencia de RCOS solo si:
- Es conforme con RCOS-Core
- Documenta públicamente sus artefactos de las Capas 0–6
- Indica claramente las desviaciones, experimentos o extensiones
9.2.4
La documentación de una Implementación de Referencia DEBERÍA incluir:
- Contexto y escala (tamaño, ubicación, propósito)
- Qué Módulos Opcionales se han adoptado
- Desafíos y fracasos conocidos
- Historial de evolución y adaptaciones principales
9.2.5
Las Implementaciones de Referencia NO DEBEN ser tratadas como interpretaciones autoritativas del estándar.

9.3 Modos de fallo conocidos

9.3.1
Los Modos de Fallo Conocidos documentan patrones de ruptura recurrentes observados en comunidades reales.
9.3.2
Los Modos de Fallo son señales informativas, no criterios de cumplimiento.
9.3.3
Los Modos de Fallo PUEDEN incluir, entre otros:
- Acumulación informal de poder
- Dominación por parte de fundadores o propietarios del terreno
- Dependencia de trabajo invisible o con sesgo de género
- Parálisis de gobernanza o sobrecarga de reuniones
- Bloqueo de salida o coerción sutil
- Captura económica mediante deuda o control de activos
- Evasión de conflictos que conduce a la fragmentación silenciosa
9.3.4
El propósito de documentar los Modos de Fallo es:
- Apoyar las pruebas de estrés de las estructuras RCOS
- Mejorar las decisiones de diseño
- Permitir la detección temprana en comunidades activas
9.3.5
La documentación de Modos de Fallo DEBERÍA hacer referencia a qué capas de RCOS están diseñadas para mitigar el patrón.

Núcleo RCOS v0.1 · §10 · Normativo

Cumplimiento y Auditoría

Este capítulo define cómo se evalúa y mantiene el cumplimiento de RCOS-Core.

10.1 Lista de Verificación de Cumplimiento

10.1.1
El cumplimiento de RCOS-Core es binario: una comunidad es conforme o no conforme.
10.1.2
El cumplimiento DEBE evaluarse por capa (Capas 0–6).
10.1.3
Para cada capa, la Lista de Verificación de Cumplimiento DEBE comprobar:
- Presencia de artefactos obligatorios
- Explicitud y accesibilidad de las reglas requeridas
- Adopción a través de procesos de gobernanza autorizados
10.1.4
El cumplimiento parcial o la "intención de cumplir" NO DEBE considerarse conforme.
10.1.5
Los Módulos Opcionales NO DEBEN incluirse en la evaluación de cumplimiento de RCOS-Core.

10.2 Casos de Prueba

10.2.1
Los Casos de Prueba son escenarios estructurados que se utilizan para validar si los mecanismos de RCOS funcionan según lo previsto.
10.2.2
Los Casos de Prueba PUEDEN ser:
- Escenarios hipotéticos
- Fracasos históricos de comunidades
- Pruebas de estrés simuladas
10.2.3
Los Casos de Prueba DEBERÍAN cubrir, como mínimo:
- Intentos de concentración de poder
- Escenarios de salida y separación
- Bloqueo de gobernanza
- Intentos de captura económica
- Conflictos críticos para la seguridad
10.2.4
Los Casos de Prueba son informativos, pero DEBERÍAN utilizarse durante auditorías, procesos de incorporación y revisiones periódicas.

10.3 Incumplimiento

10.3.1
Una comunidad DEBE considerarse no conforme si:
- Falta algún artefacto obligatorio
- Se violan los invariantes de la Capa 0
- Las decisiones se toman repetidamente fuera de las estructuras de gobernanza autorizadas
- La salida está bloqueada o restringida de manera informal
10.3.2
El incumplimiento DEBE reconocerse explícitamente una vez detectado.
10.3.3
Una comunidad PUEDE recuperar el cumplimiento únicamente mediante:
- Acción correctiva
- Adopción formal de los artefactos faltantes o corregidos
- Documentación de la remediación
10.3.4
Las declaraciones de cumplimiento de RCOS DEBEN retirarse durante los períodos de incumplimiento conocido.

Núcleo RCOS v0.1 · §11 · Normativo

Versionado y gobernanza del estándar

Este capítulo define cómo RCOS evoluciona como estándar.

11.1 Custodia del estándar

11.1.1
RCOS DEBE tener un órgano o proceso de custodia identificable.
11.1.2
Las responsabilidades del custodio DEBEN incluir:
- Mantener la especificación canónica
- Gestionar las publicaciones de versiones
- Curar materiales de referencia y aprendizaje
- Proteger los invariantes de Capa 0 del propio estándar
11.1.3
El custodio NO DEBE actuar como autoridad de cumplimiento sobre las comunidades.
11.1.4
La custodia de RCOS DEBE priorizar la claridad, la estabilidad y los aprendizajes del mundo real por encima de la pureza ideológica.

11.2 Proceso de cambio

11.2.1
Los cambios a RCOS-Core DEBEN seguir un proceso de cambio definido.
11.2.2
El proceso de cambio DEBE incluir:
- Presentación de propuestas
- Período público de revisión y comentarios
- Mecanismo y autoridad de decisión
- Versionado y publicación
11.2.3
La compatibilidad hacia atrás DEBERÍA preservarse cuando sea posible.
11.2.4
Los cambios incompatibles DEBEN estar claramente señalados y justificados.
11.2.5
Las versiones reemplazadas de RCOS DEBEN permanecer accesibles públicamente.
11.2.6
RCOS DEBE modelar los mismos principios que exige a las comunidades: explicitud, autoridad acotada, reversibilidad y aprendizaje.

Núcleo RCOS v0.1 · §A · Informativo

Apéndice A — Glosario

Este glosario proporciona definiciones informativas para los términos clave utilizados a lo largo de la especificación RCOS.
Las entradas del glosario no introducen nuevos requisitos y no prevalecen sobre las secciones normativas.

Rendición de cuentas (Accountability): La expectativa de que los roles y los miembros puedan ser llamados a explicar acciones, resultados y cumplimiento de las reglas acordadas, con mecanismos definidos de revisión y corrección.
Protocolo de rendición de cuentas (Accountability Protocol): Un artefacto que define cómo se revisan, documentan y abordan las violaciones, daños o fallos reiterados, incluyendo el debido proceso, salvaguardas y vías de escalamiento.
Artefacto: Un objeto documentado y versionado (p. ej., protocolo, registro, carta fundacional) adoptado mediante un proceso autorizado y utilizado para operativizar las capas de RCOS.
Límite de autoridad (Authority Boundary): Los límites explícitos dentro de los cuales un rol, círculo u órgano puede tomar decisiones o actuar.
Protocolo de cambios (Change Protocol): Un artefacto que define cómo se proponen, revisan, adoptan, publican y revierten los cambios, incluyendo la clasificación del tipo de decisión y las disposiciones de emergencia.
Bienes comunes (Commons): Recursos gobernados colectivamente bajo reglas explícitas de custodia, acceso y toma de decisiones.
Comunidad: Un grupo de personas que se coordinan voluntariamente en torno a un propósito compartido dentro de un ámbito y sistema de gobernanza definidos.
Cumplimiento (Compliance): El estado de satisfacer todos los requisitos obligatorios de RCOS-Core a lo largo de las Capas 0–6.
Escalera de resolución de conflictos (Conflict Resolution Ladder): Un proceso de conflicto por etapas que define los pasos mínimos de resolución y los umbrales de escalamiento, desde la reparación de baja intensidad hasta la revisión de gobernanza y, si es necesario, la separación.
Decisión constitucional: Una decisión que modifica el propósito, ámbito, invariantes o restricciones de identidad de la Capa 0, o el propio sistema de gobernanza.
Matriz de decisiones (Decision Matrix): Un artefacto de gobernanza que asocia tipos de decisiones y dominios con roles autorizados, mecanismos, umbrales y vías de escalamiento.
Tipo de decisión: Una clasificación de decisiones (Operativa, Estratégica, Constitucional) utilizada para determinar la autoridad y el proceso.
Debido proceso (Due Process): Las garantías mínimas de equidad requeridas antes de restringir derechos, aplicar sanciones o iniciar una separación, incluyendo notificación, revisión y vías de apelación según lo definido.
Cambio de emergencia: Un cambio con duración limitada promulgado bajo condiciones de emergencia explícitamente definidas, que requiere revisión posterior y ratificación o reversión.
Explícito: Escrito, adoptado, accesible y revisable.
Todo lo que no sea explícito se considera inexistente bajo RCOS.
Regla de explicitud (Explicitness Rule): El principio de que los mecanismos que asignan poder, riesgo, responsabilidad o condiciones de salida DEBEN estar escritos, adoptados y ser revisables.
Experimento: Un cambio con duración limitada y reversible, adoptado con fines de aprendizaje y evaluación.
Protocolo de salida y separación (Exit & Separation Protocol): Un artefacto que define la salida voluntaria, el debido proceso para la salida forzosa, y la separación de activos, roles, acceso y obligaciones.
Protocolo de gobernanza (Governance Protocol): Un artefacto que define el ciclo de vida de las decisiones (propuesta, deliberación, adopción, documentación, revisión) y cómo se resuelven los conflictos de gobernanza.
Dentro del ámbito / Fuera del ámbito (In-Scope / Out-of-Scope): Dentro del ámbito se refiere a las personas, activos, dominios y actividades explícitamente gobernados por la comunidad. Fuera del ámbito se refiere a todo lo explícitamente excluido o no declarado dentro del ámbito.
Protocolo de economía interna (Internal Economy Protocol): Un artefacto que define el reconocimiento de contribuciones y cualquier mecanismo de intercambio interno, incluyendo restricciones de acumulación y corrección de disputas.
Invariante: Una restricción no negociable que no puede ser anulada mientras esté en vigor.
Capa (Layer): Un dominio funcional de RCOS que define un aspecto específico del funcionamiento de la comunidad.
Registro de aprendizaje (Learning Log): Un artefacto que captura los fallos importantes, adaptaciones, reversiones y lecciones aprendidas, incluyendo desencadenantes, artefactos afectados y resultados.
Miembro: Una persona que ha ingresado explícitamente a la comunidad a través del proceso de membresía definido.
Módulo opcional: Una extensión específica de dominio que se basa en RCOS-Core sin alterar sus capas obligatorias.
Registro (Registry): Un artefacto que registra un conjunto de entradas autoritativas (p. ej., roles, recursos, estados de membresía) con titularidad clara, reglas de actualización e historial de versiones.
Implementación de referencia: Una comunidad del mundo real que documenta públicamente su aplicación de RCOS-Core.
Rol: Un conjunto explícitamente definido de responsabilidades, autoridad y rendición de cuentas, independiente de la persona que lo ocupa.
Crítico para la seguridad (Safety-Critical): Una condición en la que la seguridad física, psicológica o de menores está en riesgo, que requiere salvaguardas reforzadas y, potencialmente, acción protectora inmediata.
Sanción: Una restricción o acción correctiva definida y documentada, aplicada a través de un proceso autorizado, proporcional a la infracción y sujeta a revisión.
Ámbito (Scope): Los dominios, activos y actividades explícitamente declarados sobre los cuales la comunidad ejerce autoridad.
Custodia (Stewardship): La responsabilidad del cuidado, mantenimiento y gobernanza de un recurso dentro de límites definidos.
Tesorería (Treasury): El conjunto de recursos compartidos, saldos, obligaciones y compromisos gestionados bajo reglas colectivas.
Conjunto de reglas de tesorería (Treasury Ruleset): Un artefacto que define cómo se mantienen, gastan, reportan, auditan y limitan los recursos de la tesorería, incluyendo umbrales y reglas de conflicto de intereses.
Excepción de transparencia (Transparency Exception): Una limitación explícitamente definida, justificada y con duración limitada al acceso a la información, que aún permite la auditoría de cumplimiento.
Historial de versiones (Version History): Un artefacto que registra qué versión está en vigor y documenta los cambios adoptados, las fechas de entrada en vigencia y las referencias a las decisiones.

Núcleo RCOS v0.1 · §B · Informativo

Apéndice B — Artefactos de Ejemplo (No Normativo)

Este apéndice proporciona ejemplos ilustrativos de artefactos referenciados en la especificación.
Los ejemplos son solo informativos y no deben tratarse como formatos o implementaciones obligatorios.

B.1 Ejemplo de Carta de Propósito (Extracto)

- Propósito principal (singular): "Mantener y cuidar un lugar de vida compartido y regenerativo que proporcione vivienda estable y restauración ecológica."
- Propósitos secundarios (delimitados):
  - "Operar un pequeño programa educativo sobre prácticas regenerativas."
  - "Gestionar una cooperativa propiedad de los miembros para la producción local de alimentos."
- No-objetivos / exclusiones:
  - "No es un partido político."
  - "No es un colectivo de proyecto a corto plazo."
  - "No es un vehículo inmobiliario con fines de lucro."
- Condiciones para el cambio de propósito:
  - "Los cambios de propósito requieren una decisión constitucional y una re-ratificación completa."
- Registro de ratificación:
  - Adoptado: 2026-01-01
  - Tipo de decisión: Constitucional
  - Versión: 0.3
  - Enlace al registro de decisión: [marcador de posición]

B.2 Ejemplo de Declaración de Alcance (Extracto)

- Activos dentro del alcance:
  - Parcela de terreno "North Field"
  - Edificios: "Common House", "Workshop"
  - Fondos compartidos: tesorería operativa, fondo de reserva
  - Infraestructura compartida: sistema de agua, instalación solar, vehículos compartidos
- Dominios de autoridad dentro del alcance:
  - Reglas de gobernanza y proceso de decisión (Capa 2)
  - Reglas y estados de membresía (Capa 1)
  - Tesorería y asignación de recursos compartidos (Capa 3)
  - Coordinación operativa para el trabajo compartido (Capa 5)
- Dominios fuera del alcance:
  - Ingresos personales, deudas privadas y cuentas bancarias privadas
  - Relaciones privadas y espacios de vida privados (excepto condiciones críticas de seguridad)
  - Negocios fuera del sitio que no utilicen activos comunitarios

B.3 Ejemplo de Matriz de Decisiones (Extracto)

Dominio de Decisión	Tipo de Decisión	Órgano Autorizado	Mecanismo	Umbral	Escalamiento
Aprobación de presupuesto (anual)	Estratégica	Círculo de Finanzas	Consentimiento	Sin objeciones	Círculo General
Gasto de emergencia ≤ 500	Operacional	Tesorero/a	Autoridad delegada	N/A	Círculo de Finanzas
Gasto 501–5.000	Estratégica	Círculo de Finanzas	Votación	Mayoría	Círculo General
Agregar/eliminar un invariante central	Constitucional	Círculo General	Votación	Supermayoría (80%)	Revisión constitucional
Nombramiento de rol	Operacional	Líder de Círculo	Consentimiento	Sin objeciones	Círculo de Gobernanza

B.4 Ejemplo de Protocolo de Economía Interna (Extracto)

- Categorías de contribución reconocidas:
  - Trabajo (mantenimiento, construcción, producción de alimentos)
  - Cuidado (cuidado de infancias, cuidado de personas mayores, apoyo en conflictos)
  - Conocimiento (formación, documentación, facilitación)
  - Custodia (mantenimiento de recursos, supervisión de adquisiciones)
- Mecanismo de registro:
  - Registro semanal de contribuciones enviado por los miembros
  - Revisión mensual por el Círculo de Operaciones para consistencia y correcciones
- Unidades internas (opcional):
  - "Créditos de tiempo" registrados en horas para ciertas asignaciones compartidas
- Restricciones de acumulación (si existen unidades internas):
  - Topes de saldo
  - Caducidad después de 12 meses salvo renovación por revisión
- Disputa y corrección:
  - Cualquier miembro puede solicitar la revisión de un registro dentro de los 30 días
  - Las correcciones requieren justificación documentada y se registran en un historial de cambios

B.5 Ejemplo de Escalera de Resolución de Conflictos (Extracto)

1. Conversación directa (reparación informal)
2. Mediación facilitada (facilitador/a neutral seleccionado/a de una lista aprobada)
3. Recepción de rendición de cuentas (recepción documentada; salvaguardas contra represalias activadas)
4. Revisión de rendición de cuentas (hallazgos, plan de reparación y respuestas proporcionales)
5. Decisión de gobernanza (si deben cambiar autoridad, acceso o roles)
6. Proceso de separación (si es necesario; coordinado con el protocolo de salida y separación de la Capa 1)

B.6 Ejemplo de Plantilla de Propuesta de Cambio (Extracto)

- Título del cambio:
- Resumen (1–3 oraciones):
- Capas y artefactos afectados (enlaces):
- Tipo de cambio:
  - Cambio permanente / Experimento
- Tipo de decisión y ruta de decisión autorizada (referencia a la Matriz de Decisiones):
- Justificación:
- Riesgos y mitigaciones:
- Plan de transición y migración:
- Plan de reversión y disparadores de reversión:
- Fecha de vigencia y fecha de revisión:

B.7 Ejemplo de Acuerdo de Membresía (Extracto)

- Estado de membresía al firmar: Prueba / Plena
- Derechos de los miembros (ejemplos):
  - Acceso a los registros de decisiones definidos como transparentes
  - Derechos de participación según el tipo de decisión
  - Una ruta de salida definida en todo momento
- Obligaciones de los miembros (ejemplos):
  - Expectativas de contribución según el rol y el estado de membresía
  - Adhesión a los invariantes declarados y las reglas de seguridad
  - Participación en los procesos mínimos de incorporación y revisión
- Referencia al debido proceso:
  - "Cualquier salida forzada o restricción de acceso sigue el debido proceso de la Capa 4 y el protocolo de salida."

B.8 Ejemplo de Protocolo de Incorporación (Extracto)

1. Proporcionar acceso a los artefactos RCOS (Capas 0–6) y módulos locales
2. Confirmar consentimiento explícito a los artefactos de la Capa 0 y la Capa 1
3. Asignar estado de membresía inicial y compañero/a de incorporación
4. Completar la orientación sobre seguridad y procesos de conflicto
5. Revisar los límites de alcance y lo que está fuera del alcance
6. Registrar la finalización de la incorporación en el registro de membresía

B.9 Ejemplo de Entrada en el Registro de Roles (Extracto)

- Nombre del rol: Tesorero/a
- Propósito: Mantener los registros de tesorería y ejecutar pagos autorizados
- Alcance de autoridad:
  - Ejecutar pagos ≤ 500 dentro de categorías aprobadas
- Límites:
  - Sin autoridad para aprobar presupuestos ni alterar reglas de transparencia
- Mandato:
  - 6 meses, renovable una vez sin revisión
- Rendición de cuentas:
  - Informe de tesorería publicado mensualmente; verificación de auditoría trimestral
- Nombramiento/remoción:
  - Nombrado/a por el Círculo de Finanzas; removible mediante revisión del Círculo de Gobernanza

B.10 Ejemplo de Conjunto de Reglas de Tesorería (Extracto)

- Transparencia:
  - Balance mensual y resumen de flujo de caja publicados para todos los miembros
- Umbrales de gasto:

Monto	Tipo de Decisión	Órgano Autorizado	Mecanismo
≤ 500	Operacional	Tesorero/a	Delegado
501–5.000	Estratégica	Círculo de Finanzas	Votación por mayoría
> 5.000	Estratégica	Círculo General	Votación por mayoría
Deuda / obligación a largo plazo	Constitucional	Círculo General	Supermayoría

- Conflicto de intereses:
  - Un solicitante no puede aprobar su propia solicitud de gasto

B.11 Ejemplo de Plantilla de Reunión (Extracto)

- Tipo de reunión: Operaciones
- Fecha/hora:
- Facilitador/a:
- Asistentes:
- Agenda:
  1. Ronda de apertura (con tiempo limitado)
  2. Revisión de acciones anteriores
  3. Actualizaciones operativas
  4. Decisiones (si las hay)
  5. Próximas acciones y responsables
- Registro de decisión (si se usa):
  - Tipo de decisión:
  - Autoridad:
  - Mecanismo/umbral:
  - Resultado:
  - Fecha de vigencia:

B.12 Ejemplo de Entrada en el Registro de Aprendizaje (Extracto)

- Fecha:
- Evento desencadenante:
- Qué sucedió (narrativa breve):
- Capas/artefactos implicados:
- Señales que desencadenaron la acción:
- Qué cambió (o qué se intentó):
- Resultado después de la revisión:
- Responsable de la acción de seguimiento y fecha límite:

Núcleo RCOS v0.1 · §C · Informativo

Apéndice C — Resumen de implementación de referencia

Este apéndice define una estructura de documentación recomendada para comunidades que deseen presentarse como Implementaciones de Referencia de RCOS. El objetivo es hacer que la adopción sea auditable, comparable y útil para el aprendizaje, sin implicar un respaldo.

C.1 Contexto de la comunidad

- Nombre y ubicación
- Tamaño y escala (p. ej., 12 miembros; 3 hogares; 25 hectáreas)
- Propósito principal (Capa 0)
- Fecha de fundación y fecha de adopción de RCOS (si difiere)
- Forma(s) jurídica(s) relevante(s) (si las hay)
- Punto de contacto público

C.2 Resumen de adopción de RCOS

- Versión de RCOS-Core en uso
- Referencia del registro de decisión de adopción (autoridad, mecanismo, fecha)
- Resumen de Módulos Opcionales adoptados (si los hay), incluyendo:
  - Nombre y alcance del módulo
  - Fecha de adopción
  - Enlace a la especificación del módulo
  - Dependencias de capa declaradas

C.3 Resumen capa por capa

Para cada capa (0–6):
- Artefactos implementados (con enlaces)
- Desviaciones o adaptaciones (con enlaces)
- Desafíos conocidos y modos de fallo encontrados
Formato recomendado:

Capa	Artefactos requeridos implementados	Enlace(s) público(s)	Versión/fecha	Notas
0	Carta de Propósito; Declaración de Alcance; Registro de Invariantes	[placeholder]	v0.3 / 2026-01-01	Propósito estable; invariantes revisadas trimestralmente
1	Acuerdo de Membresía; Protocolo de Incorporación; Protocolo de Salida y Separación; Registro de Estado de Membresía	[placeholder]	v1.1 / 2026-02-15	Período de prueba de 3 meses
2	Matriz de Decisiones; Protocolo de Gobernanza; Registro de Autoridad	[placeholder]	v0.8 / 2026-03-10	Consentimiento para operaciones, votación para estrategia
3	Protocolo de Economía Interna; Reglamento de Tesorería	[placeholder]	v0.5 / 2026-03-20	Informes mensuales de tesorería publicados
4	Escalera de Resolución de Conflictos; Protocolo de Rendición de Cuentas	[placeholder]	v0.6 / 2026-04-01	Política anti-represalias incluida
5	Manual de Operaciones; Registro de Roles; Plantillas de Reuniones	[placeholder]	v0.4 / 2026-04-15	Carga de reuniones limitada a 4h/semana
6	Protocolo de Cambios; Historial de Versiones; Registro de Aprendizajes	[placeholder]	v0.2 / 2026-05-01	Los experimentos expiran si no se renuevan

C.4 Gobernanza y evolución

- Mecanismos de decisión en uso (con extracto de la Matriz de Decisiones o enlace)
- Historial de cambios y experimentos (con enlaces a registros de cambios)
- Aprendizajes principales y fallos (con enlaces a entradas del Registro de Aprendizajes)
- Registro de desviaciones (recomendado):

Elemento	Capa(s)	Tipo	Estado	Inicio	Revisión/Fin	Enlace
Prueba de facilitación rotativa	5	Experimento	Activo	2026-06-01	2026-08-01	[placeholder]
Excepción de transparencia de tesorería (seguridad)	3/4	Permanente	Activo	2026-04-10	Revisión anual	[placeholder]

C.5 Declaración de cumplimiento

- Estado de cumplimiento actual: Cumple / No cumple / Desconocido
- Fecha de la última autoauditoría o auditoría externa
- Método de auditoría (autoauditoría vs. externa)
- Períodos conocidos de incumplimiento (si los hay) y resumen de remediación
- Enlaces de evidencia (recomendado):

Evidencia	Fecha	Enlace
Resultado de la lista de verificación capa por capa	2026-07-01	[placeholder]
Notas / hallazgos de auditoría	2026-07-01	[placeholder]
Registro de remediación	2026-07-15	[placeholder]

Períodos conocidos de incumplimiento (si los hay)

C.6 Transparencia pública

- Índice de artefactos públicos (recomendado):

Artefacto	Capa	Enlace público	Versión/fecha	Notas
Carta de Propósito	0	[placeholder]	2026-01-01
Matriz de Decisiones	2	[placeholder]	2026-03-10
Informes de tesorería	3	[placeholder]	2026-06-30	mensual
Registro de Aprendizajes	6	[placeholder]	2026-06-15	redacciones indicadas

- Canal de contacto o consultas
- Declaración explícita de qué es privado y qué es público, y por qué
- Enlace a la versión actual de RCOS-Core utilizada y registro de cambios
- Canal de contacto o consultas

Nota informativa

Las Implementaciones de Referencia son instrumentos de aprendizaje, no respaldos.