Open Standard · Working Draft
mekaniskt·kontrakt

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 bindings Full 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
Order chain Peppol post-award
Payment status ISO 20022 (pain.002 / camt)
Transport Peppol eDelivery (AS4)
Application receipt Peppol MLR
Signatures eIDAS (XAdES) / BankID / EUDI
Timestamps RFC 3161
Idempotency IETF Idempotency-Key
Legal form Ricardian tuple

§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 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