 Hello everybody and welcome to another episode of law.mit.edu's idea flow and this time we have actually created some slides. Are these slides coming through? Anybody? Yep, great. Episode 13 is on a topic that we have discussed a great deal over time. But we have not yet delved into in a truly legit way, and that is the very concept of legal engineering. And with us is, you know, frankly, the best person I can imagine to walk us through what this topic is and what it could be. Namely, Michael Zargum, who's the founder and chief engineer at Block Science. And I also know him in his context as being a core member of the MetaGov project. And he's what I would consider a proper engineer, an engineer's engineer. And to get us into it, if you lack the context, what we want to do is explore the concept of legal engineering from a range of perspectives. Engineers and lawyers are specially trained professionals who apply their expertise ostensibly on behalf of society, according to codes of ethics. Both disciplines work within the boundaries of standard procedures, but must also exercise judgment regarding particular circumstances. Engineers manage technical complexity whereas lawyers manage legal complexity. But those two domains are becoming increasingly intertwined. And then I've added a little bit more context for you, Michael. And the first is we're coming from or through law.mit.edu's kind of media arm of the computational law report. And that is situated at the media lab but also at a part of MIT called IDSS. The, hold on a second, I'm about to fill up the page. Institute for data systems and society. And one of the things I wanted to really emphasize here is this word systems. And within and that's partly why the computational law is in that group. And similarly, SDM is another example at MIT of systems design. In this case, more leaning toward management than technology or law per se. But the, and it's out of Sloan primarily. And what's interesting about that is, it's another good example of systems. And in a, in a business and societal context. And that's not a bad way to think about where law generally fits. I think it's notable that there are a lot of types of engineering, which is partly what I'm bringing up here. And, you know, I think when Michael and I were talking about legal engineering and you know just kind of what it is. It was very obvious that there's arguably not a very satisfyingly deep answer to the question, what is engineering to start with, we have to understand it in the context of the type of engineering. It is. And, and if you do a Google search on types of engineering, they'll come up with a a a rollicking cacophony of different perspectives of how many types of engineering there are. The fewest I found five, the most I found was 38. And so it depends on how you parse them, but you know, chemical engineering, mechanical engineering, you know, software engineering, etc. But there is an idea of systems engineering. And there's a budding idea of legal engineering. And so I'm hoping, and then just to finish it with the inevitable reference from Wikipedia just to at least get us started. And so, and I think it's pretty, pretty legit. Engineering's the creative application of science, mathematical methods and empirical evidence to the innovation design construction operation and maintenance. And I might add and retirement of structures machines materials devices systems processes and organizations. I think we can find a lot of law in there and legal systems and rule rupture structures to I think structures is important, but we'll come back to it. Yes, thank you. And that's partly why we have you here to actually to fill us in from everything that we don't currently know and think the term engineering derived from the Latin. It's been many years since I took Latin, but I'm just going to take a swipe at this ingenium, meaning cleverness and engine, engineering, meaning five or device. And actually I see Chris is with us who is I believe a Latin speaker so feel free to come off mutant and correct me if, if, if you please. So, don't, don't feel the need to answer any of these but these are some of the questions that were rattling in the back of my head when when I knew we'd have an opportunity to talk like what from your perspective is what's engineering and an engineer in context, especially in your world. Through block science, but maybe more broadly, what, what, what might be the role of a legal engineer, like what would be our role on a project, what would be our role in a company like where we fit in the org chart, like in in whose domain or, or whatever. What are the outputs of a legal engineer I mean I know the outputs of a architect or like blueprints schematics specs, you know, for whatever. What are the outputs of a legal engineer. What are legal engineering, what's what's legal engineering vis-a-vis tech and engineering and business engineering, like where does it fit in that schema. And finally, what kind of skills and practices like would legal engineers possess, I said should which is going to fix that right now might. Yeah, that's much more spirit of it. And so, with that, those are some just some, some, you know, table setting things but I hope that you'll maybe start us off just with maybe a slightly deeper introduction of who you are. And then, you know, please take it away like what what are your thoughts on the, on the notion of legal engineering. This is super exciting. Yeah, so first point of reference is, I have four engineering degrees. One of them is a liberal arts degree from Dartmouth, and three of them are in the sort of domain of robotics and control, which is actually electrical and systems engineering. And I'll come back to systems engineering in a bit, but I've worked on a wide range of systems including sort of robotics systems aerospace systems. I've worked on business systems and today I work predominantly on organizational structures and market designs. I work on my PhD at the University of Pennsylvania with all Egypt by who's actually on the IDSS faculty at MIT now so there's a nice connection there. And I believe he's affiliated with the civil engineering department which is actually kind of interesting because one of the things I want to dig into today is that the type of engineering the classification of, at least within the scope of existing fields that legal engineering seems to fit for me is much closer to civil engineering, because you are actually providing structures that, in a sense, organize society for other people to act within. And the civil engineering field essentially already does that. It's the physical space that you're structuring. But as the world that we live in becomes increasingly digital or digitally intermediated, then a lot of our digital infrastructures are civil infrastructures, and a lot of those digital infrastructures are actually extensions of legal infrastructures or sort of structuring rules for the interactions, whether it's agreements or contracts, organizations, or even to some extent, government like bodies that are managing, you know, often in the blockchain world, we hear people talking about provisioning public goods. Again, this is a sort of a governmental function, at least in a legacy system. So sort of, I'm going to place us in this category of digital civil engineering because that's the way that I've sort of come to identify. So if we're talking about me, I'm saying, Well, I'm a digital civil engineer in so far as such a thing exists. But it turns out that civil engineers work really closely with lawyers. So I'm going to probably take that as the launch point into discussing what is engineering, unless there's any other, and we do questions as we go does or do you want to do sort of I think the best thing would be if you kind of got ahead of steam going and, you know, drop some some contact knowledge on us and then let that seed the questions, and then maybe we will interspersed them after after you've had an opportunity to kind of get some So why don't you throw the slide back up with the sequence of questions I'll use that as a scaffold, because I'm notoriously rambly some of you know me and I'm going to borrow does is outline as a way to make sure I stay on the track that we want to be on so So that is engineering. This is pretty challenging as does a pointed out but I find it to be useful to take multiple perspectives. So one perspective on engineering is just like really reductive it's making stuff, but the truth is it needs to be distinguished from sort of just making stuff in a fabrication or manufacture perspective because although a lot of people who are engineers do make stuff. It's the actual the thinking about this and the designing and the sort of articulating what it is you hope to accomplish by designing that sort of wraps around the act of making that I think is sort of really the essence of engineering. And for that, in practice, we end up with a decomposition from a sort of the functional perspective, or, you know, what are you intending to accomplish when you design, develop and even operate me and maintain something versus the process through which you design and test and deploy and even maintain something. And so, just because this has got a nice connection to the the legal language, I'm going to call the procedural part, what I'm going to call the part that's process oriented procedural meaning I'm going to follow the engineering design process and I'm going to gather or produce some sort of requirements, and I'm going to, you know, build and test against those things. I don't really want to go on a long tangent about engineering processes. So what matters here is, there are pretty dedicated processes on a sort of meta level, but also within the specific engineering domain, the kinds of processes and procedures that make that work. You know, let's say quality isn't necessarily the right word, but it's like legitimate in the sense that you did the engineering work according to the known best practices and procedures for that field. But that process and procedure or best practice can actually change over time, because it's not a particularly static field. And that's quite distinct from and ends justify the means view which we might say is more functional which is, did I accomplish the goals that I set out to whom I whom I serving and did I did I serve them as intended. If we place the functional and the procedural side by side, we might see that the procedural. I guess procedural is procedural functional is more substantive. It's like, did we accomplish what we hope to accomplish and did it really matter how we got it done if we got it done. I think placing those two things in contrast and recognizing that an engineer is actually going to make quite a few subjective decisions about, you know, what is appropriate work in order to ensure that the outcomes are met in a, like, sort of safe and appropriate and and I'm, I'm kind of trying to explore this gap between engineering as I followed all the steps versus engineering I produced the intended outcome, sort of ends verse means and sort of process versus substance of the work. And if people are engaged in making subjective choices about when and to what extent certain activities are appropriate, inevitably you end up with this third perspective which I call the institutional perspective and honestly this is the one that is most important to me. The institution of engineering is sort of, it's constituted of a bunch of shared values and principles around a certain like service to the public, and generally, it exists in this thing called the Cicero's Creed, or it's the I should say this is like the sort of oldest engineering Creed, which it basically says that you put the, the public safety or the public good above all other considerations. And if you sort of take that as a sort of principle that underwrites the entire social engine, the social institution of engineering, and it manifests itself in any number of like licensing style and regulation of engineering activities, whether it appears in different organizations like the I triple ease codes of ethics. But this, this notion pervades, and I think the understanding that an engineer at least an engineer's engineer is someone who not only understands the substantive and procedural aspects of designing things and developing and maintaining them, but also understands that the subjective choices design decisions or even in positions on those who would interact with the things that they've created that that comes with a sort of a requirement for like an ethical introspection like what am I doing to who to whose benefit, and you know what is an obligation to the public and so I would sort of wrap up the part star one by saying that you know engineering is made up of both procedural and substantive elements related to the design development and maintenance, and even potentially governance of things that we're going to use, and that the, the institutional layer of the field of engineering is the sort of values and principles that underwrite a relatively distributed set of engineering organizations and even sort of licensing programs across different institutions and because that engineering institution is greater than any individual, say regulatory body or professional organization. It's probably best to think of it as a social institution. That is really good for starting point. That is really good. May I just go put a, I want to go back and emphasize two dimensions of what you said, because we also want to create a record here that we can build on, you know, over the well hopefully years. And so one of them is back to the proceed the process oriented aspect of an engineer and engineering. So in schools they teach a lot of engineering design process is kind of like required part of a curriculum and it's always something like ask, imagine, plan, create or like prototype and improve, and then, you know, a few more or less steps in there. And so I wanted to ask, would you imagine legal engineering would would kind of fall in line with that sort of engineering process as well but in a different domain. So I think the important thing to understand is that what you were just describing is really like abstract it so it doesn't really matter what material you're acting upon your your early stages are about framing the problem and as I'm sure lawyers know whoever frames the problem really gets to determine what the solution is going to be. And so the reason you can't skip those early stages is that if you naively frame the problem or maybe don't even realize how you frame the problem, you're going to get a solution that I guess seems right, relative to your requirements but it may not actually do what you want in the world. And this is a issue we see even with software all the time, people jump straight into building software before knowing what they actually wanted to accomplish in a sufficiently degree that they end up with software, and it does stuff, but it may not do anything like what they actually wanted from a say business or legal requirements perspective. And I think we'll come back to placing, you know, business legal and technical requirements together and you know the end. I think it's something that you and I resonated with when we first met. But in terms of the engineering design process. Yeah, this relatively stylized sort of meta process is good for learning there's actually a version of it in like a child's book that I've been reading to my two year old daughter and I got to the bottom of those last page and it's in there and I was like, fell over laughing because I realized that there was something in my two year olds book that I sometimes have to explain to my clients, and that just made me laugh a little bit. Brilliant. So, so to extract it just to make sure we're tracking what I got from that is yeah, this highly abstract thing is it is it but the condensed version I mentioned which starts with the word asked. Yeah, really needs to be leaned into and it needs to be defined and validate what the requirements are and what the goals and objectives are hopefully we'll have time to come back a little bit. Yeah, an advanced look on that from Sandy and his his approach on legal algorithms really starting with a statement of the objectives that we can measure. Yeah. Yeah, and I think you know for for leveling up. It's a very good idea to look at things like systems engineering and model based systems engineering, and in particular things like the verification and validation V which allow for a degree of nesting. So you end up with something that's a properly applied is a mixture of agile and waterfall processes because there's some things that have to be ordered they simply like need a degree of they have a degree of temporal dependence, but that you still want to make your problem up into like little pieces that you can rapidly iterate on, because you know everyone knows if you try to like create this big directed a cyclic graph of dependencies and march through it that your project's going to take 15 years. And so if you want things to get done you need to operate in a relatively agile way, but when projects get too big or they have certain dependencies purely agile development starts to break down because it doesn't adequately manage. So when you get into sort of systems engineering you're going to be dealing with, you know, sort of a blend of managing dependencies between components, rolling up components into whole systems and managing requirements that are both sort of internal component, as well as sort of interfaces component to component, as well as sort of part to whole and kind of whole to part relationships and so you get a kind of networked view of codependencies or requirements. And as you move into things like organizations or large scale infrastructures or automations, there's really no way to get around doing this engineering design process in a sort of networked and recursive way. So you really want to get your head around it because it's actually a primitive, even though it seems like it's, it's an assemblage itself, you need to be able to both nest it and network it in order to get a big project up. Can I interject one thing? I'm sorry. Good. Oh, sorry. Yeah, just very quickly, just so you know where we're starting at least in my own part of MIT, we since the late 90s have been trying to do legal use cases kind of starting with you and then business use cases and now we've got a little bit of nomenclature and that's kind of taken off a bit. And then the last 10 or 15 years we've really gotten deeper into swim lane diagrams, partly because they let you do role separation. And when you have a role, you know, there's a, there's like a usually a business or a technical dimension of the role it's like a user and a server or whatever or the provider and there may be a whatever, like a buyer and a seller or an employer and employee, but there's also a legal name we can assign to each role like license or licensee or whatever you know buyers sometimes they collapse with the business ones but we found these two kind of baby steps to be a good way to start to get into a verifiable one statement of the goals of a system that we're building, but number two, a way to align and harmonize with the technical hardcore engineering and the business kind of dimensions as well but this is only like the tip of the iceberg of the engineering process design that you were describing. But anyway, I think a Brinton had an interjection. If that was his. Yes. Yeah. Yes, it was. Sorry. I'm in my car. I'll be short. The interjection your is your spot on Michael testability. The point here is that the design, the dynamics, the structure, these interplays with different sub systems are all testable and maybe we'll come back to that later. Yeah, I also like to riff on something that does it just said about the roles so actually in it in an engineering context, we often talk about functions and so in when I'm organizing things that are going to have say legal components or legal interpretations. I generally map out functions and then design roles to fulfill functions, rather than start with roles. And when you actually get a sense of what you're trying to accomplish, you'll figure out what the constituent functions are, and then start finding the minimalist way to fulfill all the functions. And then you might look at ways to create resilience through a degree of redundancy, or some checks and balances, but ultimately, your, you know, thing you are, I guess constituting is going to need to fulfill on an ongoing basis, a bunch of functions that have co dependencies with each other. And so just understanding what all the functions are, and what their dependencies are, both in terms of what they need from each other and how one function might provide say, goals, or receive outputs from sort of input output view relationship between different functions. And so a lot of mapping so I definitely agree with the swim lanes and roles and some of the tools that you bring forth. And certainly, though, will almost inevitably start with that framing that we discussed earlier and then from that base level framing, sort of iterating into sort of identifying what is in and out of scope for a particular design, defining boundary conditions and defining the functions that the thing that is being designed needs to fulfill. And then when I start looking at things like roles that would mean that I'm, I'm starting to come up with a solution now, not entirely because if the roles are representations of stakeholder groups, then there's a little bit of a matching going on between the stakeholder groups which are sort of natural roles, and then maybe the creation of roles as part of what you're designing that helps match the stakeholders to functions and identifying goals not just at the system as a whole, but potentially from the perspective of multiple stakeholders and I think this is where we start to get into the legal engineering category, because because as we're building in particular designing organizations and or software and most often, in my case, organizations that are partially constituted of software. We have to look at a bunch of different stakeholders and their potentially conflicting goals, because this is where some of my particular area of study comes in which is resource allocation algorithms because at the end of the day. There's going to be some conflict in the preference for how constrained resources are allocated. So whether that's money, or attention, or even rights to do certain things. The, the algorithms and organizations that are sort of partially constituted of software end up solving these kind of multi stakeholder resource allocation problems on it could be collective decision making, it can be sort of financial resource, both procurement like assignment to specific initiatives, it can be a wide range of things but what you'll start to notice is that, although we may be building software to meet some of these use cases or to facilitate the allocation of resources. That is still actually very much in the, the legal domain or at least the legal adjacent you're still forming organizations that have legal standing in some cases, you are almost certainly doing things that you have legal compliance requirements for, and you are ultimately quote structuring the field of action and this is why I pointed out the term structures in the engineering definition because I'm a particular fan of the Foucault governance definition which is structuring the field of action for others. I learned that one from L. A. Renny who's a collaborator from RMIT, and I found it really compelling because I realized that you know in civil engineering you're like literally structuring the field of action like you are going out and creating space for certain types of activity, you know, when you really think about what a road or a bridge is, they are, they are economic infrastructure, people and goods move over them and honestly in a pre digital era, they filled very similar functions to, you know, digital systems that move between money and effort between organizations and between people so I tend to like kind of zoom in on this idea of economic social and economic infrastructure, and then recognize that legal contracts agreements and organizations are really socially and economic infrastructure, it gets structured, they provide affordances, people get to interact according to certain rules, but they also have restrictions on what they, what they can do or what they're, you know, ostensibly allowed to do with maybe the main caveat where enforcement in the traditional sort of physical world often comes back to some sort of dispute resolution or some sort of dispute making and dispute resolution in a software system. Short hacking, there's a relatively high degree of enforcement implicit in the infrastructure so I can't really drive on the wrong side of the road, the road sort of, you know, the equivalent the digital equivalent of the road, like doesn't give me that option. The visible actions are effectively coded into these systems or you might say that they're more complete. The physical world is more incomplete in that I can, I can more fully specify what one can do, and what happens when they do it, when you're working in a software. But actually the consequence of this is that often things are over specified and I think we've got Megan on who recently gave a nice presentation at the codex about rebranding vagueness as elasticity and I'm actually a big fan of elasticity. And so far as when writing algorithms are producing software that is intended to fulfill, you know, structuring the field of action like functions, then we actually have to really carefully make space like otherwise things are vastly over determined and things that are vastly determined are at least in the physical world very fragile. So if there's no flex or give in something is a really good chance it's going to break. And so, you know, to kind of come back to what is the role of a legal engineer, I would argue that their their job is to provide the engineering methodology and the substantive like trade off decision analysis and selection of structures in the in the legal material. And I think I'm going to use that term material because as someone who's worked on, say robotics like we had teams with mechanical engineers, electrical engineers, computer engineers, and a lot of different experts needed to come together in order to make a complete project that fulfilled its function that you know, in this case the robot got deployed to Greenland and then Antarctica with the Army Corps of Engineering and that experience of working in an interdisciplinary engineering team sort of lends you to realize that some of the core principles of engineering are sort of irrespective of the material that you're working in, and that any particular project is going to need materials depending on what your optimization is what your what your goals are, also what your constraints are actually and one of the nice things about bringing the legal engineer into the mix is that I think, especially with these digital systems, we tend to forget about constraints. We don't necessarily think about codifying what one can't do. And, or maybe better yet, we say one can do all of these things. And then we also might layer in some principles or some some values something that we couldn't code that's naturally incomplete. And if we want to try to bring some of these concepts into our designs, we're going to need engineering professionals who sort of have an expertise of that medium, but we'll ultimately end up placing the requirements from the legal domain in parody with requirements like technical and business I usually use the term economics but does has a great acronym it's BLT business legal technology, and I've been you know talking with my teams which tend to be working on projects not necessarily for a specific business but for an ecology. So we generally think of it as economics, rather than business requirements, because we want, we do a little bit of market design a little bit of mechanism design but in the end, since we have end stakeholders and most of these problems will look at that as an economy rather than as a business, I tend to think of as having the business objectives or the business requirements for the business, whereas an economy might have to have requirements for, you know, two to five stakeholder groups and they need to be in balance in a way that actually processes that's brought forth by the individual actors within that system. And so I tend to lean into the signal processing network signal processing as a way of understanding markets so that the, the information is drawn from the, from the those interacting with the market, rather than being kind of imposed upon them it's it's on a magic oracle. It's a sense making institution. And in particular, if you think of it in formal terms, it's a kind of dynamic network doing signal processing. So we have some opinions about how what what that analogy or that formalism tells us about how markets may or may not be structured, but it's convenient to notice that even when designing markets. The term structured is also present. So we see some overlap in the technical, the business or economics, and the legal domain in this term structure in all cases we are structuring something. I'm arguing effectively that that's what we all have in common, we're structuring this field for others, and that when we actually do these bigger projects that involve, you know, business or economic requirements legal requirements and technical requirements that the software engineers or other technical engineers that the people thinking about the, the business or economics and the people thinking about the legal requirements actually come together to sort of come up with to design, and that means, I guess, frame the problem statement what are we trying to accomplish for whom, pick some tools and start to lay out a structuring, and that the enterprise of engineering in this case the sort of business systems engineering or maybe it's a, you know, the sort of meta on engineering that we're working with our lawyers are technologists and our economists or business people is one of structuring for others to act within. And so I'm going to pause there again for a second because I think we have some questions coming up but at least for me that's why these things are so consonant that we're doing structuring for others. That's great thank you for coming back as you had promised to that word structuring that I just sort of skated right over, and that I see what you mean in terms of having a lot of explanatory power in terms of you know what what we're doing and how it relates. One quick reflection on what you said and then let's get right to the questions, which is, you brought something up that's particularly and a particularly important dynamic I think with this idea of how legal engineering could work and how it could fit into the the other systems of engineering on a project. And it's when you talked about the typical go to level of abstraction in your team is economic and the broader systems and you, if you've looked at Sandy Pentland's perspective on legal algorithms piece you'll see that's very prevalent frame of reference from our home lab as well. We look at, you know, larger scale systems, you know markets and, you know, big populations that kind of thing. And you're quite right to point out that this particular take of BLT is literally a lower level of abstraction it's more specific. And part of that's just an artifacted before I got to MIT I did you know commercial work and I think in terms of businesses and structuring transactions and that sort of stuff at that level that only exists within systems, and that only operates with even further granularity in terms of specific transactions and, you know, and small more granular things. And, and what I want the, I guess, inside I wanted to offer about what might be what might require a little more thinking for successfully defining and incorporating legal engineering into the broader and a more organized way in the future is this the scope and the level of abstraction is particularly important to define with legal dimension because people can be doing extraordinary, you know, contributions but they're coming from a vantage point where they might be looking at, you know, traffic and parking over the bridge, or they might be looking at, you know, torts and fender benders, or they might be looking at law enforcement in terms of how can we use the photos at the toll boost to determine that, you know, this suspect was in the car and it's incredibly fact specific in a way that's very squirrely and needs to be defined. But that's something it has in common with this that's actually the point about framing right so like we deal with multi scale systems all the time so the systems engineer or the systems of systems engineer tend to sit in the highest level of abstraction and actually participate in some degree of modularization and maybe creating frames of reference and defining interactions between frames of reference so in your case with the bridge and say we're in the legal sub domain of the bridge there might be some interaction effects between some specific design decisions from the technical members let's say we are dealing with, I don't know deciding whether or not we're going to put a hard rail between the two directions, right so there's a, in some cases you might just have two lines, painted lines, and in a, another case you might put like an actual physical divider. So it might be that the engineers are making decisions based on the, in this case the technical people who are making choices about maybe traffic patterns which is a little closer to economics to the actual physical materials so we might have some people talking about the physical materials and the structural sort of properties of the bridge thermal expansion vibrational modes, you know how much weight it can bear, all that, then you might have other people worried about questions of, again like traffic patterns, accident rates, etc. And that's exactly where the sort of legal interface might pop in, because you might start to have some of the sub sections that you're talking about. They'll have some interactions with each other, but they'll also have cross links with the, the other, you know in this case I called the traffic patterns the economics category, but you know also the physical things changes to the physical structure of the bridge might affect its physical properties so by point about the networked and recursive view of the engineering design process should come into relief here, because that precisely gives you a view of the world where you're starting to break down the problem into a bunch of constituent engineering problems, which are codependent on each other. And your point is essentially that the legal engineering problems are also codependent with the economic and sort of physical technical engineering problems and this comes back to like why we're having this discussion is that it's always seemed very strange to me that legal was in a sense outside of that paradigm as opposed to inside of that paradigm as one of the engineering domains in inside of that engineering design process, rather than a thing where they sort of engineers and in this case, economists isn't quite the right term for the people who are doing traffic analysis their cyber physical systems engineers of various types. But they're engaged in this type of modeling and analysis to make decisions in the in the infrastructure. They're sort of, they're still sort of following an engineering design process but my experience is that on the legal side it's just very much a, a guess in check, it's like, there's some, you know regulatory frameworks and or some, you know, lawyers with disabilities and their job is to say no, until they get an answer from the engineers and the economists that they're willing to accept and one that removes a ton of efficiency from the overall design process and to, I would argue that that it also tends to sacrifice substantive outcomes for procedural following. So like at least my experience is that the, the engineering adjacent legal work is structured into regulation based checklists and that those checklists although they are intended to embody the desired outcomes, they tend to end up heavy on you checked all the boxes and light on the reason those boxes were checked was actually accomplished the light on spirit heavy on on rule following and I'm not saying rule following is bad but when I view these systems holistically I view the legal components as important but like the substantive bit is important. I want systems that are safer, and that are fairer, and that those things do sort of get addressed at the level of the legal engineering or the legal experts domain. You really got your finger on the pulse of part of what animates this this initiative at MIT, and I think more broadly, which is this recognition that laws very easily and very quickly seem to be subject to a kind of a socio political entropy and they become these sort of like bureaucratic steps that we take that kind of drift ever further from the initial purpose and then that's part of the idea of engineering and can we define the outcomes and the objectives. So we have to instrument the systems that they're built into such that we can continuously measure and adapt the systems but also adapt the rules to stay up to up to par and up to the moment of what our objectives are which are not snapshots that we have to be prisoners of all eternity but they also evolve. Okay, but enough of my voice. We have at least one hand up now by Brendan and I want to encourage anyone else that wants to get on this we have 11 minutes left. This is your time. Let's start with Brendan, you're up. Okay, great. Because he's put forth a number of things that are just, you know, extraordinarily exciting. What I wanted to do is I wanted to say, you know, we've spoken quite a bit for some early on about complex systems and dynamics. He's said a number of things which are really, really important that I want to tie together and then he might take the time to expand upon that more. But when we think about, you know, statute and laws, the very important thing to understand is this area that he's been discussing specifically around the dynamics of a system and boundaries and constraints and how those things are related to structure. And these all things, all of these things have an interplay. And the question becomes, how do you design statutes and laws in ways in which the parts that are static are static and the parts that are dynamic. And often that is around the messages, the events, the transactions, etc, etc. Those are the things that you want to test and engineer. And I know that there is flexibility in that statute over time or other laws, etc, etc. But this is all great Michael I couldn't go on but I'm not. If you could maybe at some point speak more to the, how the dynamics can drive an analysis of the dynamic dynamics can drive thinking about the legal side of this that would be great. I can address it directly. Oh, does it. Oh, okay. So, in my team, because we do quite a bit of work with software, and we have backgrounds and things like me systems engineering one of my collaborators is in was a was a contract theorist computational economist and, and, and many other fields but we use something we call generalized systems, and this allows us to express the dynamics of much more complex objects and things that are not numerical so historically a dynamical system is defined over real valued fields. We divine. If you, if you look this up you're going to find probably not our work because we haven't pushed it out yet but you'll find some some references to the concepts well, I'll, I'll, I'll just explain. So basically, no, I was sharing my pad. Yeah, I wanted to speak to what you're pulling up but you're not going to find the publication on this yet because we haven't pushed it out into the public but there's existing generalized dynamical systems concepts from the 60s someone by the name of rocks in was the primary contributor, and it basically took the notion of a of a dynamical system, and then described it over like an arbitrary topological space and like, what can you do with dynamical spaces dynamical systems over for lack of a better term objects. And since we deal with lots of software systems we just said hey we need dynamical systems, but we need them defined over, you know, arbitrary data structures and so well arbitrary data structures are space are basically spaces, they define the set of values that something might take and methods describe the mutations of basically of those data structures. And then if you just need to open it up and sort of look at what kinds of activities one can take, you can take a slightly more control theoretic lens and do you describe like a canonical form for like a nonlinear system would be like f of x comma you returns a new point in the, the domain X so that's a differential, it's a differential. It's a difference equation, and we tend to reason about them as differential inclusions, because we end up with these inputs you drawn from some set of admissible actions, and those admissible actions themselves might be state dependent or even like actor dependent. And so we can create quite formal representations of, for lack of a better term agreements or contracts in the form of data structures, and then the, the messages that you are allowed to pass and then the way in which those messages are resolved into changes in the data structures. And so you get these difference equations, these nonlinear, specifiable difference equations, and then you get this differential inclusion where or just discrete differential inclusion where you can see what's reachable by actually extending the space of points you can get to from the current points. And that whole family of reachability analysis underwrites a lot of our sort of formal engineering work for things like smart contracts. But one of the things we've learned recently from talking to lawyers is that turns out you can specify all sorts of great kinds of market structures and legal contracts and agreements using this sort of modular block diagram based thing that contains really nothing more than, you know, maybe a collection of data structures, and then a collection of mechanisms, and that those mechanisms have admissible action sets or like message spaces. And so you can also strongly type the message spaces, but you leave a lot of room for that elasticity you're basically saying the set of all messages that can be passed to the system are. They are passed to the system this happens, and you leave that incompleteness for, well you don't know what messages are going to come, they might come from measurements they might come from actions of participants, etc. But the nice thing about the boundary and this sort of open or permissible, or I might say admissible, since we refer to these as the admissible inputs, this admissible boundary provides the way in which information gets into the system from outside, and since a large number of things within the system might be observable to the outside world, or even reported on, then they actually give information back to the outside world. So we do quite a bit of design from this generalized dynamical systems paradigm, we've been using it for several years. And we are starting to write some publications I'm actually hoping to get something out in the next few months, because I'm giving a keynote at a conference about it in July and I want to have the paper somewhere public. But in the meantime, you can sort of follow along with, I guess some of the other work that we have published that actually contains references to it because we're using it. But for me at least this is the, the place that connects with what what Brendan's asking about we, we had to develop a sufficiently rich abstract formal system that was a kind of, you know, dynamical systems canonical form that maybe we hope one day will sit alongside some of the other canonical forms that get used, you know, LTI is LTV is nonlinear systems, etc. We just happened to construct a representation that forgoes the, the real valuedness and replaces it with strongly type objects or data structures. And once we did that, we realized that a lot of the dynamical systems equipment can still be used particular reachability analysis is incredibly helpful. It tells us what can happen as opposed to what will happen. In many cases, almost everything that could happen doesn't, but something that does happen could have happened. So that's great from, you know, again kind of founding the possibilities. We also do things like analyze what the blockchain people call economic security, which is to say, given the current configuration of the system, what would it cost in monetary terms to move to another configuration. It's still inside of the system model. But if you look at the sequences of messages, there's a sort of shortest path in, in, in cost that you could find. So if you're worried about how much it would cost to attack a system. Like what is the cheapest set of moves from its current configuration to take it to the undesirable configuration. You can also design guardrails, things that identify the precursor states to undesirable states. That's a lot like how cyber physical systems and sort of fail safes work anyway right circuit breaker. You're like, well, I really don't want this to happen. A precursor to that happening is this. So when the system reaches this state, let me turn off those other mechanisms until it may be re equilibrate or to stop to stop a shock or something. And so, you know, there's so much that you can do within that paradigm. We also do a variety of sort of signal processing tests when we we get things into software so we developed some software called CAD CAD complex adaptive dynamics computer aided design, which is loosely based on this GDS generalized systems paradigm. First version's been out for a couple years it's a little heavy from a UX perspective and we've got a team currently doing a full re implementation with an emphasis on cleaning up the UX and making the modeling language a little bit more accessible, but at the end of the day it's effectively a a Python based implementation of this GDS paradigm to make it relatively easy to mock things up and like look at what would happen if so do run scenarios, etc. Brendan I mean you're really kind of hitting my, when you started asking about dynamics that you're really hitting my home territory. Even when we get outside of the strictly formal statements and into the more sort of conceptual stuff I recently released a preprint of a paper connecting cybernetics back to dows. And one of the main things that we came back to was looking at governance surfaces or the mechanisms through which you literally adapt the governance rules and what was what's reachable in that system and like how do those systems actually adapt their own rulemaking procedures over their life cycles. Fantastic we don't have time for follow ups right now although I think we've generated about 18 months worth. Do we have time if we can really fast. Andre you had your hand up did you want to squeeze one last contribution in. Now, I will be very brief, nor that you can use our available time and my formation is not engineering. I'm, I'm, I have a legal formation and continent continental Europe legal formation not common law. And it, that there wasn't a classical alter of legal theory in tell in the Italian author that was Norbert to Bob you and Norbert to Bob you recognize that the changing from the structure to the function in law in legal theory. And it seems that that you you defend and this seems possible to return to a structure and mix structure and function, considering the new era of digital evolution and we have automation legal automation in law as proposed by St. Bantlin, and all these these return to the structure. Is it possible only because we have the digitization of law the digitization of the, the conducts and behavior. But it's not possible only because I think it's leading us to make it's making that perspective more useful again so like if you think of the as those models as perspectives, then the perspective of more carefully looking at structures and the functions those structures will, if I'm understanding this this thing that you're bringing in, at least for me. Yeah, we do a lot of, like, you know, structuring things to fulfill functions so if you don't understand the functions that you wish to fulfill, you can't define the right structures, but just thinking about things like algorithms as structuring as you know put deploying designing developing deploying and maintaining a set of algorithms or procedures as a sort of structuring the field of action for others is what, at least for me, brings this perspective back to focus right, we want structures that fulfill intended functions we don't want structures for their own sake or you know maybe gigantic bureaucracies that self, you know that they self maintain, but potentially fulfill the function from which they originally, they emerge to fulfill. And again, this is me being a big proponent of a lot of the functions that the bureaucracies, at least originally fulfilled or supposed to fulfill, but maybe not feeling like they're currently successful and maybe we can adapt or reframe those institutions to maybe fulfill their functions better, in part, by recognizing the role that the digital transformation can play in restructuring those institutions and improving their capacity to fulfill their functions, which might actually start with going back and asking what were their functions in the first place. Yeah, thank you. Brilliant. Well, there's a lot. We have some applause coming. Nice icons. There's so much more to cover and I just want to thank you, really from the behalf of the entire community, and especially the people of the future who I hope will enjoy this who don't yet know that they're going to be legal engineers for your time and for your generous and really gracious sharing of your knowledge and expertise and pointing us in the right direction. So thank you very much, Sargam and thank you everyone who participated today in this episode of law.mit.edu's idea flow. See you next month.