Seth, going back to your failing fast, learning fast, where do you draw the line between giving teams the structural permission to fail or even creative freedom to invent while keeping data strictly secure? What happens when an experiment stumbles, and how do you ensure guardrails don't end up acting as innovation handcuffs, if you will?

Well, Tom, it's a great call-out.

I will start by saying that our data is our crown jewels, and so, uh, we effectively have to draw a bit of a line around the data, but not around the idea.

So our teams actually have quite a bit of freedom in what they try, how they approach a problem, being able to be curious, whi-which I think is a truly core competency, but there are very firm non-negotiable rules about the data that they can touch and that they can't touch.

Um, and we put some, some pretty rigid access controls around that driven by our enterprise data organization.

I will note, though, like on the speed question, to us, the lesson is not necessarily, you know, around the access, but how we train and, and more importantly, like how we coach.

A lot of what we've done is put these pods in place where we have both AI experts and business experts and data experts in this pod to allow us to move a little bit faster.

Seth, when an experiment with new technologies like AI fails, how do you define the value of that failure? How can a technology executive defend a budget for bold experimentation when the financial payoff also might be years away?