Thanks, Mark. The big theme for today is how we're going to grow revenue while decreasing cost in order to reach adjusted EBITDA breakeven by the end of 2026. I'll start by talking about why we're not seeing revenue growth alongside program growth. I mentioned this earlier, and what we'll be doing to simplify our back-end automation technology to improve scalability there. Second, I want to talk about the front end, what do customers like and not like about our service terms and how we'll be simplifying on the front end to expand our offerings and simplify our offerings to reflect what we're hearing from our customers. And then finally, we're taking decisive action to reduce our costs. Specifically, we plan to reduce our annualized run rate OpEx by $200 million by mid-2025 in order to achieve adjusted EBITDA breakeven by the end of 2026. And we'll dive into the high-level plan of how we'll execute on this. Okay. Let's jump in. So the charts here are a big part of what's driving our decisions today. You can see from the chart on the left, the number of active programs on our platform grew significantly over year -- over the year. This is a good thing. Really excited about this. But alongside that, we saw a decline in our revenue from service fees. And so this is -- again, ignore downstream value share. Just look at that fee number, that's gone down. This is particularly frustrating to me because we actually have a large amount of fee bookings across these many deals. And -- but we're not converting those into revenues in the near term. And the core challenge is the rate that we're bringing these programs to full scale on our automation at Ginkgo. And I'm going to explain that, but I want to give you a little more detail so you understand that challenge because of what we're trying to fix. So on the left-hand side here is the basic process by which an R&D leader, one of our customers develops a biotech product, okay? So there, you have R&D leaders engaging with the senior scientists on their team. They're specifying a particular product scientific deliverable, okay, right? So to give some examples from Ginkgo programs of what a leader might ask for, maybe it's an mRNA design that performs a certain way in humans like we have for Pfizer. Or microbes that capture nitrogen for Bayer. Or an improved manufacturing process for Novo Nordisk. These are all scientific deliverables, all right? And in the case on the left, the customer's internal scientists will then design experiments they think will help deliver that outcome to their boss. More junior researchers will perform those experiments at the lab bench by hand. And then the data will come back to be analyzed, and you go around that loop. Now this is a manual process and generates small amounts of data, but it does work, right? I want to highlight, this is how all these biotech drugs are developed every year. And the strength of it is the flexibility right? The scientist can run any new experiment tomorrow very quickly that they want as long as their two hands can pull it off, all right? And again, when that data comes back to the senior scientists, they repeat this all over again, right? Now, of course, an R&D leader at Pfizer, Bayer and Novo, in these cases, are all choosing to instead pay to have a Ginkgo scientist give them the same deliverables instead of using their internal infrastructure. So why are they doing that? And the major reason is that Ginkgo scientists, they do that same loop, but they do it in a different way. They design experiments, but instead of small amounts of manually-generated lab data from a team, they get large amounts of data generated either via automation or via pooled approaches that leverage high-throughput DNA sequencing and barcoding. And Ginkgo is a world expert in both of these large data generation approaches. That's really the big difference, small data generation versus large data generation. And that's really our expertise. So the short answer is, why was the customer choosing to use us instead of all that in-house infrastructure they have, is they're coming to us, asking for a scientific deliverable that they think will need a lot of data to get to the answer, all right? And that's not every project, but it is an increasing number, as you see. But our approach, I want to be clear, is not strictly better than doing it manually, mainly because it takes more time to get a new protocol running at large scale. And this is the heart of why we're not seeing revenue come up with our programs in the near term. It's not a perfect correlation, but generally, the faster that a Ginkgo scientist can start to order large amounts of lab data, the faster we then see revenue coming out of all those customer projects. Now fortunately, the acquisition of