OpenCounsel

Inspiration

I'm a practicing litigation attorney, and I frequently build small projects to help me with legal tasks. I built OpenCounsel (or at least the slice demonstrated here) because I noticed that my firm was burning valuable associate time on document-formatting and assembly tasks when they should have been doing more lawyerly, scholarly things.

What it does

The challenge I faced was that memoranda of law need to (i) be properly formatted; (ii) have a conforming Table of Contents and Table of Authorities (a sort of list of all the cases, statutes, and other legal authorities cited); and, increasingly, (iii) include hyperlinks to all authorities cited in the brief. This can be a major drag and take a great deal of time.

Hence OpenCounsel, or this slice of it. It turns a poorly formatted litigation filing into a filing-ready, auditable review package through a local two-pass workflow.

The first pass repairs document structure and formatting, applies court-specific rules, generates linked and paginated front matter, identifies authorities requiring source copies, and produces separate DOCX, PDF, manifest, correction-ledger, and audit artifacts.

The second pass verifies the supplied opinions, confirms authority identity and quotations, classifies embedded links, requires approval before inserting durable links, and returns a final review package without altering the original first-pass artifacts.

It automates mechanical production while preserving the work that requires lawyer judgment.

How I built it

I used GPT-5.6 to help define the product, architecture, legal workflow, failure boundaries, and acceptance criteria. Codex worked directly in the repository to write tests, implement features, debug failures, inspect generated artifacts, run Docker rehearsals, and prepare the application for an external demonstration.

The whole thing was built during the contest period using a combination of GPT-5.6 in ChatGPT, including the GitHub connector, and Codex within the project window.

The development process was test-driven and artifact-driven. I repeatedly fed real briefs in various states of undress into the system (since I am actually using it) and gave detailed instructions on how to fix the resulting issues. I tried to follow SWE best practices, TDD, etc., but I am a lawyer, so what do I know.

The repository, tests, commits, and project-state documents served as the durable source of truth across multiple agent sessions.

Challenges I ran into

Legal documents are unusually difficult software objects. In part, this is because lawyers insist on using Word and their idea of version control is:

[doc]-last.last.final.frfr.docx

A filing must remain editable while also producing stable pagination, correct front-matter numbering, native heading structure, a linked table of contents, a usable table of authorities, and a reliable PDF.

The interaction among Word structure, LibreOffice rendering, PDF text extraction, and page resolution produced subtle failures that could not be solved by changing a template. I had to retain failed artifacts, reconstruct what the renderer actually produced, write regression tests, and fix the underlying logic. Oh, and Word Mobile does not faithfully render all sorts of things, so that was a fun discovery.

Source verification created a separate challenge. A filename is not proof that a PDF is the correct opinion, and a hyperlink is not necessarily durable. OpenCounsel therefore needed controlled authority slots, identity and quotation checks, explicit link classification, immutable artifacts, and fail-closed handling of unsafe or mismatched inputs.

The final challenge was scope discipline. There were many tempting additions, including things I had already built and wanted to include separately, such as a feature that turns a messy evidentiary record into something machine-readable for cite-checking, along with more substantive AI-assisted citation-review workflows. But the priority was one complete and trustworthy workflow rather than a broad collection of partial features.

Accomplishments that I'm proud of

I built a real, locally runnable product rather than a mockup.

OpenCounsel can take a damaged filing, produce professional DOCX and PDF outputs, generate linked front matter, identify missing source material, verify uploaded opinions and quotations, preserve immutable intermediate artifacts, and return a complete audit package.

I also built the demonstration around a real public federal filing (which OpenAI's legal team will be familiar with) and provided a clean Docker installation path so that the project can be tested as shown.

What I learned

I learned that I can replace lots of associate and paralegal time with iterative agentic engineering. Waits for applause from my office.

GPT-5.6 and Codex dramatically expanded what one domain expert could build, but they were not substitutes for product direction. The critical work remained defining the correct workflow, identifying the invariants, deciding what evidence would count as success, and refusing shortcuts that would make the demo look finished without making the system trustworthy.

I also learned that domain experts no longer need to memorize every temporary framework or wait for a conventional software team before testing a serious product idea. They need a strong map of the system, clear acceptance criteria, and the ability to direct and verify agent work.

What's next for OpenCounsel

The next step is to expand OpenCounsel from one demonstrated federal-motion workflow into a broader legal-production platform.

That includes additional courts, jurisdictions, document types, and filing profiles; stronger support for records and appendices; automated authority acquisition from approved sources; richer citation and quotation review; comparison against court rules and judge-specific practices; and reusable firm templates that preserve institutional style.

For now, the larger vision is not to replace lawyers (though I should like eventually to replace much of what they do, which will ironically probably create more, but different, work for lawyers); rather, the immediate plan is to eliminate the mechanical friction surrounding legal judgment so that more professional time is spent on the parts of the work that actually matter.

Built With

• python