# Bee post-quantum coverage matrix

**Document class:** Public claims register · Trust & Evidence · self-verifying control plane
**Applies to:** Bee — The Progressive Intelligence Engine (bee.heossi.com), operated by HEOSSI (Pte.) Ltd., Singapore, UEN 202532790K
**Version:** 0.9.9 (pre-publication draft — becomes v1.0 when all publication gates in §12 are closed)
**Date:** 2026-07-07
**Canonical register:** this document is a rendering of the signed machine-readable register (canonical hash `sha384:52d3e76d287fea787aaa51be7cb45c9eb080e489096b2d9efe8dbb748cb518a8648a7553656b03ff596e96670ce8366e`) — it is generated, never hand-edited. Verify the register with the published validator before trusting this rendering.

---

## 1. The claim

> **Bee provides post-quantum protection across its stored-data lifecycle and every transport hop between Bee clients and the Bee platform — with the exact scope published in this register, every covered mechanism continuously probed in production, and independent verification available to anyone.**

This register exists so that the claim above can be audited rather than trusted — and so that it *cannot silently rot*: every Covered row is bound to a scheduled production probe (§9) whose failure automatically downgrades the row and re-signs the register. Every data flow in the Bee platform is enumerated in §5 with one of three statuses — **Covered**, **Partial**, or **Excluded** — together with the protecting mechanism, the key holder, the tiers it applies to, its probe, and a link to live evidence. Exclusions are stated as plainly as coverage.

What the claim deliberately does **not** say:

- It does not say "quantum LLM." Bee's explicit, add-on quantum-compute path is separate from model inference and is not part of this security claim.
- It does not say "everything, everywhere." §6 lists the flows that are out of scope today, why, and — where applicable — the phase that closes them.
- It does not assert the post-quantum posture of third-party subprocessors or of customer-controlled devices.

## 2. Definitions

**Post-quantum protected (transport):** the connection negotiates a hybrid key exchange combining X25519 with ML-KEM-768 (FIPS 203) or stronger, such that recorded traffic is not decryptable by a future cryptographically relevant quantum computer (CRQC) even if the classical component fails. Hybrid negotiation requires client-side support; the enforcement column of §3 states, per profile, whether classical fallback is permitted (`prefer`) or rejected (`require`).

**Post-quantum protected (at rest):** the data is encrypted with AES-256-GCM under a per-object data-encryption key (DEK), and every key that protects that DEK — up to and including the tenant key-encryption key (KEK) held in QNSI KMS — is wrapped using ML-KEM (FIPS 203). No RSA or classical elliptic-curve key exchange appears anywhere in the wrap chain. AES-256 itself retains 128-bit effective security against Grover-type attacks and is the CNSA 2.0 symmetric baseline.

**Post-quantum provenance:** the record (audit event, inference receipt, migration attestation) carries an ML-DSA (FIPS 204) signature and is anchored into a Merkle-tree ledger whose checkpoints are ML-DSA-signed. Receipt content commitments are salted per-tenant HMACs, never bare hashes.

**Post-quantum integrity:** the artifact (model weights, LoRA adapter, system prompt, MCP manifest, release binary) is ML-DSA-signed and verified before load or install; long-horizon release roots use SLH-DSA (FIPS 205) on commercial profiles and the SP 800-208 stateful hash-based track (LMS) on the government profile.

**Key holder — platform:** HEOSSI operates the key in QNSI KMS under Bee's platform credential, scoped per tenant.
**Key holder — customer:** the customer operates the key in their own QNSI tenant (BYOK). While Bee serves the tenant it holds a customer-revocable wrap/unwrap entitlement — inference requires decryption — and the guarantee is that the customer can revoke or destroy the key unilaterally at any moment, after which the data is unreadable to HEOSSI, including support and backups, with no recovery path.

**Probe:** a scheduled or event-driven production check, defined in §9, that verifies a row's mechanism against deployed reality rather than against documentation. A failed probe auto-downgrades its rows; a probe that cannot measure reports `inconclusive`, which pages the operator and never downgrades.

**Crypto-agility RTO:** the measured time to re-wrap the entire estate of tenant key material under a replacement KEM following a deprecation or break of a deployed algorithm. Because the quantum-dependent operation exists only on ~32-byte key wraps — never on the data itself — algorithm replacement is a metadata-scale operation using the same machinery as BYOK migration. See §10.

**CRQC threat model:** harvest-now-decrypt-later (HNDL) adversaries recording ciphertext today for future decryption. LLM conversation logs, memory, and retrieval corpora are long-lived, high-sensitivity data and are treated as priority HNDL targets throughout this register.

## 3. Cryptographic profiles by tier

Crypto posture escalates with the Bee tier and is enforced by the QNSI policy engine at key-creation time — a request below the tier's floor is rejected by the platform, not discouraged by documentation.

| Profile | Bee tiers | Key establishment floor | Signature floor | Transport | Enforcement | Release root | Notes |
|---|---|---|---|---|---|---|---|
| default | Cell | ML-KEM-768 | ML-DSA-65 | Hybrid X25519 + ML-KEM-768 | prefer | SLH-DSA | Platform baseline. Classical fallback permitted for clients without ML-KEM support; negotiated-group rates measured and published via P-01. |
| strict | Brood, Comb, Buzz | ML-KEM-768 | ML-DSA-65 | Hybrid X25519 + ML-KEM-768 | prefer | SLH-DSA | Signed audit mandatory. |
| maximum | Hive, Swarm, Enclave (regulated_cloud — planned) | ML-KEM-1024 | ML-DSA-87 | Hybrid X25519 + ML-KEM, ML-KEM-1024 preferred | prefer | SLH-DSA | BYOK available; signed inference receipts; tenant may opt into transport_enforcement=require on dedicated endpoints. The Enclave regulated_cloud variant maps here deliberately: a mid-market regulated-cloud tier gets ML-KEM-1024 floors and BYOK without inheriting require-enforcement (which would reject legacy corporate clients) or CNSA 2.0 obligations sized for NSS-adjacent procurement. regulated_cloud is a planned tier (goes live with the marketing-site refresh); its mapping here is target-state and must not appear in v1.0 marketing prose until the tier is live. |
| government | Enclave (private), Enclave (regulated), Enclave (sovereign) | ML-KEM-1024 | ML-DSA-87 | Hybrid X25519 + ML-KEM-1024 | require | LMS | AES-256 / SHA-384 baseline; classical-only handshakes rejected; endpoint TLS cipher policy pins TLS_AES_256_GCM_SHA384 (shared endpoints currently negotiate AES-128-GCM, which satisfies hybrid confidentiality on prefer-profiles but not this profile's symmetric baseline — a concrete server-configuration item verified by P-01 on require-enforcement endpoints); FIPS 140-3 module path (AWS-LC-FIPS, whose validation includes ML-KEM); SLH-DSA not used on this profile, consistent with CNSA 2.0. ML-KEM-768 / ML-DSA-65 are appropriate civilian defaults and are NOT CNSA 2.0 compliant; CNSA 2.0 names ML-KEM-1024 and ML-DSA-87. |

Parameter-set note: ML-KEM-768 / ML-DSA-65 are appropriate civilian defaults (aligned with, e.g., UK NCSC guidance) but are **not** CNSA 2.0 compliant. CNSA 2.0 names ML-KEM-1024 and ML-DSA-87 specifically. Buyers with NSS-adjacent obligations must use the government profile.

Naming note: all public identifiers use final FIPS nomenclature (ML-KEM-768, not "kyber-768"). FIPS 203 conformance — including final parameter encoding and OIDs — is asserted only after publication gate PG-4 is closed; round-3 CRYSTALS-Kyber equivalence is not treated as compliance. Deployed algorithm reality is diffed against this section on every release via the published CBOM (probe P-07).

## 4. Reading the matrix

- **Covered** — the mechanism is live for the stated tiers, evidence is linked, and the row is bound to a production probe.
- **Partial** — a defined subset is protected; the unprotected remainder and its closure path are stated in the same row. Partial is a precise engineering status, not a hedge. Probes for Partial rows activate when the row's gate closes.
- **Excluded** — outside the claim. The reason is stated; where a closure exists on the roadmap, the phase is named. Permanent exclusions are boundary statements — honesty about the boundary is the point of this register.
- **Effective** — the build phase (A–D, per the integration plan) at which the row's status holds, with the row's publication gate where one applies. Later-phase rows are roadmap and are labeled as such wherever this claim is marketed.
- **Probe** — the P-ID from §9 continuously verifying the row. A row cannot carry Covered status without a probe.
- **Qualifiers** — honest constraints on a status, rendered with the row itself, never footnoted away. A qualifier bounds the claim; it does not soften it.

## 5. Coverage matrix

| # | Data flow | Status | Mechanism | Key holder | Tiers | Effective | Probe | Evidence |
|---|---|---|---|---|---|---|---|---|
| R-01 | Client-to-platform transit: workspace, OpenAI-compatible API, MCP, mobile | **Covered** | Hybrid PQC-TLS (X25519 + ML-KEM-768; ML-KEM-1024 on maximum/government) offered and preferred on every endpoint; government profile rejects classical-only handshakes.<br><br>*Qualifier:* Hybrid key exchange requires client-side support; sessions from clients or middleboxes without ML-KEM negotiate classical TLS on prefer-enforcement profiles. The guarantee on those profiles is server-side offer-and-prefer plus published negotiation rates — not per-session PQ. Per-session PQ is guaranteed only where transport_enforcement=require. | Platform | All | A | P-01 | Live PQC-TLS canary endpoint *(ships Phase A)*; [QNSI NIST ACVP conformance vectors](https://qnsi.heossi.com/verify/conformance); Negotiated-group telemetry (share of sessions completing hybrid PQ key exchange, by surface) *(ships Phase B)* |
| R-02 | Software update channels: desktop builds, SDK packages, CLI | **Covered** | Releases ML-DSA-signed with verify-on-install; SLH-DSA release root (commercial), LMS root (government profile); delivery over hybrid PQC-TLS. | Platform | All | B | P-02 | [Published release-signing keys and verification instructions](https://bee.heossi.com/trust) *(ships Phase B)* |
| R-03 | Internal service-to-service transit within the Bee platform boundary | **Partial** | Perimeter is PQC (R-01); internal hops run mutually authenticated TLS inside a private network; internal hybrid-PQC mTLS is the closure. | Platform | All | B (gate PG-1) | P-07 | Internal transit architecture note *(ships Phase B)* |
| R-04 | Conversations and persistent memory, at rest | **Covered** | AES-256-GCM per-object DEK, wrapped via ML-KEM to a per-tenant KEK in QNSI KMS; no RSA/ECDH anywhere in the wrap chain. | Platform (BYOK optional → customer) | All | B | P-03 | Key-hierarchy architecture note *(ships Phase B)*; [QNSI KMS conformance evidence](https://qnsi.heossi.com/verify/conformance) |
| R-05 | User uploads and RAG document store, at rest | **Covered** | Same envelope scheme as R-04; tenant isolation is cryptographic (distinct KEK per tenant), not only logical. | Platform (BYOK optional → customer) | All | B | P-03 | As R-04 *(ships Phase B)* |
| R-06 | Embeddings and vector index, at rest | **Covered** | Vectors and index segments encrypted under the tenant DEK scheme (SSE-X-backed on Buzz and above). | Platform (BYOK optional → customer) | All | B | P-03 | [SSE-X capability documentation](https://qnsi.heossi.com/capabilities) |
| R-07 | Embeddings and vector index, in memory during query execution | **Excluded** | Similarity search requires plaintext vectors in RAM at query time. Encrypted at rest, plaintext in memory during search. | — | n/a | D (roadmap) | — | [This register, published at the Bee trust page](https://bee.heossi.com/trust) |
| R-08 | Backups and snapshots | **Partial** | Backup sets encrypted; every backup key chain must terminate in ML-KEM-wrapped keys within the tenant KEK lineage (so BYOK crypto-shredding covers backups), with zero classical public-key wraps. Asserted as covered only after PG-2.<br><br>*Note:* Consequence stated plainly: because backup chains sit inside tenant KEK lineage, KEK destruction (R-15) renders backups unreadable too — restore-after-offboarding is cryptographically impossible, by design. Retention and legal-hold procedure (see R-15 notes) governs when destruction may execute. | Platform | All | B (gate PG-2) | P-03 | Backup key-chain audit result *(ships Phase B)* |
| R-09 | Logs and telemetry | **Partial** | Prompt and completion content scrubbed at source from operational logs; log stores encrypted under the platform envelope scheme; bounded retention. Operational metadata (timestamps, tier, token counts, latency) retained. | Platform | All | B (gate PG-3) | P-03 · P-10 | [Logging policy, Security Practices](https://bee.heossi.com/legal/security) |
| R-10a | Prompt / semantic caches, persisted to durable storage | **Covered** | Any cache written to durable storage falls under the R-04 envelope scheme. | Platform | All | B | P-03 | Architecture note *(ships Phase B)* |
| R-10b | Prompt / semantic caches, transient in-memory | **Excluded** | Transient in-memory caches carry the R-07/R-16 plaintext-in-memory exclusion. | — | n/a | D (roadmap) | — | [This register, published at the Bee trust page](https://bee.heossi.com/trust) |
| R-11 | Model weights, LoRA adapters, system prompts, tool and MCP manifests | **Covered** | ML-DSA-signed at build; the inference gateway verifies signatures at load and refuses unsigned artifacts; confidentiality at rest under the R-04 envelope. | Platform | All | B | P-04 | [Artifact-signing policy and public verification key](https://bee.heossi.com/trust) *(ships Phase B)* |
| R-12 | Audit records and per-response inference receipts | **Covered** | ML-DSA-signed event at response time (synchronous); at-least-once delivery via transactional outbox; anchored into ML-DSA-signed Merkle checkpoints. Receipt states: signed (immediate) and anchored (SLO: 99.9% within 5 minutes). Receipt content commitments are salted per-tenant HMACs, not bare hashes, so a low-entropy prompt cannot be confirmed by dictionary attack against a receipt; receipt identifiers are non-sequential and the public verifier is rate-limited and non-enumerable. Each receipt embeds the register version in force at issue time.<br><br>*Qualifier:* The 5-minute anchoring SLO is provisional: it has not yet been verified against the audit service's actual Merkle checkpoint cadence. PG-5 closure includes measuring the checkpoint interval; the SLO published at v1.0 is the measured, cadence-derived figure, and P-05 enforces whatever number is published. | Platform | Signed audit: Brood+; receipts: Swarm/Hive+ | B (gate PG-5) | P-05 | Public receipt-verification endpoint *(ships Phase B)*; [QNSI audit-ledger documentation](https://qnsi.heossi.com/platform) |
| R-13 | Platform secrets and agent/tool credentials | **Covered** | Held in QNSI Vault (ML-KEM-wrapped server-side), never in Bee's application database; scoped entitlements per service. | Platform | All | A | P-06 | [QNSI Vault documentation](https://qnsi.heossi.com/capabilities); Phase-A production proof (re-runnable) *(ships Phase A)* |
| R-14 | Key material and the wrap chain itself | **Covered** | All KEK/DEK wrapping via ML-KEM through QNSI KMS; documented entropy chain (NIST SP 800-90A/B/C); no quantum-vulnerable public-key algorithm anywhere in the chain. | Platform (BYOK optional → customer) | All | A | P-03 · P-07 | [QNSI entropy chain](https://qnsi.heossi.com/security/entropy); [QNSI algorithm catalog](https://qnsi.heossi.com/algorithms) |
| R-15 | BYOK migration and crypto-shredding | **Covered** | On upgrade, per-object DEKs are re-wrapped under the customer's QNSI KEK (data is never re-encrypted); the platform KEK is schedule-destroyed; an ML-DSA-signed migration attestation (key IDs, object counts, timestamps) enters the audit ledger. Offboarding: KEK destruction is cryptographic erasure, with signed destruction attestation covering primary stores and backups (R-08).<br><br>*Qualifier:* Custody semantics, stated precisely: while Bee serves the tenant, Bee holds a customer-revocable wrap/unwrap entitlement on the customer's KEK and can therefore decrypt tenant data in the course of providing the service — inference requires it. The guarantee is not that HEOSSI can never read the data; it is that the customer can revoke or destroy the key unilaterally at any moment, after which the data is unreadable to HEOSSI — including support, including backups — with no recovery path.<br><br>*Note:* Destruction executes only after the retention / legal-hold check in the offboarding runbook: destruction is blocked while a documented legal hold is active, and every destruction records the hold-check result in the attestation, so crypto-shredding is never spoliation. | Customer | Hive / Swarm / Enclave | C | P-09 | BYOK runbook (public architecture note) *(ships Phase C)*; Sample migration attestation *(ships Phase C)* |
| R-16 | Plaintext in host/GPU memory during inference | **Excluded** | Model execution operates on plaintext activations in RAM/VRAM, as with every production LLM today. Closure: Phase D confidential-compute inference (hardware enclaves) on Enclave deployments. | — | n/a | D (roadmap) | — | [This register, published at the Bee trust page](https://bee.heossi.com/trust) |
| R-17 | Host memory hygiene: swap, core dumps, crash reports | **Partial** | Inference and gateway hosts run with core dumps disabled, swap disabled or encrypted, and crash reports scrubbed of request content — so the R-16 in-memory exclusion cannot silently leak onto disk. Asserted as covered only after PG-6 host-hygiene audit.<br><br>*Note:* This row exists because plaintext-in-memory (R-16) is only an honest exclusion if memory never reaches persistent media through side channels. | Platform | All | B (gate PG-6) | P-07 | Host hardening baseline note *(ships Phase B)* |
| R-18 | Third-party model egress | **Excluded** | This claim applies to Bee-native model routes only. Any Bee surface proxying to an external model provider is labeled in-product and carries no post-quantum lifecycle claim. | — | n/a | Permanent | — | In-product route labeling *(ships Phase B)* |
| R-19 | Third-party subprocessors (billing, email, infrastructure providers) | **Excluded** | Bee does not assert the post-quantum posture of subprocessors. Current list maintained in the DPA; data shared with subprocessors is minimized per the Privacy Policy. | — | n/a | Permanent | — | [DPA subprocessor list](https://bee.heossi.com/legal/dpa) |
| R-20 | Customer-controlled surfaces: user devices, exported data, customer-side integrations | **Excluded** | Outside the platform boundary. Exports are delivered over PQC transport (R-01); protection after delivery is the customer's. | Customer | n/a | Permanent | — | [This register, published at the Bee trust page](https://bee.heossi.com/trust) |

## 6. Summary of exclusions

3 exclusions are permanent boundary statements (R-18, R-19, R-20): flows outside the platform's cryptographic authority. 3 are engineering exclusions with a named closure (R-07, R-10b, R-16), closed in Phase D; the closing mechanism is stated in each row. No other exclusions exist. If a reviewer identifies a data flow not enumerated here, it is treated as a defect in this register — report it to bee-security@heossi.com (RFC 9116: /.well-known/security.txt) and it will be added with an honest status.

## 7. Independent verification

This register maps to the QNSI vendor test for post-quantum claims (qnsi.heossi.com/pqc-theatre). Bee answers it on the record:

1. **Which algorithms and parameter sets, exactly?** §3 of this register, per tier — final FIPS nomenclature, with the CNSA 2.0 parameter distinction stated rather than blurred. Full algorithm inventory: qnsi.heossi.com/algorithms. Deployed reality is diffable against the claim via the published CycloneDX CBOM on every release.
2. **Can the cryptography be verified without trusting the vendor?** Yes, at four depths: NIST ACVP conformance vectors (qnsi.heossi.com/verify/conformance); the live public PQC sandbox (fresh operations per request, no canned output); the PQC-TLS canary with published negotiated-group telemetry; and — from Phase B — the public receipt-verification endpoint where anyone can validate a Bee inference receipt's ML-DSA signature and Merkle inclusion with no Bee account. The probe implementations in §9 are published, so a customer can run the same checks Bee runs against its own production — including the wrap-chain audit against their own data export, exhaustively.
3. **Where are the keys and who can use them?** §2 key-holder definitions, the row-by-row key-holder column, the per-tenant coverage endpoint (§11.1) showing each customer their own key custody in real time, and the BYOK path under which the customer can unilaterally revoke or destroy their key at any moment, rendering their data unreadable to HEOSSI with no recovery path.
4. **What is not covered?** §5 and §6. The exclusions are published in the same table as the coverage, at the same level of detail, including the plaintext-in-memory reality every production LLM shares.

Performance transparency: post-quantum overhead per completion is measured continuously by probe P-05 and published as rolling percentiles in the QNSI benchmarks format — a rounding error against multi-second inference, and stated so buyers do not have to take it on faith.

## 8. Register operations — claims as code

This document is a **rendering**, not the source of truth.

- **Canonical form:** the machine-readable register file (published schema per §11.4) in which every section of this document that carries a table is structured data: rows, profiles, probes, gates, changelog, governance. The file is ML-DSA-signed and carries the hash of its predecessor.
- **Canonicalization and signing:** UTF-8 JSON, lexicographically sorted keys, compact separators (',', ':'), hashed with SHA-384; the signature is computed over that canonical byte stream. The canonical hash of each version is anchored in the QNSI audit ledger together with the predecessor hash, forming the version chain.
- **Detached signature envelope:** Signatures are detached — a file cannot contain a signature over itself. Each signed version publishes bee-pq-register.v<version>.sig.json alongside the register, conforming to the signature-envelope schema (signature-envelope.schema.json): register version, canonical register hash, algorithm, signer role (offline-root or online-downgrade), key ID, public-key fingerprint, ML-DSA signature over the ASCII bytes of the register hash, timestamp, and the hash of the predecessor envelope. The online-downgrade authority limit is enforced mechanically, not by prose: the validator's --predecessor mode diffs an online-downgrade version against its hash-bound predecessor under the predecessor's downgrade_diff_policy, and without a passing diff an online-downgrade envelope cannot produce a clean VALID; the signer applies the identical check before signing.
- **Verification key publication and pinning:** The ML-DSA verification keys (root and downgrade) are published at bee.heossi.com/trust/keys and pinned across three independent surfaces: the QNSI audit ledger (fingerprint anchored at the key ceremony), the github.com/heossihq public mirror, and the rendered register document itself. A verifier checks the key fingerprint against at least two surfaces before trusting a signature; key rotation publishes a rotation attestation signed by the outgoing root.
- **Key custody:** The register root key is an offline ML-DSA key held outside CI and outside the production credential plane; it signs only (a) new register versions prepared by a human and (b) the delegation certificate of the online downgrade signer. The online downgrade signer, held in QNSI KMS with a scoped entitlement, may sign only version increments whose diff is limited to status downgrades and probe notes — it cannot sign upgrades, mechanism changes, or claim changes. CI compromise therefore cannot mint an improved register; at worst it can trigger a visible, audit-logged downgrade.
- **Rendered surfaces:** this document, the bee.heossi.com/trust web page, and the security-review packet are all generated from the canonical file by the published renderer. None is hand-edited; divergence between surfaces is therefore structurally impossible. The renderer refuses to render a register that fails validation.
- **CI enforcement:** the Bee release pipeline diffs each release against the register. A change that alters cryptographic behavior — algorithm identifiers, wrap-chain structure, signing keys, transport groups — without a corresponding signed register change **fails the build**. The register is a gate, not a bystander.
- **Public availability:** the current signed canonical file, the schema, the validator, and the renderer are retrievable at the coverage endpoint (§11.1), so third parties verify the signature over the canonical hash and consume the register programmatically rather than scraping prose.

## 9. Continuous verification — probes and auto-downgrade

### 9.1 Probe specifications

| Probe | Verifies | Method | Cadence |
|---|---|---|---|
| P-01 | R-01 | Connect to the public canary on each surface; assert the negotiated key-exchange group is hybrid X25519+ML-KEM at or above the profile floor; on require-enforcement endpoints, assert a classical-only handshake is rejected and the negotiated cipher suite is TLS_AES_256_GCM_SHA384. Additionally aggregate production negotiated-group telemetry and publish the hybrid-completion rate per surface. | Hourly (canary); daily (telemetry aggregation) |
| P-02 | R-02 | Fetch the latest published release artifact per channel; verify its ML-DSA signature against the published key; verify the root chain (SLH-DSA commercial, LMS government). | Per release + daily |
| P-03 | R-04 · R-05 · R-06 · R-08 · R-09 · R-10a · R-14 | Sample N wrapped-DEK records per store from production; parse each wrap chain; assert every wrap is ML-KEM at or above the tenant's profile floor and zero classical public-key OIDs appear anywhere in the chain.<br><br>*Detection strength:* Statistical sampling: provides high-probability detection of systemic misconfiguration, not exhaustive proof over every record. Sample size and store coverage are published with the probe implementation; customers can run the identical check exhaustively against their own data export. | Daily |
| P-04 | R-11 | Select a random deployed model/adapter/manifest; verify its ML-DSA signature. Confirm the gateway's verify-at-load rejection path with a deliberately unsigned test artifact in staging. | Daily |
| P-05 | R-12 | Submit a synthetic inference on a canary tenant; verify the receipt reaches signed immediately and anchored within SLO via the public verifier endpoint; record end-to-end latency percentiles for the published performance figures. | Every 15 minutes |
| P-06 | R-13 | Schema scan asserting zero secrets present in the application database; confirm each service credential resolves only through its scoped QNSI Vault entitlement. | Daily |
| P-07 | R-03 · R-14 · R-17 | Export the CycloneDX CBOM from QNSI crypto-inventory; diff against the register's profiles and flag any deployed algorithm, parameter set, or identifier not matching the claim; include host-hardening configuration assertions (core dumps, swap) in the per-release configuration diff. | Per release + weekly |
| P-08 | R-01 · R-02 · R-04 · R-09 · R-12 · R-13 · R-14 · R-19 | Resolve every evidence URL in the canonical register with ships=live; fail on any dead or changed-beyond-tolerance link. Meta-probe: it verifies the register's evidence infrastructure across rows, not any row's protecting mechanism, so rows do not bind to it. Automates gate PG-7 permanently after v1.0. | Daily |
| P-09 | R-15 | On every migration and destruction event: verify the signed attestation's ML-DSA signature, ledger inclusion, object-count consistency against the tenant store, and the recorded legal-hold check result. | Event-driven |
| P-10 | R-09 | Submit a synthetic inference on a canary tenant whose prompt and completion contain a unique high-entropy marker token; after the logging pipeline's flush interval, scan all operational log stores and shipped log destinations for the marker; fail if the marker appears anywhere outside the encrypted conversation store. Converts the one-time PG-3 scrubbing audit into continuous regression detection — a scrub regression auto-downgrades R-09 instead of surviving silently. | Daily |

Probe implementations are published alongside the register so customers and auditors can execute the identical checks independently.

### 9.2 Probe semantics

- **States:** pass · fail · inconclusive.
- **Downgrade trigger:** Two consecutive confirmed fails (one confirmed fail for P-05) downgrade every row the probe verifies to partial, re-sign the register via the online downgrade signer, record the event in the audit ledger, and page the operator.
- **Inconclusive handling:** inconclusive means the probe could not measure (probe error, network fault, dependency outage) — it pages the operator and never downgrades a row. Only confirmed mechanism failure downgrades. This prevents probe-infrastructure faults, or deliberate denial-of-service against probe targets, from forcing public downgrades.
- **Restoration:** Return to covered requires the probe passing again AND a signed register change via the offline root — the online downgrade signer cannot restore status.

The register therefore tracks production reality mechanically — it cannot overstate coverage through neglect, and the human commitment in §13 becomes the fallback, not the mechanism.

## 10. Crypto-agility — the re-wrap RTO

Post-quantum algorithms are themselves young; a credible register must answer "what if ML-KEM falls?" with a benchmark, not reassurance.

Because no data is ever encrypted directly under a quantum-dependent algorithm — only ~32-byte DEK wraps are — replacing a deprecated KEM across the entire estate is a re-wrap of key material using the same machinery as BYOK migration: unwrap under the outgoing KEK, re-wrap under a replacement-algorithm KEK, at metadata scale, with the data untouched.

- **Commitment:** full-estate re-wrap RTO target of ≤ 24 hours from decision to completion, per deployed region.
- **Evidence:** an annual re-wrap drill executed against production-scale key volume on a canary population; the measured figure is published in the QNSI benchmarks format and referenced here after the first drill. The published number is always a measured drill result, never a projection.
- **Algorithm diversity:** QNSI's multi-family catalog (lattice, code-based, hash-based) means the replacement target for a lattice deprecation already exists in the platform, and the government profile's LMS signing track is deliberately non-lattice.

## 11. Capability surfaces

### 11.1 Per-tenant coverage endpoint

From Phase C: `GET /v1/trust/coverage` returns the current signed canonical register (public, unauthenticated). `GET /v1/trust/coverage/tenant` (authenticated) returns the register **instantiated for the calling tenant**: their crypto profile and enforced parameter floor, their key holder per row (platform KEK ID or their own QNSI KEK ID), last KEK rotation timestamp, live receipt/anchoring statistics against SLO, probe status summary, and — where applicable — their BYOK migration attestation. The same view renders as a workspace dashboard panel and exports as the tenant's evidence pack.

### 11.2 Policy-versioned receipts

Every inference receipt embeds the canonical register version in force at issue time. A receipt therefore proves not only *what* was produced and *when*, but *which published security regime governed it* — auditable retroactively against this register's signed version history even years later.

### 11.3 Compliance framework cross-mapping

Each canonical register row carries a controls field mapping the mechanism to the control families it evidences — SOC 2, ISO/IEC 27001:2022 Annex A, PDPA, and the MAS TRM guidelines — inheriting QNSI's published seven-framework compliance mapping (qnsi.heossi.com/security/compliance). The register thereby doubles as the cryptography-control evidence index for Bee's own ISO 27001 track and planned SOC 2 Type II.

### 11.4 Open specification

The register's schema is published as an open specification — a reporting format any AI vendor can complete for their own product — released alongside the QNSI vendor test at v1.0. Bee's register is the reference implementation. The specification requires published, third-party-executable probes for every covered row: a register cannot be satisfied on paper. Vendors who adopt it expose their exclusions at the same resolution as ours; vendors who decline concede the verifiability ground.

## 12. Publication gates (0.9.9 → v1.0)

This register is published as v1.0 — and the §1 claim is marketed — only when every gate below is closed. Each closure is recorded in the audit ledger.

| Gate | What must be verified | Owner action | Automated by |
|---|---|---|---|
| PG-1 | Internal service-to-service transit inventoried; R-03 status confirmed against the deployed network path (or upgraded to covered if internal hybrid-PQC mTLS ships first). | Network path audit | — |
| PG-2 | Backup and snapshot key chains audited end-to-end: zero RSA/ECDH wraps; chains terminate in ML-KEM-wrapped keys within tenant KEK lineage. | Backup key-chain audit | — |
| PG-3 | Log-scrubbing verified against production log samples: no prompt/completion content in operational logs; retention limits enforced. | Log audit | — |
| PG-4 | FIPS 203 final conformance of the deployed KEM confirmed (parameter encoding and OIDs, not round-3 Kyber); all public identifiers renamed to ML-KEM-*; CI lint rejects 'kyber' in customer-facing strings. | Library conformance check + rename | P-07 |
| PG-5 | Public receipt-verification endpoint live with salted commitments, non-enumerable identifiers, and rate limiting; a third party can verify a receipt with no Bee account. | Ship verifier endpoint | P-05 |
| PG-6 | Host memory hygiene audited: core dumps disabled, swap disabled or encrypted, crash reports scrubbed of request content on all inference and gateway hosts. | Host hardening audit | P-07 |
| PG-7 | Every evidence link marked ships=live resolves to live content; thereafter enforced permanently by P-08. | Link audit | P-08 |
| PG-8 | Canonical register live with CI gate enforced (release diffs against register; crypto-behavior changes without a signed register change fail the build); probe suite P-01 through P-08 deployed and green for 7 consecutive days; signing custody (offline root + limited online downgrade signer) operational. | Claims-as-code + probe rollout + key ceremony | — |

## 13. Governance and change control

- **Disclosure policy:** internal downgrade is immediate; the public register is updated within 72 hours. If publishing failure detail would materially aid active exploitation, the public register entry states that the row is downgraded and under security review without the exploit-enabling detail; the full detail is published when remediation lands. The downgrade itself is never delayed or suppressed, and the internal audit-ledger record is complete from the moment of detection.
- **Legal scope:** This register is a factual statement of cryptographic scope at the signed version and date, not a warranty of future state. It takes precedence over all marketing language: no HEOSSI marketing claim about Bee's post-quantum posture may exceed the claim sentence and row statuses of the then-current signed version. Customer contracts referencing post-quantum coverage pin a specific register version by hash. Statuses change over time under the change-control rules herein; the version history is the record.
- **Chain policy:** The canonical hash chain begins at 0.9.2, the first version to exist in canonical JSON form; 0.9.0 and 0.9.1 were prose drafts and are recorded in the changelog only, without hashes. ML-DSA signatures begin at the PG-8 key ceremony: every version from the ceremony onward carries a detached signature envelope; 0.9.x versions before the ceremony are hash-chained but unsigned drafts.
- The canonical register file is the versioned artifact; each version carries an ML-DSA signature and the hash of its predecessor, forming a verifiable history anchored in the QNSI audit ledger.
- Any status change, algorithm change, key-holder change, probe change, or controls-mapping change increments the version and is announced in the Bee changelog (bee.heossi.com/changelog). Auto-downgrades are version increments like any other, flagged as probe-initiated.
- The register is reviewed at every phase boundary (A→B→C→D) and at minimum quarterly.
- Discrepancy handling: probe-detectable divergence downgrades automatically per §9.2. For divergence outside probe coverage, a Covered row is downgraded within 5 business days of confirmation — the register tracks reality, never the other way around.

### Register changelog

| Version | Date | Changes |
|---|---|---|
| 0.9.0 | 2026-07-07 | Initial pre-publication draft: claim, definitions, profiles, coverage matrix, vendor-test answers, publication gates. |
| 0.9.1 | 2026-07-07 | Register upgraded to a control plane: claims-as-code canonical form with CI enforcement; probe suite with auto-downgrade; crypto-agility re-wrap RTO commitment; per-tenant coverage endpoint, policy-versioned receipts, compliance cross-mapping, open specification. |
| 0.9.2 | 2026-07-07 | Risk hardening. R-01: transport claim made negotiation-honest — per-session PQ guaranteed only under require-enforcement; prefer-profiles publish negotiated-group rates (P-01 extended).<br>R-15: custody semantics corrected — Bee holds a customer-revocable wrap/unwrap entitlement while serving; the guarantee is unilateral revocation/destruction, not that HEOSSI can never read. Legal-hold check added before destruction; attestation records it.<br>R-12: receipt commitments changed to salted per-tenant HMACs; non-sequential receipt identifiers; rate-limited, non-enumerable public verifier.<br>New R-17: host memory hygiene (swap, core dumps, crash reports) with gate PG-6, so the in-memory exclusion cannot leak to disk unstated.<br>R-08: backup chains bound into tenant KEK lineage so crypto-shredding verifiably covers backups; restore-after-offboarding impossibility stated.<br>Probe semantics: third state 'inconclusive' added — probe faults and probe-DoS page the operator but never downgrade; restoration requires the offline root.<br>meta: disclosure policy (immediate internal downgrade, public within 72h, exploitation-detail exception), legal scope (register precedence over marketing, contract version-pinning), and signing key custody (offline root; online signer limited to downgrades) added.<br>Row 10 split into R-10a (persisted, covered) and R-10b (transient, excluded) for machine consumption. |
| 0.9.3 | 2026-07-07 | Independent review response. Detached signature envelope defined: signature-envelope.schema.json, filename convention bee-pq-register.v<version>.sig.json, signer roles (offline-root / online-downgrade), and public-key publication pinned across three surfaces (bee.heossi.com/trust/keys, QNSI audit ledger, github.com/heossihq) — closing the gap that a verifier had no artifact to verify with.<br>Enclave family variants enumerated: private/regulated/sovereign remain on the government profile; the planned regulated_cloud variant maps to the maximum profile so a mid-market cloud tier does not inherit require-enforcement or CNSA 2.0 procurement obligations.<br>Hash chain contradiction resolved: chain_policy added; the canonical chain begins at 0.9.2 (first canonical-JSON version, hash sha384:f96fdd5b…), 0.9.0–0.9.1 were prose drafts recorded in changelog only; signatures begin at the PG-8 key ceremony. predecessor_hash of this version is 0.9.2's verified hash.<br>New probe P-10: synthetic marker-token regression test for log scrubbing, binding R-09 — a scrub regression now auto-downgrades instead of surviving the one-time PG-3 audit.<br>P-08 reclassified as a meta-probe (scope field added to the specification): it verifies register evidence infrastructure, not row mechanisms, resolving the one-way binding.<br>Government profile: endpoint cipher policy pinned to TLS_AES_256_GCM_SHA384 and added to P-01 assertions on require-enforcement endpoints — review probes showed shared endpoints negotiate AES-128-GCM, acceptable on prefer-profiles only.<br>R-12 anchoring SLO marked provisional pending measurement of the audit service's Merkle checkpoint cadence at PG-5.<br>Recorded: independent review hand-ran P-01 and P-08 equivalents on 2026-07-07 — hybrid X25519MLKEM768 negotiated in production on bee.heossi.com, qnsi.heossi.com, and api.qnsi.heossi.com, and all ships=live evidence URLs resolved — empirically confirming R-01's mechanism ahead of Phase A. |
| 0.9.4 | 2026-07-07 | regulated_cloud marked as a planned tier: its mapping to the maximum profile is target-state (the tier goes live with the marketing-site refresh) and must not appear in v1.0 marketing prose until the tier exists.<br>Toolchain: the validator gained cryptographic ML-DSA signature verification (--public-key mode; backend order liboqs, then dilithium-py pure-Python FIPS 204) with a public-key fingerprint check against the envelope; sign_register.py added as the ceremony signer, producing schema-conformant detached envelopes from a validated register only.<br>Envelope schema: public-key fingerprint definition made encoding-agnostic — SHA-384 over the public-key bytes exactly as published at the pinning surfaces — so pinning is over the published artifact rather than a specific ASN.1 encoding.<br>Full sign-and-verify loop rehearsed end-to-end with an ephemeral TEST keypair (explicitly not the ceremony key): keygen, envelope generation over this version's canonical hash, cryptographic verification, and tamper rejection all demonstrated. The PG-8 ceremony now has a tested runbook. |
| 0.9.5 | 2026-07-07 | Security finding (independent review, test F): the online-downgrade authority limit existed only in prose — a register upgraded from partial to covered, signed with the online-downgrade key, verified clean. This defeated the purpose of the two-key custody design: CI compromise could mint an improved register.<br>Fix, in the spec: downgrade_diff_policy added as required signing data — a machine-checkable whitelist (permitted status transitions, permitted row fields, permitted meta fields, append-only probe-initiated changelog rule). The policy lives in the predecessor and meta.signing is never whitelisted, so the policy is immutable under downgrade authority.<br>Fix, in the validator: --predecessor mode. For an online-downgrade envelope, the validator binds the supplied predecessor by hash (register.predecessor_hash must equal the predecessor's computed canonical hash), then diffs under the predecessor's policy; any out-of-whitelist change fails validation. An online-downgrade envelope without --predecessor can no longer produce a clean VALID.<br>Fix, in the signer: the identical diff check runs before signing — sign_register.py refuses to sign a non-downgrade diff with --signer online-downgrade.<br>Production-signing guard: the pure-Python dilithium-py backend (not constant-time) is refused for signing unless the key ID is explicitly a TEST key; production ceremony signing requires liboqs. Verification remains backend-agnostic (public inputs).<br>Rehearsal hygiene: the 0.9.4 rehearsal secret key destroyed; fresh ephemeral TEST keys generated for the 0.9.5 rehearsal and destroyed after it. |
| 0.9.6 | 2026-07-07 | Toolchain: ci_gate.py added — the release gate PG-8 requires. Five checks per release candidate: (1) register schema and cross-reference validation via the published validator CLI; (2) detached-envelope verification including cryptographic ML-DSA verification and the online-downgrade authority diff; (3) render reproducibility — a fresh render must be byte-identical to the committed document, so a hand-edited rendering fails the build; (4) CycloneDX CBOM conformance — KEM and signature components must use identifiers permitted by the register's profiles, and banned legacy identifiers (kyber, crystals-*, sphincs+) fail anywhere they appear, automating the PG-4 lint permanently; (5) customer-facing string lint over supplied source paths. Skipped inputs are reported SKIPPED, never silently passed.<br>Gate adversarially tested before shipping: a hand-edited rendering, a CBOM carrying a kyber-768 component, and a source file containing a legacy identifier each fail the gate; the clean release candidate passes all five checks including cryptographic envelope verification.<br>Probe implementations P-01 through P-10 are deliberately not part of this toolchain: probes ship as real implementations wired to production surfaces in the product repository (published: true requires executable, third-party-runnable code, not stubs), fulfilling this register as their contract. |
| 0.9.7 | 2026-07-07 | CI gate finding (independent review, live QNSI CBOM through the gate): a CBOM of unclassified components (primitive other/unknown, pqcReadiness 0%) passed conformance vacuously — the check only inspected classified KEM/signature components. Fix: unclassified cryptographic assets now surface as warnings with a classified/unclassified summary on every run, and --strict promotes them to failures. Semantics confirmed live and recorded: the CBOM classifies the stored asset (a vault password is classical), not the envelope protecting it — envelope coverage remains probe P-03 responsibility; the production P-07 implementation must treat unclassified wrap-chain-relevant components as findings.<br>Ban list extended: bare dilithium and falcon (FN-DSA legacy name) added alongside kyber and sphincs+ — QNSI uses dilithium-N identifiers internally, so without this the legacy naming would leak into Bee-facing strings during Phase B unlinted. crystals-* variants are covered by substring. |
| 0.9.8 | 2026-07-07 | Distribution finding (independent review): version sets were being published as deltas — 0.9.7 shipped without the validator, renderer, signer, backend, schemas, and template, so the gate failed on arrival in a fresh directory, contradicting the register operations promise that the toolchain is retrievable alongside the signed register.<br>Fix, mechanical: the gate gained toolchain completeness as its first check (now 6 checks) — every required toolchain file must exist beside the gate before anything else runs, so an incomplete published set fails its own gate.<br>Repo layout decision recorded: one toolchain directory plus the current signed register and envelope, with version history in git; per-version folders were a drafting workflow, not the distribution shape. Every published set ships with a MANIFEST.sha384 covering all distributed files. |
| 0.9.9 | 2026-07-07 | Distribution-integrity finding (independent review): 0.9.8 shipped a MANIFEST.sha384 listing six test-fixtures/* files that were never copied into the distribution — shasum -c failed (12 OK / 6 FAILED) on a set whose own gate passed, one version after fixing fails-its-own-gate. Fix: the fixtures now ship (cbom-pass/fail/unclassified, lint-clean/lint-dirty — the gate's committed regression suite), and the gate's toolchain-completeness check verifies the manifest cryptographically: every listed file must exist with a matching SHA-384, the required toolchain files must be listed, and a missing or unparseable manifest fails the gate. File existence alone is no longer accepted as completeness.<br>Finalized into the product repository: trust/pq-register/ in the Bee monorepo is the single distribution directory (register, envelope, toolchain, fixtures, manifest); version history lives in git; the QNSP docs/bee-integration-v1..v7 drafting folders are preserved in QNSP git history and removed from the working tree. The release gate is wired into Bee's quality pipeline (trust:gate) per PG-8. |

---

*Operated by HEOSSI (Pte.) Ltd., Singapore, UEN 202532790K. Related evidence surfaces: bee.heossi.com/trust · bee.heossi.com/quantum · qnsi.heossi.com/security. Security contact: bee-security@heossi.com. Rendered from register version 0.9.9, canonical hash `sha384:52d3e76d287fea787aaa51be7cb45c9eb080e489096b2d9efe8dbb748cb518a8648a7553656b03ff596e96670ce8366e`.*