PF Simulation — r34 adoption implementation

Retained adoption implementation and evidence. The current r34 package retains these adoption controls and includes the subsequent public-service and interface corrections. For an untouched extraction, run python release_tools/package_r34_public_service.py verify --package. See current validation and lifecycle/rollback guidance. Commands and counts in the historical adoption sections below apply to their recorded source revision; they are not the current package verifier.

This update retains the r34 validation-refresh revision version and adds the software work requested for A2, B1 and the applicable B2/B3 adoption controls. PF Simulation, PF Research Workbench and “From equations to evidence” retain their identities. The numerical models and their scientific validity limits are not expanded by these changes.

Implemented scope

The hosted Team interface exposes project sharing, membership and research-AI policy administration. The hosted assistant requests disclosure consent when the effective policy requires it. Access and transmission restrictions are enforced by the server as well as presented in the interface.

Upgrade and configuration

Back up the database and artifact/private state together before upgrading. Run the documented SaaS database migration with the API and workers stopped. The additive schema migration preserves existing organization-shared projects; it does not silently make them confidential. Administrators must select restricted sharing and explicitly grant the intended members. Organization administrators can administer project grants, including an audited grant to themselves; a restricted project does not isolate research from its trusted organization administrators or host operator.

Existing installations retain the legacy AI-policy default until configured. The new reference deployment selects PF_SAAS_RESEARCH_POLICY_DEFAULT=institutional, which disables external AI by default. An authorized administrator must configure approved providers, endpoints and data/disclosure rules before enabling it. Project policy can tighten organization policy but cannot relax it. Policy does not automatically classify files, guarantee provider retention or establish a provider's legal data location; the institution must approve those arrangements separately.

Personal storage continues to retain PF metadata on the host. Conversations, checkpoints, permissions and code-layer metadata are not automatically removed from host storage by selecting BYOS. Follow the deployment and data-policy guides for the actual data boundaries and retention responsibilities.

Verify the original adoption revision

From the extracted package root:

python release_tools/validate_r34_adoption.py verify --package

The compatibility command remains available:

python release_tools/validate_r34_refresh.py verify --package

The adoption revision’s source and evidence bindings are in validation_r34_adoption. Its baseline.json identifies the exact incoming first-refresh archive and maps every incoming file to its retained original bytes. Changed incoming files are preserved under validation_r34_adoption/incoming_files. Earlier validation folders retain their historical records; their original hashes are not rewritten to make them appear newly executed.

The retained 117-file core map is also preserved. Its current-revision checks distinguish 114 unchanged members from three reviewed maintenance changes: research_qualification.py, result_reporting.py and run_privileged_frame_simulation.py. They verify that the earlier bytes remain recoverable, and bind the current bytes to the frozen input and explicit review. The broader current core scope additionally includes qualification_integrity.py and pf_docker_runtime.py; these additions are accounted for separately. The two legacy core-test identities remain in the original acceptance selection, with revision-aware assertions instead of an incorrect claim that every old core file is still unchanged.

The acceptance plan and per-file review are release_tools/qualification_adoption_checks.json and release_tools/qualification_adoption_review.json. Each changed release input is bound to the review and successful checks. The fresh test record identifies the exact source inventory, runtime, commands, logs and results. Current qualification registries retain the previous scientific statuses and scopes while binding the maintenance changes to their actual new evidence. Hashes establish byte integrity, not publisher authentication or scientific truth.

For a new controlled rebuild, prepare the exact incoming archive, execute the recorded plan against frozen inputs, then build and verify the records:

python release_tools/validate_r34_adoption.py prepare --baseline /path/to/incoming-r34-validation-refresh.zip
python release_tools/validate_r34_adoption.py run --plan release_tools/qualification_adoption_checks.json
python release_tools/validate_r34_adoption.py build --review release_tools/qualification_adoption_review.json
python release_tools/validate_r34_adoption.py verify
python release_tools/validate_r34_adoption.py seal --output /path/outside/source/PF_Simulation_Standalone_and_SaaS_r34_validation_refresh.zip
python release_tools/validate_r34_adoption.py verify --package

Evidence counts and acceptance boundaries

The original acceptance result comprised 1,806 collected test items and 454 subtests, reported as 2,260 by that execution's JUnit totals. The current plan requires every one of those original test identities to remain covered and reports newly added items separately. Other suites and lifecycle checks have their own counts and scopes; overlapping suites must not be added together as if they were unique tests. The first-refresh targeted result is a separate historical execution, not a reduction in the original suite.

Read validation_r34_adoption/test_execution.json for actual fresh counts and outcomes. Development runs do not replace the acceptance records from the final frozen source. No paid external-AI request is required by the local fixture checks.

A2's local replay evidence does not establish reproduction by an independent researcher on every supported platform. B1 supplies the complete reference configuration and operational procedures; the upload → simulation → assistant proposal → validation → activation → rerun → storage/export workflow still requires acceptance on the chosen Docker/PostgreSQL host. Docker execution was unavailable in the implementation workspace. B4 production operations, institutional approval of B3 retention/location arrangements, and the other unrequested adoption items remain outside this implementation's claims.