agent-receipt-verify 0.2.4 → 0.2.6

package/bin/cli.mjs

@@ -9,7 +9,7 @@
 // BEWUST GEEN NPM-PUBLICATIE NODIG. npx kan een pakket rechtstreeks uit een git-repo
 // draaien, dus dit werkt zonder dat er iets op npm staat:
 //
-//   npx github:holistis/agent-receipt-verify https://een-eindpunt.example/pad
+//   npx -y agent-receipt-verify https://een-eindpunt.example/pad
 //
 // Dat is geen trucje maar een echte eigenschap van npx, en het haalt een hele
 // publicatie-stap plus een naamclaim weg. Het betekent ook dat niemand een
@@ -23,54 +23,61 @@
 const args = process.argv.slice(2)
 const eerste = args[0]
 
+// De helptekst is ENGELS, en dat is geen voorkeur maar een gemeten noodzaak. Koud
+// gedraaid vanuit een lege map op 18 oktober 2026 bleek het eerste scherm dat een vreemde
+// ziet half Nederlands, terwijl iedereen die dit gereedschap in de x402- en
+// erc-8004-draden gaat draaien Engels schrijft. Het meetresultaat zelf was al Engels, dus
+// alleen de ingang stond nog in de weg. En de regel over wat dit NIET meet stond midden
+// in de lijst in plaats van eronder, waar een lezer hem pas leest nadat hij weet wat het
+// wel doet.
 function gebruik() {
-  console.log('agent-receipt-verify, een onafhankelijke controle op bonnetjes van agent-betalingen')
+  console.log('agent-receipt-verify, an independent check on receipts for agent payments')
   console.log('')
-  console.log('  npx github:holistis/agent-receipt-verify <url> [url ...]')
-  console.log('        meet een x402-eindpunt tegen de ladder in CONFORMANCE.md (trede 0 tot 2,')
-  console.log('        zonder te betalen). Trede 3 tot 5 vereisen een echte afrekening en komen')
-  console.log('        terug als ONGEMETEN, nooit als afgekeurd.')
+  console.log('  npx -y agent-receipt-verify <url> [url ...]')
+  console.log('        measures an x402 endpoint against the ladder in CONFORMANCE.md (levels 0')
+  console.log('        to 2, without paying). Levels 3 to 5 need a real settlement and come back')
+  console.log('        as NOT MEASURED, never as a failure.')
   console.log('')
-  console.log('  npx github:holistis/agent-receipt-verify census [uit.json]')
-  console.log('        telt een discovery-index per host in plaats van per resource.')
+  console.log('  npx -y agent-receipt-verify census [out.json]')
+  console.log('        counts a discovery index per host instead of per resource.')
   console.log('')
-  console.log('  npx github:holistis/agent-receipt-verify link --receipt=<bestand>')
-  console.log('        zoekt bij een bonnetje van versie 2 de bijbehorende afrekening op de keten.')
+  console.log('  npx -y agent-receipt-verify link --receipt=<file>')
+  console.log('        for a version 2 receipt, finds the settlement it belongs to on chain.')
   console.log('')
-  console.log('  npx github:holistis/agent-receipt-verify mcp')
-  console.log('        draait als MCP-server over stdio, zodat een agent deze controle AANROEPT')
-  console.log('        in plaats van hem aanbevolen te krijgen. Twee gereedschappen: controleer een')
-  console.log('        eindpunt voor je betaalt, en link een bonnetje aan een echte afrekening.')
+  console.log('  npx -y agent-receipt-verify mcp')
+  console.log('        runs as an MCP server over stdio, so an agent CALLS this check instead of')
+  console.log('        being advised to run it. Two tools: check an endpoint before you pay, and')
+  console.log('        link a receipt to a real settlement.')
   console.log('')
-  console.log('  npx github:holistis/agent-receipt-verify inam <vectors.json>')
-  console.log('        controleert countersigned bonnetjes tegen gepubliceerde vectoren.')
+  console.log('  npx -y agent-receipt-verify inam <vectors.json>')
+  console.log('        checks countersigned receipts against published vectors.')
   console.log('')
-  console.log('Wat dit NIET doet: het oordeelt over de VORM van een bonnetje, niet over de')
-  console.log('eerlijkheid van de partij die het afgaf. Zie CONFORMANCE.md voor wat met opzet')
-  console.log('niet gemeten wordt.')
-  console.log('')
-  console.log('  npx github:holistis/agent-receipt-verify kanon')
+  console.log('  npx -y agent-receipt-verify kanon')
   console.log('        cross-check our independent EIP-3009 verifier against the ten published')
   console.log('        vectors of iamonuwa/kanon, offline, no account and no key.')
   console.log('')
-  console.log('  npx github:holistis/agent-receipt-verify beleid')
+  console.log('  npx -y agent-receipt-verify beleid')
   console.log('        the same ten vectors under both amount policies, plus the two cases no')
   console.log('        published vector covers: overpayment, and one nonce across two payers.')
   console.log('        Those two are the open questions in x402 issue 2725.')
   console.log('')
-  console.log('  npx github:holistis/agent-receipt-verify liveness [uit.json]')
+  console.log('  npx -y agent-receipt-verify liveness [out.json]')
   console.log('        takes the census and asks each host whether it still answers 402 today.')
   console.log('        A registration in an index is not a promise that the endpoint is alive.')
   console.log('')
-  console.log('  npx github:holistis/agent-receipt-verify verify-delivery --answer=<file> --endpoint=<url>')
+  console.log('  npx -y agent-receipt-verify verify-delivery --answer=<file> --endpoint=<url>')
   console.log('        reads, at the source, whether a paid answer is TRUE. The location is')
   console.log('        DERIVED from --endpoint and never taken from the answer, because a seller')
   console.log('        who picks both the token and the place can stage any outcome.')
   console.log('')
-  console.log('  npx github:holistis/agent-receipt-verify link-vectors')
+  console.log('  npx -y agent-receipt-verify link-vectors')
   console.log('        twelve vectors for the half AFTER paying: does this receipt belong to')
   console.log('        that one settlement? Eleven run offline, the chain-reading one is')
   console.log('        marked and skipped rather than failed.')
+  console.log('')
+  console.log('What this does NOT do: it judges the SHAPE of a receipt, not the honesty of')
+  console.log('the party that issued it. See CONFORMANCE.md for what is deliberately left')
+  console.log('unmeasured.')
 }
 
 // Het argument bepaalt welke module draait. De modules zijn ook los te draaien en te
@@ -104,7 +111,7 @@ if (!eerste || eerste === '--help' || eerste === '-h' || eerste === 'help') {
   process.argv = [process.argv[0], pad, ...args]
   await import('../src/x402-conformance-check.mjs')
 } else {
-  console.log('onbekend: ' + eerste)
+  console.log('unknown command: ' + eerste)
   console.log('')
   gebruik()
   process.exitCode = 2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-receipt-verify",
-  "version": "0.2.4",
+  "version": "0.2.6",
   "description": "Checks x402 endpoint conformance before an agent pays, and links the receipt to its settlement.",
   "license": "Apache-2.0",
   "type": "module",
@@ -8,7 +8,7 @@
     "node": ">=20"
   },
   "scripts": {
-    "test": "node test/interop.mjs && node test/canonical.mjs && node test/link-onchain.mjs && node test/profiel.mjs && node test/eip3009.mjs && node test/conformance.mjs && node test/jws-offer.mjs && node test/census.mjs && node test/poortwachters.mjs && node test/metingen-bundel.mjs && node test/mcp-server.mjs && node test/cli.mjs && node test/bundel.mjs && node test/settlement-link-vectors.mjs && node test/naar-kanon-vorm.mjs && node test/verify-delivery.mjs",
+    "test": "node test/interop.mjs && node test/canonical.mjs && node test/link-onchain.mjs && node test/profiel.mjs && node test/eip3009.mjs && node test/conformance.mjs && node test/jws-offer.mjs && node test/census.mjs && node test/poortwachters.mjs && node test/metingen-bundel.mjs && node test/mcp-server.mjs && node test/cli.mjs && node test/bundel.mjs && node test/settlement-link-vectors.mjs && node test/naar-kanon-vorm.mjs && node test/verify-delivery.mjs && node test/acceptance-binding.mjs",
     "link-example": "node src/x402-link-onchain.mjs --receipt=examples/receipt-live-base-sepolia.json && node src/x402-link-onchain.mjs --receipt=examples/receipt-live-base-sepolia-2.json && node src/x402-link-onchain.mjs --receipt=examples/receipt-live-base-sepolia-3.json",
     "conformance": "node src/x402-conformance-check.mjs",
     "bench": "node bench/robustness.mjs",

package/src/acceptance-binding.mjs

@@ -0,0 +1,309 @@
+// Koppelt laag 3 aan laag 4: hoort dit acceptatierecord bij dit bonnetje.
+//
+// WAAROM DIT EEN EIGEN BESTAND IS EN NIET BIJ DE SETTLEMENT-LINK HOORT. De
+// settlement-link-vectoren beantwoorden een andere vraag: opent de gezouten belofte in
+// een bonnetje op precies een afrekening op de keten. Dat is betaalbewijs. Een
+// acceptatierecord beantwoordt iets anders: heeft een onafhankelijke partij het geleverde
+// bestand getoetst aan criteria die al vastlagen. Een uitgever die beide door elkaar
+// haalt levert een lezer een vlaggetje "onderbouwd" waarvan niemand meer kan zien welke
+// van de twee vragen nu eigenlijk beantwoord is. Daarom twee sets, twee uitkomsten.
+//
+// WAT HIER WEL GEMETEN WORDT. Uitsluitend de BINDING. Noemen het bonnetje en het
+// acceptatierecord hetzelfde opgeleverde bestand, dezelfde machtiging en dezelfde belofte,
+// en lagen de criteria vast voordat er getoetst werd.
+//
+// WAT HIER MET OPZET NIET GEMETEN WORDT, en dat is geen tekortkoming maar de grens van
+// deze laag. Wij toetsen de handtekening van het acceptatierecord NIET, en wij
+// beoordelen zijn criteria NIET. Dat is het werk van de controleur die het record
+// uitgaf, met zijn eigen sleutel en zijn eigen verifieerder. Wie hier een groen antwoord
+// krijgt weet dus dat de twee bewijsstukken over hetzelfde gaan, en niet dat het
+// acceptatierecord zelf klopt. Die twee door elkaar halen is precies de fout die deze
+// module bestaat om te voorkomen.
+//
+// GEMETEN OP EEN ECHT RECORD, 18 oktober 2026, en dat veranderde deze module wezenlijk.
+// De uitgever publiceerde een live record (invinoveritas, trilatic.acceptance-receipt/1.2).
+// Daaruit bleek dat onze eerste aannames over de VORM niet klopten:
+//
+//  1. De hash van het bonnetje staat BOVENIN de sidecar, naast `bindings`, niet erin.
+//  2. De hash van het opgeleverde bestand staat in het ONDERTEKENDE record, op
+//     `record.receipt.files.remediated.sha256`, en helemaal niet in de sidecar.
+//  3. De partijen staan genest in `record.receipt.parties`, met een `key_id` dat leeg
+//     kan zijn, en niet als twee platte tekstvelden.
+//  4. Het tijdstip van de toets heet `issued_utc`, niet `checked_at`.
+//  5. De x402-velden zijn TWEE aparte sleutels, en dat is met opzet zo: een belofte mag
+//     nooit met een nonce vergeleken worden. `x402_receipt_commitment` hoort bij
+//     `authorizationCommitment`, `x402_authorization_nonce` bij `authorizationNonce`.
+//
+// Daarom leest deze module nu de ECHTE vorm, met de vlakke vorm uit onze eerste
+// vectoren als tweede mogelijkheid. Een module die alleen zijn eigen verzonnen vorm
+// aankan, toetst niets in de wereld.
+//
+// EEN AANNAME DIE WEG IS. Onze eerste versie nam aan dat een machtiging in de sidecar
+// gelijk zou zijn aan de nonce in het bonnetje, en las daarvoor ook een generiek veld
+// `authorization`. Dat generieke veld is nu bewust GESCHRAPT. De uitgever splitste de
+// sleutels juist om te voorkomen dat een belofte met een nonce vergeleken wordt, en een
+// generieke terugval zou die bescherming meteen weer weggooien.
+
+const HEX32 = /^[0-9a-f]{64}$/
+
+const genormaliseerdeHash = (w) => {
+  if (typeof w !== 'string') return null
+  const kaal = w.trim().toLowerCase().replace(/^0x/, '')
+  return HEX32.test(kaal) ? kaal : null
+}
+
+const gelijkeHash = (a, b) => {
+  const x = genormaliseerdeHash(a)
+  const y = genormaliseerdeHash(b)
+  return x !== null && y !== null && x === y
+}
+
+const tijdstip = (w) => {
+  if (typeof w === 'number' && Number.isFinite(w)) return w
+  if (typeof w !== 'string' || !w.trim()) return null
+  const ms = Date.parse(w)
+  return Number.isFinite(ms) ? ms / 1000 : null
+}
+
+const tekst = (w) => (typeof w === 'string' && w.trim() ? w.trim().toLowerCase() : null)
+
+/**
+ * Normaliseert zowel het ECHTE record als de vlakke vorm uit onze eerste vectoren naar
+ * de velden die deze module vergelijkt. Een veld dat niet te vinden is wordt null, nooit
+ * een gok, want een gegokt veld levert een oordeel op dat niemand kan narekenen.
+ *
+ * De `naamruimte` bij elke partij is er met opzet: een key_id en een weergavenaam zijn
+ * twee verschillende soorten namen, en die mag je niet met elkaar vergelijken. Zie
+ * onafhankelijkheid() voor waarom dat hier het verschil maakt tussen een hard oordeel en
+ * een onmeetbaar geval.
+ */
+export function leesRecord(doc) {
+  const d = doc && typeof doc === 'object' ? doc : {}
+  const echt = d.record?.receipt ?? null
+  const acceptance = d.acceptance ?? null
+  const sidecar = d.bindings_sidecar ?? d.sidecar ?? null
+
+  const partij = (knoop, plat) => {
+    if (knoop && typeof knoop === 'object') {
+      if (tekst(knoop.key_id)) return { id: tekst(knoop.key_id), naamruimte: 'key_id' }
+      if (tekst(knoop.name)) return { id: tekst(knoop.name), naamruimte: 'name' }
+      return { id: null, naamruimte: null }
+    }
+    return { id: tekst(plat), naamruimte: tekst(plat) ? 'plat' : null }
+  }
+
+  return {
+    // De hash van het opgeleverde bestand, zoals het ONDERTEKENDE record hem noemt.
+    acceptatieLevering:
+      echt?.files?.remediated?.sha256 ?? acceptance?.deliverable_sha256 ?? d.deliverable_sha256 ?? null,
+    // De hash van het bonnetje, bovenin de sidecar.
+    sidecarBonHash: sidecar?.receipt_sha256 ?? d.bindings?.receipt_sha256 ?? null,
+    // De x402-sleutels, in het subobject dat daarvoor bedoeld is.
+    sidecarBindings: sidecar?.bindings ?? d.bindings ?? {},
+    // De vlakke vorm uit onze eerste vectoren noemde de levering ook in de sidecar. Die
+    // staat in een echt record NIET in de sidecar, dus dit is puur terugwaartse steun.
+    sidecarLevering: d.bindings?.deliverable_sha256 ?? sidecar?.deliverable_sha256 ?? null,
+    controleur: partij(echt?.parties?.checker, acceptance?.checker ?? d.checker),
+    producent: partij(echt?.parties?.producer, acceptance?.producer ?? d.producer),
+    onafhankelijkheidVerklaard: tekst(echt?.independence ?? acceptance?.independence ?? null),
+    criteriaVastgelegd:
+      echt?.criteria?.committed_at ?? acceptance?.criteria_committed_at ?? d.criteria_committed_at ?? null,
+    getoetstOp: echt?.issued_utc ?? acceptance?.checked_at ?? d.checked_at ?? null,
+    schema: echt?.schema ?? acceptance?.format ?? null,
+  }
+}
+
+export const ONAFHANKELIJKHEID = [
+  'VERIFIEERBAAR_ONAFHANKELIJK',
+  'NIET_ONAFHANKELIJK',
+  'ZELFVERKLAARD_ONVERIFIEERBAAR',
+  'ONBEKEND',
+]
+
+/**
+ * Kan een DERDE narekenen dat de controleur niet de producent is?
+ *
+ * Dit is bewust een drieweg en geen ja of nee, en daar zit de hele waarde. Het live
+ * record van 18 oktober 2026 zegt `independence: "independent"` terwijl
+ * `parties.producer.key_id` LEEG is. Er is dus niets om de controleur tegen af te zetten:
+ * de onafhankelijkheid is door de uitgever zelf verklaard en door niemand anders na te
+ * rekenen. Dat is geen afkeuring en geen goedkeuring, het is onmeetbaar, en precies dat
+ * onderscheid gaat verloren in een boolean.
+ *
+ * Even belangrijk: een key_id vergelijken met een weergavenaam is GEEN vergelijking. Dat
+ * zijn twee verschillende soorten namen, en "ze zijn verschillend dus onafhankelijk" zou
+ * dan een conclusie zijn die uit het formaat komt en niet uit de werkelijkheid.
+ */
+export function onafhankelijkheid(doc) {
+  const r = leesRecord(doc)
+  const c = r.controleur
+  const p = r.producent
+  if (c.id === null && p.id === null) {
+    return { staat: 'ONBEKEND', reden: 'geen van beide partijen is benoemd', vergelekenOp: null }
+  }
+  if (c.id === null || p.id === null) {
+    return {
+      staat: r.onafhankelijkheidVerklaard === 'independent' ? 'ZELFVERKLAARD_ONVERIFIEERBAAR' : 'ONBEKEND',
+      reden:
+        'een van beide partijen heeft geen identiteit in het record, dus een derde kan niet narekenen ' +
+        'of de controleur en de producent dezelfde partij zijn',
+      vergelekenOp: null,
+    }
+  }
+  if (c.naamruimte !== p.naamruimte) {
+    return {
+      staat: r.onafhankelijkheidVerklaard === 'independent' ? 'ZELFVERKLAARD_ONVERIFIEERBAAR' : 'ONBEKEND',
+      reden:
+        `de partijen zijn in verschillende soorten namen vastgelegd (${c.naamruimte} tegen ${p.naamruimte}), ` +
+        'en die mag je niet met elkaar vergelijken',
+      vergelekenOp: null,
+    }
+  }
+  if (c.id === p.id) {
+    return { staat: 'NIET_ONAFHANKELIJK', reden: 'de controleur en de producent zijn dezelfde partij', vergelekenOp: c.naamruimte }
+  }
+  return { staat: 'VERIFIEERBAAR_ONAFHANKELIJK', reden: null, vergelekenOp: c.naamruimte }
+}
+
+// Is er genoeg om uberhaupt een oordeel te vellen? Ontbreekt er iets aan ONZE kant van de
+// vergelijking, dan is het antwoord NOT_MEASURED en nooit NOT_LINKED. Een ontbrekend veld
+// als "niet gekoppeld" lezen zou een ongemeten geval als een afkeuring laten tellen.
+export function bindingMeetbaar(doc) {
+  const r = leesRecord(doc)
+  const mist = []
+  if (genormaliseerdeHash(r.sidecarBonHash) === null) mist.push('sidecar.receipt_sha256')
+  if (genormaliseerdeHash(r.acceptatieLevering) === null) mist.push('record.receipt.files.remediated.sha256')
+  return mist.length ? { meetbaar: false, mist } : { meetbaar: true, mist: [] }
+}
+
+// De twee voorwaarden van de uitgever zelf (trilatic.acceptance-receipt/1.2): een record
+// telt alleen als de controleur niet de producent is, en als de criteria vastlagen
+// voordat er getoetst werd. Ze staan hier in code omdat een voorwaarde die alleen in
+// proza staat bij de eerste drukke dag wordt overgeslagen.
+//
+// De uitkomst is drieledig, want "ik kan het niet nagaan" is iets anders dan "het is
+// mis". Dat onderscheid is dezelfde correctie die de Kanon-auteur op 17 oktober 2026
+// overnam voor zijn eigen controleur.
+export function recordTelt(doc) {
+  const r = leesRecord(doc)
+  const o = onafhankelijkheid(doc)
+  if (o.staat === 'NIET_ONAFHANKELIJK') return { telt: false, meetbaar: true, reden: 'CHECKER_IS_PRODUCER' }
+  if (o.staat !== 'VERIFIEERBAAR_ONAFHANKELIJK') {
+    return { telt: false, meetbaar: false, reden: 'INDEPENDENCE_NOT_VERIFIABLE', toelichting: o.reden }
+  }
+  const vastgelegd = tijdstip(r.criteriaVastgelegd)
+  const getoetst = tijdstip(r.getoetstOp)
+  if (vastgelegd === null || getoetst === null) {
+    return { telt: false, meetbaar: false, reden: 'CRITERIA_TIMING_UNKNOWN' }
+  }
+  if (!(vastgelegd < getoetst)) {
+    return { telt: false, meetbaar: true, reden: 'CRITERIA_NOT_COMMITTED_FIRST' }
+  }
+  return { telt: true, meetbaar: true, reden: null }
+}
+
+/**
+ * Het eigenlijke oordeel. Drie uitkomsten, nooit twee: gekoppeld, niet gekoppeld, of
+ * niet te meten.
+ *
+ * `receiptSha256` en het bonnetje zelf komen van de AANROEPER, want dat is de kant die
+ * hij in handen heeft. Alles aan de record-kant wordt uit het document gelezen.
+ */
+export function koppelAcceptatie({ receipt, acceptance, bindings, sidecar, doc, receiptSha256, deliverableSha256 }) {
+  // Een aanroeper mag het hele document meegeven, of de losse stukken zoals onze eerste
+  // vectoren dat deden. Beide komen hier op dezelfde genormaliseerde vorm uit.
+  const document = doc ?? {
+    record: acceptance?.record ? acceptance.record : undefined,
+    acceptance,
+    bindings,
+    bindings_sidecar: sidecar,
+  }
+  const r = leesRecord(document)
+
+  const m = bindingMeetbaar(document)
+  if (!m.meetbaar) {
+    return { valid: false, measurable: false, reason_code: 'NOT_MEASURED', missing: m.mist, independence: onafhankelijkheid(document).staat }
+  }
+
+  const telt = recordTelt(document)
+  if (!telt.telt) {
+    return telt.meetbaar
+      ? { valid: false, measurable: true, reason_code: 'NOT_LINKED', detail: telt.reden, independence: onafhankelijkheid(document).staat }
+      : {
+          valid: false,
+          measurable: false,
+          reason_code: 'NOT_MEASURED',
+          missing: [telt.reden],
+          detail: telt.toelichting ?? null,
+          independence: onafhankelijkheid(document).staat,
+        }
+  }
+
+  // Noemt de sidecar het bonnetje dat wij in handen hebben? Zonder een meegegeven hash van
+  // ons eigen bonnetje kan die helft niet getoetst worden, en dan is het niet gemeten.
+  if (receiptSha256 !== undefined) {
+    if (genormaliseerdeHash(receiptSha256) === null) {
+      return { valid: false, measurable: false, reason_code: 'NOT_MEASURED', missing: ['receiptSha256'] }
+    }
+    if (!gelijkeHash(receiptSha256, r.sidecarBonHash)) {
+      return { valid: false, measurable: true, reason_code: 'NOT_LINKED', detail: 'RECEIPT_HASH_MISMATCH' }
+    }
+  }
+
+  // De kern: wijzen het record en wat wij in handen hebben naar hetzelfde opgeleverde
+  // bestand. De aanroeper mag de hash van het bestand dat hij ECHT ontving meegeven; dat
+  // is sterker dan een hash die ook uit de sidecar komt, want dan vergelijk je twee
+  // velden van dezelfde uitgever met elkaar.
+  const onzeKant = deliverableSha256 ?? r.sidecarLevering
+  if (onzeKant === null || onzeKant === undefined) {
+    return {
+      valid: false,
+      measurable: false,
+      reason_code: 'NOT_MEASURED',
+      missing: ['deliverableSha256'],
+      detail: 'het record noemt een opgeleverd bestand, maar er is geen eigen hash om het tegen af te zetten',
+      independence: onafhankelijkheid(document).staat,
+    }
+  }
+  if (!gelijkeHash(r.acceptatieLevering, onzeKant)) {
+    return { valid: false, measurable: true, reason_code: 'NOT_LINKED', detail: 'DELIVERABLE_HASH_MISMATCH' }
+  }
+
+  // De twee x402-sleutels, ELK met zijn eigen tegenhanger. Een belofte wordt nooit met
+  // een nonce vergeleken: daarvoor zijn het twee sleutels. Staat een van de twee kanten
+  // niet in het stuk, dan wordt er niet vergeleken, en dat is geen afkeuring.
+  const b = r.sidecarBindings ?? {}
+  const paren = [
+    {
+      naam: 'COMMITMENT_MISMATCH',
+      sidecar: b.x402_receipt_commitment,
+      bon: receipt?.authorizationCommitment ?? receipt?.payload?.authorizationCommitment,
+    },
+    {
+      naam: 'AUTHORIZATION_MISMATCH',
+      sidecar: b.x402_authorization_nonce,
+      bon: receipt?.authorizationNonce ?? receipt?.payload?.authorizationNonce,
+    },
+  ]
+  const vergeleken = []
+  for (const p of paren) {
+    if (p.sidecar === undefined || p.sidecar === null) continue
+    if (p.bon === undefined || p.bon === null) continue
+    if (!gelijkeHash(p.sidecar, p.bon)) {
+      return { valid: false, measurable: true, reason_code: 'NOT_LINKED', detail: p.naam }
+    }
+    vergeleken.push(p.naam.replace('_MISMATCH', ''))
+  }
+
+  return {
+    valid: true,
+    measurable: true,
+    reason_code: 'LINKED',
+    independence: onafhankelijkheid(document).staat,
+    // Wat er WEL en NIET vergeleken is, want een groen antwoord zonder dat lijstje laat
+    // een lezer denken dat alles getoetst is.
+    compared: vergeleken,
+  }
+}
+
+export const UITKOMSTEN = ['LINKED', 'NOT_LINKED', 'NOT_MEASURED']

package/src/x402-conformance-check.mjs

@@ -51,22 +51,71 @@ function decodeerHeader(waarde) {
  */
 export async function meetEindpunt(url, { fetchImpl = fetch, methode = 'POST', lichaam = null } = {}) {
   const r = { url, treden: {}, bewijs: {} }
-  let resp
-  try {
-    resp = await fetchImpl(url, {
-      method: methode,
+
+  const vraag = (m) =>
+    fetchImpl(url, {
+      method: m,
       headers: { 'User-Agent': UA, Accept: 'application/json', 'Content-Type': 'application/json' },
       // Een gedeclareerd voorbeeldlichaam als de index er een geeft. Een lege {} naar
       // een route die velden eist, levert een 400 die niets over x402 zegt: dan meet
       // je je eigen verzoek in plaats van het eindpunt.
-      body: methode === 'GET' || methode === 'DELETE' ? undefined : lichaam != null ? JSON.stringify(lichaam) : '{}',
+      body: m === 'GET' || m === 'DELETE' ? undefined : lichaam != null ? JSON.stringify(lichaam) : '{}',
       signal: AbortSignal.timeout(15000),
     })
+
+  let resp
+  let gebruikteMethode = methode
+  try {
+    resp = await vraag(methode)
+
+    // EEN EINDPUNT MAG NOOIT AFGEKEURD WORDEN OP EEN METHODE DIE HET NIET AANBIEDT.
+    // Gemeten 18 oktober 2026, op ons eigen eindpunt en koud vanuit een lege map: deze
+    // meter sondeert standaard met POST, en een route die alleen GET bedient antwoordt
+    // daarop correct met 405. Dat werd hier als "haalt trede 0 niet" gelezen, dus als
+    // een fout van het eindpunt, terwijl het een fout van ons verzoek was. Elk
+    // GET-eindpunt in de wereld werd daardoor ten onrechte afgekeurd.
+    //
+    // Dus: bij een 405 een keer opnieuw meten met een methode die het eindpunt zelf
+    // noemt in zijn Allow-kop. Noemt het er geen, dan is GET de enige redelijke tweede
+    // poging, en dat staat dan ook als gok in het bewijs. Een meter die zijn eigen
+    // aanname niet opschrijft, laat een lezer niet zien waar hij kan afwijken.
+    // EN EEN 404 IS DEZELFDE FOUT MET EEN ANDER NUMMER. Gemeten dezelfde dag, op een
+    // eindpunt van een DERDE: api.thaikit.dev/number-text antwoordt 402 met een geldige
+    // payment-required-kop op GET, en 404 op POST. Dat is geen afwijkend eindpunt maar
+    // het normale gedrag van veel webraamwerken, die een pad plus een niet-geregistreerde
+    // methode als "niet gevonden" behandelen in plaats van als "methode niet toegestaan".
+    // Onze meter noemde die levende, correcte verkoper daardoor niet-conform. Alleen de
+    // 405 repareren liet dus de helft van het probleem staan.
+    //
+    // De herhaling blijft bewust smal: alleen 404 en 405, alleen als wij NIET met GET
+    // sondeerden, en precies een keer. Elke 404 blind herhalen zou het verkeer naar elk
+    // dood adres verdubbelen, en dat is niet aan ons om te doen.
+    if (resp.status === 405 || resp.status === 404) {
+      const allow = resp.headers.get('allow') || resp.headers.get('Allow') || ''
+      const genoemd = allow
+        .split(',')
+        .map((s) => s.trim().toUpperCase())
+        .filter((m) => m && m !== methode && m !== 'OPTIONS' && m !== 'HEAD')
+      const tweede = genoemd[0] ?? (methode !== 'GET' ? 'GET' : null)
+      if (tweede) {
+        r.bewijs.methode_opnieuw = {
+          eerste: methode,
+          eerste_status: resp.status,
+          tweede,
+          bron: genoemd.length
+            ? 'Allow header'
+            : 'guessed, the ' + resp.status + ' carried no Allow header',
+        }
+        resp = await vraag(tweede)
+        gebruikteMethode = tweede
+      }
+    }
   } catch (e) {
     r.treden.t0 = 'ONGEMETEN'
     r.bewijs.t0 = 'not reachable: ' + String(e.message).slice(0, 80)
     return r
   }
+  r.bewijs.methode = gebruikteMethode
 
   r.bewijs.status = resp.status
   const tekst = await resp.text().catch(() => '')

package/vectors/acceptance-binding/crossed-deliverable.json

@@ -0,0 +1,40 @@
+{
+  "id": "acceptance-binding-crossed-deliverable",
+  "schema_version": "3.0.0",
+  "verifies": "receipt-to-acceptance",
+  "encodes": "The case babyblueviper1 asked for: an acceptance record paired with a receipt for a different deliverable. It must not link.",
+  "provenance": [
+    "trilatic.acceptance-receipt/1.2, as cited in x402-foundation/tsc#4",
+    "requested in erc-8004/erc-8004-contracts#99 by babyblueviper1 on 18 October 2026: \"a vector in which the acceptance record names a different deliverable hash than the receipt it is paired with. It should not link.\""
+  ],
+  "description": "Identical to the positive control except for one byte of the acceptance record's deliverable hash. Everything else still passes: the sidecar names the right receipt, the checker is independent, and the criteria were committed first. A verifier that reports LINKED here is reading the pair as a whole instead of checking that both halves name the same deliverable, which is the one thing this binding exists to prove.",
+  "requires_chain_read": false,
+  "input": {
+    "receipt": {
+      "format": "eip712",
+      "authorizationNonce": "0x43457c8e57b7c4ff92d716350c61c88c8f3b644d09d7c813d5a7ee6450a843da"
+    },
+    "receiptSha256": "9f2c1d4e8a7b6053fe41cc90b2d7a3418e5f6072c9b8d1a4e7f0352698cdba17",
+    "acceptance": {
+      "format": "trilatic.acceptance-receipt/1.2",
+      "deliverable_sha256": "d74ad7d7c41b8e5206f39ac718be40d5392fb6ca07e1d8359f4b26cd0a39e030",
+      "checker": "invinoveritas-checker-a4cecab2",
+      "producer": "tokenizen-seller-2888f365",
+      "criteria_committed_at": "2026-10-18T00:52:03Z",
+      "checked_at": "2026-10-18T00:52:09Z"
+    },
+    "bindings": {
+      "receipt_sha256": "9f2c1d4e8a7b6053fe41cc90b2d7a3418e5f6072c9b8d1a4e7f0352698cdba17",
+      "deliverable_sha256": "d74ad7d7c41b8e5206f39ac718be40d5392fb6ca07e1d8359f4b26cd0a39e02f",
+      "authorization": "0x43457c8e57b7c4ff92d716350c61c88c8f3b644d09d7c813d5a7ee6450a843da"
+    }
+  },
+  "expected": {
+    "valid": false,
+    "reason_code": "NOT_LINKED",
+    "detail": "DELIVERABLE_HASH_MISMATCH"
+  },
+  "limits": [
+    "This proves the pair does not hold together. It says nothing about which of the two artifacts is the wrong one."
+  ]
+}

package/vectors/acceptance-binding/pairs-same-deliverable.json

@@ -0,0 +1,39 @@
+{
+  "id": "acceptance-binding-pairs-same-deliverable",
+  "schema_version": "3.0.0",
+  "verifies": "receipt-to-acceptance",
+  "encodes": "The positive control. Without it, a set that only contains failures proves nothing about the harness.",
+  "provenance": [
+    "trilatic.acceptance-receipt/1.2, as cited in x402-foundation/tsc#4",
+    "proposed in erc-8004/erc-8004-contracts#99 by babyblueviper1 on 18 October 2026"
+  ],
+  "description": "A signed bindings sidecar names one receipt and one deliverable hash, and the acceptance record names that same deliverable hash. The checker is not the producer, and the criteria were committed before the check. This must link.",
+  "requires_chain_read": false,
+  "input": {
+    "receipt": {
+      "format": "eip712",
+      "authorizationNonce": "0x43457c8e57b7c4ff92d716350c61c88c8f3b644d09d7c813d5a7ee6450a843da"
+    },
+    "receiptSha256": "9f2c1d4e8a7b6053fe41cc90b2d7a3418e5f6072c9b8d1a4e7f0352698cdba17",
+    "acceptance": {
+      "format": "trilatic.acceptance-receipt/1.2",
+      "deliverable_sha256": "d74ad7d7c41b8e5206f39ac718be40d5392fb6ca07e1d8359f4b26cd0a39e02f",
+      "checker": "invinoveritas-checker-a4cecab2",
+      "producer": "tokenizen-seller-2888f365",
+      "criteria_committed_at": "2026-10-18T00:52:03Z",
+      "checked_at": "2026-10-18T00:52:09Z"
+    },
+    "bindings": {
+      "receipt_sha256": "9f2c1d4e8a7b6053fe41cc90b2d7a3418e5f6072c9b8d1a4e7f0352698cdba17",
+      "deliverable_sha256": "d74ad7d7c41b8e5206f39ac718be40d5392fb6ca07e1d8359f4b26cd0a39e02f",
+      "authorization": "0x43457c8e57b7c4ff92d716350c61c88c8f3b644d09d7c813d5a7ee6450a843da"
+    }
+  },
+  "expected": {
+    "valid": true,
+    "reason_code": "LINKED"
+  },
+  "limits": [
+    "The signature on the acceptance record is not checked here, and neither are its criteria. That is the issuing checker's own verifier. A LINKED verdict says the two artifacts are about the same thing, not that the acceptance record itself is sound."
+  ]
+}

package/vectors/acceptance-binding/real-record-as-issued.json

@@ -0,0 +1,68 @@
+{
+  "schema_version": "3.0.0",
+  "verifies": "receipt-to-acceptance",
+  "requires_chain_read": false,
+  "provenance": [
+    "trilatic.acceptance-receipt/1.2, live record fetched from https://api.babyblueviper.com/work-acceptance/record/4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d on 18 October 2026",
+    "the two binding keys were specified by babyblueviper1 in erc-8004/erc-8004-contracts#99 on 18 October 2026",
+    "the record is issued by invinoveritas, not by us; it is copied here as test material"
+  ],
+  "id": "acceptance-binding-real-record-as-issued",
+  "encodes": "A real, live, signed acceptance record whose independence cannot be verified by a third party, because the two parties are named in different namespaces while the issuer declares independence.",
+  "description": "This is the record exactly as the issuer serves it, with only the fields this layer reads. It says independence: \"independent\". The checker is identified by key_id (invinoveritas-checker-a4cecab2). The producer has key_id: null and is identified only by a display name (\"Example Vendor (self-test)\"). A key_id and a display name are two different kinds of name, so comparing them is not a comparison: a reader cannot establish that the checker is not the producer, in either direction. The honest outcome is NOT_MEASURED, not a pass and not a fail. A verifier that returns a pass here is reporting the issuer own claim back to the reader as if a third party had checked it, and a verifier that returns a fail is treating an unmeasured field as a refusal.",
+  "input": {
+    "doc": {
+      "record": {
+        "receipt": {
+          "schema": "trilatic.acceptance-receipt/1.2",
+          "receipt_id": "INV-WA-aa4b8bc740bc2524",
+          "issuer": "invinoveritas",
+          "issued_utc": "2026-10-18T00:52:09Z",
+          "criteria": {
+            "id": "invinoveritas-p1-selftest",
+            "sha256": "d74ad7d7492908f1146b233e89db6ca205065c67f02d33758ff0aa9f8b9e02fc",
+            "committed_at": "2026-10-18T00:52:03Z"
+          },
+          "files": {
+            "remediated": {
+              "name": "refund-policy.txt",
+              "bytes": 121,
+              "sha256": "9c27eee03d50f4ff00fb60a1551a03d7311dbed257b7b943b3ff5d13eb30c083"
+            }
+          },
+          "parties": {
+            "checker": {
+              "name": "invinoveritas",
+              "key_id": "invinoveritas-checker-a4cecab2"
+            },
+            "producer": {
+              "name": "Example Vendor (self-test)",
+              "key_id": null
+            }
+          },
+          "independence": "independent",
+          "verdict": "pass"
+        }
+      },
+      "bindings_sidecar": {
+        "version": "invinoveritas.work-acceptance-bindings/v0",
+        "receipt_sha256": "4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d",
+        "criteria_id": "d74ad7d7492908f1146b233e89db6ca205065c67f02d33758ff0aa9f8b9e02fc",
+        "bindings": {}
+      }
+    },
+    "receiptSha256": "4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d",
+    "deliverableSha256": "9c27eee03d50f4ff00fb60a1551a03d7311dbed257b7b943b3ff5d13eb30c083"
+  },
+  "expected": {
+    "valid": false,
+    "measurable": false,
+    "reason_code": "NOT_MEASURED",
+    "independence": "ZELFVERKLAARD_ONVERIFIEERBAAR"
+  },
+  "limits": [
+    "This says nothing about whether the check itself was good. It says the independence claim is not auditable from the record.",
+    "One field closes it: a key_id on the producer, in the same namespace as the checker. See real-record-with-producer-key.json for the same record with that field set.",
+    "Where a producer has no key at all, the remaining third-party handle on whether two parties are the same hand is the money, not the paperwork. That is a different measurement and it is not this one."
+  ]
+}

package/vectors/acceptance-binding/real-record-crossed-deliverable.json

@@ -0,0 +1,65 @@
+{
+  "schema_version": "3.0.0",
+  "verifies": "receipt-to-acceptance",
+  "requires_chain_read": false,
+  "provenance": [
+    "trilatic.acceptance-receipt/1.2, live record fetched from https://api.babyblueviper.com/work-acceptance/record/4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d on 18 October 2026",
+    "the two binding keys were specified by babyblueviper1 in erc-8004/erc-8004-contracts#99 on 18 October 2026",
+    "the record is issued by invinoveritas, not by us; it is copied here as test material"
+  ],
+  "id": "acceptance-binding-real-record-crossed-deliverable",
+  "encodes": "The case babyblueviper1 asked for, in the shape the issuer actually serves.",
+  "description": "Identical to real-record-with-producer-key except for one byte of the deliverable hash we hold. Everything else still passes: the sidecar names the right receipt, the checker is verifiably not the producer, and the criteria were committed first. A verifier that reports LINKED here is reading the pair as a whole instead of checking that both halves name the same deliverable, which is the one thing this binding exists to prove.",
+  "input": {
+    "doc": {
+      "record": {
+        "receipt": {
+          "schema": "trilatic.acceptance-receipt/1.2",
+          "receipt_id": "INV-WA-aa4b8bc740bc2524",
+          "issuer": "invinoveritas",
+          "issued_utc": "2026-10-18T00:52:09Z",
+          "criteria": {
+            "id": "invinoveritas-p1-selftest",
+            "sha256": "d74ad7d7492908f1146b233e89db6ca205065c67f02d33758ff0aa9f8b9e02fc",
+            "committed_at": "2026-10-18T00:52:03Z"
+          },
+          "files": {
+            "remediated": {
+              "name": "refund-policy.txt",
+              "bytes": 121,
+              "sha256": "9c27eee03d50f4ff00fb60a1551a03d7311dbed257b7b943b3ff5d13eb30c083"
+            }
+          },
+          "parties": {
+            "checker": {
+              "name": "invinoveritas",
+              "key_id": "invinoveritas-checker-a4cecab2"
+            },
+            "producer": {
+              "name": "Example Vendor (self-test)",
+              "key_id": "example-vendor-producer-7f31aa02"
+            }
+          },
+          "independence": "independent",
+          "verdict": "pass"
+        }
+      },
+      "bindings_sidecar": {
+        "version": "invinoveritas.work-acceptance-bindings/v0",
+        "receipt_sha256": "4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d",
+        "criteria_id": "d74ad7d7492908f1146b233e89db6ca205065c67f02d33758ff0aa9f8b9e02fc",
+        "bindings": {}
+      }
+    },
+    "receiptSha256": "4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d",
+    "deliverableSha256": "9c27eee03d50f4ff00fb60a1551a03d7311dbed257b7b943b3ff5d13eb30c084"
+  },
+  "expected": {
+    "valid": false,
+    "reason_code": "NOT_LINKED",
+    "detail": "DELIVERABLE_HASH_MISMATCH"
+  },
+  "limits": [
+    "This proves the pair does not hold together. It says nothing about which of the two artifacts is the wrong one."
+  ]
+}

package/vectors/acceptance-binding/real-record-crossed-x402-keys.json

@@ -0,0 +1,74 @@
+{
+  "schema_version": "3.0.0",
+  "verifies": "receipt-to-acceptance",
+  "requires_chain_read": false,
+  "provenance": [
+    "trilatic.acceptance-receipt/1.2, live record fetched from https://api.babyblueviper.com/work-acceptance/record/4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d on 18 October 2026",
+    "the two binding keys were specified by babyblueviper1 in erc-8004/erc-8004-contracts#99 on 18 October 2026",
+    "the record is issued by invinoveritas, not by us; it is copied here as test material"
+  ],
+  "id": "acceptance-binding-real-record-crossed-x402-keys",
+  "encodes": "Why the format carries two separate keys: a salted commitment must never be compared against a raw nonce.",
+  "description": "The sidecar carries the commitment value in the nonce key and the nonce value in the commitment key. Both are present, both are well-formed 32-byte values, and both belong to the same real payment, so a verifier that treats the two keys as interchangeable, or that falls back to one generic authorization field, will report LINKED. It must not. This is the failure the two-key split was introduced to prevent, and it is the one case a single-field implementation cannot see.",
+  "input": {
+    "doc": {
+      "record": {
+        "receipt": {
+          "schema": "trilatic.acceptance-receipt/1.2",
+          "receipt_id": "INV-WA-aa4b8bc740bc2524",
+          "issuer": "invinoveritas",
+          "issued_utc": "2026-10-18T00:52:09Z",
+          "criteria": {
+            "id": "invinoveritas-p1-selftest",
+            "sha256": "d74ad7d7492908f1146b233e89db6ca205065c67f02d33758ff0aa9f8b9e02fc",
+            "committed_at": "2026-10-18T00:52:03Z"
+          },
+          "files": {
+            "remediated": {
+              "name": "refund-policy.txt",
+              "bytes": 121,
+              "sha256": "9c27eee03d50f4ff00fb60a1551a03d7311dbed257b7b943b3ff5d13eb30c083"
+            }
+          },
+          "parties": {
+            "checker": {
+              "name": "invinoveritas",
+              "key_id": "invinoveritas-checker-a4cecab2"
+            },
+            "producer": {
+              "name": "Example Vendor (self-test)",
+              "key_id": "example-vendor-producer-7f31aa02"
+            }
+          },
+          "independence": "independent",
+          "verdict": "pass"
+        }
+      },
+      "bindings_sidecar": {
+        "version": "invinoveritas.work-acceptance-bindings/v0",
+        "receipt_sha256": "4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d",
+        "criteria_id": "d74ad7d7492908f1146b233e89db6ca205065c67f02d33758ff0aa9f8b9e02fc",
+        "bindings": {
+          "x402_receipt_commitment": "0x43457c8e57b7c4ff92d716350c61c88c8f3b644d09d7c813d5a7ee6450a843da",
+          "x402_authorization_nonce": "0xe04421456465df1012f416b72aece3401f9e3d5be5bd78280324a031efe1d40f"
+        }
+      }
+    },
+    "receipt": {
+      "format": "eip712",
+      "authorizationNonce": "0x43457c8e57b7c4ff92d716350c61c88c8f3b644d09d7c813d5a7ee6450a843da",
+      "authorizationCommitment": "0xe04421456465df1012f416b72aece3401f9e3d5be5bd78280324a031efe1d40f"
+    },
+    "receiptSha256": "4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d",
+    "deliverableSha256": "9c27eee03d50f4ff00fb60a1551a03d7311dbed257b7b943b3ff5d13eb30c083"
+  },
+  "expected": {
+    "valid": false,
+    "reason_code": "NOT_LINKED",
+    "detail": "COMMITMENT_MISMATCH"
+  },
+  "limits": [
+    "The commitment and the nonce in this vector are from our own mainnet payment of 18 October 2026, so both are real values, not placeholders.",
+    "A verifier can also fail this on AUTHORIZATION_MISMATCH depending on which pair it compares first; either refusal is correct, reporting LINKED is not."
+  ]
+}

package/vectors/acceptance-binding/real-record-with-producer-key.json

@@ -0,0 +1,66 @@
+{
+  "schema_version": "3.0.0",
+  "verifies": "receipt-to-acceptance",
+  "requires_chain_read": false,
+  "provenance": [
+    "trilatic.acceptance-receipt/1.2, live record fetched from https://api.babyblueviper.com/work-acceptance/record/4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d on 18 October 2026",
+    "the two binding keys were specified by babyblueviper1 in erc-8004/erc-8004-contracts#99 on 18 October 2026",
+    "the record is issued by invinoveritas, not by us; it is copied here as test material"
+  ],
+  "id": "acceptance-binding-real-record-with-producer-key",
+  "encodes": "The positive control, and at the same time the exact one-field diff that makes the record auditable.",
+  "description": "Byte-identical to real-record-as-issued except that parties.producer.key_id is set to a distinct key. Now the checker and the producer are both named in the same namespace and differ, so a third party can verify the independence claim instead of accepting it. This must link. Without this vector the set would only contain refusals, which proves nothing about the harness.",
+  "input": {
+    "doc": {
+      "record": {
+        "receipt": {
+          "schema": "trilatic.acceptance-receipt/1.2",
+          "receipt_id": "INV-WA-aa4b8bc740bc2524",
+          "issuer": "invinoveritas",
+          "issued_utc": "2026-10-18T00:52:09Z",
+          "criteria": {
+            "id": "invinoveritas-p1-selftest",
+            "sha256": "d74ad7d7492908f1146b233e89db6ca205065c67f02d33758ff0aa9f8b9e02fc",
+            "committed_at": "2026-10-18T00:52:03Z"
+          },
+          "files": {
+            "remediated": {
+              "name": "refund-policy.txt",
+              "bytes": 121,
+              "sha256": "9c27eee03d50f4ff00fb60a1551a03d7311dbed257b7b943b3ff5d13eb30c083"
+            }
+          },
+          "parties": {
+            "checker": {
+              "name": "invinoveritas",
+              "key_id": "invinoveritas-checker-a4cecab2"
+            },
+            "producer": {
+              "name": "Example Vendor (self-test)",
+              "key_id": "example-vendor-producer-7f31aa02"
+            }
+          },
+          "independence": "independent",
+          "verdict": "pass"
+        }
+      },
+      "bindings_sidecar": {
+        "version": "invinoveritas.work-acceptance-bindings/v0",
+        "receipt_sha256": "4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d",
+        "criteria_id": "d74ad7d7492908f1146b233e89db6ca205065c67f02d33758ff0aa9f8b9e02fc",
+        "bindings": {}
+      }
+    },
+    "receiptSha256": "4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d",
+    "deliverableSha256": "9c27eee03d50f4ff00fb60a1551a03d7311dbed257b7b943b3ff5d13eb30c083"
+  },
+  "expected": {
+    "valid": true,
+    "reason_code": "LINKED",
+    "independence": "VERIFIEERBAAR_ONAFHANKELIJK"
+  },
+  "limits": [
+    "The signature on the record is not checked here, and neither are its criteria. That is the issuing checker's own verifier.",
+    "A LINKED verdict says the two artifacts are about the same thing, not that the acceptance record itself is sound."
+  ]
+}

package/vectors/acceptance-binding/real-record-x402-keys-match.json

@@ -0,0 +1,76 @@
+{
+  "schema_version": "3.0.0",
+  "verifies": "receipt-to-acceptance",
+  "requires_chain_read": false,
+  "provenance": [
+    "trilatic.acceptance-receipt/1.2, live record fetched from https://api.babyblueviper.com/work-acceptance/record/4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d on 18 October 2026",
+    "the two binding keys were specified by babyblueviper1 in erc-8004/erc-8004-contracts#99 on 18 October 2026",
+    "the record is issued by invinoveritas, not by us; it is copied here as test material"
+  ],
+  "id": "acceptance-binding-real-record-x402-keys-match",
+  "encodes": "Both payment keys present and each compared against its own counterpart. The positive control for the two-key split.",
+  "description": "The sidecar carries the commitment in the commitment key and the nonce in the nonce key, both matching the receipt. This must link, and a verifier should report which pairs it actually compared, so that a reader can tell a full comparison from a record that simply carried neither key.",
+  "input": {
+    "doc": {
+      "record": {
+        "receipt": {
+          "schema": "trilatic.acceptance-receipt/1.2",
+          "receipt_id": "INV-WA-aa4b8bc740bc2524",
+          "issuer": "invinoveritas",
+          "issued_utc": "2026-10-18T00:52:09Z",
+          "criteria": {
+            "id": "invinoveritas-p1-selftest",
+            "sha256": "d74ad7d7492908f1146b233e89db6ca205065c67f02d33758ff0aa9f8b9e02fc",
+            "committed_at": "2026-10-18T00:52:03Z"
+          },
+          "files": {
+            "remediated": {
+              "name": "refund-policy.txt",
+              "bytes": 121,
+              "sha256": "9c27eee03d50f4ff00fb60a1551a03d7311dbed257b7b943b3ff5d13eb30c083"
+            }
+          },
+          "parties": {
+            "checker": {
+              "name": "invinoveritas",
+              "key_id": "invinoveritas-checker-a4cecab2"
+            },
+            "producer": {
+              "name": "Example Vendor (self-test)",
+              "key_id": "example-vendor-producer-7f31aa02"
+            }
+          },
+          "independence": "independent",
+          "verdict": "pass"
+        }
+      },
+      "bindings_sidecar": {
+        "version": "invinoveritas.work-acceptance-bindings/v0",
+        "receipt_sha256": "4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d",
+        "criteria_id": "d74ad7d7492908f1146b233e89db6ca205065c67f02d33758ff0aa9f8b9e02fc",
+        "bindings": {
+          "x402_receipt_commitment": "0xe04421456465df1012f416b72aece3401f9e3d5be5bd78280324a031efe1d40f",
+          "x402_authorization_nonce": "0x43457c8e57b7c4ff92d716350c61c88c8f3b644d09d7c813d5a7ee6450a843da"
+        }
+      }
+    },
+    "receipt": {
+      "format": "eip712",
+      "authorizationNonce": "0x43457c8e57b7c4ff92d716350c61c88c8f3b644d09d7c813d5a7ee6450a843da",
+      "authorizationCommitment": "0xe04421456465df1012f416b72aece3401f9e3d5be5bd78280324a031efe1d40f"
+    },
+    "receiptSha256": "4c7273afcdb5333586b0a41c4238a968f3dedc23f66f71c5a1928ff3d279ab3d",
+    "deliverableSha256": "9c27eee03d50f4ff00fb60a1551a03d7311dbed257b7b943b3ff5d13eb30c083"
+  },
+  "expected": {
+    "valid": true,
+    "reason_code": "LINKED",
+    "compared": [
+      "COMMITMENT",
+      "AUTHORIZATION"
+    ]
+  },
+  "limits": [
+    "Linking the payment to the acceptance record does not prove the payment settled. That is the receipt-to-settlement question and it needs a chain read."
+  ]
+}