Sensing, Navigation, and Adjacent Quantum Technologies
Some of the most fundable quantum products never run an algorithm. This chapter separates sensing, timing, navigation, and communication from gate-model computing, and shows how to diligence a device that has to survive the field rather than the lab.
Adjacent quantum technologies should be judged as instruments, not as down payments on a quantum computer — a sensor earns its valuation by beating the classical instrument in the field, and it proves nothing about fault-tolerant computing.
This chapter gives you the working standard: separate quantum computing from the technologies around it, then diligence each one against its own buyers, baselines, timelines, and field evidence.
Core concepts: application baselines, quantum utility, company diligence.
Quantum technology is bigger than quantum computing
Most of this book is about computation. But quantum effects also power instruments: sensors that measure magnetic fields, gravity, acceleration, and time with precision classical devices struggle to reach; clocks; navigation aids; communication components. None of these run algorithms. They exploit quantum sensitivity — the same fragility that plagues qubits — as the product itself.
That matters strategically because these markets run on different clocks. A sensor can mature while fault-tolerant computing remains distant, with different buyers (defense, surveying, telecom, research labs), different evidence (field trials, not algorithm papers), and different infrastructure. Computing-only tunnel vision misses real opportunities — and computing-grade skepticism underrates them.
Score an instrument like an instrument
The baseline score still applies:
application_score = evidence_strength - baseline_gap - integration_risk - hardware_risk
— but the baseline is now a classical instrument: GPS and inertial systems, existing magnetometers and gravimeters, lab equipment, established industrial process. Hardware risk shrinks when the device is the product rather than a subroutine inside someone else's stack.
Timing still enters through expected value:
EV = probability_of_technical_success * value_if_success - cost_of_waiting - cost_of_capital
Adjacent technologies often have different probability and timing profiles than computing plays — frequently nearer-term, frequently smaller markets, frequently procurement-driven. Score them on their own terms.
Worked example: navigation without GPS
A company proposes a quantum navigation product for GPS-denied environments — submarines, aircraft, contested regions. The strong memo starts with the mission, not the physics: who is the buyer, what is the current navigation stack (inertial systems, terrain matching), what accuracy does the mission require, and what are the size, weight, power, and cost limits?
Then the quantum question: does the quantum sensor — say, an atom-interferometer accelerometer with low drift — improve the mission relative to those classical alternatives, after integration? Evidence gets labeled by maturity: lab demonstration, field trial, product deployment, or roadmap claim. The proof gate is a field-relevant test under operational constraints. A clean lab result is a milestone, not a product.
Category errors and other traps
The first trap is mixing categories. A successful quantum sensor does not de-risk anyone's fault-tolerant computing roadmap, and a delayed computing roadmap says nothing about sensing. Companies and investors borrow credibility across this boundary constantly; refuse to.
The second trap is lab-to-field blindness. Instruments live in the world: temperature swings, vibration, calibration drift, maintenance intervals, operator skill, size and power budgets. Field behavior should outweigh laboratory posture in your scoring, because the field is where the product lives or dies.
The third trap is inherited excitement. "Quantum" on the datasheet does not widen a procurement budget. The buyer compares against the instrument they already own, at the price they already pay.
The engineering view
To a software person, these products look like embedded systems with data pipelines. The quantum element produces a measurement; classical estimation, filtering, and control software turn measurements into positions, maps, or alerts. The value is better signal, lower drift, better timing, or operation where current tools fail.
So the evidence package is an instrument's package: precision and stability specs, calibration procedure, uptime, integration APIs, data quality, field performance. The quantum mechanism explains why the specs might be beatable; the specs decide whether anyone buys.
Where the near-term decisions are
A build memo should name the wedge precisely: sensor, navigation system, timing component, communication product, or enabling infrastructure. Each has a different buyer and a different proof gate, and "quantum sensing company" is not specific enough to build against.
An investment memo compares customer urgency, evidence level, procurement cycle length, and technical moat — and keeps the decision label clean of borrowed credibility from quantum computing's storyline. Monitor is a legitimate label here too: some adjacent technologies are one field trial away from interesting and one procurement cycle away from revenue.
Exercise
Run the comparison. Pick one quantum sensing opportunity and one quantum computing opportunity, and diligence them side by side.
- For each: name the buyer, the workflow, the baseline they must beat, and the timeline to value.
- List the field evidence, integration burden, and top two failure modes for each.
- Define the proof gate that would most change your confidence in the adjacent technology.
- Score both with the application baseline score and the opportunity expected value.
End with a label for the adjacent opportunity — build, partner, invest, monitor, wait, or avoid. If your memo treats quantum technology as one market, rewrite it: that is the category error this chapter exists to prevent.
Check your understanding
Without notes: compare a quantum sensing opportunity with a quantum computing opportunity by buyer, evidence type, and timeline.
A passing answer separates the two categories cleanly, names a classical instrument baseline for the sensor, weighs field evidence over lab results, and states explicitly that progress in one category proves nothing about the other.
Oral defense: explain to a quantum-computing-focused investor why a sensor company might be the better near-term bet — and why that says nothing about their computing thesis either way.
If you get stuck
If the memo lacks a buyer workflow, an operational baseline, field evidence, or a clean separation from quantum computing, return to Chapter 64 (What Makes a Problem Quantum-Suitable?) for the baseline-first method. The instrument version of that discipline is this chapter's whole point.