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.
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?
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?