ResearchPod Summary
The L&T Masterpiece serves as the core integration point for the Law & Technology master program at Erasmus School of Law. It is designed to bridge the gap between theoretical legal knowledge and practical application by requiring students to engage in two primary tracks: conducting an individual doctrinal legal research paper and developing a collaborative legal service innovation tool. The course emphasizes the development of interdisciplinary skills, specifically focusing on how lawyers can effectively communicate and collaborate with technical experts.
The course architecture is built upon four distinct tracks:
The course utilizes a diverse assessment structure where the final grade is a weighted combination of the research paper (40%), tool specifications (35%), jury presentations (15%), and Course Connectors (10%). Additional components, such as technology terminology exercises and group-work reflections, are graded on a pass/fail basis. The design process is iterative, requiring groups to move through stages of empathy, definition, ideation, prototyping, and testing, while maintaining a "group charter" to manage collaboration.
Alex: Welcome to another episode of ResearchPod. Today we're looking at the syllabus for the 2026-2027 Masterpiece in Law and Technology at Erasmus School of Law — and it's worth examining not just what it teaches, but how it's structured as a pedagogical argument.
Sam: What's the central claim the curriculum is making?
Alex: That legal tech should be treated as a design problem, not a doctrinal one. Most law programs study legal technology as a subject. This one treats it as a problem to be solved — and the mechanism for doing that is placing students inside a simulated consultancy firm, working on real briefs from external practice partners.
Sam: So the structural shift is from passive analysis to active production.
Alex: Right. And the curriculum operationalizes that through a four-track model. The centerpiece is a tool-development track where students apply Design Thinking — Stanford-style, iterative, user-centered — to problems submitted by real clients: government offices, legal aid organizations, that kind of partner. The student isn't writing about legal tech. They're building something that has to actually function in an institutional context.
Sam: But these are law master's candidates. How does the curriculum bridge to the technical side without expecting them to become developers?
Alex: That's where the design gets interesting. The syllabus introduces what it calls "Course Connectors" — structured reflection exercises embedded at every block that force students to reconcile legal theory with software architecture constraints in real time. The idea is that a student writing a thesis on AI liability should simultaneously be designing a compliance tool, and those two activities should be in constant dialogue with each other.
Sam: So the consultancy role is the mechanism. The student stops being a consumer of theory and becomes an architect of legal services.
Alex: Precisely. And that shift carries genuine accountability. If a design fails to meet the partner's needs, the group must arrange a resit in consultation with instructors. It's explicitly modeled on professional practice — iterative, externally validated, and consequential in a way that a seminar paper isn't.
Sam: Which raises the obvious methodological question: how do you assess that? If the output is a bespoke tool for a specific partner, how do you avoid purely subjective grading?
This course is critical because it forces students to move beyond abstract legal analysis. By requiring students to translate legal, ethical, and technical requirements into a functional design specification, the program prepares graduates to navigate the modern legal profession, where the ability to manage technology-driven change and collaborate with non-legal stakeholders is increasingly essential.
AI-generated third-party summary by ResearchPod. Not official content or an endorsement by the paper authors or affiliated organizations.
Alex: They sidestep the problem by grading the process rather than the product. Students submit a structured portfolio — interim outputs, technical specification documents, and a final feedback letter. That last element is worth unpacking. It's not a reflection essay. Students must document how they processed stakeholder feedback throughout the project: which suggestions they incorporated, which they rejected, and why. The grade is largely on the transparency of the development cycle. A polished final product with an opaque decision trail scores worse than a rougher tool with a well-documented rationale.
Sam: That's a smart design. It forces accountability at every decision point, not just at submission.
Alex: And it's reinforced by the "Tech Terms" assignments, assessed pass/fail. The goal is cross-domain fluency — ensuring students can communicate with developers without needing to be coders themselves. The syllabus frames this explicitly as minimizing translation loss between legal requirements and technical specifications.
Sam: Which is actually the core failure mode in most legal tech projects. The legal team and the engineering team end up talking past each other, and the gap opens at the requirements stage.
Alex: Exactly — and the program is designed to close that gap before students enter practice. There's also a clear generative AI policy worth noting: full disclosure is mandatory, every AI-generated citation must be verified against OSCOLA standards, and fabricated sources are an automatic fail. That's not a minor procedural note. It reflects the program's underlying argument — that the process of legal engineering matters more than the existence of a finished artifact.
Sam: So the deeper claim is that "legal engineer" should be a core professional competency, not a specialist niche.
Alex: That's the bet the program is making. Whether the market validates it is genuinely open — but as a curriculum design, it's a coherent response to a real structural gap between how law is taught and how legal technology is actually built and deployed. Thanks for listening to ResearchPod.