New$10 in starter credits free when you create an account
New$10 in starter credits free when you create an account
Sep 24, 2026
Written by: Hoonify
A nuclear criticality safety analyst at a DOE laboratory. A radiation transport specialist modeling shielding at a DOE site. A materials scientist running molecular dynamics at a national lab. All three are solving different problems. But the infrastructure question underneath them is the same one. It is not “how much compute can we get.” It is “can this environment be trusted, controlled, accredited, and kept running under the conditions our mission actually operates in?”
That question, sovereignty and control ahead of raw speed, is what separates mission-critical HPC and AI deployment from ordinary enterprise computing. It’s also the problem Hoonify Technologies was built around. Our engineering team includes people who did this work inside U.S. DOE national laboratories. They then built Hoonify TurbOS, the orchestration platform now running production workloads for national laboratories and defense industry partners. This article walks through the deployment patterns behind that work. It covers what “mission-critical” actually requires, how those requirements play out in real national-lab engagements, and where we deliberately stop. Respecting the boundary between infrastructure and scientific validation is part of how this kind of trust gets earned.
A mission-critical HPC or AI deployment is one that must satisfy four properties at once. Sovereignty: the compute stays under the operator’s control rather than a third party’s. Accreditation: it is certified to the classification, export-control, and cybersecurity regime the work requires. That means NIST 800-171, DD-2345, DoD and IC standards. Reproducibility: results can be proven not to drift when the underlying platform changes. Resilience: the mission keeps running even when a primary system, network, or site does not.
Most commercial HPC and cloud AI infrastructure is optimized for exactly one of those properties, raw throughput. Instead, it treats the other three as someone else’s problem. In nuclear criticality safety, shock physics, radiation transport, or defense simulation work, that ordering is reversed. Throughput matters, but it is the last box checked, not the first. Everything Hoonify builds into TurbOS is designed around that reversed priority. TurbOS is the orchestration layer that manages CPU/GPU resources, workflow automation, and software configuration.
Sovereign, mission-critical HPC deployment is easiest to describe through the deployments themselves. Hoonify TurbOS supports active production workloads across several U.S. national laboratories. Overall, each represents a different facet of the same underlying pattern.
LANL’s Nuclear Criticality Safety Division relies on the MCNP Monte Carlo transport code. Ultimately, those calculations underpin the laboratory’s nuclear operations. That work has historically run on a single, large, tightly locked-down computing resource. Over the past year, Hoonify and LANL’s criticality safety and radiation transport teams established a different model. The result is a configuration-controlled, software-quality-assured computing environment built on TurbOS. It meets the same rigorous requirements as the legacy system while enabling substantially greater throughput and flexibility.
LANL’s memorandum of endorsement of April 7, 2026 records a 5× improvement in computation speed. In about 40 minutes, that environment goes from power-on to a certified criticality safety calculation. LANL documented the collaboration in an internal memorandum crediting the joint software-quality-assurance and verification-and-validation program. Consequently, that program expanded the division’s capacity for high-resource calculations. The memorandum also recognized the Hoonify team’s contribution to training the next generation of criticality safety analysts.
Sandia runs TurbOS-orchestrated workloads supporting molecular dynamics and materials science research. In those disciplines, reproducibility of a computational environment matters as much as raw simulation speed. Moreover, results must hold up under independent review years after they’re produced.
Perhaps the clearest third-party credibility signal in this space comes from the Radiation Safety Information Computational Center (RSICC). RSICC distributes MCNP and other export-controlled codes on behalf of the U.S. Government. Its published guidance covers running RSICC-distributed software on commercial cloud services. That guidance identifies Hoonify as the only privately operated service in the United States providing MCNP access. Hoonify does so while meeting DoD Impact Level 4 cloud security requirements. This places Hoonify alongside AWS GovCloud (US) and Microsoft Azure Government. Indeed, they are the only other environments RSICC recognizes at that level. That’s not a marketing claim. It’s a designation made by the government body responsible for controlling access to the code in the first place.
Three patterns repeat across every one of these engagements, independent of the specific customer or code.
TurbOS runs the same qualified stack: MCNP, CTH, ALE3D, Cubit, LAMMPS, ParaView and the rest of the engineering and physics toolchain. Specifically, that stack runs in secure cloud, on-premises, and disconnected edge environments. It includes forward locations with limited bandwidth and no persistent connection back to a home network. An operator is never asked to re-validate a different platform for each target. A consistent stack from core to edge means the accreditation and validation work done once doesn’t have to be redone. Therefore, the deployment target can change without repeating it.
Every one of these programs depends on proving that a platform change hasn’t quietly altered a scientific result. A kernel patch, a new hardware target, an updated library. TurbOS manages code-locked repositories, validated software versions, and compiler/MPI stacks under strict configuration control. On the LANL deployment that means 8,015 regression and V&V tests across the full MCNP 6.3 qualification suite. Altogether, they pass at a 99% rate. That discipline is what let LANL move from a single legacy machine to a more capable, distributed environment. It did so without loosening the software quality assurance posture nuclear criticality safety work requires. It’s also what most commercial HPC platforms simply don’t offer, because most commercial workloads don’t need it.
Sovereign compute is often framed purely as a security requirement, but it’s a continuity requirement too. A design study or safety calculation may depend entirely on one facility, one shared queue, or one cluster. Thus, that bakes a single point of failure into the mission. Orchestrating distributed compute across sites, across already-owned hardware, and across cloud, on-prem, and edge targets changes that. The single point of failure becomes a design choice instead of an accident.
None of the acceleration described above touches the physics. Certainly, that distinction matters enough that it’s worth stating plainly. Hoonify’s job is orchestration and infrastructure: the right compute, in the right security posture, running the right validated software stack. Further, we do that as fast and as reliably as possible. It is explicitly not our job to assert that a simulation is more numerically accurate. We don’t make that claim. Rather, numerical accuracy and scientific validity belong to the codes themselves. They belong to the domain scientists and code-development teams who own their verification and validation programs. MCNP’s own benchmark suite, validated against internationally recognized criticality-safety benchmark experiments, is a LANL-owned process, not a Hoonify one.
What TurbOS is responsible for is proving that infrastructure change never outruns that validation discipline. Every kernel patch and platform update is exercised against the application’s own official regression and verification test suite first. Only then is it promoted to production. The results are formally recorded into the software quality assurance record supporting the customer’s mission. If a change doesn’t clear that bar, it doesn’t ship; the prior validated configuration stays in place. Platform velocity is gated by the code’s own V&V standard rather than the other way around. That order of operations is what makes it possible to modernize a nuclear criticality safety computing environment. It also lets you scale a defense simulation workload. Nobody is asked to trust a faster number over a validated one.
None of this is delivered as a vendor selling a black box. Every engagement described above was built through direct, sustained collaboration. For example, that means co-authored technical papers and conference presentations with national laboratory scientists. It means training curriculum delivered alongside a customer’s own engineers and analysts. And it means a team that includes people who did this exact work as national laboratory employees before joining Hoonify.
That collaborative model scales beyond any single contract. The same aligned tools, standardized workflows, shared verification and validation practices, and community curriculum were developed for one laboratory. They are designed to extend to a broader national community of practice. That community includes other national laboratories, university and academic research programs, engineering centers, and industry partners. A criticality safety analyst trained on one deployment can move to another and find the same validated environment waiting. Reproducible results build trust because every site runs a consistent environment. Similarly, a shared curriculum scales workforce capability as new deployments come online. That version of “partnership” is a shared standards base that gets stronger as more institutions adopt it.
Is your program comparing sovereign, on-premises, or edge HPC options for classified, export-controlled, or otherwise mission-critical work? The case studies above point to a few concrete questions worth asking any vendor:
Those are the questions the deployments described in this article were built to answer. If your team is working through a similar evaluation, we’re glad to walk through the specifics of your program.
A sovereign HPC deployment is one where the compute infrastructure stays under the operator’s control rather than a third party’s. Specifically, that infrastructure covers hardware, software stack, and data. It is also accredited to the security and compliance regime the mission requires. Sovereignty is a design property of the deployment, not just a location (cloud versus on-prem). Likewise, the same sovereign stack can run in secure cloud, on-premises, or at the edge.
National laboratories pair high-performance computing with AI and machine learning to accelerate modeling and simulation workflows. That ranges from nuclear criticality safety and radiation transport at Los Alamos to molecular dynamics and materials science at Sandia. Throughout, the underlying compute environment is kept configuration-controlled and software-quality-assured enough to meet DOE and ANS regulatory standards.
A defense-sector deployment typically prioritizes design-iteration velocity for engineering simulation, such as energetics and shock-physics R&D. It carries the same security and sovereignty requirements as a national laboratory. It also needs to run consistently in a secure data center or at a forward, bandwidth-limited edge location.
No. Infrastructure speed and scientific accuracy are deliberately kept separate. Platform and kernel changes are validated against the application’s own official regression and verification-and-validation suite before being promoted to production. Orchestration can then accelerate throughput without ever altering the numerical result a validated code produces.
Yes. A properly designed sovereign HPC stack runs the same qualified applications and configuration-controlled environment across secure cloud, on-premises, and edge deployments. That includes bandwidth-limited or disconnected locations. No separate validation is required for each target.
Hoonify Technologies builds Hoonify TurbOS, a secure orchestration platform for modeling, simulation, and AI/ML workloads. It was developed by engineers with decades of mission HPC and AI experience at U.S. DOE national laboratories. TurbOS is deployed today across national laboratory and defense industry programs, from secure data centers to the edge.
Victor Kuhns founded Hoonify Technologies in 2021, after 27 years as a supercomputing systems engineer at Cray Research and DOE’s Sandia National Laboratories. He helped design, run and tune Top 500 DOE supercomputers, including Intel ASCI Red and Cray Red Storm. He then spent two years validating personal supercomputer prototypes for the Department of Energy, the Department of Defense and the US Intelligence Community, putting serious compute in places it had never fit before.
Hoonify brings high performance computing to private industry and government agencies that need secure, turn-key, scalable systems for critical science and engineering research.
Outside work, Victor races rally and hill climb, campaigning a 700-horsepower Subaru up mountains like Pikes Peak.
Hoonify brings mission-critical computing standards to AI. Built by founders from Cray, Sandia National Laboratories, and decades of high-performance computing experience, Hoonify comes from environments where the wrong answer is worse than no answer: national labs, scientific simulations, defense systems, energy research, life sciences, and other workloads that cannot fail quietly. Hoonify is built for organizations that need AI to be fast, private, dependable, and affordable at scale. With open weights, standard APIs, nothing retained, and infrastructure you control, customers keep ownership of their data, their hardware, and their roadmap.
