The short answer is, you don’t.
Longer answer: first “works flawlessly” is meaningless. To start with, you need a spec. It should define, with as little ambiguity as possible, how the program should behave. When testing, you test to make sure the software meets the spec. You may well find things the spec doesn’t cover, and need to have things clarified/expanded/whatever, but you need some sort of way to determine what the correct behavior is.
Second, your software is part of a system. And even if the software is flawless, the system can fail. Cosmic radiation is a real thing, it does flip bits randomly. Very rarely, but it happens. More realistically, your program is probably running on top of an OS, or at least on top of hardware, and that hardware can and will fail in different ways. And if the any part of the system changes (patching, hardware upgrade, OS upgrade, etc) it may well cause your program to break, in ways you couldn’t have found before. (This is why some medical equipment still runs on Windows 95, and some ATMs still run OS/2.)
So, you don’t promise flawless behavior. You do say that on this hardware, with this spec, we validated this behavior.
Depending on the importance/severity of failure, there should be system level design that helps improve reliability. Things like multiple execution engines, and/or parallel execution, where multiple programs have to agree on what they should do. Or keeping a human in the loop. Or ECC RAM. Or having auditors. Its up to the user to decide what level of assurance they need.