PF Simulation Research library

PF research library · 5 min read

r34 execution, logs and Orbit Viewer recovery

r34 documentation · execution-logs-orbit.md · Formatted reading copy

On this page
  1. Changes
  2. What users see
  3. Existing HF installation: prepare this update
  4. Post-deployment checks
  5. Evidence and package integrity

This is the retained 10 October execution-recovery record. Its original commands, earlier input-acquisition description and validation scope remain historical. The later tracking preparation correction adds validated public-input reuse and shared downloads; every simulation still executes fresh. Use the current package verification command when checking the latest archive.

Revision: 2026-10-10. Applies to the full r34 release whose predecessor archive SHA-256 is 40b1d913d074537f6a69fa26ad3887b735a3e930584a9ead9e51b5fd24e7008f.

Changes

Area Corrected behavior
HF scientific startup The confined runtime permits reading the exact /proc/meminfo file required by Qiskit Aer. Directory enumeration, process files, writes and workload networking remain denied.
Scientific qualification The explicit HF qualification now requires real Aer density-matrix and sampled-circuit checks, in addition to the existing NumPy, FMPy and QuTiP checks. Older reports without these observations do not pass.
Run logs Scientific HF stdout/stderr populate the shared log.txt contract. The authorized log API can also recover a hash-verified historical execution.log when an older run retained an empty log.txt. The panel explains waiting or absent output.
Live diagnostics The trusted monitor relays bounded, attempt-bound log bytes and comparison snapshots without giving workload code credentials or network access. Final verified output replaces provisional data.
Current-UTC inputs The trusted HF preparation stage obtains approved GP, Earth-orientation and leap-second inputs before dispatch. It captures provenance and hashes, then the isolated computation reads those frozen inputs without downloading. Each segment still uses its actual current UTC epoch and enforces freshness and coverage.
Orbit Viewer The viewer displays authorized execution state and errors even when startup produced no session. Provisional previews are labeled, final committed results are authoritative, and requests read only the required verified comparison artifacts.
Other hosted workers Docker and subprocess workers publish the same bounded provisional comparison snapshots from their existing local work directory. Standalone continues to read its local saved sessions directly.

The shared physics and quantum calculations are not replaced by fabricated results. Historical replay fixtures are explicitly used only as offline controls and in tests. They are never substituted for unavailable current orbital data.

What users see

During preparation or provider startup, the run panel explains that it is waiting for output. Once the command prints, logs become available while it runs. A failure before comparison startup is shown in the run state and Orbit Viewer; it no longer appears only as an unexplained empty session list.

Live previews are provisional. They can be incomplete, omitted because of size limits, or unavailable during a transient connection problem. A successful HTTP connection is not a scientific-success claim. A completed or failed run's committed artifact manifest remains the authority for saved outputs.

The native channel checks for progress approximately every two seconds, skips unchanged writes, relays at most the first 256 KiB of live log bytes, and includes at most 16 comparison documents totaling 1 MiB in a 2 MiB snapshot. Full retained logs and results become available after collection. Other hosted workers check local previews at most five seconds apart, subject to the lease interval.

Every new HF job acquires its own tracking snapshot. Multi-segment live runs reuse that acquisition only while its configured refresh interval and the supplied timing coverage remain valid. A run that outlives those bounds fails with a freshness/coverage explanation; it does not silently download inside the sandbox or present stale data as current. Start a new run to acquire fresh input.

Existing HF installation: prepare this update

Use a clean extraction and the working personal-computer Python environment that can reach HF downloads. These Windows CMD examples assume the active directory is the extracted privileged-frame-simulation folder. Choose a new output path so older verified bundles remain available.

python release_tools\package_r34_execution_recovery.py verify --package
set "PF_HF_UPLOAD=%USERPROFILE%\Downloads\pf-r34-execution-recovery-generated-20261010"
python deploy\saas\huggingface_native\build_space.py --output "%PF_HF_UPLOAD%"
python deploy\saas\huggingface_native\deploy_release.py verify --bundle "%PF_HF_UPLOAD%"

Continue with the stopped-backup and upgrade procedure in the native HF guide and the public-service guide. Preserve the existing state bucket, prefix, encryption/session/database keys, public registration policy and concurrency/budget settings. This is a code upgrade, not a fresh data bootstrap; no database schema migration is introduced by this recovery revision.

Upload the newly generated private code context, record its exact revision and hash, and qualify that exact code with the selected immutable runtime image. Deploy the matching controller context. An older successful confinement report does not qualify the new code. The build tool must include the new native and SaaS modules; do not upload selected files manually from an older handoff bundle.

Confinement and runner sources are carried in the private code payload. The public runtime image only needs rebuilding if its generated runtime/ context differs from the installed qualified runtime source. Compare exact context bytes; do not infer identity from a tag such as latest.

Post-deployment checks

  1. Run the supplied qualify.py against the new private-code commit/hash and immutable runtime image. Require Aer success and the narrow proc-read/denial observations, not merely a COMPLETED provider status.
  2. Run the historical offline comparison. Confirm useful logs, completed sessions and trajectories. This checks execution; it does not test current external data availability.
  3. Run Current UTC orbit comparison · SR. Confirm fresh captured tracking provenance, changing live segment epochs, provisional viewer output during execution, then final committed results and full logs.
  4. Inspect the previously failed run: its retained execution.log should now be readable without rerunning it. Cancel a new small test run and confirm its state and diagnostics, then verify another authorized account cannot read its private project data.
  5. Check execution capacity and storage accounting return to their expected state. If a remote diagnostic write is ambiguous, computation can finish but publication is held for conservative storage reconciliation; the system must not claim a successful immutable commit over an uncertain writer.

No external messages, HF jobs or deployment mutations were performed while building this package. The local validation environment cannot run Landlock; its focused filesystem tests use explicitly labeled read-denial emulation plus the real seccomp filter. Live HF/FUSE operation, real tracking-provider access, production capacity and external scientific replication remain separate gates.

Evidence and package integrity

Run python release_tools/package_r34_execution_recovery.py verify --package. Current scoped commands and their outputs are recorded in validation_r34_execution_recovery/test_execution.json. That directory also contains the release-group ledger and current qualification registries. MANIFEST.json and PACKAGE_CHECKSUMS.json describe the delivered bytes. All preceding validation directories retain their original bytes and scope; their historical counts are not presented as newly rerun tests.