Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
Requirements — ASILO, MILPA and SCAFFOLD¶
Status: ASILO 0.1 and MILPA 0.1 each have eight requirements. SCAFFOLD 0.2 has 36 (2026-10-16): 31 inherited from 0.1 and five new. See the version history.
Each requirement follows the minimum record: stable ID, problem, scope, actor, condition, verifiable statement, evidence, exception, residual risk and external references. The words MUST, MUST NOT, SHOULD and MAY (in the Spanish text, DEBE, NO DEBE, DEBERÍA and PUEDE) have the meaning defined on that page.
How to read them¶
- Start with the principles: they explain the why.
- Go to the requirement you are interested in; the record says when it applies and how it would be checked.
- If you work with a specific technology, review the profiles.
- To see which software relates to the method, use the implementations map. The existence of a piece of software does not prove compliance.
MILPA — knowledge, authority and structure¶
| ID | Topic | One line |
|---|---|---|
| MILPA-R-001 | Authority and provenance | Every rule says where it comes from, what state it is in and who approved it. |
| MILPA-R-002 | Facts and inferences | Reports separate cited facts, inferences and hypotheses. |
| MILPA-R-003 | Homonymous scales | No “level” is translated into another scale without an accepted correspondence. |
| MILPA-R-004 | Manifest | Each project declares identity, owner, scope, profile and restricted zones. |
| MILPA-R-005 | Reserved names | Reserved names come from a declared, versioned vocabulary. |
| MILPA-R-006 | Structure | Invariant core plus a declared profile; no profile tree is universal. |
| MILPA-R-007 | Integration between projects | Links are declared at both ends with a contract and a version. |
| MILPA-R-008 | Contradictions | They are recorded and kept until a decision is made. |
ASILO — limits for AI systems¶
| ID | Topic | One line |
|---|---|---|
| ASILO-R-001 | Contracts and trust boundaries | Model output is validated and authorized before it produces effects. |
| ASILO-R-002 | Layers or rings | The model and dependency rule are declared; automatic checking is recommended when the profile permits it. |
| ASILO-R-003 | Context limits | Each task has a context budget with sources, data and expiry. |
| ASILO-R-004 | Least privilege | Each agent has a declared scope, no greater than that of whoever invokes it, and revocable. |
| ASILO-R-005 | Human review | Cataloged critical effects require informed human confirmation. |
| ASILO-R-006 | Sensitive data | Data classified with purpose and retention; secrets never in the context. |
| ASILO-R-007 | Budgets and continuity | Limits on cost, actions and time; tested stop mechanism; state preserved. |
| ASILO-R-008 | Failure evaluation | Hallucination, prompt injection and sycophancy are measured where applicable; failures between agents if there is more than one. Nothing is declared eliminated. |
What “accepted” means¶
An accepted requirement obliges, within its scope and condition, whoever declares they apply ASILO 0.1,
MILPA 0.1 or SCAFFOLD in the accepted edition they identify. It does not certify that a system complies: that requires each
project's own evidence. IDs are frozen; a retired requirement keeps its ID as deprecated.
Editorial standard rules¶
They govern how this site is written, not how a system is built.
| ID | Topic | One line |
|---|---|---|
| DOC-AX-001 | Voice | Accessible, neutral and precise voice; same normative force in Spanish and English. |
| DOC-AX-002 | Agnosticism | The method does not depend on products and its examples are fictitious. |
| DOC-AX-003 | Translation | Spanish first; each translation starts from an identified revision. |
| DOC-AX-004 | Usefulness | Useful, verifiable technical communication, without promises or unsourced figures. |
| DOC-AX-005 | Analogies | Analogies with referent, correspondence and limits; a descriptive name for each method. |
| DOC-AX-006 | AI scope | One or several assistants are different situations; each requirement keeps its conditions. |
SCAFFOLD — software projects with people and assistants¶
SCAFFOLD 0.2 is accepted since 2026-10-16 with 36 requirements: 31 from 0.1 and five new. R-017 remains pending outside both editions.
| ID | Group | One line |
|---|---|---|
| SCAFFOLD-R-001 | A · Scope and attribution | Each path has at most one write owner; shared paths are declared. |
| SCAFFOLD-R-002 | A · Scope and attribution | A change crossing zones of several owners goes in a batch with a responsible person. |
| SCAFFOLD-R-003 | A · Scope and attribution | Each change is attributed to a person and, if involved, to the assistant. |
| SCAFFOLD-R-004 | B · Context and handoff | Declaring a short, existing startup context is recommended. |
| SCAFFOLD-R-005 | B · Context and handoff | When switching assistants, a handoff note with a status is left; once taken, it is not edited. |
| SCAFFOLD-R-006 | C · Contracts, maps and code | Contract, map and code declare their version; checking for drift is recommended. |
| SCAFFOLD-R-007 | C · Contracts, maps and code | Whoever works against another unit's contract receives it in context with its version. |
| SCAFFOLD-R-008 | C · Contracts, maps and code | Every new or changed third-party dependency records who reviewed it and why. |
| SCAFFOLD-R-009 | D · Batches and record | Work is organized in typed batches; cost is data or “unknown”. |
| SCAFFOLD-R-010 | D · Batches and record | Declared checks run; an assistant does not merge or deploy on its own what is catalogued as critical. |
| SCAFFOLD-R-011 | E · Boundary and urgency | Engineering-layer configuration stays out of the deployed artifact. |
| SCAFFOLD-R-012 | E · Boundary and urgency | Exploration identifies suspendible checks beforehand, preserves ASILO/MILPA and has a formal exit. |
| SCAFFOLD-R-013 | E · Boundary and urgency | The urgency path is defined beforehand, leaves a record and ends in review. |
| SCAFFOLD-R-014 | F · Composite projects | The root declares its children and does not write in them outside a child batch. |
| SCAFFOLD-R-015 | F · Composite projects | From the root, context is limited to manifests, contracts, maps and notes. |
| SCAFFOLD-R-016 | F · Composite projects | Dependencies between batches are declared, respected on close and acyclic. |
| SCAFFOLD-R-018 | F · Composite projects | An obsolete contract or link must not be used in a feature batch; it may be used in batches whose goal is to retire it. |
| SCAFFOLD-R-019 | G · Project and start-up | The project has a charter with goal, scope, owners and critical effects before the first feature batch. |
| SCAFFOLD-R-020 | G · Project and start-up | When adopting over existing work, a baseline survey is recorded with facts and hypotheses kept separate. |
| SCAFFOLD-R-021 | H · Work and cadence | Planned work is items with an identifier, acceptance criteria and owner; batches cite them. |
| SCAFFOLD-R-022 | H · Work and cadence | Ordering, accepting and discarding work are decided by people; an assistant proposes. |
| SCAFFOLD-R-023 | H · Work and cadence | There is a definition of ready and a definition of done; nothing is finished without checking them and without human acceptance. |
| SCAFFOLD-R-024 | H · Work and cadence | A cadence is declared and continuous flow also has a work-in-progress limit; periodic review and improvement are recorded. |
| SCAFFOLD-R-025 | I · Branches and releases | Branches, integration requests and releases cite their work; traceability works in both directions. |
| SCAFFOLD-R-026 | I · Branches and releases | The branching model is declared; the main branch is protected and an assistant does not write to it without review. |
| SCAFFOLD-R-027 | J · Environments and delivery | Each environment declares purpose, data, its own secrets and who deploys; production is a critical effect. |
| SCAFFOLD-R-028 | J · Environments and delivery | The same checked artefact is promoted, with a rollback plan and a deployment record. |
| SCAFFOLD-R-029 | I · Branches and releases | Releases follow a declared scheme, with an immutable tag, notes and authorisation. |
| SCAFFOLD-R-030 | K · Crews | Each crew of people, agents or mixed has a human owner; an agents-only crew does not accept, order or deploy. |
| SCAFFOLD-R-031 | K · Crews | All work in progress has a responsible person; the capacity of people and agents is planned separately. |
| SCAFFOLD-R-032 | J · Environments and delivery | Declared delivery indicators are measured and each incident has a later review with actions. |
| SCAFFOLD-R-033 | L · 0.2 | Impact and dependent evidence |
| SCAFFOLD-R-034 | L · 0.2 | Runtime, configuration, and infrastructure |
| SCAFFOLD-R-035 | L · 0.2 | Data compatibility and migration |
| SCAFFOLD-R-036 | L · 0.2 | Verifiable structural boundaries |
| SCAFFOLD-R-037 | L · 0.2 | Remote engineering connections and actions |
The ASILO architecture and security guides explain its requirements and profile models; they are not additional requirements.
Pending amendment outside the accepted editions¶
R-017 remains a proposal; it is not one of the 36 accepted requirements. MILPA-R-007 remains the rule for links.
| ID | Estado / Status / 状态 | Referencia / Reference / 引用 |
|---|---|---|
| SCAFFOLD-R-017 | proposed | Proposed amendment to MILPA-R-007 for external links; MILPA-R-007 applies today. |