PF Simulation r34 — Project confidentiality

The r34 validation-refresh adoption update adds explicit project membership for institutions hosting confidential projects in one organization. Scientific engines, standalone workflows and the r34 product version are unchanged.

Sharing modes and roles

• Organization: existing behavior. Active, verified organization members can read the project; editors, administrators and owners can edit/run it. This is the default for existing projects and for project creation when no sharing mode is supplied.
• Restricted: only explicitly granted organization members can access project data. A project viewer can read; a project editor can edit/run subject to their current organization role. Grants never elevate organization rights. Organization administrators and site operators have no implicit restricted data access. An organization administrator/owner can explicitly grant access to themselves through the same audited management API.

Only active, verified organization members can receive grants. A project editor whose organization role is reduced to viewer immediately loses editing access. Removing an organization member deletes their project grants, so later rejoining does not silently restore confidential-project access. Disabling the account or revoking a grant is checked again on each request and transactional mutation. Project archiving continues to block editing and new work.

Administrators should classify each confidential project explicitly; an existing organization-shared project is not silently made restricted during migration. Switching to restricted resets grants and grants the acting administrator editor access. Switching to organization removes grants and makes project data available to the organization. Returning to restricted does not revive old grants. These sharing changes require deliberate administrator action and are audited.

Administration

In the Team interface, Organization member shows an explicit selection prompt until a member is chosen. Selecting a member with a saved project grant loads that grant's role; a member without a grant starts at Viewer. Saving keeps the selected member and displays the role returned by the server. The saved grants list remains the record of who has access.

An organization viewer cannot be assigned effective project editor rights. The editor applies that cap when the member or organization role changes. Moving to another project or organization clears the previous selection. A refresh removes unavailable members from the selector, and delayed responses from an older project cannot populate the current project's controls. A revoked project grant returns the editor to the safe Viewer default without restoring access; an administrator must deliberately save a new grant.

See R34_GUI_BUGFIX_GUIDE.md for this minor build's focused validation and source reconciliation.

The SaaS portal provides project sharing and membership controls to organization administrators. Equivalent authenticated APIs (session cookie and CSRF token are required for changes) are:

All grant, revocation and sharing changes record actor, project, target and role metadata in the existing organization audit log. The audit does not contain scientific inputs, attachments or credentials. Only organization administrators can manage this policy. Another organization's identifiers cannot be used to inspect or modify it. Ordinary project list and account-bootstrap responses omit restricted projects for which the requester has no grant. Project JSON includes effective_role for the requester so the interface respects read-only grants.

Enforcement and deployment

The shared project authorization rule applies to project lists, job submissions, results, logs, artifact/download/export paths, assets, orbit viewing and research assistant project entry points. Internal editing transactions recheck the same rule, including assistant execution reservations and BYOS job migration. Queued jobs are rechecked against their original submitter's current permission before claim; unauthorized jobs are cancelled and their reservations released. Running jobs receive a stop response at their next lease heartbeat. Completion also rechecks permission so a revoked job cannot commit a successful completion. An already executing process is not instantaneously erased; the worker stops it through its normal cancellation mechanism. An administrator who needs to run a revoked submitter's study should submit a new job under their own authorized identity rather than retry it with the revoked original submitter.

Already downloaded copies cannot be recalled. A download or read request already authorized and in flight may finish; revocation prevents subsequent requests. Administrators must control external copies through institutional procedures. Artifact ownership/destination rules remain unchanged.

Back up the SaaS database and stop application replicas before upgrading it. Run the existing explicit database migration command:

python -m pf_saas init

The schema advances from 4 to 5 (this is a database schema version, not a product release). The additive migration preserves all existing project IDs, scientific records and organization-shared access; it adds the sharing column, project-grant table and institutional AI-policy tables. Repeating migration is safe. Newer, incompatible schema versions are rejected before changing tables. Production startup continues to require the matching schema. Restore the database backup alongside the previous software if an operator needs to roll back; no in-place downgrade of access policy is provided.

Local verification

python -m pytest test_r34_project_confidentiality.py test_saas_accounts.py tests_saas/test_http_boundary.py tests_saas/test_jobs.py

Tests cover cross-organization denial, hidden restricted project lists, explicit administrator grants, read/write role caps, grant revocation across HTTP data paths, account disablement, organization removal/rejoin, sharing transitions, audit records and the data-preserving/idempotent schema migration. They exercise the local SQL and HTTP boundaries. Deployment-specific operational acceptance remains necessary on the institution's actual infrastructure.