At the October 15 CodeX Group Meeting, two legal-tech builders showed opposite ends of the technical spectrum: one compiles contracts into a formal model of what they do, the other lets lawyers describe an app in plain English and get a working tool.

Roland Vogl, CodeX Executive Director, hosted. The presenters were Prashant Dubey and Narain Dubey, co-founders of Vichaara AI, a neuro-symbolic contract reasoning engine, and Brad Neal, CEO of BuildLegal, which turns plain-English descriptions into legal web applications.

Watch Vichaara and BuildLegal Presentations

Vichaara AI: from what a contract says to what it does

Vichaara argues that most legal AI tools answer “what does this contract say?”, while the work lawyers actually do depends on “what does this contract do?”

Prashant Dubey has spent more than 25 years in legal technology, across discovery and litigation and then contract management. He founded a contract management company that Elevate Services acquired, and he was most recently chief strategy officer at Agiloft. Narain studied philosophy and economics at the University of Chicago, worked in strategy consulting, and now leads product. “Vichaara” is a Sanskrit word for deep reasoning, and the talk’s title, “How to Do Things with Contracts,” nods to J.L. Austin’s How to Do Things with Words.

The problem

Practitioners told the team that they are under steady pressure to produce more per person, and that they want transparency and traceable fact patterns. Yet they are adopting generative AI tools that are fundamentally stochastic. Three complaints came up repeatedly:

• The same contract and question can produce different answers on different runs.
• There is no audit trail showing why an answer was given.
• Lawyers end up rechecking everything, which erodes the productivity gains, and they worry that errors are silently carried into executed contracts.

The theory behind the design

Narain walked through three legal thinkers who shaped how Vichaara models a contract:

• H.L.A. Hart: giving people the power to make binding rights and duties makes each of them a “private legislator,” so a contract is private legislation with its own internal logic.
• Wesley Hohfeld: legal positions reduce to fundamental relations, much as different-looking fractions reduce to a common form. Clauses drafted in different words can therefore be compared on the same basis.
• Arthur Corbin: interpreting the language of a contract is distinct from construing its legal operation, which comes from how the underlying relations move and change.

Working with contract scholars and practicing commercial lawyers over several rounds, the team defined eight primitives of commercial contracting. The primitives act on one another, and that interaction defines the document’s legal operation. The talk did not list all eight.

One example was a clause letting the disclosing party approve additional recipients of confidential information in writing. Vichaara reads it as a power held over the prohibition on disclosure, conditioned on the form of the approval, and bounded by the contract’s confidentiality terms. That one clause becomes four blocks and three links. A full contract becomes hundreds of linked elements, and that structure is what the system reasons over.

How it works

Vichaara uses what it calls neuro-symbolic compilation, run once per draft. A language model parses the text up front and, at the end, articulates outputs in a bounded way. The structure in between is built deterministically, using hundreds of rules and the eight primitives as the schema. Each answer is then a computation over that structure rather than a fresh reading of the text. Narain noted that computable contracts are not a new idea (he cited Harry Surden, a CodeX fellow, from the early 2010s), but earlier efforts required hand-authored structure or contracts born as data.

Where it applies

Prashant described use across the contracting workflow:

• Drafting: ask for the structural gaps in a template or incoming third-party contract before negotiating.
• Negotiation: after a redline comes back, check whether the contract is still structurally sound and operative.
• After signing: extract the practical rules, such as what must be done, and in what order, to claim a credit when a vendor misses an SLA, and connect that to finance and accounts-payable systems to reduce contract value leakage.

Questions for Vichaara

Participants pressed on where the approach might break, and the answers kept returning to one design rule: surface uncertainty rather than hide it.

• Is the model limited to certain contract types? No. It was designed to be contract-type agnostic, covering anything from a two-party NDA to an ISDA or a power purchase agreement. Genuine ambiguity, market context and governing-law questions are flagged for the lawyer instead of being silently resolved.
• How is a wrongly compiled clause kept from producing a confident wrong answer? The compile step is symbolic. Vichaara and its partners built a large set of attorney “ground truth,” in which lawyers blind-annotate the structure they expect from a contract and then mark the system’s output correct or incorrect. When the system cannot decide deterministically, it steps back. No numerical accuracy figure was given in the session.
• Does anything get dropped if it doesn’t fit the eight primitives, such as liability caps? The team said it has not yet met a case that some combination of the primitives could not model, and that anything that doesn’t fit is surfaced to the user, because silently dropping content would undermine trust.
• What about vague terms like “reasonable efforts”? These are treated as open texture and left to human judgment, with an audit trail showing each decision so the user can verify the steps.
• What about the choice of logic? One participant raised formal logic families (temporal logic of actions, cognitive event calculus, deontic logic, first-order and frame logic), plus scaling limits as reasoning depth grows and how well generated language can be reconstructed from the symbolic form. Narain said he is not the primary technical lead, but that Vichaara checks generated natural language back against the symbolic structure. He took the suggestions to bring to the engineering team.
• What is the end goal? Prashant said the aim is to ground contracts in fundamental structure, not to solve everything. Organizational policy, materiality judgments and deliberate gaps left as negotiation leverage stay with humans. He added that agentic contracting workflows would compound the risk if they were not grounded in that structure.

BuildLegal: “Lovable for lawyers”

Brad Neal’s pitch was deliberately the opposite of the first talk: BuildLegal is meant as a “gateway drug” that draws lawyers who don’t think of themselves as technical into building software.

Brad was a software engineer before law school and a philosophy major, and he loves teaching. This was his second CodeX presentation. The first came when he was a 3L just starting his company, a law-student study platform that he said is now in 194 of 196 law schools. He described BuildLegal as a side project and wasn’t sure it would become a business.

What it does

A user describes the tool they need, and BuildLegal turns it into a working web app:

1. Describe it. A sample prompt was an NDA generator: the lawyer enters the parties, effective date and what counts as confidential, and gets a standard mutual NDA as a PDF.
2. Refine it. For a half-formed idea, the tool first asks clarifying questions about scope and design, then summarizes the plan.
3. Build it. The user presses Build. BuildLegal sets up a sandbox, and agents with tool access, similar to Cursor, write the app, a process that takes a few minutes.
4. Deploy it. A deploy button publishes the app on Vercel at a generated URL. The app’s requests go through BuildLegal’s backend, which checks authorization and stores data in a database BuildLegal controls.

The live build hit an error partway through, which Brad took in stride, and it recovered. He then edited the finished app by prompt (“make the background red”) to show how changes work.

Built for lawyers

What separates it from general tools like Lovable, Brad said, is a set of pre-built lawyer-centric “skills”: redlining, a CourtListener integration, and documents that always come out in Century Schoolbook, his legal-writing-class font of choice. Apps can also email the lawyer and include a built-in inbox, which suits an intake form where prospective clients describe their problem.

Brad was inspired by a friend who manages construction sites and isn’t technical. After Brad pointed him to Lovable, the friend called back about 36 hours later with a tool that Brad said would have taken him months to build as a professional developer. Brad’s hope is that lawyers have an advantage here because they know their own problems better than technologists do.

Questions for BuildLegal

• Who holds the data? Users can always download the code, and Brad expects serious projects to outgrow the platform, as they do with Lovable. The data belongs to the user. BuildLegal hosts the database for now because he thought less could go wrong that way. The product isn’t yet open for general signups, and he invited the group to try to break it and send feedback through the green button in the app.
• Which model powers it, and can users choose? It currently uses a recent frontier model. Letting users pick the model is on the roadmap.
• Could it include document assembly? A participant suggested building in document assembly, with a lawyer’s precedent clauses and form-filling. Brad liked the idea and said it would fit as another “skill” that the agent consults when planning an app. He floated a statute-and-regulation research tool as another.
• Does it connect to legal research? The CourtListener integration is a first, naive version that uses Brad’s own API key, so he expects to hit rate limits if usage grows. A participant mentioned a Hugging Face collection of statutes from around the world, and another described trying to build a judgment-interest calculator that needs Florida statutory rates.
• Where is it going? Brad is also considering an education track, possibly a consulting pipeline that helps people get started and then brings in more experienced partners, or folding BuildLegal into his law-student company. He closed with his philosophy professor’s line that the proof is in the eating of the pudding, and said everybody should taste some pudding.

The common thread

Both talks were about making AI useful to lawyers without asking them to trust a black box. Vichaara does it by moving the reasoning out of the language model and into an inspectable structure, and by flagging ambiguity for a human. BuildLegal does it by lowering the barrier so that lawyers can build and test their own tools, since they know the problems best.