← Back to Dashboard

Architecture

How the evaluator is put together, and which part is actually responsible for the answer. The short version: retrieval gathers evidence, deterministic code decides, and the language model explains. Those three jobs are kept separate on purpose.

The one design decision that matters

The verdict comes from deterministic code, not from the model. The model writes the prose around it. If the model reaches a different conclusion it is recorded as dissent and shown, but it does not change the answer. This is the difference between a tool you can audit and a tool that sounds confident.

Request flow

One evaluation, start to finish.

What each layer is for

Retrieval

Finds the closest known algorithms to the problem description, using keyword and vector search together.

Supplies evidence. It does not decide anything. A close match is not proof that a problem is quantum.

Deterministic router

Applies fixed rules to the retrieved evidence and the problem text, and produces the verdict and the recommended platform.

This is the part that decides. Same input, same output, every time. It is plain code with unit tests, not a model.

Utility-scale filters

Checks proven speedup, I/O cost, error-correction overhead, whether the problem is naturally quantum, and whether the crossover is reachable.

A problem has to survive all six to be treated as a quantum candidate.

Language model

Writes the human-readable assessment and cites the retrieved references.

It explains the verdict, it does not set it. When the model reaches a different conclusion, the disagreement is recorded rather than silently applied.

Cost model

Prices a reference run on quantum, AI/ML and HPC using live retail rates, falling back to pinned rates when the pricing service is unreachable.

Per-unit rates across three different billing models. Context, not a verdict.

Code generation

Emits a quantum kernel for quantum verdicts, or infrastructure-as-code for classical ones, plus a resource estimate.

Optional. Off by default because it roughly triples the response time.

Trust boundary

The browser can ask questions. It cannot write to the knowledge index. Everything behind the API authenticates with a managed identity rather than a key, and there is no ingestion path reachable from the public web. That matters because the index is what the router reasons over: anyone who could add documents to it could change the verdicts.

Operational shape

Front end
Static export, served from a CDN. No server-side rendering, no secrets in the bundle.
API
Single container, kept warm so the first request of the day is not the slow one.
Typical evaluation
Tens of seconds. Retrieval and the model dominate; the router itself is instant.
Monitoring
A scheduled probe runs a real evaluation and checks the verdict, then opens and closes an issue automatically.

A note on what is shown here

This page names service roles, not deployed resources. Instance names, hostnames, deployment names, index names, subscription and tenant identifiers are all left out on purpose. Knowing the shape of the system should not tell you where to knock.

Try the evaluator →How costs are modelled