QuantumD produces trustworthy execution evidence, not favorable quantum results.

QuantumD is the trust and execution layer for AI-generated quantum software. It verifies the exact workload, enforces execution policy, binds authorization to what actually runs, and produces evidence that can be checked independently.

You do not need a quantum computer, an IBM Quantum account, or a Google Cloud account to explore the local evidence model. The public alpha starts with a simulator-only workflow whose hardware authority is explicitly prohibited.

Run the alpha · Choose your path · Browse the docs · Join the evaluation

Choose your path

QuantumD is designed for different kinds of readers. Start with the route that matches your role or question.

You are exploring QuantumD as...	Start here	Continue with
A first-time reader	Public alpha installation	Local quickstart
A quantum developer	Evidence Graph	IBM Quantum workflow
A security or DevSecOps engineer	Trust boundary	Verify an evidence chain
A reviewer, auditor, or program leader	What the Evidence Graph records	v0.7.5 alpha release
An educator, researcher, or advanced student	Local simulation	Alpha evaluation
A contributor	Contributing guide	Roadmap
A security researcher	Security policy	Support boundaries

Why QuantumD exists

AI can generate circuits, notebooks, and computational workflows quickly. That does not establish that:

• the reviewed workload is the workload that executed
• an approval was used only for its intended project and parameters
• a submitted job identifier belongs to the approved workload
• a returned result has not been substituted or altered
• the evidence chain can be checked without trusting the original platform

QuantumD places a governed verification boundary between generated software and execution. It connects reviewer intent, cryptographic authorization, provider submission, observed execution, result artifacts, and signed receipts.

What QuantumD proves

QuantumD binds together:

• project source and manifest identity
• the verification and policy decision
• the authorized backend and shot count
• logical and executed circuit identities
• approval, submission, job, and execution identifiers
• the result artifact and its SHA-256 digest
• the execution receipt
• signing-key lineage
• the order of authorization and execution

A successful job identifier or a complete cloud log is useful, but it is not the same as a verified chain connecting approval to execution and results.

Run the public alpha

QuantumD 0.7.5a0 is distributed through production PyPI. The complete QuantumD dependency set remains available through one installation.

1. Install QuantumD

python -m pip install quantumd

QuantumD does not require you to create a virtual environment. The command installs into the Python environment associated with python. During alpha evaluation, you can pin the exact release:

python -m pip install "quantumd==0.7.5a0"

On systems that protect the system Python, install the command without manually managing an environment:

pipx install quantumd

or:

uv tool install --python 3.12 quantumd

2. Run the local governed workflow

quantumd quickstart my-first-quantumd-project

3. Inspect and independently verify the evidence

quantumd doctor my-first-quantumd-project
quantumd verify-chain my-first-quantumd-project --latest

The local quickstart remains intentionally restricted:

Trust mode:             LOCAL_DEVELOPMENT
Trust scope:            LOCAL_SIMULATION_ONLY
Hardware authorization: PROHIBITED
KMS signing used:       False
IBM contacted:          False
Hardware action:        None

Independent verification should finish with:

[STATUS] COMPLETE EVIDENCE CHAIN VERIFIED
IBM contacted:   False
KMS contacted:   False
Hardware action: None

QuantumD supports Python 3.10, 3.11, and 3.12. Python 3.12 remains the reference release environment. See the installation guide for exact-version, pipx, uv tool, WSL, and source-development paths.

The Evidence Graph

The local workflow produces:

PROJECT -> QVERIFY -> QEXEC

An organization-governed hardware workflow extends the chain:

QVERIFY -> QPLAN -> QAPPROVAL -> QSUB -> IBM JOB -> QEXEC

Independent verification checks signatures, key lineage, authorization binding, current source identity, circuit identity, result hashes, shot counts, and execution timing. A local chain can be verified without contacting IBM or Google Cloud KMS.

Read the complete Evidence Graph guide.

The trust boundary

QuantumD treats generation and governed execution as separate security domains:

1. Code, notebooks, and configuration begin outside the trusted boundary.
2. QuantumD establishes the exact project and workload identity.
3. Policy determines what is permitted.
4. Authorization is bound to the verified workload.
5. Execution and result evidence are checked against that authorization.
6. Missing, mismatched, replayed, substituted, or corrupted evidence causes denial rather than best-effort acceptance.

A local-development identity can authorize Aer simulation only. It cannot silently become hardware authority.

Read the trust-boundary guide.

Trust modes

Trust mode	Available	Signing authority	Hardware authority
UNCONFIGURED	Yes	None	Prohibited
LOCAL_DEVELOPMENT	Yes	Project-local identity	Prohibited
KMS_GOVERNED	Yes	Organization-controlled Google Cloud KMS	Policy controlled
SELF_MANAGED_HARDWARE	Planned	User-managed encrypted identity	Not yet available

The local alpha is safe to explore without cloud credentials because LOCAL_DEVELOPMENT is limited to LOCAL_SIMULATION_ONLY.

Read Trust modes for the complete boundaries.

Documentation map

Start and operate

Document	What it helps you do
Installation	Install QuantumD from production PyPI or create a source-development environment
Local quickstart	Create a governed simulator project and verify its evidence
Local simulation	Understand the simulator-first workflow
Verify an evidence chain	Independently inspect the latest execution chain
CLI reference	Find commands, options, and expected behavior

Understand the model

Document	What it explains
Evidence Graph	How verification, plans, approvals, submissions, jobs, and receipts connect
Trust boundary	What remains untrusted and what must happen before execution is accepted
Trust modes	Local, unconfigured, KMS-governed, and planned trust scopes
IBM Quantum provider	The controlled organization-governed hardware path

Evaluate, contribute, and govern

Document	What it is for
Alpha evaluation	Test the stranger experience and provide structured feedback
Evaluator worksheet	Record installation time, confusion, skepticism, and next-use cases
v0.7.5 alpha release	Review the published alpha, checksum, and validated boundaries
Security policy	Report vulnerabilities privately and understand security-sensitive areas
Contributing	Set up development and preserve fail-closed behavior
Support	Choose the correct public or private support channel
Code of Conduct	Participate professionally and respectfully
Roadmap	See the current direction without treating planned work as shipped
Changelog	Review version-by-version changes

Inclusive evaluation

QuantumD welcomes feedback from people with different technical backgrounds. You do not need production quantum-hardware access to participate.

The first evaluation cohort is intended to include:

• a quantum developer
• a software-supply-chain or security engineer
• an ML, data, or scientific-computing engineer
• a technical leader from an audit-exposed environment
• an educator, researcher, or advanced technical student

The evaluation asks a simple question:

Can a technically capable stranger install QuantumD, understand the trust boundary, produce a verified chain, and identify a real workflow where the evidence would matter?

Start with the alpha-evaluation guide.

Current alpha boundaries

QuantumD is alpha software. The current release demonstrates a governed local workflow and an existing organization-managed KMS and IBM execution path.

QuantumD does not claim that:

• passing verification proves scientific usefulness
• a simulator result guarantees hardware performance
• a local signing identity is suitable for organization-controlled production
• every provider or computational framework is supported
• alpha software should be the sole control for classified, safety-critical, regulated, or financially material operations

Pin exact versions during evaluation and preserve evidence with the version that generated it.

Community and security

• Use GitHub Issues for reproducible bugs, installation failures, documentation errors, and feature proposals.
• Follow SECURITY.md for vulnerabilities. Do not publish credentials, private keys, confidential evidence, or exploit details in a public issue.
• Read CONTRIBUTING.md before changing signing, authorization, trust selection, evidence verification, hardware access, or release workflows.
• Community participation is governed by the Code of Conduct.

Release provenance

The current production PyPI alpha is v0.7.5-alpha, published as Python package version 0.7.5a0.

• Production package: PyPI quantumd
• Release notes: v0.7.5 alpha
• Publishing identity: GitHub Actions Trusted Publishing through OIDC
• Website: quantumd.ai
• License: Apache License 2.0

QuantumD was founded and is maintained by Damarcus Thomas, founder@quantumd.ai.