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 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:
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"
      }
    }
  }
}
  1. 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.
  2. 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.
  3. 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 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 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