It's mathematically provable in most cases because the engine is deterministic from the ground up and I refused to ever compromise on that one detail. For example, nearly all of the VM and maths code functions have been validated for ALL possible 32-bit inputs and extensively fuzz tested in the 64-bit range. Even the more complicated sections of the code like the emulators have batteries of third party tests that ensure a certain level of compliance. The fact that you can play commerical ROMs to completion, including esoteric titles that require third party peripheral/MBC code, is quite solid proof too!
A form of recursion is also doing a lot of heavy lifting because the emulators are their own separate deterministic engines that are dynamically plumbed into the primary loop. This not only allows us to embed diegetic devices (as in, you can literally pick up a glowing brick in the world, hold it to your face, and play it), but also validates that the primary loop is coded accurately because the outer loop runs at X Hz while humble bricks must run at ~59.7275 Hz. Pacing inaccuracies in the main loop cause us to fail the brick suites that we test against. This concept of having features reinforce one another is applied as often as possible.
The obsession with determinism goes so far that both the DirectX and Vulkan backends are validated against each other for pixel level differences. If they differ more than the expected maximum then code is refactored until the drift is back within acceptable range.