AI Contract Review Workspace

Product thesis

In-house legal teams drown in routine paper: NDAs, DPAs, vendor terms, order forms — contracts that are ninety percent standard and dangerous in the remaining ten. First-pass review of these is largely pattern work: find each clause, compare it to what the company has decided it will accept, note what differs. That decided position is the playbook, and it usually lives in one senior lawyer’s head. This concept puts the pattern work in software and keeps the judgment where it belongs. The working principle, stated once and enforced everywhere: the tool drafts questions, the lawyer draws conclusions. It is explicitly not a law firm replacement, gives no legal advice, and never renders a verdict on whether anything is safe to sign.

Who it serves

• In-house legal teams at mid-size companies — the two-lawyer team facing a forty-contract month
• Procurement and ops teams doing pre-legal triage on inbound paper
• Sales operations, where counterparty-contract turnaround time is deal velocity

The problem, concretely

• Routine contracts queue behind important ones; turnaround slips from days to weeks
• First-pass review is mostly locating clauses and recalling positions — expensive attention spent on retrieval, not judgment
• “What we accept” is institutional memory, unevenly distributed and unversioned
• The same deviation gets renegotiated from scratch because last quarter’s disposition is buried in a redline nobody can find
• The expensive failure is silent: a missed deviation surfaces at renewal, or in a dispute

The playbook is the product

The central design object is not the AI — it is the customer’s own playbook: for each clause type, the preferred position, acceptable fallbacks, walk-away triggers, and the rationale behind them, versioned and owned by the legal team. Every comparison the system makes is against this document, so the tool encodes the company’s judgment rather than substituting its own. Deviation severity comes from the playbook’s rules, deterministically — not from a model’s opinion of what matters. Building the playbook is the onboarding: the workspace proposes draft entries from past executed contracts and redlines, and the team approves each one, which doubles as the moment institutional memory becomes an asset instead of a retirement risk.

Product strategy

1. Extract and compare, never conclude. Output is flags and drafted questions. Each flag shows the clause as found, the playbook position, the difference — and citations into both documents.
2. Citation or silence. An uncited claim anywhere in the product is a defect, treated with the same severity as a crash.
3. The queue is the surface. Reviewers work a severity-ordered deviation queue, not a chat window; the interaction model is disposition, not conversation.
4. A clean pass is still a claim, not an assurance. “No deviations found against playbook v12” is presented as exactly that — a scope-limited machine statement that a human still signs.

Core review journey

1. Contract in counterparty paper, any format, versioned
2. Clauses extracted and typed DOCX, PDF, scans
3. Playbook comparison deviations flagged, cited on both sides
4. Reviewer works the queue accept, dismiss, escalate — with reasons
5. Negotiation questions drafted editable, grounded in flags
6. Lawyer signs the review full disposition record attached

Major features

• Clause extraction and typing across formats, including scanned counterparty paper
• Playbook editor: positions, fallbacks, severity rules, rationale — versioned, exportable, unambiguously the customer’s property
• Deviation queue with side-by-side citation view: contract text and playbook position, both highlighted at the exact passage
• Absence detection: clauses the playbook requires that the contract simply lacks — the hardest and most valuable flag, surfaced with its own confidence treatment
• Drafted negotiation questions per flag, edited or discarded by the reviewer
• Disposition memory: how this team resolved this same deviation before, retrieved with its context
• The review record: every flag’s disposition, exportable as an audit trail of the review

Where AI fits — and the line

Extraction, clause typing, semantic comparison against playbook positions, absence detection, question drafting, and retrieval over past dispositions. All of it is generation constrained to cited material; none of it is evaluation of legal risk.

The line holds even when it is inconvenient: no “this is fine to sign”, no risk scores dressed as analysis, no auto-approval path for clean contracts. A contract with zero flags still crosses a lawyer’s desk, because the alternative — trust accreting silently onto the machine — is precisely the failure mode this design exists to prevent.

Confidentiality architecture

Contracts are among the most sensitive documents a company holds, and legal buyers audit accordingly:

• Tenant isolation with encryption at rest and in transit; EU residency as a deployment option
• No training on customer contracts or playbooks, contractually and architecturally
• Model inference inside the controlled boundary; no contract text in third-party logs
• Access mirrors matter structure: deal teams see their deals, and nothing widens by default
• Retention aligned to matter lifecycle; deletion that provably includes derived indexes
• The disposition record double-books as the audit trail security reviewers ask for first

Evaluation plan

Recall is the headline metric, because the missed deviation is the expensive failure:

• Recall on known-deviation test sets — seeded contracts with labeled deviations per clause type, built from public templates with synthetic modifications
• Absence detection measured as its own track, with its own labeled set
• Precision tracked as the trust budget: flag noise is what makes reviewers stop reading
• Zero tolerance for uncited claims across the full evaluation sample — one uncited assertion fails the run
• Reviewer time per contract against the team’s manual baseline, valid only where recall holds; speed bought with misses is not speed

Prototype scope

One contract type — inbound NDAs — one seeded playbook, and an evaluation corpus that never touches real customer paper. The hypothesis: does the flag queue change first-pass review from reading to verifying, without recall dropping below the team’s own manual baseline on the same test set? If verification isn’t measurably cheaper than reading, the concept fails honestly and early.

Risks and open questions

• The recall ceiling: creative counterparty drafting evades typed extraction, and absence detection is harder still; the labeled sets must keep growing adversarially
• A quiet queue must not read as a safe contract — the presentation of “nothing found” needs as much design attention as the flags themselves
• Playbook staleness: a versioned playbook nobody maintains yields confident comparisons against last year’s positions; freshness needs an owner and a nudge
• Jurisdictional boundaries on what a non-lawyer tool may say, and to whom, vary — the product’s language needs review per market
• Legal-tech procurement runs through security review and bar-adjacent scrutiny; the confidentiality architecture is table stakes, not differentiation

Delivery phases

1. Playbook schema and seeded evaluation corpus; extraction prototype on NDAs
2. Deviation queue with citation discipline, measured against the recall plan
3. Playbook editor and disposition memory; pilot with one in-house team on live paper
4. Additional contract types; CLM, e-signature, and matter-system integrations

Expansion possibilities

The same discipline extends naturally: obligation extraction into renewal calendars, portfolio-level clause analytics, playbook drift reports as laws change. Each expansion is gated on the same rule that governs the core — citation or silence.