Foundry Model Catalog.

Foundry Model Catalog is a model discovery experience within Microsoft Foundry. It gives teams a place to explore models that may support AI application tasks, review information about candidates, and consider how they could be used in a solution.

The catalog is not a model endpoint, an application, or a guarantee that a model is ready for production. A team typically needs to select an appropriate model, determine how it will be accessed, and build the surrounding application. That application may also need prompts, data connections, evaluation processes, security controls, and monitoring.

A catalog entry provides a starting point for investigation. The details and available options can vary by model, project configuration, and service updates. Teams should verify important requirements for their specific use rather than assuming that all listed models work the same way.

A catalog can help teams narrow a broad set of possibilities. Descriptions and model details may indicate what tasks a candidate is intended to support, the kinds of inputs it can handle, and what options may be available for using it. That information is useful for an initial shortlist, but it does not determine how well a model will perform in a particular organization’s workflow.

Model selection should begin with the work the application needs to do. A team building a document summarizer may prioritize different capabilities from a team creating a classification step or an assistant that uses multiple tools. Framing the task clearly helps avoid choosing a model based only on familiarity, general reputation, or a single benchmark.

A practical evaluation process moves from requirements to evidence:

1. Describe the task. Specify what the application should produce or decide, who will use it, and what inputs it will receive.
2. Identify constraints. Document requirements for data handling, access, latency, reliability, deployment, and organizational policy.
3. Build a shortlist. Use catalog information to set aside candidates that do not fit the task or constraints.
4. Test with representative examples. Use realistic inputs, including ambiguous and unusual cases, rather than relying only on ideal examples.
5. Compare results consistently. Apply the same criteria to each candidate, such as correctness, usefulness, consistency, and handling of uncertainty.
6. Validate the full solution. Test the model within the application, including its prompts, data sources, connected tools, and user experience.

A model that produces strong results in isolation may behave differently when combined with application instructions, retrieved content, or downstream tools. Evaluation should therefore include the way the model will actually be used.

There is rarely a single model that is best for every task. A candidate should be assessed against the needs of the intended workload, not just broad capability claims.

• Task suitability: Does it handle the kind of work the application needs?
• Output quality: Are responses accurate, relevant, and usable on representative examples?
• Input requirements: Can it work with the data types and formats involved?
• Integration fit: Can it be accessed through an approach compatible with the application?
• Operational demands: What are the implications for response time, reliability, and ongoing support?
• Usage and governance terms: Do the applicable conditions align with the organization’s intended use?

These factors can trade off against one another. For example, a model may produce more detailed responses but require additional review, or it may fit the task well while being unsuitable for a particular deployment plan.

A support team wants to categorize incoming requests and create short summaries for employees who triage them. The team uses the catalog to identify potential candidates, then tests each one with examples drawn from routine requests, incomplete descriptions, and uncommon issues.

During evaluation, the team checks whether summaries preserve key facts and whether categories are consistent enough to be useful. It also examines how often the system should defer to a person. The selected model is only one part of the design: the team must also decide what request data can be processed, how the results enter the support workflow, and how employees can correct mistakes.

Finding a promising model does not settle how it will be made available to an application. Access methods, deployment options, and configuration requirements can vary. Before committing to an architecture, confirm that the intended model can be used in the target environment and that the required access and operational arrangements are feasible.

Review the conditions that apply to the specific model and use case. Models can differ in provider, usage terms, data handling, and support expectations. A listing in a catalog should not be treated as approval for every business use or as a substitute for an organization’s review process.

The application also needs safeguards appropriate to its consequences. Consider how it will handle uncertain or incorrect output, whether people need to review decisions, and what information should be logged. Changes to the model, prompts, or connected data can alter results, so testing should continue after initial selection.

Before moving a candidate into development or production, the project team should be able to answer:

• What user task is the model intended to support?
• What examples will demonstrate acceptable and unacceptable results?
• What data will be sent to the model, and what rules govern that data?
• How will the application handle uncertainty, errors, or unavailable services?
• What deployment and access arrangements are required?
• Which outputs or actions need human review?
• Who owns ongoing evaluation and decisions to change models?

Resolving these questions turns model discovery into a practical architecture decision and helps prevent a catalog selection from being mistaken for a finished solution.

Foundry Model Catalog helps teams explore model options, but the catalog alone cannot establish which model will work best in a specific application. Its most useful role is to support discovery and shortlisting, followed by testing against the organization’s own tasks and constraints.

A responsible selection accounts for model behavior, integration, deployment, data handling, and ongoing oversight. The final choice should fit the complete application and the people who will rely on it, not just the model’s description in a catalog.