What a mechanical contract is

A mechanical contract is a signed document that a dumb machine can run.

Not smart. Mechanical - like a gearbox: you can open the casing, see every gear, turn the crank by hand, and get the same result every time. It has no cleverness anywhere: no AI at runtime, no blockchain, no Turing-complete anything. Its entire vocabulary is conditions (if, which) over declared state (pools, rates, dates), guarding typed openings (ports) through which standard e-documents pass. Everything it does produces a signed receipt.

The name is the positioning. “Smart contract” promises magic and delivers Solidity exploits; “mechanical contract” promises a gearbox and delivers one. For a kommunjurist, boring is the selling point: a mechanism she can inspect, test before signing, and replay in front of a judge.

Naming caveat, flagged honestly: in construction English a “mechanical contractor” is an HVAC/plumbing firm, so “mechanical contract” has ambient noise in that industry. As a concept term in legal/procurement tech it is unclaimed (as of mid-2026) - closest is Flood & Goodenough’s academic “contract as automaton”. Swedish “mekaniskt avtal” is completely free.

The five properties

1. Deterministic by construction, and trivially provably so. The language cannot express nondeterminism (no clock, no I/O, no randomness, no floats, no unbounded loops, no user recursion). “Is this contract deterministic?” is answered by the grammar - a linter check in milliseconds, not a program analysis. This is the answer to “simple to find if it’s deterministic”: you don’t find out, you make it impossible to be otherwise.
2. Evaluatable. Any state question (“hours left in the senior pool?”, “what may this invoice charge for March?”) is a pure function of (contract, event log). Pre-signature, the same evaluator runs hypothetical futures - the test-drive before signing.
3. Ports: typed entry and exit points. The contract declares up front which document types may flow in and out, who may submit them, and in what standard format. The port list is the contract’s capability manifest: “does this contract allow invoicing? renting? people? material?” is answered by reading the manifest, without reading a single rule. An absent port is a prohibition.
4. Standards-native payloads. Nothing enters a port as free-form data. Invoices are Peppol BIS Billing 3 (EN 16931), orders/call-offs are Peppol post-award documents, payment confirmations are ISO 20022 status messages. Rules reference standard business terms by number (EN 16931’s BT-146 “item net price”, BT-13 “purchase order reference”) - the mechanical contract adds no new document formats, it adds judgment over the formats that already won.
5. Proof of execution + idempotency. Every submission - accepted or rejected - yields a signed, hash-chained receipt carrying the rule trace. Every submission carries a client submission-id (idempotency key): resubmit the same thing twice, get the same receipt back, state moves exactly once. The receipt chain IS the audit trail; replaying it reproduces the state bit-for-bit.

Anatomy

                        ┌──────────────────────────────────────────┐
      IN-PORTS          │          MECHANICAL CONTRACT             │        OUT-PORTS
                        │                                          │
  allocation.request ──►│  ┌────────┐   ┌───────────────────────┐  │──► receipt.emit (always)
  timesheet.submit   ──►│  │ GATES  │──►│ RULES (if / which)    │  │──► notice.emit
  invoice.submit     ──►│  │ sig ok?│   │ over DECLARED STATE   │  │──► payment.instruct
  payment.confirm    ──►│  │ idem?  │   │ pools · rates · dates │  │    (CLOSED in referee mode)
  notice.send        ──►│  │ schema?│   └──────────┬────────────┘  │
                        │  └────────┘              ▼               │
  (no renting port   ──X│              STATE + HASH-CHAINED LOG    │
   = renting not        │              (append-only, replayable)   │
   allowed. Ever.)      └──────────────────────────────────────────┘