Why does the contract reviewer live inside Word?

Why does the contract reviewer live inside Word?

Because the alternative is a portal, and a portal asks a lawyer to stop doing their job in order to use your product.

That is a distribution decision, not a technical one. It is also the decision with the longest tail in the whole system — it constrains how you authenticate, what shape your output can take, and who owns the surface you ship on.

For the engineering lead choosing a delivery surface, and the buyer wondering why it matters. 7 minute read.

The portal nobody opens

The obvious build is a web application. Upload a contract, get a report. It is easier to build, easier to deploy, easier to instrument, and it works on every device.

It also requires a lawyer to leave the document they are working in, go somewhere else, and come back. Every review. For a tool meant to save time, the first thing it does is add a context switch.

Adoption is where AI tools die, and adoption is mostly friction. A reviewer under time pressure will skip the extra step and read the contract the way they always have, and the product's value never gets tested because the product never gets used.

Shipping inside Word inverts that. The tool arrives in the application already open, on the document already being read. There is no step to skip, because there is no separate destination.

What in-place delivery actually is

The output is not a report beside the document. It is the document, annotated — risky clauses highlighted where they sit, each carrying a risk level, a justification and a suggested revision, with findings streaming in as the pipeline produces them.

That last part matters more than it sounds. A review that takes minutes and returns everything at the end is a progress bar. One that highlights clauses as they are assessed lets the reviewer start reading immediately, and the remaining wait happens behind work they are already doing.

And the marks are in the document's own idiom. A lawyer already reads contracts by annotation. The tool is not asking them to learn a new interface — it is producing more of something they already consume.

It forces your authentication model

Here is the first cascade, and it catches teams late.

An Office add-in runs in an embedded browser frame. Session-based authentication — the default for almost every web application — does not work reliably there, because the frame does not share cookie context with a normal browser session the way the rest of your stack assumes.

So authentication becomes token-based, and that is not a preference. Our own build records it exactly that way: token-based authentication in the add-in, explicitly not session-based, because of the frame.

The consequence is architectural rather than cosmetic. Tokens have to be issued, carried, refreshed and validated on every call, and the frame's lifecycle is not yours to control — the host application decides when it reloads. A design that assumed a durable session has to be reworked, and it is usually discovered after the interface is built rather than before.

The general lesson: a delivery surface has an auth model attached to it. Choosing where the product lives chooses how it authenticates, and that is worth knowing on day one rather than in week six.

It forces your output format

The second cascade is the one covered in the chapter on deduplication, and it is worth restating from this side.

In a portal, overlapping findings are rows in a list. Ugly, but survivable — a reader can scroll past them.

In the document, overlapping findings are overlapping highlights on one sentence. Four specialists reporting the same clause produce four marks on the same text, and the result is a document that is harder to read than the unannotated original. The tool has damaged the artefact the lawyer came for.

So the merge cannot be a rendering concern. By the time a finding reaches the interface it is already a mark on the page — the convergence has to happen upstream, in the pipeline, while the findings are still data. The delivery surface reached back and changed a decision three stages earlier.

What you give up

The platform owns your surface, and you inherit its constraints. Its rendering model, its performance envelope, its lifecycle, its versions. When the host changes, you change — on their schedule rather than yours.

Your users' environments are more varied than a browser's. Desktop, web and different release channels behave differently, and a lawyer's machine is frequently a managed one where the add-in has to be approved centrally before anyone can install it.

Distribution is somebody else's process. A web application ships when you deploy. An add-in reaches an enterprise when their IT function permits it, which is a sales-cycle problem rather than an engineering one.

And you cannot iterate on the interface as freely. A web front end can be redesigned this afternoon. A surface embedded in someone else's application is constrained by what that application allows, and by what its users expect it to look like.

The trade is real. It buys the only thing that matters more than iteration speed — being used.

When not to do this

If the reviewer is not already in the document, the argument collapses. A procurement team processing a queue of contracts from a system of record is not sitting in Word — they are in a workflow tool, and meeting them there means a different surface entirely.

If your output is a decision rather than an annotation, a document is the wrong container. Approve or reject does not want to be a highlight; it wants to be a record somewhere auditable.

And if you are still learning what the product is, ship the portal first. It is faster to change, and the point of an early build is to find out what the output should be — a question best answered somewhere you can rewrite the interface weekly.

In-place delivery is a commitment to a workflow you already understand. Making it before you understand it is expensive.

What we would build, and the check for Monday

How we build it. Treat the add-in as a rendering surface over an API that also serves everything else, so the same pipeline can feed a portal, a workflow integration or a bulk path without rework. The surface should be replaceable; the pipeline should not have to be.

Status, stated plainly. This is a system we built. It runs, it is demonstrable on a call, and it has zero delivered engagements. We build these on request, against your systems and your documents. No number here describes anyone's business but our own.

The check worth running, and it needs nothing from us. Ask where your users are when they need your output. Then ask how many actions it takes them to get from there to it. If the answer is more than zero, that gap is your adoption problem — and no amount of model quality closes it.

About Cognilium Cognilium is an AI engineering company — agent systems, retrieval, knowledge graphs, voice AI and the production plumbing that makes them survive contact with real workloads. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Want to know whether your surface is costing you adoption? Book a 15-minute call — we will walk the workflow with you, on your users' actual process. No deck.

Sources

This article draws on our own build. The deduplication consequence described in §4 has its own chapter.