We said our legal model was weak on statutes. Here is the one that is not.

When we released our judgment retriever, embed-legal-en, we did something in the model card that most people skip. We measured how well it carried over to a neighbouring kind of legal text, bare statutory Acts, and we published the answer even though it was unflattering. The transfer was flat, 0.036 to 0.036. Statutes read differently from judgments, and a model tuned on one register does not automatically understand the other. So we named the gap in public.
Today we are closing it. We are releasing embed-statute-en, a small open adapter built for exactly that register: English central-statutory, bare-Act text. It is public on Hugging Face and the weights are Apache-2.0.
huggingface.co/quanfire-ai/embed-statute-en
What it is
embed-statute-en is a LoRA adapter over a frozen intfloat/multilingual-e5-small. On disk it is about 2.4 MB, it produces 384-dimensional normalized vectors, and it is purpose-built for one job: given what you are looking for, finding the provision of an Indian Central Act that says it.
The reason we keep shipping models this small is that they are honest and portable. This is not a black box you have to take on faith. It is a tiny, inspectable delta on a well-known open base, and you can run it on your own statutory text and judge it directly.
The number that matters
Statute text has a trap in it. A section's marginal-note heading often restates the section body almost word for word, so a plain keyword matcher can score well on those high-overlap pairs without understanding a thing. The honest test is the opposite bucket: the pairs where the query and the right section share almost no words, so the only way to win is to understand the meaning.
On that low-lexical-overlap slice (n=874), Recall@1 goes from 0.077 to 0.177, an increase of 131%. It more than doubles on exactly the pairs a string matcher cannot solve. That is the real evidence the model learned statutory meaning rather than surface overlap, and it is the number we lead with.
The full table
In-distribution, on 1,978 held-out central-statute pairs, against the untrained base:
| Metric | Base e5-small | embed-statute-en | Change |
|---|---|---|---|
| Recall@1 | 0.182 | 0.269 | +48% |
| Recall@5 | 0.346 | 0.488 | +41% |
| Recall@10 | 0.411 | 0.575 | +40% |
| nDCG@10 | 0.290 | 0.415 | +43% |
The Recall@1 gain sits well clear of noise: the 95% confidence intervals are disjoint, base [0.165, 0.199] against adapter [0.250, 0.289], and the two intervals do not touch. We will also be the first to keep it in proportion. An absolute Recall@1 of 0.269 is modest. The base model is small and central-statute retrieval is a genuinely hard domain. The story here is the size of the delta and the doubling on the un-gameable slice, not a claim that statute search is solved.
Where the data came from, and why that matters
The adapter is trained on 858 Central Acts of the Indian Parliament, from the annotated dataset "An annotated dataset of Central Acts enacted by the Indian Parliament" (Zenodo 5088102), which is released under CC-BY-4.0. So we attribute it plainly:
Source: "An annotated dataset of Central Acts enacted by the Indian Parliament," Zenodo record 5088102, CC-BY-4.0.
Bare-Act text carries its own care. Reproduction of an Act is a permitted act under section 52(1)(q)(ii) of the Copyright Act, 1957, and this model is non-reconstructive: it emits 384-dimensional vectors and cannot reproduce the source text. We ship the weights, not the corpus. That is why these weights are clean to build on, and clean provenance is not a footnote for us, it is the product. This is general information about how the model was built, not legal advice.
Check our work
Do not take our word for any of this, and you do not have to. The model card lays out the full benchmark, the confidence intervals, the low-overlap slice, and the scope in one place. The base model is open (multilingual-e5-small, MIT), so what we added is a small, inspectable 2.4 MB adapter and not a black box: pull it and run it on your own statutory text to judge it directly. The provenance is publicly checkable too, because the dataset is a public Zenodo record under a named licence and we attribute it. Our training framework is open source at github.com/quanfire-ai/quanfire-multilingual-embedding (Apache-2.0).
What it is for, and what it is not
We are precise about scope. embed-statute-en is built and validated for English central-statutory (bare-Act) text. It is English only, not Hindi, Tamil or other Indic statutory text. It covers Central Acts only; state legislation, rules, regulations, notifications and contracts are out of distribution and unmeasured, so do not read coverage into them. And it is statute-specific: for judgments and case-law the right model is embed-legal-en, and we do not assume transfer between the two registers in either direction. A model that tells you where it works is worth more than one that claims to work everywhere.
Why we build in the open
This is the third clean, verifiable model we have put out in the open, after embed-legal-en for judgments and embed-gov-indic for cross-lingual government text, and the pattern is deliberate. We named where the legal model was weak, we built the model for exactly that gap, and we published the proof. We think the team you trust with your documents should be a team that ships its own domain models, documents their provenance, and hands you the receipts. That discipline is what we bring to our products too.
Want that same provenance-first, verify-it-yourself discipline applied to your own documents? The same team builds DocPro. Try it on your contracts and filings.