Overview · Abstract
A signed contract a dumb machine can run.
Not smart. Mechanical - like a gearbox: open the casing, see every gear, turn the crank by hand, get the same result every time. Conditions over declared state, guarding typed ports, producing signed receipts.
No AI at runtime. No blockchain. No Turing-completeness. Anywhere.
- STATUS
- Open standard, working draft. Free to implement.
- CONCEPT
- Jonas Frost, 2023
- TERM
- mekaniskt kontrakt · the mechanical contract
- SEE ALSO
- The full specification,worked examples, andstandards & references.
What it is notFull text: §1 →
Not an AI contract
An agent is non-deterministic by construction - same inputs, different answers, failures you cannot replay. A contract cannot run on that. The machine only evaluates what was declared; judgment stays with the humans.
Not a blockchain
No chain, no consensus, no gas, no token. Evaluating a contract costs nothing and congests no network. Blockchain solves trust-between-strangers - a problem this design simply does not have.
No external cord
It reads only its own declared state and event log. Nothing off-box, no live third-party call, no foreign runtime. There is no jurisdictional cord to pull: no one can switch off your contract mid-run.
The five propertiesFull text: §1 →
Five properties, and the grammar enforces every one.
- 01
Deterministic by construction
deterministicThe language cannot express nondeterminism: no clock, no I/O, no randomness, no floats, no unbounded loops. "Is this deterministic?" is a grammar check in milliseconds - you do not find out, you make it impossible to be otherwise.
- 02
Evaluatable
evaluatableAny state question - hours left in the pool, what this invoice may charge for March - is a pure function of (contract, event log). Before signing, the same evaluator runs hypothetical futures. A test-drive.
- 03
Typed ports
portsThe contract declares up front which document types may flow in and out, who may submit them, in what format. The port list is the capability manifest. An absent port is a prohibition - renting is not allowed unless a renting port exists.
- 04
Standards-native payloads
standards-nativeNothing enters as free-form data. Invoices are Peppol BIS / EN 16931, payments are ISO 20022. Rules cite standard business terms by number. It invents no new formats - it adds judgment over the ones that already won.
- 05
Proof of execution + idempotency
receiptsEvery submission - accepted or rejected - yields a signed, hash-chained receipt carrying the rule trace. Resubmit the same thing twice, get the same receipt, state moves once. Replaying the chain reproduces state bit-for-bit.
AnatomyFull text: §1 →
Documents enter through declared ports. Nothing else gets in.
In-ports
- →allocation.request
- →timesheet.submit
- →invoice.submit
- →payment.confirm
- ✕renting.request
no port = prohibited. ever.
Sealed core
pools · rates · dates
Out-ports
- receipt.emit→
- notice.emit→
- payment.instruct→
every submission, accepted or rejected, emits a signed receipt.
The language
This is one.
A Swedish IT-consulting framework agreement. It declares its state, its ports, and its rules - and nothing it does not declare can happen. Read it top to bottom; that is the whole contract.
Illustrative. The grammar is forged against a real corpus of standard agreements, not invented at a desk.
mechanical-contract v0
id: mk-se-2027-000042
title: Ramavtal IT-konsulttjänster
prose: ramavtal-2027-0042.pdf sha256:9f2c44… # Ricardian binding
parties:
buyer: 212000-1355 "Lunds kommun"
supplier: 556677-8899 "Konsultbolaget AB"
sign: eIDAS-qualified-seal
# ── DECLARED STATE ──────────────────────────
state:
pool hours.senior capacity 3000 h
pool budget.total capacity 8_000_000 SEK # hard ceiling
# ── PORTS (the capability manifest) ──────────
ports:
in timesheet.submit from supplier as Peppol-order
in invoice.submit from supplier as EN16931
out receipt.emit always
# ── ONE RULE ─────────────────────────────────
on invoice.submit:
which line in invoice:
require line.hours <= hours.senior.remaining
charge line.net at rate.senior # BT-146
emit receipt { trace, submission-id, hash }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 |
Status & provenance
Independent prior art.
The mechanical contract concept was created by Jonas Frost in 2023, and formalized as this standard in 2026. It stands on its own: the concept predates and survives any single product built on it.
The standard is open and free to implement. A host may sell the venue - the running, the storage, the seals - but never hold your contract hostage.
Read next: the full specification · worked examples · standards & references