Skip to content

Latest commit

 

History

History
28 lines (18 loc) · 1.77 KB

File metadata and controls

28 lines (18 loc) · 1.77 KB

Quantum Computing in Vakend

Vakend’s quantum work has three distinct scopes. Keeping them separate is essential to honest communication.

flowchart LR
    Learn["Circuit learning"] --> Sim["Local ideal state-vector simulation"]
    Sim --> Native["Optional native compute acceleration"]
    Sim -. user opt-in, own credentials .-> QPU["External physical QPU"]
    Security["Security Center"] --> Inventory["Quantum-readiness inventory"]
    Inventory --> Migration["Future cryptographic migration planning"]
Loading

1. Learning and simulation

Quantum Lab lets a user build circuits and run an exact state-vector model within practical hardware limits. A simulator follows quantum mathematics; it is not a physical quantum computer and does not create quantum advantage.

2. Optional real hardware

The current product direction allows an explicit, user-keyed bridge to a supported quantum provider. That connection is optional, requires the user’s provider account, and should use a prepare/confirm flow before a job leaves the device. Provider availability, pricing, queues, noise, and results remain the provider’s responsibility.

3. Quantum readiness

The near-term practical value is inventory and migration planning: identifying which cryptographic uses may be vulnerable to sufficiently capable future quantum computers and separating them from algorithms already designed for a post-quantum setting. An inventory is not a completed migration and must not be presented as one.

Research boundary

Law 54 / CTE5:4 and Infoton work are research environments. Deterministic software probes, frequency models, or repeated patterns are not physical quantum measurements, validated medical findings, or production cryptography. Claims should remain falsifiable and clearly labeled.