Resumen

  • draft-templeman-scitt-measurement-capsule-00 separa la declaración, la observación externa y la diferencia, y fija que la cápsula no otorga autoridad de ejecución.
  • Una lectura parcial produce UNCHECKABLE, no ausencia ni fallo; una firma válida tampoco demuestra que la medición sea correcta o que el sujeto la respalde.
  • Identidad de contenido, inclusión, firma, registro y tiempo son comprobantes distintos. Admitir o excluir exige una decisión separada con principal, alcance, recurso y apelación.

Un índice ofrece cien elementos. El lector recupera noventa y siete antes de que expire el tiempo de espera. El sistema encuentra que uno de esos elementos contradice el manifiesto y que los otros noventa y seis coinciden. ¿Cuántas ausencias ha demostrado?

Ninguna. Tres elementos no fueron leídos. Convertirlos en cero sería inventar una observación; eliminarlos del cálculo alteraría el denominador. Incluso el desacuerdo encontrado sólo demuestra que dos representaciones difieren bajo una consulta concreta.

Ésta es la aportación más fértil de Declared-versus-Observed Measurement Capsules. Al 2 de octubre de 2026, el Datatracker mostraba la revisión 00 como Individual Submission activa, presentada el 27 de septiembre y con vencimiento el 31 de marzo de 2027. El texto declara intención Experimental. No tiene stream IETF ni Area Director responsable. No es RFC, consenso, adopción, certificado ni prueba de interoperabilidad.

El borrador propone un objeto JSON determinista emitido por un tercero que no es el sujeto ni participó en la acción. Conserva lo declarado, lo observado, un diferencial estructurado, digests de fuentes, estado de medición, limitaciones y tiempo. Puede firmarse, agruparse en un árbol de Merkle y registrarse como Signed Statement en SCITT. Su authority_state sólo admite una idea: medición, sin autoridad de ejecución.

La procedencia existe a ambos lados de la comparación

La declaración no flota en el aire. Está en bytes recuperados de un registro, manifiesto, tarjeta o resultado firmado. Hace falta conservar versión, dirección, hora, identidad y digest. El sujeto pudo actualizar una región antes que otra; el intermediario pudo servir caché; la consulta pudo usar una vista equivocada.

La observación también es una producción. El medidor escoge ubicación, credential, método, timeout, parser, reloj y momento. Puede verificar una firma, repetir una evaluación o leer un estado de ledger. Cada elección limita lo que el resultado puede decir.

Por eso INCONSISTENT no es sinónimo de mentira. La declaración puede estar obsoleta; la observación también. Los dos valores pueden describir scopes diferentes. El diferencial sólo registra la diferencia. Las limitaciones deben mostrar qué no se aprendió.

La escalera de evidencia evita otra confusión. Comprobar una prueba contra el commitment de un block header no significa que ese header se verificó contra consenso. Guardar una prueba no equivale a verificarla. Una respuesta de API sigue siendo la declaración del operador. El constructor no debe elevar la etiqueta para complacer a un consumidor.

UNCHECKABLE es información, no un hueco

El borrador obliga a registrar la imposibilidad de comprobar. UNCHECKABLE y los estados de incapacidad o ausencia no pueden convertirse en pass, fail, cero u omisión. NOT_LISTED exige una lectura completa. La paginación incompleta, el acceso denegado o un error de identidad no justifican una negación total.

Este requisito conserva el denominador y, con él, la honestidad económica del informe. Un proveedor de mediciones podría seleccionar principalmente sujetos con discrepancias. Cada cápsula sería exacta y el conjunto seguiría siendo engañoso. Por eso el batch debería declarar su regla de inclusión y contar exclusiones por motivo.

Un consumidor responsable conserva población elegible, intentos, lecturas completas y excepciones. No compara porcentajes entre batches cuya selección cambió. Tampoco usa la ausencia de una cápsula como prueba de conformidad.

El schema intenta impedir que la evidencia se disfrace de mando

La cápsula prohíbe campos que nombren decisión, allow, reject, approve, admit, authority, permit, enforcement, action o gate, además de varios valores exactos de allow/deny. La lista no puede capturar todos los sinónimos; el texto reconoce esa debilidad y considera allowlists por tipo.

La prohibición sigue siendo valiosa porque obliga a hacer visible la siguiente pieza. Si una plataforma transforma INCONSISTENT en bloqueo, esa regla no viene de la cápsula. Debe existir un registro de decisión separado con principal autorizado, política, versión, interés protegido, umbral, scope, excepciones, duración y mecanismo de apelación.

Una organización puede emitir la medición y operar la plataforma. Aun así, las identidades funcionales no deberían mezclarse. El firmante de evidencia no se convierte automáticamente en quien asume responsabilidad por excluir a un cliente.

El recibo compuesto no es un recibo universal

La identidad capsule_id se calcula con SHA-256 sobre la serialización JCS RFC 8785, excluyendo el propio identificador. El fichero conserva exactamente esos bytes. Los identificadores ordenados alimentan la Merkle Tree Hash de RFC 9162. Una audit path prueba que la cápsula estaba en el batch.

COSE_Sign1 puede firmar el objeto o su Hash Envelope. SCITT puede registrar el Signed Statement y producir un Receipt. OpenTimestamps o una entrada de Rekor aportan otras clases de compromiso, pero el borrador no los llama recibos SCITT.

El contenido hash responde “¿qué bytes?”. Merkle responde “¿estaba en este conjunto?”. La firma responde “¿qué clave firmó?”. El Receipt responde “¿qué registró este servicio bajo su política?”. Una prueba temporal responde “¿cuándo existía el commitment según este mecanismo?”. Ninguna responde por sí sola “¿es correcta la medición?” o “¿debemos bloquear?”.

El borrador permite que effect_reference apunte por digest a un recibo de autorización o efecto emitido bajo otro perfil, sin copiar su outcome. Así una aprobación, una ejecución y una medición independiente pueden relacionarse sin fingir un único emisor. El prototipo aún no ha poblado ese campo; hoy es diseño, no evidencia de composición real.

Corregir sin borrar obliga a reparar el efecto

Las cápsulas no se editan. Una corrección crea otra cápsula y otro batch, apunta al registro anterior, conserva before/after y explica la causa. La versión sustituida sigue disponible. Si cambia JCS o la construcción del árbol, cambian IDs y raíces aunque la interpretación del dato parezca igual.

Esta persistencia permite reconstruir qué información vio un decisor. También significa que una cápsula errónea no desaparece. El sujeto necesita un canal de corrección o exclusión. La plataforma debe reabrir su decisión, invalidar cachés y registrar la restauración. Publicar la corrección sin reconciliar la consecuencia sólo mejora el archivo.

La append-only transparency distribuye memoria, no justicia. La justicia aparece cuando un principal acepta revisar la acción, revertirla cuando corresponda y asumir el coste.

Un digest puede revelar una fuente privada

Guardar digests en lugar de evidencia reduce exposición directa. No protege un valor privado de baja entropía. Si el secreto sólo puede ser uno de diez estados o una configuración corta, cualquiera puede calcular candidatos y reconocer el hash.

El texto recomienda blinding y dice que su implementación no lo ofrece. También limita la observación a superficies publicadas para máquinas, evita credentials y detiene MCP en discovery. Estas restricciones pueden impedir verificar un claim. La respuesta correcta es UNCHECKABLE, no ampliar la recolección sin permiso.

Los números del prototipo siguen siendo afirmaciones del autor

La sección de implementación informa de 13.184 cápsulas, ocho batches y siete tipos al 26 de septiembre, además de un verificador web, compromisos OpenTimestamps/Rekor y un checker escrito sin compartir código. Son datos aportados por la organización autora.

El checker no es una implementación independiente porque procede de la misma organización. Faltan COSE_Sign1, registro real en un Transparency Service SCITT, effect_reference y digests cegados. El borrador distingue correctamente estas carencias.

Su experimento pide que otro actor reproduzca IDs y raíces, un servicio ajeno registre el batch, un tercero verifique el Receipt, se conecten emisores distintos y las correcciones mantengan el histórico. Si nada ocurre en dos revisiones, el autor promete retirar el borrador. Esa condición merece más atención que el volumen actual: convierte madurez en resultados observables.