Informative translation. The Spanish text is authoritative. If the two differ, the Spanish version prevails.
Status: in force since MILPA 0.1 (28 Sep 2026; editorial revision 0.1.1). Read the
normative language first and see the version history.
MILPA deals with where knowledge lives, who answers for it, where it comes from and what
authority it has. The requirements below are agnostic: they do not fix a language, file format
or specific folder tree. Anything that depends on the type of project goes to profiles.
MILPA-R-001 — Authority and provenance of normative claims¶
A text is treated as a rule because it sits in a “canonical” folder, carries status: canon or is repeated by an SDK, without anyone having decided it.
Scope
Any claim presented as a rule, requirement, principle or decision of a method or project.
Responsible actor
Methodology owner (or project owner for domain rules).
Applicability condition
When publishing, citing or enforcing a normative claim.
Verifiable statement
Each normative claim MUST identify: source (path or URL), revision or SHA-256, status (draft, proposed, accepted, deprecated, historical) and human owner. A claim MUST NOT be presented as accepted without a human decision record that names version and date. The location, file name and labels of the source MUST NOT be used as proof of authority.
Expected evidence
Per-page metadata; decision log with date, responsible person and revision; source inventory with hashes.
Exception
None for accepted. A guidance page without rules may omit the owner if it declares that it is not normative.
Residual risk
A correct record does not guarantee that the rule is good; only that it is known who approved it and from where.
MILPA-R-002 — Facts, inferences and hypotheses kept separate¶
An agent or a person summarizes the state of a project mixing what was verified with what was assumed; the summary is then reused as fact.
Scope
Reports, audits, status summaries and proposals produced or assisted by AI that describe a project or a source.
Responsible actor
Whoever signs or delivers the report (the person responsible for the task).
Applicability condition
When the report will be used to decide, publish or change a rule.
Verifiable statement
The report MUST separate (1) facts with a cited source, (2) inferences and (3) hypotheses or uncertainties. A figure, version or status that is not confirmed MUST be marked as uncertain. The report MUST NOT describe a future structure or capability as existing.
Expected evidence
Report with the three sections; each fact with a verifiable path or URL.
Exception
Working notes that are not used to decide.
Residual risk
A label may be assigned wrongly; human review is still necessary. It does not detect confabulation inside a wrongly cited fact.
External references
NIST AI 600-1, risk Confabulation and Information Integrity.
MILPA-R-003 — Homonymous classifications are not converted into one another¶
Several scales are called “level” and share names (Canon, Evidencia/Evidence, Referencia/Reference) with a different order and a different meaning; converting one into another fabricates authority or certainty.
Scope
Classification schemes used by MILPA, ASILO, their profiles and implementations.
Responsible actor
Methodology owner; maintainers when mapping enums.
Applicability condition
When defining, documenting or implementing a classification.
Verifiable statement
Each classification scheme MUST have its own name, purpose and definition of values. A value MUST NOT be translated into another scheme without an accepted correspondence table.
Expected evidence
Glossary with each scheme; accepted correspondence table or a statement that none exists.
Exception
None while no accepted correspondence exists.
Residual risk
It does not remove reading confusion; it only prevents it from being formalized.
Agnostic requirement (the file format belongs to the profile) · derives from MILPA-P-04
Status
accepted — MILPA 0.1 (28 Sep 2026)
Problem
To learn who is responsible, what it covers and what is restricted, a person or an agent has to walk through folders and deduce it; what is deduced may be false.
Scope
Each project or node on which agents operate or which declares that it applies MILPA.
Responsible actor
Project owner.
Applicability condition
When the project declares that it applies MILPA or allows agents to operate on it.
Verifiable statement
The project MUST publish at its root a machine-readable manifest with, at least: identifier, node role, human owner, scope, declared profile, parent node (or none) and restricted zones. If the manifest records hierarchical depth, that field MUST NOT be named the same as an authority or certainty scale (for example, level). Inheritance between manifests is out of scope of edition 0.1: a declared inheritance MUST NOT be presented as effective.
Expected evidence
Versioned manifest; schema validation; record of how inheritance is (or is not) resolved.
Exception
Projects without agents and outside MILPA.
Residual risk
The manifest may become outdated; by itself it does not prevent someone from reading a restricted zone.
MILPA-R-005 — Reserved names with a declared vocabulary¶
Field
Content
Class
Agnostic requirement (the concrete list belongs to the profile) · derives from MILPA-P-03
Status
accepted — MILPA 0.1 (28 Sep 2026)
Problem
A folder with the same name means different things in different projects, or each team invents its own reserved words.
Scope
Names of folders and files with methodological meaning.
The project MUST declare which reserved-names vocabulary it uses and its version. A reserved name MUST NOT be used with a different meaning. A new reserved name MUST be added to the vocabulary through a recorded change, not through local use.
Expected evidence
Versioned vocabulary; reference from the manifest; review of names in the project.
Exception
Domain names (products, verticals) are outside the reserved vocabulary.
Residual risk
The convention does not prevent incorrect content inside a well-named folder.
MILPA-R-006 — Invariant core and declared profile¶
The folder tree of one specific type (for example, a product dossier) is imposed on every project, or each project is left to invent its structure without saying so.
Scope
File and folder structure of projects that apply MILPA.
Responsible actor
Project owner; methodology owner for the core.
Applicability condition
Projects that declare that they apply MILPA.
Verifiable statement
The project MUST contain the invariant core and MUST declare its profile in the manifest. The invariant core of edition 0.1 is seven functions, each with an identifiable place: (1) manifest (MILPA-R-004); (2) entry point for readers; (3) registry of sources and links (MILPA-R-007); (4) instructions for agents, if agents operate; (5) documentation index; (6) decision log; (7) separate place for temporary non-canonical material. The concrete file names belong to the profile. The profile MUST NOT be inferred from the structure. The method MUST NOT require as universal any folders that belong only to one profile. If no accepted profile fits, the project SHOULD declare this and propose one, instead of forcing the closest one.
Expected evidence
Manifest with profile; check of the core and profile paths; record of projects without a profile.
Exception
Projects in transition may declare a target profile with a date, with the owner's acceptance.
Residual risk
That the folders exist does not mean their content is correct.
Two projects are treated as integrated because they share a name, folder or brand; or one plane (planning) and another (implementation) drift out of sync without either knowing it.
Scope
Relationships between projects, between planning and implementation, and between method and software.
Responsible actor
Owners of both ends.
Applicability condition
When a project consumes, derives from or documents another.
Verifiable statement
Each link MUST be declared at both ends with: provider, consumer, contract and version, data that crosses, owner, status and evidence. A local path MUST NOT be the only link mechanism for a published version.
Expected evidence
Link entries in both repositories (for example, SOURCE.md); pinned versions.
Exception
Exploratory links marked as such and not published.
Residual risk
Declaring a contract does not prove compatibility; tests in the consumer are needed.
MILPA-R-008 — Contradictions stay visible until resolved¶
A contradiction is “cleaned up” by silently choosing the most recent text, and the reason for the change is lost.
Scope
Sources, requirements and decisions of ASILO and MILPA.
Responsible actor
Whoever detects the contradiction records it; the methodology owner resolves it.
Applicability condition
When two sources or requirements say incompatible things.
Verifiable statement
The contradiction MUST be recorded with both sources, revision or hash, the conflicting phrase and the consequence. Provenance and historical text MUST NOT be deleted when resolving it; the resolution MUST cite the decision.
Expected evidence
The method's contradiction register; linked decisions.
Exception
None.
Residual risk
A long unresolved register blocks acceptance; it requires periodic review.