What we've learnt building an AI accuracy checker

Learn more about Corrik

Visit corrik.ai to learn more about our new AI visibility and accuracy tracker.

Episode transcript

Amelia: Hi, I'm Amelia.

Paul: I'm Paul.

Amelia: And this is Fin the Week. Welcome back, everybody. How are we doing? Pat, we haven't seen you in a while.

Pat: Yeah, I've been busy, especially the last 24 hours with this global PHP meltdown, which has been quite challenging.

Paul: It's been busy.

Amelia: Yeah, and I'm sure it has been for a lot of people. Why don't you tell us a bit about that? Paul was briefing me a little before the episode, but tell us what's been happening.

Pat: It's been absolutely insane, really. So we're pretty good at dealing with security vulnerabilities as they come out. We do a lot of work with Drupal, Laravel and WordPress, and from time to time one of these platforms will issue a highly critical CVE, which is a report that says there's a vulnerability in this bit of software, we're releasing a patch at this day and time, and you need to apply the patch immediately. Because even if you leave it 30 minutes, there's a high chance your site might get hacked. As soon as the patch is in the wild, the hackers can see it and start developing exploits for it, and suddenly the attacks go absolutely mental.

That's happened a few times, and they rarely hit the news. They're becoming more frequent because AI tools are getting better at finding vulnerabilities. But what happened with PHP? PHP is a programming language that underpins all of these platforms. It underpins WordPress, Laravel, Magento, Joomla, Drupal. All of these are really popular CMSs, and it literally drives 70% of the internet. So most of the internet is built on PHP, and a security researcher who had access to some really powerful OpenAI models with their security guardrails removed — OpenAI do give that access to certain trusted people — pointed these models at PHP and found two really serious vulnerabilities. They were announced yesterday morning. The patch was released at 3pm UK time. And the recommendation from PHP, and also from many security researchers, was to patch straight away. If you can't patch straight away, take your site offline.

Amelia: Really?

Pat: So yeah, it was all hands on deck. We also had two developers on leave, so we had a reduced team and it all went completely wild. But we managed to get all of our sites patched in a reasonable timeframe, so it's under control.

I've never had clients phoning us up and asking us to take their site offline in all the years we've been doing this. And yesterday we had multiple clients phoning us up saying take the site offline, including clients built on a Microsoft stack that don't have a single line of PHP in their websites. The media coverage and the panic...

Amelia: This has got people very nervous.

Pat: ...is an order of magnitude more than we've ever seen. It's pretty crazy.

Amelia: Do you think the panic was warranted?

Pat: There have been issues like this before. There have been a few Drupal vulnerabilities like this over the years, and this is as serious as those but not any more serious, and we've never had recommendations to turn sites off. I think the panic here comes from a kind of latent "AI is going to bring down our world of technology" panic that the media have been building for some time, and that manifested itself in lots of clients getting really, really panicky.

You also have the concern that most of the internet is built on PHP, and if it wasn't patched in good time then genuinely serious long-term damage could be caused to the fabric of the internet. Most government sites are built on Drupal, which is a PHP platform, and they're obviously big targets for hackers for various reasons. So because of that, the alarm was higher, the concern was higher. Loads of government sites took their sites offline, including gov.gg. They managed to get it back on quite quickly — I'm not even sure that site's built on PHP, but they did it as a precaution. So it's been mad, really. And I think we're only going to see more and more of these over time.

Amelia: Is there a way that firms can prepare for situations like this — have procedures and protocols in place?

Pat: Yeah, definitely. It's about keeping up to date with all of your patching regularly. If you've got a site that hasn't been patched for five years and suddenly a vulnerability like this comes out, you've got five years of patching to catch up on before you can apply the main patch, and that increases the scope for things to go majorly wrong. If you've got a site running on PHP that's five years old and you suddenly need to bring it up to date, the site's probably going to break. But if you're patching regularly, and you only patched a couple of weeks ago, then the little security patch to close this particular vulnerability is really minor. It's not going to break anything, and it's easy and quick to do. So stay on top of the patching. We work hard to do that.

But this one is really interesting, because PHP hasn't had a serious vulnerability like this for years and years. It's one of those things that just runs in the background and you get complacent. People think it's secure enough, it's not going to suffer from something like this. So I think there are probably lots and lots of sites out there that have gone five years without being patched, running really old versions of PHP, and quite a lot of the internet probably still isn't patched, honestly.

Amelia: So a bit of a wake-up call.

Pat: Big wake-up call, yeah. We've definitely taken some learnings from this and we'll be folding them back into our processes as well.

Amelia: So that's what you've been up to for the last 24 hours, Pat. But we're going to jump into something you've been working on this week, Paul. What are we talking about today?

Pat: It's been pretty manic, yeah.

Paul: So this is the culmination of a team-wide effort to launch a new product — version one of a new product we've been working on called Corrik. I wanted to talk about it today, but avoid it becoming a pitch for the product, and instead give an honest appraisal of the journey we've gone through to develop it and test it, where it's currently working well and where there are still gaps to be plugged.

Essentially, it's an AI accuracy checker. It can track a brand's visibility in AI tools, but then also review the results that an AI or large language model is pushing back, and check those for accuracy against a source of truth. So we wanted to do a warts-and-all review of the process we've gone through to build this tool and get to the point where we're launching it. When you're listening to this podcast, it'll be the day of the formal launch of version one.

Amelia: So let's get into it. What is it? What does it do?

Paul: Corrik is, like I say, an AI accuracy and visibility tracker. There are lots of AI visibility tracking tools out there, and we didn't want to enter the market just to build another tracker. It was inspired initially by some work with a client who is taking an active interest in AI visibility. During discussions about how we actually understand whether the brand is being mentioned in relevant AI searches, we came up with this concept of an "all else being equal" approach. If you run the same searches using the same method consistently over a long period of time, you won't necessarily see what everyone in the world sees when running those searches, but you will see a consistent benchmark over time of how frequently your brand gets surfaced. So we thought, let's build a tool that can automate that process.

In the process of building that tool, it occurred to us that for the clients we work with, which are regulated financial firms and the like, the accuracy of what a large language model says about them is equally important, if not more so. A good example: if you're selling mortgages or savings products, your rates change frequently, and it's a fairly significant risk if you've got something like ChatGPT quoting out-of-date rates, spurious rates, or pulling rates from other brands and associating them with your brand. So we wanted to build a tool that could give firms a way to monitor this.

In a nutshell, the way it works is that you set it up and load in groups of searches. So you could say, I've got a group for our mortgage product, and in there you put a set of search prompts — things you can ask the various AI models. You could ask basic questions like, what are the current mortgage rates for XYZ company? Then you can see, first of all, does the answer come back with information about your brand, and secondly, is it the correct information?

The other thing you set up with these groups is what we've called a source of truth. You load in a source of truth, which can be a link to a web page or a document, and the system uses that to understand all of the key facts it can then review the results against. So it's using this concept of all else being equal. It's not necessarily going to tell you what every single person who searches the same things will see, but over a long period of time it will give you a good understanding of how frequently your brand is mentioned and how accurate the information being mentioned about you is. But at this point, Pat, it's probably a good idea for you to talk through the bones of how it technically works, because that will give people a better idea of the system.

Pat: Sure. The public website has just gone live. It's corrik.ai, spelled C-O-R-R-I-K. You can go online and sign up, and you get 200 initial credits, which allows you to set up a couple of search phrases and configure them.

Once you've signed up, you create a search group, which is a group of search phrases that will run. It's analogous to a keyword group in SEO terminology. You add in the searches you want to track your performance against, and then you choose whether you want it to run daily, every three days or every week. It will go through every single search phrase you've entered and feed it into a number of different AI models. It feeds it into Claude Sonnet, which is the default model for Claude; Gemini 3.5 Flash, the default model for Gemini; GPT-6 Luna, the default model for ChatGPT; and Perplexity Sonar, the model Perplexity uses. It feeds each search query in, captures the result, saves it down, and looks in each result to determine whether you've been mentioned or not.

If you set up accuracy checking, it will also compare what the model has said to your source of truth and look for discrepancies for every single search phrase. If it finds a discrepancy — for example, ChatGPT is talking about out-of-date mortgage rates — it'll surface that as an alert so you can review it. And it does this periodically.

The billing is on a credit-based system. We took that approach because the cost of using different models varies quite a lot. Claude models are quite a lot more expensive than Gemini models, and Sonar is ridiculously cheap. So each model burns a certain number of credits per search. If you set up a keyword group with 30 keywords and run it across all four models daily, you're going to start burning through quite a few credits. So you can wind that back to every three days or every week, and you can have keyword groups you only check weekly and other, more important groups you check daily. That's the fundamental bones of it.

It's pretty clever and it works pretty well. We've been testing it a lot over the last couple of weeks ahead of go-live. On the accuracy side, if it surfaces any discrepancies or inaccuracies, you can work through the list. You can mark them as false positives or confirm them, and once you've got a list of confirmed discrepancies, you can generate a report which you can send to your board, your agency or your content team. The content team can then look at restructuring the content on their pages to make those particular bits of information clearer, which feeds back into more of an SEO-type exercise. So yeah, we think it'll be useful for our clients.

Amelia: It sounds very interesting, and we're going to come back to these false positives in a bit. But for now, Paul, what did you find in your test runs? What were the common themes?

Paul: We set up a few different tests across savings, mortgages and pensions, and we focused on three prominent UK brands — market leaders or close to it. The tests I was running focused primarily on the accuracy checker aspect of the tool.

The first thing we found is that the tool immediately raised questionable claims made by the large language models. I took about 70 claims to manually review. There were a lot more than that — hundreds in the background — but I took the ones ranked critical or high in terms of how problematic they could be. What we found was that 21 of the claims were genuinely inaccurate. They were legitimately wrong: the large language models had quoted incorrect rates and things like that. And 50 of them came back as false positives for one reason or another. So there's definitely some fine-tuning to do, but I think it's worth diving into the reasons behind those.

Amelia: So where do these false positives come from?

Paul: The majority — 35 of the 50 — came down to the source of truth being incomplete. A significant reason for that is simply that in setting up the tests, I was relying on only what I could relatively easily find from these brands. Taking the brand that offers mortgages, for instance, I found the best information I could — an extensive list of their mortgage rates, when they apply, who they apply to, the rules around them, the fees and so on — and loaded those in as sources of truth. But in doing so I inevitably missed certain elements that the brand itself would have access to, or would know where all of that information lives.

What we found was that getting your source of truth complete and accurate is — it goes without saying — a prerequisite for making this tool useful. If you don't have that in place, the tool will misfire. It will say this rate is wrong, or I can't find evidence of this rate, or the fees associated with it are wrong, when in actual fact, if you dive a bit deeper, you'll find that somewhere on the brand's website there's something that says this piece is correct, or it's not as clear-cut as the tool might suggest.

Some examples: the rate sheet we loaded in gave the rate but didn't detail the 24-month term that the large language model did. There was another where it didn't mention that you can choose monthly or annual interest, so the large language model spoke in terms of monthly interest, but our tool wasn't aware of that from the source of truth. It didn't have the first-time buyer definition or the lending criteria in the source of truth, which meaningfully changed how you could review what the large language model said.

All of this hammered home that a lot of the false positives came from what essentially amounts to a shoddy source of truth, which means that to make a tool like this useful, any brand that wants to use it is going to need a pretty extensive, centralised source of truth about whatever it is they're testing. In the case of mortgage rates, you're going to need a document that can be loaded in that is completely accurate and covers everything — and you still want to manually review each point. So that was something that stood out.

Something else that stood out was more about a firm's website. There was a case where a pension provider's drawdown page said the platform fee included fund management charges, but everywhere else on the site it described the fees as being on top of that. So there was actually a disparity on the website, which is worth knowing. Our tool picked up on it, but for the wrong reason. It was saying the claim was inaccurate, when in actual fact we don't really know whether it was inaccurate, because the website contradicted itself. So again, that comes back to the source of truth, and how the website is just as important for that. It's only as good as the information it's been given.

There were a few examples as well where the tool was leaning on a baseline level of knowledge. It incorrectly quoted the Financial Services Compensation Scheme. It suggested that money is protected up to the value of £85,000, but as of December 2025 that's now £120,000. So it marked a few of the answers as incorrect based on out-of-date baseline knowledge. That's knowledge that wouldn't be in an individual brand's source of truth; it's baseline industry knowledge.

Amelia: Right.

Paul: So I think there are areas there to fix to make sure that the source of truth and the baseline knowledge are accurate. You're always going to get certain false positives slipping through the net with a tool like this, but what you don't want is a compliance team inundated with false positives they have to keep batting away. What we want to do is surface things that are genuinely useful to know — where a rate has been quoted incorrectly and things like that.

Amelia: So that's the false positives. Where did it correctly identify inaccuracies?

Paul: As I mentioned, there were 20-odd cases where it flagged things that are important to know. A fixed-term savings rate quoted below every term the bank actually offers — the large language model said you can get a savings rate of XYZ, and the truth was quite different. That was legitimately wrong, and it was specifically tied to the brand we were looking at: it was saying this brand offers this rate.

An annual platform cost was given as a certain number on a certain size of pot, but it turned out the large language model was taking an annual cost and dividing it by 12 to give a monthly cost. That was wrong because, I think, that platform had different monthly versus annual costs or something like that. So again, it was calculating a result that didn't actually exist.

Fixed mortgage rates were described as "low to mid four percent" when the lowest fixed rate at that loan-to-value was 4.99%. So it was misquoting mortgage rates, and an example like that is useful for a few reasons. First of all, a compliance team would probably want to know about it so they can check whether there's anything online from their own website quoting the wrong rate, which is then feeding into the large language model. And what I found when I did a bit of digging was that a lot of these inaccurate rates were coming from old press releases on the firm's website. It was taking a rate from the brand's website and properly pointing you back to it, but it was from a press release from April last year or something.

That's a very useful thing to know, because brands can do something about it. They can keep the press releases available online but caveat them clearly, so a large language model has a better chance of understanding this is old information. Alternatively, they could make them only available to human readers, or something like that — there are different technical things you might be able to do. Or you could just take them offline altogether.

Then there was a withdrawn savings account presented in the present tense. The LLM was describing a product that no longer exists — another out-of-date thing. I haven't uncovered where that information came from, but again, that's something a brand could audit: does our website still talk about a product that doesn't exist? It could be as simple as maintaining a part of your website, maybe designed for large language models, that sets the scene and says, here's everything you need to know about products that are out of date or no longer exist, and here's everything you need to know about our current product range. A single point of reference.

Amelia: And is that easy to do from a technical point of view?

Paul: Yeah, I mean, it's easy to do. You can set up a part of a website specifically with that in mind, so it's not impossible. I think the hard part is coordinating your internal team, especially in a large organisation, to make sure that spurious information isn't still available online. But most companies have people responsible for their website who are constantly looking for things like broken links and out-of-date information, so this should just become part of that process.

I think this highlights that you probably need to take that a bit more seriously. A press release published about a rate change will live forever in the eyes of the internet, so you need to version control it. Maybe your press releases about rate changes always live on the same URL, like you would with an annual report, and you say, here's the latest rate change, we'll publish it to our rate change page. And maybe there's a historic log of what's happened before, like a version control history. That would be a smart way to manage it.

Pat: The other thing you can do: large language models like to take the easy route. They'll generally take the route of least resistance. There's a rise in creating a file on your website called llms.txt, which you add to your sitemap so that search engines crawl it, and in that file you effectively crystallise the core current facts about your products and services. You might have FAQs in there, which large language models really like to surface because they're answering questions most of the time. You can have your latest rates, drawn from your current rates page. You can have key contact information and the latest terms and conditions.

That becomes an index of the current state of your products and services, and if you do that and it's well structured, large language models will naturally gravitate towards it, because it's easier to digest. It's just a text file with everything the large language model needs in one place. They'll gravitate towards that rather than having to download a big HTML page, crunch through it and try to figure out the answer. So there's definitely a lot you can do off the back of being informed about an incorrect piece of information. There's a lot you can do on the site to make it more powerful for these models and point them in the right direction.

Paul: Yeah. And from a Consumer Duty angle as well, I'd imagine the compliance team would be keen to know if incorrect rates are being surfaced by a prominently used large language model. You can't necessarily directly change what the large language model says, but you can instruct your marketing team to tidy up incorrect references online. You can also instruct your customer support team to be ready for disappointed customers who've asked ChatGPT what mortgage rate this company can offer, it quotes the wrong rate, and the customer phones up or speaks to a branch and has to have that conversation: no, we can't offer that rate, the rate is actually this. It's almost a customer relationship thing as well — making sure your team are informed of the lay of the land and that these rates might be out there in the wild.

Amelia: Yeah, because presumably there might be customers who see that information, take it as gospel and be annoyed at these firms. It's about managing that and explaining it in a way they understand.

Paul: Yeah, exactly. I suspect that happens from time to time because of these types of things, and this isn't necessarily anything new. The other thing it can prompt you to audit is partner websites and publications. Maybe you work with brokers, for instance, who publish information about the firms they work with, and maybe they've got out-of-date information. This is all designed to surface potential issues and let you know where to go and dig: we need to look at our own website, or at our partner websites, or at media publications that have out-of-date information. We might be able to go out to them and say, here's the up-to-date information, would you mind updating it? And then also preparing your internal team: we might get customers who are disgruntled about this.

Amelia: So it's going to give you plenty to work with. That's what you found through this first round of testing, but what's next for Corrik? What's the plan?

Paul: It's the formal launch of the first version now. Pat, you're at an event tomorrow, aren't you — an expo where you'll be doing live demos for people. I think it's going to be about a lot of testing, getting people on board, and getting accurate source of truth information that we can really put it to the test with. We've got a lot of outcomes from our first round of tests, and I imagine, Pat, just from the stuff we've been talking about today, you've got thoughts about how we'd tighten up the accuracy checking.

Pat: Yeah, definitely. There's still a lot of work to do, but the version we're launching tomorrow works and provides accuracy checking. We haven't really talked about the visibility tracking, which is pretty good. On the visibility side, it tells you how often you're mentioned in the queries you configure. It can also track your competitors, so it can show how you're performing against them. If it carries out a thousand searches and you're mentioned 580 times, it'll start plotting that on a chart and show you how often you're mentioned compared to your competitors. That's quite useful, and it's all working really well.

On the accuracy side, I think there are some extra checks we need to do — some tuning of the models we're using. If it does flag a discrepancy, we probably need to run additional checks on that particular discrepancy so that we're double or triple validating each one and making sure it's got the right priority before actually publishing it.

I've been working really hard with Russell here as well. Russell's been doing a lot of the visual stuff and building up the front-end website, and I've been doing a lot of the technical stuff behind the scenes. We're both flat out trying to get it stable and over the line. We were progressing quite well until PHP melted down yesterday, and now I'm on the back foot a little bit. I've got some catching up to do today before the event tomorrow.

From there, I think it's just going to evolve very quickly. AI technology is so powerful these days that you can evolve software very quickly. I suspect we'll get a lot of feedback from the event tomorrow. Hopefully we'll get a few people signing up, they'll give us feedback, and it's going to change and get much better very quickly. And a few of our clients will definitely be using it. We'll be using it to enrich the reports we provide back to them. So I'm looking forward to seeing where it goes.

Amelia: I know you said this isn't a sales pitch, but given everything we've spoken about today, what difference do you think this can make to firms day to day and to their business?

Paul: I was thinking about this in the context of what we've done with it so far and what encourages us to carry on with the next version. Even though we've talked about the false positives it uncovered, it also uncovered genuine inaccuracies that I think a compliance team would want to know about. It's helped point out where brands have out-of-date information available online in a way that feeds inaccurate information to a large language model — we found real examples of that — and that's something you can actually do something about. It can also help uncover external sources of inaccurate information, where something's being quoted about you from an external source.

In combination with the visibility tracking element, which is what a lot of people are clamouring for at the moment — there are lots of firms trying to tackle that — I think this extra element of accuracy tracking is what makes it properly useful in my mind, particularly in the space we work in, which is regulated financial services.

The thing that's been hammered home to me so far is this concept of the source of truth, and actively maintaining a source of truth for your brand — not just to feed into a tool like we've built, but to have it there for large language models and potentially for humans as well. So you've got an easy-to-access fallback point. No matter what old press releases you've got out there, you've always got this gospel source of truth on the current state of your products. In a fast-moving space like savings and mortgages, where rates are constantly changing, that feels like a really important step to take.

Amelia: Have you got anything to add to that, Pat?

Pat: Just to expand on the source of truth: your website should be your source of truth. That's the goal of a website. You don't want to be giving out incorrect information, but if you've got a big website, or you're a complex business with loads of different products, it's really hard to stay on top of that and ensure that all of your pages are accurate and that old news stories aren't surfacing incorrect information. Playing around with the tool now and thinking more deeply about how AI agents are responding to these questions, ensuring your website provides accurate information to these tools is really important right now. And it's only going to get more important over time as people migrate from search engines to AI tools for all of their online research.

Amelia: So plenty of homework, plenty for people to think about. And as you say, Corrik is available today, as the episode goes live.

Paul: Yep. Live and ready to go. Free trial, no card needed.

Amelia: So do go and check it out. And I'm sure feedback is very welcome.

Pat: Yeah, if you come and speak to us tomorrow and you're nice to us, I might give you a few extra credits when you sign up.

Paul: Absolutely.

Amelia: And what event is it you're at, Pat?

Pat: In Guernsey, we've been running a series of events called All In: Guernsey's AI Sprint, organised by a group of local organisations. I sit on the IoD committee over here, and the idea came out of being involved in that, along with the Chamber of Commerce, the Guernsey funds organisation, the Guernsey builders' association — there's a whole load of groups that come together, called the G8, catalysed by the Guernsey Chamber of Commerce really. They've come together with the goal of getting Guernsey more engaged with AI. As a jurisdiction, AI can seem quite threatening, given that most of our businesses are in the finance industry, administering funds and insurance, and AI happens to be very good at administering things.

So the goal was to put on a whole load of events over a six-week period, get people more confident with AI and try to answer their questions. It's been really successful. There have been 50 or 60 events over the six weeks, and most of them are sold out. They're all completely free. You've got events targeted at board level, hands-on workshops, events targeted at entry-level people, Claude Code sessions for technical staff. It's been absolutely amazing.

Amelia: Wow.

Pat: The event we're at tomorrow is an expo, so that's an opportunity for firms to commercially pitch their products. All the other events are non-commercial — the goal is education — but this is like a conference where you've got a stand and pitch your products. There are a few other firms pitching various AI-related things, and we've got speakers from Microsoft and AWS down at the event on the day as well. It should be a really interesting day.

Amelia: Sounds amazing. Sounds like you haven't had a busy enough week, Pat. You need to cram some more in.

Pat: Yeah, I've been organising quite a few events for the IoD as part of this, and taking part in events and doing training as well. It's been a pretty hectic couple of months.

Amelia: Did you say you're away next week? You're off?

Pat: Yeah, we're going to Euro Disney. It's going to be fun, but it's not going to be relaxing, is it? Let's be honest, with two kids.

Amelia: Very relaxing. Maybe not quite. So you're off next week, and so is Paul. But before we go, shall we have a bit of Jargon Busters?

Paul: Yeah, let's give it a go.

Amelia: Right then. If you've not caught this before, this is where I put the guys to the test with some industry terms. This week's term is "dead cat bounce". Do we know the definition of dead cat bounce?

Paul: Got no idea. Dead cat bounce. Is it some sort of investment that...

Pat: Nah, I'm stumped on that one.

Paul: Don't know. Dead cat bounce. A cat has nine lives. So is it an investment that has failed but has a sort of last hurrah or something? That's the best guess I can come up with.

Amelia: Well, that's a good guess.

Pat: Maybe an investment that's failed multiple times and then at the last minute they turn it around and suddenly it becomes a good investment, a good business maybe. I don't know.

Amelia: Well Paul, you were sort of close. The official definition is a small, temporary recovery in the price of a declining stock.

Paul: Okay.

Amelia: But it's a good name, isn't it? Quite inventive.

Paul: Yeah, I like that one.

Amelia: So, well done. That is about it for today's episode. I think we might be taking a break next week for your time off, guys. So relax, enjoy — enjoy Euro Disney, Pat. And we'll be back very soon. Take care.

Paul: Say hi to Mickey.

Pat: Thanks a lot. Cheers, guys.