TIMEANDTOKENS FIELD NOTES
Getting Started With Computational Law: What Should I Build, and How Should I Build It?
Start small, build a usable legal artifact, keep the authority visible, and test where rules, probabilistic decisions, and AI reasoning belong.
I get a lot of questions from people interested in computational law about how to get started.
I think the easiest way to approach that question is to divide it into two:
What shall I build?
and
How shall I build it?
Those sound simple, but they open up most of the important questions about computational law today — especially now that we have capable large language models, coding agents, new forms of probabilistic computation, and much better ways to evaluate whether any of this actually works.
What shall I build?
The best way to get started is to try building something. With the assistance of powerful AI agents like Claude Code and Codex, this has never been more accessible!
For a first project, my strongest advice is: start with something you already basically understand.
You do not necessarily need to be a lawyer or an expert in the subject. But you should choose a process you can more or less explain before you start building.
Think of something like contesting a parking ticket, determining which form to file for a particular administrative process, working through a relatively understandable eligibility question, or following some other bounded legal or governmental procedure.
If you start with an area where you do not have the faintest idea how the underlying process works, you create too many simultaneous problems. You are trying to learn the domain, research the law, understand the procedure, model it computationally, learn the technology, build the application, and determine whether the result is correct — all at once.
That is a terrible debugging environment.
So start with something reasonably familiar, and start smaller than you think.
One jurisdiction. One narrow process. One manageable question.
Build something you can actually use
For a first project, I also like building something with a simple web interface.
A webpage is easy for you to use yourself, easy to test, and easy to share with somebody else by sending a link.
And today you do not need to become a traditional software developer before doing this. Use Claude Code, Codex, or another capable coding agent as a building partner. Describe what you are trying to accomplish, work through the design with it, and let it help you implement and revise the application.
Dan Sito recently gave a presentation at our Computational Law program called “HTMLaw: Building Better Client Communications Through Code.” His basic point is important: coding models make interactive HTML practical as an ordinary legal communication format. Instead of assuming the final product has to be a memo, PDF, or email, lawyers can increasingly create interactive artifacts that communicate and apply information more effectively.
That is a good mindset for a first project. Build an artifact, not merely an analysis.
Computational law is bigger than rules as code
There is an older and still very valuable conception of computational law that asks how we can represent legal rules explicitly enough for software to execute them.
That leads naturally to decision trees, rules engines, declarative logic, expert systems, Rules as Code, and explicit IF/THEN structures.
There is a lot of law for which this is extremely useful.
If a rule really says:
IF these conditions are satisfied, THEN this consequence follows,
ordinary deterministic software may be exactly the right tool.
Do not use artificial intelligence where an if statement will do.
But I think computational law now has to be understood much more broadly.
A middle layer: bounded computational judgment
There are also tasks that are not deterministic but still have a tightly bounded answer space.
A new example worth watching is Jev, from TypeSafe AI. TypeSafe describes Jev as its first “System One Model.” Instead of generating open-ended prose, Jev takes information and answers questions whose possible outputs have been defined in advance. It can choose among specified alternatives, score something against a specified scale, or return a probability. Its answers are therefore probabilistic rather than deterministic, but they are structured so ordinary software can use them directly. TypeSafe opened Jev in early access in September 2026.
That is interesting for computational law.
There are plenty of places where a legal application might need something more intelligent than a hard-coded rule but substantially more bounded than “ask an LLM what to do.”
Is this document more likely to be category A, B, or C?
How strongly does this evidence satisfy a defined rubric?
Which workflow should this matter enter?
Is confidence high enough to proceed automatically, or should we escalate?
Jev is not deterministic logic. It is better understood as a possible bridge between deterministic software and open-ended reasoning: bounded probabilistic judgment embedded inside ordinary code.
Read TypeSafe AI’s introduction to System One Models and Jev.
And then there are large language models
This is the part I think is even more important.
A huge amount of law does not comfortably reduce to deterministic rules or narrowly bounded classification.
Legal work involves interpretation, analogy, issue spotting, synthesis, applying standards to messy facts, understanding context, distinguishing cases, recognizing missing information, constructing arguments, and exercising judgment.
Those are precisely the kinds of activities for which modern transformer-based large language models such as GPT and Claude have become remarkably capable.
And I think it is a mistake to treat this as somehow outside computational law.
A large language model is computing.
It is doing an enormous amount of computation, layer after transformer layer, operating over learned representations of language and context and increasingly using retrieval, tools, code execution, memory, and agentic processes as part of a larger system.
The fact that this computation is probabilistic, learned, and capable of working directly with natural language does not make it less computational.
It makes the computational design space much larger.
So computational law today should not mean only:
How can we translate law into explicit machine-readable rules?
It should also include:
How can we use machines capable of reasoning over law expressed in natural language?
And then the engineering question becomes extremely interesting.
We can put a capable reasoning model inside a deliberately designed legal process — a harness — with appropriate instructions, authoritative information, tools, authority boundaries, escalation conditions, logging, and evaluation.
Then we can test it.
For a particular legal task, supplied with the same relevant information and judged against the same success criteria, how does the AI system perform?
Where does it fail?
Where does it outperform the workflow we had before?
And, where appropriate, can we establish empirically that it performs as well as or better than the relevant human comparator — including lawyers performing the same defined task?
That is not a philosophical question. It is an evaluation question.
And that brings us to the second half.
How shall I build it?
Start with the actual authority
Before asking an AI to model the process, gather the materials that actually govern it.
I sometimes call this a source packet. By that I simply mean the specific authoritative materials you have decided form the basis of the project: statutes, regulations, court rules, official forms and instructions, relevant cases, agency guidance, or whatever else actually controls the process.
Keep track of:
- the jurisdiction;
- the version or effective date;
- where each source came from; and
- which proposition each source supports.
Then give those materials to Claude, ChatGPT, or another capable reasoning model.
A useful shorthand is:
Source packet first. Model output second.
The model can help you understand and work with the authorities. It should not silently become the authority.
Use the AI as a tutor, critic, researcher, and builder
Do not start by saying:
Turn this statute into an app.
Instead, work iteratively.
Ask the model to help you identify:
- the actors;
- the relevant actions;
- required inputs;
- definitions;
- conditions;
- exceptions;
- deadlines;
- outputs;
- missing facts;
- ambiguities;
- points that require judgment;
- places where deterministic logic works;
- places where a bounded probabilistic judgment might work; and
- places where richer reasoning is required.
Then ask it to challenge your representation.
What did you miss?
What happens at the boundaries?
Which assumptions did you accidentally encode?
Which rules conflict?
What happens when information is missing?
Where should the software say “I cannot determine this” rather than forcing an answer?
That last category is important. A good legal system does not necessarily answer every question. Knowing when the system should abstain, escalate, or request additional information is part of the design.
Build the evaluation while you build the application
Do not wait until the end and then ask whether the thing “seems to work.”
As you build each capability, build tests for it.
Include:
- ordinary cases;
- cases that should clearly fail;
- boundary cases;
- exceptions;
- missing-information cases;
- ambiguous cases; and
- deliberately adversarial examples.
Then record what you expected to happen and compare it with what actually happened.
This is the beginning of an eval.
For AI systems, this becomes particularly important because outputs are probabilistic. You are not merely debugging code. You are measuring the behavior of a system.
The current Anthropic guidance on agent evals makes essentially this point: an eval is a defined task, inputs, success criteria, trials, graders, and outcomes; for agentic systems the evaluation should examine the model together with the harness in which it operates.
That is also why I have been working on Lake Merritt and Custom AI Evals.
A good starting point is:
The goal is to move from:
“This seems pretty good.”
to:
“Here is the task. Here are representative examples. Here is what success means. Here is how the system performed. Here are the failures. Here is what changed, and here is whether the change improved things.”
Once you have that, you can change prompts, models, tools, retrieval systems, workflows, or agent architectures and determine whether you actually made the system better.
A starter prompt
If you are beginning a project like this, you could create a Claude or ChatGPT Project, add your source materials and some of the readings below, and start with something roughly like this:
Help me turn this into a small, rigorous computational-law project.
Do not simply do the project for me. Act as my tutor, collaborator, critic, and testing partner.
Help me understand the underlying process and make me justify important decisions from authoritative sources.
Identify which parts can safely be represented as deterministic rules, which require bounded judgment, and which require richer legal reasoning.
Explicitly identify ambiguities, assumptions, missing information, exceptions, and situations in which the system should refuse to decide or escalate for human judgment.
Help me build a usable prototype, preferably with a simple web interface.
At the same time, help me create an evaluation set containing ordinary cases, boundary cases, exceptions, missing-information cases, and adversarial cases.
I want tests capable of proving my implementation wrong, not merely examples that demonstrate that it works.
Then start building.
Do not spend six months studying before making anything.
Use the project itself to tell you what you need to learn next.
A starter reading and experimentation list
You do not need to read all of this before beginning. Point Claude or ChatGPT at these resources as appropriate and use them as companions to the project.
Lake Merritt / Custom AI Evals
Start with my own practical work on developing task-specific evaluations:
This is especially relevant once you have something working and need to move from experimentation to systematic measurement.
Jason Morris — Blawx: Rules as Code Demonstration
Jason gives an unusually concrete demonstration of taking explicit rules, representing them computationally, testing them, and connecting them to a web application. It is very close to the classic version of the project described in this post.
Read Blawx: Rules as Code Demonstration.
Michael Genesereth — Computational Law: The Cop in the Backseat
Michael Genesereth is one of the foundational figures in computational law and computational logic and helped establish Stanford CodeX. This is useful for understanding the deeper idea of mechanizing legal analysis rather than merely digitizing legal documents.
Explore Michael Genesereth’s computational-law work in Stanford’s CodeX materials.
OECD — Cracking the Code: Rulemaking for Humans and Machines
A useful overview of Rules as Code that takes seriously both its potential and its limitations.
Margaret Hagan — Design Process for Lawyers
A good reminder that before formalizing a process, you should understand the users, problem, workflow, and intervention you are actually designing.
Read Design Process for Lawyers.
LegalBench
LegalBench is a collaborative benchmark designed specifically to examine what kinds of legal reasoning foundation models can perform. It is helpful for seeing how broad ideas such as “legal reasoning” can be decomposed into testable tasks.
Stanford RegLab — Hallucination-Free?
This work is a useful example of rigorous empirical evaluation of legal AI systems rather than relying on demos or impressions. The researchers constructed a preregistered evaluation to measure reliability across commercial AI legal-research systems.
Hamel Husain and Shreya Shankar — AI Evals: Everything You Need to Know
A very practical resource on finding failure modes, designing useful evals, and improving AI products through actual measurement.
Read AI Evals: Everything You Need to Know.
Anthropic — Demystifying Evals for AI Agents
Particularly helpful once your project moves beyond a single model response and becomes an agent operating with tools, state, and multiple steps.
Read Demystifying Evals for AI Agents.
OpenAI — Evaluation Best Practices
Useful practical guidance for designing representative tests and continuously evaluating changes rather than relying on “vibe-based” evaluation.
Read OpenAI Evaluation Best Practices.
TypeSafe AI — Jev
Jev is worth experimenting with precisely because it occupies a different position from both deterministic rules engines and open-ended reasoning models: unstructured information in, predefined typed probabilistic decisions out. TypeSafe currently describes access as early access.
Explore Jev and join TypeSafe’s early-access program.
What should you have learned when you are finished?
The most interesting result of your first computational-law project should not merely be:
“It works.”
You should be able to explain why it works and where different kinds of computation belong.
Which parts of the process were truly deterministic?
Where did explicit rules improve the system?
Where did formalization become awkward or brittle?
Where did you need a bounded probabilistic judgment?
Where did you need richer language-model reasoning?
What information did the system require?
Which sources supplied its authority?
Where should it abstain?
Where must a human exercise judgment?
What did your evals reveal that you would not have noticed by simply using the application yourself?
And what happened when you compared the system against the human process it was intended to assist or improve?
That, to me, is where computational law has become especially interesting.
The original project of computational law — making legal rules and processes tractable to computation — remains tremendously valuable.
But we now have forms of computation that can work directly with the language, ambiguity, context, and reasoning that characterize much of law.
So the frontier is no longer simply turning law into code.
It is designing systems in which deterministic computation, probabilistic decisions, large language model reasoning, human judgment, authoritative legal information, and rigorous evaluation all work together.
Start small.
Build something.
Keep the authority visible.
Make the boundaries explicit.
And build the tests as you go.