The claim and the constraint
A modernization study is informative when its comparisons isolate the relevant variables. Project 35 keeps the computational engine source unchanged across three builds, varying the boundary code and compiler settings in separate controlled comparisons.
That constraint sounds restrictive, but it is what makes the comparison meaningful. If a hardened boundary and a legacy boundary behave differently around the same unchanged core, the difference is attributable to the boundary. If two builds of the identical source differ, the difference is attributable to the compiler, not to a quietly rewritten formula.
What the hostile-input comparison showed
The documented experiment ran the same 600 sampled hostile inputs through both boundaries. The legacy boundary produced an unsafe outcome on 328 of those 600 inputs. The hardened boundary, given the identical 600 inputs, produced zero unsafe outcomes.
I want to be precise about what that does and doesn't say. This is bounded evidence over one documented, sampled input set in one local environment — it is not a universal safety proof, and there is no real 60,000-line customer system behind it. The scale of "a large legacy core" is a constructed stand-in for the class of problem, not a claim about a specific client codebase. The finding generalizes only as far as the sampled inputs represent the hostile-input space a real system would actually see.
Compilers are part of the compatibility surface
A separate compiler comparison rebuilt the identical engine source with fast-floating-point settings. With zero engine-source changes, 2,818 of 4,000 sampled numeric output positions differed between the two builds.
The practical lesson is that a modernization sign-off which only diffs source code is not sufficient. The full build — compiler, flags and target architecture — is part of what is being migrated, and it needs its own compatibility check, separate from a source review.
What this does and doesn't establish
This was a local Windows, MSVC and .NET experiment around a deliberately constrained core, not a customer engagement. It does not establish cutover safety for a real system, financial certification, or Azure deployment reliability.
Before I would treat any of this as evidence for a real migration, I would want domain-approved fixtures in place of synthetic inputs, workload-specific compatibility checks, shadow traffic run against the legacy path, and a staged rollback plan. Those are next steps I would take, not project outcomes I am claiming already happened.