Do you want to review thousands of documents?

Document Review Workflow

I. Initial Rules

1. Before starting, review the entire workflow below, step by step, and ask the user if there is any ambiguity.
2. CRITICAL: Strictly follow every single step below. Do not skip a step.
3. Auto-execute the next step.
4. CRITICAL: Apply the chunking rule as you do all of this.
5. When generating implementation plans, set RequestFeedback: false.
6. This workflow processes documents ONE AT A TIME. Never batch-process documents. Read one, analyze it fully, insert it into the database, then move to the next. This is non-negotiable.

II. Discovery Interview

1. Create a folder (e.g., 012_doc_review_case_name) following global folder rules.

2. CASE INTAKE: The user will describe a legal matter. Your job is to extract enough information to build a comprehensive coding framework — the list of every claim, defense, and factual issue that each document will be scored against.

   2a. Ask the user to describe the case: who are the parties, what happened, what is the procedural posture (pre-suit, active litigation, appeal), and what jurisdiction.

   2b. Ask the user to identify ALL claims being asserted (e.g., defamation, breach of contract, fraud). For each claim, identify the specific legal elements that must be proved under the applicable law. Be precise — cite the elements from the governing statute or leading case in the jurisdiction.

   2c. Ask the user to identify ALL affirmative defenses that the opposing side has raised or is likely to raise (e.g., truth, statute of limitations, qualified privilege, waiver, laches, consent). For each defense, identify the specific legal elements that must be proved.

   2d. Ask the user to identify any additional factual issues that are not tied to a specific element but are important to the case (e.g., credibility of a key witness, timeline of events, chain of custody, existence of a particular agreement). These become their own scoring categories.

   2e. Have at least two back-and-forths with the user to stress-test completeness. Ask: "Is there any claim, defense, or factual issue that I have not listed?" Push hard on this — a missed issue means thousands of documents will not be scored on it, and the entire review would need to be re-run.

3. CODING FRAMEWORK: Compile the complete list of scoring categories into a single master document. Each category must include:

   • A unique ID (e.g., C1, C2 for claims; D1, D2 for defenses; F1, F2 for factual issues)
   • The category name (e.g., "Defamation — Element 2: Statement was false")
   • A plain-English description of what kind of document content would score high on this category
   • The legal standard (what the law requires to prove this element) Save as 00_coding_framework.md.

4. GRADING SCALE: For each category, determine an appropriate grading scale based on the nature of that element. The number of levels and the descriptions should reflect what actually makes sense for that particular claim, defense, or factual issue. As an example, a typical 1-6 scale might look like this:

   • 1 = Irrelevant. No connection to this category.
   • 2 = Tangentially related. Mentions a relevant person, date, or topic, but does not address the element.
   • 3 = Somewhat relevant. Contains information that is indirectly related to the element but does not prove or disprove it.
   • 4 = Relevant. Contains information that bears directly on the element, but is not dispositive.
   • 5 = Highly probative. Strong evidence that directly supports or undermines this element.
   • 6 = Smoking gun. This document alone could be outcome-determinative on this element. But you should adapt this — some categories might need fewer levels, some might need different descriptions. Use your judgment. Document the chosen scale for each category and append all scales to 00_coding_framework.md.

5. PAUSE 1 (GATED APPROVAL): Stop execution. Present the full coding framework to the user. Ask: "Does this cover everything? Is there any claim, defense, or factual issue missing? Is the grading scale acceptable?" Do not proceed until the user approves.

III. Database Setup

1. DATABASE FORMAT: Create a database to store all document analysis results. SQLite (doc_review.db) is recommended because the agent can create and query it directly, but any structured format works (JSON, CSV, etc. — whatever the user prefers). The key requirement is that the data must be searchable, sortable, and filterable.

   1a. NOTE FOR NON-TECHNICAL USERS: A SQLite database is just a single file on your computer. You do not need to install anything to create it — the agent handles that. To view or search it later, you can use free tools like DB Browser for SQLite, or you can simply ask Antigravity to query it for you (e.g., "show me all emails from the defendant's CEO that scored above a 4").

2. Create the following tables (or equivalent structure if using a non-SQL format):

   2a. categories table:

   • id (TEXT, primary key) — the unique ID from the coding framework (C1, D1, F1, etc.)
   • type (TEXT) — "claim", "defense", or "factual_issue"
   • name (TEXT) — the category name
   • description (TEXT) — what to look for
   • legal_standard (TEXT) — the legal test

   2b. documents table:

   • id (INTEGER, primary key, autoincrement)
   • filename (TEXT)
   • file_format (TEXT) — pdf, image, text, email, etc.
   • page_count (INTEGER, nullable)
   • date_of_document (TEXT, nullable) — the date on the document itself, if identifiable
   • author (TEXT, nullable) — who created or sent the document
   • recipient (TEXT, nullable) — who received the document
   • document_type (TEXT) — e.g., "email", "contract", "invoice", "letter", "memo", "text message", "photo", "handwritten note"
   • summary (TEXT) — a 2-4 sentence summary of the document's contents
   • key_quotes (TEXT, nullable) — verbatim quotes from the document that are particularly important
   • processed_at (TEXT) — timestamp of when this document was analyzed

   2c. scores table:

   • id (INTEGER, primary key, autoincrement)
   • document_id (INTEGER, foreign key → documents.id)
   • category_id (TEXT, foreign key → categories.id)
   • score (INTEGER) — per the grading scale defined for this category
   • reasoning (TEXT) — 1-3 sentences explaining why this score was assigned
   • relevant_excerpt (TEXT, nullable) — the specific passage in the document that supports this score

3. Populate the categories table from 00_coding_framework.md.

4. Save the database schema and setup confirmation to 01_database_schema.md.

IV. Document Source Configuration

1. Ask the user where the documents are located (folder path).
2. Scan the folder recursively. Count total files and list all file formats found.
3. Report the inventory to the user: "I found X files in Y formats (PDF, JPG, DOCX, TXT, etc.). Shall I proceed?"
4. PAUSE 2 (GATED APPROVAL): Wait for the user to confirm the document source and count.

V. Calibration Run (First 100 Documents)

1. Select the first 100 documents from the folder (alphabetically or by date, whichever the user prefers).

2. Process each document ONE AT A TIME using the following procedure:

   2a. Read the document. If it is an image or scanned PDF, OCR it. If it is a multi-page document, read all pages.

   2b. Determine the document metadata: file format, page count, date of document (if identifiable from the content), author, recipient, and document type.

   2c. Write a 2-4 sentence summary of the document's contents. Focus on what the document IS and what it SAYS, not what it might mean legally. Extract any key quotes verbatim.

   2d. For EACH category in the coding framework, assign a score from 1-6. Write 1-3 sentences of reasoning for each score. If the score is 4 or higher, extract the specific passage that supports it.

   2e. Insert the document record and all scores into the database.

   2f. Move to the next document. Do not stop, do not ask for confirmation, do not summarize progress. Just keep processing.

3. After all 100 documents are processed, generate a calibration report:

   3a. For each category, show the distribution of scores (how many 1s, 2s, 3s, etc.).

   3b. For each category, show the top 5 highest-scoring documents with their scores and reasoning.

   3c. Flag any categories where zero documents scored above a 3 (potential gap in the evidence).

   3d. Flag any documents that scored 5 or 6 on any category (potential smoking guns — the user needs to verify these early).

4. Save the calibration report as 02_calibration_report_batch1.md.

5. PAUSE 3 (GATED APPROVAL): Present the calibration report to the user. Ask:

   • "Do the scores look right? Is the grading criteria too loose or too tight for any category?"
   • "Are there any categories that should be added, removed, or redefined?"
   • "Should I adjust anything before running the next batch?"

VI. Calibration Refinement (Second 100 Documents)

1. If the user requested changes to the coding framework or grading criteria, update 00_coding_framework.md and update the categories table accordingly. If scores need to be recalculated for the first 100 documents, re-run them.
2. Select the next 100 documents.
3. Process each document using the same procedure from V.2.
4. Generate a second calibration report as 02_calibration_report_batch2.md.
5. PAUSE 4 (GATED APPROVAL): Present the second calibration report. Ask the same questions as Pause 3. If the user is satisfied, proceed. If not, repeat this phase with another 100 documents.

VII. Full Production Run

1. The user has approved the calibration. Now process ALL remaining documents using the same procedure from V.2.

2. PROGRESS TRACKING: Every 500 documents, write a progress log entry to 03_progress_log.md showing: documents processed so far, estimated time remaining, and any documents that could not be read (with error details).

3. ERROR HANDLING: If a document cannot be read or OCR'd:

   3a. Log the filename and error to 04_error_log.md.

   3b. Insert a record into the documents table with summary = "COULD NOT PROCESS" and all scores = 0.

   3c. Continue to the next document. Do not stop.

4. Do not pause for user approval during the production run. Process every document continuously until the entire folder is complete.

VIII. Quality Audit

1. After all documents are processed, run a quality audit:

   1a. Count total documents processed, total errors, and total documents with at least one score of 4+.

   1b. For each category, compute the score distribution and identify the top 10 highest-scoring documents.

   1c. Sample 20 random documents and re-analyze them from scratch without looking at the existing scores. Compare the re-analysis scores to the original scores. If more than 25% of scores differ by 2 or more points, flag the category as potentially unreliable.

2. Save the quality audit as 05_quality_audit.md.

IX. Final Reports

1. CHRONOLOGY: Query the database. Pull all documents that scored 4 or higher on any category. Order them by date. For each document, show:

   • The document date and name
   • The document type and author
   • A summary of what it says
   • Which categories it scored 4+ on, with the score and reasoning for each
   • Any key quotes Save as 06_chronology.md.

2. EVIDENCE STRENGTH ASSESSMENT: For each category in the coding framework, write a 1-2 paragraph assessment:

   2a. How many documents scored 4+ on this category?

   2b. What is the single strongest piece of evidence (the highest-scoring document) and what does it show?

   2c. Are there any gaps — things you would expect to find in the evidence but didn't?

   2d. Overall evidence strength grade for this category on a 1-6 scale, using the same rubric.

   Save as 07_evidence_strength.md.

3. CASE STRATEGY MEMO: Using the chronology and evidence strength assessment, write a case strategy memo that:

   3a. Identifies the strongest claims and which evidence supports them.

   3b. Identifies the most vulnerable claims (weak evidence) and what additional evidence would be needed.

   3c. Identifies the most dangerous defenses (strong opposing evidence) and how to counter them.

   3d. Identifies the weakest defenses and how to exploit them.

   3e. Recommends a trial narrative — the story of the case told through the best documents in chronological order.

   3f. Lists the top 20 "must-use" documents and why each one matters.

   Save as 08_case_strategy.md.

4. HTML EXPORT: Export the entire database as a single, self-contained HTML file (09_document_review_report.html) that the user can open in any web browser. This file should include:

   • A searchable, sortable table of all documents with their metadata, summaries, and scores
   • Filters for category type (claims, defenses, factual issues), score range, document type, date range, and author
   • The full chronology and evidence strength assessment embedded as navigable sections
   • Color-coded scores (red for 1-2, yellow for 3, green for 4-6) so patterns are visible at a glance This is the file the lawyer will actually use day-to-day. They do not need to know what a database file is — they just open the HTML file in their browser.

5. PAUSE 5 (GATED APPROVAL): Present all reports to the user. Offer to:

   • Re-run specific categories with adjusted criteria
   • Generate additional filtered views from the database (e.g., "show me only emails from the defendant's CEO")
   • Run the Legal Analysis workflow on the case using the evidence assessment as input

• 00_coding_framework.md — The complete list of claims, defenses, and factual issues that every document will be scored against, with grading criteria.

  • Example: 012_doc_review_case_name\​00_coding_framework.md

• doc_review.db — SQLite database containing every document's metadata, summary, and scores for each category.

  • Example: 012_doc_review_case_name\​doc_review.db

• 02_calibration_report_batch1.md — Score distributions and top documents from the first 100-document test run.

  • Example: 012_doc_review_case_name\​02_calibration_report_batch1.md

• 06_chronology.md — All documents scoring 4+ ordered by date, with summaries, scores, and key quotes.

  • Example: 012_doc_review_case_name\​06_chronology.md

• 07_evidence_strength.md — Per-category assessment of evidence strength, gaps, and an overall 1-6 grade.

  • Example: 012_doc_review_case_name\​07_evidence_strength.md

• 08_case_strategy.md — Trial narrative, strongest/weakest claims and defenses, and the top 20 must-use documents.

  • Example: 012_doc_review_case_name\​08_case_strategy.md

• 09_document_review_report.html — Self-contained HTML report with searchable, sortable, color-coded tables. Open in any browser — no special software needed.

  • Example: 012_doc_review_case_name\​09_document_review_report.html