Okay. Good. I'll go very briefly. Just I'm James Hazard. I am merely a lawyer. That is I'm been in law practice in one way or another since 1979 in Boston for a stretch, and then my boss sent me to France in 1990. And I didn't come back. So I was a member of the bar there and doing various things. And then for various reasons, we came back to The States to the Bay Area. And we've been bouncing back and forth, but now seem to have landed in Berkeley. As a lawyer, I was at a large firm and it we this was in the eighties, and I happened to be there when our current word processing system failed. It documents had gotten too big for its printers. And I ended up helping guide the firm to networked computers, PCs and WordPerfect. And that started a process of then figuring out how you do document assembly and so forth. And around February, now in in solo practice in Paris, it seemed that the key thing that would make everybody's life better, including my own as a solo practitioner of corporate law, would be if there was a resource, a publicly available resource, a commons of legal text. So what you might call a contract wiki and some others have called a contract wiki. And that led to sort of iteratively through processes that included coming by MIT Connection Science and by the Berkman Center and Primavera de Filippi and then in 2014, suddenly this all moved on to GitHub. So that's my background and I'll let then Megan give you some, give you a little introduction to her.

Cool. Yeah. Yeah. We among the issues in roommate agreement, of course, is who orders pizza. So why don't I flip right in if this makes some sense, I think I'll do a really short presentation. Maybe later we'll do another short presentation because repeating an idea is often a good thing. So if that's okay, and I can figure out how to share my screen. Does that make sense?

Yeah. That's great. Perfect. Yeah. Because the key thing here is to see if we can make some connections between areas of interest, areas of work, and this bit of work that we've been doing. So I'll switch it. Let me excuse all the presentation issues. So if how do I make this and this thing's in the way. If I can how do I make this full screen? Somewhere I can make this full screen. Oh, man.

If you make this window a bit bigger, you'll see the button of the presentation.

Sorry. Somebody was being helpful.

Just increase the size of the window and then present. There

Okay. Increase the size of oh, hang on.

You can do it like this too. Yeah.

Yeah. Present. Okay. Present not present. Okay. So this this, it goes back to 02/2015. It was done with Thomas hard Janno. This is part of a dialogue between them and Primavera and me. But the basic notion here is how do you connect up this notion of prose objects that is to say of organized legal text, with the broader problem of decentralized data. So if I okay. Sorry. Here we go. So the general notion here that pardon me, I'm ready. The general notion is where do the words come from that you're reading that are binding you? And it ought to be that there's a system of provenance. It ought to be that we don't endlessly repeat and rehash stuff. If somebody said something well enough one time, why don't we just keep reusing that? And instead of making copies of it, why don't we link to it so that we know that it's not been modified and so forth. So this is in a certain sense, this is compression by of compression of the legal sludge in Cass Sunstein's phrase, compression of the legal sludge into first by text and then by ideas. And it'll turn out we lawyers don't have that many ideas, we just say them in a lot of different ways. So let me see if, man, this really runs. This is well, maybe I can just page yeah. Page down works. Sorry. Okay. So that's the general problem. Legal documents handled mostly as blobs. Word has been the the key disaster for the legal profession. Be a lot better if we organize this stuff. So what would a what would a composable system of legal text look like? And this is old and not my conventions anymore, but this is basically what you're doing. So you're gonna take if you want a document, well, a document has parts here. This is a legal, this is a contract agreement, has a prologue, it has some stuff, stuff that it actually says, it's got a signature and a might have attachments. And each one of these things can be recursively expanded into whatever it is you want. That also means it can be overwritten. So you can customize the thing you can, okay. And that the idea is that then you would have an object model for a legal system. There are certain kinds of things that that seem obvious beasts in this bestiary, like persons and things, and jurisdictions, and stuff like that. So if you think of this as a graph, then you got a bunch of nodes, and we can essentially all transacting is adding another node into this graph by connecting it up to things that are probably already there. And so bear going, you know, digging, you know, sort of projecting down into that, what would a graph of a startup finance look like? It would have a bunch of different documents and it would have a bunch of different people and they would be connected in various ways. And then an object model for a single document. This is again, the safe note the Y Combinator safe note stuff. What would that look like? Again, we've got our persons, and we've got a form and the form is made up of sections and the sections are often made up of subsections. And then this is Thomas's work. How would if we have a central repository or repositories for this legal source stuff, how would people actually transact back and forth, they'd be sending little verifiable messages back and forth, but some of which would point at the oops, point at the repository like that. And these things could be entirely private, they could be on a Blockchain, they could be however you want them to be. You could actually do this using a cocktail napkin from a restaurant by pointing at the URL for the form of agreement that you meant adding a couple of deal points and both of you signing the thing. So more technical information about how you how elements in the graph might come together. So, why don't I pretty much stop there and let's see if we get some discussion people.

That's great. Yeah. Fabulously. It turns out that that problem is also pervasive. That is one so we did a European, and I'll point to a little bit of that, a European project for the European Commission on modeling the European economy as an ecosystem of contracts. And the the genesis of the the intent there was the European Commission doesn't understand its economy well because none of the measurements that you get are really of adequate detail. And but if you were to if people within the economy were to use an essentially an object oriented approach, then they could have a far better idea of what's going on. And that points out that this problem is fractal. That is to say, the regulators got sort of the same problem that a company has, and they've got very much the same problem that an insurer has, and they have the same problem that an individual has in understanding who their relationships are, what the relationships mean, how to do the next one. So that fits, I think, perfectly into that notion of community.

Sure. Yeah. Thanks. I I'm just, you know, as I said, eager to to see more. You know, as I mentioned, I'm I'm in the process of working to this rebuild of of this this platform, which is really focused on interface called Community Rule. Just show you a picture of it here. So it's it's an attempt to basically enable, visual construction of group agreements. And, you know, if you fork this one, you can move these things around and describe them and so forth. But we're, you know, it started out as just a totally natural language thing. Now it's got these kind of movable modules. But the goal is to move it toward being much more computational functional. And so I've been looking for kind of computational languages to use as the basis of that. You know, one kind of candidate we've looked at is the Ostrom language design language. But I'd love to hear more about the yeah, just just the state of this, this project and framework and and, you know, how how ready it is and, and also, questions about about interface, whether you've explored what interfaces, you know, could and should look like for people who would who would actually engage in in using this in a design space.

Why don't why don't I step in and just do a little demo here? There we're getting perfect stuff in the in the feedback here. All questions that we thought about, we think there are answers to. We may not have the best answers to them, but we've got at least working answers to them. But let me just I'll just walk through a complex example of this. So I'm working here locally. This is the same stuff that's up exactly the same stuff that's up as commonaccord.org. The commonaccord.org just pulls from a git repo, uses Heroku. It also blows up frequently if you because of the coding is is perfect but inefficient. Locally it it always works. And I'll take, as I said, a complex example, it's a simple situation, but this is a non disclosure agreement. So non disclosure agreements are extremely widely used and must and much disdain. They are kind of hello world for contracting. And what would a nondisclosure agreement or frankly, any other contract be? It would be some links to some parties here. These are my improvised identity system, a real identity system would tie into some things like the Glyfe work so forth. There's a lot of ontologies out there that do make sense and haven't quite got the traction they should. In any event, it's two parties and a form of agreement. And we'll note here that this form is from party one to party two, which is to say it relates to information disclosed by party one to party two. You can also do party two to party one and you could also do mutual and we'll see how that's done. And then you have a bunch of deal points. So your, you know, what are dates and so forth and you'll note a kind of something that looks a little object oriented d here, but the periods actually just are for convenience. They don't have any any specific meaning. This is, it turns out this is tied into a core concept of this. And you could reach into this solution here for things that somebody has already worked out. Like, if we note here we got Andrea is a human and we're disclosing the information to Andrea and not to a corporation or something like that. So there's actually no reason she needs to speak to anybody, anybody else disclosing this information. So we've got a little formula in there that that covers that situation. But if you decided that you didn't like that, then you could just start writing here and and specify what it is that you wanted. That you would end up looking at something like that. And this renders using Primavera's fabulous Perl code from 2014 done I believe in a McDonald's in Buenos Aires between two conferences. Why McDonald's? Because they have good Wi Fi. So this is the the whole agreement. So we see we have this notion of identities, who's involved, and we still have the, it's structured information, remains structured information. So this is I talked about how they're an ontology. ELF is the life stuff. So an ontology for kinds of organizations, which then means that if we had a computer, we could reason about Acme. We could know that it has a board, we could know that it has a president or needs a president and so forth. And here's all the beautiful lawyer text like this and the here and this is our little human solely thing, little human solely snippet. You can also do very easily the basic HTML stuff so that you can have cross references, can be hyperlinks, and you can actually do that on a kind of semantic basis. So this sends us to the section which has to do with the exception to confidentiality. So, as I say, lots of lots of text here as much as a lawyer might love. But this is just a view of the data. Didn't mean to do that. This is just a view. This is the actual data. So this is the actual thing and you can see how you could then take these parameters and you could dovetail them into another system. You could dovetail them into something that, into a real computing system. So a notion of parameters, pros, and code, a Ricardian model. Then a non disclosure agreement, I mentioned that it can be p one to p two. Well, it can also be p two to p one, and it could also be mutual. Could also make it oops. Sorry. My hands are very cold. It's a little cold in Berkeley. So you could also make that mutual, in which case we'd get this. So something with some open items in it. So, then this would be a mutual agreement. And all of that can use the same library for non disclosure agreements. So basically what we're doing when we click on document up here is we're, we're expanding strings and part of the document is roughly these four points. Deal, it's why not put the deal points upfront? Definitions need to go somewhere. General relationship issues and then housekeeping in the miscellaneous section. And each one of these things is also components. So your confidentiality, we can see what confidentiality see what it is that we've so, yeah, there's and there's a little recursion problem you'll see in this thing. But this is a library that allows you to do lots of stuff regarding confidentiality. What's your engagement? How long does it last? What are the exceptions? All that. So you can need basically, if you you can take any legal idea, any legal idea somewhere will find expression in text. And if you just take that text and start breaking it apart, eventually you'll find the ideas. So, and all of that can be based on a common form. What's a contract agreement? Well, it's got a heading, list some parties, little bit of transition text. And then here we have the meat of the agreement, needs a signature, and it might have annexes to it. And that so this one, there are a lot of different languages in which people do contract agreements. Here is English, but oops. What did I do there? Here's English. My hands are cold. Here's English, but we can also have a general notion of what's a contract agreement. And if we build our contracts like that NDA from this, then we have an object here at the bottom of that stack to which we could attach code like things. For instance, something that tells us that the agreement doesn't have much meaning unless it's actually signed, and it has different meaning after it's expired than it did when it's still in in in validity. And all that is here we see how the thing is actually built up. So when I push document, it goes and looks down through the stack for something called model root. If it's up at the top of the stack, it's done. If it's it has to go all the way down here to find it, well, okay. And now what it's trying to do is to expand doc. And then from doc we're trying to expand those things and then from those things were which did did did did did did we just recursively just expanding a string is the whole system. So why don't I stop there?

Yeah. That's great. Yeah. All those are serious questions. And, yes, there is a good deal of thinking about it. The at at one level, Git allows you to solve many of these problems if you use it and and are willing to rely on it. So, you could on our cocktail napkin, when we reference this form of non disclosure agreement if we also wrote down the shorthand form of the commit number when we were referencing GitHub, that would provide us with a very high degree of non falsability. You can also put it in, I've got some demos. You can put this stuff up on IPFS and reference that stuff. The issue of of there's a kind of notion of releases, that is, maybe we have one form of non disclosure agreement and it developed it's used a bunch and then it's as this is a key connection with the block science work. It's imperfect, it's necessarily imperfect. We should start with the notion that it's imperfect. We expect that it will get better, as people use it. And, if people are are repeatedly tweaking something, then maybe that's a sign that we need either to add a use case or change our basic model. So you can have a notion of releases that can be done in a bunch of ways. One of them would be essentially to use git branches, but on another way would be, essentially just use, time stamping or and now we and and I now remind everybody that I am merely a lawyer. So there are, other solutions out there that are somewhat beyond my kin. This is this is sort of this this takes you as far as my thinking has gone. The little work with Thomas Harjano, also includes that notion. It might be now I'm getting beyond being a lawyer. It might be that there is some kind of deep integration with with Git that one could do that would provide a single solution to what in my thinking is has to be expressed in two ways. Is that responsive?

Yeah. And if and if I can take that and turn that thing another direction, this note there's the notion of governance of of common accord, governance of a center for decentralized law, governance of a decent law center. And what does that look like? So that as a legal as a commons for these kinds of ideas, it needs governance too.

if you got some tips or ideas about that. Yeah. Let let me jump into that in one in one direction. There are lots of different ways you can jump into that. One is this notion of context. So if you if two people want to do a transaction with one another, they could just use a handshake. But they could also go a little further, they could write some stuff down. But no matter how short the thing is that you write down, there's actually complexity in whatever it is that you're agreeing to do. And the question then becomes how much of that complexity do we work our way through proactively? That's what lawyers spend all all their time transaction lawyers, we spend all of our time talking to one another about horribles stuff that some stuff that might go wrong. And so, and the horribles are out there. They may not happen. One of the great tragedies is that we we spend all day talking about horribles that end up not happening. It's, it's sort of useless. It also poisons many negotiations. Another way of doing the context would be that you point at the context. And so if you just pointed out this non disclosure agreement or you pointed at a policy on on on handling of medical data. So Global Alliance for Genomics and Health is a fantastic vector for this stuff. If you just pointed out that then you'd get that context and that context if you take some of the global alliance examples goes actually back all the way to the treaties. So but you, but you're you don't have to hop right to the treaties and try and figure out what the heck the treaties say. You've got a series of hops. So you can you can start from your napkin which you've signed and you can go on to the to the URL and you can see what the deal points are and you can see what's the two parties agreed is specific to them and then you can hop to the next thing which is how is this thing, if we go back to the non disclosure agreement, how is this thing essentially filtered for a conversation this way or that way or a conversation about a customer list or a conversation about, actual deep technology or the, and then you can hop your way and eventually you'll get actually to the treaties. If you hop your way all the way down through the thing. So it's a way of providing context. So that you can focus on the deal points, focus on one another, lift your head up from the page and look at one another, but still have the benefit of all the bad stuff that's happened in the past and how people have found ways to manage that.

Yeah. Another way of putting some of that might be how much of a law firm could be rep could be substituted. How much of what you get by being at a large law firm could be substituted by having stuff up in Git on GitHub, Rarible, other places like that. And my guess is an awful lot of it.

I I presume that's me. I'm sorry. I I came late the party. I don't see another Alan there. So Yes. Okay. I'm sorry. I don't have my camera on, but you're not missing much. So I'll just leave it off for now. So I just thought I'd I'd I I was I dropped in at the invitation of James, who very kindly invited me along. I I don't know a lot about the background to this, which is often the case with James and the things we do. So I parachuted in, but it's very similar to the the stuff we're doing. I'm familiar with the background. And, really, the observation I wanted to make is is that we are working with James to deploy this in construction, and we see this as a way of of bringing teeth to contracts with yes. Yes. Yeah. I like the fingers. Yep. Teeth. Teeth as in the cogs on the machine to the machinery contract so that we can begin to speed things up in speed things up in construction commercially and make them more efficient. So one of the big challenges in the construction industry is getting people paid on time. And to do that, people need to have contracts which the parties agree to, but in our case, contracts that we can operate on. And what we're hoping to do is is deploy changes methodology so that we can use distributed ledger technology. So we can pick out key aspects of the contract and have those key aspects trigger data and financial transactions. We think we're quite close to it. I think what James is doing is brilliant. It's the best I've seen. There's lots of other stuff flying around. It's sufficiently simple. And the thing that I think is very powerful about it is it it replicates the natural language contract, and that's the biggest challenge. We can't change the construction industry. It doesn't welcome change. So we're hoping this allows people to do what they've always done and use the contracts they've always used, but have those contracts used in a more intelligent way. And ultimately, we may deal with version control by deploying something called federated learning so we can begin to see how and where contracts have worked and not worked potentially. But that was my spiel. I'll just add that. I don't want to take up any more of the time.

Yep. Yeah. Perfect question. And I dropped something into the chat relating to a the example was just clearing a paper check. The paper check being the thing that's right on the boundary between a payment and a agreement. So the way I so a comp let's yeah. Hard a hardcore computability requires algorithmic expression. But a hardcore, that's also deterministic. And therefore will be wrong in some respect. There'll be some piece something you hadn't thought about. The Nobel guys refer to it to this as incompleteness of contracts. That is there's always something that could go that you hadn't considered. And so a really good way of doing this, I think, is to embed those things in the graph. So in our non disclosure agreement, we example where we're connecting two parties to a non disclosure agreement, we would have notice interaction interactions under the non disclosure agreement and many of those could be expressed really quite totally algorithmically. If you wanna tell me something, then it it it happens this way. And there may be consequences of the thing that you told me. For instance, maybe you're telling me that you're about to discuss this with some other specified person. This leads us to the point that in lawyers are doing all kinds of stuff approximating, these kinds of things because we assume that the notice stuff is not gonna work well. But if you had a notice thing that worked well, and that's an obvious blockchain example, then, then you you could embed the code for doing that. And it may be that there are other parts of the interaction where you could also embed code that algorithmically does that. But if you also if two parties then decided that they needed to tweak something, whether it's tweak something in the text or tweak actually something in the code by overriding that code and using some variant on that code. They can do that directly in the PROSE Object Model. So I see these as comp as the the the code stuff in a way this enables the code stuff because it allows you to step out of it.