What if we designed contracts around how promises are performed—not simply how they are written? This article is based on the following video:
I recently accepted an invitation to join LexClinic Education as a director(VP) , beginning a new chapter in my work at the intersection of law, technology, and entrepreneurship.
My focus is legal engineering: translating legal obligations into processes and systems that people can understand, use, and, where appropriate, automate.
For me, this work grows out of a practical question: How can we make legal infrastructure more accessible to the people building something new?
Democratizing Legal Engineering
LexClinic brings law and computer science together through open-source educational materials, work involving ERC-7827 state-machine standards, AI-assisted roadmap interviews, and verifiable certifications.
We have begun developing a curriculum to help learners connect legal reasoning with computational thinking. Our first video introduces a shift in perspective:
What if we approached a contract as a performance, rather than simply a document?
Here are the central ideas—and why I believe they matter.
1. Beyond the Static Document
Legal education devotes substantial attention to interpreting and drafting contractual language. That foundation matters. But the document is only one part of the agreement’s life.
After signing, someone still has to track deadlines, verify conditions, deliver services, approve payments, and respond when circumstances change.
A well-written contract can still be expensive and difficult to administer.
Legal engineering asks us to consider those operational demands from the beginning: What must happen, who must act, and how will we know an obligation has been fulfilled?
One way to picture this progression is through transportation:
Traditional legal admin (Horse and Buggy): people manually interpret, coordinate, and carry out each step.
Mechanized processes (Modern Car): software assists with workflows, monitoring, and execution.
Autonomous (Self Driving Flying Car): defined events trigger specified actions, with human oversight and intervention where needed.
As with the progression from horse-drawn transportation to cars and autonomous vehicles, greater automation requires thoughtful design and appropriate guardrails.
2. Understanding Legal Performance and Software Runtime
In contract law, performance means fulfilling an obligation: delivering goods, providing services, making a payment, or carrying out another promised action.
In software, runtime is the period during which a program executes its instructions.
The connection is useful because both involve moving from a description of what should happen to actions that actually occur.
Consider a simple agreement: payment becomes due when a specified delivery is confirmed. That arrangement contains several elements familiar to software engineers:
A condition: delivery has occurred.
Evidence: confirmation that the delivery meets the agreed requirements.
An action: payment becomes due.
An exception: the delivery is disputed or fails inspection.
Identifying these elements makes an agreement easier to understand, administer, and potentially automate.
3. From Legal Obligations to Executable Workflows
Legal performance and software execution are not identical. Contracts operate within a legal and human context that code cannot fully capture.
But the analogy gives us a powerful design method.
Legal engineering translates suitable parts of an agreement into explicit rules, conditions, actions, and exception procedures. Instead of stopping at “What should this clause say?” We also ask:
How will this obligation work in practice?
Some steps may be automated. Others may require human judgment, negotiation, or dispute resolution. Good engineering accounts for both.
The goal is to connect the written agreement with a reliable process for carrying it out.
4. The Composer Metaphor
For law students encountering computer science, a musical metaphor can help.
Think of a contract as a score and its performance as the music:
Compose: Define the obligations, conditions, timing, and responses to unexpected events.
Play it: Establish the agreement and activate the relevant processes (sign).
Performance: Carry out the obligations, verify results, and address deviations.
Signing an agreement establishes commitments; performing it brings those commitments to life.
A legal engineer considers the entire composition: the score, the performers, the instruments, and what happens when someone misses a cue.
5. Reducing the Cost of Keeping Promises
The practical opportunity is to reduce transaction costs: the time, money, and effort required to coordinate activity and carry out agreements.
Clearer workflows and appropriate automation can reduce repetitive administration, make obligations easier to track, and help participants identify problems sooner.
That matters especially for entrepreneurs and organizations whose resources are limited.
I encountered these challenges firsthand before the pandemic, while developing a zero-waste protocol intended to help commercial businesses lower waste expenses and use resources more efficiently.
The project required more than a promising technical model. It also required workable agreements, a compliant funding structure, and a path through an established industry’s legal and operational constraints. Exploring token-based fundraising brought those challenges into sharper focus.
That experience helped shape the career I am building today. Entrepreneurs need guidance that identifies constraints and helps design viable paths forward. Legal engineering offers a way to bring those tasks together.
Time to Hit Play
Our goal at LexClinic is to help make legal engineering understandable, practical, and accessible—to connect legal education with the systems through which people actually fulfill their commitments.
The written agreement remains essential. Designing what happens after signing is equally worthy of our attention.
From paper to runtimes, the opportunity is to make promises easier to understand, perform, and trust.
Time to hit play:
Podcast:
Educational Disclaimer: I am a law school graduate and legal engineering educator, not a licensed attorney. This article is provided solely for general educational and informational purposes. It does not constitute legal advice, an offer of legal representation, or guidance for any particular legal matter. Reading this article or communicating with me does not create an attorney–client relationship. Consult a licensed attorney in the appropriate jurisdiction for advice about your specific circumstances.
Video Attribution: The original video discussed in this article was created by Kyle Smith using Google Gemini. This article presents my summary, interpretation, and commentary on the concepts introduced in that video.