Inspiration
Repeatedly revising a legal filing can improve its prose while quietly weakening its evidentiary structure. Exhibit citations drift, observable facts blur into inference, damage periods overlap, and emotionally strong labels can replace conduct that can actually be proved.
I wanted a repeatable workflow that begins with the record, preserves the connection between claims and evidence, tests the strongest opposing explanation, and makes every important revision easier to verify.
What it does
Evidence-Led Litigation Review is a local-first Codex plugin for reviewing Japanese litigation filings.
It converts supported local evidence into reusable text dossiers, records source and verification states, draws a two-sided chronology for self, opponent, and neutral material, and lists deterministic inconsistency candidates between filings, normalized claims, and exhibits.
It also produces a location-specific proofreading list for likely mistypes, registered misconversions, duplicate input, punctuation and bracket defects, unknown exhibit references, and explicitly supported exhibit-number repairs. The repair list includes extracted-text line and character positions and can be exported as Markdown, JSON, and spreadsheet-ready CSV.
The bundled Codex skill then guides the review through seven fixed passes:
- evidence inventory;
- issue chain;
- evidence-claim matrix;
- causation and damages;
- strongest-opponent review;
- expression; and
- filing-day verification.
The public repository contains only a deliberately invented commercial dispute using abstract labels such as 原告A and 取引相手B. It contains no real party, filing, address, case number, medical record, or exhibit image.
Two-layer architecture
The project deliberately separates deterministic processing from model judgment.
The local Python tools perform repeatable checks and return the same findings for the same inputs. They make no network request and do not call a model API. This layer handles structural signals such as unresolved placeholders, exhibit-number drift, damage-period overlap, exact proofreading locations, extraction state, and configured citation inconsistencies.
GPT-5.6 in Codex is the separate reasoning layer. It distinguishes what an exhibit directly proves from what must be inferred, tests causation and competing explanations, separates non-property damage from past and future property loss, identifies the strongest lawful response, and proposes wording that remains faithful to the available record.
The drafting-readiness score is not a win probability, legal-merits judgment, evidence-sufficiency decision, or filing approval.
How I built it
I worked solo and used Codex and GPT-5.6 as development tools.
Codex accelerated the repository-level work: plugin structure, Python implementation, DOCX and PDF handling, OCR integration tests, cache design, chronology generation, proofreading rules, synthetic fixtures, automated testing, documentation, privacy review, and release verification.
The deterministic core uses the Python standard library and supports TXT, Markdown, DOCX, and structured JSON inputs. Optional local Poppler and Tesseract tools support text PDFs, scanned PDFs, and common image formats. Outputs use Markdown, JSON, CSV, HTML, and SVG.
GPT-5.6 was used to design and encode the record-sensitive review method: separating direct proof from inference, building the chronology-to-remedy issue chain, testing alternative causes, separating damage periods, steelmanning opposing arguments, and converting those judgments into a reusable Codex skill.
Challenges
The hardest challenge was avoiding two unsafe extremes.
The first was building only a generic grammar or regular-expression checker. Deterministic rules are useful for exact notation, locations, missing citations, and repeated structural errors, but they should not pretend to decide semantic or legal questions.
The second was building a system that appears to decide legal merit. The project therefore keeps structural warnings, model reasoning, and human responsibility separate.
OCR created another important boundary. Cached text is useful for fast navigation, but an OCR result cannot authenticate evidence or replace review of the original source. Important dates, amounts, signatures, quotations, and image details must return to the original.
Privacy was also a core design problem. Removing names from a real dispute would not necessarily prevent re-identification. I therefore replaced the public fact pattern with an unrelated fictional commercial dispute and added current-tree and Git-history privacy scans.
Accomplishments
- A working Codex plugin and reusable seven-pass litigation-review skill
- A dependency-free core filing analyzer
- Local evidence dossiers with explicit source-verification states
- A filterable two-sided diagonal chronology
- Filing-to-evidence checks for both
甲and乙exhibits - Line-and-character proofreading reports in Markdown, JSON, and CSV
- Optional local PDF and image extraction through Poppler and Tesseract
- A cross-platform one-command demo requiring no API key
- A completely fictional public sample and generated outputs
- Plugin and skill validation
- Current-tree and reachable Git-history privacy scans
- Twenty-three automated unit and integration tests passing
The original deterministic demo reports:
draft: working draft | 37/100 | 11 finding(s)
stable: stable candidate | 100/100 | 0 finding(s)
Log in or sign up for Devpost to join the conversation.