Optional ISAES report assistant and reviewed proposals

Current reporting framework 2.3.0; PF Simulation release r34. The report-assistant feature acceptance below retains its original 2.2.0 source scope. See the current release and validation.

The report assistant discusses one retained ISAES report. It reads bounded evidence through the existing owner-scoped reporting service and can propose an interpretation, analysis change or saved-view change. Researchers review proposals before application. Original observations, scientific findings, numerical checks and report bytes remain retained.

The classical reporting pipeline remains independent of AI. Creating, inspecting, comparing and exporting reports does not require a provider or credentials.

Find this guide in the workbench's Documentation tab under ISAES report assistant and reviewed proposals. The adjacent ISAES reporting and evidence guide covers ordinary reporting; Chapter 32 of the complete end-user manual supplies the illustrated end-user walkthrough. These entry points are available in standalone and the signed-in SaaS workbench.

Enable controlled evaluation

This new report-assistant mode is disabled by default. The operator can set PF_ISAES_AI_ENABLED=1 in the environment used to start PF Simulation, then restart it. For example, PowerShell uses $env:PF_ISAES_AI_ENABLED="1" before the normal launch command. Remove the setting or set it to 0 to disable new report-assistant requests. Existing general Research Assistant functionality has its own established settings.

Configure the provider and model through the existing Research Assistant setup. Personal BYOK credentials remain subject to institutional policy, project membership, quotas and provider admission. Enabling the feature does not configure a provider, grant permissions or bypass those controls.

This setting enables controlled evaluation; it is not evidence of production qualification. Native Windows execution, representative researcher usability and applicable hosted/BYOS qualification remain separate gates. Actual provider/model scientific quality must be evaluated using real responses before broad activation. Local protocol test doubles establish the software boundary, not the truth of generated scientific interpretations.

Researcher workflow

1. Open a completed private-workflow run and its retained report in My workflows. Inspect the scientific findings and failed or insufficient checks first.
2. Choose Discuss report. The existing assistant panel opens a conversation bound to that report ID and exact report hash. Provider and credential controls remain in the existing panel.
3. Ask a bounded question, such as which retained finding supports a conclusion, why a check failed, or which additional analysis would help. Report mode does not expose general source-editing, workflow-authoring, shell or automatic execution tools.
4. Inspect Reference checks and interpretation limits and the invocation receipt when available. These show reference and transport provenance. A checked proposal reference means the referenced item was supplied; it does not prove the claim follows scientifically from that item. Final free-text response citations and scientific interpretation remain unassessed; inspected evidence is listed separately.
5. Return to the report and choose Refresh report proposals. Review the commentary, cited evidence and exact policy or view changes.
6. Approve or reject a proposal explicitly. Approval records the researcher's decision and does not execute an analysis. An interpretation remains separately attributed commentary, even after approval.
7. Choose Apply proposal to new revision for an approved analysis or view proposal. This creates a separate queued reporting revision. Choose Run report to execute it, then inspect its outcome, cancel it or retry an eligible failure using the normal controls. Repeating application returns the same child revision, including after an interrupted application; it does not silently launch another calculation.

An analysis revision recalculates reporting methods over the retained scientific run. It does not rerun or modify the simulation. A changed post-run plan cannot inherit prespecified status from a different pre-run plan. A view revision uses the ordinary saved-view rendering path and does not recompute scientific findings.

During an active discussion, use Pause report discussion to request a cooperative pause. An in-flight provider request may finish; processing stops at the next provider/tool boundary. A retained resumable checkpoint can be continued explicitly. Pause does not undo an already retained proposal or executed reporting job; queued/running reporting revisions have their own cancellation control.

Requests against changed report identities fail explicitly. Changes to reporting code or numerical runtime require regeneration before new analysis or rendering revisions. Workflow pause/version controls still apply to execution. Previously retained reports remain readable when execution or AI access is disabled.

Evidence and invocation records

Each reporting conversation is bound to its authenticated owner and retained report. The evidence interface has explicit section and byte budgets and reports omissions and pagination. Literature and all narrative evidence are labeled as untrusted data; they do not become instructions to change permissions or invoke tools.

The trusted application records provider/model and prompt-template identity, actual evidence supplied through the report tools, the response or failure outcome, and associated proposal IDs. Model-supplied metadata is not used to certify that a provider call occurred. AI commentary remains scientifically unassessed; structural reference validation cannot certify semantic entailment, experimental validation or arbitrary private-code physics.

Invocation records belong to the conversation. When an invocation produces a retained proposal, its evidence is also retained with the report so deleting the conversation does not silently remove the proposal's provenance. End-user conversation deletion remains available through the existing lifecycle controls. The separately retained report and its proposal evidence follow the workflow/report retention lifecycle.

No model tool approves or applies a proposal. Provider errors, incomplete investigations and cancellation do not turn an unexecuted proposal into a numerical result. Existing recovery/checkpoint behavior remains explicit; an unavailable continuation is not represented as a successful completed answer. Ordinary reporting remains available during provider failures.

Authenticated API

The reporting routes below are relative to /api/assistant/workflows/reporting. The edition adapters supply the authenticated owner; request bodies cannot select another owner, host path, executor or credentials. Existing CSRF, role and quota controls apply.

Use the existing assistant session message/resume endpoints for discussion. POST /api/assistant/sessions/{session_id}/reporting-pause requests a cooperative pause with an empty object body. GET /api/assistant/sessions/{session_id}/reporting-invocations exposes that owner's retained invocation records. Report-owned copies use the ordinary hash-verified artifact download endpoint.

Analysis proposals carry a validated reporting policy. View proposals carry a validated state bound to the visualization plan and may include presentation options. Interpretation proposals carry commentary and evidence references. External clients can declare AI attribution, but that declaration does not become trusted invocation evidence; the trusted bridge records its own invocation identity separately.

Validation and release boundaries

The preceding ISAES 2.2.0 feature acceptance remains unchanged in validation_r34_isaes_ai: 1,306 distinct Python parent tests and 130 successful subtest executions (1,436 recorded JUnit cases), plus four JavaScript commands, bound to that release's frozen source. It includes native-extension metadata rejection, dependency blocking, proposal ownership and identity checks, review/application behavior, provider protocol compatibility, report-mode evidence boundaries, disabled-provider behavior and the real workbench path using an explicitly identified provider test double. The earlier 784-test completion receipt remains unchanged in validation_r34_isaes_completion.

This documentation maintenance revision adds fresh manual, documentation-navigation and release-reader/startup checks in validation_r34_isaes_documentation. It does not rerun the feature acceptance, scientific regression, performance workload or live-model evaluation. See MANIFEST.json for the installed package's validation identity and the maintenance receipt for its exact commands and counts.

The SDK now rejects absent or null required metadata before native private method/adapter invocation, including conformance fixtures. Shared methods retain their documented descriptive/incomplete behavior and explicit legacy adapters retain their compatibility semantics.

Dense exploration restoration batches linked rendering updates while preserving the retained coordinates, observation IDs, selection and checkpoint semantics. Timing remains workload- and machine-dependent. The measurements retained in validation_r34_isaes_ai belong to the preceding feature release and were not repeated for documentation maintenance; they are not a production service guarantee.

Verify this delivered package with python release_tools/validate_r34_isaes_documentation.py verify --package. Full original-scope acceptance remains pending the external gates described in docs/ISAES_ACCEPTANCE.md.