LawBridge: Building Trust into Legal AI

Written by Law Bridge (Alexandra Tran, Benjamin Dawson, Richard Monteiro and Hans Raettzen)


At Hack the Law Cambridge, hosted by King’s Entrepreneurship Lab at Cambridge Judge Business School, we built LawBridge and were honoured to receive Best Solution for the Linklaters challenge as well as the Popular Vote Prize.

The experience was intense, generous, and genuinely energising. What made it stand out was the seriousness of the problems. The challenge briefs came from people working at the edge of legal practice, where AI is already changing how lawyers research, advise, review, and manage risk.

For our team, LawBridge became a way to explore one of the central questions in legal AI: how do you make AI useful enough for professional work, while giving lawyers the reassurance, evidence, and control they need to rely on it?

Choosing the Hard Challenge

We chose the Linklaters challenge, From Maze to Map: Navigating Regulatory Regimes, because it felt difficult in the right way.

Regulatory compliance is rarely a clean research task. A lawyer advising a client may need to work across primary legislation, secondary legislation, regulatory guidance, codes of practice, case law, legislative debates, changing obligations, and client-specific evidence. Often, this happens across more than one jurisdiction.

The challenge is not simply finding documents. It is understanding how those documents relate to each other, what authority they carry, what obligations they create, and which facts matter for a particular client.

This is where legal AI becomes most demanding. A fluent answer has little value if a lawyer cannot trace it, test it, or understand its legal basis. A legal team needs source grounding, hierarchy, provenance, confidence, review status, and a clear path back to the underlying material.

That was the problem we wanted to work on.

Speaking to the People Behind the Problem

One of the most valuable parts of the hackathon was being able to speak directly with the sponsoring legal team.

These conversations shaped the product. It is easy in a build sprint to fall in love with an elegant technical idea and then retrofit it to the brief. Speaking with the challenge sponsors helped us begin from the professional need instead: lawyers need to move quickly across complicated regulatory regimes without losing the discipline of legal reasoning.

That pushed us away from building another chatbot over legal documents. We wanted LawBridge to feel closer to a compliance review workspace, where legal sources, obligations, client evidence, and review gaps could sit together in a structured and traceable way.

Why Structure Mattered and Clear Roles Made our Team Stronger

The central idea behind LawBridge was simple: AI reads evidence. The graph structures law. The lawyer signs off.

Large language models are powerful for reading, extraction, and synthesis. In legal compliance, however, model output needs a more robust workflow around it. We wanted the system to make clear where a finding came from, which source supported it, what evidence was being relied on, and where a lawyer still needed to review or decide.

LawBridge was built around a regulatory knowledge graph and dynamic compliance database. The AI layer helped process legal and client material. The graph gave structure to sources, obligations, relationships, and evidence gaps. The review workflow kept the lawyer in control.

For us, this was the most important design choice. The aim was not to remove uncertainty. The aim was to make uncertainty visible, navigable, and reviewable. The more serious the use case, the more important that becomes.

As we developed this solution, our strongest team decision was to let each person do what they were best placed to do.

Not everyone needs to code. In a short sprint, trying to make everyone touch the tools can slow down the team. Legal analysis, product judgement, and pitch clarity are all part of the build. Our legal lead shaped what the product needed to do and why it mattered. The technical side focused on turning that into a working system.

The best decisions came from the exchange between those perspectives.

For future hackers, this is worth taking seriously. Bring the domain expert into the build from the beginning. Let them define the professional need. Then let the builders translate that need into something real.

Moving Fast without Losing the Shape

Time disappeared quickly.

Once we had chosen the direction, we had to be disciplined. We assigned responsibilities early, trusted each other to own them, and kept returning to one question: what does the demo need to prove?

That question saved us from overbuilding. Scope is part of the product. Three clear features that show the core insight are stronger than ten unfinished ideas.

Structure did not slow us down. It gave us the confidence to move faster.

Showing the Product and Centring Community

The demo was its own lesson.

A working product carries a different kind of force. Judges can see the idea rather than imagine it. But live demos also consume time, and every click has to earn its place.

Our takeaway is simple. Show the problem. Show the product. Show the moment where the value becomes obvious. The best demos do not show everything. They make the central insight hard to miss.

We know how this approach supported our Challenge win but, for us, winning the Popular Vote was just as great a deal because the event was never only about our own build. We met other teams, spoke with mentors, learned from judges and sponsors, and had conversations that changed how we thought about the problem. Once the clock starts, it is easy for teams to become inward-looking. We tried to stay open.

The relationships formed during the event mattered. So did the generosity in the room.

A Note to Next Year’s Hackers

Read the challenges early. Choose a problem you care about. Talk to the sponsoring team before you build too much. Find people with complementary skills, even if you only meet them at the first coffee break. Decide who owns what. Protect the scope. Build something real enough that people can understand the value.

And if one challenge feels a little too ambitious, it might be the right one.

Back yourselves.


Alexandra Tran is an AI and robotics engineer and the founder of Lexis Labs. Her work spans legal technology and engineering innovation, with a focus on translating emerging technologies into practical solutions to complex real-world challenges. For more than a decade, she has built interdisciplinary innovation communities through initiatives involving BMW Group, NASA, and Engineers Without Borders.

Mattias Rättzén is a practising intellectual property and AI lawyer qualified across the UK, US, and EU. He advises organisations on emerging technologies, AI governance, and legal innovation, while undertaking part-time doctoral research in AI and law at the University of Cambridge. His work focuses on bridging legal expertise with advanced technology to develop trustworthy, practical solutions for the evolving regulatory landscape.

Richard Marques Monteiro is a PhD candidate in Information Engineering at the University of Cambridge, where his research explores embodied intelligence and continual learning for next-generation robotic systems. His interests lie at the intersection of machine learning, robotics, and adaptive autonomous systems, with a focus on developing intelligent agents capable of learning continuously from real-world interaction.

Benjamin Dawson is an MSc student in Management, Technology and Economics at ETH Zürich and a founder building AI-powered consumer products. His work focuses on designing and deploying production-ready AI systems that transform cutting-edge machine learning into intuitive, scalable applications with real-world impact.

 
Next
Next

A Bet to Save Millions of Waste from Landfill: The Story of Surpluss