QFlow Studio explained: from a visual Bell circuit to reviewable evidence.

A circuit editor helps a user place gates. A provider console helps a user access a simulator or quantum device. An SDK helps a developer express, compile, and execute programs. QFlow Studio connects those activities to the brief, route decision, run history, exports, and evidence that explain why the experiment exists and what happened.

That distinction matters for the name QFlow. Unrelated companies, algorithms, and research projects also use the word. In this guide, QFlow always means QFlow Studio, the Neura Parse visual quantum workflow and learning product at qflow.studio—not the separate Quantum Flow algorithm or another QFlow-branded service.

The Bell workflow begins with an operational question: can this implementation prepare two measured qubits whose results are correlated in the computational basis? The expected ideal distribution is concentrated on 00 and 11, not evenly spread across all four bit strings.

A useful brief records that expectation before execution. It also records what would cause review: appearances of 01 or 10 under a noisy route, a missing measurement, an unexpected source change, or a result produced under a different shot count than the one approved. This makes the later result interpretable instead of merely colorful.

On the canvas, the Hadamard gate creates superposition on the first qubit and the controlled-X gate correlates the second. Measurement turns the state into classical results. Because each block remains inspectable, a learner can explain the circuit while an engineer can inspect parameters and a reviewer can compare the visible model with the approved brief.

Reusable starters accelerate common demonstrations, but templates do not remove responsibility. The team must still inspect qubit order, control and target direction, measurement mapping, parameters, and warnings. A workflow is trustworthy only when the visible structure and the intended behavior agree.

QFlow’s public generated-code documentation presents Qiskit, Cirq, and OpenQASM views linked to the workflow. These are useful for different reasons: Python frameworks expose program logic and SDK calls, while OpenQASM provides a versioned circuit-language artifact where the selected implementation supports it.

Generated code is not automatically correct because it came from a visual model. Reviewers should compare qubit indices, gate order, parameters, measurement mapping, and source-format assumptions. If someone edits or exports source, the record should make clear which representation was authoritative for the run.

A Bell circuit is an ideal simulator-first check because its expected structure is easy to explain. The local route can expose missing measurements, invalid mappings, source errors, or a distribution that contradicts the brief without consuming external hardware access.

Moving to a provider route is a separate decision. A useful preflight records adapter status, device or backend context, account eligibility, shot plan, expected queue and cost considerations, and what the team will learn from hardware that simulation cannot answer. QFlow’s live status matrix distinguishes submit-capable beta routes from validation, access-preflight, credential-test, and planned paths; a logo alone is not evidence of submission support.

Once approved, the run record should preserve the chosen mode, route, non-secret configuration, timestamps, status changes, result object, and any external job reference. A failed or cancelled run belongs in the history too. Removing failures makes the final result look cleaner but destroys the information needed to diagnose reproducibility and cost.

Counts and probabilities answer the immediate Bell question. Exports make the result portable. The workflow record connects both to the circuit and source that produced them, so a later reader does not have to reconstruct the experiment from a screenshot, a notebook cell, and a provider dashboard opened in separate tabs.

QFlow’s evidence surface describes a reviewer-safe packet that can include the brief, circuit context, Qiskit or OpenQASM source, provider route, run trace, counts, exports, and review note. That is enough for a reviewer to understand the claim and follow the artifact chain.

Provider tokens, billing state, administrative notes, and private user data stay outside the packet. This separation is not cosmetic: it lets research, teaching, and enterprise teams share the evidence needed for a decision without treating a public link as access to the underlying account.