The Litigation Workbench

Executive Summary

LegalPresence began as a monitor of official court postings that extracts and structures legal information. It has since grown a working litigation reasoning console: a set of role-specific AI seats (lead counsel, opposing counsel, the presiding justice, the client advisor) that answer questions grounded in the live case record, then run every answer through a verification gate before it is shown.

The Workbench turns that console into a complete product. It keeps the discipline that makes the current system trustworthy — nothing is asserted that the record does not support, and nothing reaches a human un-reviewed — and wraps it in the full litigation lifecycle: intake, docket watch, evidence collection, timeline and deadline management, collaborative analysis, and client reporting, all as native objects and views inside Twenty CRM.

What already exists shipping today

The differentiators below are not aspirational — most are running in production and simply need to be productized. This spec is explicit about the state of each so the roadmap is honest.

Key differentiators

Personas & User Journeys

Core workflow — question to gated answer

flowchart LR
  A[Attorney asks
from a seat] --> B[Assemble substrate
docs · markups · graph · rules]
  B --> C[Reasoning Engine
element map · counterfactuals]
  C --> D{Gate-Counsel}
  D -->|grounding · perturbation| E[Verdict + score]
  D -->|privilege / overconfidence| E
  D -->|rule compliance| E
  E --> F[Answer shown
with citations + flags]
  F --> G[Attorney accepts,
edits, or overrides]
  G --> H[Saved to CRM
as aiAnalysis + audit]

Second journey — evidence intake to insight

flowchart LR
  A[Drop docs /
docket pull] --> B[OCR + encrypt]
  B --> C[Store ciphertext in R2
DEK in SecureVault]
  C --> D[Hash-stamp +
evidenceItem in Twenty]
  D --> E[Ontology extraction
fact-assertions + RDF]
  E --> F[Human review
APPROVE / REJECT]
  F --> G[Enters the substrate
every seat can now cite it]

Functional Requirements

3.1 Docket & court-posting monitoring evolve

• Poll official sources (NYSCEF and equivalents) on a schedule; diff against the last snapshot; open a timelineEvent for every new filing.
• Classify each posting (order, motion, affirmation, notice) and route to the right matter by index number.
• Alert owners on filings that touch a tracked deadline or the enjoined subject-matter.

3.2 Evidence collection & ontology markups live

• Ingest pipeline: OCR → encrypt → object store (ciphertext) → data-encryption key in the vault → content hash-stamp → evidenceItem in Twenty.
• Ontology extraction produces factAssertion rows — the machine-readable markup layer over each document (who / what / when / affected party / source doc).
• Every assertion carries a reviewStatus (HUMAN_VERIFIED, COUNSEL_APPROVED) and a confidence; only reviewed assertions are treated as settled in reasoning.

3.3 Knowledge-graph management live

Parties, legal persons, correspondents, property units, and artifacts live as an RDF graph (parsed from the ontology + per-matter instance TTL). Relationships — counselFor, ownerOf, plaintiffIn, authoredBy, custodianOf — are queryable and visualized. The graph is both a browsing surface and a reasoning input.

3.4 AI Reasoning Engine evolve

A structured reasoning layer that operates under the six litigation objectives and thirteen house rules, not free-form. Capabilities:

3.5 AI Internal Gate-Counsel evolve

An adversarial reviewer that runs on every answer before a human sees it. It annotates and scores — it does not silently rewrite. Three independent controls plus a single honest verdict:

3.6 Calendar, deadlines & lifecycle live

• Return dates, answer dates, and CPLR-computed deadlines as CRM caseDeadlines with path-ICS export and reminders.
• Procedural clock · dependency DAG — HARD_BLOCKS propagates risk; Next 3 actions with Assign owner (responsibleRole).
• Stage tracking across the full lifecycle: pre-litigation → pleadings → motion practice → discovery → hearing → resolution → appeal.
• Deadline changes propagate: an adjournment moves the dependent dates and notifies owners.

3.7 Collaboration & client portal build

• Shared matter workspace with role-scoped visibility; internal work product never leaks to the client view.
• Client portal: plain-language status, gated for over-promising, with a documented approval step before anything is sent.
• Every mail-out goes through an admin-approval gate and a faithful audit log.

3.8 Research & adversary intelligence live

• Ranked precedents. Candidate authorities are surfaced against the matter's posture and ranked by relevance and interest.
• Verified vs candidate, on every row. Each authority is badged Verified · on file (a real opinion held in the register) or Candidate · verify (model-surfaced, unconfirmed). An unverified citation never passes as usable authority.
• Adversary profiles. Opposing-party litigation history and prior-matter patterns — for strategy, settlement posture, and vexatious-litigant analysis.
• Charted in the case graph. Every imported precedent is emitted as a PrecedentCase node carrying citation, court, holding and the issue it bears on, linked to the matters it was imported for; the Obsidian export renders it as a navigable graph with node labels on hover.
• Suggested element support. Where a precedent's posture maps to a statutory element on the record (vacatur / fraud → CPLR §5015(a)(3); spoliation → CPLR §3126), the graph carries a suggested precedent→element edge, flagged for counsel confirmation rather than asserted as settled.

Paper Workbench — shipped product surface

The live Litigation Workbench is the paper-command seat for a CRM draft (aiAnalysis). CRM is source of truth; Word/Google Docs is a handoff via clean DOCX — not a second SoT. Studio path: /studio/workbench?id=<draft> (counsel-gated on crm.legalpresence.com). This public page is the product specification only — no case data.

Partner jobs on the page live

Markup discipline

• Structured tags only: [[LP:NOTE]], [[LP:PIN evidence=… page=…]], [[LP:SIGNOFF role=…]], approval stamps. Markdown ** is not used for comments — it breaks emphasis and filing-clean.
• Fact pins link a sentence to an evidence id + page for the evidence rail.
• Every Save that changes the body snapshots a CRM version first.

What is deliberately not on this public URL

The interactive Workbench editor, Command home, and Discover run under counsel auth on crm.legalpresence.com. legalpresence.com/studio/workbench-spec is intentionally un-gated and carries no matter record.

Technical Architecture

4.1 The substrate assembler

Each question triggers a fail-safe assembler that fuses four stores into one context. Any single store can be slow or down and the answer still returns — the section is simply skipped and labelled.

flowchart TB
  Q[Question + persona seat] --> ASM[Substrate assembler]
  subgraph S[Four grounded stores]
    D[Documents
semantic RAG over corpus]
    M[CRM markups
fact-assertions via GraphQL]
    G[Knowledge graph
RDF nodes + relations]
    R[Rules engine
objectives + house rules]
  end
  ASM --> D & M & G & R
  D & M & G & R --> CTX[Fused context
+ governance dump]
  CTX --> LLM[Reasoning Engine]
  LLM --> GATE[Gate-Counsel]
  GATE --> OUT[Answer + citations + verdict]

4.2 Reasoning Engine & Gate-Counsel

flowchart LR
  CTX[Fused context] --> GEN[Generate answer
thinking-budget managed]
  GEN --> CLM[Decompose into
atomic claims]
  CLM --> P1[Perturb ×K] --> SC[Grounding +
stability score]
  GEN --> QA[Counsel-QA
hostile pass]
  GEN --> AUTH[Authenticity
citation resolve]
  SC & QA & AUTH --> V[Single honest verdict
clean · flagged · unreviewed]
  V --> UI[Rendered with
badges + links]

4.3 Thinking-budget management

4.4 Twenty CRM data model

The Workbench is expressed as custom objects so it inherits Twenty's views, permissions, relations and audit. Content differs per matter; the schema is identical across all.

erDiagram
  matter ||--o{ evidenceItem : holds
  matter ||--o{ motion : has
  matter ||--o{ caseTheory : advances
  matter ||--o{ timelineEvent : schedules
  evidenceItem ||--o{ factAssertion : yields
  factAssertion }o--o{ caseTheory : supports
  motion ||--o{ aiAnalysis : reviewed_by
  caseTheory ||--o{ aiAnalysis : scored_by

4.5 Citation linker & perturbation — near-term improvements

4.6 Self-hosting & security

• Ciphertext at rest in object storage; data-encryption keys isolated in a dedicated vault; documents never stored in plaintext.
• Per-workspace isolation in Twenty; the AI substrate is scoped to the active matter and never imports another matter's facts.
• All model keys are vault-sourced and injected at runtime; services fail loud on a missing secret rather than degrading silently.

Design Concepts & UX

The interface is timeline-centric and evidence-first. The spine of every matter is its chronology; everything else — a document, an assertion, an AI analysis — hangs off a point in time and is one click from its source.

Non-Functional Requirements

Roadmap & Implementation

gantt
  dateFormat YYYY-MM-DD
  axisFormat %b
  section MVP
  Harden substrate + gate      :a1, 2026-07-20, 40d
  Package Twenty extension     :a2, after a1, 30d
  section Phase 2
  Reasoning Engine             :b1, after a1, 55d
  Gate-Counsel (privilege/ethics):b2, after a2, 45d
  Per-claim review UI          :b3, after b1, 30d
  section Phase 3
  Docket + deadline engine     :c1, after b2, 45d
  Timeline canvas + portal     :c2, after b3, 50d

Risks, Dependencies & Success Metrics

Risks & mitigations

Success metrics