MI
In conversation with
Murat Isik — CEO of Noah Labs
Noah Labs sits at a point where the pressure to deploy AI fast and the obligation to handle data responsibly are pulling in genuinely opposite directions. What does that tension actually feel like from inside the organisation on a day-to-day basis?
At Noah Labs, tension stems from the constant friction between probabilistic AI speed and deterministic mission critical rigidity. Operating behind an air gapped sovereignty wall, the team faces a mandatory verification tax where code must be mathematically proven rather than just generated. Since mostly correct constitutes a catastrophic failure in defense, the organization practices pragmatic radicalism by balancing high velocity innovation with the meticulous responsibility of ensuring sovereign software remains secure and modern.
"Mostly correct constitutes a catastrophic failure" is a striking place to draw the line. Most organisations talk about acceptable error rates as a feature of AI adoption, not a disqualifier. Help us understand what the verification process actually looks like when a piece of generated code hits that wall.
When generated code hits the verification wall, it enters a rigorous mathematical gauntlet where every function is treated as a theorem to be proven. Instead of relying on traditional testing or acceptable error rates, the platform uses formal proof assistants to establish a definitive logical equivalence between the legacy source and the new implementation. If the AI produces a solution that fails to maintain bitwise parity or logical certainty, the output is discarded regardless of its apparent functionality. This process ensures that the speed of AI never bypasses the absolute necessity for deterministic safety in national security systems.
Formal proof assistants, bitwise parity, logical equivalence , that is a demanding pipeline to run at any pace. Walk us through the last time a piece of generated code looked functionally correct to everyone in the room, passed initial review, and still got discarded when it hit the formal verification stage.
In a recent pilot, our AI translated a flight critical Ada control loop into Rust. The code passed all unit tests and looked flawless to our engineers. However, formal verification flagged a subtle floating point precision discrepancy during extreme edge cases. Because this single bit deviation broke mathematical parity with the legacy source, the code was immediately discarded. This proves that mathematical certainty always overrides human consensus in our pipeline.
That Ada-to-Rust example is worth sitting with, because it surfaces something most modernisation projects quietly avoid. The formal verification caught what the engineers missed. But the engineers were the ones who built the verification criteria in the first place. At some point, a human decided which edge cases to test for, and which ones to leave out. Where does that human judgment enter the pipeline, and how do you prevent it from becoming the weakest link in a chain that is otherwise mathematically rigorous?
Human judgment enters at the very beginning: the specification phase. Formal verification only proves that a program matches its mathematical model; it cannot prove that the model perfectly reflects reality. The human is the one defining the boundaries, the invariants, and the assumptions about the outside world. We cannot entirely eliminate this human element, but you can prevent it from becoming a fatal flaw by treating the specifications, not just the code, as the primary vector for bugs.
Something in that answer sits with us. The specification is where the human is most exposed, and by your own account, it is also where the whole chain either holds or breaks. Has there been a moment in this work where a specification assumption turned out to be wrong in a way that genuinely surprised you, something that changed how you think about where the real risk lives?
But from observing where automated translation between older paradigms and modern languages consistently hits a wall, there is a recurring failure mode that highlights exactly what you are talking about: the assumption that a legacy system's constraints were purely logical, rather than physical or environmental. When that mathematically verified, perfectly safe Rust code runs on contemporary infrastructure, it executes too fast and triggers the race condition, or it correctly panics on the overflow instead of looping. The system fails in reality because the human who wrote the specification assumed the original code told the whole story. The real risk didn't live in the syntax; it lived in the silent context the original developers took for granted.
CloudTweaks wants to push into this, because there is a real tension underneath it. The silent context problem you are describing, where the original developers encoded environmental assumptions that never made it into any document, is not a specification writing problem. It is an institutional memory problem. And there is a debate running right now about whether air-gapped, sovereignty-first architectures inadvertently make that worse, by cutting off the very collaborative and cross-referencing tools that help surface what was never written down. Since you are deep in this, how do you think about that?
From my perspective, the "sovereignty-first" approach creates a paradox. On one hand, the highly regulated industries that use Ada or COBOL or Rust, such as defense, aerospace, banking, require that air-gapped security for survival. On the other hand, isolation is the natural enemy of discovery. The real risk is that in our rush to be "sovereign," we build a fortress that perfectly preserves our oldest mistakes. We verify the logic but ignore the environment, and in an air-gapped world, there is no one on the outside to tell us we're missing the point.
Five years from now, looking back at this period, what will seem like the obvious mistake that the entire field of regulated software modernisation made, and that almost no one is willing to name out loud today?
Looking back in five years, it will be obvious that our biggest mistake wasn't technical, it was trying to run 21st-century code through 20th-century manual compliance. Right now, we are modernizing our tech stacks but leaving the bureaucracy untouched, effectively building Ferraris and driving them through a manual toll booth every mile. The field's "unspoken" error is failing to treat Policy-as-Code as a first-class citizen. True modernization isn't just moving to the cloud; it’s making the audit as automated and invisible as the deployment itself.
The Ferrari and the toll booth is a vivid image, but it raises something harder. Automated compliance, policy as code, audits that run invisibly, these are only trustworthy if the people who wrote the policy understood what they were automating in the first place. Given everything you have described about silent context and assumptions baked into legacy systems, what makes you confident that encoding compliance into code does not simply move the same human blind spots one layer deeper?
If we simply translate a flawed, manual "blind spot" into a Python script or an OPA (Open Policy Agent) rule, we haven’t solved the problem; we’ve just given it a cloaking device. In fact, we’ve made it more dangerous because it now operates at a scale and speed that human intuition can no longer intercept. We don't solve this by trusting the code more; we solve it by requiring Cross-Functional Literacy.
