Versioned quantum job API

Purpose and scope

Binds job ownership, duplicate submissions and state transitions to a versioned API contract. A local simulator queue is not evidence of execution with a real QPU provider.

Core design rules

• POST /api/nm/jobs accepts only declared fields; source, shots and metadata sizes are bounded.
• The required Idempotency-Key is bound to tenant scope and request fingerprint; a different request under the same key produces 409.
• Polling and cancellation verify ownership server-side; credentials are not written into public job documents.

Example from the original

This example illustrates the design recorded in the original. It is not by itself a claim of executable or stable support; check required options and the current version.

queued -> running -> succeeded
                  -> failed
queued ----------> cancelled
running ---------> cancelled

Limits and interpretation

• The source specifies that production API activation depends on provider configuration.
• The document does not select a production queue, database, identity provider or hardware vendor.

Status and implementation boundary

The recorded status is preview. Durability, retry bounds and ownership tests are separate stability gates. Read NM-RFC-0033 for the additional boundary of a real QPU adapter.