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

# Applications

> How API keys, environments, and governance policy fit together.

An **application** is how RAIL organizes the AI products you monitor. Each application has its own API keys, its own environment, and its own governance policy. When you evaluate content with a key, the policy attached to that key's application decides how the result is treated.

## The model

<Steps>
  <Step title="Organization">
    Your account belongs to an organization, which owns one or more applications and your team members.
  </Step>

  <Step title="Application">
    Each application represents one AI product or surface you want to govern, for example a support chatbot or a summarizer. It carries a [policy](/concepts/policy-engine) and lives in an environment (currently `production`).
  </Step>

  <Step title="API key">
    Keys are scoped to a single application. Every evaluation made with that key is governed by that application's policy. Create and manage keys in the [dashboard](https://responsibleailabs.ai/dashboard).
  </Step>
</Steps>

## Seeing your configuration

Because a key is bound to an application, you can ask the API what governs it. These read-only endpoints work with any `rail_` key:

<CardGroup cols={3}>
  <Card title="Configuration" icon="gear" href="/api-reference/config">
    The application and policy your key is bound to, and whether enforcement is active.
  </Card>

  <Card title="Dimensions" icon="chart-simple" href="/api-reference/dimensions">
    The 8 RAIL dimensions and how your application weights them.
  </Card>

  <Card title="Capabilities" icon="list-check" href="/api-reference/capabilities">
    The features and limits available to your plan.
  </Card>
</CardGroup>

## Policy comes from the application

You do not pass governance rules on every request. Each application carries one policy, configured once in the dashboard and applied automatically to every evaluation its keys make. A new application starts in observe-only mode, so nothing is blocked until you choose to enforce. See the [Policy Engine](/concepts/policy-engine) for what a policy contains and how the enforcement modes (log, block, regenerate) behave.

**Locked vs unlocked.** By default a policy is *unlocked*: per-request parameters such as `mode`, `domain`, and `weights` override the policy defaults, which is convenient while you experiment. When you *lock* a policy, those request parameters are ignored and the policy is authoritative — useful once you have settled on the governance you want every key in the application to follow. Check the current state any time with [`GET /config`](/api-reference/config).

## Environments

An application runs in an environment — currently `production`. Environments let one application separate, for example, production traffic from staging later on; for now every key is issued against `production`.

<Note>
  Editing a policy requires dashboard access. API keys are for evaluating and reading configuration, not for changing it.
</Note>