Gyanajala

Gyanajala — ज्ञानजाल, the web of knowledge. ▎ ▎ Knowledge graphs make AI models dramatically better at law. Building one, and the Graph-RAG system beside it, is the part nobody can do. This software is that part. ▎ ▎ The idea it is built on: legal reaso. It runs on assertions — a claim, plus who made it, from which provision, and what that provision does to it. Two assertions can contradict each other and both be law. One provnother limits it, an Explanationexpands it, an Exception displaces it. A conventional knowledge graph has nodes and edges and nowhere to put that tension, so it flattens nvisible. ▎ ▎ Here every conflict is stored, and wlicts come back with the answer. Areviewer can mark a tension irreducible — a finding that this is genuine law and must not be resolved. Nothing in the system ever ▎ ▎ Machine proposes, human decides, bot the graph was accepted or corrected by a person. The record of what the machine proposed against what the human did is kept permanently, because that difference is the seconus of exactly the mistakes theextractor makes. And no claim enters at all without quoting its provision verbatim — one that doesn't is refused automatically and never r ▎ ▎ Two things on one foundation. A bareaph: structure extracteddeterministically, concepts extracted by a model and reviewed against the enacted text, exported as standard RDF. A filed petition becomt one — and that is deliberately not agraph, because a petition's structure is a set of claims about one case, never about the law. ▎ ▎ How the petition track works. Ingest a filed petition and it is anonymised as it is read — the ▎ database has no column to put a realtokens become the blanks: the appellant named four times is one token, so the form asks once. The document is then cut into stretches, each ▎ classified as one of five kinds — eve arc, expected counter, need or relief sought, boilerplate — and each kind becomes a control. Ground-triggering rules are wired to named ▎ evidence. Then you fill the form: evf live in the preview, ticking a pieceof evidence brings in the grounds that stand on it, and out comes a filing-ready .docx. ▎ ▎ Each stage has its own keys — see the key reference below. It is keyboard-first throughout, because ▎ the number this project lives or dieon. ▎ ▎ You can extend the ontology yourselfmid-review, add a stance, rename orretire a type — it is a row, not a migration, and renaming carries the whole graph with it in one ▎ transaction. ▎ ▎ Where this goes. A GitHub for legal are standard RDF with full provenance,so a graph one person reviews is one anyone can read. The same machine takes judgments, contracts, ▎ due diligence — anything where the rher than facts. ▎ ▎ Where it came from. In 2026 I built st Bengal's SIR name-deletion appeals;it produced petitions for 150+ people through the Legal Aid Society at NUJS Kolkata. That taught me the real problem — every ground had e the appellant actually held, and Ihad hardcoded all of it for one fact pattern. Gyanajala is that, generalised, with no code.

**# Key Features

## The Idea the Whole Thing Rests On

### Assertions, not facts

Legal reasoning does not run on facts. It runs on claims — each one carrying who made it, which provision it came from, and what that provision does to it.

One section defines a concept. Another limits it. An Explanation expands it. An Exception displaces it.

There is deliberately no table of bare facts anywhere in the store.

### Every conflict is kept — and it comes back with the answer

Two assertions about the same subject can both live in the system.

A reviewer can mark a tension as irreducible — a finding that this is genuine legal disagreement and must not be flattened.

Retrieval surfaces contested claims as contested. Nothing silently picks a winner.

### A machine proposes. A human decides. Both are kept.

Every claim in the graph is accepted or corrected by a person.

The record of what the machine proposed against what the human ultimately decided becomes a second product: a labelled corpus of the extractor’s mistakes.

That is what allows the system to improve.

---

# What Stops It From Lying to You

### Every claim quotes the statute verbatim — or it is refused

This is not a prompt instruction. It is a mechanical check.

An assertion whose supporting quotation cannot be found in the provision from which it was extracted is automatically refused and never reaches a human reviewer.

Review capacity is scarce. Spending it on claims the machine can already prove are invented is the worst possible use of it.

### Structure is extracted deterministically. No model touches it.

Chapters, sections, sub-sections, clauses, provisos, Explanations, Illustrations and Exceptions are identified through deterministic rules, using composed Akoma Ntoso identifiers.

They are found by pattern, not inference.

Two runs over the same PDF therefore produce the same structural tree.

531 sections. 1,199 cross-references. Round-trip clean.

### The pipeline is gated

A wrong section boundary poisons every concept extracted from it.

So boundaries are checked and signed off before anything expensive runs.

A gate refuses in words — for example, “9 stretches nobody has classified” — and the rule lives in the store rather than merely appearing on a screen.

Nothing downstream can route around it.

### Refuse a claim once and you are not asked again

Rejections carry one of six reason codes, together with rules governing how far that rejection travels.

For example:

• “True but not worth a node” can apply across the entire Act.
• “Right claim, wrong section” stays confined to that section because the claim itself may still be correct — merely misfiled.

A reviewer’s note can then feed into the next extraction prompt for that provision.

### A sweep catches what section-by-section review cannot

Reviewing one provision at a time makes each individual judgment meaningful, but it also creates a problem: inconsistencies across provisions reviewed on different days can be missed.

The system therefore runs graph-wide checks for problems such as:

• one concept typed in two different ways;
• two provisions taking different stances on the same pair;
• near-duplicate concept names; and
• concepts asserted repeatedly but linked to nothing.

Every finding explains why it fired in words a reviewer can check — never merely through a similarity score.

---

# The Bare Act Track

### Keyboard-first review, built around seconds per decision

The split screen places the enacted text on the left and the review queue on the right, with the extractor’s quoted span highlighted directly inside the provision.

Accepting takes one key.

Rejecting takes two because the second key records the rejection reason, and that reason is mandatory.

A reviewer can batch-accept the confident remainder of a provision while the system tells them what it held back and why.

### The ontology is data you can edit mid-review

Declare a new predicate. Add a stance. Rename or retire a type.

These are data operations, not migrations, and they become effective immediately.

Renaming carries the entire graph with it in one transaction.

Merging two types is deliberately harder: a fold is refused until the reviewer asks twice, because downstream systems do not otherwise retain the fact that those concepts were once distinct.

### Ask: four phases, and the model runs only two

The question-answering process is separated into distinct phases.

Planning sees the question, ontology and manifest — but not a single word of provision text. It therefore cannot answer the question; it can only plan retrieval.

Retrieval is ordinary code that the model cannot influence.

**