Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
ASILO areas, contexts and layers¶
Current explanatory guide. Classifications help readers understand and apply ASILO 0.1; requirements retain their applicability conditions. Informative translation from Spanish.
Design notes bring together knowledge areas, application contexts and architectural layers. Each classification answers a different question. Start by choosing the problem you want to address, then consult the relevant requirement and evidence.
Six areas for reading the documentation¶
| Knowledge area | Useful question | Artifact or reading |
|---|---|---|
| Foundations. | What does the method delimit, and what authority does each text have? | Purpose and limits, requirements. |
| Software architecture. | Which responsibilities exist, and what may depend on what? | Declared model and layers and rings. |
| Security. | Which assets, actors, permissions and effects need controls? | Threat model, capabilities. |
| AI model. | What context does AI receive, and which actions may it propose or execute? | AI scope, limits and human review. |
| Measurement and evaluation. | Which observable results support the controls? | Boundary tests, failures and remaining risks. |
| Adoption and evolution. | What applies now, and how is a change reviewed? | Adoption, profile and evolution. |
These reading areas can overlap. Security uses architectural decisions and evaluation results. A layer number identifies neither one of these areas nor a maturity level.
Three contexts explored in the notes¶
| Context | Useful relationship | Scope of this documentation |
|---|---|---|
| Software built with AI assistance. | Delimit context, data, permissions, resources and effects. | Application of ASILO 0.1 according to its requirements and exceptions, with one or more AI components. |
| Organizations and institutions. | Compare responsibilities, handoffs and decision boundaries. | Analogy for analyzing coordination. An organization using AI applies relevant requirements to its declared system; the comparison does not establish general legal compliance. |
| Everyday life and personal use. | Compare available resources, reversible decisions and review of consequences. | Accessible explanation. A personal assistant with file access can fall within the declared system; the analogy does not turn ASILO into a health, finance or household management standard. |
The broader contexts come from research into the method. This guide explains those relationships without creating an additional edition or extending accepted requirements by analogy to every human activity. See scope and software.
How the classifications relate¶
flowchart TD
accTitle: ASILO: areas, contexts and layers are different classifications
accDescr: A case is described through its knowledge area, use context and a responsibility model when applicable. Relevant requirements and evidence are identified separately.
C["Case: an assistant prepares a document"] --> A["Area: security, architecture or evaluation"]
C --> X["Context: software, organization or personal use"]
C --> M["Model: responsibilities and dependencies"]
A --> F["Card: scope, applicable requirements and evidence"]
X --> F
M --> F
The arrows show three descriptions of the same case coming together in a card. They do not order privileges or maturity levels. The use context alone does not determine which requirements apply: review the conditions of each ID in the accepted edition.
Example with one assistant¶
A person asks an assistant to prepare a document from authorized files. The architecture area defines rules, a reading contract and a file adapter. The security area limits the operation to reading permitted resources. The evaluation area checks that an attempted write is rejected and no file changes. The context may be personal or organizational; the AI system and its effects are declared in the same way.
If the assistant only produces text without tools or direct file access, the profile records that condition and reviews applicable obligations. It does not add nonexistent operational capabilities to complete a diagram.
See ring origins, analogies across disciplines and architecture and security.