The Contraqly Approach to Clause Intelligence

When I started thinking about what Contraqly should actually do, I spent a long time looking at what the market was already building. Most of what I found was focused on drafting: tools that help attorneys write contracts faster, generate first drafts from templates, or suggest clause language based on prior negotiations. These are genuinely useful products for teams that spend significant time on new contract creation. They weren't solving the problem I kept running into in practice.

The problem I kept seeing was different. It wasn't that in-house legal teams were drafting contracts slowly. It was that, after contracts were signed, the organization had almost no ongoing intelligence about what was in them. Every executed agreement went into a file store, and the commercial terms, obligations, and risk provisions it contained became effectively invisible until something went wrong or a renewal deadline arrived — often at the same time.

Why We Start With Executed Contracts

The distinction between drafting-stage tooling and executed-contract tooling sounds like a technical product boundary. It's actually a fundamentally different definition of what the problem is.

Drafting tools assume the risk lives in the creation of contracts — that better drafts will produce better outcomes. That's true at the margin, and for organizations that create large volumes of new contracts, drafting efficiency is real. But for most in-house legal teams, the risk that's actually materializing isn't in what they're about to sign. It's in what they signed 18 months ago, under time pressure, with a vendor whose bargaining position was stronger than theirs, with a notice period they've never tracked, and a liability cap they negotiated but haven't thought about since.

When we decided to build on executed contracts rather than drafts, we were making a deliberate choice about where legal operations risk is concentrated for teams in the 500–2,000 active contract range. That's the range where the volume is high enough that manual oversight has definitively broken down, but low enough that the organization hasn't yet invested in enterprise CLM infrastructure. It's also the range where the executed-contract backlog problem is most acute: years of agreements in various states of organization, with clause data that has never been extracted at scale.

What Clause Intelligence Is — and Isn't

Clause intelligence, as we use the term, is the extraction, classification, and comparison of clause-level data from executed contract text. The output is structured metadata: for each agreement, for each clause type, a record of what the clause says and how it compares to a baseline of standard market positions for that contract category.

It is not contract summarization. A summary is a condensed version of the document that still needs to be read. Clause intelligence produces records that can be queried, filtered, and acted on without reading the underlying document — unless the query produces a result that requires human review. The goal is to eliminate the need to read contracts in the ordinary course of contract management, reserving attorney reading time for the situations where the extracted data indicates a problem worth investigating.

It is also not contract analysis in the sense of legal advice. Contraqly does not tell you whether a liability cap is acceptable — it tells you that the cap is below the typical range for this contract type at this deal size, and by how much. The judgment about whether to accept, renegotiate, or live with that deviation is a human decision. What we're doing is ensuring that the information required to make that decision is available, accurate, and surfaced at the moment when it's actionable — not discovered retrospectively.

The Deviation Scoring Architecture

The core of how Contraqly classifies and scores clause deviations involves three layers that each have to work correctly for the output to be reliable.

Agreement classification: Before assessing any clause, the system needs to understand what kind of agreement it's reading. A liability cap that's below market for a professional services agreement may be entirely standard for a software license. Classification by agreement type is the prerequisite for any meaningful deviation assessment. We classify agreements across a range of commercial categories — SaaS, professional services, staffing and contingent labor, data processing, hardware supply, and several others — and the deviation baseline shifts by category.

Clause extraction and boundary detection: The system needs to find the relevant clause, determine where it begins and ends, and read all of it — including any defined terms that affect interpretation. A liability cap clause that references a separately defined "Losses" definition is read differently than one that uses "damages" as an ordinary term. Incomplete extraction produces wrong metadata.

Baseline comparison and severity scoring: Extracted clause terms are compared against market baselines for the agreement category and deal size. The output is a deviation score — a classification of the clause as within-market, mildly non-standard, or materially non-standard — along with the specific dimension of deviation. For liability caps: is the cap below market (favors vendor), above market (uncommon but possible), or structured unusually (e.g., per-incident rather than aggregate)? For auto-renewal provisions: what is the notice period, and does it fall within the typical range for this agreement type?

Why Executed Contracts Are Technically Harder Than Drafts

Working on executed contracts rather than drafts creates several technical challenges that drafting-stage tools don't face.

Executed contracts come in inconsistent formats. A negotiated agreement executed in 2019 might be a PDF of a scanned original, with mediocre scan quality, possibly with handwritten initials in the margins and exhibit pages that were attached from a different document. A draft-stage tool works on a clean Word document with consistent formatting. Executed-contract intelligence has to work on whatever you actually have.

Executed contracts have amendments. The operative terms of an agreement aren't necessarily in the main body — they may have been modified by amendments, addenda, and order forms executed months or years later. A system that reads only the base agreement and misses the amendment that changed the liability cap is producing incorrect metadata. Connecting amendments to their parent agreements and understanding which provisions they modify requires entity resolution across the document population, not just clause extraction within individual documents.

Executed contracts reflect real negotiation outcomes, not templates. The clause language in an executed agreement may be a hybrid of your standard form, the counterparty's redline, and a compromise position that neither party's counsel would have drafted from scratch. This makes classification and comparison harder — the clauses don't fit neat templates, and the deviation scoring has to accommodate the full range of commercial drafting variation.

Where We Don't Try to Replace Attorneys

There's a version of the pitch for tools like Contraqly that promises to "replace" legal review with automated analysis. We deliberately don't make that pitch, because we think it's both inaccurate and counterproductive.

Contraqly surfaces clause data. Attorneys decide what to do with it. The system can tell you that a mutual indemnification clause has a carve-out for IP infringement that's asymmetric — the vendor's indemnification obligation for third-party IP claims is uncapped, but yours is limited to the contract value. Whether that asymmetry is acceptable given the nature of the vendor relationship, the risk of third-party IP claims in your industry, and the cost of renegotiating it is a judgment that requires legal and business context that no extraction system has. The system gives you the facts; the lawyer applies the judgment.

This is not to say that automation has no role in the analytical chain — the extraction and classification work that Contraqly does is genuinely replacing work that attorneys were previously doing manually (or not doing at all because it didn't scale). But the scope of what's being automated is the data layer, not the decision layer. The goal is to give attorneys better information faster, not to make their judgment unnecessary.

The Operational Model: Ongoing Monitoring, Not One-Time Audit

One of the design choices I feel most strongly about is that Contraqly is built as an ongoing monitoring system, not as a one-time audit tool. The legal technology market has a history of selling "contract review" projects — a team uploads their repository, gets a report, and the engagement ends. The report is useful at the moment it's delivered, and then it ages. Six months later, 30 new agreements have been executed, five amendments have been signed, two counterparties have been acquired, and three renewal windows have passed. The "review" is obsolete.

The value of clause intelligence is persistent, not punctual. A repository that's accurately indexed today and maintained accurately as agreements change and new agreements are added is a different asset than a one-time snapshot report. The ongoing alert capability — 90-day notifications before renewal windows close, flags when new agreements deviate materially from your portfolio baseline — only works if the underlying data is current.

Building for ongoing monitoring rather than one-time audit changes product design decisions throughout the system: how ingestion works for new agreements versus backlog, how amendments are handled, how alert logic is structured, and how the team interface surfaces active issues versus historical data. Those are all choices we made at the beginning, not features we added later, because the use case we're solving for is day-to-day legal operations management — not annual contract review cycles.