Darbeye duyarlı gürültü programı

• Status: proposed program charter
• Revision: 1 (2026-08-11)
• Proposed target: browser-pulse-density
• Proposed flag: experimental.pulseAwareNoise=true
• Owners: compiler, numerical runtime, verification, tooling, product, security
• Depends on: approved NM-RFC-0018 and NM-RFC-0019; NM-RFC-0029 only for a future three-level slice
• Does not change: gate-level simulation, calibration comparison, QPU providers, or pulse upload APIs
• Implementation gate: this charter is intentionally non-implementable until section 15 decisions are approved in a revision

1. Summary

Gate-level durations and idle channels cannot describe control-envelope shape, drive overlap, or noise accumulated during a pulse. Conversely, accepting an arbitrary waveform and calling the result device-accurate would create an unsafe scientific claim and a large unbounded numerical surface.

This RFC defines the boundary for a future pulse-aware local simulator. Pulse programs and control models are immutable, bounded, exact-version data artifacts. There is no source-inline waveform, arbitrary function, live provider fetch, hardware upload, or automatic calibration binding.

Revision 1 is a program charter. It reserves names, ordering, security limits, evidence language, and review questions; it creates no executable grammar.

2. Required separation

The future implementation must keep three artifacts distinct:

1. nm-timed-execution-plan@0.1: logical/native operations and schedule;
2. nm-pulse-program@0.1: bounded control channels and piecewise-constant complex envelopes; and
3. nm-control-model@0.1: exact-version Hamiltonian/noise parameters and the mapping from logical sites to control channels.

A fourth nm-pulse-binding@0.1 artifact binds exact identities/digests and records the deterministic expansion from each timed operation to pulse segments. None of these artifacts implies trust in the others.

3. Proposed first executable slice

A later revision may approve only this slice:

• distinct browser-pulse-density backend;
• one or two qubits in a two-level Hilbert space;
• at most four named control channels;
• piecewise-constant I/Q envelopes on one integer-nanosecond grid;
• at most 256 segments and 2048 total complex samples;
• total scheduled duration at most 100,000 ns;
• closed drift and drive Hamiltonian terms over Pauli I/X/Y/Z products;
• closed Markovian Lindblad terms derived from explicit T1/T2 values; and
• terminal Z measurement with 1..4096 shots after deterministic density evolution.

Three-level leakage, more than two sites, arbitrary Hamiltonian matrices, continuous functions, spline interpolation, non-Markovian kernels, optimal control, and provider execution are outside the first slice.

4. Pulse program artifact

The proposed nm-pulse-program@0.1 is strict canonical JSON data containing:

• immutable program ID/version and exact package/export/digest identity;
• integer sample period in 1..1000 ns;
• 1..4 ASCII channel IDs;
• ordered non-overlapping segments with integer start/duration;
• bounded finite I/Q decimal samples with magnitude at most one;
• timed-operation binding IDs and explicit idle regions;
• declared units, limitations, and SHA-256 integrity.

Sparse arrays, NaN, Infinity, signed zero, inheritance, accessors, unknown fields/versions, base64 executable blobs, URLs, filesystem paths, code strings, and compressed data are rejected. A pulse package supplies inert data only.

5. Control model artifact

The proposed nm-control-model@0.1 contains:

• immutable exact package/export/digest and target identity;
• site/channel map;
• finite Pauli-product drift coefficients in radians/ns;
• finite per-channel I/Q drive coefficients;
• explicit rotating-frame and phase convention;
• optional bounded T1/T2 Markovian terms with exact provenance;
• validity/observation times supplied explicitly for replay; and
• limitations and SHA-256 integrity.

There are at most 16 Hamiltonian terms. Coefficients have absolute value at most 1e6 radians/ns. The strict reader validates Hermitian construction, units, duplicate terms, site/channel coverage, T1/T2 physical relations, byte limits, and exact target binding. No value is inferred from a neighboring site or default provider table.

6. Binding and operation order

The proposed nm-pulse-binding@0.1 binds the complete timed plan, pulse program, control model, target, observation time, compiler version, and all digests. It freezes:

1. target-native lowering;
2. deterministic timed scheduling;
3. operation-to-segment pulse expansion;
4. coincident channel summation in canonical channel order;
5. Hamiltonian and dissipator construction per grid interval; and
6. terminal measurement.

Any change to schedule, sample, coefficient, frame, channel order, target, or numeric policy changes identity. Runtime recomputes the binding before state allocation.

7. Numerical method decision gate

No runtime implementation may begin until a revision freezes all of:

• density-vectorization convention and basis order;
• piecewise-constant master equation;
• deterministic matrix exponential algorithm and scaling policy;
• absolute/relative tolerance and non-convergence behavior;
• trace/Hermiticity/positive-semidefinite validation cadence;
• cross-platform reference precision and accepted drift; and
• cancellation/time/memory limits.

Normalizing, symmetrizing, clamping, or projecting a failing state into validity is forbidden. Numerical failure must be a structured diagnostic.

Choosing a library is not a normative numerical specification. The approved revision must include independent high-precision reference fixtures and a reviewed error budget.

8. Calibration and provider boundary

• Importing or comparing calibration never activates pulses.
• No latest, live provider query, token, credential, job, or device session enters the compiler/runtime.
• A control model may cite a frozen calibration snapshot only through an approved NM-RFC-0019 binding with exact digest and replay time.
• Freshness is a recorded policy input, not proof of present device behavior.
• The result is a local model evaluation, not a pulse schedule safe for upload.

9. Proposed evidence

A future nm-pulse-density-run@0.1 must include exact artifact identities, schedule/segment counts, selected numeric method/version, interval-level norm and invariant drift, final density/probabilities, seeded histogram, resource metrics, and limitations. Raw private waveforms need not be embedded in a shareable report; their digest and bounded summary remain mandatory.

Every surface must state:

• local supplied control model;
• not sent to hardware;
• not live calibration;
• not validated device fidelity;
• no optimal-control, mitigation, leakage, non-Markovian, QEC, or fault-tolerance claim.

10. Proposed diagnostics

The approved executable revision must reserve a closed NM-PULSE-* family for negotiation, artifact identity, unit/frame mismatch, waveform bounds, schedule/binding mismatch, unsupported Hamiltonian/dissipator, numerical non-convergence, density-invariant failure, cancellation/timeout, and result reader failures. Unknown or unsupported input always fails closed.

11. Product surface

After an executable revision is approved, a Pulse Inspector may show:

• timed operations and channel-aligned I/Q envelopes;
• exact artifact/digest/frame/unit provenance;
• interval-level Hamiltonian/noise summaries;
• invariant/error-budget evidence; and
• comparison with the identical gate-level plan.

It must use accessible tables/text alongside plots. The action is run local model, never run on device or calibrate. Experiment Studio integration is last in the rollout, after the same strict result reader is available.

12. Export and security

Gate-level exporters cannot silently discard pulses. Strict export fails or emits an explicit versioned sidecar. No revision authorizes OpenPulse/provider upload.

Readers validate byte/count bounds before decoding arrays, copy accepted data, reject executable content/prototypes/getters, and never dynamically import a package. SHA-256 establishes integrity only. Telemetry carries IDs, counts, timings, diagnostics, and numeric drift, not raw waveforms, calibration values, credentials, or source.

13. Non-goals

• Hardware control, pulse upload, provider adapters, automatic calibration, optimal-control search, gradient fitting, or device certification.
• Analog arbitrary functions, user code, plugins, remote solvers, GPU claims, continuous-time/non-Markovian environments, leakage/qutrits in the first slice, or raising existing backend ceilings.

14. Program acceptance criteria

Before an executable revision can be proposed, it must provide:

• complete schemas and hostile strict-reader fixtures for all four artifacts;
• a frozen numerical algorithm with independent high-precision references;
• checked allocation/time budgets for the maximum workload;
• exact cross-platform artifact/evidence policy under pinned Node 22;
• a no-network/no-code package boundary;
• fail-closed circuit exporter behavior;
• EN/TR product labels and claims tests; and
• explicit decisions for every row in section 15.

15. Required review record

This charter creates no parser syntax, flag, backend, artifact reader, capability, lab, or provider integration. A merge, prototype, or passing CI is not approval.