Resumen

  • draft-mih-agent-settlement-records-00 pide que pagador y beneficiario sellen solo la observación de su propio sistema. Un verificador deriva después si ambas patas del pago concuerdan; ningún registro declara por sí solo el resultado conjunto.
  • Pago y entrega tienen estados independientes. El borrador permite expresamente un pago agreed con entrega none, por lo que la coincidencia bilateral no acredita el cumplimiento de la contraprestación.

La contabilidad puede cerrar por ambos lados mientras el intercambio sigue abierto. Ese es el límite más valioso de Two-Party Settlement Records for Agent Payments, revisión 00, incorporada al Datatracker el 2 de octubre de 2026.

La propuesta organiza hasta cuatro patas: términos, observación del pagador, observación del beneficiario y entrega. Cada firmante habla únicamente de su propio sistema. Puede conservar y citar la evidencia de la contraparte por su resumen criptográfico, pero no apropiarse de ella como observación propia.

El estado agregado no aparece escrito en ninguna pata. Lo calcula el verificador después de comprobar cápsula, envoltura del productor, estructura, importes, objetos incluidos, coherencia de roles y política local de claves. Una pata inválida queda asociada a su fallo y no participa en la derivación.

Si solo habla una parte, el resultado sigue siendo una afirmación unilateral. payer_stated informa del lado del pagador y payee_stated del beneficiario. La ausencia contraria no implica desacuerdo: tal vez la segunda pata no exista aún, no se haya compartido o nunca se produzca. El modelo de solicitud de evidencia distingue respuesta, negativa firmada y ausencia registrada.

Para llegar a agreed, ambos registros deben poder unirse, estar sellados con claves distintas aceptadas, referirse al mismo pago normalizado, compartir estado y satisfacer una igualdad exacta. El importe del pagador debe ser igual a lo recibido por el beneficiario más la comisión de recepción, con el mismo activo y una escala común. No se admite tolerancia; comparar directamente enviado y recibido también sería incorrecto cuando hay una comisión legítima.

Coincidir entre sí no significa coincidir con el contrato. Ambas partes pueden describir el mismo movimiento y, juntas, apartarse de los términos. Que una comisión resulte aceptable exige leer las condiciones y aplicar política comercial; no se deduce de la simetría de las firmas.

La entrega funciona por otra vía. Sin pata de entrega, el estado es none. Un solo lado no contradictorio produce stated. Los resúmenes iguales de contenido enviado y recibido producen matched; los diferentes, o los que chocan con los términos, producen mismatch. También puede haber entrega coincidente y únicamente una declaración del beneficiario sobre el pago.

Un resumen de contenido identifica bytes, no toda la prestación. No demuestra por sí mismo calidad, puntualidad, funcionamiento, autoridad para aceptar ni extinción de remedios. Para un servicio o un bien físico, esos juicios necesitan pruebas y reglas propias.

Los estados de pago siguen siendo locales. settled significa final para el sistema del firmante: débito del pagador o crédito/recepción del beneficiario. La propuesta contempla reversed y recomienda que una observación posterior sustituya a la anterior. No existe aquí una garantía universal de irreversibilidad.

Tampoco basta con contar dos claves. La política que vincula una clave con un pagador o beneficiario autorizado queda fuera del borrador. Exigir claves distintas evita que una sola clave fabrique las dos voces, pero el verificador debe decidir si cada voz pertenece a quien dice representar.

Los objetos firmados de protocolos existentes se preservan por resumen y no deben volver a firmarse. La envoltura prueba inclusión, no autoría del objeto original. Del mismo modo, un recibo SCITT prueba entrada en un registro de transparencia concreto; no certifica la verdad del contenido ni convierte una pata unilateral en bilateral.

Conviene no adelantar el estado institucional. El documento es un Internet-Draft individual, sin stream ni nivel de estándar. Sus cruces con x402, AP2, Payment HTTP, Open Payments, Lightning e ISO 20022 son propuestas del texto, no adopciones demostradas por esos sistemas.

La Especificación Inicial Mínima de Lu Heng aconseja compartir la forma estrictamente necesaria para unir observaciones y dejar local el juicio que desencadena consecuencias. Running-Code Primacy exige conocer objetos, claves, reglas de normalización y cadena vigente. Reality Layers mantiene separados observación firmada, acuerdo de pago, entrega y cumplimiento jurídico o comercial.

El recibo operativo debe conservar esas capas: patas presentes, fallos, política de claves, estado derivado del pago, comparación con términos, estado de entrega, verificación de objetos, sustituciones y decisión local. Solo así una disputa puede mostrar dónde terminó la coincidencia técnica.

Fuentes