> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trylimitless.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Policies

> Publish versioned checks and apply them to inference requests.

Policies are organization-owned rules evaluated by the configured inference backend. Drafting, publishing, and inference use separate stages so an unfinished edit cannot silently change active behavior. Publishing requires the deployment's policy backend to be configured; otherwise it returns `503`.

For API automation, use an Admin API key with `policies:write` for mutations and `policies:read` for reads.

## Manage policies in the console

Open **Policies** to create a draft, write its yes-or-no rule and choose its mode and scope. Save the draft, review **Published behavior**, then publish a version. Owners and admins can edit, publish, pause, resume and delete policies; members can read them. **Published versions** shows the immutable configuration for each version.

Saving an edit does not change active behavior. Publishing activates the saved draft; resuming a paused policy restores its existing published version. If another change causes a revision conflict, load and review the latest revision before retrying. An interrupted request offers **Retry same request** to recover the original operation.

The page also shows policies automatically applied to the sidebar's selected project. Playground displays these automatic policies and lets you choose one additional published per-request policy. Automatic policies cannot be disabled by clearing that selection. The [**Decisions** page](/guides/decisions) reads recorded policy evaluations across the workspace. Request capture and the persisted page are enabled in the current sandbox deployment. The verified provider decision feed is still pending, so the page shows a connection notice and empty history. Successful model responses do not supply per-policy results and are not turned into assumed decisions.

If a Playground request is blocked by a policy or its evaluation is unavailable, **Review policies** opens the policy controls. Your prompt remains available to retry after reviewing the active rules.

## 1. Create a draft

A rule is a yes-or-no question ending in `?`. Set `direction` to `request`, `response`, or `both`. Start with `monitoring` to observe behavior before choosing `enforcing`.

```bash theme={null}
curl --fail-with-body "$LIMITLESS_BASE_URL/organization/policies" \
  -H "Authorization: Bearer $LIMITLESS_ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: policy-reference-001" \
  -d '{
    "name":"Product scope",
    "rule":"Is this unrelated to the products sold by this application?",
    "direction":"request",
    "mode":"monitoring",
    "scope":"unattached"
  }'
```

Save the returned `id` and `revision`. A newly created draft does not apply to inference.

## 2. Select scope

| Scope | Application |
| - | - |
| `organization` | Automatically applies to every project in the workspace. |
| `projects` | Automatically applies to the supplied `project_ids`. |
| `unattached` | Applies when explicitly selected in a request's `policy_ids`. |

Project scope requires at least one active project belonging to the workspace. Remove archived assignments before saving or publishing a draft. Request-selected policies add to automatic rules; they cannot remove organization or project policies.

## 3. Publish a version

```bash theme={null}
curl --fail-with-body "$LIMITLESS_BASE_URL/organization/policies/$POLICY_ID/publish" \
  -H "Authorization: Bearer $LIMITLESS_ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"revision":1}'
```

Use the actual current revision, which may differ from this first-publication example. Publication creates an immutable version. If backend publication is uncertain or fails, the new version does not become active until publication is confirmed; retry the same intended revision.

Edit a draft with `PATCH /organization/policies/{policy_id}` and its current `revision`. Edits remain unpublished until the next publish. Fetch the latest policy before another mutation; stale revisions return `409`.

## 4. Apply an optional policy

Include the published Limitless ID in any Chat, Responses, or Messages request:

```json theme={null}
{
  "model": "abliterated-model",
  "messages": [{ "role": "user", "content": "Help me choose a product." }],
  "max_tokens": 512,
  "policy_ids": ["pol_REPLACE_WITH_RETURNED_ID"]
}
```

The placeholder must be replaced with an ID from your own policy API. Foreign, missing, unpublished, or paused selected policies are rejected. Customer IDs are resolved within the organization and project; internal backend policy IDs are never customer credentials.

Monitoring evaluates without enforcing a match. Enforcing rules can reject requests or responses. `policy_violation` and `policy_evaluation_unavailable` use `policy_error` with a request ID. Response policies can delay streamed text until evaluation finishes. A failed policy evaluation releases its reservation without a generation charge; a policy violation can still carry billable reported usage. Policy checks are not a guarantee that every undesired input or output will be detected.

## 5. Operate the policy

Pause or resume with `POST /organization/policies/{policy_id}/pause` or `/resume`, including the latest revision. Read version history through `/versions` and `/versions/{version}`. Inspect automatic rules for a project through `/organization/projects/{project_id}/effective_policies`.

Delete with `DELETE /organization/policies/{policy_id}?revision=LATEST_REVISION`. This removes future application; requests already dispatched may still finish under the earlier snapshot.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.