Impact feed
Every amendment gazetted in the last 12 months, scored by how much of the precedent corpus it moves. Click a row for the change note and the affected clause patterns.
No results for these filters.
Impact graph
Provisions on the left, precedent document types on the right. Each edge is one provision reaching one document type; the thickness is the number of clause patterns on that link.
Top 8 provisions by affected clause patterns — whole corpus
Hover an edge for the clause-pattern count. Click a node to isolate its edges; click again to release.
Table view — every edge in this graph
| Provision | Document type | Clause patterns |
|---|
Amendments by month
Last 12 months to August 2026 · whole corpus, all jurisdictions
Table view
| Month | Amendments |
|---|
Affected clause patterns by practice area
Whole corpus · 110 clause patterns across 30 amendments
API feed
The same graph, sold as a feed. Build a request, run it, and see the response a DMS or CLM vendor would embed.
Request builder
Responses are generated from this demo’s local dataset — nothing leaves the page.
Response
200 OKGET /v1/impacts
Pricing
Per-seat revenue is the wedge. Per-call licensing to other vendors is the business.
About this play
The second-order thesis behind StatuteGraph, in plain English.
The first-order wedge
The obvious product is a tool that updates a law firm’s precedent documents when legislation changes. A statute is amended, the tool finds the clauses in the firm’s templates that no longer work, and proposes a redline. Firms buy it per seat, because keeping a precedent bank current is expensive, dull, and the sort of work that quietly slips until something goes wrong.
What the wedge actually accrues
To do that job at all, the tool has to build a map: which legislative provisions touch which clause patterns in which kinds of document. That map is the real asset, and it is the thing nobody currently owns, because nobody else sits inside the update workflow. Every time a lawyer accepts or rejects a proposed change, the system gets a labelled edge between a provision and a clause — a piece of ground truth that cannot be scraped, only earned by being in the loop. The redlines are the by-product; the graph is what compounds.
The two parties it connects
On one side are the legislative and regulatory feeds: bills, gazettals, commencement dates, explanatory memoranda. On the other side is every product that touches a document — document management systems, contract lifecycle tools, drafting assistants, in-house legal teams, and rival firms. Those products all face the same question and none of them can answer it: when this amendment commences, which of my templates break? StatuteGraph is the layer that sits between the two and answers it in a form software can consume.
The endgame
Bloomberg for statutory change impact. Seats fund the build and keep the labelling flowing; the licensed feed is the business, priced per call to vendors who would rather buy the map than build it. Churn stays low because the graph gets better with age and leaving means losing the history behind every edge. The thing that would validate it is narrow and testable: get one document management or contract lifecycle vendor to say they would pay for a feed telling them which templates a bill amendment touches — and ask that before building anything past the prototype.