Visión general del Evidence-Gated Assurance Framework (EGAF)
Los equipos que preguntan «qué hace realmente tu marco de cumplimiento» están haciendo una pregunta de entrega: ¿puede esta organización demostrar, en un commit dado, que las comprobaciones que declara se ejecutaron, con herramientas independientes, con evidencia que un desconocido puede volver a leer? El Evidence-Gated Assurance Framework (EGAF) es la respuesta de Koinessa a esa pregunta. Es un marco de garantía. Un proyecto declara conformidad con EGAF L1, L2 o L3 en un commit dado, con evidencia adjunta. No es una certificación, una acreditación ni una autorización para operar.
Esta página es la visión general — la URL que le envías a un comprador, a un CISO o a un revisor. Los diez artículos de perfil de industria profundizan más. El resto del blog de ingeniería es la práctica de Evidence-Gated Agentic Development que rodea a EGAF y sobre la que este se apoya.
Sistema en prelanzamiento, operado por su fundador; las etiquetas de capacidad actuales describen el límite de la evidencia.
Qué hace el Evidence-Gated Assurance Framework
EGAF está En curso. Es un estándar orientado a la especificación y guiado por datos para la entrega de software verificada, compilado a partir de los regímenes por los que ya se pregunta a las organizaciones de ingeniería y de las formas de trabajo que este sistema ya ejecuta: trazabilidad desde un requisito hasta una prueba, baja complejidad, baja duplicación, cobertura del código modificado, pruebas de mutación, evidencia firmada e higiene de la cadena de suministro.
Tres partes, en cada ejecución:
- Un catálogo de controles. Cada control es un
checkde máquina (un artefacto producido por una herramienta independiente) o unevidence: attestation(una declaración firmada por un principal identificado). Una comprobación declarada sin un artefacto que la respalde es DRIFT, nunca PROVEN. Un archivo vacío pero analizable no es un veredicto. El catálogo que describe este sitio es una instantánea con estado Medido: 109 controles, incorporados a Koinessa en el pin0.0.0-dev+98d08efel 2026-08-30. - Un evaluador determinista. Las mismas entradas producen un informe de conformidad idéntico byte a byte. El evaluador no ejecuta pruebas ni escáneres. Lee artefactos que otras herramientas ya produjeron y registra sus digests. Un agente no puede fabricar un PROVEN sin producir el artefacto que la comprobación nombra.
- Un perfil versionado.
.egaf/profile.yamlen el repositorio consumidor es lo que evalúa CI. Si ese archivo no existe, el evaluador usa el perfil Core incluido, de modo que los controles obligatorios de L1 siempre aplican. Los perfiles solo pueden endurecer un umbral.
Esa es toda la afirmación de producto. Los marcos son orientación. Los controles son comportamiento. La evidencia demuestra que el comportamiento ocurrió. Las cargas organizativas — formación, seguridad física, BAA, una evaluación C3PAO, la calificación de herramientas DO-330, un encargo Type II con un tercero — siguen recayendo en la organización. El libro blanco de Koinessa es el argumento largo; el informe de entrega verificada es lo que este sistema ya publica sobre sí mismo.
Cómo se puntúa una ejecución
Tres niveles. L1 Core es obligatorio para declarar cualquier conformidad con EGAF. Si falla un control L1 aplicable, la primera línea del informe es L0. Una EXCEPTION nunca satisface un control L1. L2 Regulated añade controles de perfil de industria. L3 Safety-critical añade independencia, cobertura estructural, entradas para la calificación de herramientas y vinculación con peligros.
El estado de un control condensa los siete resultados de comprobación que ya se usan en los paquetes de evidencia de Koinessa:
| Resultado de la comprobación | Estado del control |
|---|---|
| PASS | PROVEN |
| FAIL | FAILED |
| SKIPPED-NOT-APPLICABLE con una razón registrada | NOT-APPLICABLE |
| INFRASTRUCTURE-ERROR, TOOL-MISSING, EVIDENCE-INVALID o ABSTAIN | DRIFT |
| Evidencia ausente | DRIFT |
El informe siempre muestra dos listas de honestidad con el mismo peso visual: No probado (FAILED y DRIFT) y Aceptado sin prueba (NOT-APPLICABLE y EXCEPTION). Una insignia limpia sobre un bloque de honestidad vacío es el fallo que el marco existe para evitar. El repositorio público de la especificación está Planeado; hasta que exista su grupo de GitLab, trata EGAF como un borrador pre-1.0 etiquetado y pendiente de publicación. El primer informe de conformidad del propio Koinessa en la rama principal está Planeado.
Es la misma disciplina que Evidence-Gated Agentic Development: el modelo genera el trabajo, el pipeline lo demuestra, la arquitectura del cerebro lo recuerda. EGAF nombra el estándar frente al que demuestra el pipeline.
Los diez perfiles de industria
Todos los perfiles salvo Core extienden Core y unen más marcos. Ninguno de ellos relaja un umbral. Elige el artículo del régimen bajo el que realmente entregas. Estas diez páginas son el cuerpo de la serie; esta visión general es el índice.
L1 — la línea base
- Perfil EGAF Core: garantía L1 para la entrega verificada — el predeterminado. Complejidad, duplicación, cobertura, mutación, trazabilidad, evidencia firmada. Si no hay ningún archivo de perfil en el repositorio, esto es lo que se ejecuta.
- Perfil EGAF OSS Maintainer para proyectos de código abierto — Core más OpenSSF Scorecard y OSPS Baseline. Sigue siendo L1; publicar código abierto no es un cuarto grado.
L2 — capas reguladas
- Perfil EGAF Financial: garantía L2 para finanzas reguladas — PCI DSS v4.0, SOX 404 ITGC, NYDFS Part 500, GLBA Safeguards, EU DORA, SR 11-7. FFIEC CAT está deliberadamente ausente.
- Perfil EGAF Health: garantía L2 para software médico — HIPAA Security, Privacy y Breach; HITRUST CSF; IEC 62304; 21 CFR Part 11; ciberseguridad previa a la comercialización de la FDA.
- Perfil EGAF Defense: garantía L2 para programas CUI — CMMC / NIST 800-171, NIST 800-53, NIST 800-161, CISA SSDAF. La evidencia local-first es una superficie, no una determinación de CUI.
- Perfil EGAF Public Sector para software gubernamental — NIST 800-53, CISA SSDAF, NIST CSF 2.0, Section 508, EN 301 549 sobre la WCAG 2.2 de Core.
- Perfil EGAF AI-Regulated para sistemas de IA de alto riesgo — EU AI Act Arts. 9–15, ISO/IEC 42001, OWASP LLM Top 10 2025, OWASP Agentic ASI y AGT-10 incorporado a L2.
L3 — capas de seguridad crítica
- Perfil EGAF Aerospace: software L3 crítico para la seguridad — DO-178C, DO-330/331/333, ARP4754A, ARP4761. El DAL lo declara la propia evaluación de peligros del adoptante.
- Perfil EGAF Automotive para software ISO 26262 — ISO 26262 partes 6/8/9 y MISRA C:2012. El ASIL proviene del HARA del adoptante.
- Perfil EGAF Industrial para IEC 61508 y ferrocarril — IEC 61508-3 y EN 50128. El SIL lo declara el adoptante.
Para quién es esto: equipos de plataforma, DevEx y DevSecOps en organizaciones de ingeniería que ya ejecutan varios agentes de codificación con IA, ya tienen CI y tienen un problema visible de verificación o de política. La página principal de Koinessa expone la posición del producto. El desarrollador es un usuario del pipeline; el comprador económico es el equipo que tiene que responder un cuestionario sin inventarse un certificado.
Lo que esta visión general no afirma
La conformidad con EGAF es una declaración por commit que un proyecto hace sobre sí mismo, con evidencia adjunta. Citar un marco en un perfil es una correspondencia, no un estado que el adoptante haya alcanzado. Ningún multiplicador de rendimiento sobre tareas completas. Ningún nombre de cliente. Los elementos planeados no llevan fechas. El informe de estado de limitaciones es el hermano honesto de esta página: lo que el sistema de entrega todavía no hace.
Si llegaste aquí desde un cuestionario de proveedores, empieza por Core y luego abre el único perfil L2 o L3 que coincida con el régimen del formulario. Si llegaste aquí desde la serie del libro blanco, continúa por la brecha de verificación en el desarrollo agéntico y demostrar que el código escrito por IA está listo — EGAF es el estándar declarado al otro lado de esa brecha.
El resto del blog de ingeniería
Todos los demás artículos que hay actualmente en koinessa.com, agrupados para que esta página pueda ser el único enlace que envíes.
La tesis y la brecha
- Qué es realmente un sistema operativo de IA para la entrega de software
- La brecha de verificación en el desarrollo agéntico
- La brecha de verificación: demostrar que el código escrito por IA está listo
- Evidence-Gated Agentic Development: dentro del bucle EG
- Siete lecciones de cincuenta años de sistemas
Cómo funciona Koinessa
- El cerebro de Koinessa: cinco planos, un sistema
- Autonomía por niveles de riesgo: cómo Koinessa controla la autoridad de los agentes
- El costo es el piso, el control es el multiplicador
- Por qué importan la complejidad de funciones y de archivos en la entrega de IA verificada
- La economía del contexto en la IA: recuperación sin el multiplicador
- Entrega de IA local-first: ventaja de costos por arquitectura
Estado, límites, lo que sigue
- Limitaciones y estado de Koinessa: la franqueza como evidencia
- Hoja de ruta de Koinessa: once direcciones, etiquetadas con honestidad
El índice del blog es el listado cronológico. Esta visión general es el mapa.