Readout co-design
Read your qubits
without wrecking them.
We put hard numbers on the cost of your readout — and tell you the best one your hardware can actually build.
A design-time engagement for teams building protected quantum memories: which code, which meter, which coupling, which lattice.
The problem
Measuring a protected qubit disturbs the thing the protection is for.
Every team building a protected memory knows this trade exists. Almost nobody can say what their particular readout costs — it gets discussed qualitatively, in intuition and folklore, and then designed around by guess.
It does not have to be qualitative. How much a measurement disturbs a logical qubit is fixed by the code's own error-correcting structure. That makes it a number we can compute for your device, with no fitting parameters — and a floor we can tell you whether you have already hit.
What we do
Put a number on your readout imperfection.
Every real device has an imperfect readout, and today nobody can say what it costs. We can: this much contamination in your readout costs this much of your readout quality — with no free parameters. Different contaminations cost differently, and we rank them.
The stop-work certificate.
We prove whether you are already at the physical floor on readout quality. If you are, stop spending engineering effort there — it is a wall, not a gap. Redirecting a team off a dead end is worth more than another quarter of tuning.
We know where the theory stops working.
The naive version of this analysis — optimizing against the bound — gives catastrophically wrong answers. We know that, and we verify every candidate against ground-truth simulation rather than against the bound alone. That judgment is not something you can download.
If your readout is bad, we give you the better realizable option.
Not an idealized optimum: the best readout your actual hardware menu can build, and how far it sits from ideal. For GKP codes, lattice choice is a readout knob — distinct from the usual distance-optimal choice — and we map that trade for you.
Scope
This is not a new error-correcting code, a decoder, or a QEC protocol. It is a constraint on readout that any QEC scheme has to obey, plus a recipe for meeting it. It is a design-time input — what to build — not a runtime or operational tool, and it addresses one subsystem: the logical readout.
How an engagement runs
01
Intake
You tell us your code family and dimension, the meters available on your device, your noise, and what decision this informs. We work from a rigorous intake checklist — every input maps to a real simulator parameter, so nothing is estimated by feel.
02
Analysis
We compute your readout options against the physical floor using a validated simulator, then verify every candidate against ground truth. Configurations outside the covered menu get a scoping sprint, not a guess.
03
Deliverable
A documented packet: the recommended readout, a ranked meter menu with the disqualifying floor for each alternative, the physical-floor certificate for your code, and — for GKP — the lattice trade-off between readability and protection.
Engagements
4 tiersReadability Assessment
1–2 weeks$20,000
fixed
Menu-covered analysis: the recommended readout, a ranked meter menu, and the physical-floor certificate for your code.
Custom Readout Scoping Sprint
2 weeks$30,000
fixed
De-risks the custom build. We model your device, confirm feasibility, and return a fixed quote plus a go/no-go for the full co-design.
Custom Readout Co-Design
8–12 weeks$150,000
milestone-based
An original device-specific model of your meters and noise — extending the bound past the idealized regime to your hardware, and co-designing the readout with your team.
Annual Readout-Design Partnership
ongoing$175,000
per year · or $18,000 / month
Cogitan as your readout-design function across code, meter, and lattice choices through tape-out. Billed annually, the rate is about 19% under monthly.
Every engagement starts with a conversation, not a checkout. We scope against your actual device before anyone commits to a number.
Methodology
How we work
Grounded in original Cogitan research on the rate limits of logical readout — a bound showing that how much a measurement disturbs a logical qubit is fixed by the code's error-correcting structure, with an explicit recipe for a self-reporting readout.
We reproduce the result from scratch, not from a lookup
Our core routine independently reproduces the structural numbers in the underlying paper, computed rather than tabulated. When we hand you a number, we can show you where it came from.
We deliver error budgets, not verdicts
We quantify how much readout quality is lost per unit of a given contamination, and rank contaminations against each other — so the budget tells you which imperfection to spend your effort on.
We check the bound against ground truth, always
The bound is a diagnostic: it explains why a meter is bad. It is not an objective function, and treating it as one produces confidently wrong designs. Every recommendation we make is ranked by simulated ground truth.
We can tell you when a faster decoder is wasted money
On this axis, decoder speed does not buy back readout damage below a clear operating threshold. That is a purchasing decision we can settle before you make it.
Active research
For continuous-QEC and syndrome readout, we are developing a zero-free-parameter prediction of the induced logical error — taking an obstacle already well known in that literature and attaching a number to it. So far this is exact on a toy example only. We treat it as a promising research direction, not a finished guarantee, and we will say the same inside an engagement.
The underlying paper is not yet public. A link will appear here on release; until then we can walk through the result directly under NDA.
Start with a Readability Assessment.
Tell us your code family, your available meters, and the decision this informs. If your readout is already at the floor, we would rather tell you that than sell you the next tier.