Simple, y luego técnico.
Lee primero el diagrama en lenguaje llano. La capa técnica debajo nombra las mismas cajas que el material fuente, y aquí no se expone nada que se lea como una receta de exploit.
EXTERNAL ROOTS / PINS
│
VERIFICATION ADAPTERS (signatures, attestation formats — future)
│
MASTER FRONT ASSURANCE KERNEL (the small core that decides)
│
ASSESSMENT RESULT (record_valid / security_status / release_authority=false)
│
EXTERNAL RELYING PARTY (someone else, deciding)
│
OPTIONAL EFFECT PATH (often: nothing happens)Qué hay dentro del kernel de referencia
- Canonicalización (MF-CANON-1): JSON estricto, claves normalizadas NFC, sin floats, sin valores no finitos.
- Hashing y comparación de pins contra digests suministrados externamente.
- Ligadura autoridad–política: la autoridad debe referenciar exactamente la política consumida.
- Un grafo de evidencia finito: cinco relaciones, sin código, sin operaciones arbitrarias.
- Ligadura de ejecución y comprobaciones de caducidad/tiempo contra ventanas declaradas.
- Evaluación de conflicto y completitud bajo el modo declarado por la política.
- Consistencia de un solo uso para permisos y sus registros de consumo.
- Agregación de propiedades y resultado en record_valid / security_assessment_status.
Qué queda deliberadamente fuera
- Acceso a filesystem, red, subprocesos y reloj ambiental.
- Verificación concreta de firmas o COSE/DSSE.
- Un servicio de transparencia o un ancla externa durable.
- La Secure Execution Gate — un componente de referencia separado, no alcanzable desde este sitio ni desde su CLI.
La parte que podría cambiar algo en una máquina es un componente distinto de la parte que decide. No son la misma base de confianza.
V Verificado contra los bytes de la fuente De dónde sale esto
- Fichero fuente
03_ARCHITECTURE/00-ARCHITECTURE-OVERVIEW.md- Sección
- 3. Qué está deliberadamente fuera
- Digest del fichero
- 78c19b5bae12a001f385a6f2d1afb22ed507f72d019f806beebf73a466e01c8c
- Cita literal
secure runner/effect gate **dentro del kernel**
The gate lives in 11_SECURE_EXECUTION_GATE as a separate TCB. This website never invokes it.
Hasta dónde llega realmente el aislamiento de la puerta es un límite, no una estructura, y está registrado en Estado y límites.
Antes de que corra cualquier código de la candidata, un bootstrap externo verifica el SHA-256 del ZIP candidato, comprueba manifest y content-root, y sólo entonces importa el kernel desde bytes sellados y verificados. Este sitio no profundiza más allá de eso — la misma disciplina de adaptador que usa el propio CLI de este sitio, a menor escala, para ligar su importación del kernel a un digest antes de confiar en él.
Cómo llega el núcleo a un resultado.
Cómo funciona esto
- 01
El expediente se canonicaliza
JSON estricto, claves normalizadas, sin floats ni valores ambiguos. Dos expedientes que significan lo mismo deben reducirse a los mismos bytes, o un digest no prueba nada.
- 02
La identidad se compara con pins aportados desde fuera
El núcleo contrasta expediente, política, autoridad y artefacto con digests que quien llama fijó de antemano. Nunca inventa una identidad.
- 03
El grafo de evidencia se valida y luego se razona
Los extremos deben existir, los duplicados se rechazan, y una regla sólo puede consumir la evidencia que declaró. La evidencia de otra ejecución no se puede pedir prestada.
- 04
Reglas finitas producen propiedades, y las propiedades agregan un resultado
Un conjunto pequeño y fijo de operaciones — nunca se ejecuta código aportado — da los tres ejes y, siempre, release_authority: false.