A committable artifact for quantum exposure. SBOM-shaped, JSON-strict.

QXM is the JSON artifact produced by npx pqcheck lock — a snapshot of a domain's HNDL exposure stable enough to commit alongside source code. This page documents the schema, the classification logic, what fields are stable across versions, and how QXM relates to SBOM / CycloneDX.

What QXM is

A QXM file (cipherwake.lock) is a JSON document. Like package-lock.json or Cargo.lock, it captures the result of an exposure check at a moment in time. Like an SBOM, it is portable across tools and intended to be consumed by CI / supply-chain analyzers.

The companion file (cipherwake-report.md) is a human-readable Markdown rendering of the same data, suitable for PR descriptions or README inclusion.

Legacy filename: earlier versions wrote quantapact.lock + quantapact-report.md under the project's former name. The CLI accepts both filenames forever and preserves whichever already exists in your repo — no migration needed.

The schema is published at cipherwake.io/schemas/qxm/v1 and is open. Anyone can produce a conforming QXM from their own tooling; we will treat such files as first-class inputs in future Cipherwake features.

What QXM contains

The schema v1 fields:

{
  "$schema": "https://cipherwake.io/schemas/qxm/v1",
  "version": "1.0",
  "domain": "example.com",
  "scannedAt": "2026-05-08T13:42:00Z",
  "tool": { "name": "pqcheck", "version": "0.5.0" },
  "score": { "value": 4.3, "grade": "C", "label": "Moderate" },
  "components": {
    "keyExchange": 5.5,
    "certLifetime": 3.2,
    "keyPersistence": 6.0,
    "subdomainScale": 2.8
  },
  "findings": [
    {
      "id": "rsa-fallback-accepted",
      "severity": "high",
      "title": "RSA-only handshake accepted",
      "evidence": { "cipherProbe": "ephemeral-preferred-rsa-fallback" },
      "classification": "join-waitlist"
    }
  ],
  "asm": { "spf": "ok", "dmarc": "p=none", "hsts": "missing", ... },
  "certs": { "currentLifetime": 89, "longestKeyReuse": 1095 },
  "subdomains": { "observed": 14, "wildcardPresent": false }
}

Classification logic

Each finding is tagged with a classification describing the recommended action class. Current values:

• monitor — informational; no immediate action implied.
• investigate — likely benign but worth verification (e.g. cert anomaly during a known migration).
• review-config — adjustable in the customer's TLS config (e.g. disable RSA-only fallback).
• join-waitlist — points to Tessera SDK as the eventual fix path. Used when the underlying issue is a key-exchange architecture choice that benefits from a PQC handshake library.

Important: we do not use fix-with-tessera as a classification today — Tessera SDK is not yet shipped, and recommending a tool that does not exist is misleading. The placeholder is join-waitlist until the SDK is generally available.

How it scores

QXM does not introduce its own scoring; it is a faithful serialization of a Cipherwake scan. The score, grade, and component values match the values published in the scan's DBR computation.

One CI-relevant convention: a QXM with any finding of severity: critical should fail a CI lint by default. npx pqcheck lock --fail-on critical exits non-zero; --fail-on high tightens the bar.

Relationship to SBOM / CycloneDX

QXM is intentionally narrower than a full SBOM. SBOMs catalog every dependency; QXM catalogs the public quantum-decryption exposure of one domain. They are complementary, not redundant:

• An SBOM tells you which crypto library is in your build.
• A QXM tells you what an attacker observes when they handshake with your live endpoint.

A future schema revision may emit QXM-as-CycloneDX-component for direct embedding into existing SBOM pipelines, but v1 is standalone JSON.

What QXM does NOT claim

• It does not certify compliance. A QXM is not a HIPAA / PCI / SOX / CMMC artifact. It is engineering data.
• It does not snapshot code. Unlike an SBOM, it does not list libraries, dependencies, or versions. A repo with a perfect QXM and a vulnerable npm dependency is still vulnerable — different scope.
• It is not signed. QXM v1 is not cryptographically signed. Signed-attestation support (Sigstore-style) is a v2 candidate, not present today.
• It is point-in-time. A QXM committed today does not protect against a regression next week. Re-run on a CI cadence.
• It does not include private endpoints. Internal services not exposed to the public internet are out of scope by construction.

Schema stability + versioning

• Stable fields (v1): $schema, version, domain, scannedAt, score.value, score.grade, findings[].id, findings[].severity. Anything machine-consuming should rely on these.
• May change in minor revisions: finding-specific evidence fields, classification taxonomy (additions only — existing values will not be removed in the v1 line).
• Deprecation policy: a v2 schema will publish at /schemas/qxm/v2 with a 12-month overlap period during which both are produced.

Try it

• npx pqcheck lock example.com — generates cipherwake.lock + cipherwake-report.md in the current directory.
• CI gate: npx pqcheck lock example.com --fail-on high exits non-zero on a high-severity finding.
• Schema: cipherwake.io/schemas/qxm/v1