# How to evaluate fixed-choice routing with Microsoft-Decision-1

> Microsoft-Decision-1 returns probabilities or scores for bounded questions in Foundry. This documentation-only guide covers version 1 access, requests, validation, price and human review.

By BIGCHANGE.AI Editorial

Published: 2026-10-10T19:26:16.957Z
Updated: 2026-10-10T19:26:16.957Z
Canonical: https://bigchange.ai/blog/microsoft-decision-1-fixed-choice-routing-guide

![Illustrative charcoal drawing of an orange three-position selector switch mounted on a metal panel.](https://bigchange.ai/api/media/file/microsoft-decision-1-fixed-choice-selector-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. The switch is an illustrative analogy, not Microsoft hardware, a model interface, a deployed workflow or an observed outcome.

Microsoft-Decision-1 gives developers a way to score a question against options they define in advance. Microsoft released the model on October 9, 2026, and lists version 1 as generally available in the Foundry catalog. Its output is a typed decision with probabilities or an ordered score, rather than a written answer. This guide follows Microsoft's current documentation; BIG CHANGE has not deployed the model or tested its accuracy, latency or billing.

The useful question for a developer is narrower than whether the model can "make decisions": can an application send a known set of routes or a grading rubric, inspect the returned numbers, and keep control over what happens next? [Microsoft's deployment guide](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-microsoft-decision) documents that path, including the request shape and a small classifier example.

## What goes in and what comes back

A request supplies `state`, which can be text or JSON, and one or more named questions. Each question has a type and instructions. A `choice` question provides fixed option keys and descriptions; the response selects one key and reports a probability for each. A `score` question supplies an ordered list of rubric levels and returns a probability for each level plus a probability-weighted average of their indexes. A `noul` question asks a yes-or-no condition and returns a probability from 0 to 1. Microsoft calls the output a decision, and says the response includes `answers` under the submitted question names, the model name and token usage. The model does not provide a written rationale.

Those distinctions matter when wiring a workflow. For a `choice` route, the application can check that the selected key belongs to its allowed options. For an ordered `score`, the returned number can fall between named levels; it is not necessarily one of the rubric labels. Microsoft advises using scores for relative ordering and thresholds, rather than treating them as absolute calibrated ratings. The application must set and validate any threshold, abstention rule or handoff. A high returned probability does not by itself establish that a route is correct on the developer's own data.

## Run a documented fixed-choice check

These steps describe Microsoft's Foundry workflow as documented on October 9, 2026. They have not been executed by BIG CHANGE.

1. **Confirm access.** Have an Azure subscription with a valid payment method, a Microsoft Foundry project, permission to create a model deployment, and Microsoft Entra ID authentication or an API key. Microsoft's Python quickstart requires Python 3.10 or later and `azure-identity`. The catalog calls Microsoft-Decision-1 generally available, but deployment still depends on the resource, role, region and available deployment type. The guide lists `GlobalStandard` and `DataZoneStandard` in selected regions.
2. **Deploy version 1.** In your Foundry project, open Model catalog, select Microsoft-Decision-1, choose **Deploy**, and copy the resource endpoint and deployment name from the deployment details. Microsoft's CLI example specifies model name `Microsoft-Decision-1`, model version `1` and `GlobalStandard`. Use a deployment type available to your resource; the deployment name you chose, rather than the base model name, is the request's `model` value.
3. **Define the decision.** Supply the state, a question name, `type: "choice"`, instructions and a `criteria` object whose keys are the only allowed routes. This is the support-ticket request printed in [Microsoft's guide](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-microsoft-decision):

```json
{
  "model": "<deployment-name>",
  "state": "The API returns 500 on every call.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "billing": "Charges, invoices, and refunds",
        "engineering": "Bugs, errors, and outages",
        "support": "How-to and account questions"
      }
    }
  }
}
```

4. **Call the decision endpoint.** Send that JSON to `<your-foundry-resource-endpoint>/providers/microsoft/v1/systemone` with `Content-Type: application/json` and either a Microsoft Entra bearer token or the documented `api-key` header. Microsoft's guide has the full `curl` command and an executable Python classifier. Keep credentials out of source code and logs.
5. **Read and validate the answer.** Check for a successful HTTP response and parse the JSON. Find `answers.team`, confirm its type is `choice`, confirm the chosen key is one of the three supplied keys, and inspect the option probabilities and usage. Microsoft's sample code validates the answer shape and allowed key before returning a route. Do not assume any particular route or numeric probability for the request above: this article did not call the endpoint.
6. **Evaluate before automating.** Replace the guide's small sample set with representative, labeled inputs from the intended workload. Measure routing errors and request latency, test altered option wording and order, then choose thresholds based on the cost of a wrong route. Microsoft recommends an explicit `cannot tell` option where a forced choice is inappropriate. Send uncertain cases to another evaluation or a person. Keep the downstream action in application code, where it can be logged and reviewed.

The same `state` can support several named questions in one request. Microsoft's documentation shows `choice` for a team, `score` for severity and `noul` for repeat contact together. That is useful when one routing step needs several bounded judgments, although each question and its criteria still need evaluation on the actual task.

## Cost, data and operational limits

[Microsoft's launch post](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/) lists **$0.042 per million input tokens** and no charge for output tokens. A cost estimate is therefore `input tokens ÷ 1,000,000 × $0.042` at the stated price, before any other applicable Azure charges. For example, 100,000 billed input tokens would cost $0.0042 by that arithmetic. This is a calculation, not a measured bill; the request's usage field and current Azure pricing are the checks for a real workload.

The catalog describes text input and JSON output. The model's decision API is for bounded scoring, classification and grading; it will not compose a response or explain its choice. Microsoft's deployment guide says `GlobalStandard` can process inference in supported Azure regions, while `DataZoneStandard` keeps processing within the selected data zone where offered. Developers with locality requirements should check the deployment type and region before sending production data.

For privacy, send only data needed for the decision and apply the organization's rules for customer or employee information. [Microsoft's Foundry data privacy documentation](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy?view=foundry-classic) describes processing and training treatment for models sold by Azure, but a service policy does not replace the developer's authority to submit a particular record. Microsoft also warns that the model can reflect bias, vary with question wording and miss harmful content. It says the scores must not be the sole basis for consequential decisions about individuals in areas such as credit, employment, housing, healthcare or legal matters; meaningful human review is required there.

## If the result fails a check

Separate transport and permission failures from a questionable decision. Microsoft's troubleshooting table maps HTTP 400 to request shape, 401 to credentials, 403 to deployment access, 404 to endpoint or path, 422 to the deployment name or question definition, and 429 to rate limits. Check the exact field or permission indicated; for 429, Microsoft recommends exponential backoff or more quota. An invalid or missing `answers.team`, unsupported choice key or unusably low confidence should remain unacted on and enter the application's review path. Revise the state, instructions or option definitions against labeled examples, then rerun the evaluation before using the route automatically.

## The big change

Microsoft has made a version 1, generally available Foundry model for fixed-choice and rubric decisions. A developer can supply context and bounded questions, receive per-option probabilities or an ordered score, and write the action policy around that output. The change is an API for numerical decisions inside an application workflow; its usefulness for a particular route still depends on access, representative evaluation and human oversight. Microsoft's reported benchmark speed and accuracy are vendor claims, not results BIG CHANGE reproduced.

## Sources & further reading

- [Microsoft's October 9 launch note](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/) introduces the model, states its price and reports Microsoft's own evaluation. The benchmark figures are not independently verified here.
- [Microsoft's Foundry deployment and API guide](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-microsoft-decision), updated October 9, 2026, documents prerequisites, request types, endpoint, sample code, limits and troubleshooting. This is the basis for the steps above.
- [The Foundry catalog entry](https://ai.azure.com/catalog/models/Microsoft-Decision-1?publisher=microsoft) lists the model's generally available lifecycle, text input and JSON output. Availability to a specific resource still needs checking in Foundry.
- [Microsoft's Foundry data privacy documentation](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy?view=foundry-classic) explains processing geography and data treatment for models sold by Azure. Check the current terms and your own data permissions before use.

## Sources

- [Introducing Microsoft-Decision-1, our model for fast decision-making](https://commandline.microsoft.com/microsoft-decision-1-model-foundry/) — Launch, vendor benchmark claims and posted input/output token price.
- [Deploy and use Microsoft-Decision-1 in Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-microsoft-decision) — Prerequisites, version, deployments, API, request/response, code, limitations and troubleshooting.
- [Microsoft-Decision-1 model catalog](https://ai.azure.com/catalog/models/Microsoft-Decision-1?publisher=microsoft) — Official indexed catalog listing: generally available, text input and JSON output; direct detail page retrieval failed.
- [Data, privacy, and security for Foundry Models sold by Azure](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy?view=foundry-classic) — Vendor data handling and geographic processing reference; data permission remains with user.