How it works

No guesswork. A pipeline you can audit.

Vern doesn't hand your contract to a model and hope. It runs fixed stages in a fixed order, records the exact document and playbook version it used, and anchors every finding to the characters it came from. Same input, same output, check it yourself.

Intake
Three lanes, one version
Engine
Four fixed stages
First results
Seconds, then upgraded
Every finding
Anchored to characters
Step 01 · intake

However it reaches us, it becomes the same thing.

Parsing is a fallback, not a platform. DOCX is read properly so redlines can go back properly.

LANE 1 · DOCX
Read as OOXML

The primary contract format, parsed locally. Clause numbering and structure survive, and we keep a map from the extracted text back to the ranges in the file, which is what makes true tracked-change write-back possible.

LANE 2 · PDF
Text layer, then read

Born-digital PDFs give up their text layer locally; the model reads the document natively as the semantic layer on top. No screenshot-and-guess.

LANE 3 · SCANNED
OCR, EU endpoints

A photographed or scanned contract goes through OCR before anything else. The vendor sits behind a small interface and runs on EU endpoints only.

The same contract is never analysed twice by accident.

Every lane ends the same way: the text is normalised and hashed, and that hash is the version. Upload the file your colleague already emailed in and it resolves to the version that exists, findings appear instantly and no credit is spent. Change one word and it's a new version, and a follow-up round.

Web upload → 8f3a92c
Email attachment → 8f3a92c
Word add-in → 8f3a92c
API call → 8f3a92c
ONE VERSION · FOUR WAYS IN · ONE CREDIT
Step 02 · the engine

Four stages, in this order, every time.

Not an agent deciding what to do next. Code decides the order; the model does the reading and the judging. Pick a stage.

CODE-ORCHESTRATED · NOT FREE-ROAMING
Stage 02 · score
Both scores, produced together

Each clause is judged against your playbook position and, separately, against whether it would hold up under UK law. One pass, two independent answers, which is why they are free to disagree. Answers come back through an enforced schema, so a malformed score fails rather than quietly becoming a wrong number.

OUTPUT · PLAYBOOK 0–100 + BAND · VERN STRONG/CAUTION/WEAK
3.1 Fees & rebate schedule 88
5.2 Payment terms 54
8.1 Limitation of liability 12
Strong Strong Weak

8.1 breaches your position and would not hold up. 5.2 breaches your position and is perfectly enforceable. Different problems, different responses.

Step 03 · while you wait

First verdicts in seconds. Then they get better.

A fast triage pass streams preliminary verdicts into the screen almost immediately, so you can start reading. The deep pass follows and upgrades each finding in place, you never sit in front of a spinner, and you're never shown a number that turns out to be provisional without being told.

Nothing polls. Progress is an event stream every surface subscribes to, so the dashboard, the Word pane and the API client all see the same run advance at the same moment.

Clause list on screen 4s
Triage verdicts complete 19s
Deep review, all 18 clauses 2m 47s
Credit consumed on delivery
A REAL 18-CLAUSE TERMS OF BUSINESS · FIGURES VARY WITH LENGTH
Step 04 · what you can check

Every finding has a receipt.

This is the part a general-purpose chatbot cannot give you. Not because the model is worse, because nothing around it is recorded.

Anchored to characters

A finding stores the offsets it was drawn from. Click it and you land on the words in your document. There is no Vern finding that can't be traced to a sentence.

One row per clause

Findings are records, not a blob of text: classification, both scores, impact, suggested wording, fallback tiers. Queryable, exportable, diffable.

Versioned on both sides

A run records the document version, the playbook version, the model and a hash of the prompts. Edit a position tomorrow and last month's review still says what it said.

Reruns never overwrite

Re-analysing produces a new run beside the old one, free of charge. Compare them. If a model upgrade changes a verdict, you can see exactly where.

Structured, not parsed

Scores come back through enforced schemas rather than text we hope to read correctly. A malformed answer fails loudly instead of quietly becoming a wrong number.

A human can sign it off

Escalate to expert review and a qualified reviewer's revision sits over the AI run as an overlay. The original is never mutated, and every reviewer action is logged.

A run is exactly this run = f(documentVersion, playbookVersion, model, promptsHash) Four inputs, nothing hidden. Hold them steady and you get the same review every time.
Step 05 · after the review

Then it's a negotiation,
not a report.

Everything below sits on the same record, so nothing has to be reconciled afterwards.

01 Push back Apply a position from your playbook as a real Word revision, or export a DOCX redline built from genuine OOXML insertions and deletions. Their counsel accepts or rejects it like anyone else's.
02 Ask about it Ask Vern fetches the clause and your position with tools before it answers, so it is reading the contract rather than a summary of it. Threads persist against the matter.
03 Take the next round Their redline comes in as the next version of the same matter. Vern re-scores and shows the deltas, improved, worse, unchanged, new, at a fraction of a credit.
04 Learn from it Vern records which of your fallback positions the other side actually accepts, and tunes which wording it offers first. Your playbook gets better because you used it.

Run it on a contract you already know the answer to.

That's the honest test. Thirty minutes, your playbook, a contract you've already negotiated, and see whether we'd have caught it.