PF Simulation r34 — Intelligent Scientific Analysis and Evidence System

ISAES redesign and autonomous investigations · Reporting engine 2.3.0 · Product release remains r34

ISAES turns retained scientific results into traceable analyses, interactive figures, reports and presentations. Its classical reporting pipeline works without an AI provider, credentials or model weights. Optional reviewed report discussion and unattended autonomous investigations use the existing provider and BYOK controls under explicit enablement and owner policy. Existing private workflow programs, scientific layers, authorization, regular storage and Bring Your Own Storage remain in the existing platform.

This autonomous revision builds on archive SHA256 1987acf5712a7d2311744089bfb350885501bd925e18a2c31ee43447329d6a74. Earlier reporting, assistant, documentation and figure-gallery receipts remain historical evidence for their original frozen source. See MANIFEST.json for the installed package's current validation identity. The autonomous requirements and qualification boundaries are mapped in ISAES_AUTONOMOUS_ACCEPTANCE.md.

Delegate an unattended investigation

The new autonomous ISAES guide describes per-workflow standing delegation. Once explicitly enabled with provider sharing and the permitted capabilities, a completed scientific run can start its investigation without a chat prompt or approval at every step. The investigator develops a plan, reads associated literature, performs permitted contextual online discovery, computes analyses, assesses claims, produces scientific figures and presentations, and refines or finishes within cumulative budgets.

Generated scientific and presentation code extends the investigator beyond a fixed menu of methods, inside the configured isolated runtime and installed compatible libraries. Original solver/results remain retained. New analyses and child runs have their own execution evidence; claims retain source versions, limitations and their AI attribution. The UI provides durable progress, pause/resume/cancel and policy controls. Native exports and storage/lifecycle handling retain the same evidence chain.

This delegation is separate from Discuss report and its reviewed-proposal workflow below. The deterministic reporting pipeline remains usable without any AI configuration. Enabling autonomy does not establish live-model scientific correctness, researcher usability, native Windows or production/BYOS qualification.

Use the redesigned workbench

Open Documentation in either standalone or the signed-in SaaS workbench for this guide, the report-assistant guide and the complete end-user manual. Manual Chapter 32, ISAES: from workflow results to evidence, is the illustrated task walkthrough. Markdown guides open as readable source text; the manual is a PDF.

1. Install or update the research environment through the existing setup process. The Python 3.12 reporting worker needs the packages in requirements_reporting.txt; these are included by the existing research/assistant requirement chain. The launcher and doctor identify missing reporting components. Provider credentials are unnecessary for reports.
2. Open My workflows, select an activated private workflow and run it, or choose an existing completed run in Run history. Inspect its ISAES scientific report section below the run outputs. Reporting uses retained scientific outputs and does not rerun the original simulation.
3. Use the reporting controls to enter a research question, exploratory or confirmatory intent, audience and dataset meaning. A dataset identifies a retained output pointer or JSON artifact, a scientific kind, and relevant units, frame, basis, sampling or method settings. The advanced JSON editor preserves settings not exposed by the guided controls.
4. Inspect the independent status dimensions, findings, assumptions, checks, uncertainty and analysis decisions. Open the evidence details to trace a finding to its source and method.
5. Open the embedded interactive report in the authenticated workbench for linked point inspection, table filtering, retained frame selection and saved exploration state. A standalone interactive HTML export is also available. Linking uses explicit observation identities; coincident array positions are not automatically the same experiment. Exported HTML is self-contained and uses locally included Plotly code.
6. Download PDF, PPTX, presentation/visualization JSON, the export manifest, or the complete ZIP. Slides contain editable text/tables and scientific figures; arbitrary scientific plots are embedded images. SVG and exact figure JSON/CSV are available inside the ZIP.
7. Compare retained report revisions or saved runs through the workbench. This comparison displays the saved values, method/source differences and missing findings. Statistical scenario contrasts use the registered comparison method with declared scientific prerequisites.
8. Save and restore the active exploration directly in the workbench. A saved view is bound to the visualization plan and report identity. Export the current view as a new rendering revision: PDF, slides and figures reflect the retained selected checkpoint and display filters, while original findings, exact source values, report bytes and scientific runs remain unchanged. Further revisions can be exported from that view; bounded ancestry is validated on every render. JSON import/export remains available.
9. When optional report discussion is enabled, choose Discuss report. Return to Refresh report proposals to inspect exact changes and choose Approve proposal or Reject proposal. Approval records a decision only. Apply proposal to new revision queues an approved analysis or view change; select Run report to execute it. Interpretation proposals remain separate commentary. The operator enables controlled evaluation with PF_ISAES_AI_ENABLED=1 and the existing provider/BYOK setup; see the report-assistant guide.

The supplied documentation/workflow_examples/qiskit_floquet_isaes.json is an importable six-qubit, eight-cycle example with enhanced shared quantum evidence analysis. Its embedded scientific program is unchanged from the existing Floquet example. It adds reporting metadata for local-state and joint evidence interpretation. The original example remains available for compatibility. The new documentation/workflow_examples/qiskit_floquet_isaes_v2.json separately versions the program to retain actual reduced-q0 state checkpoints at each cycle, linked to the original trajectory and table. These are explicitly local reduced states; the display does not claim intermediate full-register states were recorded. Both six- and eight-qubit workloads remain bounded. The nonquantum documentation/workflow_examples/srgr_timing_isaes.json executes the production SR/GR radial-ray path with explicit clock, coordinate, metric and unit semantics.

Interpret the statuses

A complete report can contain a failed physicality or agreement check. An incomplete report preserves useful results while showing unsupported methods, missing semantics or conflicting requirements. A failed job identifies an execution, environment, storage or export problem and retains eligible analysis for retry.

Released scientific capabilities

Methods use explicit scientific prerequisites. An ordered trajectory is not treated as a collection of independent experiments. Local Bloch vectors alone do not establish entanglement. A fitted model does not become a new executed simulation. Error mitigation does not guarantee an ideal answer. Literature relevance does not establish applicability.

The detailed schemas and worked examples are in:

• Original-scope implementation matrix
• Developer SDK and capability contracts
• Autonomous investigations, setup and controls
• Autonomous requirements and acceptance evidence
• Optional report assistant and reviewed proposals
• Scientific methods
• Tomography and phase-space protocols
• Domain adapters and legacy migration
• Acceptance and external qualification
• Quantum evidence and adapters
• Visualization and presentation
• Persistence, literature and evidence API

Literature, history and recovery

The literature list is shared across your own workflows. Archive document changes that owner's document status everywhere; it is not a way to remove one workflow association. Archiving is the normal action for literature already in use: it hides the item from new-association choices while preserving its identity, bytes, existing associations, extraction history and retained reports. Restore it before creating another workflow association. The workbench separates active materials from the archived-materials section and identifies selected-workflow associations.

To stop using a document in one workflow, edit that workflow's selection and save its associations. This creates a new configuration revision; older associations remain visible to retention checks. Choose Review association release when you need to resolve those older administrative links. The preview groups current and historical associations by workflow, explains protected references and requires explicit selection of the workflows to release.

Release selected associations removes only that document's administrative selection links in the chosen workflows. It retains the original configuration records and appends hash-bound release receipts; a new current configuration keeps all other document selections and reporting settings. This operation does not delete the document, archive a workflow or rewrite scientific/report snapshots. Reporting-reference mappings, workflow bundles, runs, validations, reports and private layers remain hard blockers for permanent document deletion. Their presence does not prevent releasing administrative selections; they simply remain protected afterward. Unknown or unreadable dependencies block release because its scope cannot be verified.

Permanently delete document remains visible for active and archived materials and performs a fresh check before proceeding. Check deletion eligibility shows the retained dependencies and inspection errors. Permanent deletion requires an authoritative inspection that finds no retained dependency, followed by a fresh coordinated check. Pending and cancelled jobs, retained reports, fitted-model evidence, figures, decks and saved views continue to protect their inputs. Unreleased historical administrative associations also remain dependencies. After a successful association release, review deletion eligibility again; deletion is a separate explicit action and is never automatic.

Reporting now separates analysis from rendering. If exporting fails, retry can reuse the verified analysis artifact when input, source and runtime identities still match. A code or environment change requires regeneration with a new identity. Cancellation stops publication and leaves retained ancestry protected. These report resume/retry controls operate the existing request-driven reporting pathway. The separate autonomous controller can drive permitted investigation tools without per-step prompts while its worker is available; this is not a claim of a distributed scheduler or computation after the application stops.

Workflow reporting can be paused or enabled for selected retained workflow versions. Pausing preserves readers, literature protection and prior exports, and blocks new analysis and rendering revisions. It remains available at normal quota limits through a bounded stop receipt. Confirmatory labeling requires a matching owner-locked plan registered before the recorded scientific run start; post-run declarations remain exploratory. A locked plan records prespecification identity, not independent scientific approval of its hypotheses or study design.

Previously retained schema-1 reports remain readable. New generation uses report schema 2. Regeneration creates a new version and does not rewrite earlier report bytes or scientific runs. Existing private analyzer/renderer hooks remain supported inside isolated workers. Methods executed in a private-extension/layer environment are conservatively attributed to that private environment, including shared methods used there. The trusted parent verifies report schema, hashes and private authority before accepting checkpoints or publishing exports, including retries. Ordinary reporting does not add workflow files to the numerical library import path. These checks do not certify arbitrary private prose or create an in-process Python sandbox; existing isolated-executor controls remain necessary.

Library and deployment boundaries

The shared core supplies contracts, method registration, applicability checks, evidence identity and presentation rules. Scientific libraries run inside the isolated worker; the workbench handles presentation and bounded authorized requests. This does not require microservices or additional remote providers.

The qualified modern reporting dependency set is pinned in requirements_reporting.txt; the base scientific packages remain governed by the existing requirements. Compatibility pins are supplied for the legacy desktop route. The feature acceptance receipts in validation_r34_isaes_ai retain their tested environment and exact package versions; those historical receipts do not qualify the new autonomous controller or remeasure its performance. Native Windows and the legacy Python 3.8 runtime require their own execution qualification; syntax compatibility alone is not an execution result.

Qiskit/Aer and QuTiP object adapters are exercised with their installed SDKs. Mitiq, Qiskit Experiments and chemistry adapters accept documented supplied evidence records; they do not perform remote hardware acquisition, full device calibration, tomography collection or molecular-orbital generation. PyMC/SALib remain available through the existing optional research environment; this release does not claim a general automatic Bayesian-model or sensitivity-design engine. Zarr/Parquet and remote hardware connectors remain workload-specific extension choices rather than mandatory new storage services.

The optional report assistant consumes authorized evidence and retains separately attributed proposals and actual invocation receipts. It cannot approve its own proposals or rewrite scientific findings. The operator must explicitly enable controlled evaluation; provider credentials, institutional policy and ordinary permissions still apply. See the report-assistant guide. Implementation and local protocol tests do not qualify live-provider scientific accuracy or automatically close deployment and researcher gates.

Bounds and validation evidence

The implementation intentionally keeps explicit resource bounds. Current worker admission retains an 8 MiB combined reporting snapshot; an analysis checkpoint is a separate artifact of up to 8 MiB with a small transport manifest. Final structured reports retain the existing approximately 1.8 MiB budget, omitting convenience previews when needed. Exact figure data remains in export artifacts. Workflow artifact and output quotas still apply; these limits are reported rather than silently truncating scientific values.

The quantum state catalog supports one to eight qubits and bounded retained checkpoints, shots and requested observables. Scientific methods have documented array/model/resampling limits. These are supported release workloads, not an unrestricted scalability claim.

The preceding ISAES 2.2.0 feature acceptance records 1,306 distinct Python parent tests and 130 successful subtest executions (1,436 recorded JUnit cases), plus four JavaScript commands in validation_r34_isaes_ai/test_execution.json. Those checks covered reporting, lifecycle, standalone/SaaS, browser, startup, assistant/provider and legacy-report compatibility against that feature release's frozen source. Provider protocol tests used explicit test doubles, with no live-provider scientific qualification. The retained performance and browser receipts remain bound to that same source and workload contract; the current autonomous implementation retains them as historical evidence and records its own fresh checks separately.

Historical documentation-maintenance commands, counts, runtime and source identity are recorded in validation_r34_isaes_documentation/test_execution.json; its reconciliation.json identifies the documentation, navigation and release-accounting delta from the feature archive. That historical maintenance gate checked the updated manual, authenticated documentation links, actual browser navigation and release-reader/startup compatibility. It does not rerun the complete scientific regression, dense-view performance measurements or live-model evaluation.

The original 527-test receipt remains intact in validation_r34_isaes, the 784-test receipt remains intact in validation_r34_isaes_completion, and the feature acceptance remains intact in validation_r34_isaes_ai; historical receipts are never reused as current execution. The entire product scientific benchmark catalog is not implied by reporting or documentation acceptance. The earlier documentation package used release_tools/validate_r34_isaes_documentation.py. Current autonomous execution belongs to validation_r34_autonomous/test_execution.json; use python release_tools/validate_r34_autonomous.py verify --package and the installed manifest for this revision. Its manifest, checksum inventory and qualification registries preserve the earlier evidence chain.

The retained validation_r34_isaes_ai/acceptance_status.json distinguishes feature software qualification from complete original-scope acceptance; the current MANIFEST.json and autonomous qualification records preserve that distinction. Real researcher participation and native/deployed-environment evidence cannot be replaced by scripted browser checks. The qualification tools provide reproducible collection and review procedures; missing external receipts remain pending.

Linux developer-executor and browser evidence does not independently qualify native Windows, production Docker containment, live external BYOS infrastructure, quantum hardware, every optional library combination, or representative-researcher task-performance targets. These limitations remain explicit in the release receipt.