✓ Survived Rank 1 of 18 proposedVenture Other Oct 28, 2026

Point-in-time statute API for legal research tools

An API that returns the exact text of any US Code section as it stood on any date, with provenance for every amendment.

A ready-to-paste brief for Claude Code, Cursor or any coding agent.

I want to build a venture-scale product. Help me plan and start the MVP.

Product: Point-in-time statute API for legal research tools
What it is: An API that returns the exact text of any US Code section as it stood on any date, with provenance for every amendment.
Who pays: Legal tech startups and AI legal research teams (e.g., companies like Harvey, Casetext, LexisNexis innovation groups) and in-house legal data teams at AmLaw 200 firms; $2k–20k/mo from their data licensing budget as a cheaper, more precise alternative to Westlaw/Lexis APIs.
Closest alternatives: Westlaw/Lexis point-in-time statutes (closed, expensive, no clean API for AI pip, Lexifina itself (early, limited to nine titles, no retroactivity warnings), eliask/lawvm (open source, incomplete for US), Cornell LII (current text only)
The gap: Westlaw and Lexis have point-in-time views but lock them in expensive closed products with no developer-friendly API; open projects can't handle US complexity (retroactive effective dates, amendment chains). Nobody offers a verified, provenance-tagged temporal statute API built for LLM retrieval.
Why now: Legal AI adoption exploded in 2025–2026 and research published this year quantifies that temporal validity failures are a hard blocker for LLM statutory QA, creating demand for retrieval layers with verified historical text.
Moat to build toward: The hard part is the verified amendment-application engine plus a manually adjudicated edge-case corpus; each corrected ambiguity is compounding data that competitors must independently reproduce, and provenance-verified accuracy is a trust barrier.
Biggest risk: Westlaw or Lexis ships a cheap developer API for historical statutes and the open lawvm-style projects become good enough for the AI use case, collapsing willingness to pay.

First three steps:
1. Extend a release-point diff engine (as in the article) to all 54 titles, flagging retroactive and conditional effective dates.
2. Ship a REST/JSON API: section + as-of date returns text in force, change annotations, and citing public law.
3. Sign 2–3 pilot legal AI startups and measure improvement in their temporal QA accuracy vs. current-text retrieval.

Start by asking me up to five questions about constraints (stack, budget, timeline), then propose the smallest version a paying customer would use, and scaffold it.

Overall6.5/10

Pain7

Willingness to pay7

Timing7

Gap7

Moat6

Feasibility4

For

Who pays

Legal tech startups and AI legal research teams (e.g., companies like Harvey, Casetext, LexisNexis innovation groups) and in-house legal data teams at AmLaw 200 firms; $2k–20k/mo from their data licensing budget as a cheaper, more precise alternative to Westlaw/Lexis APIs.

What people said · 3

Article shows models fail on temporal statute questions (24% correct alone vs 87% with retrieved text) and that LLM-generated historical consolidations contain legally significant errors, so a verified point-in-time record is needed. From the article ↗
A builder doing open-source amendment-driven law for multiple countries notes US/UK law is much harder to do correctly and that some cases are irreducibly ambiguous and need adjudication. Read the comment ↗
A commenter who spent months on legal text tracking says naive git-style diffing is a trap because legal versioning has fundamentally different semantics. Read the comment ↗

Paraphrased from the discussion. Follow the links for the original comments.

Competitors and gap

Westlaw/Lexis point-in-time statutes (closed, expensive, no clean API for AI pipLexifina itself (early, limited to nine titles, no retroactivity warnings)eliask/lawvm (open source, incomplete for US)Cornell LII (current text only)

Westlaw and Lexis have point-in-time views but lock them in expensive closed products with no developer-friendly API; open projects can't handle US complexity (retroactive effective dates, amendment chains). Nobody offers a verified, provenance-tagged temporal statute API built for LLM retrieval.

Why now

Legal AI adoption exploded in 2025–2026 and research published this year quantifies that temporal validity failures are a hard blocker for LLM statutory QA, creating demand for retrieval layers with verified historical text.

Moat · 6/10

The hard part is the verified amendment-application engine plus a manually adjudicated edge-case corpus; each corrected ambiguity is compounding data that competitors must independently reproduce, and provenance-verified accuracy is a trust barrier.

Against

Red team: Quantified evidence that temporal statute failure blocks legal LLM QA, incumbents provably lock point-in-time data in closed products, and the amendment-adjudication corpus is a genuinely compounding asset — hard to build but a real company.
What would kill it: Westlaw or Lexis ships a cheap developer API for historical statutes and the open lawvm-style projects become good enough for the AI use case, collapsing willingness to pay.

Start

First three steps: Extend a release-point diff engine (as in the article) to all 54 titles, flagging retroactive and conditional effective dates.
Ship a REST/JSON API: section + as-of date returns text in force, change annotations, and citing public law.
Sign 2–3 pilot legal AI startups and measure improvement in their temporal QA accuracy vs. current-text retrieval.
Source discussion: Git for the US Code ↗ 408 points219 commentsFrom the storyLinked article

For

Against

Start

More from this issue