Prior art

The document lineage: forty years of e-documents, zero e-agreements

The question “EDI, EDIFACT - super old formats - what exists today?” has a clean answer, and it IS the thesis:

1979   ANSI X12 (US)                 electronic purchase orders + invoices (810)
1987   UN/EDIFACT (UNECE; ISO 9735   INVOIC, ORDERS, DESADV... - the 6-letter
       from 1988)                    messages still running global trade today
1990s  EDIFACT CONTRL / APERAK       syntax + application acknowledgements -
                                     RECEIPTS existed in the 90s (transport level)
2004   Svefaktura (SFTI, UBL-based)  Sweden's first national e-invoice format;
                                     + SFTI Fulltextfaktura (EDIFACT D96A profile)
2005   Denmark NemHandel/OIOUBL      world-first mandatory B2G e-invoicing
2014   EU Directive 2014/55/EU  ──►  2017 EN 16931: THE European e-invoice
                                     standard (semantic model; UBL/CII syntaxes)
2019   Sweden: lag 2018:1277         Peppol BIS Billing 3 (an EN 16931 CIUS)
       (from 1 April 2019)           mandatory for ALL public-sector purchases
2025   Svefaktura formally dead      B2G legacy formats discontinued (July 2025)
2030s  ViDA                          e-invoicing forced EU-wide, B2B too

So: yes, Swedish “e-faktura” is a standard - a stack of them: EN 16931 is the European semantic norm, Peppol BIS Billing 3 the operative profile, Peppol eDelivery the network, mandated by Swedish law since April 2019. And BEAst is not the European invoicing standard - it is the Swedish construction industry’s e-business standards body (sector profiles for despatch, project logistics, invoicing on top of the same stack); the European invoicing standard is EN 16931.

The lesson cuts deep: the invoice has been electronic and standardized for nearly forty years (EDIFACT INVOIC 1987), acknowledgements/receipts existed at the transport level in the 90s (CONTRL/APERAK - direct ancestors of our judgment-level receipts), Sweden has iterated through three generations of invoice formats - and in all that time the AGREEMENT the invoice bills under was never once made machine-readable. Even the old paper “EDI interchange agreements” that governed 90s electronic trade were prose contracts about machines that no machine could read. Forty years of standardizing every document AROUND the contract is the strongest possible evidence that the mechanical contract is the missing piece, not a crowded one - the document-standards bodies standardize documents; the agreement is a domain-model problem they structurally never touch (the same gap survived 20 years of Danish state digitization).

Mapping the mechanical contract’s specific claims

The six-tradition deep-dive covers the field; here is what maps to the mechanical contract’s specific claims, and what does not:

Mechanical-contract claim	Closest prior art	Gap
Contract as a boring deterministic machine	Flood & Goodenough, “Contract as Automaton” (OFR 2015 / AI&Law 2022): a loan agreement as a literal DFA; computation theory used to check the contract is coherent and complete	Academic, one loan agreement, no ports/payloads/receipts, never productized
“A contract a computer can evaluate compliance against”	Surden, “Computable Contracts” (2012) + Stanford Computable Contracts Initiative (2020)	The concept and the vocabulary, not a language or a system
Typed entry points with authorization (“who may submit what”)	Daml choices on templates (controller + choice = our port + from); CSL’s party-indexed obligations	No standards-native payloads, no procurement semantics, developer-facing
Minimal starved rule language, statically analyzable	Marlowe (total, exhaustively analyzable, contracts-as-data)	Finance/blockchain habitat, no document ports
Prose + parameters + executable spec under one hash	Ricardian contract (Grigg 1996)	The legal form exists; nobody bound it to EN 16931 ports
Proof of execution as signed receipts	Peppol MLR + AS4 non-repudiation receipts, ETSI evidence, RFC 3161	Exists at transport/syntax level (“message arrived, schema valid”); NOBODY issues receipts at the contract-judgment level (“this price is wrong per clause X”)
Idempotency of money-bearing submissions	IETF Idempotency-Key draft, Stripe’s design	API-infrastructure practice; never specified as a contract-document property
Port manifest as capability signature	(nearest: WSDL/AsyncAPI service manifests; Daml template choices)	Genuinely novel as a CONTRACT construct - “what may flow in/out of this agreement” as a declared, signable, diffable surface
Accumulators over finite control (pools, balances)	Petri nets / vector addition systems (Petri 1962) - the math of parallel draws on shared pools, with decidability results; counter machines (Minsky) as the warning to stay restricted	Never applied to commercial agreements; Flood & Goodenough’s DFA is the memoryless special case of our machine class
Cadence / rate guards as contract terms	token bucket (networking QoS), timed automata (Alur & Dill), IETF httpapi RateLimit headers draft (same WG as Idempotency-Key)	API-infrastructure practice everywhere; never a signable, litigable contract clause
Approval legs (straight-through vs in-the-loop)	STP in payments; kommunal attestordning + four-eyes; Daml authorization; workflow human-task patterns (BPMN user tasks, Step Functions task tokens)	Approval lives in ERP/workflow config, never as signed contract terms; “agent approver = key + hashed policy” is new
Escalation as throw/catch/finally	BPMN 2.0 escalation + error + compensation events; multi-tiered dispute-resolution clauses (eskaleringstrappa, NEC4 ladder); saga-pattern compensation; survival clauses = finally in prose	Process engines have the semantics, contracts have the prose; nobody gave the eskaleringstrappa a runtime
Governed reference artifacts (tables/variables)	incorporation by reference (AB 04, ISDA Definitions); SFTI/Peppol catalogue price-list updates; rate-fixings governance; content addressing (git/IPFS)	Catalogues update ERPs, not agreements - nobody machine-checks an update’s LEGALITY against the consuming contract (cadence/window/bounds/approval)
Publisher-signed data > transport pinning	eIDAS seals (XAdES/JAdES), signed-exchanges thinking; certificate pinning as the weaker fallback	Public-sector publishers (SCB!) mostly don’t seal their data files; ingest attestation bridges until they do
One core + jurisdiction profiles	EN 16931 + CIUS (Peppol BIS as the living example); EDIFACT’s global-grammar/national-subset lesson	Proven for the invoice DOCUMENT; never applied to the agreement. Profiles must constrain, never extend computation

Net: every load-bearing part has proven prior art - which is exactly what we want, this is a composition, not an invention. The three pieces nobody has: (1) the port manifest as a first-class contract surface, (2) receipts at the judgment level rather than the transport level, (3) all of it bound to the procurement standards stack (EN 16931 BT-terms, Peppol, SFTI, eIDAS) instead of finance or blockchain. Plus the brand: everyone else promises smart; we promise boring.