Imagine you want to compare four different car engines, but each one can only be tested on a different racetrack with different weather. You'd never know which engine is actually faster — you'd only know which track-weather combination favored which engine. That's the state of QKD simulation today: each protocol gets its own bespoke simulator with its own noise model, making apples-to-apples comparison impossible. This paper builds a single racetrack. The claim is straightforward: a unified simulation platform that runs BB84, B92, E91, and BBM92 through identical impairment models — fiber attenuation, source/detector losses, polarization drift, intercept-resend eavesdropping — and reports results with actual statistical rigor (20 independent runs of 10,000 qubits each, means, standard deviations, 95% confidence intervals). The platform ships with both a Tkinter desktop GUI and a React/Node.js web interface sharing a common backend. This is an engineering contribution, not a physics one. The ladder question here is simple: what prior multi-protocol QKD simulators exist, and does this one beat them? The authors position their work against fragmented single-protocol tools, but they don't name a specific competing multi-protocol platform and provide head-to-head numbers. The key results — BB84 at 160,045 Hz mean key-rate over 25 km, BBM92 at 80,023 Hz, E91 at 52,815 Hz, B92 at 40,011 Hz — are internally consistent (they track sifting efficiency ratios precisely: BB84's 50% sifting vs B92's 25%), but these are simulation outputs, not validated against experimental hardware data. The architecture is Qiskit-native Python with a shared impairment pipeline. The design choice that matters is the shared noise model: rather than letting each protocol define its own channel, all four share fiber attenuation coefficients, detector efficiency parameters, and eavesdropper insertion rates. This is the right structural decision for fair comparison, but it's also the easy case — real hardware differences between prepare-and-measure (BB84/B92) and entanglement-based (E91/BBM92) protocols involve hardware asymmetries this simulation may flatten. The CHSH S-statistic demonstration (2.12 baseline → 1.58 under eavesdropping) validates E91's Bell-inequality intrusion detection, but in simulation this is expected by construction. Integrity is the weak spot. The platform is grading its own homework: the simulation generates quantum states, applies impairments, and measures outcomes, all within the same codebase. There's no comparison against experimental QKD testbed data, no independent replication, and no pre-registration. The statistical methodology (repeated runs with CIs) is a genuine improvement over single-run reporting common in QKD simulation papers, but the 95% CIs are narrow because the simulation is deterministic-plus-noise, not because the results are robust to model misspecification. The milestone question exposes the gap between simulation and reality. QKD hardware costs remain in the $50K–$500K range per node. This simulator could be useful for protocol selection and parameter optimization before committing to hardware, but the paper doesn't demonstrate that its simulation predictions match any real deployment. The next meaningful milestone would be validation against a real fiber-optic QKD testbed — showing that the simulator's predicted key rates and QBER values match physical measurements within some stated tolerance. The obvious experiment not run: comparing simulation outputs against published experimental data from real BB84 or E91 deployments. This data exists — groups like Toshiba, ID Quantique, and various university labs have published experimental key rates at various distances. The authors almost certainly had access to these numbers. The honest read is (a) or (b): either the comparison wasn't attempted because the simulation's noise model is too simplified to match real hardware, or it was attempted and the match was poor enough to omit. This is the difference between a useful teaching tool and a validated engineering platform.
