QFlow Studio is documented as a product system, not as a collection of isolated screens. The primary object is the workflow record: a durable unit that keeps design state, generated source, provider context, execution history, and evidence together.
The docs are organized around the workflow lifecycle rather than internal menus. Start with a workflow record, inspect the design and code, route execution with provider boundaries, then keep each result attached to a reviewable evidence trail.
Use this overview to decide where to begin. Use the linked guides when you need exact behavior for the canvas, generated code, routing, run history, academy workflows, security boundaries, or deployment health.
Workflow path
Step-by-step path
Create a durable workflow record
Create or open a workflow from a template, prompt, blueprint, or existing record. Confirm the title, owner, design state, generated source, route context, and evidence destination before treating it as operational work.
Result A named record that can be inspected, reused, and reviewed.
Inspect design and generated source
Use the canvas, block inspector, generated code, and analysis views to confirm what the workflow represents before it reaches a provider queue or simulator run.
Result A circuit and source snapshot that match the intended work.
Route execution with clear boundaries
Select provider context from authenticated product surfaces. Keep queue posture and route fit visible, but keep provider tokens, billing state, and private credentials out of screenshots, notes, and public evidence.
Result A route decision that is explainable without exposing secrets.
Retain evidence for review
After execution, return to run history and evidence pages. A useful evidence packet answers what ran, which source or circuit was used, which route was selected, and what result came back.
Result A saved execution trail that can support review or teaching.
Section 01
Documentation scope
These pages cover the public product model, normal user workflows, teacher-facing learning flows, provider routing concepts, result evidence, and deployment health orientation.
They do not replace private operations runbooks, incident response notes, customer workspace records, billing data, or provider credential procedures. Public documentation should explain behavior without becoming a place where secrets or admin state are copied.
- Product behavior
- Workflow lifecycle
- Provider boundary
- Evidence model
Section 02
Who should use these docs
Researchers use the Studio and Run guides to move from a circuit idea to a runnable workflow without losing context between notebooks, SDK review, provider portals, and evidence artifacts.
Teachers use the Learn and Teach guides to understand academy progress, lesson execution, resource submission, and role-safe classroom workflows.
Operations and security teams use the Route, Evidence, Security, and Deployment guides to understand provider boundaries, reviewer-safe sharing, health checks, and production service responsibilities.
- Researcher path
- Teacher path
- Operations path
- Security path
Section 03
Documentation standards
Each guide starts with the purpose of the surface, explains where it fits in the lifecycle, and then names the decision a user should make before moving forward.
Screenshots appear only where they clarify product behavior. Captures are taken from controlled accounts; admin pages, billing tables, provider tokens, private emails, and customer data are excluded from public documentation assets.
When a page mentions an ecosystem or provider, it describes QFlow's independent workflow context. It should not imply official affiliation, certification, replacement, or endorsement unless that relationship is explicitly stated elsewhere.