Ingeniería agnóstica y verificable: propuesta de perfil¶
Estado: propuesto. Contexto: proyectos de software construidos con personas y asistentes, con o sin IA en el producto. Esta propuesta no acepta un perfil, modifica principios ni añade requisitos universales. Sus axiomas son compromisos candidatos del perfil, no axiomas nuevos de ASILO, MILPA o SCAFFOLD. Una decisión de planeación no acredita un control implementado.
Propósito y primer paso¶
Evitar que una tecnología elegida, una salida convincente o una comprobación parcial se confundan con arquitectura, autoridad o evidencia suficiente. Empieza con la carta y el levantamiento (SCAFFOLD-R-019, R-020); identifica responsable, efectos y criterios. La guía de artefactos concreta el recorrido.
Axiomas candidatos del perfil¶
| ID | Compromiso propuesto | Comprobación observable |
|---|---|---|
| ENG-AX-001 | Agnosticidad: el núcleo usa contratos explícitos; proveedores, herramientas, formatos y asistentes se conectan mediante adaptadores. | Dos consumidores o adaptadores distintos ejercitan el mismo contrato; límites y versiones declarados. |
| ENG-AX-002 | Responsabilidad y fronteras: cada módulo tiene un motivo de cambio y efectos identificados. | Reglas de dependencia y pruebas muestran que el núcleo no importa presentación, red o almacenamiento concretos. |
| ENG-AX-003 | Sustitución: un adaptador conserva precondiciones, resultados, errores y límites de efectos del puerto. | Suite conductual compartida, incluidos fallos, cancelación y casos adversariales; una firma compatible no basta. |
| ENG-AX-004 | Extensión mínima: sólo se crea una abstracción por una variación o consumidor comprobados. | Segundo caso y decisión explican la extensión; no se instalan complementos por leer datos. |
| ENG-AX-005 | Autoridad explícita: texto, paquetes, salidas de IA y resultados técnicos no conceden permisos. | Un efecto sin sujeto, alcance y autorización vigente resulta denegado en su frontera de ejecución. |
| ENG-AX-006 | Control requerido incierto: ausencia, invalidez o resultado no evaluable impiden darlo por satisfecho. | Configuración inválida y evidencia ausente no se convierten en aprobación. |
| ENG-AX-007 | Revisión vinculada: cambios materiales invalidan la evidencia dependiente del objeto anterior. | Cambiar artefacto, contexto, política, perfil o fuente obliga a revisar su uso. |
| ENG-AX-008 | Evidencia íntegra y mínima: versión, procedencia y alcance acompañan el resultado; se minimizan datos. | Huellas contrastadas, referencias legibles y errores sin secretos; una huella no autentica a su editor. |
| ENG-AX-009 | Efectos contabilizados: repetición, reanudación y fallos tienen un resultado explícito. | Cada operación termina una vez o queda pendiente de reconciliación; no se reintenta un efecto incierto sin criterio. |
| ENG-AX-010 | IA desde el diseño: instrucciones, contexto, herramientas y evaluaciones tienen límites y versiones. | Simulación, evaluación del modelo y aceptación humana se registran por separado; no se inventa diversidad. |
| ENG-AX-011 | Optimización medida: primero corrección y línea base, después una hipótesis comparada. | Medición antes/después de calidad, coste y latencia; la caché conserva invalidación y permisos. |
| ENG-AX-012 | Entrega trazable: el artefacto comprobado, sus decisiones y su reversión son identificables. | Misma huella promovida, configuración separada y decisión del efecto crítico según el proyecto. |
| ENG-AX-013 | Autoridad por tema: existe una fuente canónica por tema semántico; un índice la referencia y las vistas derivadas declaran su procedencia. | Conflictos y duplicados de autoridad se detectan; al cambiar la fuente se identifica evidencia dependiente. |
| ENG-AX-014 | Seguridad desde el diseño y confianza cero: identidad, recurso, acción y contexto se verifican en cada frontera pertinente; faltas en controles requeridos fallan cerradas. | Casos de amenaza y pruebas de autorización cubren caminos permitidos, denegados y fallos; esto reduce riesgo, no demuestra ausencia de vulnerabilidades. |
| ENG-AX-015 | Límites de IA explícitos: contexto, salidas, evaluaciones y herramientas tienen procedencia, versión y autoridad separadas. | Pruebas adversariales, referencias exactas y mediación determinista de efectos; el modelo no concede permisos ni acepta su propia salida. |
La taxonomía para declarar estilos de aplicación, repositorios, despliegue y perfiles regionales está en el perfil de arquitectura de software.
Skills, plugins y protocolos de herramientas — propuesta de perfil¶
Esta distinción concreta el perfil; no crea requisitos universales ni cambia las ediciones aceptadas. Usa las condiciones de SCAFFOLD, MILPA y ASILO vigentes.
| Elemento | Función | Qué no concede |
|---|---|---|
| Skill | Instrucciones y recursos para orientar una tarea, distribuidos en el formato que consuma un host. | No concede identidad, acceso a rutas ni permiso para ejecutar herramientas. Su contenido es entrada no confiable. |
| Plugin | Código que extiende un host concreto y puede ejecutarse dentro de su ciclo de vida. | No es portable por definición ni confiable por estar instalado. |
| MCP | Protocolo para que un host se conecte con servidores que exponen herramientas, recursos y prompts. | No constituye por sí mismo una política de autorización, clasificación de datos ni revisión humana. |
| Adaptador | Traducción opcional entre un contrato externo y un puerto estable del framework. | No amplía permisos ni cambia la autoridad del contrato. |
Cómo se complementan los métodos¶
- SCAFFOLD registra estas integraciones como dependencias del proyecto o del lote cuando se usan para construir: origen, versión, compatibilidad, finalidad, responsable, zonas, criterios de aceptación y evidencia. Conserva la gestión de cuadrillas humanas y agénticas, planificación, entrega y medición según R-001..R-032; no impone Scrum, un gestor concreto ni un DAG para todo.
- MILPA conserva fuente, owner, estado, versión y relaciones de manifiestos y contratos (R-001, R-004..R-008). Un índice federado referencia repositorios y contratos con revisión/digest; no implica herencia efectiva, clonado automático ni una sola fuente global que duplique todos los artefactos.
- ASILO aplica límites según capacidad y efecto: entradas de Skills, recursos y resultados externos se tratan como no confiables; identidad, recurso, acción y contexto se verifican en la frontera pertinente; los permisos son mínimos y revocables; secretos y revisión humana conservan sus requisitos (R-001, R-003..R-008).
La crew de ingeniería construye el software; la crew de runtime atiende el uso del producto. Pueden compartir proveedor o framework, pero no heredan identidad, permisos, secretos, datos, presupuestos ni credenciales. SCAFFOLD organiza la construcción; ASILO protege cualquier fase que cumpla sus condiciones; MILPA mantiene procedencia y autoridad durante el ciclo.
Criterios candidatos de adopción¶
- Declarar origen, versión o digest, owner, compatibilidad y estado antes de usar un paquete, Skill, plugin, servidor MCP o contrato externo como contexto del agente.
- Separar lectura de datos, instrucciones y efectos. La activación de una Skill no activa sus herramientas; descubrir una herramienta no la autoriza.
- Seleccionar mediación directa o gateway según evaluación de riesgo y topología. El perfil no exige que todas las llamadas pasen por Horcón; sí exige autorización comprobable en la frontera donde se ejecuta la acción.
- Para código extensible, registrar capacidades, permisos, aislamiento, actualización, revocación, compatibilidad y reversión. Un plugin se considera código ejecutable.
- Probar entradas maliciosas, permisos denegados, revocación, repetición, límites de tiempo y fallo del adaptador. Un esquema válido no demuestra que el efecto sea seguro.
- Vincular evidencia de uso al digest exacto de la fuente, perfil de autorización, contrato, modelo/configuración y artefacto. Un cambio material obliga a revisar la evidencia afectada.
Estos criterios son una propuesta de perfil pendiente de owner, revisión metodológica y decisión. No se asignan IDs de requisito para evitar simular que existe una edición aceptada. Los contratos MCP, Skills y plugins deben fijarse contra las revisiones externas aplicables en el momento de implementar; la interoperabilidad no elimina sus cambios de versión ni sus riesgos propios.
SOLID, patrones y confianza cero¶
Responsabilidad única, extensión, sustitución de Liskov, interfaces pequeñas e inversión de dependencias se concretan con contratos y pruebas, no con número de clases. Puertos/adaptadores, estrategias y un núcleo funcional son opciones del perfil; no son una arquitectura universal. La confianza cero (zero trust) evita conceder confianza por ubicación o pertenencia: hay que comprobar identidad, recurso, acción y condiciones en cada frontera pertinente.
Referencias: NIST SP 800-207, subtipado conductual de Liskov y Wing, puertos y adaptadores. Son antecedentes externos; no certifican este perfil.
Relación con los métodos y aceptación¶
ASILO aporta alcance, fronteras, permisos y revisión de efectos (R-001 a R-007); MILPA aporta procedencia, clasificación, versiones y relaciones (R-001, R-003, R-004, R-007, R-008); SCAFFOLD aporta contratos, trabajo, comprobaciones y entrega (R-006, R-010, R-019 a R-032, según condición). SCAFFOLD-R-017 continúa fuera de la edición aceptada.
Ejemplo ficticio: una biblioteca y una aplicación web usan el mismo contrato de evidencia; la web añade revisión de UI y la biblioteca declara por qué ese alcance no aplica. Sus decisiones humanas y permisos conservan controles propios. Los detalles API y de instalación pertenecen a la implementación, no a esta ficha.
Responsable del perfil, aceptación metodológica y revisión independiente permanecen pendientes. Cambiar estos compromisos exige identificar revisión, razón, evidencia afectada y transición; no modifica en silencio los requisitos aceptados.