I'm a lawyer and have programmed very simple things in very simple programming languages, and I endorse both your Contracts 101 description, which is very easy to understand and also accurate, and your parallels with computer programming. Your focus on risk allocation is spot on. I promise to do something for you, you promise to pay me, and the other 50 pages are just risk allocation and rules on how to parse the risk allocation.
Re patches on top of patches: There is some truth here. For context, there are two reasons that contracts I work on end up looking like this. The first is that the patches are carve-outs for some very particular contingency the client is worried about, and because they're not lawyers, they don't understand the non-patchy things that address their concern, so they want something specific addressing their concern. The other side tends to agree because they, too, know that the patchy thing is superfluous. It's sort of like if you were a programmer who was really bad at math, and you wanted to print "hello world" if x was between 5 and 10 but it was EXTREMELY PERSONALLY IMPORTANT to you that "hello world" be printed where x=7, you would code
{if(5<x<10), PRINT "hello world"
if(x=7), PRINT "hello world"}
The second reason is cost. I could write a bespoke contract for every client's every need, but to save time==money, there are vast form books/online repositories for standard transactions, plus we ruthlessly plagiarize from each other--it really is the highest form of flattery. The patches are added to address the specific concerns or unique details of the particular deal. We then run a sanity check applying the patches to the rest of the agreement to make sure nothing weird happens.
Finally, I would characterize a "reasonableness" requirement as "we'll just ask a jury" rather than a "do what I mean" button. Because taking a case to trial is so flipping expensive, and putting in a reasonableness standard or "course of business" all but guarantees (due to common law) that you will have to go to trial if there's an unresolvable dispute, and juries are super unpredictable, you would almost never use "reasonableness" as a substitute for "do what I mean." You would keep hammering at a verbalization of "what I mean".
If the other side were insisting on a "reasonableness" standard for some action which we could define by reference to objective facts (like "200 widgets made out of ASTM A125-96 steel"), my mental model of them would update to "so likely to be planning to cheat my client that we should walk the deal".
The other use of "reasonable" you mention is more common--to give the party some freedom but not absolute discretion.
Thanks again for this excellent post. I feel hopeful when I see non-lawyers understanding law stuff, because it makes me feel hopeless for the future of the Rule of Law (TM) when some part of my job is so complex that no person without specialized training could hope to do it. The law should be for everyone.
This was a super-helpful comment, thank you!
I'm surprised about the jury part, for multiple reasons. I would have expected that judges handle most contract disputes without a jury (partly because I'd expect disagreements on law/interpretation more often than fact), and that the sort of parties who want to avoid trials would usually prefer to designate some other arbitrator ahead of time for most matters anyway. What am I missing here?
In most US jurisdictions, interpretation of a contract is a question of law (read: decided by the judge). However, some subparts of that inquiry are questions of fact (read: decided by the jury). By far the most common is to argue that some key term of the contract is ambiguous--that if we read the document as a whole, that key term has two mutually inconsistent meanings.
This opens the door to evidence about the parties' intent, which is a jury question. We lawyers are nothing if not sensitive to language, so we're very good at coming up with possible ambiguities. A judge confronted with a bona fide ambiguity, or even a borderline one, ought to let the case go to trial for the jury to resolve the intent question. (The "ought" comes from common law about when summary judgment is inappropriate.)
Another good one is in contracts for specialized goods and services with esoteric terms and requirements. You identify some inadequately defined word no jury is familiar with and hire an expert witness to opine that the word's meaning in the particular commercial context is x. Your opponent hires an expert to say it's y. Again, the appellate courts tell the trial courts that in this situation, a jury should resolve the "battle of the experts." P.S. you can find an expert to say just about anything for $5,000, $10,000 on the high side.
As you can imagine, it's much easier to litigate the interpretation of a contract than to draft one that can't really be litigated. Transactional attorneys tend to give litigators a hard time about this, and litigators give transactional attorneys a hard time about being terrified of court rooms.
Curated. In addition to giving me an overall grounding in "what's up with contracts?", I was particular intrigued by the parallels with software development.
I'm interested in learning more about whether there have been any startup-y attempts to do some manner of "integrate lessons from software development into contract design".
Look up ethereum smart contracts, algorand TEAL stateful contracts. I think the area you are stumbling into Is Turing-complete smart contracts blockchains. After all it seems to me that the main issue of blockchain is consensus, specifically consensus among every node as to the content of the blockchain. Thanks to virtual software environments running directly on top of the consensus algorithms of these public networks, we can program a contract that will execute an action once conditions agreed upon by the network through the consensus algorithm are met.
Thanks to technologies like Chainlink and QR codes we can verify the states of real world objects as well as data sets outside the blockchain network and align them to states on the blockchain. This the blockchain acts as a sort of digital map of some Aspect of either the real world or the mental map of the programmer(s) involves in making smart contracts. And even more impressive, some smart contracts are actually frameworks for non-technical individuals to form their own smart contracts that will be verified and enforced via public consensus.
A fun experiment to check out is tokensets, which enable me to invest into trading and interest-farming strategies of dozens Of real life traders without ever giving up my name, social, or even an email! The contract is set up such that each trading strategy that a trader launches generates an empty tokenized pool. Anyone is able to buy any fraction of a share in said pool by paying into it with a crypto of their choice. This crypto is then rebalanced according to the settings the trader has set based on his analyses of the market. My hardware wallet holds the number of shares I own relative to the size of the pool, So I am always able to cash out my proportion of the fund and redeem it for the underlying assets or an asset of my choice.
I think even more broadly the idea of consensus algorithms and the parallels that can be drawn between online trustless digital consensus and the alternative system of today that is the Rule of Law. I honestly think it could be the dawn of a new era, where humans express the substance of their business and high-worth personal interactions not through ambiguous human language, but through absolute and perfectly repeatable language of computers. After all the Rule if Law in my opinion could be inadequate once the deals involved in a contract reach certain magnitudes. Say in the future when entities discuss mining rights to asteroids with quadrillions of today’s dollars Worth of minerals and metals, I don’t think they’d wanna secure them in ways that could later be scrutinized and disputed in human courts, knowing how fallible humans are to bribery and weakness of will.
I would absolutely love some additional input on this as my knowledge is that of a simple avid watcher and investor of various crypto currencies and the overall developments taking place in the field.
Shouldn't smart contracts with staking also allow you to more readily enter contracts where payoffs are unknown? (eg you're not sure if investing in a person or decision will result in the payoffs you want - there's rather a distribution/ambiguity of outcomes). You mention rebalancing - this is where formalized smart contracts allow you to rebalance contracts based on another element of risk if you notice that you've staked too much on options that are volatile in response to investments that have too much time-correlated X1 in them?
You might even be unsure as to what your value function is (many people are!) but still have some aesthetic discernment/taste that allows you to make contracts in those areas where you are discerning
Once formed, a contract acts as custom, private law between the parties.
This is a cool way of understanding contracts.
I'm putting this on the shelf of facepalm-obvious-but-beautiful realizations like
Wow, thank you so much for this! This makes me feel a lot more comfortable writing my own contracts for small things.
If anyone wants to dig further into commercial contracts, there's the "Uniform Commercial Code" which is like a big software library that most people have basically agreed to implement in the same way across different programming languages.
This is great! It's also been on my to-do list for a while to look more into how exactly contracts work and what the relevant abstractions are, and this feels like it gives me a decent framework to start from.
Thanks for the informative and easily-readable summary! This makes me wish Blinkist would add a checkbox to enable good epistemology in their book summaries. Or more plausibly, makes me want to contribute some summaries here too.
Compared to (good) software developers, lawyers do not seem to be very good at this; they tend to throw patches on top of patches, creating more corner cases rather than fewer.
Do we actually know that they're not good at it? I realize that their solution looks bad when evaluated on the standards of a software developer, but for something like contract law that has been around for a really long time, my heuristic would be to assume that a seemingly bad solution has some hidden purpose behind it.
I agree with this heuristic in general; when I say they don't seem to be good at this, I do mean that they don't seem to be good at it. It's entirely possible that there's some underlying purpose.
That said, there are plausible reasons to expect that modern contract-writing is not yet near equilibrium.
First, modern contract law is relatively new; the uniform commercial code, for instance, only came along in 1952. My impression is that older versions of contract law had a lot more use-case-specific rules, requirements for specific wording, geographic variation, etc - in short, it was less based on general principles. (And this is still the case in many other countries.) I'd expect older versions of contract law to have made it easier to write contracts which "just worked" in common use cases, but also made it harder to develop good general-purpose techniques.
Second, it took half a century for software-writing to come as far as it has, and the incentives for scalable legibility just don't seem as sharp in contracts - so it should take even longer. At the end of the day, most contracts operate in an environment where people are invested in reputations and relationships; an oversight which could be abused usually isn't, an accidental breach can usually be worked out with the counterparty, and so forth. It's not like a computer which just executes whatever code is in front of it. (And even today, plenty of software engineers do throw patches on top of patches - it just seems more commonly understood in the software world that this is bad practice.)
I think part of it is that contracts are mostly interpreted by trained humans. A computer works through each line of code before continuing to the next line. A human can look at a paragraph of standard legal language, understand that it does the standard thing, and move on in a second or so; reading a paragraph of non-standard language makes the human stop and think, which is much slower and often causes anxiety.
Even better, there are usually many court cases establishing exactly how the standard language should be interpreted in a wide variety of circumstances, which makes the standard language much more predictable and reliable. In software terms, it has already been debugged.
I agree with this heuristic in general; when I say they don't seem to be good at this, I do mean that they don't seem to be good at it. It's entirely possible that there's some underlying purpose.
Fair enough!
First, modern contract law is relatively new; the uniform commercial code, for instance, only came along in 1952.
Huh, interesting. That's surprising to me; I expected contracts to have a sufficiently long history that there wouldn't be any recent major innovations. In retrospect, I realize a long history alone isn't enough to assume that: mathematics is also ancient but has seen its fair share of recent-ish innovations anyway.
Second, it took half a century for software-writing to come as far as it has, and the incentives for scalable legibility just don't seem as sharp in contracts - so it should take even longer. At the end of the day, most contracts operate in an environment where people are invested in reputations and relationships; an oversight which could be abused usually isn't, an accidental breach can usually be worked out with the counterparty, and so forth. It's not like a computer which just executes whatever code is in front of it. (And even today, plenty of software engineers do throw patches on top of patches - it just seems more commonly understood in the software world that this is bad practice.)
I feel like this is part of what I was gesturing at with the "on the standards of a software developer" bit. If the nature of the domain is such that "throwing patches upon patches" actually works fine most of the time, then I wouldn't say that lawyers are bad at what they do for relying on that. One could flip it around and say that they're good at what they do, for not wasting effort on optimizations that largely wouldn't make a difference.
That's surprising to me; I expected contracts to have a sufficiently long history that there wouldn't be any recent major innovations. In retrospect, I realize a long history alone isn't enough to assume that: mathematics is also ancient but has seen its fair share of recent-ish innovations anyway.
From Personal To Prison Gangs is probably relevant here. As society transitions from many repeated interactions between small numbers of individuals to more one-off interactions between large numbers of individuals (ultimately enabled by communication and transportation technology), we should expect more reliance on formal rules and standards. Those formal rules and standards also need to cover more people in a wider variety of situations - they need to be more general-purpose (since people themselves are less siloed than previously).
That sort of transition seems to have been particularly prevalent around the early-to-mid twentieth century.
That's the sort of heuristic which predicts this kind of fundamental shift in contract law (among many other things) around the time that we saw such a shift.
Huh, interesting. That's surprising to me; I expected contracts to have a sufficiently long history that there wouldn't be any recent major innovations.
The key change doesn't seem to be so much about innovation but about standardization between different jurisdictions.
Standardization between multiple jurisdiction that each like their own standards is hard as shown by the US still using a lot of imperial units.
I'm curious what you mean by enforced scope and modularity in a contract. As a lawyer (though one who rarely works with contracts), I agree that the nested series of if-then's is common, but I don't have a good sense of what you're suggesting as an alternative.
That wasn't intended to be an alternative to a nested series of if-thens; it's a solution to a different problem. (The usual software engineer's solution to a nested series of if-thens is to figure out what the thing is that you actually want, which all these conditions are trying to approximate, and then write the thing you actually want instead. Of course it's more difficult than that in practice, because sometimes the thing you actually want can't be written directly due to the limitations of programming languages/contract enforceability. I would imagine that skill is quite similar for both good contract lawyers and good software engineers.)
The idea of enforced scope/modularity is to make the table of contents binding, so people with specific use-cases don't need to review the whole thing. So for instance, suppose we have some complex transaction involving both representations and covenants, and we put the representations in their own section. Post-closing, people will mostly need to double-check the contract to see what the covenants say, not what the representations say. So it would be useful to have language alongside the table of contents nullifying any post-closing covenants which appear in the "Representations" section. Then, most people reviewing the contract post-closing won't need to read through the Representations section just to be sure there aren't any covenants hiding in there.
Thanks, that's an interesting idea, and not one I've seen before.
2 potential issues come to mind:
1. As you noted, a key goal is to reduce ambiguity as much as possible. An enforced scope provision opens up the possibility that a court will nullify another provision for being in the wrong place. This adds ambiguity to the contract, especially because at first there wouldn't be any court decisions on how they interpret enforced scope provisions. I'm not sure off hand how serious of a problem this would be--maybe the dividing line between covenants and representations is clear enough that no provision might be interpreted to create both, for example.
2. Unlike software development (I expect), negotiating contracts is somewhat adversarial. Adding new types of provisions, or even deviating from common ("market") language on a given topic raises an inference that you're trying to pull one over on the other side. That is, adding an enforced scope provision could be seen as an indication that you think there's some other provision that might be invalidated to your advantage.
These both weigh against creativity in contract drafting, which helps explain why there's so much copy and pasting of precedent contracts.
Thanks, I was hoping someone would leave a comment along these lines. Definitely helps me understand the underlying drivers better.
While I don't think this quite gets to where you are suggesting every contract I have ever seen includes some clause that pretty much talks about the independence of the sections and how they stand even if some other clause is invalidated. That seems to be a form or modular/scope structure.
Perhaps the question there is where the difference might be. For instance, when using the software metaphor I don't think it is really good to compare a simple application to the contract but more like a whole suite of applications. Don't compare Excel to the contract but Office365. In this setting, does contract seem to stand a bit more firmly than say the security around the inner working of the applications within Office?
Or is than not really a good comparison?
Compared to (good) software developers, lawyers do not seem to be very good at this; they tend to throw patches on top of patches, creating more corner cases rather than fewer.
There are plenty of different lawyers and different one's have different interests.
YCombinator for example has a bunch of relatively short contract documents on offer. YCombinator has an interest in startup short contracts in a way that most law forms who pay for their legal services don't.
might put lawyers out of business
This might be even worse than she thought. Many, many contracts include the exact opposite of this clause, i.e., that the section titles are without any effect whatsoever on the actual interpretation of the contract. I never noticed until just now that this is an instance of self-dealing on the part of the attorneys (typically) drafting the contracts! They're literally saying that if they make a drafting error, in a way that makes the contract harder to understand and use and is in no conceivable way an improvement to the contract, the courts need to assume "well, one common kind of drafting error is putting a clause in the wrong section, probably that's what happened here" only because the "clauses in wrong section are void" provisions you mentioned are as far as I know literally unheard of!
Contracts is one of those areas that I always figured I ought to study, at least enough to pick up the basics, but never seemed either interesting or important enough to reach the front of my queue. On top of that, there’s a lot of different angles from which to approach the subject: the law-school-style Contracts 101 class covers the legal principles governing contracts, the economists’ version abstracts away the practical specifics and talks about contracts in game-theoretic terms, more business-oriented books often focus on negotiation, etc.
“Working With Contracts: What Law School Doesn’t Teach You” is about the practical skills needed for working with contracts on an everyday basis - specifically the sort of skills usually picked up on the job by young lawyers. It talks about things like what to look for when reviewing a contract, how to organize contracts, why lawyers use weird words like “heretofore”, various gotchas to watch out for, etc. It assumes minimal background knowledge, but also includes lots of technical nuts and bolts. In short, it’s the perfect book for someone who wants a technical understanding of real-world contract practice.
This post will review interesting things I learned from the book.
First, some very brief background info, which the book itself mostly assumes.
Legally, in order to count as a “contract”, we need four main pieces:
A Contracts 101 class has all sorts of details and gotchas related to these. Notice that “signature on a piece of paper” is not on that list; e.g. oral contracts are entirely enforceable, it’s just harder to prove their existence in court. Even implicit contracts are enforceable - e.g. when you order food from a restaurant, you implicitly agree to pay for it, and that’s a legally-enforceable contract. That said, we’ll focus here on explicit written contracts.
Once formed, a contract acts as custom, private law between the parties. Enforcement of this law goes through civil courts - i.e. if someone breaches the contract, then the counterparty can sue them for damages. Note the “for damages” in that sentence; if a counterparty breaches a contract in a way that doesn’t harm you (relative to not breaching), then you probably won’t be able to sue them. (Potentially interesting exercise for any lawyers in the audience: figure out a realistic contractual equivalent of Newcomb’s problem, where someone agrees to one-box on behalf of someone else but then two-boxes, and claims in court that their decision to two-box benefited the counterparty rather than harming them. I’d bet there’s case law on something equivalent to this.)
Note that this is all specific to American law, as is the book. In particular, other countries tend to more often require specific wording, ceremonial actions, and the like in order to make a contract (or component of a contract) enforceable.
The “functional” components of a contract can be organized into two main categories: representations and covenants. A representation says that something has happened or is true; a covenant says that something will happen or will be true.
Some example representations:
Nominally, each of these is a promise that something is true. However, that’s not quite how they work functionally. Functionally, if a counterparty acts based on the assumption that the statement is true and is harmed as a result, then they can sue for damages. In other words, when providing a representation, we provide insurance against any damages which result from the representation being false. Bob may not even have checked that the house he’s selling contains no asbestos, and that’s fine - if he’s willing to insure the counterparty against any asbestos-related risk.
This idea of insurance becomes important in contract negotiations - there’s a big difference between e.g. “no environmental problems” and “no environmental problems to the best of their knowledge”. The former insures against any environmental problems, while the latter insures against any environmental problems which the signer knew about at time of signing. One puts the duty/risk of finding/fixing unknown problems on the signer, while the other puts it on the counterparty.
The other key thing to notice about representations is that they’re as of the signing date. When Bob states that his house contains no asbestos, that does not insure against the house previously containing asbestos or containing asbestos in the future. It only needs to be true as of that one moment in time. This becomes relevant in complex multi-stage contracts, where there’s an initial agreement subject to a bunch of conditions and reviews, and the final closing comes later after all that review is done. For instance, in a mortgage there’s an initial agreement subject to the borrower providing lots of forms (credit check, proof of income, proof of insurance, etc…), and the final contract is closed after all that is reviewed. In these situations, the borrower usually makes some representations early on, and then has to “bring down” the representations at closing - i.e. assert that they’re still true.
While representations deal with past and present, covenants deal with the future. They’re the classic idea of contract provisions: precommitments to do something. Some examples:
These work basically like you’d expect.
Representations and covenants often run in parallel: a representation that X is true will have a corresponding covenant to make X continue to be true in the future. For instance:
This is mainly for contracts which will be performed over a long time, especially debt contracts. One-off contracts (like a purchase/sale) tend to have relatively few covenants; most of their substance is in the representations.
Representations and covenants seem pretty straightforward, at least conceptually. One is insurance against some fact being false, the other is a precommitment.
The technical complexity of contracts comes from the interplay between two elements. First:
The goal of a contract is to describe with precision the substance of the meeting of two minds, in language that will be interpreted by each subsequent reader in exactly the same way.
In other words, we want no ambiguity, since any ambiguity could later be used by one of the parties to “cheat” their way out of the contract. This creates a headache very familiar to software developers: like programs, contracts mean exactly what they say. There is no “do what I mean” button; we can’t write something ambiguous and rely on the system to figure out what we meant.
Second: we don’t have perfect knowledge of the future. When making a precommitment in a contract, that precommitment is going to operate fairly mechanically in whatever the future environment looks like. Just like a function written in code may encounter a vast space of unusual inputs in the wild, a precommitment in a contract may interact with a vast space of unusual conditions in the wild. And since we don’t know in advance which conditions will be encountered, the person writing the code/contract needs to consider the whole possible range. They need to figure out, in advance, what weird corner cases could arise.
Put those two pieces together, and the picture should feel very familiar to software developers.
The result is that a lawyer’s job ends up involving a lot of the same pieces as a software engineer’s job. A client/manager says “here’s what we want”, the lawyer/programmer says “ummm I don’t think you really want that, because <problem> happens if <circumstance>”, and they go back-and-forth for a while trying to better define what the client/manager really wants. An example from the book pictures a lawyer reviewing a contract with a client (simplified slightly by me):
Lawyer: This is a covenant that restricts your business from incurring debt…
Client: That’s fine, we don’t plan to use any bank financing.
Lawyer: Well, the definition of “debt” used is very broad. For instance, it includes payment plans on any equipment you buy…
Client: Well, we can add some room for that.
Lawyer: How much room do you need?
Client: Based on our current needs, less than $1M at any given time.
Lawyer: But if that new plant you were talking about gets off the ground, won’t you need to buy a bunch of new equipment for it?
Client: Good point, we’d better ask for $5M…
This could go on for a while.
Despite the parallels, lawyers are not very good software engineers, in general. The most common solution to the sorts of problems above is to throw a patch on it, via two kinds of exceptions:
Over the course of negotiations, patches are layered on top of patches. An example from the book:
Little Corp may not transfer any Shares during the term of this Agreement, except for (i) transfers at any time to its Affiliates (including, without limitation, Micro Corp) other than Medium Corp, and (ii) so long as an Event of Default attributable to Big Corp shall have occurred and be continuing, transfers to any Person (including, for the avoidance of doubt, Medium Corp).
This mess is the contractual equivalent of a series of if-statements nested within if-statements. This is, apparently, standard practice for lawyers.
(Another complaint: in a complex contract, it would not be hard to include provisions alongside the table of contents which nullify provisions which appear in the wrong section. Then people reviewing the contract later wouldn’t have to read the whole thing in order to make sure they didn’t miss anything relevant to their use-case; it would be the contract equivalent of variable scope. My mother’s a lawyer in real estate and wills, so I asked her why lawyers don’t do this. Her possibly-tongue-in-cheek-answer: might put lawyers out of business. Kidding aside, the bar association engages in some pretty incestuous rent-seeking, but judges have been pushing for decades to make contracts and other legal documents more legible to non-lawyers.)
A contract writer’s job is much easier than a programmer’s job in one key respect: a contract will ultimately be interpreted by humans. That means we can say the equivalent of “look, you know what I mean, just do that”, if we expect that a court will actually know what we mean.
This gives rise to a bunch of standard tricks for invoking the do-what-I-mean button. We’ll talk about three big ones: materiality, reasonableness, and consistency with “ordinary business”/”past practice”.
Materiality
Roughly speaking, materiality means ignoring small things. For instance, compare:
The first would be breached if e.g. the borrower forgot to update their payment information on their $10 monthly github subscription, and the payment was late. The second would ignore small things like that.
In general, materiality is relative to the size of the business. A $100k oversight would be quite material to most small businesses, but immaterial to AT&T. It’s also relative to the contract - if that $100k oversight is directly relevant to a $300k contract, then it’s material, even if the $300k contract itself is small change to AT&T.
Where’s the cutoff line? That’s for courts to decide, if and when it matters. That’s how pushing the do-what-I-mean button works; you have to rely on the courts to make a sensible decision.
One particularly common usage of materiality: “material adverse change/effect”. Rather than saying “X has no pending lawsuits”, we say “X has no pending lawsuits whose loss would entail a material adverse effect”. Rather than saying “Borrower will notify Lender of any change in their business forecasts”, we say “Borrower will notify Lender of any material adverse change in their business forecasts”. This way a lender or buyer finds out about problems which actually matter, without being inundated with lots of minor details.
Reasonableness
Reasonableness is exactly what it sounds like. It’s saying something that has some obvious loophole to abuse, then giving a stern look and saying “don’t go pulling any bullshit”. Example: “Company shall reimburse X for all of X’s out-of-pocket expenses arising from...” vs “Company shall reimburse X for all of X’s reasonable out-of-pocket expenses arising from…”
Some patterns where reasonableness shows up:
What would each of these do without the reasonableness clause? In the first case, the borrower could claim that they didn’t expect Obvious Bad Thing to impact their business. In the second case, XYZ Corp could withhold consent for some case they obviously don’t care about in order to extract further concessions from ABC Corp. In the third case, an insurer could simply refuse to provide X, and the borrower wouldn’t be able to do anything about it.
Behaving Normally
Sometimes a lender or prospective buyer wants to say “what you normally do is fine, so do that and don’t go crazy”. Two (similar) standards for this: “in the ordinary course of business” and “consistent with past practice”.
Typical examples:
In general, this is a pretty good way to let business continue as usual without having to go into all the tiny details of what business-as-usual involves, while still ensuring that e.g. a borrowing company doesn’t sell all their assets, distribute the funds as a dividend to a parent company, and then declare bankruptcy.
In general, if a contract is breached, the counterparty can sue for damages. If you want anything else to happen as the result of a breach, then it needs to be included in the contract. In particular, common things triggered by a breach include:
The last is somewhat redundant with the court system, but by including it explicitly, the contract can also specify how to calculate damages, how damages are to be paid, caps or exceptions to liability, etc. Rather than leaving such matters to the whims of a court, the contract can specify them.
Termination and acceleration are particularly relevant from a negotiation standpoint - the former for one-shot contracts like sales, and the latter for long-term contracts like debt.
The earlier stages of a complex sale (e.g. a merger/acquisition of a company) involve an agreement to sell subject to a long list of conditions being satisfied - i.e. the “due diligence” conditions. If any of those conditions are not met, then the buyer gains the right to terminate the contract - i.e. walk away from the deal. But these things can take months; the last acquisition I saw took around a year. During that time, the buyer may change their mind for reasons entirely unrelated to the seller - e.g. market prices for the seller’s assets may change. The seller wants to prevent the buyer from walking away in a case like that.
This means that the buyer has incentive to ask for very complicated and/or very subjective conditions, to give themselves the opportunity to walk away whenever they want. For instance, if a buyer manages to get a condition which requires “X which is satisfactory in Buyer’s sole discretion”, then the buyer effectively gains a blanket option to walk away from the deal; they can always just claim that some inane detail of X is unsatisfactory. (This is a good example where reasonableness can fix the problem.) In particular, if market conditions change, then the buyer may use that option to negotiate more concessions, like a lower purchase price.
Acceleration has a similar effect in debt deals. Nobody ever wants to accelerate debt; it’s a surefire way to end up in bankruptcy court. When a contract breach gives a lender the option to accelerate, what actually happens is that they use that option as leverage to negotiate a new deal. They’ll want a higher interest rate, or a claim on more of the borrower’s assets, or the like.
Takeaway: just because a contract specifies a particular penalty for breach does not mean that the penalty actually happens. Often, the penalty is really used as an option by one party to renegotiate the contract, and provides leverage for such a negotiation.
Contracts are a lot like computer programs: they’re taken very literally, and they could potentially encounter a wide variety of corner cases in the wild. Together, those two pieces make a contract writer’s job quite similar to a programmer’s job: a client/manager will tell you what they think they want, and then you go back-and-forth trying to formulate what they really want.
Compared to (good) software developers, lawyers do not seem to be very good at this; they tend to throw patches on top of patches, creating more corner cases rather than fewer. They don’t seem to have even realized that enforced scope and modularity are things which one could use in a contract; consequently, every contract must be read in its entirety by anyone relying on it. That puts a sharp limit on the scale of today’s contracts.
Unlike programmers, lawyers do have a “do what I mean” button, although its use comes with a cost; it means leaving interpretation to the whims of a court. For many “simple” things, that cost is relatively minor - so contracts can ignore “immaterial” problems, or require “reasonable” behavior, or stipulate consistency with “past practice” and “the course of ordinary business”.
Functionally, contracts provide insurance against stated facts being false, and they provide precommitments for the future. They can also stipulate nominal penalties for breach of contract, though in practice these penalties often serve as options to renegotiate (with leverage) rather than actually being used.