Iniciativa de reemplazo soberano
La Iniciativa de Reemplazo Soberano es el programa formal que registra cada dependencia foránea en un libro contable estructurado, aplica aislamiento de cuarentena hasta que un reemplazo nativo esté listo, y retira la dependencia una vez que el reemplazo alcanza paridad estructural.
El problema estructural
Cualquier plataforma que haya pasado por una fase de transformación digital hereda componentes arquitectónicos de terceros que no diseñó. La dependencia de esos componentes — proveedores de autenticación en la nube propietarios, controladores de GPU foráneos, APIs de grafos comerciales — crea un riesgo estructural: si un proveedor de terceros cambia sus condiciones de servicio o depreca una API, la plataforma dependiente debe adaptarse bajo presión o detenerse.
El libro contable de dependencias
La Iniciativa mantiene un libro contable físico de dependencias de terceros pendientes. Cada entrada registra la dependencia, el riesgo estructural que representa, y el estado de la iniciativa moonshot que construye el reemplazo. Véase Iniciativas Moonshot para el estado de construcción por iniciativa — existen veintitrés directorios moonshot hoy, de los cuales tres llevan ingeniería activa sustancial, seis siguen siendo esqueletos, y catorce aún no se evalúan individualmente.
El libro contable hace la deuda visible. La visibilidad evita que se acumule silenciosamente — una dependencia no registrada es una dependencia que no recibe priorización de ingeniería.
Criterios de finalización
Una entrada del libro contable se cierra cuando la iniciativa moonshot asociada alcanza paridad estructural con el componente en cuarentena que reemplaza. La paridad estructural tiene tres condiciones:
- Cobertura funcional. La implementación nativa cubre todos los casos de uso de la plataforma que actualmente sirve el componente en cuarentena.
- Supersesión física. El directorio
vendor-*en cuarentena se elimina del repositorio. No quedan referencias en el código fuente al componente reemplazado. - Objetivo de verificación formal. Para componentes en la capa de kernel, la implementación nativa satisface el requisito de verificación formal de la plataforma (compatible con seL4, memoria segura, sin desbordamiento de búfer). Para componentes en la capa de aplicación, se cumplen los requisitos de cobertura de pruebas y la integración con el libro contable de auditoría.
Hasta que se cumplan las tres condiciones, la cuarentena permanece activa y la entrada del libro contable sigue abierta.
Relación con ADR-08
La Decisión de Arquitectura 8 registra formalmente el sistema de inicio systemd como una dependencia en cuarentena — la dependencia que la plataforma acepta mientras la iniciativa moonshot-kernel avanza hacia el reemplazo con el micronúcleo seL4. La Iniciativa de Reemplazo Soberano es el mecanismo de gobernanza que da fuerza operativa a ADR-08: sin el libro contable, la cuarentena es una declaración de intención; con el libro contable, es un compromiso rastreado con una trayectoria de finalización definida.
Véase también
- Iniciativas Moonshot — cada programa de ingeniería activo que esta iniciativa coordina
- Sustrato del micronúcleo seL4 — el micronúcleo formalmente verificado que es el objetivo final para los reemplazos en la capa de kernel
- Gobernanza ontológica — la gobernanza de clasificación que opera junto con la gobernanza de dependencias
- Inspector de verificación — el agente de auditoría que confirma la finalización del reemplazo contra el libro mayor
- Hospedaje por el cliente — la propiedad de separación que permite la eliminación de dependencias foráneas
Cite this record: /wiki/sovereign-replacement-initiative — revision 7fd0f305, last updated 19 May 2026.