# Qsolve for enterprises

> How an enterprise team can evaluate a Qsolve workflow, control spend with limits and budgets, audit runs, and what its results can and cannot be relied on for.

Source: https://qsolve.omlabs.co/docs/use/for-enterprises
Updated: 2026-11-12

Qsolve gives an enterprise team three things it can check: a measured track record for each workflow against a classical baseline, a price quoted before every run with hard caps on spend, and a record of every run for later audit. It does not promise a quantum advantage, and it does not guarantee that a workflow will perform on your data as it did on its benchmarks.

## Evaluate a workflow before you adopt it

Work through these steps in order, cheapest first.

1. **Check the fit.** On the workflow page, **Limits** gives the largest problem it accepts and which machines it runs on. If your real problems are bigger, the workflow cannot take them as they are. The optimisation workflows stop at 24 variables, so a larger problem has to be split first.
2. **Read the track record.** Look at the benchmark cases nearest your problem's size and type, including the amber and red squares. See [Choosing a workflow](/docs/use/choosing-a-workflow).
3. **Open benchmark rows.** Each shows every method run on that input side by side, the classical baseline by name, the quantum answer, the mitigation figures and the circuit. You can open the benchmark run itself and read its receipt.
4. **Judge the baseline.** An exhaustive search or an exact solver is a strong baseline. A heuristic is weaker, and Qsolve cannot prove any baseline is the best classical method. If you have a classical method you trust, run it on the same input and compare.
5. **Run your own representative input on the CPU simulator.** It is the cheapest test and shows how the workflow behaves on data from your domain, which the track record cannot.
6. **Check hardware separately.** If you plan to use a quantum computer, read the **Noise-model estimate** and **On quantum hardware** tables and run a small case on the machine. Hardware results do not count towards the headline accuracy because they measure the device as much as the workflow. See [Accuracy, fidelity and noise](/docs/use/accuracy-fidelity-and-noise).

## Control cost

Each run shows a quote before credits are taken. The submitter sets a **Spend limit** per run, above which the run waits for approval. Qsolve refuses any run above a per-run cap, and the account owner can set a **monthly budget** per UTC month, which refuses runs that would pass it.

Monthly spend counts charged credits plus what active runs hold, so concurrent runs cannot overshoot the budget. A run never costs more than its hold. The cap values, concurrency limit and worked examples are in [Credits and pricing](/docs/use/credits-and-pricing).

**Usage** shows the balance, spend against the monthly cap, spend per month for the past year, spend by workflow and by target, and every credit movement, which makes it a ready view for budget reviews.

## Accounts and teams

Credits and runs belong to an **account**, which is personal or an organisation. A member's role is **owner** or **member**. Everyone in an account shares its balance, monthly budget and run history, and only the owner can set the monthly budget. The **Account** page shows the account's name, plan, your role, status (Active or Suspended), balance and monthly use. A suspended account cannot start runs.

You cannot create an organisation account or invite members yourself. If your team needs a shared account, ask the Qsolve team.

## Audit a run

Each run keeps the exact input and settings (with an input hash), the workflow version, code commit and SDK version, the target and device (plus a calibration snapshot on hardware), every distinct circuit sent, the quote, hold, charge and return, and a result hash. **Report** downloads all of it. See [Run records](/docs/use/run-records). Records are not permanent: progress events are deleted after 30 days, and 90 days after a run finishes its input and result are cleared. Download reports if you need a longer audit trail. See [Data and privacy](/docs/use/data-and-privacy).

## What you cannot rely on

| Limit | Detail |
|---|---|
| Quantum advantage | At these sizes classical baselines can often find the exact answer. The best a quantum method can do is match it |
| The baseline being the best classical method | Qsolve shows the baseline and other classical methods that were run, and does not prove they are the best |
| Mitigated figures | They are the workflow's own, labelled "reported", beside Qsolve's measured raw figures |
| Benchmarks predicting your data | The track record describes benchmark cases only |
| Simulator accuracy predicting hardware accuracy | Simulators are noiseless |
| Hardware reproducibility | Real-device runs vary with the device's state at the time |
| Hardware availability | The quantum computer may not be open to every account and has queue waits. Check **Machines** |
| Large problems | Each workflow caps problem size, for example 24 variables or 12 qubits |
| Privacy on hardware | Circuits that encode your problem go to the hardware provider |

A sensible pilot starts with simulator runs on your own representative problems, sets a monthly budget, reviews the receipts, and tries hardware only for the cases where it matters.