LexScope

Inspiration

Legal information is inherently jurisdiction-dependent. A question that sounds simple — such as whether a consumer can return a defective product — can have materially different answers depending on the country, region, applicable regulation, and date.

General-purpose AI systems are trained across large amounts of information and can produce convincing answers without reliably demonstrating which jurisdiction their answer comes from.

We wanted to explore a different approach: what if a legal AI system treated jurisdiction and evidence as hard constraints instead of optional context?

This wasn't hypothetical for us — researching sources for the prototype, we found Pakistan has no single national consumer protection law at all; it's split across five separate provincial acts. A system that just said "Pakistan" without picking one would already be wrong before a single question was asked.

What it does

LexScope answers legal questions inside a hard jurisdiction boundary. You pick a jurisdiction and a legal domain before asking anything — there's no default, so you can't accidentally get an answer without specifying one. Ask a question, and LexScope retrieves the relevant provisions from that jurisdiction's authoritative source only, generates an answer grounded in those provisions, and shows you the exact section text behind every claim.

Ask the same question again after switching jurisdiction, and you get a different, independently-sourced answer — because consumer rights law in the UK and in Punjab, Pakistan are genuinely different statutes with different remedies. Remove the jurisdiction and it refuses to guess. Ask something the corpus doesn't cover and it says so instead of making something up. In our own testing, both of those refusal behaviors fired correctly every time we tried to provoke them.

How we built it

Jurisdiction-filtered retrieval sits between the question and the language model. A FastAPI backend filters the source corpus by jurisdiction in SQL, before either keyword or semantic search runs — not as a prompt instruction the model could ignore. Retrieved provisions are ranked, checked for evidence sufficiency (below a calibrated threshold, the system abstains before generation even starts), passed to the LLM with an explicit "this is data, not instructions" framing to resist prompt injection from ingested legal text, and then checked again afterward: any claim the model makes gets verified against the actual jurisdiction-filtered evidence set, regardless of what the model itself cites.

Stack: Next.js/TypeScript/Tailwind frontend, Python/FastAPI backend, PostgreSQL + pgvector for hybrid keyword-and-semantic retrieval, with a provider-agnostic LLM layer so swapping models doesn't touch business logic. The corpus itself is the UK's Consumer Rights Act 2015 and the Punjab Consumer Protection Act 2005, parsed and chunked section-by-section so every citation traces back to a real, specific provision.

Challenges we ran into

Pakistan turned out to have no single national consumer protection law to point at — it's split across five separate provincial acts — which meant the jurisdiction model had to support sub-national granularity (Pakistan — Punjab, not just Pakistan) before a single line of retrieval code made sense.

The sharpest challenge was one we only found by actually running the system end-to-end against a real database instead of trusting the code by inspection: our keyword search used AND-based query matching, which requires every word in a question to appear in the same short legal section. Against our real corpus, our own core demo question — "Can I return a defective product for a refund?" — matched zero provisions in either jurisdiction, including the UK section whose entire subject is exactly that. We caught it, switched to OR-based matching, recalibrated the abstention threshold against real measured scores instead of a guessed number, and wrote a regression test so it can't silently regress.

Beyond that: making sure retrieval could never leak a foreign jurisdiction's provisions into an answer (solved with a hard SQL filter plus a backstop assertion), and designing claim verification so the model can't cite evidence that doesn't actually exist.

Accomplishments that we're proud of

Getting jurisdiction isolation from a design principle to something we could actually prove: two automated tests that fetch real evidence for a UK question and a Punjab question sharing the same everyday words ("refund," "manufacturer") and assert neither ever returns the other's provisions — passing against a live, fully-ingested database, not a mock.

Catching the AND/OR retrieval bug before it reached a demo, by insisting on live end-to-end verification rather than "the code looks right." A system whose entire pitch is reliability failing silently on its own headline question would have been a bad look to discover in front of judges instead of in testing.

Building real abstention that we can demonstrate on command: ask an out-of-scope question and it says INSUFFICIENT_EVIDENCE instead of confidently answering anyway, every time we tried.

What we learned

That "jurisdiction" is a much messier concept than a dropdown menu implies — provinces, territories, and overlapping statutes are the norm, not the edge case, and a system that doesn't model that granularity from the start will get real answers wrong in exactly the cases that matter most.

That verification has to be adversarial against your own system, not just functional. Every individual piece of our retrieval code was "correct" — the SQL ran, the function returned results — and it still failed on the one question the whole project exists to answer, because correctness at the unit level didn't guarantee correctness at the pipeline level. Only running the real question against real data surfaced that.

That abstention is a feature you have to design and test for directly — an LLM's default instinct is to answer, and every layer of this system (the retrieval threshold, the prompt, the claim verifier) exists specifically to override that instinct when the evidence doesn't support it.

What's next for LexScope

More jurisdictions — particularly a second Pakistani province like Sindh, which would let us demonstrate genuine cross-provincial conflict detection rather than just jurisdiction isolation. More legal domains beyond Consumer Rights. Wiring in a real LLM and embedding provider (the current build runs in a deterministic demo mode by design, so judging never depends on external API uptime, but semantic search is implemented and ready to switch on). Automated source-freshness monitoring, semantic legislation diffing, and a formal evaluation benchmark for jurisdiction leakage beyond our current two hand-written tests. Longer term: multilingual civic/legal information, a browser extension, and workflows built for legal clinics and public-sector policy analysis.

Built With

• embeddings
• fastapi
• hybrid
• llm
• next.js
• pgvector
• postgresql
• provider-agnostic-ai
• python
• rag-(retrieval-augmented-generation)
• search
• supabase
• tailwind-css
• typescript