Blog / BABYLON-60
Cómo leer el Verification Mirror sin ampliar sus conclusiones
Una ruta de revisión para distinguir archivos coherentes, identidad de publicación y evidencia histórica del runtime.
Fijar qué paquete estás revisando
Empieza por la revisión del repositorio y el manifiesto del paquete. El mirror incluye fuentes formales, declaraciones de claims e informes para inspeccionarlos sin el árbol de trabajo del autor. Una fecha de empaquetado identifica esa publicación, mientras que el informe de ejecución conserva su propia fecha y fuente. Pueden corresponder a momentos distintos. Antes de comparar cifras o conclusiones, comprueba qué archivos se incluyeron y a qué revisión se refiere cada resultado.
Ejecutar el comando y leer su alcance
Desde el repositorio o el ZIP extraído, ./verify.sh comprueba la integridad y las vinculaciones del manifiesto antes de ejecutar lake build. Requiere Python y la versión de Lean indicada en lean-toolchain. Una salida correcta acredita esas comprobaciones y la compilación de AX0; no vuelve a ejecutar el arnés completo. Lee también los fallos registrados y la diferencia entre estados verificados y acotados. El código de salida no reemplaza la interpretación del informe.
Separar identidad y ejecución
Una huella publicada junto al ZIP facilita comprobar coherencia, pero no constituye una identidad independiente. Para comprobar una firma necesitas una clave pública obtenida por un canal de confianza y el modo de verificación correspondiente. Los informes históricos conservan sus límites: pruebas P-256 software no demuestran presencia humana en Secure Enclave, y SIGKILL no representa un corte eléctrico. El mirror permite examinar estas diferencias; no transforma informes antiguos en una atestación nueva del sistema actual.