Test correlation really, isn't it? Yeah. You just the most straightforward answer is to have it begin with test data from a a tested sample. I mean, correlation comes in many forms as well from small coupon material samples that we can generate material models from replicate in test data going all the way up to full crash analysis and blast analysis where we have something that's gone off for a test and we check that our models are validated against these results. And what we find is a strength for us. Our team is that we have that feedback loop with the customer. So even if we've done some kind of pioneering in an early design concept phase and we find it's going to test, we like to be fed back the results to see how we marry out, to find any differences between and over time. You build up this confidence in various aspects of your of your modeling and simulation. Yeah, that's the classic example of that is that nose cone crush that we've got on the we got the F a simulation and the real world test and you can just overlay them and see that they perform the same. Yeah. That was a was that former student. Yes. No composite. Yeah yeah yeah I think ultimately we with simulation like a lot of things it is the quality of the output is driven by the quality of the input. So if you don't have good data going in driving, driving your model, then you're not going to get a good answer. You might, you might get an answer, but I have confidence in the answer. You've got to have confidence in what data is going in. In the first place. And like Matt says, that can be material test dates or material data. It could be test data. It could be, yeah, it could be making sure you've got a good understanding of the boundary conditions of a problem. For example, we do a lot of simulating and simulating tests and no test rig or test structure is infinitely rigid, but it's quite easy to make something infinitely rigid in in a free world. So being aware of those limitations and where you're making assumptions and ultimately making sure that that the information you're putting in is appropriate and accurate and to guarantee that you going to get a good answer. Is one thing we've taken advantage of, actually, is we have a test lab, a small test lab in in our office in Leamington. And so what we can do if the customer is not testing something we've commonly going to build a little test rig should costing allow for it and we can validate ourselves small parts that we might be unsure about too. So that comes in quite handy. I think that's a good reason why a lot of customers will come back to us because we've got so much experience in that room. You know, there's 50 years of experience almost around the table here and and then people come to us because we know the nuances of the simulation world and how to make it applicable to the real world and how to tie them up. Yeah, I guess it all comes down to, again, the grass roots level really isn't that so? If you get the material data right based on your own experience evidence, then what formulations are correct? So what you've done before is bring in that knowledge from yourself, everyone around you in the team as well, and then put together and then compare it with test data. Then you're a pretty strong position. And as I should have in theory, I think has gone. And I guess a lot of that is is like you say, how drawn from the experience in the team where someone in the office knows that the answer is actually you just change this one to a to somewhere on a on a on a card and being in the office and being able to to talk to each other and make sure that everyone is aware of what everyone's doing and what the challenges are on various projects. It means that other people can can offer their input and insight from something they did seven years ago that might affect what we're doing today. And it's just that little bit of knowledge is locked away up in someone's head. But having that good communication within the team means that we can share easily and and disseminate that knowledge everywhere. I guess it's the aspect of quality as well with to really hone in on that in recent years in terms of our quality assurance processes too. So making sure they go for a robust checking process, for not always making sure they're vetted before they even get put in front of the customer is quite an important aspect to it now as well, trying to convey, particularly for new staff, other people join the company the difference between stuff like precision and accuracy. You can be consistently wrong and not realizing it's having the accuracy is key and sometimes it requires that knowledge within the team. Someone the second pair of eyes to actually see if it is indeed correct is what you put it in standard from experience. So I think that's something that we've really sort of developed, particularly in recent years as well, and what customers keep coming back to us. I mean, it's one of Oliver's favorite things, isn't it? Is quality assurance versus quality control. You want to make sure the quality is there at the start, not just catch it at the end. You want to make sure that the quality is there throughout, and that's your quality. Assurance is ensuring that you've got good quality in your model and in your data and in your results, not just the quality control which is catching. If there is an issue at the end you want, you want a combination of both, but if you get the first one right, you need a lot less of the second.