Reference
Standards & references
The mechanical contract invents one layer and borrows every other. This page lists the external standards it binds to, and the prior art it stands on - each link points at the source, not a summary.
Standards bindingsFull text: §10 →
Nothing invented that already exists.
The 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. A supplier's Peppol stack already speaks every payload below.
| Layer | Standard | |
|---|---|---|
| Invoice payload | EN 16931 / Peppol BIS Billing 3 ↗ | invoice.submit port type; rules cite BT-terms (BT-146 price, BT-13 reference) |
| Order chain | Peppol post-award ↗ | Order, Order Agreement, Despatch Advice - allocation.request / material.delivery ports |
| Payment status | ISO 20022 (pain.002 / camt) ↗ | payment.confirm port |
| Transport | Peppol eDelivery (AS4) ↗ | default profile, not a dependency - already carries signed non-repudiation of receipt |
| Application receipt | Peppol MLR ↗ | our receipt rides the same pattern one level up: judged against the contract |
| Signatures | eIDAS (XAdES) / BankID / EUDI ↗ | genesis signing, per-event signing, receipt seals |
| Timestamps | RFC 3161 ↗ | receipt timestamping |
| Idempotency | IETF Idempotency-Key ↗ | submission-id semantics, verbatim (the Stripe/PayPal pattern) |
| Legal form | Ricardian tuple ↗ | {prose, parameters, spec} under one hash; prose governs on conflict |
§11 · Prior art
The field, and the gap it leaves.
Forty years of standardizing every document around the contract - EDIFACT INVOIC in 1987, receipts at the transport level in the 90s, three generations of Swedish invoice formats - and the agreement itself was never once made machine-readable. Here is what comes closest, and what each one misses.
Contract as a boring deterministic machine
Flood & Goodenough, "Contract as Automaton" ↗Gap Academic, one loan agreement, no ports/payloads/receipts, never productized
A contract a computer can evaluate compliance against
Surden, "Computable Contracts" ↗Gap The concept and vocabulary, not a language or a system
Typed entry points with authorization
Daml choices on templates ↗Gap No standards-native payloads, no procurement semantics, developer-facing
Minimal starved rule language, statically analyzable
Marlowe ↗Gap Finance/blockchain habitat, no document ports
Prose + parameters + executable spec under one hash
Ricardian contract (Grigg 1996) ↗Gap The legal form exists; nobody bound it to EN 16931 ports
Idempotency of money-bearing submissions
Stripe's idempotency design ↗Gap API-infrastructure practice; never specified as a contract-document property
Accumulators over finite control (pools, balances)
Petri nets / vector addition systems ↗Gap Never applied to commercial agreements; the DFA is the memoryless special case