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

# Model access locks

> Hold a project to the provider routes its Model access rules allow today, with each route's handling facts recorded. Later rule changes cannot widen a locked project.

A Model access lock holds one project to the service routes that its saved
[Model access](https://docs.opper.ai/control-plane/rules/model-access.md) rules allow when you take
the lock. A service route is one provider serving models from one place, such
as `azure:se` (Microsoft Azure in Sweden) or `openai/api-us`. The lock records
each route with the facts Opper's catalog holds for it that day: the company
that runs it, where inference runs, and how the route handles content for
training, logging, moderation, and caching.

Use a lock when a data processing agreement or an internal policy names the
providers and locations a workload may use, and that list must not change when
someone edits the rules. Once a project is locked, no rule change can widen
what it reaches, and neither can a provider, location, or route that Opper
adds to the catalog later. Only replacing or releasing the lock changes it.

Locks are listed under **Settings**: open **Data processing** under **Access &
security**, then **Model access locks**. The page is at
`platform.opper.ai/<your-org>/settings/data-processing/locks`. Taking a lock
needs the Control Plane or Enterprise plan.

## How a lock works with your rules

A lock is a ceiling on top of the project's Model access rules. A call from a
locked project goes through only when both of these hold:

* The rules that apply to the project, the organization rule and any project
  override, allow the model.
* The model's service route is one of the locked routes.

Which models the project may use on the locked routes is still up to the
rules, so you can keep narrowing them. The lock blocks anything the rules
allow outside it.

| After the project is locked | Effect on the project |
| - | - |
| The organization rule or the project override is narrowed | Applies. The project reaches less than its lock holds, and the lock is shown as listing routes the rules already block. |
| Either rule is widened | No effect past the lock. Routes the rules now allow outside the lock are shown as blocked by the lock. |
| A rule is deleted or replaced | The project follows the rules now in force, inside the lock. |
| A rule change would leave the project no model it can call | Refused. See [Change rules on a locked project](#change-rules-on-a-locked-project). |
| Opper adds a model to a locked route | Reachable when the rules allow it. |
| Opper adds a provider, a location, or a route | Not reachable. |
| Opper renames a locked route | The lock still admits the route under its new ID. |
| Opper retires a locked route | The project can no longer call it. The lock does not change. |
| Your organization's agreement for a [restricted route](https://docs.opper.ai/control-plane/rules/model-access.md#routes-that-require-an-agreement) ends | The project can no longer call that route. |

A lock is taken from the saved rules and the restricted routes your
organization has an agreement for. Changes not yet saved on the Rules page are
not part of it.

Like rules, a lock applies to every model type on the Opper v3 API, including
the [compatibility gateway](https://docs.opper.ai/build/gateway/drop-in-sdks.md) and the playground.
Deprecated APIs are not supported with locks.

## Who can lock a project

| Action | Permission | Plan |
| - | - | - |
| See locks on Data processing and the Rules page | **View rules** | Every plan |
| Lock a project, or replace its lock | **Configure rules** and **View projects** | Control Plane or Enterprise |
| Release a lock | **Configure rules** and **View projects** | Every plan |
| See lock events in the Audit Log | **View audit logs** | Enterprise |

With the built-in roles, Owners and Admins can lock, replace, and release.
Developers can see locks but not change them. Viewers do not see them. See
[Roles and permissions](https://docs.opper.ai/control-plane/roles-and-permissions.md).

Seeing and releasing locks work on every plan, so an organization can always
see and remove a lock it holds. On another plan, a member who may configure
rules is told which plans can lock and offered **Upgrade to Control Plane**.

Locks are taken on Data processing, or from a project rule on the Rules page.
The [Management API](https://docs.opper.ai/control-plane/management-api.md) does not take, replace,
or release them.

## Lock a project

**1. Open Model access locks**

In the Opper platform, open **Settings**, then **Data processing**, then
**Model access locks**, and select **Lock a project**.

**2. Pick the project**

The dialog reads the project's saved rules and shows the lock it would
take, for example "4 routes at 2 companies, 37 models."

**3. Review the preview**

The [readiness review](#the-readiness-review) lists what to know before
you lock, each item with the action that changes it where there is one.
**Routes in the lock** lists each route under the company that runs it,
with where it runs, how many models it serves, and its handling facts.

**4. Take the lock**

Optionally add a **Label**, such as the agreement the lock is for, then
select **Lock project**.

The new lock is version 1 of the project's lock. It reads **Activating**, then
**In force** once every Opper server has confirmed it, usually in under a
minute. See [Activating and in force](#activating-and-in-force).

You confirm the preview you see. If the project's saved rules or the readiness
review change before you select **Lock project**, the lock is refused and the
dialog shows the new preview for you to confirm.

### Lock from the Rules page

A project rule's panel on the [Rules](https://docs.opper.ai/control-plane/rules/overview.md) page has
a **Lock** group for each project the rule names. For a project with no lock,
the group reads **Not locked**, with **Lock this project**: "A lock holds this
project to the routes its saved rules allow now. Rules can narrow that later,
not add to it." The button opens the same lock dialog.

**Lock this project** shows only to a member who may lock, on a plan that can.
It is unavailable while the panel has unsaved changes: "Save or discard your
changes first. A lock is taken from the saved rules."

### The readiness review

The preview sorts what to know before you lock into three groups. Each item is
part of what you confirm.

| Group | Items |
| - | - |
| **Blocks locking** | "The project's saved rules allow no models.", with **Edit Model access**. While something blocks locking, the review shows nothing else and **Lock project** stays unavailable. |
| **Review** | A [check](#checks-on-a-locked-project) that does not run while the project is locked, because the lock blocks the models it runs on, with **Choose an available check model**. The item says whether requests then go through unchecked or are refused. |
| | An automatic [dynamic route](https://docs.opper.ai/capabilities/routes/overview.md) that does not work while the project is locked, because the lock blocks the models it classifies with, with **Open route**. |
| | Your organization's [custom models](https://docs.opper.ai/capabilities/custom-models.md): "The lock blocks the organization's 2 custom models." |
| | Always shown: "The lock blocks Opper's web search and web fetch tools. They send queries to search and fetch providers that are not routes in the lock." |
| | Models the rules allow that have no service route, which the lock blocks. |
| **Good to know** | Always shown: "The lock does not cover calls made with an organization key and no project header." See [What a lock does not cover](#what-a-lock-does-not-cover). |

### Activating and in force

Each Opper server enforces its own copy of your locks and confirms every few
seconds which version it enforces. A new lock, or a new version from a
replacement, reads **Activating** while the servers confirm it: "Every Opper
server confirms a new lock before it is in force. This usually takes under a
minute." Servers enforce the lock as soon as they load it, so calls outside it
can already be refused while it is activating.

Once every server has confirmed it, the lock reads **In force**. Its
**Technical details** give the moment it came into force: **In force since**,
"Every Opper server enforces it."

A lock can stay Activating for up to about 45 minutes after an Opper server
stops unexpectedly. Every server that has loaded it enforces it meanwhile. If
it is still Activating after an hour, contact support.

A server that cannot confirm its locks stops calling providers until it can.
See [If a server cannot confirm its locks](#if-a-server-cannot-confirm-its-locks).

## What the Data processing page shows

**Model access locks** has one row per lock version, newest first, with the
project, status, version, label, number of routes, who took the lock, and
when. Replaced and released versions stay listed, so the list is also the
history. Search by project or label, filter by status, and sort by date,
project, status, or version.

| Status | Meaning |
| - | - |
| **Activating** | The project is held to this version, and Opper's servers are confirming it. |
| **In force** | Every Opper server has confirmed it and enforces it. |
| **Replaced** | A newer version replaced it. |
| **Released** | A member released it. |
| **Project deleted** | The project was deleted. |
| **Organization deleted** | The organization was deleted. |
| **Plan downgraded** | The organization moved to a plan without locking. |
| **Released by Opper** | Opper released it. |

When an active lock and the project's saved rules differ, a chip beside its
status says how:

| Chip | Meaning |
| - | - |
| **N blocked** (amber) | The saved rules allow routes the lock does not hold. The lock blocks calls to them. |
| **N outside rules** (neutral) | The lock holds routes the saved rules no longer allow. Nothing is blocked. |

Select a row to open its details:

* **The lock.** The project, the status, the version and its label, who took
  the lock and when, and for a version that has ended, how, when, and by whom.
  While the lock is activating, it says what it waits for.
* **How the lock and the rules differ.** When the saved rules allow routes
  outside the lock: "The project's saved rules allow 1 route, but the lock
  blocks it." When the lock holds routes the rules no longer allow: "The rules
  already block 5 routes listed in this lock. Updating the lock removes them."
  Each lists the route IDs, with **Update lock** and **See rules**, which
  opens the project's Model access on the Rules page.
* **Locked routes.** The number of routes, then each route under its company
  and legal entity, with its location, route ID, and how many of its models are
  available now. Each row shows the recorded training and logging facts and
  flags anything else to know, such as **Residency not enforced** or **Some
  handling facts unknown**. Open a route for every recorded fact: training,
  logging, moderation, caching, residency, third-party access, and
  sub-processors. A fact the catalog had not researched reads **Unknown**.
* **Source rules.** The organization rule and the project rule as they stood
  when the lock was taken, in the words the Rules page uses, each with **View
  current rule**. **Entitlements** lists the restricted routes your
  organization had an agreement for.
* **Version history.** When the project has had more than one version, every
  version, with who took it and how it ended. Select **Open** on one to view
  it.
* **Technical details.** The lock ID, the snapshot hash, the catalog version,
  and for a lock in force, **In force since**. Use them to refer to this exact
  lock.

Source rules, Version history, and Technical details start folded.

Opper never rewrites a lock. Its routes and facts stay as they were recorded,
whatever changes in the catalog later. Model counts leave out models Opper has
retired since.

## Update a lock after a rule change

A lock and the project's saved rules can come apart in two ways:

* **The rules were widened.** They allow routes the lock does not hold. The
  lock blocks calls to those routes until you replace it.
* **The rules were narrowed.** The lock holds routes the rules no longer
  allow. Nothing is blocked, since the rules refuse those routes. But a later
  rule change that allows them again needs no new lock, so replace the lock
  to bring it down to what the rules allow now.

Opper points both out in these places:

* **Above the Model access card** on the Rules page, a notice lists each
  locked project whose lock and saved rules differ, for example "1 lock
  differs from the saved rules". Projects whose lock blocks routes the rules
  allow come first, in amber: "The rules allow 1 route, but the lock blocks
  it." Narrowed locks follow in neutral text: "The rules already block 5
  routes listed in this lock." Each line has **Update lock**, or **View lock
  ↗** for a member who cannot update it, and the notice ends "Update lock
  creates a new lock version from the saved rules." The notice is amber while
  the lock blocks any route the rules allow, and neutral when every difference
  is a narrowing.
* **When you save** on the Rules page, **Rules saved** names the projects the
  save moved, for example "support-bot's rules now allow 2 routes, but the
  lock blocks them." or "default's rules already block 5 routes listed in its
  lock. Updating the lock removes them.", with **Update lock**.
* **In the Rules page**, the project's Model access row says how many routes
  the lock blocks, for example **1 route blocked by the lock**, and the
  **Lock** group in its panel shows how the lock and the rules differ.
* **On Data processing**, the lock reads **N blocked** or **N outside
  rules**, and its details list the routes.

A lock is taken from the saved rules, so **Update lock** on the Rules page is
unavailable while there are unsaved changes: "Save or discard your changes
first. A lock is taken from the saved rules." A member who cannot update the
lock reads who can in its place.

To replace the lock, select **Update lock**, or open the lock's details on
Data processing and select **Manage lock**, then **Replace lock**. The **Replace the lock** dialog builds a new
preview from the saved rules and compares it with the current version:

| Row | Meaning |
| - | - |
| **Adds** | A route the new version holds that the current one does not. |
| **Removes** | A route the current version holds that the new one does not. |
| **Facts changed** | A route in both whose recorded facts have changed since the current version was taken. |

If nothing differs, the dialog says the routes and facts are the same as the
current version's. The label starts as the current version's. Select
**Replace lock** to confirm.

Replacing creates the next version and marks the previous one **Replaced** in
the same step, so the project is never unlocked in between. The new version
reads **Activating** until every Opper server has confirmed it. If another
member changed the lock while the dialog was open, the dialog compares with
the lock as it is now and asks you to confirm again.

## Release a lock

Open the lock's details and select **Manage lock**, then **Release lock**. The
dialog names the project, the version, and how many routes the lock holds.
Select **Release lock** to confirm.

Once released, the project's saved rules alone decide which models it can
reach, including any route they allow that the lock blocked. Every Opper
server picks up the release on its own, usually within a minute. The version
stays in the list as **Released**. Releasing works on every plan.

## Change rules on a locked project

Under **Model access**, the [Rules](https://docs.opper.ai/control-plane/rules/overview.md) page lists
every locked project, whether or not a rule names it:

* **The project's row** shows **locked v1** beside its name and the number of
  models it can call, such as **37 models**. When its saved rules allow routes
  the lock does not hold, the row says how many in amber, such as **1 route
  blocked by the lock**.
* **The project's panel** has a **Lock** group: "A lock holds this project to
  the routes it records. Rules can narrow that, not add to it." It shows the
  version and label, who took the lock and when ("Locked by … on …"), the
  locked routes, and **Can call** with the number of models, followed by how
  many the saved rules allow when that is more. **View lock ↗** opens the
  lock on Data processing.
* **A locked project with no rule of its own** has a row and a panel too. The
  panel says "No project rule. The organization rule applies, within the
  lock." and offers **Narrow model access for this project**.
* **While you edit a project rule**, the model count says how many of the
  matching models are inside the lock. In the route picker, a route the lock
  does not hold is marked **outside lock**: "The rules allow this route, but
  the lock blocks it. Updating the lock allows it." You can still pick it.
* **The organization rule's panel** has a **Locked projects** group: "Locks
  hold these projects to their routes. This rule can narrow them, not widen
  them." Each project shows the models your draft leaves it within its lock,
  and in amber any routes outside the lock.
* **Blocked calls.** In the organization rule's panel, beside the rules' own
  count, **lock blocked N calls · 24h** counts calls the lock refused that the
  rules allowed.

A change that would leave a locked project with no model it can call is not
saved. The panel you saved from says "Not saved: support-bot would have no
model to call.", names the lock's version, and links to Data processing. A save
from the page's bar says the same in a notification. Your changes are kept. To
make the change, keep a model on a locked route in the rules, or replace or
release the lock first.

Deleting a rule is checked the same way, because a deletion can put a narrower
rule in force. The same check applies to rule changes made through the
[Management API](https://docs.opper.ai/control-plane/management-api.md#manage-rules-from-code).

## Checks on a locked project

A [check](https://docs.opper.ai/control-plane/rules/checks.md) that uses a model is held to the lock
like any other call: it runs only on models whose routes are in the lock.

* **When you lock.** The preview names each check that applies to the project
  and has no model inside the lock.
* **While the project is locked.** Such a check does not run in the project,
  and the request follows the check's **On error** setting: **allow**, the
  default, lets the request through unchecked, and **block** refuses it. Rules
  marks the check **couldn't run**. Open it to read that a project's Model
  access lock admitted none of its models, with a link to Data processing.
* **When you save a check.** The check's model picker offers only models the
  lock admits. Saving a check that could run on none of its models in a locked
  project it applies to is refused, with a message that names the lock and its
  version.

> [!WARNING]
>
> For a check a locked project must never skip, set **On error** to **block**
> and pick a model on one of the locked routes.

## What a refused call returns

A call to a model outside the lock is refused with HTTP `403` before anything
reaches a provider. That includes streaming requests: the error comes back
before the stream opens. The message opens with
`model "<model>" is blocked by the project's Model access lock`, says why,
names the project and the lock's version, and ends with a link that opens the
lock in the platform:

```json theme={null}
{
  "error": {
    "code": "permission_error",
    "message": "model \"openai/gpt-4.1-nano\" is blocked by the project's Model access lock: service route \"openai/api-us\" is not one of the locked routes (project \"support-bot\", lock version 1). View the lock: https://platform.opper.ai/go?org=…&to=model-access-lock&project=…&lock=…",
    "details": {
      "docs_url": "https://docs.opper.ai/control-plane/rules/model-access-locks",
      "lock_url": "https://platform.opper.ai/go?org=…&to=model-access-lock&project=…&lock=…"
    }
  }
}
```

The lock is checked before the rules, so a model the rules also refuse gets
this message. The reason after the colon depends on the call:

| The call | Reason |
| - | - |
| Names a model on a route outside the lock | `service route "openai/api-us" is not one of the locked routes` |
| Names a bare model, and none of its providers is on a locked route | `none of its providers is on one of the locked routes` |
| Uses a custom model or your own provider credential | `it is called with your own provider credential, so it is not on one of the locked routes` |
| Names a model with no service route | `the model has no service route, so it is not on one of the locked routes` |

Each reason is followed by the project and the lock's version, such as
`(project "support-bot", lock version 1)`, or only the version when the
project's name is not known, then `View the lock:` and the link.

A bare model name served by a pool, such as `claude-sonnet-5`, and a `models`
fallback list skip what the lock excludes, the way
[Model access](https://docs.opper.ai/control-plane/rules/model-access.md#what-model-access-covers)
skips what the rules exclude. They are refused only when nothing inside the
lock is left. Opper does not switch a call to another model for you.

Each endpoint returns the body it returns for a rule refusal, so a client that
handles one handles the other:

| Endpoint | Where the code is |
| - | - |
| `/v3/compat/chat/completions` | `error.code` is `permission_error` |
| `/v3/compat/v1/messages` | `error.type` is `permission_error` |
| `/v3/compat/responses` | `error.code` is `model_not_allowed` |
| `/v3/compat/openresponses` | `error.code` is `model_not_allowed` |
| Gemini-compatible `generateContent` | `error.status` is `permission_error` |
| `/v3/compat/embeddings` | `error.type` is `permission_error` |
| Image, audio, video, and OCR endpoints | No code: `error` is the message |

On `/v3/compat/chat/completions`, `/v3/compat/v1/messages`,
`/v3/compat/responses`, `/v3/compat/openresponses` and
`/v3/compat/v1beta/interactions`, `error.details` also carries the links:
`docs_url`, this page, and `lock_url`, the link the message ends with. The
other endpoints carry the link in the message only.

A [dynamic route](https://docs.opper.ai/capabilities/routes/overview.md) that the lock stops fails with
the code `route_compliance_blocked`, as it does for a rule.

If Opper cannot read a project's lock, it refuses every call from that project
rather than letting one through unchecked, with a message that ends
`the lock could not be read, so every model is refused until it can be`,
followed by the project and the lock's version.

### See refusals in the platform

* [Logs](https://docs.opper.ai/control-plane/logs.md) shows a refused call as **Blocked by project
  lock**, under the **Blocked** status filter.
* A call's [trace](https://docs.opper.ai/control-plane/trace.md) reads **Blocked by the project's
  Model access lock**.
* The model catalog and the playground's model picker mark models outside the
  lock **Blocked by project lock**, and link to Data processing.

### Check before you call

List models with the locked project's API key and
`GET https://api.opper.ai/v3/models?include=policy`. Each model outside the
lock has `"blocked_by": "lock"` and the same reason as the `403`:

```json theme={null}
"policy": {
  "allowed": false,
  "blocked_by": "lock",
  "reason": "service route \"openai/api-us\" is not one of the locked routes (project \"support-bot\", lock version 1)"
}
```

## If a server cannot confirm its locks

Every Opper server confirms the locks it enforces every few seconds. A server
that cannot confirm them for several minutes stops calling providers until it
can, so that it never serves an out-of-date copy of a lock. This applies to
every call that server receives, whether or not the project is locked.

Such a call is answered with HTTP `503` and `Retry-After: 5`, and the message:

```
model "openai/gpt-4.1-nano" is refused: this server could not confirm its Model access locks, so it refuses every model until it can. No rule or lock refused this call; retry the request
```

Where an endpoint puts a code, the code is `model_access_lock_unconfirmed`, in
place of its usual refusal code. For example, a chat completion returns:

```json theme={null}
{
  "error": {
    "code": "model_access_lock_unconfirmed",
    "message": "model \"openai/gpt-4.1-nano\" is refused: this server could not confirm its Model access locks, so it refuses every model until it can. No rule or lock refused this call; retry the request"
  }
}
```

Image, audio, video, and OCR endpoints return the message in `error`, with no
code. A dynamic route stops with the same code.

**Retry the request** after the `Retry-After` delay. Another server, or the
same one once it confirms, serves it. Treat `model_access_lock_unconfirmed` as
a temporary error, like a rate limit, and not as a refusal by your rules or
your lock. Model lists keep listing the models you can use. A realtime session
open on such a server is closed, and you can open a new one.

[Logs](https://docs.opper.ai/control-plane/logs.md) shows such a call as **Server could not confirm
locks**, under the **Error** status filter. It names no project and has no
link, because no lock refused it.

## If a change has to wait

Some changes wait for any other lock change in progress: saving a rule, taking,
replacing or releasing a lock, creating a custom model, deploying or rolling
back a [dynamic route](https://docs.opper.ai/capabilities/routes/overview.md), and deleting a project,
in the platform or through the [Management API](https://docs.opper.ai/control-plane/management-api.md).
A change that waits too long is not made. It is answered with HTTP `503`,
`Retry-After: 2`, and the code `model_access_lock_busy`:

```json theme={null}
{
  "error": "Model access locks are busy with another change. Try again in a few seconds.",
  "code": "model_access_lock_busy"
}
```

When the wait was for something other than the locks, the message is "Another
change is in progress. Try again in a few seconds." Nothing was changed.
**Retry the request** after the `Retry-After` delay.

## When a lock ends without a release

| Event | What happens to the locks |
| - | - |
| A locked project is deleted | The delete confirmation says "This also ends its Model access lock". The lock is listed as **Project deleted**, and its details say **Project deleted**. A call or queued job of the project that is still running stays held to the lock. |
| The organization is deleted | While the deletion can still be cancelled, the locks stay active and enforced, and cancelling leaves them as they were. When the deletion goes ahead, every lock is released with the reason **Organization deleted**. |
| The organization moves to a plan without locking, such as Gateway | Every lock in the organization is released and listed as **Plan downgraded**. |
| The organization moves from Enterprise to Control Plane | The locks stay. Control Plane includes locking. |

> [!WARNING]
>
> A downgrade to the Gateway plan also deletes every rule in the organization.
> With no rules and no locks, every project can call every model in the catalog.

On Enterprise, the Audit Log records each change as **Locked model access**,
**Replaced model access lock**, or **Released model access lock**, including
the releases a project deletion or a downgrade makes.

## What a lock does not cover

* **Calls that do not run in a project.** A lock belongs to a project. Calls
  made with an organization key and no project header do not run in a project,
  so no project's lock covers them. They are held to the organization's Model
  access rule alone. For example, a
  [personal agent credential](https://docs.opper.ai/integrations/coding-agents/github-copilot-cli.md#optional-project-attribution)
  works at organization scope until you attribute it to a project. To hold
  calls to a lock, make them with the locked project's API key, or attribute
  them to the project.
* **Custom models and your own provider credentials.** A lock lists Opper's
  routes, so a locked project cannot call a custom model or use its own
  provider credential.
* **Processing Opper runs for itself.** A lock taken from 2 November 2026 has
  none: every model call Opper makes for the project is held by the lock. An
  older lock also records what Opper ran for itself when it was taken, which
  no rule chooses: script generation, plus Opper's embedding model before 27
  October 2026 and error rewriting before 23 October 2026. Opper runs neither
  script generation nor an embedding model of its own now, and does not send
  a locked project's provider errors to a model to rewrite them.
* **Opper's web tools.** A locked project cannot use them. Opper's
  [web search](https://docs.opper.ai/build/gateway/web-search.md) and web fetch tools send queries to
  search and fetch providers that are not routes in the lock, so a request
  that asks for them is refused with `403` and a message that says the tool
  `is blocked by the project's Model access lock`. A model
  provider's own web search is part of the model call and stays inside the
  lock: with `engine: auto`, a model that has one uses it.
* **What Opper stores.** A lock does not change trace storage. Configure it
  under [Opper retention](https://docs.opper.ai/control-plane/rules/retention.md).
* **Other projects.** Each lock holds one project. There is no organization
  lock: to hold every project, lock each one.

## FAQ

> [accordion] Does a lock switch my calls to another model or route?
>
> No. A pinned model outside the lock is refused with `403`. A bare model
> name runs only on providers whose routes are in the lock, and is refused
> when there are none.

> [accordion] How many projects can I lock?
>
> Any number. Each project has its own lock, with its own versions.

> [accordion] How do I check that a lock is in effect?
>
> On Data processing, the lock reads **In force** once every Opper server
> has confirmed it, usually under a minute after it is taken. To check from
> code, list models with the project's API key and `include=policy`: models
> outside the lock read `"blocked_by": "lock"`.

> [accordion] Why did a call fail with 503 and model\_access\_lock\_unconfirmed?
>
> The server that took the call could not confirm its Model access locks,
> so it refused every call for the moment. Retry after the `Retry-After`
> delay. See [If a server cannot confirm its locks](#if-a-server-cannot-confirm-its-locks).

> [accordion] What happens when a locked route's facts change?
>
> The lock holds routes by ID and keeps the facts as it recorded them. The
> route stays in the lock and calls to it go on. When you open **Replace lock**,
> the comparison lists the
> route as **Facts changed**, so you can review the facts the catalog
> records now and create a new lock version.

> [accordion] Does releasing a lock delete it?
>
> No. Every version stays on Data processing with who took it, when it
> ended, and why. Only the project's access changes.

> [accordion] I widened the rules and the new models still fail. Why?
>
> The lock holds the routes it was taken from. The rules can narrow a locked
> project but cannot add routes outside its lock. Select **Update lock** to
> create a new lock version from the saved rules.

> [accordion] Can I take or release a lock from code?
>
> No. Locks are taken, replaced, and released in the Opper platform. You
> can read the effect from code with `GET /v3/models?include=policy`.


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