Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Concepts — current methodology guide¶
Current explanatory documentation for ASILO 0.1, MILPA 0.1 and SCAFFOLD 0.1. It defines terms and preserves the scope of the accepted editions.
This page sets the minimum vocabulary needed to read the rest of the site. It explains; it does not oblige.
ASILO, MILPA and SCAFFOLD¶
| Name | What it is | Where it is documented | What it is not |
|---|---|---|---|
| ASILO | Methodology for defining, applying and reviewing engineering limits in systems built with artificial intelligence (AI) assistance. | This site | A product, a package or a security guarantee. |
| SCAFFOLD | Approved methodology for managing software projects built by people and AI assistants, from framing to delivery: charter and planned work, crews, zones, handoffs, batches, branches, environments and releases. | This site | A code scaffolding generator or a software tool. |
| MILPA | Methodology for giving a project's knowledge a recognizable place, owner, provenance and status. | This site | An ecosystem manager or an agent taxonomy. |
Each piece of software documents its capabilities in its own repository; the method and implementation guide explains that boundary.
Method, profile, example and implementation¶
- Principle: a foundation that guides decisions; it is not verified directly.
- Requirement: a verifiable obligation derived from a principle, with an actor, a condition and evidence.
- Profile: application of requirements to a specific context (a language, a type of project).
- Example: an illustration; it never creates an obligation.
- Implementation: software that attempts to cover parts of one or more requirements. Its coverage is demonstrated with a version, an executed test and a result.
The requirement record defines how each type is written.
“Level” has several meanings¶
The word level is used for different classifications. None of them becomes another by sharing a name or a number.
| Classification | What it orders |
|---|---|
| Document authority: Canon · Reference · Evidence | Authority and change regime of a document |
| Claim certainty: Canon · Evidence · Reference · Hypothesis | Empirical strength of a claim |
| Data exposure: 1 Public · 2 Internal · 3 Confidential · 4 Critical | Harm from exposure; decides what may enter a model's context |
| Personal data: PII-1 … PII-4 and PII-M | Type of personal data; decides retention |
Each scale is named by its purpose (in bold) and there is no correspondence between them. The first two use almost the same names with a different order and a different meaning: “Evidencia” (Evidence, in the Spanish document-authority scale) is the third value of one and “Evidence” is the second of the other. Translating one into the other would fabricate authority or certainty; MILPA-R-003 forbids it.
Layers, rings and zones¶
These models answer different questions:
- Architectural layers: group rules, contracts and mechanisms in a declared model.
- Profile rings: define concrete layers and dependency rules; numbering is not universal.
- Trust zones: bound access to resources and actors; layers alone do not determine them.
The method does not choose one of them: requirement ASILO-R-002 asks you to declare the model in use and to check the direction of dependencies.
The milpa analogy¶
Maize, beans and squash are an analogy about relationships and mutual care. They do not define agent roles, permissions or a product taxonomy.
AI and agent count¶
ASILO bounds systems built with AI assistance; SCAFFOLD manages software projects built with AI. A multi-agent system is one particular case. AI scope defines model, assistant and agent while preserving each requirement’s conditions.