Evidence & Discovery Analyzer

Documents in. Coded. Privilege log out. Nothing to remember, nothing to lose.

Slice I of the Sciolto-flavored legal-services vertical. Where the Litigation module (slice H) handles the phase stepper and deadline calendar, this one handles the *document universe* — intake, review coding, privilege log generation, production set assembly. The eDiscovery review half of the vertical.

Deliberately deterministic. No LLM at query time, no LLM at coding time. Two guardrails at coding, one derivation query for the privilege log, one join for the discovery dashboard. LLMs enter slice J (case theory + auto-drafting), not here.

The three views

Review queue — every document across every case with its latest coding state. Filterable by coding state (reviewed / unreviewed), responsiveness, hot-only, and keyword substring. Inline *Code* / *Re-code* actions per row. Uncoded docs get a primary-color button; coded docs get a ghost re-code button.

Privilege log — pick a case, see its exportable privilege log. Every doc with the latest coding where privilege ≠ not_privileged, joined with the doc metadata columns the log needs (bates, date, author, recipients, subject, privilege, basis).

Discovery dashboard — per-case rollup: ingested / coded / uncoded / responsive / privileged / hot / production sets. One row per open case, one call. The single view that tells a solo how their document universe looks across every open case.

The two coding guardrails

Every reviewer decision writes a fresh ReviewCoding record — the most recent one wins, older ones stay as history. Two constraints fire at write:

1. Privileged documents require a basis

RULE privileged_document_requires_basis {
  WHEN coding.privilege != "not_privileged"
  AND  coding.privilege_basis is empty
  THEN REFUSE with "privileged_document_requires_basis"
  PRIORITY 100
}

A privilege log without a basis column is not a privilege log — it's a mistake. Opposing counsel will move to compel and the court will not be pleased. The UI hides the basis field when privilege = not_privileged and reveals it (required) as soon as any privilege type is chosen.

2. Hot documents require notes

RULE hot_document_requires_notes {
  WHEN coding.hot_document == true
  AND  coding.notes is empty
  THEN REFUSE with "hot_document_requires_notes"
  PRIORITY 100
}

A hot document without notes is useless — you'll pick it up during deposition prep three months later and have no idea why past-you flagged it. The reviewer explains what makes it hot; the audit log preserves that reasoning forever.

Production guardrails

add_document_to_production refuses at three points:

• Production already produced — no further additions once the set is closed.
• Document not coded — can't produce what hasn't been reviewed.
• Document coded as privileged — privileged docs cannot be produced. The privilege log exists so they *don't* accidentally go out with the responsive set.
• Document coded as non-responsive — non-responsive docs cannot be produced. Same reason.

The guardrails compound: the reviewer's coding decisions become the *literal* filter on what leaves the firm.

Deterministic search

The keyword search does substring matching across five columns (title / author / recipients / subject / extracted_text) with hit-count ranking and a snippet return per match. It's the slice-I baseline. Embedding-based conceptual search — the "conceptually similar documents" story — lands as an upgrade later; the return shape is unchanged either way (document id + snippet), so the tool caller doesn't move when we swap the engine.

What's wired

| Entity | Purpose | |---|---| | EvidenceDocument | The doc itself — bates, custodian, source, author/recipients, extracted text, sha256 for dedup | | ReviewCoding | Reviewer's per-doc decision, versioned (most-recent-wins), history preserved | | ProductionSet | A bundle of coded docs prepared for production, with bates prefix + document count |

Tools (9): list_evidence_documents, ingest_evidence_document, code_evidence_document, list_review_coding, privilege_log, create_production_set, list_production_sets, add_document_to_production, discovery_dashboard.

What's NOT in this slice

• AI-suggested coding — the "GPT-suggests, reviewer confirms" pattern. Slice J or later — needs prompt engineering, human confirmation gates, and a way to flag the model's confidence.
• Embedding-based conceptual search — same shape as slice I's keyword search, just a smarter backend. Upgrade in place.
• AI-generated document summaries at ingest — for review-speed. Slice J.
• Redaction tooling — the coding record has a redactions_needed flag, but actually applying redactions to PDFs is separate infrastructure. Save for a later slice.
• Cross-matter learning — training a TAR-like classifier from past reviewer decisions. Deep AI work; unclear demo value; save.

The point of slice I is *defensible workflow*, not clever AI. The AI story goes on top of a workflow that already works.