# Projects and access

Canonical: https://savrn.com/cloud/docs/platform-projects-access

SAVRN Cloud · Coming soon. Public documentation and a browser simulation are available; connected services are not yet available.

Projects organize SAVRN Cloud requests, experiments and sample credit allowances around a shared purpose. The preview demonstrates selecting that context, while this guide explains why actual membership, role enforcement and cross-project isolation require server-side controls.

**SAVRN Cloud · Coming soon · Public preview · Browser-local simulation · No live compute or payments**

## Establish the working context

Open [Projects](https://savrn.com/cloud/console/#/projects) and review the available project names, budgets and recorded spend. Select the project for your next walkthrough before starting a playground request, Work Order or experiment. Choose **Create project** and enter **Project name**, **Purpose** and **Sample credit allowance**. Creating it selects the new context; the allowance has no automatic monthly reset.

Use descriptive fictional names, such as “Methods workshop,” rather than real student, patient or confidential sponsor details. The browser stores this information locally. The project selector is a workflow aid; it is not an authentication boundary between people who can access the same browser profile.

## Follow project activity

After completing an action, inspect its project association and [Usage](https://savrn.com/cloud/console/#/usage). Use **Open project** to switch context and **Adjust allowance** to change the total sample SWC limit. Available credits account for spend and local reservations. A displayed allowance does not represent deposited money or a paid service contract. If you change the active project, confirm the context before creating the next record.

Review [Keys](https://savrn.com/cloud/console/#/keys) to understand scoped credentials and [Approvals](https://savrn.com/cloud/console/#/approvals) to understand decision records. Both remain demonstrations of control-plane behavior.

## Before connected services launch

Projects require durable server-side ownership, authenticated membership and least-privilege roles. Authorization must apply to every record and artifact, not merely the visible navigation. Key permissions must match permitted projects and operations. Institutional roles, grant allocation, delegation and access removal need explicit policies. Production tests must show that a user cannot read or mutate another project's work by changing an identifier.