Contract

Origin & evolution

The modern SaaS deal is rarely one document. It is a modular stack with a Master Services Agreement as the foundation, carrying the long-lived terms: liability, intellectual property, confidentiality, dispute resolution. Transaction-specific documents hang off it. A Statement of Work names the deliverables, timeline, and price for one engagement. A Data Processing Agreement, required under GDPR and similar regimes, governs how personal data is handled. A Service Level Agreement⏱️Service Level AgreementCustomer SuccessA service level agreement with customersView reference → sets the uptime and response commitments. A Non-Disclosure Agreement protects information shared before any deal is struck (CloudNuro, SaaS Agreement Terms).

This modular shape exists to front-load the hard negotiation. Settle liability and IP once in the MSA, and every later SOW becomes a short document about scope and money. The structure introduces its own hazard: when an SOW and the MSA conflict, which wins? The fix is an order-of-precedence clause, typically stating that MSA terms govern unless an SOW explicitly overrides a named section, so that a project document cannot quietly undo a core protection (Promise Legal, SaaS Agreements).

How it works in practice

A B2B SaaS vendor signs an MSA with an enterprise customer. Two terms in it shape the product for years. The liability cap limits the vendor's exposure to twelve months of fees, which the finance team relies on when pricing the deal. A data-residency commitment promises that customer data stays in the EU. Eighteen months later the product team wants to move analytics processing to a cheaper US region. The MSA blocks it for this account. The decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → is no longer purely technical; it is governed by a clause someone signed, and changing it means renegotiating with the customer. The contract has become a constraint🔒ConstraintStrategyA constraint entityView reference → on the roadmap, which is exactly why it belongs in the same map as the features it touches.

Contract vs. its neighbours

• Contract clause§Contract ClauseLegalA clause within a contractView reference →. The contract is the whole agreement; the clause is one provision inside it. The contract gives you the parties and the relationship; the specific commitment that constrains a feature, the liability cap or the SLA, lives in the clause. Modelling only the contract loses the detail that actually binds.
• Partnership. The partnership is the commercial relationship; the contract is the instrument that governs it. A partnership can exist informally for a while, but the contract is what makes its terms enforceable, which is why contract_governs_partnershipContractgovernsPartnershipcross-domain bridges the two.
• Subscription🔂SubscriptionSales & RevenueA recurring subscriptionView reference →. A subscription is the recurring commercial arrangement a customer is on; the contract is its legal backing. The subscription tells you the plan and the billing; the contract tells you the obligations and the remedies.

In the graph

In the Unified Product Graph the contract is the anchor of the legal domain. Three edges define it: contract_contains_contract_clauseContractcontainsContract Clausehierarchy breaks it into its binding provisions, legal_entity_bound_by_contractLegal Entitybound byContracthierarchy records which entity carries the obligation, and contract_governs_partnershipContractgovernsPartnershipcross-domain bridges into the business model💰Business ModelBusiness ModelThe business model canvas or definitionView reference →. The domain's standing warning is the contract with no clauses, because a contract described only at the top level hides exactly the commitments a product decision needs🫀NeedUserA user need, pain, desire, or constraintView reference → to check against.