Home / Quantum

Put your data on a
quantum computer — and
know whether it worked.

Turn a question about your own records into the exact mathematical form a quantum annealer accepts, solve it locally or on a vendor machine — and get told, in the same reply, whether the answer that came back was actually the best one.

The quantum gateway is built in. AtomicDB turns a question about your records into the exact form quantum machines accept — a QUBO / Ising model — submits it straight to the vendor's machine, and maps the answer back onto the records it came from. No export, no job broker, no queue, no separate gateway to deploy and staff: the path between your data and the quantum computer has no intermediary.
The gateway problem, solved

Same question, same quantum computer.
One path has nothing in the way.

An illustration of one optimisation job travelling both ways. On top, the usual gateway architecture: five extra components between the data and the machine. Below, AtomicDB with its built-in gateway: the problem leaves from the records and the answer lands back on them.

🎲

Your data becomes the problem

There is no modelling exercise. Point at a record and its neighbourhood is formulated automatically as a QUBO — the canonical form an annealer takes directly and a gate machine compiles to.

from business records to qubits, with nothing in between
⚖️

Every answer carries a verdict

Any quantum or annealing result is a heuristic: good, not guaranteed. When the problem is small enough to settle outright, it is settled exhaustively and both answers are reported side by side.

an energy with no optimum beside it is only plausible
🔌

Bring a QPU, or bring nothing

A deterministic local solver ships with the engine and needs no account, no credentials and no network. The vendor machines are drop-in: supply your credentials and the same problem goes to real hardware.

start today on the simulator; change one setting later
Interactive · a real run

Solve it, then find out
whether the answer was actually optimal

A neighbourhood of 18 records taken from the live graph, split to maximise separation. Choose a backend, solve, then verify.

ATLAS · /atlas/quantum · 18 variables
Backend
Problem

The split that cuts the most relationships — the fault line through a neighbourhood.

The submitted flag is the load-bearing element. A local preview is never dressed up as a quantum result — the caller can always distinguish a simulated answer from a submitted one, programmatically, without inspecting prose.
The architectural difference

Three of those five components
exist only to bridge a gap

The gateway architecture

  • Export the problemOut of the analytics system — a file, a table extract, an API pull — because the platform has no concept of a QUBO.
  • A job broker serviceRe-encodes it into the vendor's problem format. Deploy, monitor, secure, patch, staff.
  • A queueDecouples submission from execution, because the broker is asynchronous.
  • A cloud gatewayHolds vendor credentials and performs the actual submission.
  • A result storeResults land here, and must be retrieved and re-associated by hand with the records they describe.

AtomicDB

  • Nothing is exportedThe QUBO is formulated in process, from live graph state.
  • One short-lived subprocessqsubmit.py carries the vendor SDKs, performs the call, prints one line of JSON, and exits.
  • No port, no daemon, no queue, no stateThere is nothing to keep alive between jobs, and nothing running to attack when no job is in flight.
  • Credentials never leave the host environmentNot the browser, not a URL, not a process argument, not a log.
  • The answer comes back attached to your recordsThe engine retained the variable-to-node mapping, so the bit-string resolves to two groups of named entities.
There is no external gateway to run: the quantum gateway is built into AtomicDB, so the broker, queue and result store have nothing left to do.
Why no translation layer is required

The correspondence
is exact

A QUBO is defined over binary variables with linear and pairwise-quadratic terms. An association graph is defined over nodes and weighted pairwise associations. A relational system must first derive a graph from its tables before it can formulate anything — a join, a materialisation, an adjacency construction. AtomicDB stores the graph natively, so formulation reads what is already there.

Association graphQUBO
nodebinary variable
association between two nodesquadratic coupling
node-level bias / weightlinear term
a partition of the grapha bit-string
The entire problem statement
{ "n": 42, "offset": 0, "linear": [ -1.5, 0.0, 2.25, ... ], "quadratic": [ [0,1,-1.0], [0,4, 0.5], [2,7,-2.0], ... ] }

Vendor-neutral — an annealer consumes it directly, and a gate-based machine consumes it via QAOA.

The entire reply contract
{ "status": "ok|not_configured|error:…", "submitted": 0|1, "job_id": "…", "energy": -18.75, "x": [0,1,1,0,1, ...] }
From a record to a quantum answer

Five steps, all inside the engine

Nothing is exported, and no problem file is hand-written.

1

Choose a record

Its surrounding network becomes the problem — bounded to a size a machine can hold.

2

Formulate

Written out as a QUBO / Ising model: one binary variable per record, one weight per relationship.

3

Solve

The local annealer, or a vendor QPU if you have configured one. Same problem either way.

4

Verify

Small problems are also solved exhaustively, so the reply says optimal true or false, and the gap.

5

Read it back

The answer comes back as two groups of your actual records — not a vector of bits.

Step 5 is the one an external gateway architecture cannot do cleanly. Because the engine retained the variable-to-node mapping, each bit resolves back to the node it represents. Once a problem has been exported, re-associating the answer is a manual join against whatever identifiers survived the round trip.
What actually changes for the owner of the data

Questions that are
currently never asked

🧹

Cleaning stops being a hunt

Today, correcting CHINO requires somebody to notice CHINO. Posed as one optimisation, the user is shown every value that appears to be the same thing said differently, as a single reviewable list — scored together, so the solver cannot propose that A is B and B is C while denying that A is C.

the difference between auditing your data and being handed the audit
🧭

Segments discovered, not guessed

Segmentation today is a set of rules an analyst writes — revenue bands, regions, industry codes — encoding what somebody already believed before looking. Community detection over the merged graph returns groupings that emerge from the relationships themselves.

behaviour rather than assumption
📐

Allocation answered properly

Reps to territories, staff to projects, stock to locations, cases to reviewers — each a binary assignment under constraints that interact, which is precisely a QUBO. The gain is that every constraint is satisfied simultaneously rather than in the order the spreadsheet happened to apply them.

🎯

“The best set”, not “the top ten”

A ranked list is wrong whenever the items interact. The top ten products by revenue may be near-substitutes for one another; the best ten to stock is a different set entirely. Selection with pairwise interaction terms is a QUBO, and the answer is a set rather than a ranking.

the difference between a report and a decision
❓

A category of question becoming askable

These have no spreadsheet answer, so they are never put on an agenda:

“Split this business into two divisions so that the fewest working relationships are broken.” · “Which twelve customers, if we lost them, would disconnect the most of our network?” · “What is the smallest set of products whose removal simplifies the catalogue without losing a customer?”

📊

An answer that reports how good it is

For a decision that matters, “here is an assignment” is weaker than “here is an assignment, and it is optimal”. Because the engine computes the exact ground state below its enumeration limit, you receive a result and a bound on it — which converts an optimisation output from a suggestion into evidence.

the difference between a figure that survives a board meeting and one that does not
And nothing to buy, learn, or rebuild. You acquire no quantum hardware and no quantum expertise, and you do not restructure your data — because the shape these problems require is the shape the merge already produced. The same question runs on the in-engine simulator today and on a vendor backend the moment credentials exist, with the formulation written once. As hardware improves, the same questions return better answers with no re-integration and no change to how anyone works.
Credentials and the trust boundary

Held in exactly
one place

The environment of the ATLAS host process. Nowhere else.

The browser never handles a credential

The interface asks only which backends exist and whether each is configured — a boolean. No token is entered in a form, transmitted in a request, or stored in browser state.

Never in a process argument

The submitter receives only the provider name, the QUBO file path and a shot count. Anything visible in a process listing is non-sensitive.

Never logged

Read from the environment inside the subprocess and passed to the SDK directly.

An unconfigured provider costs nothing

The C engine checks the required variables are present before spawning anything. If they are not, no process starts and no request is made — the response simply names what is missing.

SituationReportedsubmitted
Simulator selected
in-engine simulated annealing
ok0
Provider, credentials absent
local preview; response names the exact missing variables
not configured0
Provider, submitter unavailable
local preview, stated plainly
sidecar not reachable0
Provider, credentials present
submitted to the vendor backend
ok (QPU)1
The fall-back is deliberate. A missing credential or an absent SDK degrades to a usable classical answer rather than an error page — while saying exactly what was degraded and why.
Enabling a provider — the whole integration
1. install the vendor SDK on the ATLAS host qiskit-ibm-runtime + qiskit-optimization azure-quantum cirq 2. set that provider's env vars on the host 3. restart ATLAS so it inherits them

No additional service, no network path beyond outbound HTTPS to the vendor, and no change to the engine, the schema, or the data.

The other way in

Build the problem
as mathematics

A SymPy-backed symbolic engine sits alongside with six domains — algebra, calculus, geometry, mathematics, physics, trigonometry — kept apart deliberately, because the same symbol means different things in each (e is Euler's number in mathematics and energy in physics).

A formula built in that builder converts to the same QUBO form and is solved and verified by the same machinery that handles the graph problems. The workflow is identical from step 4 onward; only the origin of the QUBO differs.

ProblemFormulation
Graph partitioning / max-cutminimise cross-partition association weight
Community detectionpartition maximising internal association density
Portfolio / resource selectionbinary selection under quadratic interaction terms
Scheduling and assignmentbinary assignment with quadratic conflict penalties
Feature / subset selectionbinary inclusion with pairwise redundancy terms
Worth knowing. Exhaustive verification applies up to 20 variables — beyond that the reply reports the heuristic energy and says the optimum was not computed, rather than implying one. Problems are bounded to 128 variables per run, and the vendor backends need your own accounts.