Model catalog - Azure Glossary

Understand the concept

In plain English

A model catalog is a discovery experience for finding AI models by provider, task, modality, capability, benchmark, or deployment option. In Microsoft Foundry and Azure Machine Learning, it helps developers, data scientists, and architects compare foundation models, open models, partner models, and deployment choices. The catalog does not remove the need for evaluation. It narrows the search, exposes useful metadata, and connects model selection to deployment, quotas, region availability, safety review, and cost planning. That context keeps model selection practical instead of guesswork.

Why it matters

Model catalog matters because model selection has become an architecture decision that affects data residency, cost, latency, safety, support, and vendor risk. Without a clear definition, teams may change the wrong setting, misread symptoms, or accept weak defaults. The value is not just the feature itself; it is the evidence trail around it. A strong implementation shows who owns the setting, what workload depends on it, how it is monitored, and what should happen before a change reaches production. That makes support faster and reduces surprise during audits, migrations, scale events, model releases, and incidents. Record the owner, evidence, rollback step, and monitoring signal before release.

Official wording and source

Microsoft Learn describes the Microsoft Foundry model catalog as a place to discover and deploy AI models from Azure, partners, and the community. The catalog organizes models by provider, capability, deployment option, and use case so teams can select models for applications.

Open Microsoft Learn

Technical context

Technically, Model catalog sits in the AI model discovery and selection layer in Microsoft Foundry and Azure Machine Learning across catalog entries, model cards, collections, deployment options, and benchmarks. It is represented as a searchable catalog of model entries with provider metadata, capabilities, region or deployment availability, benchmark data, and links to deployment workflows, and it usually depends on Foundry projects, Azure subscriptions, model providers, deployment regions, quotas, permissions, provider terms, safety review, and evaluation process. The boundary is the catalog helps select a model, while Azure resources, projects, endpoints, deployments, evaluations, and monitoring operate the selected model.

Exam context

AI-901 Microsoft Azure AI Fundamentals

Compare with

Model registry Model card Azure OpenAI Service

Where it is used

Where you see it

In Microsoft Foundry and Azure Machine Learning, model catalogs appear as searchable model lists, provider filters, model cards, benchmark details, deployment buttons, and project links.
In planning evidence, they appear through selected model names, provider metadata, region availability, quota requirements, deployment options, pricing notes, and evaluation records, during support, governance, and release review.
In architecture reviews, they appear when teams choose between foundation models, open models, fine-tuned options, serverless endpoints, managed compute, and provisioned throughput, when operators need evidence during support.

Common situations

Find candidate models for an AI workload.
Compare providers, tasks, and deployment options.
Start evaluation from a catalog model.
Connect model selection to quota and cost planning.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Customer service model selection Scenario, objectives, solution, measured impact, and takeaway.

Scenario

WillowMart needed a customer-service chatbot, but teams were testing models from different providers without a common selection process.

Goals

Create a short list of approved catalog models.
Compare deployment options and data residency.
Estimate token cost before pilot.
Document model choice for security review.

Approach using Model catalog

The architecture team used Model catalog as the operating concept for the project. They configured Microsoft Foundry model catalog, model cards, deployment type comparison, Azure Monitor metrics, and cost forecasts, documented ownership and approval rules, and connected the work to Azure Monitor, role assignments, deployment records, and release checklists. Architects used catalog filters for task, provider, and deployment availability, then linked selected cards to internal evaluations and pilot approval records. Operators captured CLI and studio evidence before rollout, then compared metrics and audit records after the change. The runbook also listed failure signals, escalation owners, and the exact evidence required before the release could be marked complete. Architects tagged the chosen model source so future deployments could be traced back to catalog selection evidence. For this workflow, reviewers recorded the business owner, rollback artifact, monitoring window, and dated approval note so later audits could trace the decision.

Potential outcomes

The shortlist was reduced from twelve models to three.
Security review finished 38% faster.
Projected pilot cost was 26% lower than the first candidate.
The selected model met support-quality thresholds.

What to learn

The model catalog turns AI discovery into a governed architecture workflow.

Scenario 02 Manufacturing visual inspection Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Alpine Gearworks wanted AI-assisted defect inspection, but engineers did not know which open vision models could be hosted on approved Azure infrastructure.

Goals

Find candidate vision models for managed compute.
Confirm provider and deployment constraints.
Run internal image evaluation before plant rollout.

Approach using Model catalog

The architecture team used Model catalog as the operating concept for the project. They configured Foundry model catalog, Azure Machine Learning managed compute, model registry entries, storage datasets, and evaluation jobs, documented ownership and approval rules, and connected the work to Azure Monitor, role assignments, deployment records, and release checklists. The team used catalog metadata to identify models compatible with managed compute, then registered finalists and evaluated them on plant-specific defect images. Operators captured CLI and studio evidence before rollout, then compared metrics and audit records after the change. The runbook also listed failure signals, escalation owners, and the exact evidence required before the release could be marked complete. Security reviewers added a provider-review checkpoint before engineers could request wider access to catalog deployments. For this release, operators kept a signed evidence snapshot, rollback marker, and escalation contact so future incidents could be investigated without guesswork.

Potential outcomes

Model discovery time dropped from three weeks to four days.
One provider option was rejected before procurement.
Evaluation accuracy improved 17% over the baseline model.

What to learn

Catalog discovery helps teams find feasible models before they spend engineering time integrating them.

Scenario 03 Public agency language assistant Scenario, objectives, solution, measured impact, and takeaway.

Scenario

CivicBridge Agency needed a multilingual assistant for benefits forms and had to justify model selection to accessibility, privacy, and procurement teams.

Goals

Compare language coverage and deployment types.
Match model selection to privacy requirements.
Prepare evidence for procurement review.
Avoid unsupported regional processing.

Approach using Model catalog

The architecture team used Model catalog as the operating concept for the project. They configured Foundry catalog filters, model cards, deployment-type documentation, Microsoft Entra approvals, and Azure Monitor usage tracking, documented ownership and approval rules, and connected the work to Azure Monitor, role assignments, deployment records, and release checklists. The architecture group reviewed catalog options by language capability, deployment availability, and provider category before starting internal evaluations. Operators captured CLI and studio evidence before rollout, then compared metrics and audit records after the change. The runbook also listed failure signals, escalation owners, and the exact evidence required before the release could be marked complete. Faculty reviewers documented classroom-use assumptions so the pilot model did not expand beyond approved courses. For this workload, the team linked model evidence to the change record, monitoring dashboard, and retraining trigger so ownership stayed clear after launch.

Potential outcomes

Procurement approval cycle shortened by 30%.
The team avoided two models with unsupported region constraints.
Accessibility reviewers received model details early.
Pilot launch stayed within the approved privacy design.

What to learn

A model catalog is valuable because it connects discovery with governance questions from the start.

Azure CLI

Azure CLI is useful for Model catalog because it creates repeatable evidence instead of relying on portal screenshots. Operators can inspect scope, state, identity, network, deployment, job, run, model, endpoint, catalog, or workspace details before approving a change. CLI output also fits automation, audit packages, rollback reviews, and incident handoffs, which makes Model catalog easier to govern consistently.

Useful for

Inventory Model catalog configuration across workspaces, registries, endpoints, deployments, jobs, models, resources, or subscriptions before release review.
Inspect live Model catalog state during troubleshooting, audit evidence collection, migration planning, access review, or rollback validation.
Create, update, compare, deploy, archive, or export related settings through approved automation when the Azure CLI command group safely supports the operation.
Export JSON output for change tickets, compliance review, drift detection, owner handoff, and post-incident analysis.

Before you run a command

Confirm tenant, subscription, resource group, workspace, registry, endpoint, deployment, job, model, experiment, or resource scope before running commands.
Verify your role assignment allows the read, write, invoke, security, monitoring, data, or machine learning action you plan to perform.
Choose JSON, table, or TSV output intentionally so results can be reviewed, scripted, or attached as evidence.
For production changes, confirm maintenance window, rollback path, cost impact, dependent owners, and monitoring coverage first.

What the output tells you

The output shows whether Model catalog exists, where it is scoped, and which Azure resource, workspace, registry, endpoint, job, or model owns the setting.
State, region, identity, network, version, traffic, compute, inputs, outputs, tags, metrics, and timestamps separate configuration problems from workload symptoms.
Repeated output over time can prove drift, confirm remediation, or show whether a deployment reached the intended resource.
Errors usually reveal missing permissions, wrong scope, unsupported region, retired model version, unavailable quota, or an extension that must be installed first.

Mapped commands

Command group

az cognitiveservices account deployment list --name <account> --resource-group <group>

az cognitiveservices account deploymentdiscoverAI and Machine Learning

az ml registry model list --registry-name <registry>

az ml registry modeldiscoverAI and Machine Learning

az ml model list --workspace-name <workspace> --resource-group <group>

az ml modeldiscoverAI and Machine Learning

az monitor metrics list --resource <resource-id> --metric <metric-name>

az monitor metricsdiscoverMonitoring and Observability

Architecture context

A model catalog is the discovery and selection layer for models that can be evaluated, deployed, or referenced by AI applications. In Microsoft Foundry and Azure Machine Learning, it brings together Azure-hosted models, Azure OpenAI models, open models, partner models, benchmark data, model cards, and supported deployment options. The architecture value is controlled choice: teams can compare capabilities while platform owners still define allowed providers, regions, quotas, networking, and cost rules. I review catalog use with procurement, security, and product teams because the selected model can change data processing terms, latency, price, and support boundaries. The catalog should feed an approval workflow, not bypass one.

Security: From a security angle, Model catalog should be reviewed for identity, permission scope, data exposure, secret handling, network reachability, and audit evidence. The common risk is selecting a model from the catalog without reviewing provider terms, sensitive data handling, private networking, content safety, or identity controls. Security teams should check who can create, update, delete, invoke, read, or bypass it, and whether those permissions are direct, inherited, or automated through pipelines. For production use, prefer managed identity, least privilege, private access, encryption, monitored changes, approved secrets handling, and clear exception ownership wherever the Azure service supports them. Record the owner, evidence, rollback step, and monitoring signal before release.
Cost: Cost impact for Model catalog is direct when catalog choices lead to token billing, provisioned capacity, managed compute, or batch processing; indirect when unsupported models cause rework. Direct cost may appear through compute hours, retained capacity, token usage, model serving replicas, image builds, storage operations, data movement, premium features, or monitoring volume. Indirect cost appears when weak ownership causes idle resources, duplicated work, failed access attempts, unnecessary reruns, or prolonged support work. FinOps reviews should identify who pays, what metric drives the bill, and whether cheaper settings still meet the workload requirement. Do not optimize cost by weakening security, durability, compliance, or recovery commitments without documenting the tradeoff.
Reliability: Reliability for Model catalog depends on how it behaves during deployment, scale, maintenance, dependency loss, retry, recovery, and operator error. The key reliability question is whether selected models remain available, supported, region-compatible, and replaceable when providers update versions or deployment options change. Some impact is direct, such as endpoint continuity, reproducible execution, artifact recovery, traffic routing, or workflow rerun behavior. Other impact is indirect, because the setting controls how quickly teams can detect drift and restore known good state. Operators should record dependencies, rollback options, retry behavior, and health signals so incidents start with evidence instead of guesswork. Record the owner, evidence, rollback step, and monitoring signal before release.
Performance: Performance for Model catalog depends on model size, modality, deployment type, quota, region, capacity model, context length, provider runtime, and request pattern chosen from catalog evidence. Useful signals include request latency, throughput, queue time, job duration, data read speed, image build time, dependency resolution, capacity saturation, metric logging overhead, or operator time to diagnose problems. Teams should measure before and after important changes instead of assuming the setting improves performance. Good evidence includes Azure Monitor metrics, job logs, CLI output, application traces, endpoint metrics, storage diagnostics, activity records, and the time support staff need to isolate the bottleneck. Record the owner, evidence, rollback step, and monitoring signal before release.
Operations: Operationally, Model catalog needs a repeatable inspection path. Teams should know which studio page, portal blade, CLI command, SDK call, REST response, metric chart, activity log, diagnostic table, or deployment artifact shows the live state. Runbooks should explain normal ownership, approved change windows, rollback steps, and what evidence to capture after a change. For production environments, avoid undocumented portal-only edits. Use CLI, scripts, tags, source-controlled definitions, and monitoring so support staff can compare actual configuration with intended design quickly during releases, incidents, and audits. Record the owner, evidence, rollback step, and monitoring signal before release. Validate live state before changing dependent workloads or closing the change.

Common mistakes

Changing Model catalog without checking dependent resources, owner approval, monitoring signals, and rollback steps first.
Assuming a studio or portal label tells the whole story instead of validating live state through CLI, logs, diagnostics, access records, or activity history.
Granting broad permissions for convenience, then losing track of who can publish, deploy, invoke, delete, or read sensitive model evidence.
Optimizing for cost or speed without documenting the impact on reliability, security, evaluation quality, compliance, and operational support.