 So one thing that you should do, put headphones in and then just start the, and we're back. This is part two of one session, the Inserio session, which is titled Interoperable Legal Apps and Services. We're going to stand by for a few moments to give time for one to join and for everybody to join in. So as you've got one viewer so far, more to follow, no doubt. So stand by while we, while we all get online. Yeah. Yeah. Yeah. Yeah. Yeah. All right. Great. So it looks like we have all, everybody's here and one, can you, can you hear me? I can hear you. Great. It's pretty wild. And Diana, can you hear me? I feel like it's more defensible. Diana? Can you hear me? Can you hear us? Yeah. Um. Um. Um. Um. Um. Um. Um. Um. Um. Um. Um. Because it's. Um, it's. Seriously. Okay. Uh. You might just be an expert knowing how to, you know, mitigate that.ramer. So Diane, can you hear us? Okay. Yeah. Okay, great. And we can hear you. Uh, can you hear Diana 1? Can you hear? In a minute, yes. Great. Right. So, one, we've heard that your session, part one, was really extraordinary. Brian was telling us that, you know, you kind of laid the foundation for, as it were, for discovery and started to introduce people to basically, you know, what is e-discovery and, you know, kind of the network and application layer with relativity and we're sort of ready to jump in and go a little deeper now with interactive, you know, integration of interoperable apps and services. Yeah. Yeah, it went well. There's going to be some overlap in session too, so whoever didn't make the first one, should work all the time. Perfect. So, let's wait, I'd say let's give people a few moments to jump on, but when you're ready, please go ahead and get started and primarily Diana is going to fill the role that Brian filled last session. And we should be monitoring the feedback from people on the integrated pigeonhole widget and she is also an attorney and a computer scientist and engineer and so she may also have questions or feedback from time to time as well. Yeah, yeah, I thought with Brian we had some back and forth and I thought it made it flow really well. Beautiful. So yeah, I think it's going to be a great conversation, so yeah. It looks like we've got some viewers so far, so if you do you want to get started and let people kind of, you know, experience this through the asynchronous wonder of YouTube. Yeah, what is the link for this one, the same one you said previously? Yeah, exactly. We're looking for the target length is about 45 minutes. Okay, so we're going to use, yeah, I can join. Well, as soon as we hang up here, I can join. Oh, actually good news. No need to hang up. This is the hang up. Oh, just the one for my break up. Awesome. Yes, indeed. So yeah, we can let's just get right into it. Cool. All right, if we are on, welcome everyone. My name is Juan Ramirez. I am the founder of Inserio, which is a custom development shop that customizes and develops applications on top of the relativity platform for the e-discovery industry. Mouthful, but a lot of turns there. So we will recap a little bit of what we talked about in the previous session. So if you join the previous session, bear with us while we go through some of the basics. I don't want some of the people who are just joining to be completely lost. So there will be some overlap there. Apologies, but hopefully this time I explain a little bit of the first time. So basically we'll start with e-discovery. If you're not familiar with e-discovery, e-discovery is basically the handling of electronically stored information. And that is something, let me share a little slide here. That is something that didn't exist maybe 15 years ago. I feel like a black and white movie where there's a law firm involved. It included some associate level attorney that would review stacks of paper, right? That was kind of like a little joke, a black and white movie. You get a stack of paper and you start reviewing it. Sometime in 2016, early 2017, there was an amendment to civil procedure that basically said that electronically stored information can be used as evidence in court. So multi-billion dollar industry where you would host this patient, you would review it, you would provide the results to a opposing counsel. You can see in the slide, it's pretty massive already. It's 2018. It's a $10-billion industry. And in four years, it's been a close to double price in the past. And that's basically why we exist. We, as a serial, we program our property for various reasons, right? They have really good coverage in their API and they control it up there so we're not tied to old technology. They are a dominant, you know, they have a dominant footprint in the industry. So that means we get access to a lot of the clients. And it really is something that with a base that either a .NET or PHP or any other client scripting, it's so flexible that you don't have to be technology centric, right? You really could write something with client scripting and use REST to query or update or whatever your application has to do with relativity. So relativity, you know, it's core focus currently. I'm showing you the EDRM, which is the whole process of eDiscovery. They're focused in the middle, mostly. They are expanding quite a bit. But between processing, review, and analysis, this is kind of what I'll go over relativity in a little bit. Collection is the piece where they start, you know, saying, what information do we need? What custodians are there that interest us in the dataset we want to review within relativity? And production-wise is, you know, just generating the documents that you've found to be pertinent to the case and sending them over to opposing counsel. So, you know, they're expanding the presentation piece. There are some applications they're starting to work on. And some of the pieces on the left, they're starting to work on as well. But their bread and butter is basically, you know, processing, review, analysis, production, and collection. So they're growing. And that's why we've basically partnered with them and we focused to be our niche. And that's our technology. And who are we? We're a small company. You know, we're about 40 strong right now. We started in 2011. And there's enough demand and the industry is going, you know, in many directions. Not only discovery, does it, you know, our development doesn't just, you know, is not centric around, you know, how can I review documents faster? Or things where, you know, can I find more accurately the documents I'm looking for? Lately, it's been more facilitating the jobs of maybe it's project management for a case. Or maybe it's just analyzing data in different ways that don't necessarily have to do with document review. So things are kind of spiraling outside of the scope of review, which is, you know, it kind of aligns to what Salesforce is doing, right? They obviously focus and started off as being like a customer management, customer management platform. But there is so many things you can do with it that there's software shops that expand its functionality. And now some of those software shops are worth like, you know, over a billion dollars. But, you know, right now we're focused on relativity. We could expand at some point. We do have some, you know, AM law 500 in our list of clients, some big service providers, which is basically these companies that provide like legal services to either law firms or to private or to corporate. And corporations as well, as well as government. So we're expanding as well as far as our client list is concerned. And then, you know, given the examples I was giving before, which some of our biggest successes aren't centric to reviewing a document, last year we had a huge case with Brickler and Neckler where they had a pipeline or, you know, this was the petition that was last year. The petition issue was analyzing signatures that were to approve a petition in the state of Ohio. And this was, you know, the first in history where they win a case in the Supreme Court of Ohio. And it was based on the application that we developed for Brickler and Neckler, which was probably not very familiar with it, which I wasn't either. The whole petition business is kind of, I don't want to say shady, but it has its sides where you're actually paying for signatures. So once you're paying for something, it has a tendency to get out of control. And so what we got the case thrown out, or they got the case thrown out thanks to the tool we were using, they were able to analyze that there was, you know, procedures weren't being followed. One, they started collecting signatures too early. And so the judge said, you know, we can rule it out just based on that. And the other one, we were able to visualize the data in a way that shows where things were going. So, you know, we broke it down to all counties. So it actually looked like a voting map. And you can see red when things were going. And this was a big deal. This was a big win for that law firm. And the return on investment was huge. And so this is a good example of how, you know, it's breaking away from just the regular day-to-day review. We covered wireless relativity. So those of you who weren't in the last session will kind of appreciate a little walkthrough of relativity. So I kind of want to go through its basics and some of the concepts that it has. And any questions as of now, am I going too quick or anything like that that people want me to focus on a little more? We don't have any feedback here. So I think we have a good flow. So yes. So if you're seeing my screen, relativity is basically a big relation out there. What they do is they break things down from climate, climate data, and a good thing to have some workspaces within it. And so a workspace is basically a bucket where I can throw my documents in and basically create work products. You know, it's, it's, what we've done here is the collection piece of the EDRM where we have documents inside relativity at this point. And what I'm showing here is the actual viewer of relativity where you take native documents. It could be an email. It could be a word doc. It could be a PDF. You know, it could even be like an SMS message. And then we review it in relativity. And so how things started when relativity first came out was the cases weren't that big. They were in the hundreds of thousands of documents and you can hire some attorneys to manually review the document. And what they would do is tag these documents. They would say, All right, this document is not responsive. Let's review the next one. This document is responsive. Let's keep going. And so this obviously takes time. And it's not inexpensive. But these are people who are billing hourly. And so the, what started happening is they started implementing machine learning where relativity can start learning and you train it to whatever document you're interested in, whatever topic, you start selecting those documents and it starts building basically a model of what it thinks you want to see. And so now that cases are, you know, five, 10 million documents strong, it would take a really long time to manually review each of these. And so with machine learning, what they've done is reduce the workload quite a bit and allow you to focus on things that are most likely relevant versus, you know, either junk mail or jokes that people are sending to each other that have nothing to do with the case. In order for you or your firm to, you know, save billable hours or turn things around a lot faster and be able to produce your documents to opposing counsel. And so relativity has this metadata and it's expandable. There is workflows that your lit support or your project manager will basically give you a recipe for. But it's very common to have multiple passes in a case where, you know, you have your associates kind of go through the first pass and so you see, you know, filter things out. And then as you have that filter result set, you can have some of either a partner level or some other attorneys that are more focused in the case that you're looking at. And so they use all kinds of metadata. This is all customizable. I can add different fields. Anything that you see is it has a property is basically what they call fields. And fields is just metadata, metadata that you can tag onto this document. They have searching, highlighting, using keywords, using DT searches to get some concepts or to build some rules around your searching. And so relativity's focus is really getting, you know, finding a needle in a haystack through big data sets. They started off using SQL as their back end. They still use SQL for basic, I guess, object relationship and properties. But when we're talking about actually looking through big pieces of data, they use a technology that's a no-seval database based on the scene that allows you to really search very fast and large data sets. So they really have evolved as case loads have evolved and grown. And that's one of the reasons that we stick to them. Another reason we stick to them is the extensibility of their API. And so the API that they have, it basically covers all of the functionality that they have available in the application. An event handler is basically something that occurs just as it sounds. I do an action. It could be on a document where I save a document and I gave it a value that maybe doesn't coincide with another value. And this would be an event handler that we can write that says, you know, if you wrote something that says this document responsive and then you have a conflicting designation that says, all right, this is not responsive, but I've said this is hot, we can write an event handler that shows a warning and says, hey, can you review the other piece of data? That's an event handler with them. Maybe we can have one of the questions because they're all about SQL, no-SQL database seem structure. And also maybe a second question on the top of that, the schema, if you're using JSON or XML, because you always have this trouble of finding the schema and the right database type. So maybe if you could explain in the demo, it would be great. So they could understand what are the fields you're mentioning and how it goes. Sure. Sure. So great. Thank you. So I will build in the first session we built, and I will show you using this, I'll jump around a little bit. In an API here, it could be an API, but this is like a way to write applications without writing any code, which is called dynamic objects. And that is like a visual way of creating a relation database by creating entities and that's analogous to a table and then columns and these are called RDOs. And so I'll show you what we did in the first session. We actually created the concept of a contact and we associated that contact to an address. So we created two objects, you know, I think we have like part of the Smith family here, but basically to relate to your question regarding databases, I created this using no code and it's basically called an object type. And an object type in this particular case is just something I named. I said new object type and then I created it and then I started adding fields, which would be analogous to columns in a data table. And so it really is like a visual interface to creating data tables in the SQL database. And whenever to address your no SQL database, it stores anything that we were to create as a really large piece of text, right? So they have different field types, one of them being fixed length text, which could go up to 4,000 characters or long text, which is I think pretty much unlimited, but they might have capped it at maybe 200 megs. So it's a really big piece of text and this is where the data is stored on the Lucene engine or which is the elastic search. And I don't know if that answers the question at all, where we're creating database structures with just the user interface and some things go into SQL and some things go into the no SQL database. Yes, because one of the questions was related to graph database. So it was linked to the no SQL question. So this is kind of to grab up the questions, the structure of data. So it's kind of and also on this is kind of the question that has been popped up. It's one related to and you're trying to get that further is what is the actual business model when you do these things versus if you are selling like machine learning, we sell software as a service. And another thing is for the user, how they integrate these things with the other applications because you're building one thing and you have to integrate with the other kind of software. So yes, it's kind of the questions being popped up right now. So there's two business models here at play, right? Relativity's business model is obviously they've gone into software as a service, which is they have a cloud solution, they'll host your data for you and then you can kind of use their software on the cloud in a shared environment, but it's really your slice because they're all on the cloud, you don't really share things. There's a lot of privacy and security that there's no way you'll be able to see data from someone else. And our business model is basically just development services, right? If a law firm comes to us and says, I need this application built because it's, you know, this process is very inefficient or we need to track this data, then we become a regular development shop where we'll spec something out, we'll do some wireframing, we'll do some estimating, we'll finally agree on something and then, you know, once we have a price and a timeline defined, then we'll start working on that product or application. And, you know, we're an agile shop, so we try to deliver something every two weeks. That way we don't get too far away from the original design or it gives the, basically the customer, the law firm an ability to change their mind without, you know, investing too much into what we were currently developing. So, the thing, some of the tricks that we have is sometimes we have some white label on try to resell or just doing from scratch because sometimes it's much easier, everyone is asking the same thing, so it would make sense, I would say. Then try, yes. Maybe we can have started with the same concept that we have, which is, hey, get the custom application and do it, you know, every time. Incredibly, a lot of the applications are so unique that we haven't had too many that are, hey, we did this for this other guy, why don't we just like give it to you again. The times that we have, they're different enough where we start from scratch. The times that we've seen enough similarities, we could theoretically change our business model to actually selling and licensing the software versus, you know, creating it from scratch every time. And some of our competitors have done that. They've created a couple applications that they sell. For example, there's one from Malilly that identifies personal information in a workspace and redacts it automatically from the documents that are online in relativity. So, there are some very interesting solutions out there. Us from a company standard or stance, we have not made that jump yet. We might, I mean, obviously there's benefits to that business model, but there's also negatives, right? You have that residual income, but then you also need this ongoing support structure that we don't have yet. And also Lincoln to that is how do you integrate because you have an application, they are using application for third parties. How do we plug in because we have to kind of plug in the whole thing and the client in the end wants something that flows across the whole ecosystem they have inside. Yes, so there's different ways. They have what's called integration points, which it depends what you want to do. I'll give you an example, which is there was a law firm that wanted to link their billing system where all their attorneys basically logged all their time in and they wanted to put that, be able to report to a specific case that was already in relativity. And so they wanted that to be seamless. And so what we did, hopefully their application did have an API and if they don't, there's got to be some sort of entry point whether it's directly to the database or some, hopefully some service you can consume. In that particular case, they did have an API and they were all kind of on the same network, so we were able to use the same authentication to get into both systems. And so you could enter your time in from relativity as you were reviewing, you would take a batch of documents and then you would log your hours and it would report back to their time system. So, and this is just an example, you can tie it into anything else. There's a lot of workflows that want to handle the data in one system and then once that data is massaged, the reduced documents that can come back to relativity. And that could be done, I talk about agents, which is something that runs on an interval, it could be something that goes out checks if there's a new data to be consumed, brings it back in. So most solutions that we work with have, they touch different pieces of the API. But so far there hasn't been anything that we haven't been able to integrate with one way or another, right? If it's legacy technology, are we using text files? Are we doing like mimicking clicks and things like that? They actually have no API and it's an old Windows application. But most things are fairly modern that have an API or a database that we can integrate with. I don't know a law firm with the API, so I'm guessing it's not a normal case. It depends on the software. Most law firms are hesitant to write something custom that's only good for them because they have so many worldwide branches, a representation that maybe this works for the New York office, but it's no good for the Zurich office. And so they tend to buy off the shelf applications, which at least been my experience. But when they don't, they do allow us to write to whatever industry standard application they have implemented. Another thing because it's very related to legal is the language, because you have been working English primarily, right? And one of the question is, and it's Spanish, because the whole maybe some of the things you have work clearly in English language structure. So if you have experience in other languages, here the question was Spanish, but we're expanding to other kind of other languages other than English and other than US legal system. Yeah, well, absolutely. They have a worldwide presence. They can do Mandarin, Japanese. And basically most popular languages, I don't know if they do some more niche languages, but they cover most of the globe. They have office in China. They have an office in Australia, in Britain. And so they do cover a lot of these languages. And it's part of the configuration when you set this up. It is a challenge that we have sometimes, because if it's software that is not centric to an English language, then we have to be kind of aware of that and be zone centric. So it knows that you're in Japan. And so a lot of our error messages and prompts and things like that will adapt to the language you have defined within Relativity. As far as programming and some of the documentation of their APIs, that's all in English at this point. But for instance, have you been working with... Because this is not just a structure, how do you collect analytics at language processing is the hardest part. So it's kind of the experience not just that the fields are the same on the same spot on the front end, but on how if using natural language processing, you have to change the whole algorithm, the whole notation of the database. So it's kind of... Agreed. I know the language adaption that they have is basically... No analytics can work in most alphabets, not the expert in the analytics engine that Relativity has. But I know you can get Relativity in most popular languages. So I probably haven't answered your question whether we have to adapt to the analytics models. I can get back to you on that one and post the answer in the pigeonhole once I talk to their experts. So that's something I could follow up on. Yeah, that would be great. Okay. Yeah. So if you want... I'm sorry for interrupting the presentation. No, it's not interrupting. It's great. So where we left off was in the last session we built an RDO that was a contact that stored different addresses in another address. So we have contact and we have addresses. And when I say RDO, it's anything that's a dynamic object. People use them to track all kinds of things. They can create a project management software without ever writing a single line of code. They can create contact lists. They can track the shipping of hard drives when they receive them so they can adjust them into Relativity. So really anything that you can think of that you can draw on a piece of paper as far as here's this and then tie it to this. In this particular case we just did a contact with different addresses, which is a very simple example. And so what I wanted to expand on to keep the coverage of dynamic objects is create another dynamic object that we can then visualize somewhere else. Maybe it could show because I could see what you see. That would be great. Thank you. Yeah, so it's a good follow. Thanks for that. And so what I want to do here is create some sort of like project management software that I can just simply assign a task to somebody who creates tasks and monitor them. And so I've gone into my admin space creating a new task object. And right now it's just a text description of what it is. So now that I've basically created a table in the database called task within my workspace, my demo workspace database. And so to add columns to it or fields as they call them, I can create new fields. Some of them end up being columns depending on the field type. Some of them end up like we talked before about long text fields. They end up in a different database or database type. In this particular case, let's go ahead and create the basics, which is, I don't know, start date. Cheated some of them are, which could be just date. And we can kind of keep going. Let's start date. And we'll just do a couple here. I don't want to waste too much time defining this object to its completion. This would be date as well. And we want to see something that tells us how it's going. So status would be very helpful. And status, if we choose field type of choice. Single choice, since it could either be like a new in progress and we'll add choices to that in a little bit. And the task can probably have, I think, priority, something I had mapped out, right? It's also going to be a single choice. And let's go ahead and do something long that would sit in a different database and we'll do it like a long text field. And so now we have this concept of task and we can look at its properties that we've built in 30 seconds. There are some system things in here that are inherent to the system because they want to track who did what and you can assign permissions to these things. One thing I do want to do this thing is add relation to the context. So I do want to be able to assign a task or a person to a task. And so let's see and we'll make it contact. Okay, so now we've built our object as all the properties we want. In the database for the most part, anything that's text or not fixed-length text is sitting in a table. Anything that's choice actually gets split into other tables and the reference to what they call artifact ID. So it's basically two tables with a join. And anything that's long text, you can configure to sit in this other engine or this other database for quick searching. And so once we did that, we have a new object here and these are tabs in Relativity. And it looks pretty bland, right? This is very flat. And so they have this concept of looking at lists of things. They call these views. And if I want to add columns to it, I basically edit my view and give it whatever fields I want to look at. And so I'll add all the ones that we just talked about. And since you can see I have my new columns now, but I don't have any objects. So to create, this would be like a form, pretty similar to how you would use like Google Forms or a Survey Monkey or any other piece of software that allows you to collect data. Now that I have my data defined, I have to edit my layouts, right? My layouts tells me what pieces of information I want to collect in my form. So I'll say, well, I want to know, I'm assigning this to. I want to know what priority this is or I want to enter that in. I want to do start and date. And let's give it a description. And we'll make this one a bigger field and status, right? Is this thing... Just a quick question. This is very pre-logic. So it's kind of you are setting up the rules of the task, right? Yeah, because, yeah, this is kind of the question I was looking to this. So we have always to pre-define the flow of a given task. I need this task and I need these elements, right? Right. Yeah, okay, great. Yeah, so in this particular case, we're actually building something that doesn't have too much to do with the actual case, right? There are documents in the case that are evidence and I kind of want to find the hot one. But what we're seeing is that people are interested in building applications that sometimes don't have to do with the actual review case. They have to do with productivity and task management or project management. And so this would be a case of somebody really simply building something that says, let's not lose track of this. Let's put a date on it. Let's assign it to somebody so there's some accountability. So just by clicking around no code yet, I'm able to have a functional structure that I can work with. And how's the feedback from the people using it? Because it seems easy. So this is one of our non-coders. But because sometimes we have to teach how to use software and technology. It was one of the human factors. So how is the feedback? It's double edged, right? There is a learning curve to relativity. Some of the features I'm showing you right now are very easy to learn since I'm just clicking around. You have to be familiarize yourself with what is an object? What is a field? What is a choice? And if you don't have that, there is a learning curve there. But they have really good documentation. I think the learning curve is steep when you start dealing with some of the other facets of it. For example, processing information from Outlook PSTs or exchange files or running analytics on it and running indexes. That's half art, half science, where people know where the case is going to go. So they know indexing 10 million documents is going to take a while. So where should we segment this or should we split this up into a different case? So that's for a good case project manager or a good litigation support specialist would be able to guide you in this. But for somebody who has been, are onboarding for somebody, for example, in the QA side of things, is a couple of weeks. So within a couple of weeks, you should be pretty proficient in relativity and be able to write some of these, I guess, structured apps where they're just dynamic objects. Where it gets the feedback, the negative feedback is yes, this is good, the positive feedback or the negative feedback is that, well, the UI is very limited. All right, this looks good. But for example, there's nothing that says, all right, if I select status complete, then why wasn't it assigned to somebody where you start building some business rules? And that's where the API helps, because we can create an event hammer that says, all right, if you have moved this thing from new to in progress, which we haven't defined the choices here yet, then there should be a business rule that says, well, if it's in progress, then it should be assigned to somebody. So that's where some of the business rules would start happening. And I could say, new. And here I am adding the different choices for the combo box. And this is all self-contained, right? I haven't had to leave the interface, it knows, and I have rights to do this, I'm an admin. So you could limit, maybe I'm just someone playing around and I created a new choice and I threw the whole project management application out of control. I'll do the same thing for priorities. All right, so now I have a full functioning little application. I could assign it to people, and these are people who have previously created, so these are also dynamic objects. And let's see, my first task is, all right, demo RDOs properly. All right, this is in progress, this is what we're doing. We're doing it today and we'll finish tomorrow. And we'll say, all right, make sure people don't fall asleep while doing it. Hopefully I'm achieving that. All right, and so we've just created a task object. We added all its properties. We've created an instance of it. We've created this view that tells us what we can filter for and sort by. We've also modified the layout, which tells us what pieces of information I want to collect. And I've also associated it with an object that we had previously, which was the whole contact. And so now I have a set of objects that I created without writing a single piece of line of code, which is when we have the task, we have the contact and we have the address. If we were to visualize this, we have the address relates to the contact, the contact relates to the task, and it all kind of plays well together because if we were to look at it as a schema, there would be several joins making this happen. And then, as we mentioned before, if you wanted to do something like this from scratch in your own web app, obviously you need a database, whatever database it is, have your DBO create this for you, then migrate that over to a web developer. The web developer would then create the layout that we had and then create this type of functionality where it lists the actual objects that you have in the system. He would need to have all the functionality for filtering, sorting, and searching. And so those are the things that would probably take a couple of weeks, I would say, depending on how efficient and how good their requirements are. But it's something that we did in just a couple of minutes and we didn't need to do anything else. Now, you're saying, well, why do this in relativity? If we wanted to expand something like a task, we could assign it, we could associate it to a document and say, hey, somebody review this document, I'm very confused as to why somebody marked it responsive. Or the task could be, we could say task types and it could be prepare this document and print it out and review it or email it to somebody. And so the sky's the limit as to what you can do. The things that we've done a lot and without actually messing around with the interface too much is event handlers that keep data consistency and avoid errors or do cascading things where you have a choice that you want to fill something else out based on the choice that you previously set. So it's basically an event handler could be very well used to follow business rules or to make life easier for the reviewer. So that would be the reason to keep this all in relativity. And so far we've seen the same thing that we saw in the last session. I don't want to say boring, but it's pretty bland when we look at this thing. And so to give you an example of how we can further make this a useful tool, I will show you something we wrote really quickly to demonstrate how you can take something that it's back end is in relativity. But we wrote a front end for it so you can actually manipulate it as you would in a more, I guess, useful way besides just treating it like you're treating it like everyone. Just a quick interruption maybe. One of the cool things is I looked at this and I understand the value, but maybe if you could explain how a normal lawyer could pick up this and see how they could improve their practice because most of the time in lawyering it's actually with these small talks. So maybe if you could give kind of an example of how a normal lawyer could use this and how they could get the benefit. Could be great on a real example because if we see this and the question is, hey, I'm here, I see that, but how can I use this? And also because it sounds simple but has a lot on the back. So it would be great. They understood what you were actually doing and how they could be actually benefit from it. So it's... Yeah. So I think if you... Oh, and also because... Yeah, and also because... ...that have been able to bid on cases because they're more efficient due to some of the tools we wrote. In the particular case that I'm showing you right now which is a simple task management application that assigns to contacts, maybe an attorney wouldn't use it so much but their lit support team would. So if they have questions or they need to add more memory to a system or they need to do some mass printing or whatever task needs or create a new user account, anything that's going on from the support staff or the lit support team, instead of sending emails back and forth and things getting lost in the whole email thread, they're able to track something and actually associate it to something measurable whether it's they created a new object type or they gave access to somebody within the workspace to a certain object or assigned a document to somebody for further review. It would make them more efficient and allow them to either under bid or have bigger profits or use less people. So it really depends on the application. To give you a real-world example which is what I was mentioning before, we did a case for an oil pipeline that was being built and so the people who were building this oil pipeline obviously had to purchase a lot of land to get the pipeline built. Instead of looking at all these basically data tables that relativity shows you, we were able to take a lot of that DPS data and actually map it out and tag with colors to see what the process was. Like green was, we purchased this piece of land. Red was, the owner of the land is not cooperating so we probably have to go to court and see if we can get that land somewhere. Orange was, we're in progress. And so it was, even though it's the same underlying data, visualizing the data and creating a nice interface for it allowed them to be very efficient and actually monitor their progress a lot more than having thousands of pieces of parcels that you were all over the place and they had to relate data to it. And in that particular case, they probably had like maybe 50 different object types to track this whole thing and we solidified it into two interfaces. So it made it really simple to write reports and make them efficient. Another thing that I'm looking at is most of the time we lose is trying to find information in millions of documents. Yeah, and this is the greatest values that I've seen database because we have tons and tons of data and we have to find a needle in a hashtag and kind of, this is why we lose most of the time. So maybe you have some examples with that could be great because I think any lawyer kind of know how many hours has to review documents. So it's cool. Yeah, tons. I mean, the biggest advancement is that is their quick searching and the analytics engine which allows you to do conceptual searches. For example, if you were just to search on the word school, if it was just a keyword search, it would just look for school. But through the analytics and their concept engines, they can search for school, university, campus. It would encapsulate all that and you can narrow it or expand it as much as you want. And so it basically facilitates what you're thinking about and expands it into what it could possibly be. And so it's trying to reduce the manual review because it is time consuming and expensive. So through their machine learning, which I think they just call it Relativity Assisted Review, you start training the system. It starts learning about what you're interested in and trying to find models that it could use to give you similar data sets. Like memory libraries tries to learn with you what you do and try to get feedback back in the loop in the models with something like that. Yeah, you're creating these models based on what human, some human, for example, chose 100 documents based on what you marked. Yeah, this document is relevant. This document is not relevant. It starts building its models and then eventually should be able to save you tons of time by reducing more than half of the workload or the documents that you have on there. Because as data sets grow, millions is now the new standard where thousands was before. There's just no way you can, a good reviewer is doing 60 an hour, 60 documents. And if you have a 100 million document review case, you either gonna pay a lot or take a lot of time or you start using some of these machine learning technologies. So just before we wrap up, the last question because we have some people asking about if you have some kind of trial version so they can test for free, yeah. So it's a good way to get better testers and have feedback just saying. I know they have the educational concept where you can speak to relativity and say, hey, I'm really interested in this and whether you're in a university or you just kind of want to learn it. There's tons of education. As far as them giving you like a free instance, I'm not 100% sure that could be something I myself or Brian can talk to our Janice, our rep out there and see if they do have something like trial. We're just closing. So maybe if you could add some final words and how maybe some highlights in the end would be great. Yeah. Well, from a, I can do both, right? Where I can focus on what we've been able to do in relativity, right? The technology is extensive. So you can either write something from scratch and build something very powerful or tie it to industry standard applications that people are using. The reason we use relativity is just its coverage. Their constant API and the EDRM expansion. And it's easy to learn. They document their things very well. They have examples and it's tools that are not technology centric, right? It's not like we're writing in PHP or old ASP.net. They modernize their APIs and their RESTful APIs so theoretically you can write in any language and be able to consume their services and use the APIs. So it's something that if you like PHP or you like Python, that's, you know, you like Ruby, that's where you want to program in and you can do it. So that's kind of why we stick to them. So it's language. Yeah, it's agnostic. You're on mute. So I think that's it. And I would like to thank you for the talk. And congratulations on your work. You also look great. Hopefully you have more projects to show up. So and also you can, most of them can recycle. So you can do SAS as well. It would be great. Yeah. Well, it's heading that way. That's the way it's going. And good luck as well. All right. Thank you so much. Thanks everyone. And just in closing, what can people look forward to tomorrow in the breakout? You've got some more. If you haven't addressed that, can you just mention that before we close the broadcast? Absolutely. So tomorrow we're going to we're going to consume two different pieces of technology, right? We want to give you an example of consuming some AI services. So we're going to write a quick application that does some translation using Microsoft Cognitive Services. And we also want to tie into some of the theme today, which was, you know, can I use industry standard tools with relativity and how can I tie into them? So we're going to write a simple application that basically ties in slack to relativity. So you can run queries from slack. Hey, you know, how's this workspace doing? Or, you know, how many people are working on this task? And so those are all, you know, based on rest and the APIs from both technologies. So we'll actually look at code and it'll be a little more hands in the zeros and ones of these applications. Beautiful. And then again, just, you know, we're under some obligation as a not-for-profit, you know, institution. Of course, we're not endorsing relativity here, but we do think it's a, and Serio is a great example of a company that's showing how, where there's a legal platform that provides application programming interface that's well-documented and featureful and, you know, simple and powerful look because it's rest and uses tokens. This is the type of constellation of apps and services that you could build. And there's like a budding ecology. There are other e-discovery platforms. Some of them do also have interfaces and the high-level point for purposes of the computational law course and law.mit.edu in general is that when there are platforms, government platforms, legal platforms, commercial platforms, you know, billing platforms, whatever, weather platforms, whatever is relevant to you that have a rest interface. This is the type of stuff that you can do to extend and transform your business, the business of law, the practice of law. And there's nothing better to understand than to dig down an actual real-world example with people who are at the front lines and that's partly why we're just so tickled to have you and your team kind of pack along with us. So thank you very, very much, Juan. No, thank you guys. I'm going to be a part of this. Okay, thanks. So thank your team for us, for everything they've done, and we look forward to hacking the law again in a good way with you tomorrow. All right, thank you very much. And thank you, Diana, for facilitating and monitoring the course for us. Okay, bye now.