r34 integration inventory and website claim review

Reviewed the actual source at the corrected r34 package on 2026-09-22. This review covers integrations other than the separately assigned Qiskit and satellite/orbit audits. It cross-checks shipped guides, adapters, operation manifest and representative tests. It is a source audit, not a new live-provider, vendor-hardware or full-release execution certification.

Recommended presentation

Use Scientific engines, recorded data and connected research services, not “all live APIs.” The native Python libraries execute locally/on configured workers; some adapters require licensed products or reviewed native executables; others import files or reanalyse frozen published records. The real network APIs are AI-provider calls, selected live orbital data feeds, BYOS and optional hosting services.

The audited capability registry contains 15 scientific integration families. pf_integrations/capability_registry.py lists each bounded operation and its limit. capability_manifest():73 distinguishes scientific applicability from installed dependencies, licensing, successful execution and experimental outcomes. pf_integrations/runner.py:capabilities() is explicitly an availability probe with execution_verified: false for every entry. An ambient-interpreter invocation of python run_research_integrations.py --list completed during this review, but that interpreter lacks most optional research dependencies. This does not assess the separately installed research environment.

Use small capability cards with four fields: What runs · Research question · Requirements · Scope. Link the relevant original r34 guide. A broad page-level statement should explain that optional adapters expose specific operations, not every upstream API, and that checked simulations do not establish experimental accuracy or commercial advantage.

Scientific engine catalogue

Recorded-data and published-reference catalogue

NumPy, SciPy, Matplotlib, SymPy, h5py, JPype and plotting/reporting utilities are supporting runtime libraries. They should not be counted as separate live scientific services. Qiskit, SGP4/Astropy/orbital data sources and Orekit belong in the separately audited quantum and satellite sections.

AI and private storage services

All five AI protocols share PF’s proposal/diff/validation/explicit activation/deletion and active-private-stack execution controls. Neither a model response nor a passed validation automatically activates a layer. Provider validation used scripted HTTP protocols with real numerical subprocesses, not paid live model access or proof of reasoning quality. BYOK separates credentials and vendor billing; selected evidence/source may be sent to that provider. BYOS separates bulk artifact location; it does not move all control records off PF infrastructure or confer unlimited quotas. Sources: R34_BYOK_GUIDE.md, R33_AI_PROVIDERS_GUIDE.md, PF_Simulation_r34_BYOS_Guide.md, tests_saas/test_r34_byok_saas.py, tests_saas/test_r34_byos_integration.py.

Optional hosting integrations (deployment detail)

These are real integrations but should not become scientific Gallery cards: AWS Batch for administrator-selected job queues/definitions (pf_saas/aws.py:11 AWSBatchAdapter); managed AWS S3 (pf_saas/storage.py:141 S3Storage); Amazon Cognito ID-token verification and local-session exchange (pf_saas/cloud_auth.py:22 verify_cognito_token); Stripe billing checkout/portal/webhook reconciliation (pf_saas/billing.py:28 StripeAdapter, :94 BillingService); and SMTP transactional email (pf_saas/mail.py:12 MailService). They require actual deployment configuration and acceptance, and the static Network Solutions website does not itself run those services. PostgreSQL/SQLAlchemy, FastAPI, Docker and Python are platform/runtime components, not research APIs.

Cohesive value proposition

Recommended language: “Connect the evidence across your research workflow. PF Simulation keeps the selected inputs, declared assumptions, engine versions, numerical checks and resulting artifacts together, so teams can compare implementations and build the next study on an inspectable result.”

The valuable implemented bridge is explicit lineage from actual parent outputs into compatible scientific companions (pf_integrations/workflow_bridge.py:172 build_companion, :333 companion_catalog, :439 run_companion_suite). The five companions consume saved state, memory proper times, radii, orbit state or solved ray data. If prerequisites are missing they fail or explain unavailability; they do not generate a substitute example. The orbit companion is explicitly a reoriented reference initialized from derived osculating elements, not an epoch-matched replay. A contextual SeQUeNCe/PyMC/FMPy reference is not an executed-data validation of the parent mission.

For academic teams, this supports auditable methods, hypothesis comparison and numerical reproducibility. For corporate R&D, it supports traceable design choices, reuse of controlled configurations and prioritization of experiments. These are defensible workflow benefits inferred from the implemented artifacts and controls. There is no evidence here for quantified time/cost savings, commercial superiority, customer demand, experimental mission accuracy or a PF-specific performance advantage.

Gallery recommendations

1. Add actual Qiskit and satellite examples after the separately assigned audits, with precise runtime/data labels.
2. QuTiP memory dynamics is a strong next example: actual time-evolving matrix/coherence and residual plots explain why model comparisons matter. Use fresh actual output and identify synthetic modeled input.
3. SeQUeNCe reservation contention is a good complementary network example: display native deliveries and occupancy alongside admitted/rejected requests. Keep it labelled stationary fiber network, not quantum satellite routing.
4. kuibit GW150914 is appropriate only with conspicuous “published output reanalysis” and original dataset attribution; never caption it as a fresh PF black-hole merger simulation.
5. PyMC/SALib can illustrate estimation vs sensitivity, but the synthetic counts/distribution assumptions must be visible. Do not blur posterior sampling with empirical validation.
6. Do not add MATLAB, Swabian acquisition, or paid AI imagery as executed demonstrations without genuine execution/data. Catalogue their available adapter and stated prerequisites instead.

Avoid saturating the home page with logos. A compact engine strip can lead to the detailed integration catalogue, with selected gallery stories demonstrating distinct research questions rather than a list of vendor names.

---

r34 satellite and quantum-workflow audit

Validated against the corrected r34 source in the corrected r34 package. No PF source files were edited. This audit concerns implemented capability and bounded executed evidence, not hardware or operational mission qualification.

Safe public wording

Live satellite forecasts for quantum-link research. PF Simulation retrieves published orbital elements from CelesTrak and propagates satellite states at the requested UTC times. Researchers can connect those trajectories to moving-endpoint photon propagation, visibility, timing and quantum-channel models, then compare SGP4 predictions with matched numerical orbit models. Save the exact inputs and replay the experiment as your assumptions evolve.

What “live” means: current-UTC model updates using periodically refreshed GP/TLE elements—not streaming spacecraft telemetry or measured photon data. A configured update interval is a minimum; solver runtime can make updates slower.

Research value: study how orbit-model choices and declared hardware/channel assumptions affect predicted link opportunities and timing; inspect model discrepancies under matched initial states; preserve inputs and selected-epoch artifacts for reproducible follow-on studies. This enables controlled design comparisons; it does not establish mission accuracy or a PF performance advantage.

Verified implementation

Avoid claiming “instant telemetry,” “nanosecond satellite accuracy,” “guaranteed quantum advantage,” or that sample spacecraft carry the modeled quantum instruments. Likewise, SeQUeNCe stationary fiber/router experiments must not be presented as a directly coupled moving satellite/free-space network backend.

Fresh executed validation for this enhancement

• Python 3.12 validation environment; tracking dependencies available. test_real_time_tracking.py and test_audit_tracking_replay.py: 51 passed, 2 expected timing-policy warnings; 34.02 seconds. Tests include Vallado reference propagation, transforms, invalid/stale/missing data policy, explicit time inputs and real GUI/CLI replay behavior.
• A real run_comparison.py replay completed from the r34 config_comparison_replay.json, overriding only horizon to 120 s and orbital sample count to 13. Command and results are in matched_replay.log and matched_replay/.
• Exact start epoch: 2026-09-16T18:32:00Z. This is a historical replay, not a fresh online data fetch. It uses unchanged CelesTrak captures for ISS (25544), TECHNOSAT (42829), and HST (20580) as illustrative emitter/detector orbit roles.
• 39 orbit-comparison samples (13 per spacecraft), with SGP4 and matched DOP853/J2 predictions. All start-state differences are zero. Maximum position differences across 120 s: ISS 2.666875 m, TECHNOSAT 3.063653 m, HST 3.201510 m. These are differences between predictions, not measured orbit errors.
• 18 photon/quantum scenario epochs executed: 3 scenarios × 3 epochs × 2 orbit branches. Both branch validation reports passed; all 18 epochs had resolved propagation and Earth-clear pair geometry. Scenario 3 reused Scenario 2's physical events as configured. Phase noise and storage were disabled; source depolarization remained 0.005.
• Conditional fidelity was 0.996250 and purity 0.99251875 for all these epochs under the same declared zero-phase-noise channel. This is a model result, not a PF advantage or observed satellite result. Finite-count sampling was off; no measured counts were collected.
• No live HTTP acquisition, hardware, calibrated optical receiver, QKD key exchange or API account was exercised for this evidence.

Gallery recommendation

Add “From satellite forecasts to quantum-link studies” as one gallery case, clearly tagged Historical GP replay · SR model. Show actual propagated orbit geometry and a separate matched-orbit residual plot. Explain the research decision: compare orbit assumptions before transferring an actual saved state into a scientifically applicable companion study. Keep configurable quantum-channel assumptions close to any fidelity/rate figures; do not give this example a headline implying a superiority result.

Gallery reproduction includes the exact saved configuration and original public GP input provenance. The public config should be copied from the canonical r34 preset with the 120-second/13-sample overrides and package-relative fixture paths, so it runs from an extracted r34 root.

---

r34 Qiskit integration audit for website copy

Audit date: 22 September 2026. Authority: actual r34 source and configuration, inspected without modifications. This is a scoped review and fresh representative numerical run, not a new full-platform validation claim.

Accurate capabilities and evidence

The implemented capability registry explicitly states that an adapter is a bounded operation, not access to every upstream API. It explicitly excludes physical QPU execution and automatic SPAM calibration for tomography. No IBM Runtime hardware execution entry point was found in the examined mission, quantum benchmark or scientific integration code.

Existing validation safeguards inspected

• test_execution_authenticity.py injects Aer exceptions/unsuccessful results into density-matrix and tomography jobs and requires execution failure to propagate.
• test_quantum_channel.py checks matrix reconstruction, qubit ordering/Y-sign and statistical estimators.
• test_competitive_channels.py spies on actual Qiskit DensityMatrix.evolve calls and checks analytical channel limits.
• test_r24_quantum_tomography.py contains actual state/process tomography execution and exact raw-count replay, malformed-setting rejection, asymmetric bit-order and acquisition-metadata tests. These tests were inspected, not freshly run here because the optional Qiskit Experiments dependency is absent.
• test_r26_workflow_bridge.py explicitly tests that tomography of a saved mission density matrix preserves its coherences and remains labeled simulated counts.

Fresh gallery validation

See README.md and results/aer-gallery-summary.json: 42 actual Aer density-matrix evaluations, ten actual nine-setting tomography runs, 737,280 simulated measurement shots, 210/210 exact-state/reference checks. Maximum fidelity/purity reference errors are 2.00e-15 and 3.11e-15 respectively. Figures have been visually inspected. All complex state data, original counts, scalar plot CSV, per-case settings/seeds, reproduction driver and PF module hashes are preserved.

Recommended cohesive website language

Quantum modeling with Qiskit and Aer. Evaluate encoded polarization states, configured quantum channels, fidelity and purity alongside PF's classical trajectory and link calculations. Inspect exact density matrices and optional simulated measurement counts, then trace the assumptions and evidence behind each result.

Tomography through Qiskit Experiments. Optional research workers support two-qubit state and one-qubit process tomography, including studies derived from saved mission states and replay of explicitly labeled acquisition records. Raw counts, reconstructions and fit diagnostics remain inspectable.

R&D interpretation. The practical benefit is a connected and reproducible path from a declared physical scenario to state/channel diagnostics and bounded cross-checks. The new Aer gallery demonstrates why noise covariance and encoding should be considered together, while keeping exact predictions separate from finite-shot estimates. Avoid promising experimentally proven design savings, faster simulations, commercial superiority, validated quantum advantage or hardware execution: these fresh results establish none of those outcomes.

Source anchors

• quantum_channel.py: module contract; simulate_polarization_pair; sample_tomography_from_density.
• pf_benchmarks/protocols.py: module contract and protocol execution; pf_benchmarks/channels.py: channel tomography execution and defaults.
• pf_integrations/tomography.py: validate_records; design; run; returned limitations and artifact manifests.
• pf_integrations/capability_registry.py: tomography/quantum bounded-operation contracts and mission applicability.
• pf_integrations/workflow_bridge.py: mission_state_tomography companion and saved-state lineage.
• pf_integrations/runner.py: optional backend dispatch and provenance/version manifest.
• config_r24_tomography_state.json; config_r24_tomography_process.json; requirements_research_integrations.txt.
• Existing release collateral explains Aer polarization scope, separate orbit/propagation modules and the difference between numerical implementation agreement and empirical evidence. Use current source limits if older collateral overgeneralizes process-tomography exclusions.

---

Upstream format and simulator references

The PF-specific catalogue above is grounded in r34 code. CelesTrak documents its GP formats at https://celestrak.org/NORAD/documentation/gp-data-formats.php and Qiskit documents Aer simulation methods at https://qiskit.github.io/qiskit-aer/stubs/qiskit_aer.AerSimulator.html . These upstream capabilities do not imply that PF exposes the entire upstream API.