Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Adopting in parts¶
Current application guide based on ASILO 0.1 and MILPA 0.1. It explains accepted rules; it adds no obligations and defines no adoption levels.
The first question people ask is whether this has to be adopted all at once. It does not: each requirement says when it applies, and outside that condition it does not apply. This guide gathers in one place what the requirement sheets already say about starting small.
It is not all or nothing, and there is no ladder either¶
Every requirement sheet has an Applicability condition field and an Exception field. The normative language defines them: the condition says when a requirement is triggered, and outside it the requirement does not apply.
Edition 0.1 defines no maturity levels and no mandatory order of adoption. What varies from one project to another is not a level: it is how many conditions are met.
One clarification that prevents a misunderstanding: the word SHOULD in some sheets lowers the cost of one part of a requirement that already applies; it does not let you postpone the whole requirement. Every sheet contains at least one MUST.
What is triggered depending on what your project does¶
| If your project… | Then | Sheet |
|---|---|---|
| has no point of effect fed by a model (it only shows text to a person) | the contracts and boundaries requirement does not apply, but you record that condition; if it changes, it applies | ASILO-R-001 |
| is a single module or package | the layer model does not apply, and you record the condition | ASILO-R-002 |
| does tasks with no internal data and no persistent memory | the context limits do not apply to those tasks | ASILO-R-003 |
| has no agents with access to tools or data | agent permissions do not apply | ASILO-R-004 |
| handles no sensitive data and no secrets | the sensitive-data requirement is not triggered | ASILO-R-006 |
| only runs locally, with no cost and no external effects | budgets do not apply to those runs | ASILO-R-007 |
| is an internal prototype without external users, marked as such | failure evaluation is exempt, and the prototype cannot support public claims | ASILO-R-008 |
| does not declare that it applies MILPA | reserved names and the core and profile do not apply | MILPA-R-005, MILPA-R-006 |
| does not declare that it applies MILPA and does not allow agents to operate on it | the identity manifest does not apply | MILPA-R-004 |
Two things this table does not say and should not be read into it. A run that has a cost is still under ASILO-R-007 even with no external effects: the exception asks for both at once. And a script that calls a model can trigger ASILO-R-001 without any "agent" existing.
Four rules triggered by what you do¶
Four MILPA requirements do not wait for a declaration: their condition is an activity.
| When… | The rule, in one sentence | Sheet |
|---|---|---|
| you publish, cite or enforce a rule | say where it comes from, who approved it and in which version | MILPA-R-001 |
| you write a report that will be used to decide, publish or change a rule | separate what is backed, what you infer and what you assume | MILPA-R-002 |
| you define, document or implement a classification | give it its own name and do not translate it into another with a similar name | MILPA-R-003 |
| two sources say incompatible things | record it with both sources; do not delete the inconvenient one | MILPA-R-008 |
They make a good first step because they need no infrastructure: they are writing habits. They have their exceptions — working notes that are not used to decide, for example — and those are in each sheet.
Whether these four also bind a project that has not declared that it applies the method is a question edition 0.1 does not expressly settle. This guide does not settle it.
Two limits that admit no exception¶
When their condition is met, these two are not staged:
- An agent with external effects needs its own identity, a scope declared before it operates, and a way to revoke it. The sheet says "None for agents with external effects" (ASILO-R-004).
- Credentials do not enter a model's context. The sheet says "None for credentials" (ASILO-R-006).
The transition state¶
Only one requirement expressly recognises an intermediate state. MILPA-R-006 says in its exception:
Projects in transition may declare a target profile with a date, with the owner's acceptance.
And in its statement: if no accepted profile fits, the project SHOULD declare that and propose one, instead of forcing the closest.
In edition 0.1 no profile is in force (see profiles). That is why, as this guide reads it, declaring a proposed profile or a target profile with a date is today the usual way to meet this requirement. Do not announce an accepted profile that does not exist.
How to say where you are¶
Edition 0.1 defines no formula for "I apply the method in part". What you can state, because a sheet says it:
| You can say | Because it is said by |
|---|---|
| "project in transition, with a target profile and a date" | MILPA-R-006 |
| "exploratory link, marked as such and not published" | MILPA-R-007 |
| "internal prototype without external users, marked as such" | ASILO-R-008 |
| "no points of effect; condition recorded" | ASILO-R-001 |
| "a single module; condition recorded" | ASILO-R-002 |
And, to depart from a requirement that does apply to you, a recorded exception with a responsible person, reason, scope, duration, risks, rollback and review date, as the normative language asks.
Avoid phrases the method does not define, such as "partial conformance" or "basic level". And do
not use the statuses draft, proposed or accepted to describe your adoption: they are statuses
of a rule, not of a project, and MILPA-R-003 asks you not to
convert one classification into another because they look alike.
Declaring requirement by requirement takes longer, and it is the only thing that can be sustained today.
One possible route¶
It is not a required order. It is a way to start that leaves no step half done:
- Write with the four rules. You need no tools.
- Record the conditions that do not apply to you. No points of effect, a single module, internal prototype: one line each, with a date. If they change, you will know what was triggered.
- If you declare that you apply MILPA, publish the manifest and declare your profile — proposed or in transition — following identity and manifest and files, folders, and names.
- When an agent, an effect or a cost appears, go back to the table: what did not apply before does now. Continue with context and handoffs and architecture and security.
- Before stating anything in public, the prototype exemption ends: read evaluation and review.
For the route of a concrete first assignment, go to apply the methods.
Next: identity and manifest · See the ASILO requirements · MILPA's
A staged journey¶
A journey is planned for its destination and conditions. Adopting in parts means identifying what applies and recording why, not choosing only convenient obligations. The analogy does not replace requirement exceptions.