 Hey everybody, it's Brian with the 2019 MIT Computational Law Workshop course. And we're here today for the breakout session with Juan from Ontario and we have our superstar monitor Diana helping kind of get the conversation flowing and going and ensure that your pigeonhole feedback is digested. And so with that, I'm going to kick it over to Juan to kind of give everybody an overview of where the day is headed and then we will then we'll start digesting questions and diving into how to, to the different ways that you can build these cool interoperable legal apps and services. All right. Well, thank you, Brian. Thank you, Diana. Hello. My name is Juan Ramirez from Inserio. So today is going to be a little bit of an overview of relativity, which is a document review platform in eDiscovery. What we're going to do is kind of show how we can build applications within relativity using no code. And after that, we'll expand into writing custom views for manipulating objects and manipulating data. And the third part of the presentation or the workshop will be kind of some hands-on and looking into code of some very simple integrations with some Microsoft cognitive services as well as with Slack. So what we want to do is get you an overview. Some of you may be familiar with relativity, some of you may not. So we'll start with a slight overview and we'll even backtrack a little bit to eDiscovery. So those of you who don't know what eDiscovery is, it's basically the handling of electronically stored data for litigation. So somebody else, Pepsi, Suzco, Coca-Cola, they're going to want to collect some documents and review them. And in the old days, how this happened was just stacks and stacks of paper and you would just have these papers you were reviewing, you put in one file, it had to do with the case and you discard them if it didn't. Nowadays, I don't know the exact law or the exact date, but I know in sometime in December of 2006, they allowed electronic documents to be submitted and reviewed in court. So that opened up a multi-billion dollar industry, which at this point is, I believe in 2018, it was at $10 billion industry a year and the estimates are for 2023 to $17 billion. So it's a growing market and with a growing market and good backing, there comes innovation. And with an expanding market, we see things like relativity as a platform instead of just like a SaaS software. They are forward thinking in the way that they know that one case does not fit all, so their software doesn't fit all the whole workflow of the case. And so they allow you to build things on top of it. So with relativity, they've been around since I believe 2005 and let me kind of share the covers that they focused on. So what we're looking at here is the EDRN graph and it covers the whole spectrum of the process of a collection anywhere from identifying data, preserving it. As soon as you get like a legal hold, that's when you have to identify data that has to be collected. What custodians are involved in this case? And so once that gets collected, it gets processed into relativity. So when I look at these little blue squares, this is where relativity is kind of bread and butter. They're expanding and they have horizontally, they have more coverage, but this is kind of where they started. They're already doing production. They're looking at tools for presentation. They're all doing collections. So they are covering more. But from our perspective, we customize things that are in this blue area and even outside of it. A lot of the things that we do are not even having to do with actual document review. So our document review, they have a viewer and I can kind of go into what relativity looks like in a bit. But applications that customers normally ask for us sometimes has to do with document review where they want data to be consistent. So they'll ask us to write something that this happens, then set the document or email somebody to do this. But a lot of times it doesn't have to do with review. And that's kind of where relativity is a forward thinker where their API allows us to write applications. For example, we wrote an application last year for a, what was it? It was the pipeline. No, that was a year before. So it was a petition app where somebody was kind of like pushing for this law for, I believe, for the cost of liver transplants. And so it was a certain process and these guys kind of analyzed the whole petition process through relativity, which really had nothing to do with review. They were just analyzing and visualizing data. And this case was kind of like a first time that it goes to the Ohio Supreme Court and it was dismissed partly in help for the application that we wrote for this law firm because what they did was, they allowed, they visualized the counties in all of Ohio and they were able to see who was progressing, what dates they started on and who was doing these signatures. And so the judge basically saw that they started signing things way ahead of time. So before they agreed upon time and there were things happening at different sites or different counties at the same time of different people. So they dismissed this case and it was a pretty big deal because it saved them like $20 million. So it was a huge success story, huge return in investment there. So there are a lot of examples that don't have to do with actual analyzing and reviewing documents and their API kind of allows for that. So from a little bit about us, we are a small little development firm. We're about 40 strong, we've been around since 2011. But in that short time, we've managed to work with some really big law firms. Some recognizable corporations. And it's basically fitting and aligning the software to their specific workflows. So why relativity? This is it, right? They're growing coverage of the ERM, forward thinking on the API coverage and what you can do with it. And they have a big footprint, right? So then we get access to a large client base. Just maybe some people don't know the difference between SAS and ES or infrastructure as a service. So maybe if you could kind of explain, because some people may not get the difference, would be great. Yeah, so relativity is going through an evolution right now where it was software that you would host in your own servers, in your own data centers. And they're converting over to SAS right now. So software as a service. And that's basically what a lot of these web companies are doing. They'll you'll put your data on their servers. They'll host it, they'll manage it, they'll update it. And it's basically you don't have to worry about infrastructure anymore. You just care about your data and using the software versus owning it and requiring administrators and DBAs and things like that. So software as a service is you don't have any servers in your data center. Great, so yeah, we can move on. Great, thank you. All right, so if you haven't seen Relativity ever, I'll do a quick walkthrough. So relativity kind of aligns in the way that they have clients. They underneath clients, they have cases. Underneath cases, a case could be broken down into several workspaces. And a workspace is basically a bucket where you can put all your documents. And once you have your documents in a workspace, you can use analytics to basically do conceptual searches. You can do keyword searches. The main engine is that they allow you to break out work into batches. And they add this thing or metadata, which they call fields. And fields in this particular case is what we're looking at in the pane on the right. And this is really part of it is metadata that came from the document itself as to when this email was sent, who it was sent to. But other pieces of metadata are things that we can add to the document itself. For example, here you can see it's a first pass review. And this is where they would assign it to a low cost or an associate level attorney where they can review these documents and then make a decision whether it's relevant to the case or not. And so with cases growing and growing, in 2007 cases were an average in the hundreds of thousands, so 100, 200,000 in size. But nowadays, it's easily the average sizes in the millions. So instead of having people manually review a lot of this, they've come up with a machine learning model that you can train the system to show it how, what content you're looking for. And then so that creates predictive coding. It'll give you a subset that way you don't have to manually review 5 million documents. You can focus on the documents that the system found relevant for you. And there are samples that you can go through to make sure it's aligning. The model is aligning is what you're looking for. And the whole idea is to find a couple, what they call smoking guns in a big pile of documents. There's a, most of it is just junk, right? If you have a 10 million document case and you're really looking for a handful that points to one direction or not to the case, then this is where AI and machine learning is really stepping in. So you are using kind of the train data sets, something like that, right? Yeah. Yeah, great. Maybe, yeah, the thing, actually, this is another thing. You are also using permits prior, right? Like who can review the document and who can kind of sign off the flow? Yeah. So it's like in paper, we have a permit. This is kind of equivalent, right? Yes. So it's very granular. You could split things up into document folders or even at the document level, you can grant people access or not. And so not everyone can view everything. This is what eventually becomes like privileged documents. But yeah, relativity has a very granular security system. So even with documents or with other objects or even functions, right? Not everyone can download natives or not everyone can produce a document. Not everyone can create safe searches. And there are safe searches that are private that you don't want other people to see. So there is a lot of granularity in the application. Because I'm just thinking about the typical NDA. That is one of the big things. Who can see what? Who can download? So this kind of one of main things when you have NDAs and all these documents on several transactions, for example, I guess. Well, I would assume that the NDA probably covers the entire content just because if you're reviewing the document set, you're part of like your counsel team. And then by the time it gets to opposing counsel, right? By the time you produce documents and hand it over to opposing counsel, I mean, there could have already been redactions. And you don't have to, I mean, it's that part of the law. I'm not sure if they give the whole set of documents or just the subset that needs to be produced that are relevant to the case. I'm thinking like it happens a lot. Sometimes you have a transaction. You have to send some piece of information to accountants, a lot of people. And you don't want to send all just that parts. They have to review. So sometimes you have this kind of typical example in big transactions, I guess. Yeah, so I think when you send it over to opposing, then you definitely limit what you're going to send over. All right, so this is relativity and a three minute explanation from a document review perspective. And if we look at like what they have to program in, and this is why we like it is just that the covers that they have of the functions that they offer is very extensive. And this very first one that we're looking at here, the relativity dynamic objects, is a way to basically interact with the database without having to know any, without needing a DBA basically and doing it all visually. And so an example that we have here is we created some contacts and we created some tasks and associated address objects that associate to the contact as well. So we built like this whole, this whole, well let's look at fields. So object types here you can kind of create an analogy between a data table or an entity of some kind. And so here we've created an item called task and task we gave several properties. And this was all done without writing any piece of code. And so we told that we want to know when it's due, we want to know when to start, what the status and what the priority is. And this was simply done by creating a new field or a new property onto that object. And so the purpose of this would be to basically store data into relativity without creating new tables since it does that all in the front for you. And we did this example where now I created a task definition and now I can actually enter in my new task by using these layouts which is basically just a web form. And these web forms are all dynamic where I can modify them and show you or make available whatever data you want entered. So this is all being done and it allows you to really kind of get some kind of project going without visualization. And so where we come in and where we specialize is to actually, so people can see I've got the application. I think we lost your image, just maybe it could work. Yeah, yeah, thank you. You see it now? Yeah, great, thank you. So this is usually, we usually don't get involved in this piece, usually customers or a lit support person is they have enough expertise in the application to be able to build some of these, I guess data driven apps. But when it becomes kind of a pain to actually work with this because if you look at just tasks itself, it becomes very Excel-like. So now I just have a list of things and to be able to manipulate it, I have to edit and make changes, things like that. So it went in progress or it went into completed. I have to go in, select the choice and then save. Whereas, I'll give you an example of this where we built this little tool called Combonify, which is just a little moniker for it, where you can take the backend data and we do this a lot for other applications. What you can do is give some sort of interface to the object itself, right? Instead of having to go in there with the Excel view, I can go in there and actually modify things with a more intuitive thing, which would be something like drag and drop. So let me build this little tab really quick. This is a tool that we built just to manipulate this object. And so what this does, it takes the backend piece that we just built and adds an interface to it. So here you can see the object that I was seeing before, which is the task, but now I can manipulate it using like a modern technique of drag and drop versus edit, click through things, hit save, go back to the list, select the next one. So this is a typical piece of work that we do, which is add a good flow to it and also add good behavior, right? Add ease of use. And so in the back, in the back, and let's see if I can add some changes to this while we're looking at it. You know, to do that same action, I would have to go in here and say, you know, let's say it's new and here if I refresh, it'll be new again. And let's say I go to in progress, it changed the backend object. So this is all done through their APIs. In this particular case, we're using custom pages, which for whatever reason I don't have here. And so custom pages is a way to inject any kind of HTML or web application into relativity. So all that you're seeing here is custom code that we've written and injected it into their application. So it looks like it belongs there, right? It's in one of their tabs and it hasn't really interfered with any other functionality itself contained. But through their APIs, it's manipulating actual objects that we created manually. So that's one of probably the most common request that we get is something that has a very fluid API or a very fluid UI. And so we can manipulate these dynamic objects, these RDOs using, be it REST or be it, well, they're modernizing everything to what they call a Kepler API and it's all REST driven. One of the questions that's been popping out is on pigeonhole is if there are countries where it discovery and document review is still not accepted on what, and they are asking other use cases besides the discovery and document review. Yeah, so I mean, so relativity is very focused on review itself. So at this point, it might not be worth the investment to use it for something else, but the idea for them is to definitely use relativity for all things, right? And in several cases, what we've done is we've created project management applications that pertain to case management, right? So when is our deposition? When is our court date? When do we have to file these documents? So there are applications that are built on relativity that really have nothing to do with reviewing ESI. So you could use relativity for just about anything, right? If you wanted to make a catalog or your MP3s, you could, it's just not gonna be very cost-effective. So it's not an inexpensive tool and they're working on reducing costs and seeing how licensing happens, but certainly not the expert in that regard. But if there are specific pricing questions and things like that, I can maybe connect with some of the relativity folks and see if they can help answer that. I'm just a quick idea. One of the problems in law, nearly public law is the deadlines. We cannot fail deadlines. So I would say you could send a whole bunch of alerts and so on. So when one misses the deadlines, it's kind of the critical thing, I would say, something like that, right? So we had built something like that for a law firm in New York, where they really just needed to see the whole thing in timeline, they call it like a case management or I forgot what they called it. But it was basically driven on a case type. So it was, if there was a real estate case, they would have like a different logo and different like task types. If it was, you know, like a government type case, then they would do the same thing, right? They know, they basically templatized it and they know certain things needed to happen for this type of case. And reminders and even subscriptions to things like, I know this document is very important, so notify me when it changes. And so people could subscribe to things and get notified. So yeah, there are tons of project management tools out there, but keeping things within relativity helps because anything associated to the case is in relativity already. So instead of jumping outside of the application and saying, hey, here's a link to the document. And then you click that link and it asks you to log in and then now you have two applications going. It just makes it a little harder to collaborate. And since you're already paying the license for relativity, that's where they see, they get a lot more return on investment for relativity. So a lot of people are opting to keep basically the entire case within relativity. And so the question, if governments are still not accepting like ESI, it might still be beneficial from a, you know, if there is an ESI in there somehow or they're just not using any ESI at all, is that? Or there's not enough information in that question. Because the idea was maybe you can't submit it still, but you can still analyze it and kind of get to a smoking gun that could help you maybe reach a settlement or something that gives you knowledge in your case. Like when we have to prepare the case court, so it's kind of a help tool that can file in the normal procedure, I would say that. Instead of trying to find tons and tons of documents, trying to find something in the middle of a bunch of... Yeah, life easier and it lets things go faster. And that's another thing that some of these tools are doing is they make the investment and so now the law firm is more efficient. They could come in and probably with the lower bid than before because there's less hours, there's less billable hours, so the technologies is helping out. Or, but they're also winning in is inaccuracy. There's no, there's less mistakes. For example, if we build something that, you know, if somebody marks this, let's say responsive, but then the issue is the opposite, right? That there's some data consistency tools that we can do and we can build that allow for accuracy, you know, for mistakes to be made. So there's a lot of things to actually make the manual process easy and more accurate, not necessarily like replace somebody. They're just tools that help them be more efficient. So then law firms are able to either win clients a little easier or have more success in their cases. Cool. All right, what else can I show you? I have a plan here. So I just showed you Kanbanafi. I kind of wanted to show you this piece, which is more visualization that we used in a pipeline case. And it was visualizing data that is already stored in relativity and in particular case, they were building an oil pipeline. They were kind of determining, you know, all the land they had to acquire. And so they had surveyors and all this. And so, you know, there's just tons and tons of data that it really had nothing to do with review, but they put it all in relativity. And so what we did is we built an interface around it that, you know, visualized the map using Google Maps. And using Google Maps, we were able to like color code things, right? Like this is land we've acquired. This is land that, you know, we still have to acquire and maybe read for, you know, we have to take these guys to court because they're not willing to sell. So, and from that, we were able to build something that good since all the contacts and all the landowner information was in there, we were able to build something that would package like all the paperwork for them to, you know, I guess, I don't know if it was a suit. I mean, we nicknamed click to suit, but they didn't like that. It's like having the big picture because sometimes you have so many things to do and having kind of the big picture of the whole case. This case was real estate. Yeah. Yeah. It was a pipeline that involved real estate. And they really need to get the whole land. Otherwise, I cannot use land to get the pipelines, I guess. Right. And so here's a quick example, right? I just put some coordinates on a document object and I'll show it to you in a bit. This is Google Maps integrated within relativity and using data that is stored and I did a little MIT mapping here. If you could share, if you have any example. So, see, it would be great. What do you mean, like some coordinate or? Just if you had the map, it would be great. Otherwise, I think people can get the idea. Yeah. Yeah. It's color mapping and it goes, yeah. So let me switch over. Great. Thank you. So here we're back at the documents and so what we've done is we've added GPS information to the document itself, right? So these are fields that, in this particular, that we only added it to a couple of documents. So the interface that we wrote was using Google Maps API and using the metadata and excuse the development purposes only this key is expired. But it's using Google Maps and these are points that relate to documents within relativity. And so, here's MIT's coordinates and we've tied this to a document. Could you use OpenStreetMaps because I'm one of the things of Google Maps versus it's paid until such a number of calls. So probably I'm just wondering if someone could use an open source. Yeah. Great. As long as they have some sort of API, then we can use it and I think that definitely does. And GIS data. So if it's formatting that way, we can put it in any map I guess. Correct. And so once I clicked on this, it opened up the actual relativity document which I answered it as kind of like the shield here. And here's the GPS data that is basically field data or metadata within the document. So in the particular case where let's say it's real estate or anything to do with locations and you have the longitude and latitude, it obviously is a lot easier for me instead of reading this and trying to identify where that is. It's obvious that working through a map and something that makes life a lot easier is worth building. And in this particular case, being able to see the whole pipeline in a map and seeing what sections we still needed was a huge win. The investment wasn't very big and the time savings was huge. So this is just another example of adding like a good user experience to data that normally is hard to work with. And that sits within relativity already. Cool. Yeah, another user I'm seeing because when you use maps, city councils need a lot to have the whole mapping of the city when they want to implement some kind of policy. And one of the troubles actually is to know who lives there, who owns what, who has the permit. So I always think like the map and we have layers of permit, documentations and so on. So maybe I'm just looking to that as well. Yes, makes sense for cities because some have everything in paper, others don't. But as soon as we get those and most are moving to also GIS and CAD files, makes sense to have the permit and see on the map and see, this is what we have to do. So I'm just looking to kind of, just not just private sector, but also kind of the public sector because the other one's doing urban planning, for instance, so it would make sense, I would say. Yeah, I mean, it's interesting that once you start really thinking about it, it includes everything, right? It includes government, one of them, real estate, their home offices, even if you're looking at a case of, any kind of case within, where this accident happened and then they can kind of trace it where, I mean, we've seen all kinds of things, we're just visualizing things, whether it's in a map or through, is super beneficial for somebody to get their head around it. I'm naming it for policy makers because sometimes we have to know when we're trying to do something new and the question is, how many steps and how many people and how many permits? Yeah, yeah, great, great. All right, what else can I show you? That's fun, we built, we also have a, when I was sticking to the Google theme, we've created a, like a map to actually view, or I'm sorry, a calendar. So we used Google Calendar to visualize dates and this goes back to your case management, when is this gonna happen? And so it's easy to see in a list, but it's a lot easier to work through in a map or in a calendar. So let me show you what that looks like for us. And so this is the exact same, like object that we can create just using the RDOs and adding some field data to it. You're just visualizing it in relativity itself. So if I were to, this is using this RDO, this is called calendar entry. So it's a pretty boring, looking piece of data there, but once you actually start working with it, it's very functional. So I can create something here that's my tea party. And the date's already set because I selected a piece of date there. And so this created an entry and that entry sits in the back end and the back end is the RDO. So it's really simple to create data structures. And then when you add an interface to it, it makes it really easy to work with. So this is just another example of, this would be great for case management, right? This would be, all right, when is our deposition? When is our core date? I mean, Benjamin, for instance, that if it's like Google calendars and I use that a lot, for instance, you know that that line is coming so it has an alert two days prior to check that I have everything filed because sometimes where you want to know the deadline but also have some kind of event to trigger, like send an email to know something else or check if the document is there. So I'm not sure. So I'm guessing you can do that as well, right? Yeah, absolutely, absolutely. And the idea that this is pretty simple, right? This is data that's already in there. This is the data that you need. An expansion to this could be to add notifications, right? Send me a couple of days before. And so when I go in this object, maybe I set a trigger that says, all right, two days before, send me an email or send this group an email. So you could extend this to your heart's content, right? The base is, I believe Google Maps or I'm sorry, Google Calendar, but you can modify it extensively, right? You're not locked into just Google Calendar functionality. And so this really was just another way instead of like looking at this flat data, we're able to modify it. And if we relay it back to what pieces of API, in this particular case, we use the custom pages which we injected data in there. But if you did want, for example, for notifications to happen, we would use something like agents, which agent is similar to like a Windows service or a Unix daemon where it runs on an interval and during that interval, you can do whatever you want, right? In this particular case, what we can do is look at all the events that are happening. Are there some that have alerts ready within a certain time period? If there are, then I could send my notification. So there is a lot of coverage in what they cover in the API. And custom pages is what we're looking at right now. We were basing it on RBOs, but we could also use agents to help us out and do things automatically without human interaction. Exactly. Another thing that I've been asking, actually two sets of questions is, if you could use Relativity for Due Diligence. Well, it depends, right? You can do pretty much anything with it. For example, a due diligence that we saw in patents recently is that they were able to import tons of patents from this patent source, and using like relative to these analytics, they were able to really expand the scope of their search to find more relevant patents or more competing patents or similar patents versus just keyword searching and some of like Google patents has or some of these other patent tools. And so there is some due diligence you can do, but I guess it would depend on, it's not set for that. So it would depend on either like your litigation support or your product manager to kind of set things up to help you do that. I'm sorry, did I lose audio? Yeah. Second question is, we have all these tools on one, the question is about security because when we have a lot of integrations like with Google Maps and calendars, and namely in Europe and also so on, because we have to make the information safe, if there's, how do you deal with security is namely when you have integration, so you have a lot of data coming in and coming out of this server. So, and how do you address these things? Because one of the, namely, law firms, just a quick thing, last two weeks ago, a big law firm back in Lisbon was hacked, I'm not even joking, so imagine all the emails from the senior partners now are exposed online, on big cases. Yeah. And this, for lawyers, it's important to note that information is safe, namely when they're using third party applications and so on. Yeah, so, since the data is on the cloud, it's definitely a concern, but in the relativity side, they've gone through tons of certifications to make sure that they comply with all, either US rules or Europe rules, and whatever levels of encryption that they're using, I don't know off the top of my head what ISO certifications they have to comply with this, but I know they have an entire department set for this, and when you utilize the APIs, it's the same thing, right? It doesn't jump security, they audit everything, so whenever you modify something, it has like a paper trail or a whole slew of information that, let me switch over so you can see what audit data looks like, not coming up to the top of it. But basically, they do have all that kind of in mind, otherwise they couldn't be in that market. I don't know if you can see that, I don't know which one I'm sharing, but it's basically, every single piece of action, whether using the API or the actual application themselves, it is logged, right? So, but regarding sending data over to some third party, like in this particular case, we're using Google Maps, I mean, it's just visualizing the data, right? So they're not getting any real personal information there, and the data's encrypted, right? You get application keys that aren't shared with anyone, and it's all being in-flight through HTTPS, right? So there's nothing going over the wire, clear text. Right. So any more questions we should address before moving on? I think we are covering all the questions for now, so yes, we can move on, it's great. Awesome, so I'll show the presentation just to show what our process is probably very similar to what most development shops do, which is just doing a lot of question-asking, right? We have sessions with either the law firm or the project manager or law firm or corporation. They usually have great ideas. Some things are possible to do, most things are, but some things aren't within the realm of performance, right? I mean, if they have like a 100 million document case and they want a huge report to happen within 10 seconds, then it might be tough to sit through all that data. So, you know, we have to set some realistic estimates once we've established the requirements. We then build some prototypes and mock some wireframes, send it back to them, and it just goes to the whole cycle of estimating, you know, time delivery and cost. And then, you know, we've adopted scrum, so then we try to deliver something that we can demo every two weeks. That way, it keeps us, you know, we're able to pivot if we're going in the wrong direction and it doesn't take, you know, six months to deliver something that somebody didn't want. So... Maybe, I know Scrum is very developer things. Some people are not developers, so maybe if you could explain what Scrum is, otherwise people that are not in the field probably don't know. Sure. Scrum comes, the actual word scrum is from that big pile that happens in rugby where everyone's trying to push each other. And so, you know, they call it scrum just because we're all trying to get to the same goal. And so, you know, agile scrum is where you try to deliver pieces of functionality within a sprint, right? In the sprint, I think most often is every two weeks. And so, without having, you know, to have this big requirement and delivering it two months from now and then when they deliver it, yes, it's what we asked for, but now it's not what we wanted. Or, hey, this is not what we asked for. We try to break it down into two-week chunks. And so we have a scrum master that kind of like defines what acceptance criteria is so the client is happy. And then once you deliver every two weeks, they're able to make changes or change their minds a little bit without being so far into the process that it becomes very expensive for them to make changes. And so that, I think that's been adopted throughout like the software development world, just because it allows you to ship, you know, your direction very easily without huge investment. And it allows people to see what they're paying for very often. So it's also, you know, like client satisfaction factor there too. And one of the things when you have so much different ways of working is sometimes clients won't know what he wants. It happens a lot. And sometimes they want something but it's not feasible or the resources are not there or they want, sometimes you have questions like, I want something like Google and we have to say maybe it's not feasible with the actual resources on time. So how that process goes because it's also some kind of iteration that is important. And most of the times he's setting the expectations right. So just companies, I think you may have that problem. How do we put the expectations in the right place? So don't over-promise and under-do and all the things and how you do with that kind of, I think it's in discovery clients. Yeah, it comes from experience, right? So I think in the beginning we were very novice and we would just say yeah to things and then we'd get in a little bit of trouble. But I think now we've learned that having a good requirements document and then let them see that in like a statement of work with visualizations, right? With some wireframes and things like that. So they know exactly what they're gonna get and they can raise questions before we even actually start working. And so that pertains to price as well, right? So we think it's gonna take 100 hours and it ends up taking 150 hours because they made so many changes. We could always refer back to the requirements doc and say, hey, this wasn't there but usually that's prior to, right? If there's changes along the way we try to get approvals that says, hey, this changes the original plan, do you approve this extra amount of work? And usually if it's not too costly they'll just say, yeah, it's part of their budget. But it's an interesting industry because you can get somebody who's very savvy in relativity and in software. So they're usually very, very accurate in what they want. Or you can get someone who's just, you know like a partner, love an attorney who doesn't really care for the stuff. He just has great ideas. He doesn't care how it's gonna happen. And those are the challenges that we kind of have to hand hold a little more and explain things and set some expectations, right? Because to them or to people who don't understand the process, everything's easy, right? Just like put a button there that does this. All right, yeah, I could put a button but all the work that goes behind it is a lot of work. One more feature curse, I guess. Yeah, I mean, it's inevitable. I think that there's no industry that is above that or outside of that. And how do you, this is kind of interesting. Most of them don't know what is actually needed. So you somehow have to be able to translate what they need to some kind of process and software. So it's kind of time to get the clues, what may be what they want. So it's kind of, yeah. Well, no, and a lot of times they, what they want is already in the product itself and the core relativity project. And so sometimes we sell ourselves out of the sale. Sometimes we say like, look, this already does it. Why would you pay us to rewrite existing functionality? And it's sometimes it's educational for them that they didn't know they can do that. So, but yeah, there's a lot of times where just from experience we have to tell them, well, wouldn't it be better if you did it this way? That way the user wouldn't have to click 10 times here. So yeah, there's a lot of that where we have to, from experience, just say like, we've seen this before and it works better if you do it this way. Yeah, but in the end, the customer is always right. So if they push for their way, for sure. Another thing maybe you also have, there's a lot of companies, they have this need. We are talking about education and so on. So are there some firms, what they do? They can do some kind of learning and teaching and workshops because most law firms, I'm guessing, is they don't go straight to product development. So they need something prior. Some firms have workshops or strike, usually they try to understand how these could help me. So maybe I'm not sure if you're probably doing that as well. Yeah, and that helps from like meeting them and helping them to get the success story behind it. Law firms are very money-conscious and they try to stay for their budgets very, very tightly and they monitor hours the whole bit. So sometimes for them becoming slightly more efficient is a little harder for them to spend the money on it. So what we see a lot of business from law firms mainly is if it's a request from their customer and their customer's willing to pay for it. So that makes things tons easier. But with kind of like the reputation we've built in the industry, they've seen some solutions that aren't really client-based or client-facing and they see the value in the efficiency that they generate. And so those projects are less popular just because of the budgetary constraints and it's not as tangible to see the results, right? If I say, hey, I can save you 10% of your time and then they have to quantify it and they just don't see that as a huge benefit until it happened. So yeah, once we get a good success then they kind of see the value and they start building more. So also it's, yeah, because use case I think are important because usually we see this technology and so on and quite how this would help me out and to have some related case or some law firm or someone that you may know say, hey, I use this. So maybe I do what I say is the referral may be one of the best. Exactly, yeah. And then it happens where they want to see when we show the logos that our customers and then they want to say can I talk to them and see how it was to work with you guys. So the referral process and word of mouth is huge. Yes. Absolutely, absolutely. All right. So I don't know if you think it's a good idea to actually look at code and look at the technologies we use to add functionality. Cool. Yeah, it would be great so they could see how it looks. Yeah, so we'll use two very simple examples, right? So we might get some criticism saying, well, how is that useful? Well, use your imagination of how you can expand it. So I wanted to give two examples. And one of them is kind of the trend that we're seeing is with a lot of these AI services that are provided by Google, Amazon, Microsoft, how to consume those and make them useful within relativity. And so what we've done here, and pretty shortly you'll meet Marlon who'll walk through the solution. But basically he wrote this quick application to just do some translation. And the translation engine is the Microsoft cognitive services engine. And this is useful for not necessarily that we need to translate documents and there's a whole service for that. But maybe you know your cases in English but for one reason, this document that you're looking at, there's a section of it that is not in English. And so we've added the functionality where you translate opens up a little window, the little window will talk to Microsoft. Microsoft has already identified that what I've selected is English since the little combo box was selected. And then I can change this to whatever. So this was a little integration that we put together that I think is actually very useful. And as we were just talking about it before the session that maybe we can like sell it. It's simple. There's a lot of translation engines out there that you can basically say, all right, I've identified 500 of my documents to be in Thai. Can you translate those in English because my reviewers are in the United States or in the UK? And so there is demand for this. But the little widget like this is very simple. So it's a call, it's a REST call to Microsoft services and then they return what, JSON? Yeah, JSON and then we populate this thing. So this is kind of like a quick little app that to talk about what technologies we've used here. Also we've got, I'm thinking about some companies when we have clients across the globe is one of the issues. They have a lot of complaints and so on. So probably they could fit in in the language they used and NPL on top of that you're using Microsoft, right? And then someone can write back to them in the language they receive because when you have so many companies, we work a lot with different jurisdictions here in the US I would say that Spanish is the second one, I would guess. And people also want to have the reply in the same language, you do both, right? You get documents translate and also when you have to get back to the original sender, I'm just sorry, you can go again. I mean the world is smaller now and translation is key. And with this, you know, with that little engine it's fairly accurate, right? I think Microsoft says it's like 70 some percent accurate. I'm sure it doesn't understand certain lingoes and it doesn't translate 100% to a certain dialect. But for the purposes of understanding the content of a document, it works perfectly. And if you need further translation then there are services that have actual people that are native to that language that can kind of help you out there so you have 100% translation. But usually this is enough, right? I mean, I've done, what did we do? We did Spanish since we're in Bogota right now. And it was pretty accurate. Also, you know, because sometimes we are in law, language is one of the major things. So it's kind of sometimes in translation that if you don't have in the right language you're not able to understand and sometimes I'm going back to cities again. I remember that even apps or simple bots, one of the major burdens at the time was the language because most of the population in this specific city was Spanish and so just having for instance the things in English would not have the feedback that the city was kind of getting. So I'm just saying, and here in the US I think it would be a major thing. Namely, if people are not able to understand what is written in law sources it's a problem when they sign up contracts and so on. Absolutely, I agree. So with showing you how the app actually works, right? Very simple app. Technology that we used here was a page interaction event handler that basically said for all documents allow me to inject my own code. And so with that we were able to, when you click on this little context menu it opens up like this injected HTML that we have in here. And so that's another thing an event handler can do. And so to actually explain the code because I don't really have, we can probably spend three hours in here and I'll confuse you more than anything. I'll put Marlin over here and Marlin is actually our first employee and our lead developer. And so we'll introduce Marlin and then he's gonna share the field project that was used to create that. So Marlin, hi all, how are you? Hi, how are you? Welcome. Oh, thank you. One second, let's turn this one. Application window. Okay, so. So have code. Great. So I wanna say, there is people application. I'm going to show you the key points here. Basically, as Juan said, this is a patient interaction event handler, which allows you to inject your own code into your activity. And basically this is just JavaScript. And this is how you can see here is just a pull-up here. So you're using GS, right? So this is kind of the base code, it's GS. It's just JavaScript and on the back end is C-sharp. So as you can see here, we can inject or custom page, our custom page is basically a web application isolated, but in relativity. With isolated, I mean that it shares some information, but not all, I mean it is, or it's own application. So I think in relativity terms, or specifically in IIS terms, it runs in its own application pool. So it has no threat of crashing relativity itself. Yeah, that's right, that gives the advantage that if something goes wrong with the application, will not affect the integrity of relativity itself. So as you can see here, basically we have, yeah, the page interaction, we have here the HTML, which is basically the small window where you can select the language. And after that, we have an Angular controller here, where we do all the calls to the... Yeah, okay. This is Angular AIS, and for example here, we have the calls to get the available languages, to fill the drop downs with the languages, where you select which language you want to translate. Maybe it's, I think it's helpful because some of the people are not used to see raw code, because understanding this, because I'm seeing here the function to get something to choose the language. Maybe if you could kind of, one of them, you could explain the simple functions, what he's doing so everyone can not be so scared of code. Okay, I think I'm waking scared, for example, the, trying to share the postman window, I think it's... Yeah. Here? Okay. And then yeah, you should stop sharing. And then you share this other app. Okay. Transparenification, postman, and postman. Yeah, so if you guys, some of you might be familiar with postman, hopefully it's like a tool to utilize REST services. Yeah, so this is basically what I'm doing is just do REST calls to the Microsoft services to get the, for example, the languages. So it is just a get with authentication header with a weird token. So it's going to return me the older languages, available languages. I did the same for all the calls, right? If I have the text, I just do a post to the Microsoft service with the text to translate and it will return me a JSON with the level of accuracy and the result. I mean, it is very straightforward because all these services provided by Microsoft are just REST. So in this case, we are using C-sharp in the backend, but you can use... And you have XML, right? Because I'm looking to that. So the output is going to be XML file, right? I'm just wondering, sometimes it depends on what people are working, but once JSON, XML, it's very government driven, I guess. Someone may want, I don't know, CSVs or something like that, if they're doing analytics. I'm just wondering if, for instance, because it depends on how we get the data, if they get the XML, they have to know how to read. Yeah, I think in this particular case, the output is XML, but with other services, it typically is like, with other, I think Google is like JSON. Yeah, it depends on, yeah. Yeah, sometimes it is plain text. Yeah, it depends on the service provider, yeah. And it depends on the data structure that you're looking for as well, right? If it needs to be nested, right, multiple levels, then maybe JSON's easier, or it needs to be quick and you're going to handle it at the client level, maybe JSON's better, but if you're going to handle it in backend and it doesn't matter, you can handle it at XML with no problem. Because one of the things, and also just a quick thing, is most people, I'm not sure if they understand what GET may is in return. So in this case, we're trying to get a parameter. So this is kind of, I'm trying to see the value we're trying to get. Yeah, so this GET verb, you know, and if you see up there, it says, you know, get languages for translates. So I have this here. It's returning a list. This is kind of, because it sounds simple, but looking at this with no kind of reference, maybe hard. Yes, because for, you know, so it's kind of, so everybody kind of understands and I'll be frightened. Yeah. So this is kind of, we are getting the list, like if I do, yeah, we get less and then on here and we have the list and of the, these strings are all the language we have, right? Right. That's right. Thank you. Okay, so I may be going back to the code again. So basically, this is, for example, this class is just all the same calls I'm doing in Postman, but using CCHARP. The advantage of this, I mean, as the backend base of relativity is CCHARP or .NET, we are using here this, but you can use JavaScript and I mean, you can be all the application only use using JavaScript. So you don't need to use nothing on backend. So you can do application very light without any restriction. Because right now, JavaScript is like a very powerful tool. So that's the advantage of use this kind of services that provide a RESTful API. So it's very used to consume and use. What else I can show you here? Well, I think that's pretty much the application is. For example, here we have the method to translate. It is very straightforward. We can just send the front, which is the language code. The tool, which is the language code as well and the text portion we select in the front end. And it basically will return me JSON, which I deserialize and show the result in the window. One way, maybe, people can understand better because this string from string two, if they think a tabular form maybe could be easy and I'm getting this in the one column to this, right? And using something, right? This is kind of, if people are wondering if people can kind of visualize what is happening in this one line when you have translate and you're not getting the string from. So the original text, I imagine, right? But adding the language, you just show that you have shown some language. And then we have the output string text is what they are going to get. So they can imagine, I don't know, three columns I'm thinking. Sometimes it's easier to kind of visualize all the whole thing instead of reading directly. Yeah, and if we look at the example that we were using in relativity, it's basically, the parameters we're sending is the value in the combo box, the text that was in the big box, and then whatever we get written back from Microsoft, we write to that little bottom box, right? So if we look at this, the top one is an input, that's an input. The big text that we selected is an input that we're sending to Microsoft. The two, because we want Microsoft to translate to this language, is an input. And then Microsoft, as an output, gave us that, that's where they return that and rewrote it into this HTML element. Yeah, because I think it's important also so people can understand how it works internally. Yeah. Nice, so thank you. Yeah, no, perfect. Cool, right? Yeah. Oh, thank you guys. Any questions on that? I guess not, so we can move on to the second example you have. Cool, all right, so thank you. The second example's gonna be exciting. So we have in relativity, let me exit out of here and look at another workspace, which has less documents and more gear towards this example. And so here we have two documents. And what we've exposed here is one of the columns is the artifact ID. Artifact ID is basically its unique identifier or its primary key in the database. And so if we look at, if we were to click on this, we would see it in the URL where we're at. But if we look at this URL, you can see that we're in this 101, 8, 4, 4, 6. And that means that's the workspace so they know what database I'm looking at, right? That's relativity's workspace. And so knowing the document ID and the workspace ID, I can go to Slack and basically query like the latest from that ID. And so- I'm just a quick joke. You noticed the change of logo this morning, I guess. Yeah, that was interesting. Yes, so yeah, they changed today the logo Slack, so for the easy. Probably paid somebody a lot of money to come up with that. Yeah. All right, so this is the piece where I thought maybe you wouldn't find so useful, right? But this is like the beginnings of things, right? We just really wanted to show you the integration of relativity speaking with an industry standard collaboration tool like Slack. And so here we're basically our little command that we installed is called rel for relativity. We didn't wanna spell the whole thing out. And so what we wanna do is tell relativity, hey, relativity, in this workspace, tell me some information about what, all right? We want information about a document and I'm gonna tell you the document ID is this 103-9505. And so once I make that query, it's gonna talk to a custom page that we have in relativity. And, well, we'll go there and just compile. All right, and it's basically gonna query the document itself and tell you different things, right? Like who created the document, when it was created and when it was last updated. So if I switch over to relativity, I can modify this document and when I query it again, all of that should have changed. So let me change. It's like putting a tag on that document and doing a query with all this tag. Show me what has been on this workspace. Right. Just a question because, so you can search in all private channels as well because sometimes we have private channels, we have open channels and so on. So we're searching the whole database of the methods we didn't slack. Yeah, I mean, at this point, it's, it works everywhere, right? At this point, it's wherever you install it. You can use it in private channels. Yeah. Well, the whole point is that you don't have to leave the slack tool. So if I'm chatting with somebody and I say, hey, what's the latest status on that document? If I type in this command, it'll say it was actually modified two minutes ago. And I think this is using like UTC time or something because it's in the future. And also it's linking directly to your database. So it's opening. So I might like click. It's opening connection. And if I type in the document, probably I have a notification on Slack. Maybe if I'm following that element, I guess. Yeah. So that could be another use case, right? We're integrate. If I subscribe, you know, I'm very interested in this document and we build something that says, hey, I want to subscribe to this. So whenever there's a change in Slack, it'll tell me that, hey, document 9.505 changed. So it would be another method of getting a hold of you versus email or any other piece of communication. So obviously, I think the criticism here is like, well, is this really that useful? It could be, right? Right now, querying for a document, you're like, well, I don't memorize artifact IDs of documents and I don't memorize workspace IDs. So this is the first iteration of it. You could always make it a little easier. So if you knew the actual document name and you can choose what information gets pulled back, maybe you just want to know if it was found relevant or not, right? Or if this is a hot document in the case or not. Or maybe there's a comment field on the document and from Slack, you want to write comments onto it without having to switch the application. It could record maybe a small conversation between you and another attorney regarding that document. I mean, there's a way that it's basically useful. Maybe I'm just wondering, you can put, for instance, labels because those IDs are very hard to memorize so people can't count. Yes. I imagine you're also kind of putting labels so when they call the doc because you always get some kind of shortening of the name of the document. Right. And just putting labels who sort around these kind of huge IDs we have here. Right. So yeah, so I mean, you can use your imagination to see how we can expand this application and make it useful. You know, and everyone's using Slack, whether you're using Slack Microsoft Teams or anything like that. You can build integrations to talk from one system to another that make, you know, your day-to-day more efficient or that the data doesn't get lost somewhere, you know, whether it's a conversation or a huge email thread. But this potentially has a future somewhere. So that's another thing we were discussing this morning whether it's like a fun little widget somebody can install and expand on. And so- It's mobile. One of the things where the problems is most of the people are working in mobile displays and Slack has this kind of. Yes. So it helps a lot. We don't have to, most of the things are next stop and most people need information or I don't know, in court or before filing something. Yeah. Sometimes who kind of, and yeah. Another thing is how do you see differently because I'm seeing, I don't know, Milan and Zerzo are using Slack totally. Yeah. But older partners, I'm not seeing so much on Slack. Yeah. The partners don't use lots of technology. But they will. You know, as associates become partners then they're gonna use the technology. There still is a lot of email flows and they're trying to find where in each email someone says something and they have these chain emails and trying to find something. It's like a nightmare. You know, the target might not be the, you know, the partner level attorney for this, right? It might be like the reviewers who are actually working on the case and doing a lot of the heavy lifting to find the actual documents and tagging the documents. And then, you know, when they're done with that then the partner level attorney gets the documents. But during like the collaboration he probably doesn't need to be involved. Yeah. All right. Yeah. Just imagine because I say currently the new generation is in this because it's mobile, it's easy, it's fast. Yes. I don't have, but some of them are actually adopting, it's quite interesting, but they still use a lot of emails and they attach everything in every email. They have a changes in the new documents. So we have kind of, sometimes you have 20 documents for the same document with 20 versions. So it's kind of nonsense. Yes. That's changing. I think in a couple of years, messaging is going to be more dominant than actual emails, right? I think people are starting to email whatever let's say bad things that they do in a text. And so text has become a very targeted piece of evidence. Yeah. So it's kind of like a joke in the industry that people do bad things in text and not so much an email anymore. So to kind of give you a walkthrough through the application, I want to introduce Carlos, which is our architect here in Syrio. And Carlos will kind of walk through it. It's something they put together what between yesterday, yesterday afternoon this morning. So it should be a pretty smooth ride walking through the app since the code is very simple. So Carlos. Yep. Yeah. And... Hey everyone. Hi. Welcome. I was almost saying yeah this was like a pretty simple idea we had. So... That's cool. She's not like some fancy code that's something pretty straightforward idea that was showing the ability to connect like different tools, external relativity with relativity and how is it that can be, okay? So let me go pretty quick to the code. You're going to be, you're going to notice something pretty cool that it's just 74 lines for everything. So let me share this thing. There you go. As you're able to see right now, here's basically a full code that we have here. So what we have here is just an endpoint that we put in an MBC controller that's going to do the querying of whatever we're going to see in the database at relativity. So this is the format that Slack requires us to have. So for example, just what's the name of the user is talking with and what's the text they wrote in the message. When we get this information, we're doing just a pretty basic set of validations like well, the text you're writing has sense, the user that's connected well can look at this thing for a simple thing. And the important part of this code is this place. So this is where we can start seeing how we are integrating with relativity itself. So as you're able to see here, we are getting this fancy thing that's called the object manager. Object manager is one of the APIs relativity provides you this API specifically for consuming, reading, updating, the link, all the crude process for objects in relativity. This is including the relatively dynamic objects, the one that's on top of privilege. And so people just can kind of refrain. So you are using these text identifiers and matching with that parameter in your database, right? Not exactly. What we are using here is we take the text. So we are processing that text and we are getting the workspace ID, the object ID and the object type you want to get, right? So what we are doing here is creating this condition that it's based on the artifact ID, using the type, getting it from the workspace, the information. What you're seeing here in the fields is what we are getting back. So that's what we get back from the database and what you're seeing in message. Let me get back here real quick. So as you're able to see, you see this message that says the type of the thing you're querying, the identifier and text of the thing you're querying, who created, when created and when that was updated and who was the updater. So if you go in that code, it's pretty simple because as you're able to see here, we are taking this information from the database and what we are giving to Slack is just that message form of that way. So what's the object, what's the identifier, what's the name and the email of the person that created it, the date and same thing for the person that did the last update. So as you're able to see, pretty simple code, something pretty simple to read and the result is a full integration with a totally external tool. So for doing that is not just like writing this code so you can come here. Slack has this apps concept that you can add integrations. They have very different ways to integrate. So they have incoming webhooks, interactive components, slash comments, bot users. So as you see, every feature has their advantage. So if you think about a notification concept like the subscription you were talking before, incoming webhooks will be the greatest way because you're often just an endpoint that whatever application can communicate just using REST calls, right? In this case, it is... One thing that maybe we should address I'm just because some people maybe never use an API. It's also important for instance for law firms and that we can give access and permits. So when they create a Slack account, we can define precisely Slack has this, I believe, who gets access to what. So they can also know they can keep the information within Slack safe. Not every employee can get an access to the API and whatever is happening in the Slack channels of this company for instance, right? Yeah, that's the reason when we built this we decided to use an slash comment to the example because a slash comment since in Slack has this beauty ability that can be for everyone but in a big change you can go and do it and do it in a direct message with yourself. So I'm here with account upon so I can talk with myself and use exactly the same comment I put in here. So let me just couple this pretty quick. I mean a DM message and when I did this I'm going to get the same result but this is going to be a private message because it's going to be just for myself. And when you go like more deeper in these implementations and all the things you can come in here and change what's the response type. So in here we're using channel which is basically where you are setting the request you're getting the response but you can have the ability to save the in private which is going to be when I ask, whatever I ask I'm going to get the answer as a DM from myself. And if you get like get more power this gives you the ability to use the bot users. This has like a full events framework pretty cool that you can start doing regular responses frequently asked questions. If you want to have some reporting this kind of thing you can start thinking more far away from what you get here just a message and put the power but basically using the integrations as lacks across you and the power relatively can put in the process you're going up. So that was basically the concept of the application. I don't know if there's any question around or. No, just maybe do you have any cool examples with bots because I know a few and like trying to bundle people or some kind of cool reminders. Sometimes because you have bots sometimes they're kind of more friendly so people can get along when namely when you have big kind of a lot of people in the same channel. Yes, that's a cool thing because in the case of the slack thing they have a really good documentation on how to write the bots. So at the end of the day if you look the bots they're just like the centralized point to do many tests so it's how you integrate it. So you have this event description so this is an architecture oriented to events that's basically how I can say when it's happening something on slack. So when you're writing a message if you want to do something very specific so you can mention hey, but can you let me know at the end of the day today whatever I want to know about something that's going to raise an event. So you can have an external service in this case it can be a relativity. You can have as the source so you're in a review process so let's think in an option. You're managing a reviewer team so you can say hey I want to know when the day ends at 8 p.m. I want to know how many documents were reviewed and how many are remaining on the chunk of review we are having right now. So you can do that and at the end of the day the automation can be just the bot will receive this message from relativity saying hey this is the total and the bot is going to be the one that's showing you that information and you can say if that can be public or private. So as you're going to see there's like the tools around it's how the imagination can be used to put that together in product way. It's an example prior. So imagine we have two people working in the same document and it has a certain deadline. So in theory I could put kind of a bot two days prior to that line to join these two people working on the same document say hey both of you have a document to submit right. Something like that. Yeah it's something pretty cool. Just like notify me when someone gets in a document I am now. So. Yeah great. We can convert it like in components and code and we can see like the solution of it can be pretty simple. But the goal is knowing the components to do it in a great way. Yeah. Like the biggest portion of it. So you might. Right. I would say like that was the part really to integrate with the system. All right thank you Carlos. And those were our demos right. I don't know if people had like code specific questions or technology or API or you know whatever since we're kind of at I know we have tons of time so this is where we would love questions. So I'm looking to the questions maybe so sometimes it's good to go back to basics explaining what is API or REST interface maybe it could be a good thing because they just look how it looks. This is why I'm trying to see the to some people I'm scared but explain what is API what is REST and how this relates to things. So that is not scary words. Sure. So API is pretty common within like the development industry and it's basically like the application programming interface and it's something that as your application you expose to people who want to develop with your application instead of exposing them directly to like you know your database directly. So it's something that you can control that way you set standards, you set security and you basically put a wrapper around your application that developers can consume with their old programs. So it could be you know an API is pretty generic it's not specific to any technology it's anything really. And REST, REST is basically a stateless technology of communicating using verbs using you know something like post to send something to a system using get to get information using delete to delete whatever you know you're manipulating. And so it just uses standard verbs that are technology agnostic. So you don't have to use a Python you don't have to use Microsoft.net. So it's kind of like a neutral ground for all applications to use and it's a common standard in basically like web technologies. Yeah. Just on last maybe you have some two stories to share is kind of with clients and how it goes on that project that kind of Yeah, I think it's fun stories and we learn a lot so it's kind of fun. Stories we have those are fun to tell like scary stories. Usually no names are needed so just to get a picture so people kind of have the kind of fun side not fun or not so fun the funds. We had probably one of the high pressure and high budget projects that we had was and I didn't even know that this existed but basically a company said look we want an application to help us sort out through jury right and we're doing jury selection. And so there's people out there that specialize in jury selection and they charge a lot of money. And so they wanted us to build something that can catalog jurors really quickly and allow this high end like jury selector specialist to put all that data in there and to be able to sort them out quickly and like budget was no object because this guy was like getting to work in the evening and he was charging like in the thousands in the hour. So for us to build something that could save somebody three hours was worth $6,000 to them already because this guy was very high end and as one of those situations where they called us last minute and they wanted it done immediately and we turned it around to it was a fun little project. So that was like a high pressure one and we've had tons of little snappos here and there. I don't know which ones, none of them are really comical all of them end up with some sort of repercussion where whether we just work really later over the weekend to try and get it fixed. And hopefully at the end of it we have a client that's happy. But yeah, we've, I mean, in this industry we signed so many NDAs it's hard to talk about some of these things but you see in the news a case that we're working on and it's kind of cool to see what's happening in the news and that we had even on my new impact in that. So those things are pretty neat. So one of the things is kind of when I have this kind of clients they kind of don't, they have these higher budgets I think you have more freedom to run. So it's kind of fun. Yeah, I mean, for sure. We still don't like running too much with it unless it makes sense. And we like to have some ability because it all depends on the time, right? Like during that time it might be, hey, you run with it and then after math when they read this, you know, they won a case or they didn't want a case then if we went too crazy with it then they say like, why did this happen? So green light usually just means like get it done fast and we try to give an estimate anyway, right? I'm going to re-finance. Going back is, you just have been working in the US market. So it's, and any specific transition or you have been working the most? No, I mean, US is probably 90%. We have Ireland and we also have UK. So we do have a couple of clients in Australia. I believe some in China, some in Cayman Islands but the majority of them are in the United States, yes. And you see this difference between states in law? So it's kind of, do you have to change a lot the process because it's for a court decision in New York? The other one is, I don't know, California and so it's, do you have this with? I think the thing that we are always super careful about is the transfer of data from one country to another just because of the data privacy laws. So we're very good and we usually never need to touch anyone's data. So if it's a case that, you know, we're building an application for a certain case, we only see sample data. We never actually see like a Bernie Madoff email, right? Like we'll never see something like that. So we're careful never to bring it down because a lot of our developers are in South America. So we're actually talking from Bogota and so to bring that data either from the UK or from the United States, we trust the borders. And if it's, you know, personally identifiable information then we'd be in trouble. And, you know, we aren't attorneys ourselves so we have no business in analyzing the data. So that's where we're careful. So who is storing the data in this case? It's the clients. Yes, correct. It's just access because, yeah, because in Europe we also have this discussion of where the data is stored and who has access namely because if you're dealing with names, court decision is the one. So it's like you're just giving the process to run on that data or that servers because some of them, so it's kind of sure everything is integrated with that servers, whatever they are. Yes, so in the example of these two examples, the Slack or the translate, we would give them like an installation package that they would install in their environment and then they use their own data with it, right? So we don't actually see any of the information they're passing or using or even with maps. We don't know what it looks like. We know they have, we agree on data types, so we know we need longitude and latitude and they need to be integers, but then the actual data itself, we don't know about it. So yeah, that's kind of, we're definitely very separated from that. Because it's also less reliability because if you have to send all the data or storing in one of US servers. Yes. And in Europe, for instance with GDPR is quite important because you have to make sure that it's all set up, it's important. So do you also kind of make aware of the clients? I'm not sure how many law firms have IT departments or someone dealing with the whole information or data. Yeah. So the question is, if you also some kind of do some kind of counseling on that area? Oh no, on the IT side, it's usually their own internal guys and I would say 100% of the law firms that we deal with have like an internal admins there. Okay, so I think we are, I don't have any more questions. I think if you want to kind of have final remarks to be great, any cool ideas, I think we already have some cool ideas what also could be done, it's quite important. Yes. Yeah, so thank you guys for the opportunity. We covered, I think at a light level, a lot of topics and probably for those who are, they're not developers or not familiar with relativity might be, that was probably a right level for those of you who are familiar with development and familiar with relativity, we might have not gone deep enough, but feel free to reach out. I think your information is on the actual agenda. So if there are any questions you didn't get answered or you want it to be more like a one-on-one thing, feel free to reach out. But yeah, the idea of this was to really kind of like show what kind of thing you can do within relativity, which is what we focus on. We don't do, there's plenty of competition for relativity, but this is a technology that we focused on. This is not necessarily focused on .NET. So if you enjoy programming and other languages, relative kind of has expanded, and that's kind of what rest is for. Yeah, I guess the point is hopefully you got something that official out of this. And if there's something we didn't cover, feel free to reach out directly and we'll try to answer your questions. Oh, so maybe it could be great if you could send us the presentation so we could share. Because that graph was really cool to have in the beginning with the whole discovery. So yeah, it's much easier if that just could share with everyone. So thanks a lot for the... Yeah, we'll definitely put that out there. So I don't have any more questions and thank you a lot for the time and on showing all the things that you've been working and also congratulations. It's a lot of fun also to work with this area. Yeah, it's fun. High pressure, but fun. Thank you. All right, well, thanks everyone. Bye. Bye bye.