A lawyer does not read a law as an isolated page. A lawyer asks what it refers to, what it replaces, what supports it, and how it connects to the facts of a case.
That is where ordinary legal search begins to fall short.
A traditional search engine can locate a phrase inside a statute. It may show every document containing “criminal procedure,” “bail” or “appeal.” But legal work requires more than locating words. It requires understanding relationships.
Which Act cites another Act?
Which section refers to another section?
Which law belongs to a particular legal period?
Which authority appears repeatedly across the legal corpus?
Can the system retrieve the complete statute rather than only a matching sentence?
These questions shaped the architecture of our Bangladesh Legal Acts GraphRAG system.
One legal system, two types of memory
The architecture uses two complementary storage layers.
The first is a knowledge graph. It holds the relationships between legal entities.
The second is DynamoDB. It holds the detailed legal content.
The distinction is simple:
The graph explains how legal information is connected. The database provides the information itself.
The graph currently contains more than 51,000 nodes and 62,000 relationships across Acts, sections, footnotes and historical periods. DynamoDB holds Act metadata, statutory text, footnotes, reverse-citation records and corpus information.
This separation matters.
When a user asks for a complete Act, the system does not need to walk through a graph. It can retrieve the Act’s metadata, sections and footnotes directly from the database.
When the user asks which Acts cite a particular law, the relationship graph becomes valuable.
Instead of forcing one technology to handle every problem, the architecture gives each layer the work it performs best.
What the graph understands today
The current graph has four main entity types:
- Acts
- Sections
- Footnotes
- Historical periods
It also understands four important relationship types:
- An Act contains a section
- An Act contains a footnote
- A section references another section
- An Act cites another Act
- An Act was enacted during a historical period
This creates a structural map of the legal corpus.
Consider an Act from 1822. The system can connect it to its sections, footnotes, historical period and cited Acts. It can preserve a citation even when the cited law is not yet available in the corpus by creating a temporary reference, known as a stub node.
That is a significant improvement over flat document search. The system does not simply know that two phrases appear in two files. It knows that one legal instrument points to another.
Eleven tools turn the data into usable legal research
A knowledge graph becomes useful only when an agent can access it correctly.
The Legal Acts system exposes 11 tools for tasks such as:
- Retrieving a complete Act
- Retrieving one section
- Listing Acts by year
- Listing Acts by legal period
- Searching for relevant Acts
- Identifying Acts cited by a law
- Identifying laws that cite a target Act
- Exploring amendment chains
- Finding conceptually neighbouring Acts
- Retrieving bilingual statutory text
- Reading corpus statistics
Not every tool uses the graph.
Several direct-retrieval tools use DynamoDB because it is the fastest and most reliable source for full statutory content.
Other tools use graph traversal because the question concerns relationships.
One tool, legal_act_cited_by, combines both. It checks deterministic citation records in DynamoDB and incoming citation relationships in the graph. It then records whether the result came from the database, the graph or both.
That provenance is important.
A legal AI system should not merely provide an answer. It should communicate how strongly the available evidence supports that answer.
The system is structural, but not yet fully semantic
There is also an important limitation.
The graph currently understands legal structure, but it does not yet fully understand legal meaning.
Future semantic entities may include:
- Legal concepts
- Government authorities
- Persons
- Geographic jurisdictions
- Doctrines
- Institutions
Future relationships may include:
- Amends
- Amended by
- Defines
- Mentions
- Establishes
- Has jurisdiction over
Today, an amendment-chain tool exists, but its results remain limited because amendment relationships have not yet been fully populated.
Similarly, a concept-neighbour tool can search for related Acts, but without dedicated LegalConcept nodes it must partly rely on lexical matching.
This is not a failure of the architecture. It is a clear boundary between what has already been structurally extracted and what still requires semantic extraction.
The difference between knowing and understanding
The current search process scans titles, labels and selected attributes for words from the user’s query.
This works well when a user searches for an identifiable statute.
It becomes less reliable when the user asks a conceptual question using different wording from the Act title.
A search for “Penal Code” may produce a strong match.
A search for “a law covering intentional harm resulting in death” requires semantic interpretation.
That is where embeddings, concept extraction and semantic reranking become necessary.
The current architecture therefore gives us a strong legal-data foundation, but the real value emerges when another system can use that foundation to reason over an actual case.
The next question is the one every legal-AI platform must eventually answer:
What happens when a user uploads a case file and asks, “What are my possible outcomes?”
That is where the Legal Orchestrator enters the story.