Skip to main content
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.
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.

​
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 and teams that carry its traffic, and the 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).
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 for how Wardin maps signed receipts to specific framework controls.