Legal Engineering Defined
Legal engineering is proposed here as a discipline whose competence must be demonstrable in practice.
Legal work depends on systems: how a matter arrives, how facts become usable, how a question is identified, how research is checked, and how a decision reaches the person entitled to make it. Technology changes parts of that system. Engineering asks whether the arrangement works and how it can be improved.
Scope of the proposal
Harvey's public description brings together legal expertise, technical fluency, process improvement, and user enablement. The present framework seeks to specify the corresponding process, technical, and delivery competencies more precisely.
Entry should be open; the standard substantial
A legal engineer need not be a lawyer. Interest in AI, a product demonstration, or a new job title does not, without further evidence, establish engineering competence.
Legal practice followed by technical study, engineering followed by substantive legal-domain study, and integrated education are possible entry routes. Assessment should concern the work a practitioner can understand and deliver, including the limits recognised.
A route into the discipline should not be confused with its destination. Neither a law qualification nor a technical qualification supplies every capability on its own.
Understand the work before automating it
A lawyer's narrative begins an investigation. Who performs the work? Who owns the decision? What information must exist before someone can act? Which exception changes the route? Where does the work wait, and why?
A legal engineer should be able to turn that account into a model that other people can inspect. Observations, assumptions, proposed causes, and measured benefits need distinct labels. Automating a poorly understood process can make its defects faster to repeat.
Technical fluency must reach beneath the interface
Someone building a workflow should be able to explain its data, rules, dependencies, failure states, and tests. Someone shipping software should be able to review and maintain the implementation. AI assistance does not remove those responsibilities.
The appropriate depth depends on the work. Recognizing when a task requires a specialist is itself part of competence. But the person claiming engineering responsibility must be able to scrutinize the system they put into use.
Delivery and accountability belong in the definition
Useful systems are built with people. Priorities compete, reviewers have limited time, and prototypes expose assumptions. A legal engineer should be able to coordinate deliverable changes and use feedback to improve them.
When AI contributes, someone must be able to inspect the inputs, the outputs, the evidence, and what remains unresolved. A workflow should not quietly invent an approval. A record should help the next person understand a decision rather than simply show that a box was checked.
Let the artifacts test the argument
The three-layer toolkit provides an illustrative implementation through which the proposed account can be examined. Research methods examine the domain layer; delivery skills examine coordination; and the process compiler and runner examine whether a consultation can become a reviewable system.
The framework remains under development. Its limitations form part of the account, and its claims remain subject to revision through implementation evidence and contributions from practitioners and researchers.
The next chapter makes the proposed standard concrete: what should a legal engineer be able to demonstrate? From there, the guide develops the architecture, the underlying methods, and their application to working systems.