First, what ROX OS is. Then the objections people raise most often, and one question about the name. Every answer says what is measured and what is not claimed. Where a claim has no record behind it, the answer says so instead of making the claim.
An operating system for quantum computers. You describe a problem. ROX OS reads the machine, predicts what it will return, shapes the run to fit the machine, runs it, and proves afterwards what happened. One interface for IBM and IQM machines, and a simulator to try it for free.
Today you pay for quantum machine time without knowing what you will get, and when the result comes back you cannot tell whether it is right. ROX OS writes the expected result down before the first shot, seals it, and grades the result against an exact answer where one exists and against the vendor's own path where it does not.
Four steps, every time. READ: the calibration of the machine, minutes before the run. PREDICT: the expected result, sealed with a hash. OUTPERFORM: the job runs twice on the same machine in the same minute, once the vendor's way, once ROX's way. PROVE: raw counts, job IDs and a certificate anyone can recompute.
A record for every job: forecast, measurement, both arms, raw counts, official job IDs, a signed certificate with a check address. Better results where the machine is near its capacity. And an honest answer where it is not: on easy jobs ROX OS tells you to use the vendor path and charges nothing.
Researchers in physics and chemistry who need results they can cite. Engineers who paste their own circuits. Finance and logistics teams with a portfolio, a route or a network to optimise. Buyers and programmes that need to know what a machine delivers before they sign for it.
Free on the simulator, forever. Real hardware runs on your own IBM or Braket instance at the vendor's list price; ROX OS never marks it up. Its own fee applies only when ROX arms run on real hardware, and only where they help.
Against the vendor's own default path, on the same machine, on the same problem, with the plan written down before the first shot. Not against other research groups, not against the best result anyone has ever published, and not in general.
Each comparison is one record: same circuit, same machine, same day. One arm runs the way the vendor's stack would run it, the other the way ROX chooses. Both are sealed first, so neither side can be chosen afterwards.
Where ROX did not come out ahead, the record says so and stays in the ledger. A ledger that only keeps its good days is a brochure.
The four records behind this answer, each a signed certificate anyone can check: VQE · IBM ibm_fez · 12-spin ring · VQE · IBM ibm_phoenix · 12-spin ring, forecast sealed · QAOA · IBM ibm_fez · MaxCut chain, depth 100 to 150 · QAOA · IQM Emerald · MaxCut chain, depth 12
True, and we say so on every simulator run. A simulator run carries no verdict here. It shows the measured value, the exact answer and the distance between them, and nothing else.
The simulator is there so that you can see the whole path once without paying for machine time: plan, seal, run, result. The claims about machines come from records that ran on machines, and those name the machine and the day.
Fire Opal makes the circuit survive the machine better. ROX OS writes down beforehand what it expects, then measures whether that was right, and keeps the file either way.
The two are not the same job, and we have not run them against each other. Until such a record exists, we do not claim to be better than them. When it exists, it will be a record like every other, with both arms sealed before the first shot.
Yes, and that is a reason to check rather than to trust. That is why the method is built the way it is: the plan is written and hashed before the run, the raw counts stay in the file, and anyone can recompute the result from them.
You do not have to believe anything here. Take a record, recompute it, and see whether the number comes out the same.
The preregistration: the plan, the forecast, the metric, the calibration timestamp, the shot count and the reference. Those go into a file, the file gets a hash, and only then is the job sent.
What the seal does not do: it does not make the forecast right. A forecast that misses is a sealed miss, and it stays in the ledger as one.
Because it sits between your problem and the machine and does the same four things every time, whatever the machine underneath is: it reads the problem, it predicts what the machine will do with it, it shapes the run to fit, and it proves afterwards what happened. You bring the problem. It picks the machine, writes the plan, seals it, runs it and files the result.
That is what an operating system does for a computer: it hides the machine, keeps the rules, and leaves a record. It is not a library you call, and not a service that hands back a number without a file behind it.
What is not claimed here. No overall balance of wins. No comparison with a vendor that has no record behind it. No statement about machines drawn from a simulator run. No number that does not come from a file in the ledger.