MILPA se ocupa de dónde vive el conocimiento, quién responde por él, de dónde viene y qué
autoridad tiene. Los requisitos siguientes son agnósticos: no fijan lenguaje, formato de archivo
ni árbol de carpetas concreto. Lo que depende del tipo de proyecto va a perfiles.
MILPA-R-001 — Autoridad y procedencia de afirmaciones normativas¶
Un texto se trata como regla porque está en una carpeta «canónica», lleva status: canon o lo repite un SDK, sin que nadie lo haya decidido.
Alcance
Toda afirmación que se presente como regla, requisito, principio o decisión de un método o proyecto.
Actor responsable
Owner metodológico (o owner del proyecto para reglas de dominio).
Condición de aplicación
Al publicar, citar o hacer cumplir una afirmación normativa.
Formulación verificable
Cada afirmación normativa DEBE identificar: fuente (ruta o URL), revisión o SHA-256, estado (draft, proposed, accepted, deprecated, historical) y owner humano. Una afirmación NO DEBE presentarse como accepted sin un registro de decisión humana que nombre versión y fecha. Ubicación, nombre de archivo y etiquetas de la fuente NO DEBEN usarse como prueba de autoridad.
Evidencia esperada
Metadatos por página; registro de decisiones con fecha, responsable y revisión; inventario de fuentes con hash.
Excepción
Ninguna para accepted. Una página orientativa sin reglas puede omitir owner si declara que no es normativa.
Riesgo residual
Un registro correcto no garantiza que la regla sea buena; sólo que se sabe quién la aprobó y desde dónde.
MILPA-R-002 — Hechos, inferencias e hipótesis separados¶
Un agente o una persona resume el estado de un proyecto mezclando lo comprobado con lo supuesto; el resumen se reutiliza como hecho.
Alcance
Informes, auditorías, resúmenes de estado y propuestas producidos o asistidos por IA que describan un proyecto o una fuente.
Actor responsable
Quien firma o entrega el informe (persona responsable del encargo).
Condición de aplicación
Cuando el informe se usará para decidir, publicar o cambiar una regla.
Formulación verificable
El informe DEBE separar (1) hechos con fuente citada, (2) inferencias y (3) hipótesis o incertidumbres. Una cifra, versión o estado no confirmado DEBE marcarse como incierto. El informe NO DEBE describir estructura o capacidad futura como existente.
Evidencia esperada
Informe con las tres secciones; cada hecho con ruta o URL verificable.
Excepción
Notas de trabajo que no se usan para decidir.
Riesgo residual
La etiqueta puede estar mal asignada; la revisión humana sigue siendo necesaria. No detecta confabulación dentro de un hecho mal citado.
Referencias externas
NIST AI 600-1, riesgo Confabulation e Information Integrity.
MILPA-R-003 — Clasificaciones homónimas no se convierten entre sí¶
Varias escalas se llaman «nivel» y comparten nombres (Canon, Evidencia/Evidence, Referencia/Reference) con otro orden y otro significado; convertir una en otra fabrica autoridad o certeza.
Alcance
Esquemas de clasificación usados por MILPA, ASILO, sus perfiles e implementaciones.
Actor responsable
Owner metodológico; mantenedores al mapear enums.
Condición de aplicación
Al definir, documentar o implementar una clasificación.
Formulación verificable
Cada esquema de clasificación DEBE tener nombre propio, propósito y definición de valores. Un valor NO DEBE traducirse a otro esquema sin una tabla de correspondencia aceptada.
Evidencia esperada
Glosario con cada esquema; tabla de correspondencia aceptada o constancia de que no existe.
Excepción
Ninguna mientras no exista correspondencia aceptada.
Riesgo residual
No elimina la confusión de lectura; sólo impide que se formalice.
MILPA-R-004 — Manifiesto de identidad del proyecto¶
Campo
Contenido
Clase
Requisito agnóstico (el formato de archivo es de perfil) · deriva de MILPA-P-04
Estado
accepted — MILPA 0.1 (28-sep-2026)
Problema
Para saber quién responde, qué abarca y qué está restringido, una persona o un agente tiene que recorrer carpetas y deducirlo; lo deducido puede ser falso.
Alcance
Cada proyecto o nodo sobre el que operen agentes o que declare aplicar MILPA.
Actor responsable
Owner del proyecto.
Condición de aplicación
Cuando el proyecto declara aplicar MILPA o permite operar agentes sobre él.
Formulación verificable
El proyecto DEBE publicar en su raíz un manifiesto legible por máquina con, al menos: identificador, rol del nodo, owner humano, alcance, perfil declarado, nodo padre (o ninguno) y zonas restringidas. Si el manifiesto registra profundidad jerárquica, ese campo NO DEBE llamarse igual que una escala de autoridad o de certeza (por ejemplo, level). La herencia entre manifiestos queda fuera de la edición 0.1: una herencia declarada NO DEBE presentarse como efectiva.
Evidencia esperada
Manifiesto versionado; validación de esquema; registro de cómo se resuelve (o no) la herencia.
Excepción
Proyectos sin agentes y fuera de MILPA.
Riesgo residual
El manifiesto puede desactualizarse; no impide por sí mismo que alguien lea una zona restringida.
MILPA-R-005 — Nombres reservados con vocabulario declarado¶
Campo
Contenido
Clase
Requisito agnóstico (la lista concreta es de perfil) · deriva de MILPA-P-03
Estado
accepted — MILPA 0.1 (28-sep-2026)
Problema
Una carpeta llamada igual significa cosas distintas en proyectos distintos, o cada equipo inventa palabras reservadas.
Alcance
Nombres de carpetas y archivos con significado metodológico.
Actor responsable
Owner metodológico (vocabulario); owner del proyecto (uso).
Condición de aplicación
Proyectos que declaran aplicar MILPA.
Formulación verificable
El proyecto DEBE declarar qué vocabulario de nombres reservados usa y su versión. Un nombre reservado NO DEBE usarse con otro significado. Un nombre reservado nuevo DEBE añadirse al vocabulario mediante cambio registrado, no por uso local.
Evidencia esperada
Vocabulario versionado; referencia desde el manifiesto; revisión de nombres en el proyecto.
Excepción
Nombres de dominio (productos, verticales) quedan fuera del vocabulario reservado.
Riesgo residual
La convención no evita contenido incorrecto dentro de una carpeta bien nombrada.
MILPA-R-006 — Núcleo invariante y perfil declarado¶
Se impone a todo proyecto el árbol de carpetas de un tipo concreto (por ejemplo, un dossier de producto), o se deja que cada proyecto invente su estructura sin decirlo.
Alcance
Estructura de archivos y carpetas de proyectos que aplican MILPA.
Actor responsable
Owner del proyecto; owner metodológico para el núcleo.
Condición de aplicación
Proyectos que declaran aplicar MILPA.
Formulación verificable
El proyecto DEBE contener el núcleo invariante y DEBE declarar su perfil en el manifiesto. El núcleo invariante de la edición 0.1 son siete funciones, cada una con un lugar identificable: (1) manifiesto (MILPA-R-004); (2) entrada para lectores; (3) registro de fuentes y vínculos (MILPA-R-007); (4) instrucciones para agentes, si operan agentes; (5) índice de la documentación; (6) registro de decisiones; (7) lugar separado para material temporal no canónico. Los nombres de archivo concretos pertenecen al perfil. El perfil NO DEBE inferirse de la estructura. El método NO DEBE exigir como universales carpetas que sólo pertenecen a un perfil. Si ningún perfil aceptado encaja, el proyecto DEBERÍA declararlo y proponer uno, en lugar de forzar el más cercano.
Evidencia esperada
Manifiesto con perfil; comprobación de rutas del núcleo y del perfil; registro de proyectos sin perfil.
Excepción
Proyectos en transición pueden declarar un perfil objetivo con fecha, con aceptación del owner.
Riesgo residual
Que las carpetas existan no significa que su contenido sea correcto.
Dos proyectos se tratan como integrados por compartir nombre, carpeta o marca; o un plano (planeación) y otro (implementación) se desincronizan sin que ninguno lo sepa.
Alcance
Relaciones entre proyectos, entre planeación e implementación y entre método y software.
Actor responsable
Owners de ambos extremos.
Condición de aplicación
Cuando un proyecto consume, deriva de o documenta a otro.
Formulación verificable
Cada vínculo DEBE declararse en ambos extremos con: proveedor, consumidor, contrato y versión, datos que cruzan, owner, estado y evidencia. Una ruta local NO DEBE ser el único mecanismo de vínculo para una versión publicada.
Evidencia esperada
Entradas de vínculo en ambos repositorios (por ejemplo, SOURCE.md); versiones fijadas.
Excepción
Vínculos exploratorios marcados como tales y sin publicación.
Riesgo residual
Declarar un contrato no prueba compatibilidad; hacen falta pruebas en el consumidor.
MILPA-R-008 — Contradicciones visibles hasta su resolución¶
Se «limpia» una contradicción eligiendo en silencio el texto más reciente y se pierde la razón del cambio.
Alcance
Fuentes, requisitos y decisiones de ASILO y MILPA.
Actor responsable
Quien detecta la contradicción la registra; el owner metodológico la resuelve.
Condición de aplicación
Cuando dos fuentes o requisitos dicen cosas incompatibles.
Formulación verificable
La contradicción DEBE registrarse con ambas fuentes, revisión o hash, frase en conflicto y consecuencia. NO DEBE borrarse la procedencia ni el texto histórico al resolverla; la resolución DEBE citar la decisión.
Evidencia esperada
Registro de contradicciones del método; decisiones enlazadas.
Excepción
Ninguna.
Riesgo residual
Un registro largo sin resolver bloquea la aceptación; requiere revisión periódica.