Contract¶

Version: v2 · 2026-10-17 · History
Prime #: 744
Domain group: Professional & Organizational Practice
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¶

Current abstraction Contract Prime

Parents (1) — outgoing typed relations

Contract presupposes, conditional Interface Prime

When a distinct modular interface exists, a contract governing duties across it presupposes that interface; other enforceable contracts need not contain such a surface.

Condition / exception A distinct bounded interface exists between the parties or systems, with a stable exposed protocol, some hidden implementation, and independent internal change within that protocol; the contract governs duties and remedies concerning that interface.

Children (22) — abstractions linked here by typed relations

Accord and satisfaction Domain-specific is a kind of Contract

It remains its own entry because its identity is fixed by the governing jurisdiction, original obligation and dispute, offer and acceptance, substituted consideration, accord terms, satisfaction event, breach consequences and discharge effect.
Break/Fix Domain-specific is a kind of Contract

Contract is the broader abstraction this entry instantiates.
Contingent Contract Domain-specific is a kind of Contract

A contingent contract retains binding parties, obligations, breach and remedy structure while making particular duties depend on a future trigger.
Cost-plus contract Domain-specific is a kind of Contract

A cost-plus contract is a contract whose payment rule reimburses allowed costs plus an additional fee.
Employment Contract Domain-specific is a kind of Contract

Employment Contract is a strict kind of Contract: its frozen identity entails the parent's defining structure while adding domain-specific restrictions.

▸ Show 17 more

Exclusion clause Domain-specific is a kind of Contract
It remains its own entry because its identity is fixed by the jurisdiction and contract type, parties and bargaining context, exact term and notice, liability or remedy targeted, breach or event, incorporation route, construction rule, statutory or common-law control, severability and legal consequence.
Fundamental Breach Domain-specific is a kind of Contract
**Contract** is the broader abstraction this entry instantiates.
Non-compete clause Domain-specific is a kind of Contract
It remains its own entry because its identity is fixed by the jurisdiction and effective date, parties and relationship, restricted activity, duration and geography, consideration, protected interest, worker or transaction exemptions, severability, remedy and current enforceability authority.
Partial agreement Domain-specific is a kind of Contract
It remains its own entry because its identity is fixed by the Council of Europe framework and legal resolution, participating and nonparticipating member states, subject activity, accession and withdrawal rules, budget and cost allocation, governing body and voting, secretariat support, ordinary partial enlarged or enlarged-partial type and participation by nonmember states.
Rent-to-own Domain-specific is a kind of Contract
Rent-to-own is a contract combining temporary possession, periodic payment, and a conditional path to ownership.
Service-level agreement Domain-specific is a kind of Contract
An SLA literally binds parties to obligations, breach criteria, and responses under an accepted regime; service indicators and recurring operational governance supply its domain-specific residual.
Side letter (contract law) Domain-specific is a kind of Contract
**Contract** (`prime:contract`).
Underwriting Contract Domain-specific is a kind of Contract
Underwriting Contract is a strict kind of Contract: its frozen identity entails the parent's defining structure while adding domain-specific restrictions.
Void contract Domain-specific is a kind of Contract
**Contract** is the strict parent because voidness classifies a purported contract by failure of the binding conditions that make contractual obligations enforceable in an accepted regime.
Voidable contract Domain-specific is a kind of Contract
A voidable contract retains the constitutive agreement and obligation structure of a contract while adding a unilateral avoidance power.
Will contract Domain-specific is a kind of Contract
Will contract is a domain-specific kind of Contract: A will contract is an enforceable agreement in which a promisor undertakes to make, not revoke, or dispose of property by will in exchange for present consideration or performance.
Consistency Model Prime is a kind of Contract
A consistency model is explicitly an explicit contract specifying legal observations of shared state, fitting the general obligations-and-permissions bundle structure of contract.
Incomplete Contract Prime is a kind of Contract
An incomplete contract is, structurally, a contract (a rule-set fixing outcomes for some contingencies) plus the distinctive move of an acknowledged gap and designated gap-handler and governance.
Cover (law) Domain-specific includes Contract
the original agreement supplies the normative baseline and breach relation.
Design–Build Project Delivery Domain-specific includes Contract
One enforceable owner-facing contract bundles a design–builder's design and construction duties as an internal constituent of this delivery arrangement.
Impracticability Domain-specific includes Contract
**`contract`:** the doctrine modifies enforcement of a contractual duty.
Take-or-pay commitment Domain-specific presupposes Contract
The enforceable payment-if-unused term requires a binding agreement with covered supplier and payer duties, but the term is not the whole contract.

Hierarchy path (1) — routes to 1 parentless root

Contract → presupposes, conditional Interface → is a decomposition of Boundary

Not to Be Confused With¶

Contract is not Interface: an interface specifies a bounded exchange protocol and may hide internals; a contract binds parties to obligations with breach criteria, remedies and an accepted enforcement regime. An API contract can govern an interface, but neither category universally contains the other.
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.