Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Normative language and requirement record¶
Informative translation. The Spanish text is authoritative. If the two differ, the Spanish version prevails.
Common rule for ASILO 0.1 and MILPA 0.1.
Purpose¶
A rule can only be complied with, audited or discussed if it is known what it obliges, whom, when and how it is checked. This page proposes the vocabulary and the minimum record that the ASILO and MILPA requirements on this site will use.
Keywords¶
This repository adapts the BCP 14 criterion (RFC 2119 and RFC 8174) to Spanish. It does not claim conformance with those RFCs, which define English words. The Spanish edition uses DEBE, NO DEBE, DEBERÍA, NO DEBERÍA and PUEDE; this English translation renders them as MUST, MUST NOT, SHOULD, SHOULD NOT and MAY, with the meaning defined in RFC 2119 and RFC 8174. The proposed correspondence is:
| Word on this site (Spanish) | BCP 14 equivalent | Meaning |
|---|---|---|
| DEBE | MUST / REQUIRED / SHALL | Obligation with no alternative within the scope of the requirement. |
| NO DEBE | MUST NOT / SHALL NOT | Prohibition with no alternative within the scope. |
| DEBERÍA | SHOULD / RECOMMENDED | Expected to be met; departing from it requires a recorded reason and acceptance of the risk. |
| NO DEBERÍA | SHOULD NOT / NOT RECOMMENDED | Expected to be avoided; doing it requires a recorded reason and acceptance of the risk. |
| PUEDE | MAY / OPTIONAL | Permitted option; it creates no obligation. |
Following the RFC 8174 rule, these words have normative meaning only when they appear in uppercase. In lowercase they keep their ordinary meaning.
While a requirement is proposed, its MUST describes the obligation it would have if it were
accepted; today it obliges no one. No audit may declare non-compliance with a requirement
that is not accepted.
States¶
| State | Meaning | Who assigns it |
|---|---|---|
draft |
Text being written; may change without notice. | Author |
proposed |
Complete, traceable wording, ready for decision. It does not oblige. | Author, with provenance |
accepted |
Obliges within its scope from an identified version. | Only the human owner, with a recorded decision |
deprecated |
Replaced or withdrawn; kept for traceability. | Human owner |
historical |
Explains provenance; does not govern. | Human owner or curation |
A label in a source document (for example, “canon”) is not equivalent to accepted: authority
is resolved by the owner's recorded decision, not by the label.
Minimum requirement record¶
Each requirement records these fields:
| Field | What it contains |
|---|---|
| ID | Stable identifier (ASILO-R-NNN, MILPA-R-NNN). It is not reused even if the requirement is retired. |
| State | One of the states above. |
| Class | Agnostic principle, agnostic requirement, technology profile or example. |
| Problem | What failure or harm it prevents. |
| Scope | Systems, artifacts or activities it refers to. |
| Responsible actor | Human role who answers for compliance. |
| Applicability condition | When it is activated; outside it, it does not apply. |
| Verifiable statement | The rule, with keywords in uppercase. |
| Expected evidence | Artifacts that would make it possible to check compliance. |
| Exception | How a departure is authorized and what must be recorded. |
| Residual risk | What the requirement does not prevent even if it is met. |
| Provenance | Source of origin with its revision, and external sources with version. It is kept in the method's registry; the public page may omit it. |
| Pending decision | What a person must decide before accepting it. After acceptance it is called Future decisions and collects what was left open for another edition. |
Principle, profile and example¶
- Agnostic principle: holds regardless of language, platform or model provider.
- Agnostic requirement: verifiable obligation derived from a principle; it names no technology.
- Technology profile: selection and concretion of requirements for a context (for example, TypeScript or a type of project). A profile does not modify the base method.
- Example: illustrates; it never creates an obligation.
If a source only describes a profile, the extracted rule stays in the profile. To turn it into an agnostic requirement, you must justify why it applies beyond that context.
Exceptions¶
An exception to an accepted requirement records the responsible human, reason, scope, duration, risks, rollback and review date.