Learning to code the law, and why it matters.
0x41434f
Over the last few weeks, I’ve been exploring computational law, a field where legal systems meet logic and code. It is about translating legal concepts into structured formats that computers can understand. That includes automating legal processes, designing smarter compliance tools, and even encoding legal reasoning itself.
For me, it is not just an academic curiosity. It feels like a continuation of the work I have been doing in privacy, security, and compliance, and a new lens through which to think about fairness, access, and accountability.
This post is a snapshot of where I am starting, what I have learned so far, and how this connects back to everything I laid out in The 0x41434F Code.
I first came across the phrase “computational law” while reading about the intersection of legal theory and systems design. At first, it sounded abstract. But the more I read, the more it felt like a missing link, a way to bring clarity, logic, and even automation to areas of law that often feel opaque and overloaded. Coming from a background in cybersecurity and privacy compliance, I have always been interested in how rules are enforced, not just written. Computational law offers a new kind of toolkit for that question.
One of the core ideas that pulled me in is this: if the law is a system of rules, and computers are designed to work with structured rules, then why can’t we write law in a way that both humans and machines can interpret? This does not mean replacing lawyers with bots or putting judges in the cloud. It means designing systems where legal compliance, access to justice, and public understanding are improved through code, not obscured by it.
The book that gave me a real foundation was Law for Computer Scientists and Other Folk by Mireille Hildebrandt. It is not trying to turn engineers into lawyers. Instead, it offers a deep, thoughtful bridge between legal reasoning and computer science. It explains how law functions as an architecture, made up of interpretation, vocabulary, institutions, and competing forces, and why that matters to those building the infrastructure of the digital world. The book explores everything from the roots of legal theory to questions of privacy, cybercrime, copyright, and the possibility of legal personhood for AI. One idea that stuck with me is how modern law emerged in a world of print, but now faces pressure to adapt to a world of computation. That friction is precisely where so many questions I care about live.
I have been experimenting with SWI-Prolog, one of the most well-established open source implementations of the Prolog language. It is written in C and Prolog itself, supports nearly every platform, and even runs in the browser thanks to WebAssembly. At first glance, it feels minimal. But under the surface, it is an incredibly powerful tool, used across industries for everything from natural language processing to robotics, software verification, and even legal reasoning.
What drew me in was its ability to model rules and relationships with clarity. Instead of writing imperative logic, you describe facts and rules, then query what the system can infer. That framing mirrors the logic of legal systems more closely than most programming languages I have worked with. You do not tell it how to reach a conclusion. You define the conditions, and the system explores the possibilities.
I started small, encoding parts of Nigeria’s NDPR and mapping how it overlaps with international frameworks like the GDPR. Even a basic model, something like defining who a data controller is, what counts as personal data, and what lawful processing might look like, felt meaningful. Because once the rules are in place, you can begin to ask structured questions like, “Does this system have a valid basis for collecting this data?” and see how the logic responds.
It is still early, and the work is far from complete. But something about using Prolog for this clicked. It makes legal reasoning explicit, testable, and open to challenge. You start to see where laws contradict themselves, where ambiguity lives, and where clarity could lead to better systems.
Where this leads, I am not entirely sure yet, but I know where I want to take it. My goal is to build legal decision systems that can make law more accessible, testable, and adaptive. Not to replace human judgment, but to support it. To help policymakers, companies, and individuals navigate complex rules without needing a law degree. If I ever get a solid exit from one of my startups, I hope to go to law school and bring all of this full circle, blending legal training with years of technical and policy experience to help pioneer what some call legal knowledge engineering.
I have already started drafting business rules based on data protection and health regulations, trying to represent them as clean, modular, executable code. The aim is to build a system that can answer questions about compliance not just by flagging risks, but by showing the reasoning behind each result. Policy automation is one part of that. The other is simulation, using large language models and reasoning agents to explore edge cases, contradictions, and the long tail of regulatory complexity.
Right now, I am cleaning datasets to train a custom model on cybersecurity and data protection regulations. The goal is not just search or summarization. I want to develop a domain-specific language for modeling legal rules and combine it with a structured knowledgebase pulled from different jurisdictions. A kind of programmable legal substrate, one that could support everything from compliance checks to automated explanations, simulations, and even legislative drafting.
It is an ambitious idea. But it is one I keep coming back to. Not because it is trendy, but because I have seen how the gap between law and systems thinking leaves people unprotected, uninformed, and unheard. Bridging that gap might be one of the most useful things I can do.
This is just the beginning. I am still learning, still fumbling through code, still adjusting how I think about law and systems and the space between them. But I keep coming back to this work, not because I have it figured out, but because I believe it matters.
If we want laws that are more just, more accessible, and more adaptive, we need better ways of understanding and modeling them. That starts with learning the grammar of both code and law, and imagining what is possible when the two begin to speak the same language.
I will keep sharing what I learn. And if you are working on anything similar, or want to, I would love to talk.