PF research library · 5 min read
Scientific APIs across PF workflows
r34 documentation · workflow-integrations.md
The workbench can launch a scientific companion from a completed mission job. Each companion records the selected parent artifact, epoch, exact input hashes, derived settings, numerical checks, actual plots, and sources. Companion results are separate experiments with explicit scope; they do not overwrite the parent prediction or turn a numerical check into empirical qualification.
Executed-data companions
| Companion | Consumed parent data | What actually runs | Boundary |
|---|---|---|---|
mission_state_tomography |
Complete complex conditional density matrix, tensor order and state provenance | Qiskit Aer prepares that density matrix; Qiskit Experiments reconstructs newly sampled counts; independent Born-rule inversion checks the reconstruction | Counts are synthetic, including when the original imported state was a measured reconstruction; a state does not identify its channel |
mission_memory |
Actual memory input and final density matrices, executed per-arm proper holding durations, normalized T1/T2 | QuTiP solves the Lindblad equation; PF's production Kraus channel independently evaluates the same model; the saved parent final matrix is also compared | Independent local Markovian memory only; retrieval/optical loss stays separate; no gravitational dephasing is inferred |
mission_schwarzschild |
Actual saved satellite radii from a completed static-GR mission | EinsteinPy symbolic metric/curvature and PF metric, static-clock and radial-null references at those radii | Static radial reference, not the original moving-satellite photon path |
mission_orbit_reference |
Actual saved Cartesian satellite position/velocity, recorded duration and declared force model | Orekit and PF propagate a reference orbit initialized from the derived Newtonian osculating elements | The reference is reoriented and starts at pericentre/J2000; this is explicitly not the original epoch-matched mission trajectory; drag is rejected |
mission_spectral_channel |
Actual solved GR ray endpoints, covectors, clock rates and the same saved GM/body radius | The ray boundary-value calculation is repeated; EinsteinPy checks endpoint clocks; the invariant frequency ratio drives a declared Gaussian receiver mode and an actual QuTiP bosonic channel | Spectral single-rail receiver-mode loss and an ideal heralded protocol are separate from parent polarization decoherence |
All five are applicable to simulation, orbital comparison, precision, and assurance jobs when the selected result supplies their required fields. The same shared bridge is used by the standalone and hosted workbenches. Successful application to a precision nominal result does not repeat the parent's entire uncertainty ensemble; successful application to an assurance result does not close its experimental-evidence gaps.
The spectral companion displays its additional receiver assumptions explicitly: default carrier 700 THz, spectral intensity standard deviation 1 MHz, no compensation, zero residual delay. These are editable declared optical-mode assumptions. They are not inferred from the parent's detector bandwidth. The carrier/spectral-width ratio must be at least 20. Compensation may preserve the received state while changing receiver-mode matching; a frequency shift is not automatically decoherence.
Unavailable prerequisites produce an explanation. A missing state is never reconstructed from fidelity, a failed memory operation is never replaced by a demonstration, and an occulted ray is never substituted with a visible ray. Physical fields cannot be overridden through companion options.
Standalone reproduction
Use the Python 3.12 research environment. A parent request is the ordinary saved request.json object containing workflow, config, and options. The parent output folder contains effective_config.json and actual scenario outputs, including nested nominal outputs where applicable.
.venv_research\Scripts\python.exe run_workflow_integrations.py --capabilities
.venv_research\Scripts\python.exe run_workflow_integrations.py --request path\to\request.json --parent-output path\to\output --list
.venv_research\Scripts\python.exe run_workflow_integrations.py --request path\to\request.json --parent-output path\to\output --selection selections.json --output linked_studies
Example selections.json for a parent that actually executed memory decay:
{
"studies": [
{"companion_id": "mission_memory", "options": {"artifact_path": "scenario2.json", "epoch_index": 0, "points": 51}},
{"companion_id": "mission_state_tomography", "options": {"artifact_path": "scenario2.json", "epoch_index": 0, "shots": 10000, "seed": 7331}}
]
}
Only the selected artifact's exact saved epoch is used. Directory paths are not accepted inside the browser request. The standalone artifact reader accepts fixed JSON basenames, rejects symlinks/traversal, and enforces 32 MiB per file, 128 MiB total and 256 files. Discovery examines a bounded first 256 epochs per companion; an explicit selected epoch beyond that search remains independently validated.
The output includes:
derived_requests.json: replayable research requests with explicit assumptions and lineage.- A separate directory for each executed child, preserving effective settings, source-bound evidence, backend data, numerical checks and visualizations.
workflow_integration_report.json,.mdand.html: an aggregate status/evidence view and the actual child plots, without combining unrelated physical metrics.workflow_evidence_manifest.json: hashes of parent request, all child evidence and reports.
Source hashes bind the code used by each research study. File hashes establish integrity against the recorded manifest; they do not establish external source authenticity or independent replication.
Other API families and applicability
run_workflow_integrations.py --capabilities exports the complete workflow-by-API-family matrix. Every cell states supported, reference_only, inapplicable, or unimplemented, with a concrete reason and the relevant operation limits. These categories are separate from installed runtime availability and executed validation status.
The existing SeQUeNCe, PyMC/SALib, time-tag/Swabian, published-data, FMPy and licensed MATLAB/Simulink operations remain directly available as research studies. A standalone batch may attach an explicit reference_study to a scientifically compatible parent; that relation is labelled explicit_contextual_reference, never derived validation. Backend schemas, managed input policies, runtime requirements, and study-specific limits still apply.
Examples of important boundaries:
- SeQUeNCe's stationary fiber/router model is not silently converted into an orbital free-space link.
- PyMC memory observations and SALib uncertainty bounds must be declared for their specific pure-dephasing model. They are not inferred from unrelated mission uncertainty settings.
- Swabian requires the actual vendor SDK and recordings; no hardware or acquisition qualification follows from a successful CSV replay.
- The pinned reference FMU and fixed MATLAB/Simulink clock model do not identify a spacecraft controller from mission settings.
- Einstein Toolkit execution and kuibit diagnostics have their own supported benchmark/import domain. A generic three-dimensional AMR metric is not automatically a satellite ephemeris or photon propagation model.
- Standalone quantum component benchmarks have no satellite trajectory or spacetime to transfer to GR/orbit tools.
The operation manifest documents the functionality actually implemented. It does not claim to expose every upstream solver, thorn, function, hardware target, or visualization in those libraries.