# Q-Sign — Capability Dossier (canonical public projection)

> Reviewed 2026-10-27 against current implementation and rulings; corrections are listed in the change record.

> Generated by Knowledge Compiler v1.1 as a faithful projection of governed implementation. Each factual sentence carries a claim state: **[VI]** VERIFIED_IMPLEMENTATION · **[VS]** VERIFIED_SPECIFICATION · **[M]** MEASURED · **[D]** DESCRIPTIVE. `[D]` is framing, never verification evidence. A [VI] tag means a resolvable implementation component exists; it does not mean the component is deployed or has been observed running in production. No benchmark figures, availability, SLA, production-readiness, deployment-completeness, or "complete-patent-system" claims appear here (see *Claims not made*).
>
> **First-use definitions (capability-specific):** *substrate* — here, a decision-integrity foundation autonomous systems are evaluated against. *committed scope* — the constraints an agent agreed to operate within at registration. *governance state root* — a hash of the governance state at decision time. *NAP (Negative Authority Proof)* — a portable, signed file recording that an action was evaluated and denied under that state. *offline verification* — re-checking the file's internal bindings and its signatures against the public keys the file carries, without a call to H33; on its own this does not establish who issued the file.

## What it is
**[D]** Q-Sign is H33's governed **decision-integrity substrate** for autonomous systems. **[VS]** An autonomous agent submits a request for action, and Q-Sign decides whether the agent had the authority to perform it *under the governance state at decision time*. If it did not, Q-Sign emits a portable **Negative Authority Proof (NAP)**: signed evidence binding the request to the agent's committed scope, the governance state, and the verdict. A third party can check that evidence offline. **[VS]** The design goal is for that check to confirm the issuer as well. Today the offline check confirms the file's internal consistency and its signatures under the keys it carries (see *Verification model*).

**[D]** The consumable is the artifact, not the code. **[VI]** The NAP is a portable `.h33pqv.json` file. It contains:
- the full inbound request;
- the agent's committed scope;
- the governance state root hash with a replay frame;
- the list of scope axes that failed;
- a hash binding all of the above;
- a plain-language summary;
- post-quantum signatures from the agent's key and from a separate issuer key.

## Problem it solves
**[D]** Conventional authorization proves *who* is calling but not *whether an autonomous action was authorized* under the governing policy at that moment, and it cannot hand a third party checkable evidence of a rejection. **[VS]** Q-Sign is specified to produce a determination of authority for an autonomous action, together with a portable signed record of the verdict that can be checked offline. **[D]** This maps to the graph problems *"Prove an AI decision was authorized"* and, through Agent-008, which is designed to consume Q-Sign's proofs, *"protect and govern autonomous AI agents."*

## Architectural role
**[VI]** Q-Sign is built on H33-Root, H33's authority-preservation substrate, for hashing, canonical encoding and signing. **[VI]** An Agent-008 component depends on Q-Sign's proof artifacts, and an Agent-008-to-Q-Sign adapter exists. **[D]** The full Agent-008 / Q-Sign composition is described here as architecture, not claimed as running. **[D]** Foundational substrates (H33-Root, and H33-74 as a related evidence layer) are described as sitting *beneath* Q-Sign. Q-Sign is a platform capability; in the layer stack it is where an agent's authority is evaluated and sealed into evidence.

## Governed module architecture (logical)
**[VI]** Q-Sign is organized as governed modules with distinct responsibilities. A Lite core covers the decision path. Several extended modules exist as dedicated implementation components, described as *architecture foundations*. Maturity is stated per row, not implied, and no row implies production deployment.

| Logical capability | Responsibility | Maturity | State |
|---|---|---|---|
| Governance state root | Deterministic root hash of governance state at decision time | Core (Lite) | **[VI]** |
| Authority evaluator | Multi-dimension AND-gate authorization decision | Core (Lite) | **[VI]** |
| Execution attestation | Structured, signed record of the evaluated decision | Core (Lite) | **[VI]** |
| Nonce registry | Append-only, hash-linked registry used for replay checks | Core (Lite) | **[VI]** |
| External verifier | Multi-step verification of an attestation against supplied evaluator keys | Core (Lite) | **[VI]** |
| Explanation | Human-readable rationale for a verdict | Core (Lite) | **[VI]** |
| Policy engine | Rule-based governance policy evaluation | Core (Lite) | **[VI]** |
| Negative Authority Proof | Portable `.h33pqv.json` rejection record | Foundation | **[VI]** |
| Bounded autonomous authority evaluation | Evaluate a request against committed scope axes | Foundation | **[VI]** |
| Authority lineage | Append-only, hash-linked governance-event DAG (in-process in v0.1) | Foundation | **[VI]** |
| Temporal authority | Revocation-scenario detection & deterministic ordering | Foundation | **[VI]** |
| Machine-verifiable authority object (Q-Key) | Embedded authority metadata with computation-class binding | Foundation | **[VI]** |
| Delegation | Agent-to-agent authority transfer, intersection-only, revocation cascade | v0.2 extension | **[VI]** |
| Governed escalation | Deterministic, signed escalation walk of the authority hierarchy | v0.2 extension | **[VI]** |
| Conformance | Test vectors and runner for the v0.2 delegation, escalation and policy extensions | v0.2 extension | **[VI]** |
| Federation | Cross-organization identifiers + verification/audit receipt artifact types | Foundation (library only) | **[VI]** |

**[VI]** Scope boundary, preserved from the implementation: the Lite core covers a defined module set. Other patent-described modules are **out of scope for the Lite core** and are not claimed as complete by this dossier. Where they exist, they appear above at *Foundation* or *extension* maturity.

## Cryptographic profile
**[VS]** Q-Sign is designed to bind its evidence using three independent post-quantum signature families: **ML-DSA** (ML-DSA-87), **SLH-DSA** (SLH-DSA-SHA2-256s) and **FALCON** (FALCON-512 in the v0.1 profiles). **[D]** Full three-family production verification remains pending completion and independent qualification of the FALCON repair. **[VS]** The specification permits only STARK-based zero-knowledge constructions. **[VI]** The NAP itself uses SHA3-384 bindings and signatures; it carries no zero-knowledge proof. **[VS]** Classical signature schemes appear only inside specified hybrid composites, never on their own.

## Verification model
**[VS]** The documented workflow supports **offline checking without a required H33 network call**. A third party runs an offline verifier on the `.h33pqv.json` file and gets a valid/invalid verdict. **[VI]** A verifier command-line tool implements this workflow. It recomputes the file's internal bindings and hashes, and requires all three signature families to verify, both for the agent's signatures and for the issuer's signatures under the keys carried in the file. **[D]** A valid offline verdict therefore shows that the file is internally consistent and was signed by the keys it carries. It does not, on its own, show that a trusted issuer produced it. Checking issuers against authenticated, versioned issuer keys with rotation history is not yet established. **[D]** Long-term offline checking also requires retaining, at issuance, the file and the public keys of the issuing period. **[D]** Production evidence for real signature verification, failure propagation, durable receipts, historical keys and issuer trust is still being established, so Q-Sign verification is not yet available for production receipts. **[D]** The public Proof-Lab page `/proof-lab/q-sign/` is an illustrative, scripted walkthrough with sample data. It does not verify a live artifact.

## Standard & conformance
**[VS]** Q-Sign Standard **v0.1** is the governing specification version projected here. It is a reviewer release written for external reviewers, auditors and technical buyers; external review engagement is its stated next step. *This is H33's own governing standard version — not a claim of an externally ratified industry standard.* **[VI]** A conformance test-vector suite and runner exist for the v0.2 delegation, escalation and policy extensions. **[D]** They are intended for external implementers to check their own implementations; no external conformance results are claimed.

## Benchmarks
**[VI]** Internal benchmark harnesses and baseline measurements exist as governed artifacts. **No figures are published here** until each carries full reproducibility metadata: exact commit; hardware/OS; build profile & feature flags; workload/dataset; iteration & warm-up counts; statistical treatment; execution date; reproducible command; and a baseline/laboratory/production label. **[D]** Published benchmark claims will state *what was measured*, not a collapsed "Q-Sign performance."

## Intellectual property
**[VI]** The implementation maintains a governed traceability map between specified modules, implementation components, and applicable intellectual-property records. **[D]** Patent mapping establishes traceability to the claimed invention structure; it does **not** independently establish validity, enforceability, novelty, or coverage. (The detailed module-to-patent crosswalk is retained as reviewer-only provenance.)

## Related capabilities
Agent-008 (designed to consume Q-Sign proofs) · H33-Root (authority substrate Q-Sign uses) · H33-Key · Verification.

## Evidence (typed, with confidence)
| Type | Confidence | State | Projection |
|---|---|---|---|
| Implementation | ★★★★★ | VI | source exists — projected here; not observed running in production |
| Specification (Standard v0.1) | ★★★★★ | VS | exists — projected here |
| Verification (offline CLI) | ★★★★☆ | VI | internal-consistency and carried-key signature checks; issuer trust and production verification pending |
| Conformance (v0.2 extensions) | ★★★★☆ | VI | projected here; no external results claimed |
| Demonstration | ★★★★☆ | D | illustrative Proof-Lab walkthrough (sample data) |
| Benchmark | ★★★☆☆ | M (withheld) | pending reproducibility metadata |

## Claims not made
- No claim about patent-described modules outside the stated Lite/foundation set; no implication the complete patent-described system is implemented or deployed.
- No claim that Q-Sign, or any module above, is deployed or has been observed running in production.
- No claim that production receipts currently carry three verified post-quantum signatures.
- No claim that a valid offline verdict establishes the identity or authority of the issuer.
- No benchmark figures until reproducibility metadata is complete.
- No availability, uptime, SLA, production-readiness, scale-beyond-measured-workload, or "battle-tested" claim.
- No assertion that Q-Sign v0.1 is an externally ratified industry standard, or that it has completed external review.
- No assertion of patent validity, enforceability, novelty, or coverage.