Project access and AI disclosure: B2 and B3 walkthrough

A complete narrated tour of project access, institutional AI policy and disclosure consent, paired with recorded server enforcement checks.

Watch the walkthrough

Open the video and chapter controls. The player includes English captions, full-screen playback and an MP4 download. The existing research workflow demo remains available in Resources.

Recording scope

Recorded using the r34 member-controls maintenance build. Its compressed package SHA-256 is b4be04061be6618982833563a15c56446c047aaced1fe5c7f59f4839a352dc7b. The current application package is identified in Delivered package and validation. The video retains the site's narrated chapter format. Its GUI sections contain actual moving browser recordings: the pointer, field values, save actions and resulting states are visible. Consent-dialog details are enlarged from the actual recorded pixels for readability. Interactions play at their recorded speed; the chapter timing allows viewers to read the changed settings. Server evidence is presented in separately labeled cards.

The GUI runs the unmodified application locally with SQLite and synthetic demonstration accounts and project data. A small Bell simulation is genuinely executed to supply saved-run context. Provider replies and transport are scripted; no external AI request is made. The server demonstration calls the real FastAPI routes and SQL repositories through an in-process client.

The fresh direct-server demonstration passed 41 observations and a focused selection of 49 B2/B3 tests. All 1,029 release inputs matched the delivered source before and after execution. These demonstration checks are separate from the software build's validation; the full regression was not rerun. The source ZIP includes capture and rendering scripts, action timing, observations, screenshots, clips, narration and source hashes. Temporary databases, session secrets and raw authentication tokens are excluded from the reproduction files.

The worker cards exercise queued-claim, execution-start, heartbeat and completion database boundaries independently. They do not depict an operating-system process being killed. The provider counter measures calls to scripted transport, not network packets to a live provider. Compatible endpoint approval evaluates configuration without a network request. This walkthrough does not qualify a production host, PostgreSQL deployment, external model or customer infrastructure.

What the walkthrough covers

Evidence values shown in the video

A project viewer's read returns HTTP 200, while its upload returns HTTP 403. An authorized editor upload returns HTTP 201. A request without a project grant, or after revocation, returns HTTP 404 in the recorded direct-access cases. A grant exceeding the current organization role returns HTTP 422.

In the consent scenario, institutional denial and missing consent both produce HTTP 403 with zero transport calls. The permitted request after acceptance returns HTTP 200 and raises the cumulative count to one. Revoking consent blocks the next request with HTTP 403; the count stays at one.

In the retry case, a first scripted response returns HTTP 503. Policy changes before the next attempt, which is blocked; there is only one transport call. The independent later-round case creates an opener, then revokes consent before invoking it; no transport call is sent. In the continuation case, the initial investigation pauses after three calls. Disabling external AI in policy denies the resume and leaves the count at three. Restoring permitted policy and accepting current consent permits a resume and raises it to four.

The provider selector lists supported options; selecting one does not mean institutional policy permits it. The server enforces the effective policy for the selected configuration.

Operating guides

• Project confidentiality and access
• Institutional AI and disclosure policy
• Bring Your Own Key
• Complete hosted reference
• r34 implementation scope

Narration transcript

0:00 — Project access and AI disclosure

Welcome to PF Simulation and the PF Research Workbench. This walkthrough covers B2, project access, and B3, institutional AI policy and disclosure consent. We will follow the interface, then inspect the server checks behind it. The application runs locally with demonstration accounts and data. Provider replies are scripted, and no research data is sent to an external AI service. The interface captures and server responses come from the current release r34 source.

0:31 — Restrict a research project

Begin with an organization-shared project. In Team, open its project access controls and change the sharing scope to selected members. Save the change. The server clears the previous explicit grants and gives the acting administrator an editor grant. Existing projects stay organization-shared until an administrator makes this choice. Changing back to organization sharing removes explicit grants; restricting the project again does not restore the old list.

1:00 — Give a colleague read access

Choose an active, verified organization member and grant viewer access. Now switch to that colleague's account. The restricted project appears in the project selector, and its effective role is viewer. Project editing and upload controls are disabled. The distinction matters: an organization editor can have only viewer access to this particular project. A project grant never raises the member above their current organization role.

1:37 — Grant editing, then revoke access

Return to the administrator and change the colleague's grant to editor. In the colleague's account, permitted editing controls become available. Next, remove that explicit grant. When the colleague refreshes their workspace, the restricted project is no longer listed. Organization administrators do not receive an automatic data-access bypass. They can manage access and make an audited grant to themselves when needed. Host and database administrators remain trusted.

2:25 — Verify the server boundary

A disabled button is only the visible part. These recorded checks call the real server routes directly. An account without a grant cannot discover or read the restricted project. A viewer can read but cannot write. An editor can perform the permitted mutation. Removing the grant blocks subsequent requests. Jobs, logs, results, artifacts, downloads and assistant access use the same project boundary. Mutation paths recheck permission inside their database transaction.

2:55 — Revocation follows queued work

Permission also follows work already submitted. The worker checks the submitter again before claiming a queued job. Revoked access cancels that work. For a running job, the next heartbeat and normal cancellation mechanism stop execution; revocation is not an instantaneous process kill. The completion path checks again before committing the result. The retained checks exercise these boundaries independently. Files already downloaded, and data already transmitted, cannot be recalled.

3:26 — Set the organization AI policy

Back in Team, open Organization policy. Its seven settings control external AI, allowed providers, approved compatible endpoint identifiers, source disclosure, required consent, data classification, and the maximum classification permitted for external transmission. Review the complete form and save it. Classification is assigned by administrators; this is not automatic content classification. The Linux reference begins with external AI and source disclosure disabled. Existing installations retain their legacy defaults until configured.

4:10 — Tighten policy for the project

Open Project policy to apply stricter rules to this research project. The effective policy combines the organization and project settings. A project cannot reopen a provider or disclosure path that the organization forbids. For example, a more sensitive project classification can exceed the permitted external-data ceiling and block the request. Review the effective policy summary after saving. Policy revisions also prevent an older editor form from silently overwriting a newer change.

4:54 — Provider choice stays within policy

The research assistant lets a researcher select a provider and model for their personal AI account. With your personal AI provider API key, PF Simulation uses your credentials to access the AI service; it does not bypass institutional policy. The server checks the selected provider and its actual destination. Compatible endpoints must meet the configured approval rules. Disabling source disclosure blocks model requests, rather than quietly removing source text and sending the rest. Saving credentials alone does not demonstrate provider connectivity or approve a disclosure.

5:34 — Review the disclosure before sending

From a saved run, open the research assistant and submit a question. When consent is required, the interface pauses for disclosure review. Read the identified provider, model, destination and statement describing the information that may be sent. The confirmation control requires an explicit acceptance. Canceling leaves the assistant request unsent. A viewer cannot grant chat consent to gain editing or assistant privileges that the project role does not provide.

6:06 — Accept, inspect and revoke consent

After reviewing the disclosure, explicitly accept it to continue. Consent is bound to the user, project, effective policy and selected provider configuration, including credential revision. It expires after twenty-four hours. Changes to the relevant policy, provider or key can require fresh consent. Open disclosure settings to inspect the current state and revoke it. A later request must satisfy the current rules again. Revocation cannot undo information already sent.

6:45 — Measure blocked outbound requests

The server evidence makes the boundary measurable. Direct requests are tested with a scripted provider transport that counts attempted calls. When policy denies the request, or required consent is missing, the outbound count remains zero. After the required policy and consent conditions are satisfied, an allowed request reaches the scripted transport. Separate checks cover provider restrictions, endpoint approval, classification and personal credentials. These observations verify application enforcement, not a live provider's behavior.

7:21 — Check again before every attempt

Admission is not the last check. Before each outbound attempt, the server checks current access, policy and any required consent again. The recorded cases change policy or disclosure state between attempts. A retry or tool round must stop when the new state no longer permits transmission. Resuming an investigation uses the same current controls. This closes the gap between a request that was acceptable when started and one that is no longer authorized to continue.

7:51 — Make the controls part of the workflow

B2 connects each project to its authorized readers and editors. B3 connects each external AI request to institutional policy and, when required, explicit researcher consent. The interface supports those choices, while the server enforces them. Use the project confidentiality and research policy guides for administration, migration and operating details. The transcript includes the demonstration scope and retained evidence. Together, these controls support a deliberate path from research questions to permitted investigation.