David Rosen

The through-line

David Rosen's recurring argument is that contracts are code, and that the legal industry has never fully reckoned with the consequences. He came to law from database development and found derivatives work immediately congenial because of how it was built: "you're basically are looking at these books of definitions that are integrated by reference," so a five-page contract is "in reality" a 500-page contract assembling published modules [1]. That, he realised, "was the same exercise as coding right so when you're writing good code you write modules and you're passing through parameters" [1]. He grants he was an oddball for thinking this way, but the conviction has stayed constant: "I always thought of that of what we did as lawyers as actually code" [1].

From that follows everything else he says. If contracts are code, then the data in them is not a mess to be tidied but a structure to be read at machine speed, and the failure to read it is a failure of tooling rather than of the documents. His prediction runs the argument to its end point: contracts as drafted artefacts disappear, replaced by organisational preferences that mesh and generate the document behind the scenes [1].

On contract data being the most structured data in business

He rejects the standard framing outright. "We talk about contract data is unstructured I'd argue it's actually the most highly structured data that we have in business," because lawyers spend their working lives trying to get an agreement "into a place where it could be unambiguously interpreted by some third party at judge or whatnot" so that it is "repeatable over time" [1]. The apparent messiness is historical residue: the drafting tradition "evolved over Millennia" in conditions "when you didn't have computers and you didn't have code," producing "a guild of a highly trained very expert" lawyers whose craft "doesn't reflect fundamentally what they're doing" [1]. The technical opportunity is therefore a translation problem: "if you could actually translate the syntax of contacts into a machine readable format you could well understand what's in a contract and reproduce what was in the contract at machine speed" [1]. He is careful about how far his own company has taken this, noting they have done the reading part and "haven't done the writing part yet" [1].

The code analogy also exposes where contracts are worse than software. "Your compiler doesn't run until it's too late," so a syntax error surfaces "way down the line" [1]. He likens drafting to mainframe programming in the 1970s, where you had an hour a month and reviewed carefully before submitting, because "you have one chance to get it right" [1]. The result, in his view, is that billions of pages of US contracts "are Rife with syntax errors" and "the code is broken," a fact exposed in the credit crisis when top law firms turned out to have generated tens of thousands of pages "with like fundamental flaws in them that only came out when the music stopped" [1].

On contracts as the golden source for the whole company

His self-declared controversial opinion is about organisational data more than about law. Whatever the CFO tracks, whatever the chief risk officer tracks, whatever sales tries to capture in the CRM, "the golden source of all of that or almost all of it is actually the contracts" [1]. Relationships the organisation cares about, its constraints, what it agreed to do, what it can expect to happen, all of it is buried in the contracts [1]. Because that data is so hard to extract, companies give up on the contracts and instead collate the same facts into separate pools, which he sees as the wrong instinct: "if you can really crack the data problem at the golden source of all that data it will flow through to all the other things" [1]. The impulse to "shove their contracts in Salesforce" is a symptom of the same underlying truth, since when you want to know whether the CRM is accurate, "the answer is usually found in what you sign with something else" [1].

This reframes the legal department as well. He accepts the usual characterisation as fair, that legal is treated as "a Backwater a cost center a place where deals go to slow down and die," and accepts the more generous version, that it stops the company shooting itself in the foot [1]. But he adds a third reading: "the actual reality of an organization's interaction with the world is really in the contracts," even if most of it stays out of reach [1].

On where contract analytics actually earns its keep

He is blunt that single-document review is not the case that matters. Analytics helps "anywhere where you need to read through a contract," but the real situation is "if you have to look at 100 or a thousand or ten thousand contracts and you're constrained by what I call reality," where money alone will not solve it and hiring a top firm to read everything "may be impossible" [1]. His archetype is the Friday afternoon fire drill: the CEO asks something you ought to know, the answer sits across thousands of documents with variation everywhere, and an experienced in-house lawyer can say directionally what to expect but cannot say whether anything specific is in there [1]. With ten hours you give constrained advice; with portfolio-wide extraction you can carve out ten contracts to handle differently, treat another twenty more aggressively, and set a mainline approach, "much more nuanced advice given in real time across portfolios" [1]. He treats that Friday as a miniature of the systemic case, recalling the Lehman Brothers weekend when the entire Credit Suisse legal department was pulled into an emergency SWAT team for two or three days to answer fundamental questions [1]. Better information in those crises would mean better and more accurate valuations, and importantly it cuts both ways: risk-averse institutions become less conservative "because once they know they can do it they'll do it," while risk-accepting entities become more conservative once they can identify what is genuinely toxic, producing "much more calibrated activity" [1].

The other uses are less dramatic and more continuous. Extraction can pull operational data out of legacy and third-party contracts to feed downstream systems, and he draws a firm boundary around his own product: Catylex is not a contract lifecycle management system, it feeds one [1]. The gap he identifies in CLM is that these systems capture data well for documents they generate, while for third-party and legacy paper "you're still generally relying on people to get that data out" [1]. In diligence, machines need not be right about everything to make lawyers "10 times faster cheaper," and where a lawyer would otherwise sample because full review is too expensive, they can cover a much larger proportion or the entire portfolio [1]. At the largest scale, pooled contract data supports inference: patterns and relationships such as the range of vendors across many affiliates, "things that you would like to know that are prohibitively expensive to know right now if the only source to get them is by reading the contracts" [1].

On accuracy, ambiguity, and what extraction cannot fix

He does not claim machines eliminate error, and he points out that "people do this make mistakes all the time" too [1]. Quality control still means repeatable results plus humans reviewing outputs at some point, because the output eventually goes in front of a court [1]. More interesting is his distinction between extraction accuracy and contractual meaning: an extraction can be "an accurate rendition of what the contract says" while that text is itself ambiguous, doing "something different than what you might expect business intent was," whether by accident or occasionally on purpose, and "we're not trying to solve that problem" [1]. What large-scale review does surface is anomalies. Some are artefacts of the system doing the reading, some come from how particular lawyers drafted, and some "are actually bugs" [1].

On the death of contracts as we know them

Looking forward, he expects contract data to disseminate through the business to non-lawyers, including data lawyers themselves do not focus on or care about [1]. He also expects contracting practice itself to change, because "a lot of the variation that you see in Contracting is actually unnecessary": ninety-five percent of the time different formulations are trying to say exactly the same thing, five percent of the time the difference is meaningful, and within that five percent some of it is an attempt to "hide the ball" [1]. His view of purpose is deflationary and firm: "the business purpose of contracts is not to fool the other person not to express something more creatively it's to get this like very concrete manifestation of what the relationship is between two legal counterparties" [1].

He connects this to the smart contract enthusiasm while explicitly setting aside blockchain and ledgers. What limited smart contracts from spreading was "the vast permutations in the way the data actually can be expressed between parties," which is very hard to code, and getting things down to a basic machine-level representation is what would make contracts "truly smart" [1]. His stated prediction, hedged on timing between five and twenty years and offered as his genuinely controversial opinion, is "the death of contracts as we know" them: no contracts written on paper, organisations holding preferences that "just mesh and that will generate a contract behind the scenes," and "you're not going to have lawyers drafting contracts" [1].

Takeaways

• Contract data is not unstructured; it is the most highly structured data in business, because lawyers optimise agreements for unambiguous, repeatable interpretation by a third party [1].
• Contracts work like modular code, with definitions incorporated by reference turning a five-page document into an effective 500-page one, but with no compiler, so errors surface far downstream [1].
• The high-value analytics case is portfolio scale, not the single document: the Friday afternoon question spanning thousands of contracts that no budget or law firm can answer in time [1].
• Better contract information changes behaviour asymmetrically, making risk-averse institutions less conservative and risk-accepting ones more conservative, producing more calibrated decisions [1].
• Catylex is not a CLM; it feeds one, filling the gap where third-party and legacy contracts still depend on people to extract the data [1].
• Extraction accuracy and contractual meaning are different problems: a faithful extraction of an ambiguous or badly drafted clause is still ambiguous, and human review remains part of the workflow [1].
• Contracts are the golden source behind CFO, risk and CRM data, which is why organisations end up trying to push contracts into systems like Salesforce [1].
• Most drafting variation is unnecessary, and the endpoint is contracts generated automatically from organisational preferences rather than drafted by lawyers [1].