Registros de decisión¶
Esta página reúne, en un solo lugar público, quién aceptó cada edición, cuándo, sobre qué revisión
y qué contradicciones siguen abiertas. Cumple la función que MILPA-R-001 y MILPA-R-008 piden a
cualquier proyecto que adopte el método: decisiones con responsable y contradicciones visibles
hasta su resolución. Los registros de integridad están en reference/; el historial de
versiones, en Versiones y cambios.
ASILO 0.1 y MILPA 0.1¶
| Campo | Valor |
|---|---|
| Ediciones | ASILO 0.1 y MILPA 0.1 |
| Fecha de aceptación | 28-sep-2026 |
| Responsable metodológico | José Adrián Ruiz-Carmona (cuenta pública kasailabs en Codeberg) |
| Revisión de aceptación | Commit 31ff230 |
| Bytes registrados | Revisión editorial 0.1.1 (commit fd7d0c3). Sus formulaciones verificables son idénticas a las de la revisión de aceptación; cambian cabeceras, notas de procedencia y referencias internas. Decisión del 15-oct-2026. |
| Forma de la decisión | Comunicada por el responsable metodológico en una sesión de trabajo asistida por IA y transcrita en el registro original, que el responsable revisó. |
| Qué se acepta | Lenguaje normativo y ficha de requisito; conceptos; principios ASILO-P-01 a P-06 y MILPA-P-01 a P-06; requisitos ASILO-R-001 a R-008 y MILPA-R-001 a R-008. Ningún requisito excluido. |
| Qué no se acepta | Ningún perfil (siguen como candidatos); ningún documento de diseño previo como tal; ninguna declaración de conformidad de una implementación; ninguna conformidad o certificación con OWASP, NIST, MITRE ATLAS o ISO/IEC 42001. |
| Riesgos aceptados | Parte de las fuentes de diseño tenía historial Git incompleto; la evidencia de implementación fue lectura de código sin pruebas ejecutadas; huecos declarados: envenenamiento de datos y modelos, ejecución de código inesperada y las categorías NIST de sesgo y contenido dañino. |
Cambios aplicados al aceptar¶
| ID | Cambio |
|---|---|
| MILPA-R-004 | El campo de profundidad no puede llamarse como una escala de autoridad o certeza; la herencia entre manifiestos queda fuera de la 0.1. |
| MILPA-R-006 | El núcleo invariante se define como siete funciones; los nombres de archivo pertenecen al perfil. |
| ASILO-R-003 | Las clasificaciones restringidas son las dos más altas de la escala de exposición. |
| ASILO-R-004 | Comprobar la revocación antes de cada acción pasa a DEBERÍA. |
| ASILO-R-005 | El catálogo de efectos críticos considera como mínimo pagos, borrados, permisos, publicación a terceros y decisiones sobre personas. |
| ASILO-R-008 | Sin umbrales numéricos en la 0.1. |
Registros originales¶
Los registros completos de la aceptación se conservan en el historial del repositorio, en la
revisión fd7d0c3. Contienen referencias a fuentes de diseño internas y se citan como procedencia,
no como texto vigente:
registro de aceptación,
contradicciones,
procedencia y
revisión editorial 0.1.1.
SCAFFOLD 0.1¶
| Campo | Valor |
|---|---|
| Edición | SCAFFOLD 0.1 |
| Aceptación | 13-oct-2026, commit e41ff0a: SCAFFOLD-R-001 a R-016 y R-018 |
| Edición completada | 14-oct-2026, commit 6a13fa3: SCAFFOLD-R-019 a R-032 (31 requisitos vigentes) |
| Responsable metodológico | José Adrián Ruiz-Carmona (cuenta pública kasailabs en Codeberg) |
| Excluido | SCAFFOLD-R-017, enmienda propuesta a MILPA-R-007 |
| Principios | SCAFFOLD 0.1 no tiene principios propios; cada requisito declara su base en el campo «Base». |
| Detalle | Estado de SCAFFOLD |
La edición conserva el nombre «SCAFFOLD 0.1» con la nota «completada el 14-oct-2026»
(decisión del 15-oct-2026). Las huellas del 13-oct se conservan como revisión sustituida en
reference/scaffold-accepted-0.1-sha256.json.
Contradicciones abiertas¶
Cada fila sigue abierta hasta que una edición nueva la resuelva. Responsable: el responsable metodológico de la metodología afectada. Registradas el 15-oct-2026, salvo indicación.
| ID | Contradicción | Siguiente acción |
|---|---|---|
| CA-01 | ASILO-R-004: la excepción («ninguna para agentes con efectos externos») deja sin decir qué ocurre con agentes sin efectos externos. | Precisar la excepción en la próxima edición de ASILO. |
| CA-02 | ASILO-R-007: el alcance («ejecuciones de agentes y llamadas a modelos con costo o efecto») es más estrecho que la condición («toda ejecución automatizada con costo o efectos»). | Igualar alcance y condición. |
| CA-03 | MILPA-R-001: «ninguna para accepted» sugiere excepciones en otros estados, pero la única descrita (páginas orientativas sin reglas) queda fuera del alcance de la ficha. |
Aclarar si hay excepciones por estado. |
| CA-04 | SCAFFOLD-R-018 sólo regula lotes de tipo función; los demás tipos de lote quedan sin regla. | Proponer que aplique a todo lote. |
| CA-05 | El lenguaje normativo se declara común a ASILO 0.1 y MILPA 0.1, pero SCAFFOLD 0.1 lo usa. | Ampliar su ámbito a SCAFFOLD en la próxima edición. |
| C-05 | Contenido de los anillos 2 y 3 en el perfil ASILO para TypeScript (aplazada el 28-sep-2026). | Resolver al aceptar ese perfil. |
| C-11 | Identificadores de axiomas reutilizados con significados distintos en otra base documental (abierta el 30-sep-2026). | Ver el registro original de contradicciones. |
SCAFFOLD 0.2 — 2026-10-16¶
José Adrián Ruiz-Carmona acepta las cinco ampliaciones R-033 a R-037. La decisión identifica alcance, base 0.1 íntegra, transición, traducciones pendientes y límites de aceptación. Son 36 requisitos; ASILO/MILPA, R-017 y perfiles conservan su estado.