Loading docs
Start from reusable workflow blueprints, starter circuits, and patterns before building a workflow from scratch.
Blueprints reduce setup time and improve consistency. Use them when a team repeats a known experiment, lesson, provider check, or demo path.
A good blueprint should be understandable before it is executed. Open it, inspect the blocks, review generated code, and then adapt it to your context.
Section 01
Use a blueprint when the workflow shape is known but details like provider, qubits, or owner need to change.
Avoid starting from blank canvas for routine onboarding, academy lessons, or provider readiness checks.
Section 02
Large project app packs map source-backed repositories and official implementation suites into reviewed QFlow surfaces. QANTIS is the reference pattern: the Hub shows repository provenance, source manifest counts, report attachments, runnable QFlow kernels, app surfaces, and adapter-needed guardrails together.
Large project imports are planned before they are runnable: QFlow pins provenance, recognizes dependency manifests, filters unnecessary or unsafe files, selects bounded runnable kernels or QASM candidates, and keeps raw source, notebooks, provider scripts, GPU/HPC workloads, and hardware jobs behind adapter-needed guardrails.
Import planning separates representation from execution. A project may be fully represented while only selected QFlow kernels, validated QASM/JSON circuits, or reviewed adapter jobs are runnable on compatible isolated runner profiles and version tracks.
Do not treat a source-backed pack as raw GitHub execution. Only bounded QFlow workflow templates are runnable in public app or API routes; notebooks, Python packages, hardware scripts, provider setup helpers, and unpublished campaign artifacts remain provenance until a reviewed adapter and owner credential policy exist.