Technology

Every file I take in becomes rows in a database, not a folder of PDFs. A search engine reads those rows by word and by meaning, and an AI assistant answers your questions from them, citing the exact page every time. Nothing about how it works is a secret; this page walks the whole stack in order, from the moment a file arrives to the moment you get an answer, then goes deep for the technical reader.

The pipeline

Source. Your file arrives, digital or scanned, and every page is hashed and counted so nothing can go missing or get reordered.

OCR. Amazon Web Services reads every page the way a person would, putting a confidence score on every word. The result is a real text layer laid over the original image, never replacing it.

Database. The text is split into small, indexed pieces inside a PostgreSQL database, one private schema per matter, running on Amazon Web Services or Google Cloud.

Search. A hybrid engine searches those pieces by word, by phrase, and by meaning at once, then a second pass re-ranks the results so the most relevant pages come first.

Assistant. A command-line AI assistant answers your question from the search results, citing the document and page it came from, and nothing else.

Database

PostgreSQL 18, with pgvector for vector search (HNSW index, cosine distance), pg_textsearch for BM25 scoring, pg_trgm for fuzzy trigram matching, and pgcrypto. Every matter gets its own schema (case_<slug>), never commingled with another client's data, another matter, or any shared corpus.

Data model

Core tables: source_files (sha256 hash, page count, Bates range), documents, pages, and document_chunks. Chunks run about 1,000 characters with roughly 150 characters of overlap between them, embedded locally into a 384-dimension vector, and indexed three ways at once: HNSW for vector similarity, a GIN index over a tsvector column for full-text search, and BM25 for term-frequency ranking.

Retrieval

A hybrid search function runs all three index legs (BM25, vector, trigram) and combines their rankings with reciprocal rank fusion, so a query does not depend on one method alone. At Level 2 and up, a cross-encoder reranker re-scores a wide candidate set (thousands of chunks) down to the most relevant few before the assistant ever sees them: retrieve deep, filter, then rerank. This is deliberately not a single embedding lookup; a bare vector search alone misses too much, and a bare keyword search misses paraphrase and meaning.

Ingest

A file-walking pipeline hashes every source file, runs it through OCR (Amazon Web Services, an engine trained on millions of documents with a confidence score per word, HIPAA eligible for medical records), chunks the extracted text, and embeds it, with guarded checks against re-ingesting a file that has not changed. OCR text is kept as a layer alongside the original page image; the original is never altered.

Assistant

A command-line AI assistant configured with a retrieval skill that calls the hybrid search function, a Bates-number lookup, and date-range queries, plus a matter-level instruction file that states the schema, the citation rule (every answer names its document and page), and a strict read-only posture against the database. It connects to the enterprise AI service your firm already trusts: safe, reliable, no service calls. A dedicated local server is available separately for firms that want one; see AI server builds.

Entity, timeline, and evidence layers (Level 2 and up)

An entity table with role labels and aliases; a per-document, per-chunk presence count so you can see where a name actually appears; an events table keyed to date, actor, and source page for chronology queries; and a Bates-numbered evidence manifest with collision checks, so a page number always resolves to exactly one page.

Agent memory (Level 2 and up)

A memory store that lets the assistant carry confirmed facts, corrections, and open questions across sessions, so your team is not re-explaining the case each time. Every retrieval is logged to a query-audit table, so there is a record of what was searched and when.

Authority corpus (Level 3)

The practice-area law is loaded into a parallel schema, chunked and embedded to the same shape as the evidence: Oregon statutes with full section text, administrative rules, UTCR and supplementary local rules, appellate opinions with full opinion text, Attorney General opinions and orders, bench books, and forms. A unified view unions the matter schema and the authority schema into one search, so a query can return a record and the statute behind it in the same answer. Citation-checking tooling verifies that any drafted text citing the authority pack is actually backed by a loaded source.

Delivery

A pg_dump custom-format archive of the schema, an install.sh script that creates the database role and extensions, restores the dump, and verifies chunk counts against the manifest, and a page-count and hash manifest you can check against what you sent. The assistant connects through a read-only database role.

Hosted (retained) isolation

Each retained matter runs in its own PostgreSQL cluster or, at minimum, its own schema, excluded from every shared view, index, and memory scope. No client's data is ever reachable from another client's search, by design, not by convention.

What it runs on

Level 1: any modern workstation, 16 GB of memory, an SSD. Level 2 and 3: the same, with a mid-range graphics card recommended for the reranker; it works without one, just slower. Built on Amazon Web Services and Google Cloud; no other cloud or AI vendor is part of this stack. The assistant connects to the enterprise AI service the firm already uses; no local model or separate subscription is required unless the firm wants a dedicated AI server (see AI server builds).