Fault-tolerant quantum resource estimation is an assumption ledger, not a hardware forecast.

Fault-tolerant resource estimation asks what resources an application could require under a specified future or hypothetical architecture and error-correction design. It is not a benchmark of a currently available noisy processor, a delivery date, or proof that the application will outperform a classical method.

Keep three records separate: current hardware execution evidence, fault-tolerant resource scenarios, and provider roadmaps. They can inform one programme decision, but none validates the others.

Name the algorithm variant, problem instance, input representation, target observable or output, success probability, precision, repetition rule, and classical pre- and post-processing. A toy kernel without data preparation, optimization iterations, or sampling can understate the end-to-end requirement.

Preserve the application source or intermediate representation and a logical-resource summary: qubits, Clifford operations, non-Clifford operations, arbitrary rotations, measurements, depth or dependency structure, and any adaptive classical control relevant to the estimator.

Physical gate and measurement times, error rates, connectivity, cycle behavior, instruction support, and control assumptions shape the physical estimate. Built-in hardware models are useful comparison scenarios, not guaranteed product specifications.

Version the architecture model independently from the application. That separation lets a team rerun the same logical workload against improved hardware assumptions without silently changing the algorithm at the same time.

Specify the error-correction code, code-distance selection rule, logical error target, decoding and cycle assumptions, layout, routing, and how the total error budget is divided. For algorithms with many non-Clifford operations, factory type, throughput, copies, distillation rounds, and target state error can drive qubit and runtime requirements.

Do not hide factories behind one physical-qubit total. Report data-qubit, routing, factory, and other overhead categories where the tool exposes them so reviewers can see which engineering dependency dominates.

Rotation synthesis, gate decomposition, layout, scheduling, parallelism, measurement strategy, and factory scheduling can move an estimate substantially. Preserve tool version, transform configuration, approximation tolerance, and the logical trace or summary used by the estimator.

A lower number produced by a different transform is not automatically an improvement. Confirm that both scenarios implement the same application contract and success criterion.

Microsoft's current resource estimator exposes Pareto-optimal tradeoffs between physical qubits and runtime under a maximum error threshold. That shape is more useful than one selected point because programme decisions usually have constraints on both space and time.

Sweep the assumptions most likely to change the decision: physical error rate, cycle time, error budget, synthesis tolerance, QEC family, factory count, and application size. Report elasticities or scenario deltas so a reviewer can see which improvement matters and which barely changes feasibility.

Use QFlow's documented workflow, source, route, trace, export, and reviewer-note fields as a container for the estimate decision, then link or attach the application source, estimator version, logical summary, architecture model, QEC and factory choices, error budget, transform configuration, result table, Pareto plot, sensitivity runs, classical baseline, and next gate as supporting artifacts.

QFlow's public status matrix currently describes Azure Quantum as validation and resource-estimator context. It does not claim that QFlow executes the Microsoft Quantum resource estimator or exposes every assumption above as a dedicated first-class field. Run and verify the estimate with the authoritative QDK tooling, preserve its export, and label the QFlow layer as evidence context.

The next gate may be to improve the formulation, validate a logical count, compare another architecture, wait for a hardware milestone, or stop. An assumption-bound estimate can support those decisions without being presented as current-QPU performance or a guaranteed roadmap outcome.