Zusammenfassung

  • draft-mih-agent-settlement-records-00 lässt Zahler und Empfänger jeweils nur die Beobachtung ihres eigenen Systems versiegeln. Erst ein Prüfer leitet aus beiden Beinen den Zahlungszustand ab; kein einzelner Datensatz darf ihn behaupten.
  • Zahlungs- und Lieferzustand sind unabhängig. Eine Zahlung kann agreed sein, während die Lieferung none bleibt. Bilateraler Finanzabgleich ist daher kein Erfüllungsnachweis.

Eine Zahlung kann in beiden Büchern stimmen und der Austausch trotzdem unvollständig sein. Diese Trennung steht im Zentrum von Two-Party Settlement Records for Agent Payments, Revision 00 vom 2. Oktober 2026.

Der Vorschlag kennt bis zu vier Beine: Bedingungen, Zahlerbeobachtung, Empfängerbeobachtung und Lieferung. Jeder Versiegler berichtet ausschließlich, was sein eigenes System gesehen hat. Ein fremdes Beweisstück darf per Digest zitiert werden; dadurch wird es nicht zur eigenen Beobachtung.

Der Gesamtzustand steht in keinem Bein. Ein Prüfer kontrolliert zunächst Capsule, Producer Envelope, Struktur, Beträge, eingebettete Objekte, Rollen und seine lokale Schlüsselrichtlinie. Anschließend gruppiert er gültige Beine nach Bedingungsreferenz und typisierter Zahlungsreferenz und berechnet den Zustand aus ihren Bytes.

Spricht nur eine Seite, bleibt es eine Behauptung. payer_stated beschreibt den gemeldeten Abgang, payee_stated den gemeldeten Eingang. Das fehlende Gegenstück beweist keinen Widerspruch: Es kann noch nicht existieren, zurückgehalten oder nie erzeugt werden. Der verwandte Evidence-Request-Entwurf trennt Antwort, signierte Ablehnung und dokumentierte Abwesenheit.

agreed verlangt zwei verknüpfbare Beobachtungen, akzeptierte unterschiedliche Schlüssel, dieselbe normalisierte Zahlungsreferenz, gleichen Status und eine exakte Betragsregel. Zahlerbetrag muss Empfängerzugang plus Empfangsgebühr entsprechen, im selben Asset und auf gemeinsamer Skala. Toleranz ist nicht vorgesehen; ein Vergleich ohne Gebühr würde dagegen ehrliche Differenzen falsch bewerten.

Übereinstimmung der Seiten ist noch keine Übereinstimmung mit den Bedingungen. Beide Systeme können denselben Fluss melden und gemeinsam vom vereinbarten Betrag abweichen. Ob Gebühren zulässig waren, entscheidet sich an Bedingungen und lokaler Geschäftspolitik.

Die Lieferung folgt einer eigenen Zustandsmaschine. Kein Lieferbein ergibt none, eine nicht widersprechende Einzelstimme stated, gleiche Digests von Versand und Empfang matched, abweichende Digests mismatch. Umgekehrt kann Lieferung übereinstimmen, während die Zahlung nur payee_stated ist.

Ein gleicher Digest bindet Bytes, nicht jede Leistungspflicht. Qualität, Frist, Softwarefunktion, Annahmebefugnis und Ende vertraglicher Rechtsbehelfe brauchen zusätzliche Regeln und Belege. Das gilt besonders, wenn physische Güter oder fortlaufende Dienste nicht auf einen einzelnen Inhalt reduzierbar sind.

Auch Finanzstatus bleibt perspektivisch. settled bedeutet final auf der Seite des Versieglers — Belastung beim Zahler, Gutschrift oder Empfang beim Begünstigten. reversed ist vorgesehen, spätere Beobachtungen sollen frühere ersetzen. Daraus folgt keine railübergreifende Unumkehrbarkeit.

Zwei Schlüssel sind noch keine zwei berechtigten Parteien. Der Entwurf definiert keine Vertrauenspolitik dafür, welcher Schlüssel für Zahler oder Empfänger sprechen darf. Getrennte Schlüssel verhindern eine künstliche Doppelstimme mit demselben Schlüssel; die Zuordnung muss der Prüfer dennoch verantworten.

Bereits signierte Zahlungsobjekte werden per Digest erhalten und dürfen nicht neu signiert werden. Die Hülle beweist Aufnahme bestimmter Bytes, nicht deren ursprüngliche Ausstellung. Ebenso beweist ein SCITT-Receipt nur die Registrierung in einem benannten Transparenzdienst, weder Wahrheit noch Bilateralität.

Institutionell bleibt der Text ein individueller Internet-Draft ohne Stream oder Standards Level. Seine Abbildungen auf x402, AP2, Payment HTTP, Open Payments, Lightning und ISO 20022 sind Vorschläge des Entwurfs, keine nachgewiesene Übernahme durch diese Systeme.

Lu Hengs Minimum Initial Specification spricht für eine kleine gemeinsame Form, in der unabhängige Beobachtungen zusammengeführt werden, während Folgenentscheidungen lokal bleiben. Running-Code Primacy fragt nach tatsächlich geprüften Objekten, Schlüsseln, Normalisierung und aktueller Supersession-Kette. Reality Layers hält Beobachtung, Zahlungsabgleich, Lieferung und Vertragserfüllung auseinander.

Ein belastbarer Entscheidungsbeleg bewahrt deshalb Beine, Fehler, Schlüsselpolitik, Zahlungszustand, Bedingungsvergleich, Lieferzustand, Objektprüfung, aktuelle Version und lokale Konsequenz. Nur so lässt sich im Streit erkennen, wo technische Übereinstimmung endete.

Quellen