diff --git a/docs/joyas-reusables.md b/docs/joyas-reusables.md
index e2bfd232..52cea412 100644
--- a/docs/joyas-reusables.md
+++ b/docs/joyas-reusables.md
@@ -22,6 +22,24 @@ ya usa como identidad se convierte en verificación por-lectura del kernel. Cost
 **Gate barato:** prototipo de `hammer hydrate --backend composefs` sobre un artefacto sellado;
 comparar con hardlink en frío/caliente. No reemplaza ADR 0005 — convive como backend.
 
+**Prototipo MEDIDO (2026-07-17, laptop, composefs 1.0.8, sobre el product-rootfs sellado
+`ba351f1b…`, 262MB / 730 entradas):**
+- `hammer hydrate` (hardlink, ADR 0005): **28ms**. `mkcomposefs --digest-store`: **507ms**
+  (incluye hashear todo al objects/). El manifiesto `.cfs` resultante: **136KB firmables**
+  para el rootfs entero.
+- La comparación de velocidad es la métrica equivocada: ambos son sub-segundo. Lo que
+  composefs compra y el hardlink NO puede dar: (1) fs-verity por fichero en runtime —
+  integridad verificada en cada lectura, el cierre §5 en serio; (2) proyección
+  genuinamente read-only — **con hardlinks, un write con privilegios a través del árbol
+  hidratado corrompe el store** (comparten inode); con composefs es imposible por
+  construcción; (3) el manifiesto chico como unidad de firma/distribución.
+- **Hallazgo de diseño**: el objects/ de composefs se indexa por digest **fs-verity
+  (sha256)**, no por `b3:` ⇒ el backend mantiene un objects/ paralelo al store (lo
+  construye `mkcomposefs --digest-store` solo, y DEDUPLICA contenido entre artefactos)
+  o hammer guarda el mapa b3→verity al sellar. No es bloqueante, es una tabla.
+- **Pendiente (pide root)**: montar el `.cfs` (overlayfs+EROFS) y medir lectura
+  fría/caliente vs hardlink. El kernel linux-metal re-sellado ya trae EROFS+FS_VERITY.
+
 ## 2. PGO/BOLT con perfil sellado — la que NADIE probó bien
 
 **El problema ajeno.** PGO y BOLT dan 10–20% real (Fedora ya envía clang/rustc bolteados),