Skip to content

Contract

Version
v1 · 2026-08-24 · History
Prime #
744
Origin domain
Law & Governance
Subdomain
contract law → Law & Governance

Core Idea

A contract is an explicit, multi-party bundle of obligations, permissions, and consequences that binds the parties under an enforcement regime they have accepted as authoritative. What distinguishes it from a mere promise is a breach criterion and a remedy attached to an authority able and willing to adjudicate.

How would you explain it like I'm…

Promise With A Referee

A pinky-promise is just "I'll try." A contract is a promise where you also agree ahead of time who's the boss that can punish you if you break it, and exactly what counts as breaking it. So it's a promise with rules and a referee everyone already agreed to.

The Deal With Consequences

A contract is an explicit, agreed-upon deal between two or more sides that spells out what each side must do, may do, and must not do, what each side gets, what counts as breaking the deal, and what happens if someone breaks it. The special move is bundling all those pieces into one agreement that everybody has accepted in advance, so instead of a fuzzy cloud of expectations you have one clear thing to point at. What separates it from a regular promise is that there's a breach rule and a punishment backed by an authority, a referee, who can actually judge and enforce. Without that enforcer who can act, it's just a statement of intent, not a contract.

Binding Agreement With Enforcement

A contract is an explicit, multi-party specification of obligations, permissions, and consequences that binds the parties under an enforcement regime they have accepted as authoritative. Its real content is not the promise itself but the bundling of four things behind one agreement everyone committed to in advance: what each party must, may, and may not do; what each party is owed; what counts as a breach; and what enforcement follows from breach. The defining move gathers these into one artifact whose authority all parties accept, replacing a diffuse web of mutual expectation with a single binding reference. This is what separates a contract from a mere promise: the presence of a breach criterion and a remedy attached to an enforcement regime. Without an authority able and willing to adjudicate and apply consequences, the document is just an expression of intent rather than a contract, which is why the obligation structure and the appeal to an enforcer are load-bearing parts of the concept, not decoration.

 

A contract is an explicit, multi-party specification of obligations, permissions, and consequences that binds the parties under an enforcement regime they have accepted as authoritative. Its structural content is not the promise itself but the bundling of four things behind a single agreement all parties have committed to in advance: what each party must, may, and may not do; what each party is owed; what counts as a breach; and what enforcement follows from breach. The defining move is gathering these elements into one artifact whose authority every party has accepted, so the diffuse web of mutual expectation is replaced by a single binding reference. A contract is therefore distinguished from a mere promise by the presence of a breach criterion and a remedy attached to an enforcement regime: without an authority able and willing to adjudicate and apply consequences, the document is an expression of intent rather than a contract. The structural variables, parties with the capacity to bind themselves, an obligation set, performance conditions distinguishing fulfilled from breached, a remedy structure, an enforcement regime, a completeness trade-off, and an acceptance record, are abstract enough to recur across substrates, but the pattern is deeply framed by its legal and institutional origin and carries a normative obligation structure with it wherever it goes. The notion of obligation, the evaluative weight of breach, and the appeal to an authoritative enforcer are load-bearing, not incidental, which keeps it anchored in the human-practice cluster even as it extends to software interfaces (where the runtime or compiler is the enforcement regime) and to algorithmic settings (where executable code on a shared ledger is the enforcement substrate).

Broad Use

  • Law and economics: sales, employment, lease, and treaty instruments specify performance, consideration, and remedy under a judicial regime.
  • Software interfaces: API contracts and design-by-contract name the obligations of caller and callee, with the runtime or compiler as enforcer.
  • Diplomacy: treaties specify obligations among states, enforced via mutual sanction, international courts, or self-help.
  • Organizational governance: service-level agreements and charters bind units, with an HR or audit function as the enforcement regime.
  • Ledger settings: smart contracts encode the obligation-and-consequence structure as executable code on a blockchain.

Clarity

Forces the unstated to become stated — what each party must do, what counts as having done it, and what happens if not — and makes the enforcement regime a separate, explicit question, since a clause means only what that regime can adjudicate.

Manages Complexity

Collapses a graph of pairwise, partly-tacit expectations into a single artifact every party and any future arbiter can consult, dropping the coordination cost from maintaining \(n\) private models to maintaining one shared specification.

Abstract Reasoning

Supports completeness-versus-incompleteness reasoning (which contingencies are worth specifying), enforcement-attaches-to-specification (the regime's reach bounds operative content), detectability (an undetectable breach is inert), and remedy-design (deterrence lives in the consequence, not the wording).

Knowledge Transfer

  • Law → API design: "name the enforcement regime first" applies to a treaty without a binding court and an API contract without a runtime that enforces it.
  • SLAs → treaties: "make breach detectable" is the same discipline behind a measurable uptime threshold and a treaty verification mechanism.
  • Contract law → protocol design: "engineer the remedy, not just the obligation" carries to a software contract's panic and a treaty's sanction clauses.

Example

A hospital-vendor SLA bundles guaranteed uptime and response times, makes breach detectable via a defined monitoring methodology, attaches liquidated damages where deterrence lives, and names the courts as the enforcement regime.

Relationships to Other Abstractions

Local relationship map for ContractParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.ContractPRIMEPrime abstraction: Interface — presupposesInterfacePRIMEDomain-specific abstraction: Cover (law) — is part ofCover (law)DOMAINDomain-specific abstraction: Impracticability — is part ofImpracticabilityDOMAINDomain-specific abstraction: Accord and satisfaction — is a kind ofAccord andsatisfactionDOMAINDomain-specific abstraction: Break/Fix — is a kind ofBreak/FixDOMAINDomain-specific abstraction: Economic partnership agreement — is a kind ofEconomic partne…DOMAINDomain-specific abstraction: Exclusion clause — is a kind ofExclusion clauseDOMAINDomain-specific abstraction: Fundamental Breach — is a kind ofFundamentalBreachDOMAINDomain-specific abstraction: Non-compete clause — is a kind ofNon-competeclauseDOMAINDomain-specific abstraction: Partial agreement — is a kind ofPartialagreementDOMAINDomain-specific abstraction: Service-level agreement — is a kind ofService-levelagreementDOMAINDomain-specific abstraction: Side letter (contract law) — is a kind ofSide letter(contract law)DOMAINDomain-specific abstraction: Tenant-right — is a kind ofTenant-rightDOMAIN+6 more

Current abstraction Contract Prime

Parents (1) — more general patterns this builds on

  • Contract presupposes Interface Prime

    'An interface that no authority enforces and whose violation carries no remedy is a contract's structural SKELETON without its binding force.' A contract = interface and normative obligation and breach criterion and remedy and accepted enforcement regime.

Children (18) — more specific cases that build on this

  • Accord and satisfaction Domain-specific is a kind of Contract

    The proposed strict upward parent is prime:contract.

  • Break/Fix Domain-specific is a kind of Contract

    Contract is the minimal prospective parent.

  • Economic partnership agreement Domain-specific is a kind of Contract

    The proposed strict upward parent is prime:contract.

  • Exclusion clause Domain-specific is a kind of Contract

    The proposed strict upward parent is prime:contract.

  • Fundamental Breach Domain-specific is a kind of Contract

    Contract is the proposed immediate parent.

Hierarchy path (1) — routes to 1 parentless root

Not to Be Confused With

  • Contract is not Interface because an interface specifies the shape of an interaction, whereas a contract adds normative obligation, a breach criterion, a remedy, and an accepted enforcement regime.
  • Contract is not Incentive Compatibility because incentive compatibility makes desired behavior each party's self-interested choice, whereas a contract imposes obligations backed by external remedy even when compliance is against self-interest.
  • Contract is not Informal Enforcement because informal enforcement relies on reputation and social sanction with no formal adjudicator, whereas a contract names an accepted enforcement regime able to adjudicate breach.