Legal Engineering, Part 2
Definitions:
Data Primitives: A contract’s information can be expressed through simple types of values…
Number: An amount or quantity, such as
500.String: Text, such as
"Buyer"or"Payment approved".Boolean: Either
trueorfalse, such as whether payment has been received.
JSON (JavaScript Object Notation) organizes these values into structured text that software systems can exchange.
Unix philosophy encourages small programs that do one thing well, work together, and communicate through text. JSON follows that same practical idea: using text as a common way for different tools to share information.
This article is based on this material from LexClinic:
In my first article, I introduced Lex Clinic’s shift from paper to runtimes. This second installment explores the software concept behind that shift: what happens when written instructions become an operating process.
1. From Paper to Performance
Much of legal work revolves around documents: drafting, reviewing, interpreting, and revising language. Those documents set the framework for action, but they usually depend on people and institutions to take the next steps.
Legal engineering adds another design question:
Which parts of this agreement can become instructions that a computer can reliably execute?
Imagine an agreement that releases a payment after a delivery is verified. Its operational structure might look like this:
Agreement → Running software → Check conditions → Authorize payment
Each transition requires a decision. What counts as delivery? Who can confirm it? What evidence is acceptable? What happens if someone disputes the confirmation?
The work begins by making those assumptions explicit.
This moves from a static document to a dynamic system: an agreement supported by machinery that can monitor events, evaluate conditions, and perform authorized actions.
2. Software Runtime: Where Instructions Become Action
Runtime refers to the period when a program executes. A runtime environment provides the resources and services it needs to run.
For legal engineering, the useful distinction is between instructions that have been written and instructions that are actively being carried out.
Consider a payment workflow. Software might receive a delivery confirmation, check it against the agreement’s requirements, and send a payment request through a bank’s application programming interface, or API—a defined way for software systems to communicate.
A property transaction offers another useful comparison. The written agreement describes when possession should transfer. Performance includes handing over the keys. In a carefully designed digital-access system, software could automate a comparable access step after the required approvals.
The document describes the commitment. The running system helps perform it.
The composer metaphor from the first article applies here:
Compose the rules → Activate the system → Monitor the performance
The designer sets how the parts should work together, reducing the need to manually coordinate every routine action. Human judgment remains essential for exceptions, disputed facts, and decisions the system is not authorized to make.
3. The Roots: From Legal Markup to Computer Markup
Lawyers already understand the practice of marking up a document: identifying provisions, proposing changes, and making the document’s meaning clearer.
Charles Goldfarb helped bring structured documents into computing. Working with Edward Mosher and Raymond Lorie at IBM, he co-developed Generalized Markup Language, a predecessor to SGML.
The connection is easy to grasp: marks that help people understand a document become tags that help computers recognize its parts. A heading, paragraph, or clause can be identified explicitly instead of being buried in a page of prose.
Legal redlining and computer markup serve different purposes, but the familiar act of marking up a contract provided a useful bridge between them.
For legal engineering, the next question follows naturally: once a computer can recognize the structure of an agreement, which instructions can it help carry out?
Nick Szabo approached a related problem through transactions. His 1994 writing on smart contracts explored how computerized protocols could execute contractual terms and reduce the costs of coordination and enforcement. The idea preceded modern blockchain platforms; it was broader than cryptocurrency or decentralized-network incentives.
Together, these histories illustrate a recurring opportunity: turning structured descriptions of relationships into systems that can act on them.
Why text still matters
Another useful foundation comes from Unix: build small programs that perform focused tasks, work together, and communicate through text streams. This approach supports composition—connecting relatively simple tools to accomplish more complex work.
Plain text is not guaranteed to remain useful forever. Its meaning still depends on documentation, encoding, and context. But open, well-documented text formats can make information easier to inspect, exchange, and migrate between systems.
One example is JSON, short for JavaScript Object Notation. JSON represents structured data using text. It can carry names, amounts, lists, and true-or-false values between applications. It is a data format, not an executing program.
For an AI-connected legal workflow, that separation is valuable: a structured record can move between tools while each tool performs a defined task.
The durable design principle is straightforward: make information understandable beyond the application that first created it.
4. Logic and Data: The Distinction That Makes Automation Work
Before designing a smart contract, we need to distinguish the information a system holds from the rules that act on it.
Data describes the situation. Logic determines what the system does with it.
For example:
A string represents text, such as a party’s name.
A number represents a quantity, such as a payment amount.
A Boolean represents either
trueorfalse, such as whether an approval has been recorded.
These are basic JavaScript data types. Their usefulness comes from how program instructions read and evaluate them.
A spreadsheet can also calculate values and support automation. The distinction is therefore not simply “spreadsheets are passive; JavaScript is active.” A value becomes operational when a running process uses it to make a decision or perform an action.
Assignment and comparison
Small symbols can change a program’s behavior substantially:
JavaScript symbolFunction=Assigns a value==Compares values, allowing certain type conversions===Compares values without type conversion
In a simple assignment such as amount = 500, the value on the right is assigned to the variable on the left. In a comparison such as amount === 500, the program asks whether the value matches.
This is a useful adjustment for anyone accustomed to reading contractual prose: punctuation is now part of the operating machinery.
The “and/or” problem
Legal drafting often accommodates uncertainty through context, qualifications, and standards. Executable rules require us to specify how each condition affects the result.
Suppose payment requires delivery confirmation and approval. Both must be present.
If either of two authorized approvals is sufficient, the rule uses or.
But what happens when an approval is missing, disputed, or withdrawn? Those situations need their own treatment. A system should not silently convert “unknown” into “false” when the distinction matters.
This is where legal reasoning contributes directly to engineering: identifying ambiguity, distinguishing exceptions, and deciding when a process should pause for human review.
Separating data from decision rules can also make updates easier. A revised deadline may require changing a value; a new approval requirement may require changing the logic. Neither update should be assumed safe without review.
5. Three Stages of Legal Infrastructure
The transportation metaphor offers a useful way to picture this development.
The horse-and-buggy stage: manual coordination.
People interpret the agreement, move documents between participants, check conditions, and arrange performance.The automobile stage: mechanized assistance.
Software accelerates drafting, signatures, recordkeeping, and administration. People still coordinate many decisions, while greater speed and scale create new demands for oversight.The autonomous-vehicle stage: greater operational automation.
Systems handle more routine steps within defined boundaries, escalating exceptions and recording what happened.
The flying car is an image of possibility, rather than a claim that legal systems can become entirely self-regulating. Increased autonomy makes the design of permissions, evidence, accountability, and intervention more consequential.
These stages also coexist. The practical task is choosing the right degree of automation for the obligation.
Two Paths into Legal Engineering
People can enter this work from either direction.
Engineers can develop the legal literacy needed to understand obligations, evidence, and institutional constraints. Lawyers can develop the computational literacy needed to model conditions, information, and execution.
Neither path requires one discipline to absorb the other. The opportunity lies in making them work together.
In my work with LexClinic, I am interested in that translation: helping people connect the meaning of an obligation with the design of the process that carries it out.
A useful system must answer more than “Does the code run?” It must also ask: Does it reflect the intended arrangement? Can participants understand its decisions? What happens when the facts are wrong or the circumstances change?
That is the deeper significance of runtime.
We are learning to compose the conditions under which promises become performance.
Part 1:
From Paper to Runtimes
What if we designed contracts around how promises are performed—not simply how they are written? This article is based on the following video:
Educational disclaimer: I am a law school graduate, not a licensed attorney. This article provides general educational information about legal engineering and software concepts. It is not legal advice or an offer of legal representation and does not create an attorney–client relationship. Consult a licensed attorney for advice about a specific legal matter.