PF Simulation r34 — continuation storage and attachment management

Current hosted execution recovery is described in execution recovery. Deployment-specific upgrades use the native HF guide or public-service guide, with the existing private state and credential keys retained.

This revision adds Remove beside assistant attachments and stores new investigation checkpoints in a compact, lossless format. It retains the r34 scientific core, completed run outputs, private source layers and recorded investigation history. The changes apply to standalone and hosted assistant sessions, including hosted personal storage.

Continue a retained investigation

The assistant now pools repeated long strings, including repeated image payloads, before compressing private checkpoint data. Decoding restores the original JSON values, including provider-native tool history, reasoning/signature blocks and cached results. Compression does not summarize or discard that state.

Checkpoint storage stays bounded:

Stored byte counts and expanded byte counts describe different limits. The Continuation checkpoint capacity details show the available numeric diagnostics and the capacity boundary encountered. These limits are also separate from PF_AI_MAX_CONTEXT_BYTES, provider response limits, the model's token context window and the owner's private-storage allowance. A compact checkpoint can still require a larger context budget to make its next provider request.

The reader accepts intact legacy schema-1 checkpoints as well as the new compact schema-2 envelope. Both must pass the same provider, tool, evidence, profile, credential and source binding checks. Corrupt, oversized or mismatched state is rejected; checksums detect damage and do not replace those binding checks.

Use Continue investigation or Retry saved investigation when the session reports a retained checkpoint. Each action starts one bounded investigation step and remains subject to applicable usage limits. When only the context budget is insufficient, the checkpoint remains retained and the interface reports the minimum required context budget. An operator can adjust that budget within supported limits and reload the application.

An older checkpoint_too_large, checkpoint_storage_limit or checkpoint_unavailable result may have no saved private state. Updating the application, raising a budget, or removing attachments cannot reconstruct it. Start a new question using the remaining evidence and the historical findings. Upgrading also does not bypass existing source or evidence binding checks for a checkpoint that has become stale.

Remove an attachment

1. Open the assistant session and find the attachment below the conversation.
2. Select Remove beside its download link and review the confirmation.
3. Confirm removal. The attachment leaves the active evidence list and its download becomes unavailable.
4. If the session had a saved continuation, start a new question about the remaining evidence.

Removal first commits a tombstone containing the attachment's identity, filename, size, hash and removal time, then deletes its retained payload. If that metadata transaction fails, the active attachment and its bytes remain intact. Historical messages and citations remain unchanged; the removal record marks the payload as unavailable to the session. Removing a file cannot retract material already sent to a model or erase quotations from earlier messages.

If local file cleanup fails, the attachment remains removed from active evidence and its tombstone reports cleanup_pending. The interface offers Retry removal to finish deleting the stored file. New investigations in that session remain blocked until cleanup succeeds, so a file still awaiting physical deletion cannot re-enter the assistant's evidence tools. A retry uses the existing removal record and does not repeat research work. This local cleanup state also survives an application restart.

Removal clears private provider continuation data and saved investigation checkpoints for that session. Its existing investigation status becomes stale with reason attachment_removed, so the assistant cannot resume against evidence that is no longer available. Completed scientific runs, result artifacts, proposals and source layers remain retained.

Only users allowed to edit a hosted project can remove attachments. Removal requests are scoped to the current owner and session; repeating a successful request for the same attachment is safe. An attachment from another session cannot be removed through the current session.

Selecting a file uploads it immediately. The file chooser clearing itself after upload means that selection has been processed; it does not remove the uploaded file. New identical uploads in the same session reuse an active attachment when filename, SHA-256 and byte size all match. The supplied matching bytes also repair a missing or corrupted retained payload; personal storage verifies or repairs its remote object before reporting durability. An unavailable storage destination remains a retryable pending operation rather than a successful duplicate acknowledgement. A different filename or different contents creates a separate attachment. Existing historical duplicates remain available for explicit removal. Re-uploading a removed file creates a new active attachment; its earlier removal record remains in the audit.

Personal storage and pending removal

When personal storage is enabled, removal also deletes the corresponding remote object. If that storage operation fails, the active attachment remains removed from the session while a durable operation journal records the unfinished deletion. The interface reports pending_delete and offers Retry removal. It does not report remote deletion as complete before the storage operation succeeds.

Restore the session's configured storage destination if necessary, then select Retry removal. The retry finishes the retained storage operation without repeating model requests, tool calls or scientific execution. Other profile mutations remain paused until the pending operation is resolved. A process interruption with uncertain effects remains an operator-reconciliation case; it is not automatically replayed as an ordinary completed-operation retry.

Upgrade and verify

Keep the existing assistant database, stored evidence, personal-storage configuration and both credential-vault keys as a consistent recovery set. Stop the API and workers, install the new r34 package and apply python -m pf_saas init for schema 10. Configure project access and institutional AI policy, then restart and reload the browser. Do not purge saved history to clear a capacity warning. Use the lifecycle and recovery guide and Linux hosting reference.

Verify an untouched package extraction with:

python release_tools/package_r34_public_service.py verify --package

Current public-service and UI-correction evidence is under validation_r34_public_service. The retained validation_r34_lifecycle record includes assistant-storage, lifecycle and enhancement checks. The earlier adoption acceptance retains its original regression identities, continuation/attachment and provider-lifecycle evidence. Read current validation for exact counts and completed outcomes. Historical execution records and source hashes are not regenerated against this revision.

Saved investigations must still match provider, credential, evidence and source/profile bindings. The current research policy and any required consent are rechecked before every outbound attempt, including continuation and retries. Upgrading source can invalidate an older checkpoint; it does not create a new valid continuation from transcript text.

Acceptance uses scripted provider responses, real local numerical execution and controlled storage endpoints. Actual-host Docker/PostgreSQL, live provider and cloud/NAS behavior require separate deployment acceptance.

Delete a saved conversation

Use the end-user Delete conversation control and review its confirmation. It removes transcript messages, provider continuation context, checkpoints and conversation attachments. Saved workflows, layers and derived runs remain independent. Retained source/input evidence needed by those objects can remain in an execution-only context without chat messages. Saved derived runs provides Inspect saved run and Discuss saved run; discussion starts a fresh conversation without restoring deleted messages or rerunning the study. Pending cleanup and retry behavior are described in the lifecycle guide.