Execution Architecture and Analysis
Where editing, simulation, diagrams, storage, and heuristic circuit analysis actually run.
Execution architecture
- Browser: DSL editing, syntax highlighting, input checks, request construction, local structure analysis and visualization.
- Azure Function API: request/rate/usage validation, DSL parsing, ideal statevector calculation, Bloch vectors and probabilities, seeded shot sampling, and SVG circuit diagram generation.
- Browser: displays returned results, renders the statevector explorer, copies DSL/OpenQASM, decodes returned SVG for standalone download and converts it to PNG.
Modeler API routes additionally build the formulation and circuit, search parameters, enumerate the bounded classical reference, and calculate symbolic resource projections. These computations are not performed solely in the browser.
Production and localhost UI configuration currently call the Azure Function host directly, as specified in frontend/config/settings.js. The website's /api/ URL is a documentation page, not the simulation host. Running a simulation or building a model requires network access and an available API. Editing and inspecting already-loaded results do not require a new execution request. The startup text preview is a browser placeholder, not a simulated diagram.
Storage and sharing
The simulator saves editor/settings/theme state and a usage session identifier in browser localStorage; Learn progress uses ag-learn-progress-v1. Browser storage may persist between sessions and can be cleared by the user. Seed/settings are carried in modeler handoff URLs. Share URLs contain the encoded circuit and settings; encoding is not encryption. API calls transmit the circuit/model, execution settings and session identifier. Do not interpret browser-first as private, offline computation.
Entangling-gate interaction analysis
The browser tracks controlled gates and distinct qubit pairs. This indicator is derived from circuit operations and does not independently calculate an entanglement measure from the final quantum state. Entangling-capable gates do not necessarily leave a state entangled. Likewise computational-basis correlations alone do not verify entanglement: a classical mixture can have the same probabilities. Protocol descriptions are circuit-pattern hints, not proofs.
AutomationGlance Complexity Score
The score is a normalized heuristic for comparing circuit structure inside AutomationGlance. It is not a standardized quantum-computing complexity measure, runtime prediction, hardware error rate, computational hardness estimate, or evidence of quantum advantage.
S = min(1, 0.4 min(d/50,1) + 0.3 min(g/100,1) + 0.2 min(e/20,1) + 0.1 min(n/8,1)). Here d is greedy circuit depth (each operation takes one layer, including measurement), g is non-measurement gate count, e is the number of distinct controlled-gate interaction pairs (not the number of entangled states), and n is width. Gates on disjoint wires can share a layer. Measurements in local structure analysis retain written positions, although the API samples them terminally.
For valid supported input the expected range is 0–1, displayed to two decimals. Larger values mean more of these structural factors, saturating at the chosen thresholds; those thresholds are UI heuristics, not physical limits. Performance mode reduces UI animation and shadows; it does not increase the 8-qubit execution ceiling. See the score implementation.