India’s justice and governance ecosystem is moving steadily towards digital platforms, AI-enabled workflows and technology-led dispute resolution. But the next challenge is no longer simply making technology available. It is about building systems that reflect the way courts, tribunals, regulators, enterprises and citizens actually interact with institutions. In this conversation with Tech Achieve Media, Mansi Omar, Co-Founder and Chief Strategy Officer, Jupitice Justice Technologies, discusses the gaps that remain in digital justice, the challenges of building technology for institutions with very different processes, the role of AI in decision-making, and why the next phase of JusTech will need to focus as much on accountability and process design as it does on technology.
TAM: Having worked closely with courts, regulators, and enterprises, what are the biggest gaps still holding back India’s justice and governance ecosystem beyond technology availability, things like language access, on-ground digital infrastructure, and court communication design?
Mansi Omar: Technology availability is only one part of the problem. The bigger challenge is designing technology around how institutions actually function and how people interact with them. Take language, for example. A digital system is of limited use if a litigant cannot understand a notice, a hearing update or what action is required next. The same applies to communication design. In justice and governance, a notification is not simply a message; it can have procedural or legal consequences. The system therefore has to make the information clear, timely and actionable.
There is also a gap between putting an existing paper process online and actually redesigning the process for digital use. Courts, tribunals, regulators and government bodies have different rules, roles, approval structures and ways of working. Technology has to account for those differences rather than forcing every institution into the same template. Our experience has been that institutions need technology that understands their processes, preserves the required checks and creates a clear record of what happened at every stage. That is a more difficult problem than simply putting forms and files online.
TAM: Jupitice works with very different buyers, courts, regulators, enterprises on one platform. What’s been the hardest part of getting such different institutions to adopt and standardize on the same system?
Mansi Omar: We don’t try to standardise the institutions. That would defeat the purpose. A High Court, a regulator and a bank have very different requirements. A court may need judicial hierarchies, cause lists, hearing schedules and order management. A financial institution may need recovery workflows, compliance checkpoints and customer dispute processes. What we have tried to standardise is the underlying technology, while allowing the institution to configure the rules, roles and workflows it needs.
That thinking came from our experience of working with institutions such as the Rajasthan High Court, MACT tribunals and RERA authorities. We realised fairly early that technology cannot simply digitise paperwork. It has to understand the rules and procedures that sit behind the paperwork. This is also the reason behind our “Configure, don’t code” approach. We build the common technology layer once and allow the institution to configure how that layer works for its own requirements.
TAM: With Jupitice now supporting over 23 million case journeys across 180+ institutions, what was the turning point where you felt the model had truly proven itself at scale?
Mansi Omar: For us, it wasn’t one particular customer or one particular number. The real test was whether the same underlying platform could work across institutions that operate very differently. When we started, JusTech was not an established category. We were building something for which there was no obvious benchmark. Our early work with courts and other institutions showed us that there was a need for something broader than individual software products.
The stronger validation came when we started seeing the same platform being used across courts, government bodies, regulators, financial institutions and enterprises, with the rules and workflows configured differently for each. Today, the numbers like more than 23 million case journeys, over 10 million users, 180+ institutions and more than 4,000 ADR professionals give us confidence that the underlying approach works at scale. For me, however, scale is not just about the number of users. It is about whether the technology continues to work reliably when the processes become more complex and the consequences of an error become more serious.
TAM: Jupitice’s “Trust Layer” is built to keep AI assistive rather than decision-making. How does that design compare with where the Supreme Court’s draft AI Regulations for Courts, 2026 are pushing the rest of the industry?
Mansi Omar: The principle is very similar: AI can assist, but responsibility cannot be handed over to the machine. Our position has always been that AI should support the person taking the decision rather than become the decision-maker. For example, our AI capabilities can assist with legal research, document analysis, drafting, summarisation, transcription, translation and identifying potential risks. The authorised human user remains responsible for the decision.
That distinction becomes particularly important in justice. If an AI system produces an incorrect legal summary or recommendation, the question is not only whether the output was wrong. We also need to know who reviewed it, what information the system relied upon, whether the output can be examined and how the error can be corrected. That is why we believe safeguards have to be part of the system from the beginning. The issue is not whether AI will ever make a mistake; the issue is whether the institution has a way of identifying, reviewing and correcting that mistake.
TAM: How do you see the market for AI adoption evolving across the legal, justice, and governance ecosystem?
Mansi Omar: The first phase was largely about experimenting with AI in legal research, summarisation, drafting, transcription and similar tasks. The next phase will be different. AI will increasingly sit inside the actual processes through which institutions handle cases, compliance, disputes and other decisions. That will create a much higher bar for adoption. An organisation cannot simply put an AI tool next to an existing process and call the job done. It needs to decide what information the system can access, what the AI is permitted to do, where a human has to intervene and how the activity is recorded.
I also expect adoption to spread well beyond courts. We are already seeing demand from regulators, financial institutions, government departments and large enterprises. The common thread is not the sector. It is the presence of complex processes involving rules, multiple stakeholders, approvals and accountability. This is where we see the larger opportunity for JusTech. LegalTech has traditionally focused on helping lawyers and legal teams. JusTech looks at the wider system of courts, tribunals, ADR bodies, regulators, governments and enterprises that make or support decisions with legal and regulatory consequences.
TAM: Jupitice’s platform spans litigation management, trust and quality assurance, and document execution, connected layers rather than separate tools. How do you think about building coherent infrastructure versus a collection of features?
Mansi Omar: We start with the process, not the feature. A legal matter rarely stays within one function. It can begin with a notice, move into litigation or dispute resolution, involve document execution and compliance, and eventually result in an order, settlement or other legally relevant record. If every stage sits in a separate system, the organisation ends up moving information between applications and losing context along the way.
Our approach is to build common underlying capabilities like workflows, rules, forms, documents, approvals, hearings, notifications and reporting and then use those building blocks for different products and institutional requirements. That is what makes our products connected rather than just a collection of features. The same underlying architecture can support litigation management, ODR, compliance or document execution, while the actual workflows are configured for the institution using them. The longer-term objective is to build what we call an institutional operating system, something that can accommodate new processes and requirements without the organisation having to start again with a new technology stack every time.
