“My motorcycle was stolen outside the market. The police arrested someone, but he was released the next day.”
A lawyer reading that sentence immediately begins forming legal questions.
Was a complaint filed?
What evidence connects the suspect to the theft?
Was the release related to bail?
Was the arrest lawful?
Which offences may apply?
Which procedural rules govern the next step?
A lexical search system sees something different.
It sees words:
- Motorcycle
- Stolen
- Market
- Police
- Arrested
- Released
Those words may not appear in the titles of the relevant Bangladesh Acts.
This exposes one of the most important challenges in legal AI: the difference between legal language and human language.
Professional legal documents are easier to retrieve against
The current GraphRAG search performs well when the document includes clear statutory references.
For example:
“The accused was convicted under section 302 of the Penal Code.”
This sentence provides strong retrieval signals:
- Section 302
- Penal Code
- Convicted
The system can match the Act title, retrieve statutory content and connect it to relevant precedent.
A professionally drafted petition may also mention:
- Code of Criminal Procedure
- Special Powers Act
- Evidence Act
- Specific section numbers
- Named offences
- Recognised legal doctrines
These terms make Act retrieval much more reliable.
Narrative files create a different problem
A layperson’s complaint may contain all the important facts but none of the legal vocabulary.
The document may describe:
- A dispute over property
- Threats made by another person
- A police arrest
- Money taken through deception
- A broken agreement
- A government decision affecting a licence
The facts may be legally significant, but the words may not match an Act title.
Because the current Act search is primarily lexical, it may return:
- No relevant Acts
- Weak matches
- Laws that coincidentally share a generic word
- Statutes that are related only indirectly
The precedent-search stage may still find similar cases because embeddings are better at recognising semantic similarity.
However, the analysis then becomes precedent-heavy and statute-light.
The confidence system correctly responds by lowering the result to medium or low.
The Legal Orchestrator therefore degrades safely, but it does not yet solve the underlying retrieval problem.
Doctrinal cases are even more difficult
Some cases turn on concepts rather than explicit Acts.
Examples include:
- Mens rea
- Natural justice
- Burden of proof
- Legitimate expectation
- Reasonable doubt
- Doctrine of necessity
- Procedural fairness
These concepts often live across judgments, commentary and multiple statutes.
The current legal graph contains structural entities such as Acts, sections and footnotes. Dedicated LegalConcept nodes have not yet been fully populated.
Without these semantic anchors, the graph cannot reliably move from:
“failure to establish criminal intention”to:
mens rea → related cases → relevant statutory provisions → evidentiary burdenThe model can still reason from precedents and its general knowledge, but the answer is less tightly grounded in the legal corpus.
The highest-leverage solution: extract the legal issues first
The strongest immediate improvement is not rebuilding the entire graph.
It is adding a small legal issue-extraction step before Act retrieval.
The system would read the narrative and return structured fields such as:
- Facts
- Acts explicitly mentioned
- Sections explicitly mentioned
- Possible offences
- Legal issues
- Relevant doctrines
- Procedural stage
- Possible remedies
The raw story:
“My motorcycle was stolen and the suspect was released.”
could become a structured retrieval query containing:
- Theft
- Criminal complaint
- Arrest
- Bail or release
- Recovery of property
- Evidence connecting accused to property
These high-signal legal terms would then be passed to the Act-search system.
This relatively small step could solve a large portion of the narrative-input problem.
The second improvement: semantic Act search
The next step is replacing or enhancing lexical matching with embeddings.
Lexical search asks:
Do the same words appear in the query and the Act title?
Semantic search asks:
Do the query and the Act represent similar legal meaning?
This allows the system to connect different expressions of the same concept.
For example:
“law governing intentional killing”could be semantically connected to the relevant provisions of the Penal Code, even when the user never writes “Penal Code.”
The best system would likely combine:
- Exact statutory matches
- Section-number detection
- Keyword search
- Embedding similarity
- Semantic reranking
- Graph relationships
Exact search protects precision.
Semantic search improves recall.
The graph explains relationships.
The third improvement: build the semantic legal layer
A mature legal knowledge graph should eventually include:
- LegalConcept nodes
- Authority nodes
- Court nodes
- Person and organisation entities
- Geographic jurisdictions
- Amendment relationships
- Definition relationships
- Doctrine-to-case relationships
This would allow the system to answer more difficult questions.
For example:
- Has this section been amended?
- Which Act defines this legal concept?
- Which related statutes may apply?
- Which authority administers this law?
- Does the provision still apply in this jurisdiction?
- Which doctrines appear in similar judgments?
This is the difference between a graph that maps legal documents and a graph that begins to model legal reasoning.
Transparency must remain part of the product
The system should not hide retrieval weakness.
When it cannot strongly connect a narrative to Bangladesh Acts, it should say so.
A useful user-facing message might be:
We could not confidently anchor this analysis to specific Bangladesh statutes. Adding the relevant Act, section or legal issue may improve the statutory analysis.
That message does two things.
It protects the user from false certainty.
It also teaches the user how to improve the next analysis.
The real goal is not to eliminate uncertainty
Legal systems contain ambiguity.
Facts may be disputed.
Evidence may be incomplete.
Judgments may conflict.
Statutes may have been amended.
Procedure may change the result.
A responsible legal-AI system should not pretend this uncertainty does not exist.
Its job is to make uncertainty visible, organised, and actionable.
That leads to the final question in this series:
Should legal AI ever be marketed as a verdict machine, or is its real future something more useful?