What this project is for
The proposed definition holds that legal engineering should be something people can demonstrate. This project tests that claim in the most direct way available: it builds a working model of legal service delivery and makes every part of it open to inspection.
Simulating legal service delivery with skills
Legal services are delivered through systems: a request arrives, someone clarifies it, research and drafting happen, a reviewer decides, and the outcome is recorded. Most of that system is invisible. It lives in habits, inboxes and the memory of whoever did it last.
This project rebuilds that system out of skills: packaged methods that an AI host can follow, each with defined inputs, outputs and checks. A lawyer's request becomes a workflow; each step is performed by a person or by a skill; each decision stays with the person who owns it; and every step leaves a record a reviewer can open.
"Simulating" is meant precisely. The matters are synthetic and the tooling is not a production service. But the methods are real, the checks run, and the records are the kind a supervising lawyer would need. The point is to see what legal service delivery looks like when it is designed deliberately, and where it breaks.
Three goals
Make the legal engineer's role concrete. The process the project follows, from a lawyer's account of their work through to a released workflow, is offered as an entry gateway into how a legal engineer functions. Following it means doing the core of the job: understanding the work, designing a better process, choosing or building the capabilities it needs, and taking it into use with the people responsible.
Make capabilities reusable and replaceable. Research, drafting, review and extraction are separate capabilities with explicit contracts. A workflow asks for a kind of work, not a particular tool, so one method can replace another without redesigning the process.
Keep accountability visible. The design is signed off by the process owner, the released version is signed off again, and each legal decision is recorded by the person who made it. The system can show what it received, what it produced, which sources support the result, and what remains unresolved.
A general architecture, and one curated instance
The architecture in the following chapters is not specific to a jurisdiction or a practice area. It describes how legal understanding, process design, delivery and domain methods fit together anywhere.
The bundled toolkit is one curated instance of that architecture, built for Singapore: research and cite-checking against Singapore sources, Singapore deadline computation, clause drafting under Singapore law, and an assessment method for the Personal Data Protection Act. It shows the architecture working with real constraints, such as publisher access terms and amended legislation, rather than in the abstract. Another jurisdiction or practice would keep the architecture and change the domain capabilities.
What it is not
It is not an accreditation scheme, a commercial product, or a claim that AI can act as a lawyer. Legal conclusions remain the responsibility of the lawyers who review them. A passing check shows that a record is consistent, not that its legal analysis is right. The project records its limits alongside its results.
How to read this part
The legal engineer's journey follows the process from a lawyer's first account to a released workflow and back. The three-layer architecture and Inside the three layers explain the structure behind it. The bundled toolkit describes the skills that implement it today, and what has and has not been verified.