Choose your research environment

Your work.
Your controls.

Project membership, institutional AI policy, private enhancements and storage choice support an environment aligned with your institution’s confidentiality and infrastructure requirements.

Watch project access and AI policy in action

From interface choices
to server enforcement.

Follow the B2 and B3 controls in the PF Research Workbench: restrict a project, grant and revoke access, configure organization and project AI policy, and review disclosure consent. Recorded server checks show how those choices apply to direct requests, queued work, retries and continuation.

Project access and AI disclosure8:26

B2 / B3 GUI and server walkthrough · Narrated · English captions

Follow project sharing, viewer and editor grants, revocation, institutional AI policy and disclosure consent. Actual interface captures are paired with server checks using demonstration accounts and scripted provider replies.

Jump to a chapter

Private workflow programs and results

Reusable controls.
Enforced research boundaries.

My workflows retains each user’s program, schema, immutable versions and run evidence in its research context. B2 authorization applies on the server, and AI-assisted authoring obeys B3 provider, source-disclosure and consent policy. Project sharing does not automatically share another member’s private workflow.

Private by application scope

A subsystem that belongs
to your research workflow.

Keep enhancements separate.

Private layers are scoped to their owner and research context. Another ordinary user does not inherit access to your layers. Active overlays customize permitted scientific code for your runs without changing the shared installation.

Keep decisions traceable.

Review diffs, numerical comparisons and activation records. Layer order and dependencies are preserved. You explicitly activate passing candidates and can manage or delete layers within the stack’s dependency rules.

These are application access controls, not a guarantee of absolute IP isolation. Hosting administrators and infrastructure are not cryptographically excluded. Your deployment and provider agreements determine additional confidentiality and retention protections.

Project access

Choose who can read.
Choose who can run.

Shared or restricted projects

Projects can remain organization-shared or use explicit viewer and editor grants. Project grants cannot exceed a member’s current organization rights. Existing projects stay shared until an administrator restricts them.

Access follows current permission

Project lists, jobs, artifacts and assistant access respect membership. Revocation is rechecked for queued work and running-job completion; running workers stop through their cancellation mechanism.

Restricted projects have no automatic application-administrator data bypass. Organization administrators can make audited grants to themselves; infrastructure administrators remain trusted. Previously downloaded copies cannot be recalled.

Read project access and migration rules

Institutional AI policy

Approve the disclosure
before the request.

Organization and project policies jointly restrict external AI, providers, compatible endpoints, data classification and source disclosure. A project can tighten organization policy. BYOK uses the same checks.

Consent with a defined scope

When required, consent is bound to the user, project, policy and selected provider configuration. It expires after 24 hours. Current access, policy and consent are checked again before every outbound attempt, including retries and continuation.

Defaults that need deliberate setup

The new Linux reference starts with external AI and source disclosure disabled. Existing installations retain their legacy default until configured. Administrators assign classifications and approve provider retention and data-location arrangements.

Read AI policy and consent controls

BYOK / Bring Your Own Key

Choose the AI account
behind your investigation.

SaaS deployments can enable per-user credentials for all five integrations: OpenAI, operator-approved OpenAI-compatible endpoints, DeepSeek, Google Gemini and Anthropic / Claude. Standalone uses locally configured credentials.

Separate credentials and billing.

Hosted personal keys are stored in the credential vault and excluded from frontend settings responses. Missing or invalid personal credentials do not fall back to the operator’s key. A saved key remains available when the settings panel is reopened; saving credentials does not itself test provider access.

Understand what the model receives.

When effective policy and any required consent allow a request, the configured provider receives selected evidence, source excerpts and conversation content needed for the investigation. BYOK obeys the same organization and project policy as operator-managed AI. It does not change the provider’s retention practices.

BYOS / Bring Your Own Storage

Choose where bulk
research evidence lives.

Use an approved S3-compatible HTTPS destination or the outbound Linux / POSIX NAS connector. Regular PF-managed storage remains available. Changing your default destination does not silently move earlier runs.

User-owned bulk storage

  • Large inputs, outputs and evidence payloads
  • Resources pinned to their original destination
  • Recorded length and hash verification
  • Recovery and retries after transfer failures

PF-managed control records

  • Accounts, permissions and run identities
  • Conversations and continuation checkpoints
  • Layer changes, diffs and activation records
  • Trusted hashes and validation records

PF workers need readable access to files and use temporary working storage for execution. Offline or full user storage can interrupt access to uncached files. BYOS moves bulk retention costs and responsibilities; it does not remove compute, temporary disk or network costs.

Operator-managed deployment

Connect the services
around the workbench.

The complete Linux reference combines PostgreSQL, durable API and worker state, rootless numerical execution, HTTPS and backup/restore procedures. It includes project access and AI policy setup. Actual-host operational acceptance is still required.

Configured hosted deployments can use AWS Batch for simulation jobs, managed AWS S3 for artifacts, Amazon Cognito for identity, Stripe for billing and SMTP for transactional email. These are optional operator integrations with their own account and configuration requirements.

The AWS/Fargate template serves its ordinary-job topology; assistant flags alone do not provide the full reference runtime and durable state. The public website does not activate these services. An institution’s separate PF deployment determines which connections are enabled, who operates them and how research data is handled.

This public website

Public examples.
No research credentials required.

This website presents documentation and recorded demonstration results. It does not ask for API keys, connect to your research storage or execute private simulations. No analytics, advertising scripts, contact forms or application cookies are included in the supplied website code.

The hosting service may process ordinary request and access logs. Following an external link brings you under the destination’s practices. The separately deployed PF workbench has its own account, data-handling and operational requirements.