Findings We Didn’t Teach the System to Look For

Before a company moves its systems to the cloud, someone has to answer an expensive question. Are we ready? Not ready in the aspirational sense, but ready in the specific ones. Can our applications survive the move, is our data clean enough to migrate, does our team have the skills, what breaks, and how do we fix it?

Companies rarely answer that alone. They hire an advisory firm to run a readiness diagnostic, a multi-week or month assessment that ends in a report, and that report becomes the map for everything that follows. The migration plan, the budget, the timeline, and often millions of dollars in downstream spending all stand on what the diagnostic outlines.

We recently evaluated an engagement with that shape. An advisory firm, a cloud migration readiness diagnostic, a $140,000 fixed fee, and a pretty standard SOW 5 pages long.

A SOW of that length can seem thin for work with this much riding on it, but that’s by design. Companies that work with the same firm repeatedly don’t negotiate a full contract for every project. They sign a master services agreement once, and it carries all the legal machinery. Liability, indemnity, insurance, confidentiality, termination. Each new project then only needs a short statement of work naming the tasks and the price. It inherits everything else from the master. One long contract, and many short ones living underneath it. A parent and its children. We call that structure a Document Family, and it is one of the most common arrangements in commercial contracting.

It is also where risks hide.

3 Questions a Careful Buyer Asks

If the diagnostic is done negligently, the client doesn’t lose $140,000. They execute a multimillion-dollar migration on a bad map, and the losses show up later as blown budgets, failed cutovers, and revenue that never materializes. So before signing paper like this, a careful buyer wants 3 things settled.

The Cap

Almost every services contract limits how much the client can recover if things go wrong, usually to some multiple of the fees paid. The question is whether that ceiling bears any relationship to the damage the work could cause.

Insurance

A promise to pay is only as good as the money behind it, so buyers require the firm to carry errors and omissions coverage, the professional-liability policy that pays when advice turns out to be negligent. The question is whether the client can reach that policy when it matters.

Exclusions

Contracts routinely carve out categories of damage neither party will pay for, and lost profits are a classic one. So, the question is whether the excluded category is the kind of harm this engagement could produce.

This contract answers all 3 questions, but in places where no one reading the statement of work would look.

What the System Found

When Revver Contract Intelligence reviewed the Cloud Migration Readiness SOW, it produced a finding that reads like a senior lawyer’s margin note. Recovery on this engagement is capped near $140,000. The $5,000,000 errors and omissions policy the client requires is largely decorative. And lost profits are excluded, which is the exact category of harm a negligent readiness diagnostic would cause.

The statement of work contains none of those clauses.

No liability cap. No insurance requirement. No lost profits exclusion. The document contributes exactly one number, the $140,000 fixed fee. Everything else lives upstream in the master services agreement. The master caps recovery at 6 months of fees paid under the applicable statement of work. The master also requires the firm to carry $5,000,000 in errors and omissions coverage, but excludes lost profits.

Run the arithmetic. 6 months of fees on a $140,000 fixed-fee project is $140,000. The client is requiring a $5,000,000 insurance policy it can recover roughly $140,000 against, on an engagement whose failure mode is measured in millions, in a category of damage the contract excludes anyway. The policy exists. But as drafted in the contract, the client can’t reach it.

No single clause within the Document Family is unusual. The cap is ordinary. The insurance schedule is ordinary. The exclusion is boilerplate. The finding only exists in the interaction between them. And the interaction only becomes visible when a number from one document meets a formula from another.

To understand why we find this result so interesting, you need to know a little about how machines read contracts, and about how ours reads them differently. Bear with me…

How a Machine Reads a Contract

Most contract AI never reads a contract the way you would. The documents get chopped into small fragments, a few paragraphs each, and stored in a database. When a question comes up, the system fetches the handful of fragments that look most relevant and reasons over those. Engineers call this chunking. It’s popular because it’s cheap, fast, and it scales.

But look at what it costs. No fragment knows what the other fragments say. It is like tearing a book into pages, handing one page each to 100 readers, and asking the group what the story means. Every reader does their job. Nobody has read the book.

Now hold our findings up against that. The fee sits in the statement of work. The cap formula sits in a different document, thousands of words away. No fragment of either document contains this finding, so a system that reads in pieces cannot make this catch, no matter how smart the model behind it is.

We built RCI the opposite way, deliberately and at real expense. It reads the full raw text of the contract in a single pass, front to back, every word. And before that read begins, it walks the contract’s Document Family and brings the related agreements along, so the statement of work arrived for review with its master agreement beside it. Everything on the same desk. That choice makes each review slower and costlier (to us) than a chunked one, and it is the reason the finding above is possible.

A Map of How Clauses Interact

Reading everything is necessary. It’s not sufficient. A contract is not a list of independent rules. It is a web of rules that change each other. A liability cap means one thing next to a strong indemnity and something else next to a weak one. An insurance requirement looks protective until the cap makes the policy unreachable. Reviewing clauses one at a time is how bad deals pass review.

Borrow a tool from a branch of mathematics called graph theory. Draw every clause as a dot. Call the dots nodes. Now draw a line between any 2 clauses that change each other’s meaning. Call the lines edges. Do this honestly for a real contract and the picture stops looking like a checklist and starts looking like a spider web.

Our experts have spent careers learning where the load-bearing edges are, the interactions that decide whether a deal protects you or only appears to. We encoded their collective experience as our Cross-Clause Binding Matrix, the map of clause interactions every RCI review checks. Cap to indemnity. Insurance to cap. Termination to payment. It is the distilled judgment of people who have watched these interactions go wrong in live deals, applied by a machine with a consistency no human team can match. And every review ships with a Review Receipt listing each standard checked, so you can see what the review covered instead of taking our word for it.

The Pass With No Checklist

If we had stopped there, we would have built a fast, tireless version of our own knowledge. That was never the goal, because we started with an assumption that’s unusual in software. We don’t know everything. We never will. Contracts change, markets change, and the next deal contains something the last 1,000 didn’t. A system built only from its makers’ knowledge carries its makers’ blind spots, permanently, at scale.

So, after the structured read, RCI takes a second pass over the full text with no checklist at all. Its only instruction is to report anything material that no standard asked about. Whatever it finds lands in its own lane, labeled as what it is. We call these Emergent Findings. They are the system’s way of saying it noticed something we never told it to look for.

The finding at the top of this piece was emergent. No standard in our library requested the comparison. No edge in the matrix connected these clauses across these documents. The system pulled the fee from one document, ran it through the formula in another, computed the ceiling, held it against the insurance the same master demands, and then noticed the exclusion that removes the one category of damage a failed diagnostic produces. Arithmetic in the middle, judgment at the end, inside a pass we built so that our own knowledge would never be the ceiling.

What Surprised Us

When we designed Emergent Findings, we pictured it finding missing nodes. A clause type we hadn’t encoded, a provision our experts hadn’t met before, a new dot for the map.

What it found was a missing edge. Every clause in this story was already in our library, and each one passes review on its own. The risk lives in the line between them, a line no one had drawn, running between two documents. We expected the unbounded pass to grow the map’s dots. It grew the web instead. We’d argue the matrix itself is why. A system that reads a map of interactions before every review learns that the space between clauses is where meaning lives, and the unbounded pass carried that instinct past the map’s borders. And an interaction nobody encoded is, by definition, an interaction nobody is checking for. That is where the most dangerous problems in contracting live, and we now have the system reaching into that space on its own.

What Happens to a Finding Like This

An emergent observation doesn’t quietly become doctrine. It queues for expert review, and a human decides whether the new edge gets drawn into the Cross-Clause Binding Matrix permanently, checked on every future review, for every client. This is the loop the whole system is built around. The machine reads everything and does the arithmetic no human has time for. The humans judge what deserves to join the map. The map grows, and the second pass keeps looking past it, because a system that relies 100% on its own accumulated intelligence is a system that has started going stale.

We built RCI on the assumption that we don’t know everything. This is what it looks like when that assumption pays.

If you ever want to reach out, I’m at sp@revver.ai, or find me on LinkedIn.