Specification · v0 working draft
The Mechanical Contract
A signed contract a dumb machine can run. 13 sections: the port model, the formal shape, approval and escalation, governed artifacts, profiles, composition, the data model, and the standards it binds to. Normative language is intentionally plain; nothing here requires a blockchain, a runtime AI, or trust in the host.
- §1What a mechanical contract isDefines the mechanical contract as a signed, deterministic document a dumb machine can run, and lays out its five properties, ports, and anatomy.
- §2The language, by worked exampleWalks the pseudo-language through a full IT-consulting ramavtal, then covers what a receipt looks like, the envelope/body grammar, and the three binding tiers of contract language.
- §3The formal shape: finite control, accumulators, cadenceDefines the mechanical contract's computational model - finite control plus accumulators, cadence as a rate primitive, scheduled money, an optimistic log-first execution model, executor confirmations, and fork/join flow.
- §4Approval and escalationCovers how approval (the attest), escalation (throw/catch/finally), and fault handling are declared and enforced inside the contract rather than left to the surrounding systems.
- §5Tables, variables, and referenced artifactsSpecifies how contracts reference external variables and lookup tables as hash-addressed, versioned artifacts that carry their own governed update rules and trust anchors.
- §6Universal by design: one core, many profilesDescribes a jurisdiction-neutral semantic core constrained by CIUS-style profiles, the template/instance split for high-volume contracts, and versioning through signed declarative transforms.
- §7Contracts calling contractsCovers inter-contract topology through ports, trust via pinned identity and verified receipts, compensational (saga) execution instead of distributed ACID, the rejection of governing/middleware contracts, transport-agnostic messaging, call-outs to services, and an import manifest for external functions.
- §8The data model: declared storage, checked flow, owned valuesHow a contract declares what it can store, validates everything that enters, and names an ownership verb for every flow, built from a closed set of domain types and four pool flavors.
- §9Why if + which is enoughThe rule language is deliberately starved to conditions, exhaustive pattern matches, bounded arithmetic, and effects, which buys decidability, readability, and immunity to whole classes of smart-contract exploits.
- §10Standards bindingsA layer-by-layer table of the existing standards the mechanical contract consumes as-is for payloads, transport, signatures, timestamps, and idempotency, spending its novelty budget only on the judgment layer.
- §11Prior artForty years of standardized e-documents never made the agreement itself machine-readable; this section maps every load-bearing claim of the mechanical contract to its closest prior art and names the three pieces that are genuinely new.
- §12Sekretess and privacy: the open problemAn honest map of the confidentiality problem for structured contracts under Swedish OSL, the selective-disclosure prior art that could solve each layer, and the v1 access-control posture with scoped receipts.
- §13The standard and the products built on itThe direction of dependency: the standard predates and governs any product built on it, a product is only a consumer of it, and the naming and reference-implementation concerns are stated as separate matters.