Translation

Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.

Where the ring model comes from

Current explanation of ASILO 0.1. Background informs design; accepted requirements retain their scope and authority. Informative translation from Spanish.

This page helps readers choose and explain a layering model. In ASILO, rings represent responsibility boundaries that a profile declares and checks. Their circular shape helps read a system from its rules to its external mechanisms. A component's position grants no permissions and does not demonstrate failure containment.

The method's research notebook brings together ideas from architecture, computer protection, compartmentalization and regulation. This review organizes those references and compares the model with implementation code. The sources below document each tradition; their proposed relationship with ASILO is the method's editorial synthesis. They do not attribute ASILO's creation or approval to those authors.

Four documented approaches with different purposes

Documented reference	What it explains	Contribution to this guide
Protection rings, Schroeder and Saltzer, 1972; work presented in 1971.	Processor mechanisms controlling privileges and crossings between rings.	Ask which mechanism controls each crossing. Author's publication at MIT.
Ports and adapters, Cockburn, 2005.	Separation of an application's interior from external technologies through ports and interchangeable adapters.	Keep rules independent of specific mechanisms. The drawing's six sides are not essential. Original article.
Onion Architecture, Palermo, 2008.	Dependencies pointing toward the core, with infrastructure at the periphery.	Explain dependency direction and infrastructure replacement. Original article.
Clean Architecture, Martin, 2012.	Code dependencies toward internal policies, separated from external mechanisms. Its circles are schematic.	Declare responsibilities and dependencies without a universal layer count. Original article.

A protection ring controls access in an execution environment. An architectural layer groups code and declares dependencies. ASILO uses layers as a representation and requires a declared model when applicable; a profile identifies the execution controls it needs. Import rules, authorization and isolation provide different evidence.

Defense in depth combines people, technology and operations through complementary barriers. It provides another reference for distributing controls; drawing circles does not create those barriers. NIST definition. The consulted sources do not establish a single military origin for all these models.

How ASILO brings these ideas together

flowchart TD
  accTitle: ASILO: complementary references for the ring model
  accDescr: Three traditions contribute different questions. The editorial synthesis leads to a declared profile and controls with their own evidence; arrows do not claim a demonstrated genealogy.
  A["Architecture: ports, Onion and Clean"] -->|organize dependencies| S["ASILO: declare boundaries and responsibilities"]
  P["Protection: privileges and capabilities"] -->|control crossings and effects| S
  D["Defense in depth and containment"] -->|combine controls| S
  S --> M["Profile: model, rules and exceptions"]
  M --> E["Implementation: mechanisms and results"]

SVG graphic · Mermaid source.

The first three arrows express contributions to this explanation. The last two show the path from a methodological decision to observable mechanisms. They assert neither a historical sequence between authors nor a security certification.

Why four or five layers appear

The illustrative ring view groups rules and types into one core and shows four responsibilities: core, contracts, adapters and composition. Design notes also describe five: types or kernel, domain logic, contracts, adapters and application. Here, kernel means a core of types, rather than an operating system kernel.

Four-group model	Model separating five responsibilities
Core: rules and types.	Type core + domain logic.
Contracts or ports.	Contracts or ports.
Adapters.	Adapters.
Application or composition.	Application or composition.

This compares responsibilities, without equating numbers. Separating the domain may clarify a large system; grouping it may suffice for a small one. A profile declares its names, dependency direction, exceptions and tools. ASILO-R-002 requires neither four nor five rings; it also retains the condition for single-module systems. See the accepted requirement.

Lessons from inspecting an implementation

The code inspection on 14 October 2026 confirmed that a layer map, a dependency rule and an execution control require separate comparison. Finding a script or test in a repository shows it exists; recording its execution and result demonstrates something else. The related software note identifies the relationship without establishing conformity.

Observed element	Check to record in the profile
Responsibility map.	Modules exist and their responsibilities match the current map.
Rules in different tools.	They cover the same scope or declare their differences; exceptions have an owner and a stated validity period.
Context, permissions and input validation.	Context does not equal authenticated identity; valid format does not equal authorization.
Tests, CI workflows and audit records.	Identify environment, execution, results, persistence and limits of the evidence.

These questions also apply to one assistant that can read and write files. A dependency control checks imports; an authorization control checks whether that assistant may delete that file. A negative test should verify rejection and the absence of deletion. AI scope does not depend on having multiple agents.

Continue with analogies across disciplines, areas and contexts or layers and rings.