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 runtime AI, exotic infrastructure, or trust in the host.
- §1 What a mechanical contract is Defines the mechanical contract as a signed, deterministic document a dumb machine can run, and lays out its six properties, ports, and anatomy.
- §2 The language, by worked example Walks 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.
- §3 The formal shape: finite control, accumulators, cadence Defines 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.
- §4 Approval and escalation Covers 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.
- §5 Tables, variables, and referenced artifacts Specifies how contracts reference external variables and lookup tables as hash-addressed, versioned artifacts that carry their own governed update rules and trust anchors.
- §6 Universal by design: one core, many profiles Describes a jurisdiction-neutral semantic core constrained by CIUS-style profiles, the template/instance split for high-volume contracts, and versioning through signed declarative transforms.
- §7 Contracts calling contracts Covers 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, an import manifest for external functions, and compile-time modules - the standard library of law/ statute mirrors and std/ vetted reusable modules, flattened with provenance.
- §8 The data model: declared storage, checked flow, owned values How 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.
- §9 Why if + which is enough The 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.
- §10 Standards bindings A 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.
- §11 Prior art Forty 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.
- §12 Sekretess and privacy: a committed pillar Confidentiality answers a question none of the other properties do - what may this contract reveal, and to whom. The committed v1 design: minimal disclosure by construction, a signed disclosure policy, scoped receipts, receipted reads, and detachable personal-data bodies, with the reconciliation against replay tested, not asserted.
- §13 The standard and the products built on it The 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.