Validate and extend the package¶
Verification layers¶
Definitions: fix the Hamiltonian, units, transfer ordering, boundary convention, observable insertion and limiting procedure.
Independent tiny oracles: construct signed boundaries, explicit small quantum matrices and complete classical sums independently of the production implementation. Check constants as well as normalized expectations.
Kernel laws: on admitted tiny state spaces, enumerate proposal flows and verify row sums, detailed balance, connectivity and self-loops. Compare proposal deltas with direct target ratios, including zero/rare cases.
Implementation equivalence: compare the transparent reference and accelerated/stencil engines over exhaustive tiny states, mixed moves, cache recounts and deterministic geometry fixtures.
Public workflows: test actual exported calls, installed wheels outside the source checkout, complete schedule inventories, saved-array replay, checkpoints and uninterrupted-versus-resumed persisted suffixes.
Failures and limits: inject real child failures, deadlines, memory/output breaches, sharing conflicts, vanished staging files, malformed metadata, frozen-file drift and nonzero exits. Preserve terminal evidence.
Scientific assessment: study initialization, autocorrelation, uncertainty, finite M, size and decoder dependence for the intended physical result.
Passing one layer does not imply the next. Unit tests are engineering evidence, and numerical campaigns are not mathematical proof certificates. The source reference, derivations, exact arithmetic and floating tests need distinct labels.
What changes require review?¶
For a new model/domain:
Add an explicit public declaration, support checks and mathematical definition.
Derive the actual finite-M weight and retain normalization constants.
Establish positivity or reject a sign/complex-weight regime explicitly.
Check resource estimates, integer/index ranges and numerical representability.
Validate both measurement families where advertised, including source-axis zeros and the dual-degree change.
For a new transition:
State the target, full proposal distribution and acceptance ratio.
Include proposal normalization, state dependence and reverse moves.
Preserve a justified observation clock.
Review the RNG, precision/rare-event branches and all counters.
Do not reuse an uncollapsed-target invariant-law argument for a collapsed move.
For a new observable:
Define support geometry, slice/time order, basis and any decoder/background.
Determine its transformation under every integrated logical shift.
Implement joint products before conditional averaging.
Test operator-square identities, overlapping supports, identical/opposite signs, zero character means and nontrivial joint terms.
Distinguish physical variance from Monte Carlo estimator variance and retain unresolved statistical cases.
For an execution/refactor change:
Preserve every consumed manifest field and exact schedule semantics.
Exercise actual public paths and OS interactions, not only stubbed helpers.
Check output containment, complete-operation budgets and final failure precedence after sampling has already finished.
Test old/new common-stream outputs when the target/algorithm should remain unchanged, while keeping the old artifact’s identity available.
Documentation and examples¶
Build against the real installed library without mocked API objects. Check every top-level export is documented. Execute the exact named example blocks from the source pages in fresh development directories with explicitly supplied engineering seeds and bounded schedules. Confirm inventory counts, result keys, replay and continuation rather than asserting favorable random physics.
Statistical examples should include constant/tied histories and unavailable diagnostics. Equation checks should compare independent definitions instead of reproducing a function line by line. Do not skip a public failure path or mark a regression expected-to-fail to manufacture a passing release.
Release identity¶
Keep source, tests, docs, run data and generated artifacts distinct. A behavior or module change needs a new version/artifact identity and appropriate checks. Documentation-only work can retain runtime 0.3.2 when runtime module bytes and installed wheel identity remain unchanged; issue a separately hashed companion documentation artifact. Do not overwrite the original wheel or a run’s freeze. If changing packaging metadata to ship documentation in a new distribution, assign and test an explicit new distribution identity.