Okay, we'll go ahead and get started. Good afternoon, everybody. My name is Quinn Bolton. I am the quantum computing and semiconductor analyst for Needham & Company. Welcome to the 21st annual Needham Technology, Media, & Consumer Conference. We're pleased you can join us. It's my pleasure to host this fireside chat with Horizon Quantum. The company recently came public in late March. We're gonna have Dr. Joe Fitzsimons, co-founder and CEO or founder, excuse me, and CEO. Joe will walk through some introductory slides, and then we'll come back for our fireside chat. We also have CFO Greg Gould and Katherine Bailon, who handles investor relations here in the audience. With that, I'll hand it over to Joe, and then we'll come back for the fireside chat portion of the talk. Joe? Thanks very much. Sorry. Thanks for joining us. I wanted to talk a little bit about what we're doing at Horizon. Since it's our first quarter as a public company, I wanted to give you the flavor of what we do. Specifically, what we do as a company is we try to deal with the fact that, you know, no computer that is out there is really effective without software. Quantum computers are not any exception to this. There's been tremendous progress that has been made over the last year, 18 months, in getting towards quantum computers that can actually do useful work, and we're getting to the point where we're starting to see the first signs of solving really hard problems using quantum computers for the first time. But they're still not at a mature stage. They're still not at the point where software running on quantum computers in production is affecting the bottom line for companies using those systems. What we're focused on is getting there. Our mission at Horizon is to build the software infrastructure that enables developers to take advantage of quantum computers to solve hard problems, to produce software that generates real value for the end users of that software. Now, in order to get there, we have to deal with several different things, right? There's a lot of software infrastructure that needs to be built on. You can think about where we sit in the quantum computing ecosystem. At least I like to think we sit at the heart of the ecosystem in the sense that we are connecting three of the major groups in that ecosystem. We're connecting developers to hardware providers and to end users through our software infrastructure. By that, what I mean is we are building the programming languages, we're building the compilers to be able to take code written by a developer and compile it down into a form that we can then compile further to target any one of the wide range of quantum computers that are out there today. We're then able to wrap up that quantum program and expose it as a web API, so it can easily be baked into user-facing software. In order to do that, you know, the reason we're doing this is really to overcome one of the major problems in quantum computing. If you think about it, quantum computers, they're promises to be computers, but with an extra trick. They're promises to be better computers. Unfortunately, there's two different things you need to do. First of all, you need to be able to build systems that can actually process information as quantum states, and that's really hard. That's a major challenge, and you see a lot of companies working on that in the hardware space, trying to build systems that can represent information using quantum states, manipulate it using quantum mechanics. Because we know if you can do that, we know there are certain hard problems you can solve much, much, much more efficiently than you could with a conventional computer. The other problem you have, though, is how do you take advantage of such a system to tackle a specific problem? The real, you know, the reality of the situation is that there are several major barriers to doing this. The first is that, you know, quantum computers work in a different way than conventional computers. They have to be able to harness this quantum effect of interference between different possible branches a computation could take in order to extract information about the results for those different branches, in order to be able to get any kind of a speed-up compared to conventional computers. If you are not harnessing this particular quantum physics effect in your computation, you're not having any advantage over running on a conventional computer. The reality is this is just non-intuitive. Humans just don't have a natural intuition for how quantum mechanics works. We don't experience it in our day-to-day lives. The way we think about solving a paper, maybe with pen and paper, maps pretty well to how conventional computers work. It doesn't map at all to how quantum computers work. If you look at the number of people that have had any success in terms of being able to build quantum algorithms, being able to construct the kinds of algorithms you need to run on these systems to harness those effects, the number of people that have done it more than once is, like, 250 people worldwide. It's not a large number of people. One of the reasons for this is it takes a long time to get any good at this. You have to build up experience by basically failing 99 times before you succeed once. You know, if you're a glutton for punishment, you do it all over again. The other problem you have is that quantum computers are really diverse at the moment and imperfect. You have a wide range of different underlying physical systems, everything from photons to trapped ions, neutral atoms, superconducting systems, silicon quantum dots, and so on. Each one of these systems behaves in a different way. Their architecture's different. Their instruction set's different. If you wanna take maximal advantage out of the system in front of you're almost certainly writing code that is tied very directly to that one particular hardware system, and so isn't portable. The third problem you have is that, you know, the programming languages lack abstraction. The programming languages we use to program quantum computers today, it's basically like, it's like machine code. We're piecing together programs one logic gate at a time. Maybe we're using the machinery of Python to do that, make it more efficient, and you certainly see a lot of frameworks out there that allow you to do this in Python and make use of Python loops and so on. The reality is there's no abstraction there. You're still thinking about how you construct your program one logic gate at a time. If we want to get to a place where quantum computers are solving hard problems in production, creating real value for the end users of those programs, then it's not just a hardware problem. Software is also a big part of getting there. What we're trying to do at Horizon Quantum is to essentially build a bridge between classical software, and by classical I mean anything that's not quantum, so between conventional software and accelerated implementation on quantum computers. If we want to do this, there's a lot of technological challenges we need to overcome along the way. First, we need to be able to take a program written for a conventional computer, we need to be able to break apart the things that make it slow, the loops, the recursive function calls and so on, break them into simpler and simpler parts. We need to recognize which each one of those parts is doing, and then we need to replace it with a more efficient means of doing the same thing. If we do that, and those replacements we're making, when I say replace with a more efficient means of doing the same thing, I mean using some kind of processing to some kind of quantum processing to do this, then we can get to a point where we have a quantum algorithm for that task. That has come from code that is written for a conventional computer that expects the niceties and the capabilities of modern computers. Although the promise of quantum computers is to be better computers, the reality is they're currently worse computers. That means that a lot of the systems today are not able to do things like simple loops. They're not able to repeat instructions again and again until a particular condition is met. What we have had to do is to build up the programming languages that target ideal quantum computers. We've had to build up the compiler infrastructure to take those programs, compile them down into something that you can run on real systems today, and build up the execution stack that extends the capabilities of those systems in order to be able to more closely mimic an ideal system. That lower part of that, going from a high-level description of a quantum program all the way down to deployed program as a web API, that's in Triple Alpha, our software today. We work primarily with the hardware companies, so this is only in early access. It's only a small user group. It's not generally available. What this allows users to do is to build much more complex quantum applications than would otherwise be possible, and to compile them down and execute them on a really wide range of quantum computing hardware. What we're doing is essentially removing the need for developers to bet on which technology is going to win. You can write the code in our languages, and you can make it run on basically anything. We're not just a thin software layer. We're actively extending the capabilities of the systems we run on. That means if you think of things like loops, if you think about things like dynamic memory allocation, you think about things like being able to measure a qubit in the middle of a quantum computation and do something with the result, that is largely not supported on many of today's quantum computing systems. When you access those same systems through our software, you are able to do that. We're really extending the capabilities of what developers are able to do with these systems. We're also, I think, the first software company in the world, or first quantum software company in the world to start operating our own quantum computing systems. We have a superconducting system based on a Rigetti processor that is currently up and running in Singapore in our headquarters there. And we've just announced plans for a second system, a trapped ion system from IonQ. Being able to work this close to the hardware allows us to tightly integrate with the control systems, which is really necessary to be able to extend the capabilities of these systems, to have that tight integration to actually get to a real advantage. If you need to go through many software layers on the way down, it adds a lot of bloat. It's very difficult to get to a real advantage at this time where the systems are only just on the cusp of being able to solve hard problems. You know, the highlights for the last quarter are severalfold. We've added additional hardware partnerships. We, you know, as I said before, we focus on working with the hardware companies. We've recently signed agreements with Alice & Bob and with AQT, which is AQT some of you may have seen announcements from over the last few weeks where they have announced a record quantum volume. We've also been expanding our testbed system. Our first testbed system based on that superconducting system, that superconducting chip from Rigetti, is up and running at our offices in Singapore. We have signed an agreement at the end of the quarter to purchase a 256 qubit system from IonQ that we expect to have up and running sometime in 2027. The other side of this is we have focused heavily on moving up the stack in terms of the technology development, building out our languages to introduce a first object-oriented programming language called Beryllium. We showed Beryllium in preview back in December. Over the course of this quarter, we've really been extending the capabilities of that, getting ready to open it up to external users. Just to show you what a quantum computer looks like, obviously it's always lit in blue and green like this because, you know, you wouldn't want to light a lab any other way. This is based on a Maybell refrigerator, which you can see there. We have a Rigetti processor inside it. The control systems come from a company called Quantum Machines. We have also, as I said, now ordered this system from IonQ, which will add a second testbed system for us. The real advantage of doing this, you might say, "Well, you know, how many systems do you need?" The reality is you can divide basically all quantum computers into two categories. You can talk about solid-state qubits or which tend to be manufactured systems. Like, they're kinda engineered systems. You're maybe making a superconducting processor by etching it and so on. You've high control over the parameters, there's also high variability between different devices. There's device-to-device variability. These things tend to need to be extremely cold, you need a dilution refrigerator, like I showed you in the last slide. You tend to need microwave control and so on. There's the second category of qubits, and I'll call them AMO qubits, these tend to be atomic molecular optical physics. These are things like trapped ions or neutral atoms or photonics. You know, they, their structure is dictated by nature, so it's not, it's not flexible. You can't engineer it. At the other side of this, every single one of them is identical. You know, a cesium atom is identical to every other cesium atom. And you know, typically these things require things like optical stability and high vacuum and so on. There's a separate set of facilities requirements you need to care about for these. With the introduction of our second testbed system, we now have coverage one testbed system of each type. It kind of lets us learn the lessons to be able to host and operate quantum computers of more or less any kind. I will leave it there and I'll, you know, finish up, but I just wanna leave you with this. What we're doing is to try to build the software infrastructure that we believe is critically important to enabling a broad quantum advantage, to enabling developers to take advantage of quantum computers to solve hard problems across industries. We're doing this in a way that's hardware-agnostic from the perspective of the developer. The developer does not need to make a bet as to which system is gonna win out in the end. Instead, they can write their code in our programming languages and then compile it and run it on whatever hardware system is most appropriate for that task. Lastly, we're a software company, so our economics look just totally different than that of the hardware companies. You know, our CapEx is much lower. We would expect our margins to be very much different. Thanks very much. Great. Great. We'll start with the fireside chat portion now, and if we do have questions from the audience, just raise your hand and we can take those questions for Joe. Joe, thank you for the very comprehensive overview of the company and sort of where you play in the quantum software infrastructure. I guess for folks in the room who may be newer to quantum or just trying to get a high level of overview of quantum programming and how it's done today, can you start with, you know, before Horizon, how were quantum computers programmed through frameworks like Qiskit or Cirq, and what are some of the disadvantages of those frameworks currently? The most common way to think about programming quantum computers that's quite prevalent at the moment and has been up to now is the idea of quantum circuits. This is a little bit like something like an integrated circuit, right? You're thinking about piecing together logic gates. In this case, quantum logic gates, but they're similar to piecing together the NAND gates or something like that you would use in conventional computing. What you're thinking about is, "How do I implement my piece of software by writing out a pattern of logic gates that gets me to a solution?" This is really like adding together an AND gate where, like, if these 2 bits are both one, then the output of the AND gate is one. If one of the input bits is zero, then the output of the AND gate is zero. You're thinking, "How do I piece together primitives like this?" They're a little bit different for quantum computers. We have things called CNOT gates and Hadamard gates and so on. It's very much a similar vein. What you're thinking about as you program quantum computers in these frameworks like Cirq and Qiskit and so on is, "How do I piece together a program logic gate by logic gate that gets me to a solution?" Of course, that's very painful if I have to write out all the logic gates. What has happened is that you have the emergence of these Python frameworks that allow you to use the machinery of Python, the loops in Python and so on, to piece together these circuits in a, you know, in a kind of mechanical way. You can say, "Well, keep adding AND gates to the circuit until those conditions match." That, you know, that is a way to build circuits that can run on these systems. There's a few limitations. First of all, not all of computation is circuits. Like, the programs running on your laptops now, almost none of them can be expressed as a sequence of logic gates. The reason for this is that they contain things like indefinite loops. They contain while loops, where it repeats some set of instructions again and again and again until some condition is met. Actually, it's really famous in There's a famous problem in computer science called the halting problem, which kind of, the premise of this is that it is undecidable whether a general computer program halts or not. You don't know how long the runtime is going to be. If you take away the halting problem, you say, "I'm gonna build only things that I know when they halt," then you're essentially restricting to circuits, and that's what's happened in quantum computing to date. We've tried to go a different way. We've tried to go beyond circuits. We've tried to say, "What can an ideal mature quantum computer do?" Can we design programming languages that target that ideal, perfect future quantum computer? Can we build the compilers that lower them down to target different kinds of systems? Can we build the runtime capability, the execution stack, to be able to take that program written for an ideal future quantum computer and run it on today's quantum computers? Normally, what we have to do there, when I said we extend the capabilities of hardware, what we're doing is we're making multiple calls to hardware systems. We're doing multiple different quantum computations and stitching them together with conventional compute to give the effect of a single run on a much more capable system. With our testbed system in Singapore, we're able to extend those capabilities of the hardware system, so we can go beyond circuits and start to do real-time execution where you do have things like while loops and so on. For us, that's kind of critically important in getting to really useful quantum computing. We kind of see it as having to speed run the history of computer science. With Beryllium, where we've gotten to object-oriented programming, I'd say we've gone from 1940s to 1980s. I guess we still have some way to go. My next question is Triple Alpha. You know, one of the key features of Triple Alpha is your layers of abstraction to sort of mask some of the complexities of the hardware and requiring a programmer to understand quantum mechanics. So maybe spend a minute talking about the benefits of abstraction and how you achieve that through Triple Alpha. The way we have approached this is that ultimately we want to get to a place where the developer does not need to understand quantum mechanics at all in order to be able to program quantum computers, in order to be able to get the benefit from running on them. That's a challenge, right? Fundamentally, you need some kind of algorithm that exploits quantum mechanics in its processing in order to have any advantage at all from running on these systems. The way we have approached this is we have started from this kind of very low level, gate level and below it, and started to build up programming languages that move further and further away from the low-level physics and more towards how you manipulate different kinds of information. What we have done with Beryllium is to essentially build an object-oriented quantum programming language. The basic idea here is that because developers can start to create classes to represent different kinds of information, it allows them to build up higher and higher levels of abstraction. Within our own compiler, we have Hydrogen that is like an assembly language that's kind of 1950s technology. We have Helium that sits above it. That's an imperative language. It's a little bit like a quantum version of Basic, so, you know, solidly 1960s technology. Then Beryllium sits above that, which basically we have built these up to be able to get to higher and higher abstractions ourselves. As we have gotten to Beryllium, this kind of object-oriented language, so maybe solidly 1980s technology, what we are allowing is developers to build classes to represent different kinds of information, so vectors, matrices, graphs, you know, whatever it happens to be, to build them to describe how that information is stored and represented as a combination of quantum and classical information. To make those available to other developers or to reuse them themselves, such that now the developer only needs to import that library and they can suddenly start to work just with that information type. If you've built a library that allows you to represent matrices and vectors, another developer can import it. They can work, just say, "Okay, I'm gonna define a vector, I'm gonna define a matrix, I'm gonna start multiplying them together, and so on." That allows me to build machine learning algorithms or whatever on top of that. I can build a new library that allows me to do to do machine learning algorithms, for example. Each time a developer builds a new library, it kind of builds a new abstraction that is available to all other developers then. That gives you a kind of leveraging up, where each developer can build higher and higher level of abstraction, but allows each developer subsequent to them to do more with less code. You know, hopefully it's unlocking a fairly strong network effect. It's really the reason that Python is so popular. If you look at its prevalence today, a lot of that is due to the strong library ecosystem and the fact that each new library is essentially extending the power of the language. Got it. ultimately or one of your ultimate goals with Triple Alpha is to accelerate, quantum accelerate any code written, classically. I believe this will be the layer that will ultimately be called Carbon. Can you walk us through sort of the process of how do you break down classical code, find those portions that can be quantum accelerated, and then rebuilding up a program? Sure It's quantum accelerated? Yeah, sure. I mean, back in 2019, we kind of laid out this path with Hydrogen, Helium, Beryllium, and then Carbon. You know, we're on step three of four at this point. At the level of Carbon, what we are aiming to do and what we've been able to demonstrate in kind of standalone demos is the ability to automatically construct quantum algorithms from code written for conventional computers. The way we approach that is we say, "Well, what makes the code slow?" The things that make the code slow tend to be things that cause instructions to be repeated many times. There's kind of two kinds of things that do this. One is loops. You have a while loop or a for loop that just iterates through the same instructions again and again and again and again. You have recursive function calls. You have a function that calls itself, and the whole thing telescopes out. You repeat the same instructions again and again and again and again and again. What we do is we try to break these apart. We might have several nested loops. We try to break apart the instructions with inside those to make more and more and more loops, but each one of them simpler than the loop we started with. We try to break these apart. It's called, I mean, technically it's called fissioning loops, but we try to break these loops apart into simpler elements. Now we have just a loop that maybe only has an if statement inside it. We know it has no effect unless the condition in the if is satisfied. It turns out we can replace that with a quantum algorithm that does the same thing. We can use a quantum, a quantum search algorithm, a kind of quantum linear search, to search for the first instance in which that if condition is satisfied. What that allows us to do is to start to piece together a quantum algorithm, an algorithm that is exploiting quantum information processing to get to a solution more efficiently than you could with conventional processing. The reason we're doing this, not trying to, like, just generate a solution straight from the start, is because if you were hired to go into a company as a consultant and try to construct a quantum algorithm for a particular task, the smartest thing you can do on day one is to say, "How do you already solve this problem?" If you start with code that already gets to a solution and you make transformations that only make the code more efficient, then you're guaranteed more or less that the solution you generate is at least as efficient as the solution you started with. That's generally not true with quantum algorithms. The particular approach we're taking is kind of ensuring that we can always accelerate code where those accelerations exist. Excellent. I wanted to shift to Triple Alpha. We talked about sort of the ability to develop programs, the various layers, an important feature of Triple Alpha is your runtime kernel that can reside on a, you know, piece of quantum hardware and almost acts as the operating system. Maybe if folks aren't familiar with what an operating system does is for a classical computer, start with what's the role of an operating system and what's the opportunity to get your runtime kernel on- Sure quantum hardware? I mean, the way programs work on conventional computers, the programs don't really run in isolation. They're running alongside system software that is running on your computer, and that's providing various services to those programs that are running. An example of this is something called dynamic memory allocation or dynamic memory management. Within your laptop, within your iPhone, whatever it happens to be, you have some amount of computer memory, and that is being used by different programs all of the time. And in those programs, you know, as they're executing, they may need space to store variables. Well, they almost certainly do. Almost every instruction needs some space to store something. And you need to manage what space is free and what space is used on the device. Each program can't manage it alone, otherwise you would have to divide up your RAM into dedicated blocks for each program. You don't know how big they're gonna be. You can't make good use of your RAM. Instead, you want the operating system to manage that, to see, okay, what blocks of memory are available when, so that a program can request memory to store variables. If you don't have that, you end up trying to pre-allocate all of this at compile time. You end up trying to assign where you're gonna store all of the information right at the development time, and the reality of that is it's horrifically inefficient. You would just use much more memory than you need. The current situation with quantum computing is that we are getting to quantum computers that have literally hundreds of bits of memory. That's the current state of the art, right? It's not terabytes of memory, it's not gigabytes, it's not megabytes, it's not kilobytes, it's barely bytes. We're at this point where it is critically important to manage this as well as possible. What we have had to do is to build up these capabilities that normally system software on your laptop would take care of for you, because we want to get to a point where we can take programs written for conventional computers and run them on quantum computers, so we need to start filling in these gaps. We need to start adding these capabilities to manage the execution of the programs to provide the services to them as they are running in order for those programs to take best advantage of the hardware. We have put in a lot of effort to build up that side of things, but at the same time, in order to implement a lot of these, you need quite advanced execution capabilities. You need to be able to do classical compute at the same time as quantum compute is happening. In order to do that, what we do is we generate code directly for the control systems so that we're storing that classical data on the control systems as the quantum program is running, and so that we can inject it directly into the program. you know, we have this kind of interacting classical and quantum computation that are going on at the same time. That is not where most quantum computers are today, at least through the public APIs. you're much more restricted to only being able to execute, you know, circuits which are basically lists of instructions that end in measurement. By being able to extend this kind of execution infrastructure, it allows us to unlock a lot more and start to get us to the place where it makes sense to start talking about kernels and about operating systems, about quantum system software in a way that really hasn't made sense up to now. I mean, the term operating system is used quite often in quantum computing, but usually people just mean an orchestration platform where you're queuing up jobs or something like that. I'm really talking about something fundamentally different. I'm talking about what, you know, the role DOS plays or the role Linux plays in running conventional computer programs. On that front, how do you see the quantum industry developing, classical computers? You've tended to have one OS that's dominant across multiple hardware platforms. You look at sort of MS and DOS over on PCs. Do you think the quantum industry ultimately moves that direction or is it gonna be very fragmented where each hardware vendor ultimately tries to develop its own version of an operating system or at least partners for? Well, I think you can look at what happened in the history of computing, right? I mean, in some sense, I think there's a very direct analog between the way conventional computing evolved and the way quantum computing is evolving. You know, the early days of conventional computing, OSs were built by the hardware manufacturers. It was very fragmented. There was no compatibility between systems. There was no portability really. Then you started to see, you know, operating systems emerge with some level of compatibility across systems, with, like, System/360 from IBM and stuff like this. I think that is the path that quantum computing is on. The reality is that there is no one dominant hardware player at the moment. There are very many different hardware efforts that are credible. There are at least four distinct paths to building large scale error-free quantum computers, based on photonics, based on neutral atoms, based on superconducting qubits, and based on trapped ions. Each one of these, there are multiple players that are trying to pursue different architectures within that one modality. I think that's really a moment of opportunity for a company like us because it allows us to provide an abstraction layer that insulates developers from having to guess which one is going to win out and from having to redevelop their code for each new system that comes along or as they move between different hardware platforms. I think although there is an argument that if a single player became totally dominant that they would want, you know, to have their own software stack that would, you know, would be the end state, but the reality is the ecosystem's very fragmented at the moment, and that means that if a software layer becomes dominant at this point while the ecosystem is fragmented, even if things consolidate, even if the hardware side consolidates to a single player, that software layer that is already being used by developers, that's already creating a lot of value and that's getting more out of that hardware, is going to be in place. It's gonna be pretty strongly entrenched. Yeah, I think that's, you know, how things are likely to play out. Excellent. I'm wanting to shift gears to sort of the go-to-market strategy, how the company intends- Yeah to generate revenue on a go-forward basis. I think there are two primary channels. One is sort of usage-based access. Sure Through APIs that call specific quantum computing resources. The other is, as we just talked about, more serving as the operating system for on-premise deployments. Maybe talk about those two channels. Sure. Yeah, absolutely. What I would say is that the nature of our tools is that when you write programs in our languages, they are deployed to our deployment infrastructure, executed through our execution stack. That kind of necessarily means that every time a program produced with our tools is used, it is going through our infrastructure. That kind of puts us in a similar position to where AWS is with web apps, that every time you build an application, it is calling our infrastructure, and that puts us in a position to charge based on usage and based on the value of the resource being accessed. I think that has proven itself to be a pretty strong model in other places in computing it has shown up. At the same time, I wanna be clear that we are really focused at the moment on getting to a real quantum advantage, that our focus is on getting on enabling advantage so that developers can actually build applications that really generate real value in the real world. That means that our focus is on technology development and on integrating with hardware partners at the moment rather than on driving revenue, and it's gonna stay that way until we can, you know, until a real advantage starts to emerge. The reality is that's the step change that the entire industry is waiting for. The industry just looks completely different before and after quantum advantage, at least in my view. I think you mentioned that one of the reasons you're not pursuing near-term revenue opportunities like proof of concepts is so that you can focus. Yeah enabling the capabilities. Absolutely. You turn into a consulting company otherwise, right? You can certainly drive revenue through professional services. As I said, you know, one of the ways to try to get to quantum applications that have some kind of advantage is essentially through consulting. You have a room full of quantum computing experts, and you go out to industry and you say, you know, "Tell us about your hard computational problems," and you bring them back, and you try to solve them. That's, you know, maybe that works well for certain high-value problems and so on. Our focus is on trying to automate that process. Because if that process is not automated, it's a massive bottleneck for the adoption of quantum computing. It's really going to result in much slower adoption than if we can automate this process. By automating it, we make it possible to harness quantum computing to solve a much wider variety of problems. We just make it much more applicable. Turning to sort of, one of the questions that we've had from investors, just sort of the competitive landscape, you have hyperscalers like Google, Amazon, Microsoft trying to develop their own software platforms. Yeah I think taking advantage of their web API or their own quantum computing services. You have NVIDIA with CUDA-Q. How are you know, what are the pros and cons of those approaches versus Horizon's approach? I think the way we approach things is fundamentally different. Most programming approaches that exist to date for quantum computing have kind of co-evolved with the quantum computing hardware. That means, you know, kind of exposing capabilities of hardware as they have emerged. We've kind of gone the other way around. What does an ideal quantum computer look like? How do you program that ideal quantum computer? How do we take that code and execute it with today's systems? That necessarily means that we're exposing capabilities that are just not possible with these other approaches. One of the key things that we are enabling by going to a kind of object-oriented approach to quantum programming, which I realize is deeply technical, but the reality is that if you try to piece together quantum functions, you say, "Okay, I'm, you know, I'm gonna build a functionality that does search, and I'm gonna build a functionality that does Monte Carlo methods, and I'm gonna build a functionality that does, you know, factoring or whatever, and I'm gonna stitch them together with classical compute," which is the way most of these other frameworks have been approaching this. You lose out on something. You lose out on the ability to have compounding speed-ups. For example, you might imagine, you know, you have a problem where you try to find, for example, mispriced derivatives. You're gonna search over, you're gonna search over the different instruments, you're gonna search over hedging strategies, and then for each one of those, you're gonna use Monte Carlo to price it. Now, if you stitch together your quantum search functionality with your quantum Monte Carlo functionality with classical compute, you will get a square root speed-up for that problem. If you are able to construct a larger quantum program that uses quantum Monte Carlo, the quantum Monte Carlo algorithm, inside a quantum search for the hedging strategies, inside a quantum search over instruments, you can improve this to not just a square root speed-up, but to a square root of a square root of a square root. You can get to much larger speed-ups if you are able to build these larger, more complex quantum programs, and that's where we're focused. I would say it's, you know, significantly distinguishes us from other approaches. Excellent. We're down to about the last 30 seconds. Joe, maybe for those in the audience tracking the company, what are some of your biggest goals or what milestones should folks be looking for from the company, say, over the next six to 12 months? Yeah, sure. At the moment, what I would say, like a major focus with us, we've shown Beryllium in preview back in December. We will start to get that available to early access users in our system and start to build up out the library ecosystem around it so that developers are really able to get kickstarted with building larger and, you know, with building further and further abstraction layers. We really start to kickstart that effect. The other thing I would say is that you will see our testbed. We have the first testbed system up and running. We will start to integrate that. Well, we are working to integrate it with Triple Alpha at the moment. We'll start making that available to early access users too, then you'll start to see the, you know, you'll start to see the second testbed system start to be installed. The capabilities of that system are such that it should be, you know, if it lives up to spec, it should be just on the cusp of a real quantum advantage. It should be just about, you know, whether it will be perfect, whether it will be capable of actually realizing a quantum advantage or not is not yet clear, but it is right on the cusp. That's gonna be a very exciting time for us, I think. Excellent. Well, Joe, thank you very much for joining us. Thank you very much. at the Needham Conference. We really appreciate it.