Introduction

Before you can govern a model you have to pick it out of a list, and that list belongs to the connection rather than to UnifyApps. Understanding whose list it is explains why a model you expect to see sometimes is not there.

Where to find it

AI Governance > Model Registry > Add Model. The library is the third step of that drawer.

Getting to the library

Pick the platform — "Select the platform this model is served from." This is the serving platform, not the model's author — a model served through Bedrock is a Bedrock model here regardless of who trained it.
Pick the connection — "Select a connection for {platform}." One platform can have several connections; each has its own credentials, and therefore its own view of what exists.
Pick the models — "Pick one or more models from this connection to import." A searchable, multi-select list with Select all and Clear all, ending in Import N models.

Whose list this is

The library is not a catalogue UnifyApps maintains. It is the answer the connection gives when asked what it can serve, at the moment you ask. Three consequences follow, and each explains a common surprise:

What you see	Why
A model you expected is missing	The connection's credentials cannot see it, or the platform does not expose it to this account
The same model appears under two connections	Two credentials both reach it. They are genuinely two paths, and importing both is sometimes correct
The list is empty	"This connection returned no importable models" — the connection works but has nothing to offer

Note: The library shows what the connection can reach, not what your organisation uses. A hundred available models does not mean a hundred models in production. Import what is actually called; an inventory of things nobody uses is noise in every report downstream.

What a row tells you, and what it does not

Each row carries the model's name and the platform's icon. That is all — there is no type, context window or pricing shown at selection time.

So the decision at this step is made on the model identifier alone. If your naming is such that -v2 and -v2-preview are meaningfully different, that difference has to be legible in the name, because nothing else at this step will tell you.

Import is not registration

The vocabulary difference is real and worth keeping straight:

	Registering an agent	Importing a model
You supply	Name, description, owner, department	A selection
Identity comes from	You	The serving platform
Volume	One at a time	Many at once
Afterwards	Instrument it, then wait for traces	Nothing — spans arrive if anything calls it

Because import is bulk and cheap, it is easy to over-import. The correction is not technical: decide before opening the drawer which models you actually intend to govern, and import those.

After importing

Check who owns them — Imported models take the person who imported them as owner. The owner cannot be changed from the model page afterwards, so import from the account of the person who should own them.
Expect Inactive at first — A model is Active once spans arrive. Freshly imported and quiet is the normal starting state.
Point a policy at it — Importing brings a model into the inventory. It does not govern it — nothing does until a policy covers it. See Apply a Policy to Assets.

"Importing a model tells you it exists. It does not tell you anyone is watching it."

When you should not use this drawer at all

If the connection already runs discovery sweeps, models arrive on their own and appear on the connection's asset list alongside agents. Importing by hand is for the case where you want a specific model in the registry now, rather than at the next sweep — or where you want a narrow selection rather than everything the sweep returns.

For the sweep-driven path, see Review & Triage Discovered Assets.

The Model Library