Home / Glossary

Glossary

The terms a Veriqa brief uses, defined the way we use them.

Plain definitions for the terms a Veriqa brief uses — quantum, post-quantum cryptography, and decision-grade diligence vocabulary. Every term defined the way we use it in the engine.

Read the full methodology Request a brief

Jump to

01 · Cluster

Quantum claims.

The vocabulary you need to read a hardware roadmap, a sampling result, or a vendor advantage claim without getting talked past. Each term names a specific thing the engine looks for in the source.

CClassical baseline

The named comparator a quantum claim must out-perform on the same benchmark and problem size before reaching Proceed.

How we use it. Every advantage claim Veriqa reads is checked for a named classical algorithm running on a named classical machine on the same task at the same size. Missing the baseline is the single most common defect we see; it triggers the needs-baseline flag and blocks a Proceed verdict in code.

QQuantum advantage

A measured, benchmarked win over the best known classical method on a defined task; absent a baseline it is a marketing claim, not an advantage.

How we use it. The engine only treats "advantage" as graded evidence when the source names the task, the problem size, and the classical comparator. Without those three, the assertion is recorded as an assertion and the maturity score it would otherwise lift is capped.

LLogical qubit vs. physical qubit

The error-corrected logical qubit is the unit useful work is measured in; physical qubits are the noisy hardware substrate (typically thousands of physical per logical at current rates).

How we use it. When a vendor headline counts physical qubits, the engine looks for the implied logical-qubit count and the assumed error-correction overhead before scoring the claim. A roadmap denominated only in physical qubits cannot, on its own, support a useful-work claim.

Related: Fault tolerance · TRL

FFault tolerance

The regime where error-corrected logical operations run at usefully low error; large-scale fault tolerance is years away on public roadmaps.

How we use it. Claims that depend on fault-tolerant execution are graded against the public roadmap of the named hardware modality and the gap between today's physical error rates and the threshold the chosen code requires. A "we will need fault tolerance for this" admission is read as a timing signal, not a defect.

TTRL (Technology Readiness Level)

A 1–9 scale we use honestly to grade quantum sensing, PNT, and comms maturity on Defense & Dual-Use briefs.

How we use it. A TRL is pinned to the specific evidence that justifies it: a lab demonstration is TRL 3–4, a relevant-environment prototype is TRL 5–6, a fielded system is TRL 7–9. The engine flags any claimed level whose supporting evidence falls short of the level's definition; see also the standards-cluster entry below.

HHype-risk

One of the three scores in a brief; computed by a rule-based heuristic over hedging vs. superlative language, presence of benchmarks, baselines, dates, and named entities.

How we use it. Hype-risk rises with unbenchmarked "advantage" language, superlatives without sources, and missing comparators; it falls with precise scope, stated limitations, and claims that cite their evidence with confidence levels. Scoring is a transparent rule-based heuristic — not statistically validated, and not a probability of being wrong.

MMaturity score

A claim's readiness for production; capped by the absence of a classical baseline (needs-baseline → cannot reach Proceed).

How we use it. Maturity is raised by a named benchmark, a stated problem size, a present classical comparator, and reproducible or peer-reviewed results. It is lowered by toy-instance demonstrations and claims marked unverified, and it is capped when any core claim carries the needs-baseline flag.

UUrgency score

How time-sensitive the decision is; raised by the shelf-life of affected data and proximity of public-roadmap milestones.

How we use it. Urgency is about when, never about whether the science holds. It rises when an external clock is attached — a regulatory deadline, a harvest-now-decrypt-later exposure window, or a near-term roadmap milestone — and falls for speculative timelines with no clock at all.

Related: Data shelf-life · HNDL

02 · Cluster

Post-quantum cryptography (PQC).

The minimum vocabulary for a CISO conversation: the threat model that sets the clock, the three finalised NIST standards, and the design property — crypto-agility — that decides whether the next migration is cheaper than this one.

HNDL / Harvest-now-decrypt-later

An adversary captures ciphertext now and decrypts it later, once a sufficiently capable quantum computer exists; the central reason data shelf-life governs the PQC migration timeline.

How we use it. Veriqa's PQC plan prioritises assets by the product of their data shelf-life and their current key-exchange exposure. Long-lived secrets protected by classical key exchange are P1 by construction — the breach window opened the day they hit the wire.

NNIST FIPS 203 (ML-KEM)

The standardised key-encapsulation mechanism (Module-Lattice-based, derived from CRYSTALS-Kyber). Use it to replace RSA/ECDH key exchange in TLS, IPsec, SSH.

How we use it. Any RSA, DH or ECDH key-exchange entry in an inventory is mapped to ML-KEM as its NIST target. The agent records the source algorithm, the target, and the protocol context (TLS, IPsec, SSH) so the plan can be reviewed line by line.

NIST FIPS 204 (ML-DSA)

The standardised digital signature scheme (Module-Lattice-based, derived from CRYSTALS-Dilithium). Use it for code signing, document signing, and X.509 certificates.

How we use it. ECDSA, RSA-PSS and DSA signing entries are mapped to ML-DSA as the NIST target. The plan separates PKI and certificate lifecycles from one-off signing surfaces, because the migration shape — and the audit trail — differs.

NIST FIPS 205 (SLH-DSA)

The standardised stateless hash-based signature scheme (derived from SPHINCS+). A conservative, lattice-independent fallback signature.

How we use it. SLH-DSA is recommended where signature longevity matters more than signature size — firmware signing, root-of-trust, long-lived document signing — and as a lattice-independent fallback in any environment that does not want to bet a whole signing estate on a single mathematical assumption.

Crypto-agility

System design that can swap cryptographic primitives (e.g. RSA → ML-KEM) without re-architecture.

How we use it. Veriqa's PQC plan grades inventory by crypto-agility readiness — whether algorithms are negotiated, configurable, and isolated behind a clean interface, or hard-coded throughout the stack. Crypto-agility is the durable outcome the migration aims at; without it, the next standards revision is a second full project.

DData shelf-life

How long the protected data must remain confidential; the primary input to HNDL prioritisation.

How we use it. Shelf-life is captured per inventory entry — five years, ten years, "lifetime of the patient" — and combined with the asset's current exposure to set its phase in the migration plan. The plan treats a five-to-ten-year shelf-life as the threshold at which classical key exchange is already a liability.

Related: HNDL · Urgency score

03 · Cluster

Standards & frameworks.

Public standards Veriqa maps to rather than reinvents. Where an external standard exists, the engine uses it; where it does not, the engine names its own rule and writes it down.

NIST PQC standardisation

The multi-round NIST process culminating in FIPS 203/204/205 in August 2024.

How we use it. PQC migration plans target the finalised standards by name — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) — rather than a generic "post-quantum" label. The standards' publication date is what moves the conversation from "research topic" to "compliance clock".

Related: FIPS 203 · FIPS 204 · FIPS 205

TRL (1–9), with verdict mapping

The 1–9 readiness scale, used honestly: a TRL is pinned to the evidence that justifies it, and unsupported levels are flagged.

How we use it. As a rough mapping into Veriqa's three-verdict vocabulary on quantum-sensing, PNT and comms briefs: TRL 7–9 with a present classical baseline supports a Proceed verdict; TRL 5–6 typically lands on Monitor; TRL 1–4, or any level whose evidence is missing, lands on Require further diligence. The mapping is a default heuristic, not a guarantee — the rest of the evidence still has to hold.

04 · Cluster

Diligence vocabulary.

The terms a Veriqa report uses to describe its own verdicts, flags, and workflow gates. These are product requirements enforced in the engine, not adjectives.

PProceed / Monitor / Require further diligence

Veriqa's three-verdict vocabulary; Proceed is blocked in software while any core advantage claim lacks a baseline.

How we use it. Every brief lands on one of these three. Proceed means the graded evidence supports moving forward on the named claim. Monitor means the evidence is mixed or early and the decision is to track, not act. Require further diligence means the evidence is insufficient and the named next steps are listed.

Needs-baseline flag

The engine marks any advantage claim without a named benchmark, a problem size, and a classical comparator; needs-baseline cannot raise the maturity verdict.

How we use it. The flag is set automatically when any of the three required elements is missing. While it is set, the maturity score is capped and a Proceed verdict is blocked in code — the report still ships, as a Monitor or Require-further-diligence call, never as a green light.

EEvidence confidence (0–1)

How strongly the cited source supports the sub-claim; NOT a probability the claim is true.

How we use it. A confidence of 0.9 means the source backs the sub-claim well. It degrades with the quality of the source, not with optimism: an undated whitepaper or a press release carries lower confidence than a peer-reviewed result with a method section, regardless of how the claim is phrased. Uncitable claims are marked unverified and cannot raise the verdict.

Related: Claim discipline · Hype-risk

RReviewer gate

The software-enforced workflow gate that holds every customer-facing report in draft until an internal reviewer approves it against a written credential standard.

How we use it. The gate is enforced in code — a report cannot be released around it — and the reviewer's approval is logged against the exact version it signed off. The credential standard for any reviewer we engage is written down (graduate degree in quantum information, physics, or applied cryptography, or equivalent hands-on grading experience). We do not represent that an independent outside expert reviews every report; for high-stakes decisions we recommend independent expert review on your side as well.

Claim discipline

The five product-requirement rules the engine enforces: named baseline, classical comparator, illustrative labelling, citations, reviewer gate.

How we use it. These are not marketing principles. They are product requirements applied uniformly to every input and enforced in code — the API blocks a Proceed verdict while any core claim is needs-baseline, illustrative figures are labelled, and the reviewer gate holds every report in draft until approved. See /science and /about#charter.

Read the method, then bring us a claim.

The full pipeline — claim extraction, the classical-baseline gate, the three scores, the evidence table, and the reviewer gate — is documented end to end. Then send the company, paper, roadmap, or cryptographic inventory you actually have to grade.

Read the full methodology Request a brief