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

# AI Use-Case Registry

> Wardin's evidence-bound AI inventory — register use cases with a risk tier, allowed models, and bound keys/teams/policies, then reconcile the registry against actual gateway traffic to surface shadow AI (registered vs. observed).

Every auditor asks for the same artifact first: an **inventory of your AI systems**. The
usual registry is a self-reported system-of-record — a form someone fills in, which
nothing checks against reality. Wardin inverts that. Because the gateway already sits in
the request path, the registry can be **reconciled against actual traffic**: what you
*registered* versus what the gateway *observed*.

<Note>
  The registry covers **gateway-routed AI only** — the traffic Wardin actually sees. It is
  not, and cannot be, a discovery tool for AI systems that never touch the gateway. Every
  surface states this scope explicitly.
</Note>

## What a use case is

A **use case** is one registered AI application, carrying:

* a **risk tier** — the EU AI Act classification (`unacceptable` / `high` / `limited` /
  `minimal`), which frames the obligations it must meet;
* **allowed models** — the models this use case is permitted to run (empty = no
  restriction declared);
* an **owner** and a **status** (`draft` / `active` / `retired`);
* **bindings** to the [virtual keys](/concepts/virtual-keys) and teams that carry its
  traffic, and the [policies](/concepts/policies) that govern it.

Registration is not paperwork — binding a use case to its keys/teams and policies is what
makes it *reconcilable*. A use case **covers** a key when the key is bound to it directly,
or when the key's effective team (the same `COALESCE(key.team, owner.team)` rule the cost
ledger uses) is bound to it.

## Registered vs. observed (drift)

The registry's payoff is **drift** — the diff between what's registered and what's on the
wire, over a chosen window:

* **Unregistered keys** — keys running traffic that no active use case covers. This is
  shadow usage, evidence-backed.
* **Disallowed models** — a `(key, model)` pair on the wire where the key *is* covered,
  but the model falls outside every covering use case's allowlist. A use case with an
  empty allowlist is treated as *unrestricted*, so it never generates false drift; a
  **retired** use case stops covering its keys, so retiring an entry re-surfaces its
  traffic as drift.
* **Shadow usage by team** — unregistered request volume grouped by team.
* **Coverage %** — the share of on-the-wire requests attributable to a registered use
  case.

## Where to find it

The registry lives in the **Console → AI Registry** section. The Drift panel sits up top
(registered-coverage KPI band, plus the unregistered-keys, disallowed-models, and
by-team lists); below it, the registry list lets a manager create, edit, and delete
entries and inspect each entry's real traffic and observed models (`ALLOWED` /
`OFF-LIST`).

Reads are available to any member; creating or editing a use case requires a **manager**
role (registering a use case wires it to enforcement policies, so it's org configuration).

<Note>
  Risk-tier labels reference the EU AI Act's classification scheme to help you organize
  your inventory. They are an organizational aid, **not** a legal determination that a given
  system belongs in that tier — that classification is yours (and your counsel's) to make.
  See [Framework Coverage](/concepts/framework-coverage) for how Wardin maps signed
  receipts to specific framework controls.
</Note>