Résumé

  • draft-mih-agent-settlement-records-00 propose que le payeur et le bénéficiaire scellent chacun ce que leur propre système a observé. Le vérificateur, et non une des parties, déduit ensuite si les deux volets du paiement concordent.
  • L’état du paiement et celui de la livraison sont indépendants : le paiement peut être agreed alors que la livraison est none. L’accord bilatéral ne vaut donc pas reçu d’exécution commerciale.

Deux livres peuvent raconter la même sortie et la même entrée d’argent sans dire ce qui a traversé le comptoir en sens inverse. C’est le point de départ de Two-Party Settlement Records for Agent Payments, révision 00, déposée le 2 octobre 2026.

Le projet compose un règlement à partir de quatre types de volets au maximum : conditions, observation du payeur, observation du bénéficiaire et livraison. Chaque scelleur ne parle que pour son propre système. Détenir la pièce adverse permet de la citer par empreinte ; cela ne transforme pas l’observation adverse en fait observé chez soi.

Cette discipline déplace le verdict vers le vérificateur. Aucun volet n’inscrit « accord » ou « désaccord » dans l’objet. Avant toute combinaison, le vérificateur contrôle la capsule, l’enveloppe de production, la structure, les montants, les objets encapsulés, le rôle annoncé et sa propre politique d’acceptation des clés. Une pièce qui échoue reste signalée mais ne produit pas l’état dérivé.

Un seul côté demeure une déclaration. payer_stated rapporte ce que le système du payeur affirme avoir débité ; payee_stated, ce que le système du bénéficiaire affirme avoir reçu. L’absence du second volet ne prouve pas un désaccord. Il peut ne pas encore exister, ne pas avoir été partagé ou ne jamais être produit. Le projet connexe sur les demandes de preuve distingue précisément réponse, refus signé et absence enregistrée.

Pour obtenir agreed, les deux volets doivent être joignables, scellés sous des clés distinctes acceptées, porter la même référence de paiement normalisée, le même statut et satisfaire une égalité exacte. Le montant du payeur doit égaler le montant reçu plus les frais de réception, dans le même actif et à une échelle commune. Une tolérance, même d’une unité, est interdite ; ignorer les frais créerait au contraire un faux conflit.

Cet accord reste plus étroit que les conditions. Les deux systèmes peuvent tomber d’accord sur ce qui a circulé tout en s’écartant ensemble du montant promis. Le caractère acceptable des frais relève des conditions et de la décision commerciale, pas de la simple concordance.

La livraison possède sa propre machine d’état. Sans volet livré : none. Avec une déclaration non contradictoire d’un seul côté : stated. Si envoi et réception portent la même empreinte de contenu : matched. Si les empreintes divergent, ou contredisent celle des conditions : mismatch. Le projet dit également que la livraison peut correspondre alors que seul le bénéficiaire a déclaré le paiement.

Une empreinte identique circonscrit les octets, pas toute l’obligation. Elle ne prouve pas seule la qualité d'un objet, la ponctualité d'un service, le bon fonctionnement d'un logiciel, l'autorité de la personne qui accepte ni l'épuisement des recours contractuels. Fermer un litige exige une règle locale et des preuves adaptées à l'objet de l'échange.

Les statuts financiers restent eux aussi perspectifs. settled signifie final du côté du scelleur : débité pour le payeur, crédité ou reçu pour le bénéficiaire. Le modèle prévoit reversed, et un volet plus récent devrait supplanter le précédent. Rien ne justifie donc de traduire « settled » par irréversible dans tous les rails.

Deux clés différentes ne suffisent pas à nommer deux parties autorisées. Le projet laisse expressément hors champ la politique qui rattache une clé à un payeur ou à un bénéficiaire. La règle des clés distinctes empêche une seule clé de fabriquer les deux moitiés, mais le vérificateur garde la responsabilité d'accepter ou non chacune d'elles.

Les objets signés existants sont conservés par empreinte et ne doivent pas être resignés. La signature de l'enveloppe prouve l'inclusion de ces octets, non leur émission par le scelleur. De même, un reçu SCITT prouve l'inscription d'un volet dans un journal donné ; il ne rend pas son contenu vrai et ne crée pas une seconde partie absente.

Le statut institutionnel demeure borné. Le Datatracker présente un Internet-Draft individuel, sans stream ni niveau de normalisation. Les correspondances proposées avec x402, AP2, Payment HTTP, Open Payments, Lightning ou ISO 20022 sont celles de l'auteur du projet, pas des preuves d'adoption par ces écosystèmes.

La spécification initiale minimale de Lu Heng indique la bonne architecture : partager la plus petite forme permettant aux observations de se rencontrer, puis conserver localement la décision à conséquences. Running-Code Primacy demande quels objets, clés, règles de normalisation et têtes de remplacement ont réellement été traités. Reality Layers empêche de confondre observation signée, accord de paiement, livraison et exécution contractuelle.

Le reçu décisif doit donc conserver les quatre niveaux. Volets disponibles, échecs de validation, politique de clés, état de paiement, comparaison aux conditions, état de livraison, vérification des objets, version la plus récente et décision locale doivent rester reconstruisibles.

Sources