# Scientific APIs across PF workflows

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.

```bat
.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:

```json
{
  "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`, `.md` and `.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.