De dónde viene el modelo de anillos

Explicación vigente de ASILO 0.1. Los antecedentes orientan el diseño; los requisitos aceptados conservan su alcance y autoridad.

Esta página ayuda a elegir y explicar un modelo de capas. En ASILO, los anillos representan fronteras de responsabilidad que un perfil declara y comprueba. Su forma circular permite leer el sistema desde sus reglas hasta sus mecanismos externos. La posición de una pieza no concede permisos ni demuestra que un fallo quede contenido.

El cuaderno de investigación del método reúne ideas de arquitectura, protección informática, compartimentación y regulación. Esta revisión organiza esos referentes y contrasta el modelo con código de una implementación. Las fuentes siguientes documentan cada tradición; la relación que proponemos con ASILO es una síntesis editorial del método. No atribuyen a sus autores la creación o aprobación de ASILO.

Cuatro antecedentes con propósitos distintos

Referente documentado	Qué explica	Qué aporta a esta guía
Anillos de protección, Schroeder y Saltzer, 1972; trabajo presentado en 1971.	Mecanismos de procesador que controlan privilegios y cruces entre anillos.	Preguntar qué mecanismo controla cada cruce. Publicación del autor en MIT.
Puertos y adaptadores, Cockburn, 2005.	Separación entre el interior de una aplicación y tecnologías externas mediante puertos y adaptadores intercambiables.	Mantener las reglas independientes de mecanismos concretos. Los seis lados del dibujo no son esenciales. Artículo original.
Onion Architecture, Palermo, 2008.	Dependencias dirigidas hacia el núcleo, con infraestructura en la periferia.	Explicar la dirección de dependencias y la sustitución de infraestructura. Artículo original.
Clean Architecture, Martin, 2012.	Dependencias de código hacia políticas internas, separadas de mecanismos externos. Sus círculos son esquemáticos.	Declarar responsabilidades y dependencias sin fijar una cantidad universal de capas. Artículo original.

Un anillo de protección controla acceso en un entorno de ejecución. Una capa de arquitectura agrupa código y declara sus dependencias. ASILO utiliza la representación de capas y pide declarar el modelo cuando corresponde; un perfil identifica los controles de ejecución que necesita. Las reglas de importación, la autorización y el aislamiento aportan evidencias diferentes.

La defensa en profundidad combina personas, tecnología y operación mediante barreras complementarias. Es otro referente para distribuir controles; una serie de círculos no constituye esas barreras. Definición de NIST. Las fuentes consultadas no permiten atribuir a todos estos modelos un único origen militar.

Cómo se reúnen en ASILO

flowchart TD
  accTitle: ASILO: referentes complementarios del modelo de anillos
  accDescr: Tres tradiciones aportan preguntas diferentes. La síntesis editorial desemboca en un perfil declarado y controles con evidencia propia; las flechas no representan una genealogía demostrada.
  A["Arquitectura: puertos, Onion y Clean"] -->|organizar dependencias| S["ASILO: declarar fronteras y responsabilidades"]
  P["Protección: privilegios y capacidades"] -->|controlar cruces y efectos| S
  D["Defensa en profundidad y contención"] -->|combinar controles| S
  S --> M["Perfil: modelo, reglas y excepciones"]
  M --> E["Implementación: mecanismos y resultados"]

Gráfico SVG · Fuente Mermaid.

Las tres primeras flechas expresan aportaciones a esta explicación. Las dos últimas muestran el recorrido desde una decisión metodológica hasta mecanismos observables. No afirman una sucesión histórica entre autores ni una certificación de seguridad.

Por qué aparecen cuatro o cinco capas

La vista ilustrativa de anillos agrupa reglas y tipos en un núcleo y muestra cuatro responsabilidades: núcleo, contratos, adaptadores y composición. Los apuntes de diseño también describen cinco: tipos o kernel, lógica de dominio, contratos, adaptadores y aplicación. Kernel significa aquí núcleo de tipos, no núcleo de un sistema operativo.

Modelo de cuatro agrupaciones	Modelo que separa cinco responsabilidades
Núcleo: reglas y tipos.	Núcleo de tipos + lógica de dominio.
Contratos o puertos.	Contratos o puertos.
Adaptadores.	Adaptadores.
Aplicación o composición.	Aplicación o composición.

Es una comparación de responsabilidades, no una equivalencia de números. Separar el dominio puede aclarar un sistema grande; agruparlo puede bastar para uno pequeño. Un perfil declara sus nombres, dirección de dependencias, excepciones y herramientas. ASILO-R-002 no exige cuatro ni cinco anillos; conserva también la condición para sistemas de un solo módulo. Consulta el requisito aceptado.

Qué enseñó la revisión de una implementación

La revisión de código del 14-oct-2026 confirmó que un mapa de capas, una regla de dependencias y un control de ejecución deben contrastarse por separado. Encontrar un script o una prueba en el repositorio demuestra que existe; registrar su ejecución y resultado demuestra otra cosa. La nota de software relacionado identifica esa relación sin convertirla en conformidad.

Elemento observado	Comprobación que debe registrarse en el perfil
Mapa de responsabilidades.	Los módulos existen y su responsabilidad coincide con el mapa actual.
Reglas en herramientas diferentes.	Cubren el mismo alcance o declaran sus diferencias; las excepciones tienen responsable y vigencia.
Contexto, permisos y validación de entradas.	Contexto no equivale a identidad autenticada; formato válido no equivale a autorización.
Pruebas, flujos de CI y registros de auditoría.	Identificar entorno, ejecución, resultados, persistencia y límites de la evidencia.

Estas preguntas sirven también para un solo asistente que puede leer y escribir archivos. El control de dependencias revisa imports; el control de autorización comprueba si ese asistente puede borrar ese archivo. Una prueba negativa debe comprobar el rechazo y la ausencia del borrado. El alcance de IA no depende de tener varios agentes.

Continúa con analogías entre disciplinas, áreas y contextos o capas y anillos.