Org-level policies
Org policies let an organization set defaults for project settings — and mark any of them Enforced, meaning project owners cannot override them. Enforcement is server-side: the API silently applies the forced value, or rejects the request with a message that names the policy. The project-settings UI shows enforced controls locked with a "Set by your organization" hint, but even a raw API call cannot bypass an enforced policy.
Every save is written to the organisation's activity with what changed: each policy as it was and as it is now, with "(enforced)" where it applies. A policy left out of a save goes back to its default, and that is recorded as a change too.
Locks and gates
Policies come in two kinds, and Enforced means slightly different things for each:
- Value-locks (rates visible, managers-don't-earn, allowed visibilities, contributor cap, creation roles, storage providers, retention): Enforced pins the setting at the org's value in both directions — enforced-off is locked off, and project owners see the control disabled either way.
- Gates (future-only rate changes, consent-before-public, license before export, join approval, audio QC, invite/export restrictions, HF-push forbid, external-URL ban, passkey requirement): they act only when turned on; the Enforced checkbox stays disabled while the gate is off, since enforcing an inactive gate does nothing.
Where it lives
Organization → Settings → Policies. Visible to Owner and Admin only (platform staff can also manage it).
The page is laid out as the organisation's Settings page: the policy
groups are listed down the left (Governance, Payment, Consent &
licensing, …, Data & storage) and one group is shown at a time. A number
beside a group says how many of its policies are enforced.
/organization/policies?group=storage opens straight on a group.
Each policy row has a control (checkbox, dropdown, list of options, number or text box), an Enforced toggle, and a one-line description. One Save policies button saves every group at once, so you can move between groups before saving.
Default vs. Enforced
- Not enforced — the value is a default for new projects and new rate cards. Project owners can change it afterwards.
- Enforced — the value is policy. Requests that try to override it are either overwritten server-side (the response reflects the forced value) or rejected with an error naming the policy.
Organizations that never touch the tab behave exactly as before: registry defaults, nothing enforced.
The policies
Governance
| Policy | Enforced |
|---|---|
| Who can create projects | Project creation (including creating from a template) is limited to the chosen roles: owners and admins; owners, admins, and managers; or any member. "Any member" still excludes guests. |
| Invites restricted to owners and admins | Invite links, invite-link token resets, email invites, and adding existing users to the org all require an owner or admin. |
Payment
| Policy | Not enforced | Enforced |
|---|---|---|
| Managers never accrue earnings | Default for new rate cards. | Every rate card keeps owners/managers out of the earnings ledger, regardless of what the project saves. |
| Rates visible to contributors | Default for new rate cards. | Rate cards are always visible to contributors before they join. |
| Rate changes apply to future work only | — | Saving a rate change with "also reprice unpaid past work" is rejected; done work always keeps its old rate. |
Consent & licensing
| Policy | Enforced |
|---|---|
| Consent agreement before going public | A project cannot be switched to public visibility until it has at least one consent agreement attached (Settings → Consent). A brand-new project therefore cannot be created public — create it private, attach consent, then publish. |
| Dataset license before export | Data exports and Hugging Face pushes are refused until the project has a license chosen via Settings → Licensing. |
Visibility & joining
| Policy | Not enforced | Enforced |
|---|---|---|
| Project visibility ("Private only") | — | No project in the org can be made public — rejected on create and update. |
| Join requests need approval | Default join mode for new projects. | Every join on open projects is held pending until a manager approves it — including projects whose stored join mode predates the policy. |
| Contributor cap per project (0 = no cap) | Default contributor limit for new projects. | Project contributor limits are clamped to the cap ("unlimited" becomes the cap). |
Quality
| Policy | Enforced |
|---|---|
| Audio QC on recording projects | Projects whose labeling config contains an <AudioRecord> interface cannot switch automated audio QC off. |
Export
| Policy | Enforced |
|---|---|
| Exports restricted to managers | Only owners, admins, and managers can export data, download or convert export snapshots, or push to Hugging Face. Reviewers and annotators get a 403 naming the policy. This is the org-wide version of the per-project "restrict exports to managers" toggle. |
| Hugging Face pushes disabled | Nobody in the organization can push datasets to Hugging Face — personal HF tokens don't matter. Imports from the Hub keep working. |
Content
| Policy | Enforced |
|---|---|
| No external URLs in task data | Imports are rejected when task data references an http(s):// URL — the error names the offending value. Upload files or attach cloud storage instead. Annotations/predictions in the payload may still carry URLs; cloud-storage sync is unaffected. |
The rule holds on every way a task is made or changed: file imports, Hugging Face imports, bucket syncs (a file that carries an external URL is left out and counted among the sync's errors), and tasks created or edited one at a time through the API.
Security
| Policy | Enforced |
|---|---|
| Passkey required for sensitive actions | Saving org settings, saving policies, and marking payout runs paid require at least one passkey (Account Settings → Passkeys) on the acting account. To avoid lockouts, enforcing this policy requires the enforcing admin to already have a passkey. |
API-token controls (disable legacy tokens, token time-to-live) are not policies — they already live in Organization → Settings → Access (per-org JWT settings).
Retention
| Policy | Behavior |
|---|---|
| Delete export snapshots after (days) | 0 = keep forever. When set, the cleanup_exports maintenance command deletes export snapshots (and their converted files) older than N days for this org. Operators schedule it like the other maintenance jobs: python manage.py cleanup_exports (supports --dry-run). Applies whether or not the row is marked Enforced — there is nothing for a project owner to override. |
Both retention policies are applied by the daily maintenance job
(python label_studio/manage.py maintenance, which runs
clearsessions, cleanup_exports and purge_expired_project_data).
On the hosted service it is scheduled by deploy/gcp/setup-maintenance.sh;
on your own server, run it once a day. Nothing is deleted while it is not
scheduled. maintenance --dry-run reports what would be deleted.
Storage
| Policy | Enforced |
|---|---|
| Allowed storage providers | Attaching a project source/target cloud storage of a provider outside the allowed set is rejected: "Your organization restricts storage providers to: …". |
| Data stays in the organisation's own buckets | Media and files may only live in connected cloud storage. Uploading files through the import page, the recorder or the resumable uploader is refused; the splitter writes clips back into the project's Google Cloud Storage source bucket (and refuses when there is none); a project needs a source storage and a target storage before it can be published, so media is read from the bucket and annotations are mirrored back to it; Hugging Face pushes are off. Task records and annotations keep their working copy in the platform database (Postgres on Cloud Run); the target storage holds the exported copy. |
| A recording is heavy over (minutes), An audio file is heavy over (MB), A video is heavy over (MB), An image is heavy over (MB) | Not gates: they set what the organisation calls a heavy file (defaults 10 minutes, 50 MB, 200 MB, 10 MB). The storage file check and the Data Manager's Heavy file column use them. Nothing is refused. |
Data & storage (residency)
The Data & storage card on the same tab shows where the org's data actually lives:
- Platform default — where task data and uploads are stored on this install, read from the server's storage configuration: a cloud bucket (provider + bucket name, region when configured) on cloud installs, or local disk on self-hosted and desktop installs.
- Projects with their own cloud storage — every project in the org that attaches its own source or target storage, with provider and bucket/path per project.
- The Allowed storage providers policy control sits beside the list, so restricting future attachments happens where you can see the current ones.
API
GET/PUT /api/organizations/<id>/policies— the policy registry (labels, types, defaults, descriptions) merged with the org's saved values, plus the residency payload. Owner/Admin only.GET /api/projects/<id>/effective-policies/—{key: {value, enforced}}for the project's org; used by project settings pages to render locked controls. Org members only.