Specification · Section 10 of 13
Standards bindings
A layer-by-layer table of the existing standards the mechanical contract consumes as-is for payloads, transport, signatures, timestamps, and idempotency, spending its novelty budget only on the judgment layer.
| Layer | Standard | Role in the mechanical contract |
|---|---|---|
| Invoice payload | EN 16931 / Peppol BIS Billing 3 | invoice.submit port type; rules cite BT-terms (BT-146 price, BT-13 reference) |
| Order chain payloads | Peppol post-award (Order, Order Agreement, Despatch Advice), SFTI profiles | allocation.request, future material.delivery ports |
| Payment status | ISO 20022 (pain.002 / camt) | payment.confirm port |
| Transport | Peppol eDelivery (AS4) - as the mk-se-public profile DEFAULT, not a dependency (§7.4: the contract is transport-agnostic) | port ingress/egress; AS4 already provides signed non-repudiation of receipt at transport level |
| Application receipt | Peppol MLR-shaped response | our receipt rides the same pattern one level up: not “message received/valid” but “submission judged against the contract” |
| Signatures | eIDAS qualified seals/signatures (XAdES), BankID/Freja OrgID today, EUDI wallet + vLEI from 2026-27 | genesis signing, per-event signing, receipt seals |
| Timestamps | RFC 3161 | receipt timestamping |
| Idempotency | IETF Idempotency-Key (the Stripe/PayPal pattern, being standardized) | submission-id semantics, verbatim |
| Legal form | Ricardian tuple {prose, parameters, spec} under one hash | the signed artifact; prose governs on conflict |
The mechanical contract’s entire novelty budget is spent on ONE layer: the judgment layer - executable contract terms with typed ports. Every other layer is an existing standard consumed as-is. This is also the interop story: a supplier’s existing Peppol stack already speaks every payload format; adopting pre-validation is a new endpoint, not a new stack.