 My section is not super long, but we'll talk a little bit about integration options with verify and do a little overview of the verify architecture. This is a long time coming. We've been working on this product for probably close to about two and a half years since we first started discussing it. So it's good to see it come to fruition here. This is the overview of our architecture. You'll notice on the left and the bottom, that's what we've created. We have a dashboard, which most of you who are customers have been to probably. That's where you see your test results and other things. We have extended that dashboard to include all the verify steps such as creating links and taking tests and seeing results. We created a iOS and Android app and both those talk to our backs back services via an API that we've created. We have made available to you as authorized customers or organization service providers the ability to to access that API. And basically duplicate exactly what we've done in any fashion that you need to. So you'll notice like Todd talked about the question server. That's one element. The other server there in the customer development square is a third party system integration. That would be your systems talking to our systems without having manual intervention. You could create your own dashboard. And then later on, we haven't created this yet, but our goal is to get a set of SDKs so that people can build their own white labeled version of our app. And we will show you exactly what you need to do to capture the frames and send them up to us to score. That is a future enhancement, though. That's not ready today, obviously. So this is the overview of the different types of integrations and how difficult they are. See a little slider in the bottom on the X axis is difficulty from left to right. Todd talked about the different steps for taking a test, creating a task, getting results. I've listed those from top to bottom. And they are in order. You have to write a test. You have to create a test link. Get to set the link, send a link to the examinee. He has to take the test on a phone. He contacts us to start the test. He goes to a question server to get the test itself. Once he's done, the telemetry sent up to us. And finally, you view the results. On the left is what we're calling a 100% manual approach. And that's available just right out of the box. If you have the verify flag set up on your account, then you'd be able to start today to create test links and send to examinees and see results. It takes no programming. And then in the middle there, as you're starting to get into the red, that's what we're calling our fully integrated approach. So you're going to use the API to create test links. You're going to use your own programming to send out those links, whether it's by email or text. And that would require no manual intervention if you're completely programmed to the API. You'll notice on the manual side on the left, there is also a couple of things that are still in the green. They don't take a lot of programming or server infrastructure to implement. And Todd talked about these a little bit. So data sites using the dashboard and batch uploading using the dashboard. And so I'm going to talk quickly about those two options for creating test links to be able to send out to examinees. So for data sites, if you had to test, let's say that you wanted to add in specific information. Like identity test. We would create that for you and putting these data sites and then you would be able to use it in the dashboard today by just filling in the edit boxes that correspond to each variable. And you'll notice this is a shortened demo type of test. Most of the time you'd have many more edit boxes. But everything that has the same variable name, you can copy down with that plus button and Todd will demonstrate that later on. As you mouse over that little file icon, it will highlight where in the pre-test instruction or in the question this variable is going. And so it's really easy to manually, without any programming, create these or put in the data site data, create a test link and then send it to an examinee. The next one that I'll mention is batch uploading on the verify tab down the bottom. There's a batch upload button for you upload a file. If you press that button, it will it will ask you to to upload a CSV file or comma separated value file. Here's an example of what those look like. The file obviously must be in a certain format or won't process. So if this is a path that you'd like to explore and various can send you a CSV file template. It'll look much like the one above. It'll have an examinee ID or sorry, basically a template ID, which is the test that we've created. A bunch of other things like name and email and mobile phone. And the header just needs to stay how it is. And you can you can enter one to end lines. When you notice on this one, there's also in column G and H the data for the data sites. So if this was an identity test, you would have a bunch of these columns dealing with those data sites. Then all you do is you upload it. And as the output for that upload, you'll receive back the same file. But in that last column where it says URL slash error will be the link for the test. If if the link is not there, you'll have some kind of error. Either you forgot to fill in the name or something else or that template ID doesn't exist. And I'll tell you. And so all you have to do is correct the error on that line. Reupload the batch and it will skip all the rows where a link has already been created. So you can do that as many times as you need until you have all the links over on that right hand column, column I. And then it would be up to you to take those links and either text them or email them out to your examinees for them to take the test. So this is one way that you can get close to an API type of integration without having to do any kind of programming or any kind of integration. On the bottom is an example of that same file just in a text editor. Like I said, it's probably easiest to edit in a spreadsheet like I have above like an Excel, but you do have to save it out as a CSV file. You can't save it out as an Excel file because it has to be a text only CSV file. So also along with this, there are a lot of organizations that do this already, but they'll have macros and things that will spit out information either to emails or to different lists. And so you could probably piggyback on that and get these CSV files pushed from whatever system that was with very low programming. Okay, next thing we're going to talk about as you go over to the right more on the difficulty scales, the API. So to fully integrate with Converter's ecosystem, you're going to need to code the API. This will require you to have development resources and that allow you to allocate time for a project. It's not super hard, but you will need developers or access to a shop that can develop before you. It's just a standard RESTful style SSL API where each action is a function call that either creates something and returns an ID or just returns data. So if this is something that your organization would like to do, you'll need to contact us and we can point you to the API documentation. And also if you've had a time to look at it and see if it will work for you, we will provide you with an authentication token. And that's what you'll use in your development and your programming. You'll send that up in the header of your request every time you make a function called the API. Without that, you won't be able to access the API and it will tell us as we decrypt that token who you are and what you have access to. So that's how we keep it segmented. Just as an example, the Verify API allows you to do anything that we do on our dashboard and it lets you add it to your HR management software or to your workflow processes. For example, this is the main Create Test Link page on the Verify tab in the dashboard. The very top dropdown gives you a list of examinees that you have created for Verify. If you wanted to get that list and recreate it on your system, you would just call the API call for list of examinees and it would give you your examinees. The bottom dropdown list is just the list of tests that are assigned to your account. All you need to do is call the API call for list tests, populate your form, and then that submit button. When you hit submit, if you're creating a new examinee, it creates it, gets back a subject ID or an examinee ID, and then echoes that back with the template ID to create a test, and then gets back a link. So on this page, like I said, there's nothing here that we're doing that you can't do. We're just using four API function calls to flush out this page, which you'd be able to do in your system. And finally, the question server. Todd alluded this in a little bit as his initial slides. We're calling this a question server because we can't think of a better name. In essence, the question server allows companies and organizations to keep who they are testing and what they're testing about private. So that's a requirement in your organization. We can talk about how you can create this. Basically, you'll see our server over on the left. We have a master set of basically encryption keys. We have the one that corresponds to the app. And then we give you one so that when the app talks to you, you can decrypt the incoming token and crack it open and see exactly what you need to do. So if we're to do this in a step by step process. And again, you're going to need development resources to be able to create this question server. You're going to need server infrastructure. Because you will have to provide for the app a series of endpoints. So the app can talk to you and talk to us at the same time. So starting step one, you want to do a new test. You need to register the test template with us. You don't send us the questions. That's the whole idea about this. You just say, I want to create this type of test. And then you need to send us a list. Obviously, this is done all programmatically. You need to send us a list of the expected answers for every question. Question ID. So each question will have an ID that's unique. You need to tell us whether the youth, whether the expected answer is true or false so that we can use that as part of our scoring. And again, the questions only reside on your server over on the right. Then the examinee would click the link and start taking the test. And we would tell it where to go to get the questions, which server and which endpoint to go to. And on this particular case, the endpoint is not us, which it usually is. It's a question server that's been registered with us over on the right. And so in step three, the app would go and get the questions from your server. And the person would start taking the test. Once test is over, it calls your server again and uploads the face images so that we never see those. And then finally, it uploads to us all the data we need to score. So the telemetry on the eyes and the other features that we need, response times and all that. Nowhere in this process do we see the questions that you gave to the examinee. So that is how the question server works in a nutshell. So at that point, you have access to the face pictures and the questions and all we would give back is the score. All right. Thank you for your time. And we look forward to helping you integrate with I detect and that's about it.